[04:15] <micahg> RAOF: can you copy chromium to precise-security as well?
[04:17] <RAOF> micahg: It wasn't already? Urgh.
[04:18]  * micahg didn't see it on the list
[04:21] <xnox> whoever synced sinfo, thank you.
[04:22] <xnox> infinity: was that you? ^
[04:23] <micahg> xnox: 'twas jbicha on 6/30
[04:24] <xnox> thanks jbicha for sinfo sync
[04:24] <xnox> micahg: ok, but how did you find out? =)
[04:25] <micahg> xnox: quantal-changes :)
[04:26] <xnox> micahg: lp lists it here: https://launchpad.net/~jbicha/+synchronised-packages but not
[04:26] <xnox> https://launchpad.net/ubuntu/+source/sinfo/0.0.46-1
[04:26] <xnox> =(
[04:26]  * xnox should start subscribing to quantal-changes....
[04:26] <micahg> xnox: https://lists.ubuntu.com/archives/quantal-changes/2012-June/003787.html
[04:28] <slangasek> xnox: has ev brought you my DVI cable? :)
[04:29] <xnox> slangasek: nope =) will get him tomorrow
[04:29] <slangasek> ev: take my DVI cable to work with you! :)
[04:30] <RAOF> slangasek: At your leisure, could I get your opinion on https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/978012
[04:30] <ubot2> Ubuntu bug 978012 in e2fsprogs "Please SRU micro bug fix release of e2fsprogs 1.42.4-3ubuntu1 (main) from Quantal (main)" [High,Confirmed]
[04:30] <xnox> slangasek: RAOF needs more work from me
[04:30] <slangasek> RAOF: as long as you understand that "my leisure" is likely to only be 18 hours or so from now
[04:31] <xnox> after my recent experience with mdadm...
[04:31] <xnox> sru
[04:31] <RAOF> slangasek: That's fine; I just want to get it on your radar.
[04:39] <jbicha> xnox: yeah, it would be nice if LP would list who requested the sync on that version page
[04:41] <micahg> jbicha: there's already a bug for that
[04:41] <xnox> micahg: "there is an app for that" vs "there is a bug for that"
[04:41]  * xnox *sigh*
[04:50] <micahg> jbicha: bug 861488
[04:50] <ubot2> Launchpad bug 861488 in launchpad "Mention sync requester on package version page" [High,In progress] https://launchpad.net/bugs/861488
[05:04] <infinity> RAOF: I looked at it when it was first filed, and the rationale all seemed sensible then.  Haven't revisited it, though.
[05:05] <RAOF> infinity: Agreed, except possibly for the "makes my life easier" bit. It's just a sizable chunk of diff for a critical package.
[05:20] <infinity> RAOF: Yeah, give this one to me.  I was watching it earlier, but didn't notice Ted's updated comments more recently.
[05:20] <infinity> RAOF: I'm in a reasonable position to review, though.
[05:20] <RAOF> infinity: Excellent.
[05:20] <RAOF> This is an outcome I was hoping for.
[06:33] <tjaalton> RAOF: howdy ho, I've uploaded a new upstream microrelease (ugh) of libmusicbrainz to precise-proposed. the current version became obsolete when Musicbrainz changed their web api after precise release :/
[06:33] <tjaalton> bug 1005075
[06:33] <ubot2> Launchpad bug 1005075 in libmusicbrainz "Libmusicbrainz fails to parse metadata after recent MusicBrainz API update" [High,In progress] https://launchpad.net/bugs/1005075
[06:34] <tjaalton> the fix was in the 4.0.3 release, but it depended on other stuff from the earlier bugfix snapshots
[06:34] <tjaalton> so little reason to backport
[06:35] <RAOF> Hurray for web APIs
[06:35] <tjaalton> yeah
[06:40] <RAOF> Race of the jobqueues: will libmusicbrainz get a launchpad diff before alioth has processed my SSH key?
[06:41] <tjaalton> I'm afraid the diff looks scarier than it actually is
[06:41] <tjaalton> since the package has the api docs in it too
[06:43] <tjaalton> most of it is in schema & tests
[06:43] <tjaalton> actual source changes aren't that huge :)
[06:47] <micahg> RAOF: ^^
[06:47] <RAOF> Ack.
[07:00] <RAOF> tjaalton: You don't happen to know if any rdepends will FTBFS if they use deprecated functions?
[07:01] <tjaalton> RAOF: the only one is sound-juicer, I'll try to rebuild it
[07:01] <tjaalton> all others still use libmb3
[07:06] <RAOF> tjaalton: Also, how sure are you this doesn't break ABI?
[07:06] <tjaalton> RAOF: I take upstream's word for it :)
[07:06] <tjaalton> sound-juicer built fine
[07:07]  * RAOF is not going to take upstream's word that they've managed to somehow not break their C++ ABI  ☺
[07:08] <RAOF> Especially since they've added fields to classes and changed some signatures.
[07:08] <tjaalton> ok, if you can add a comment there and I'll ask andy to reply
[07:09] <tjaalton> would that suffice?
[07:09] <RAOF> I'd prefer diffing the set of exported symbols, but I'm not sure what tools we have to ensure C++ ABI.
[07:14] <tjaalton> me neither
[07:16] <RAOF> Commented.
[07:18] <tjaalton> thanks
[08:36] <ev> slangasek: will have to do it tomorrow. I didn't see your message until just now.
[08:36] <tjaalton> RAOF: andy replied, so looks like it is safe abi wise
[08:37] <xnox> ev: well I didn't forget my NERF gun, so watch out ;-)
[08:37] <ev> hahaha
[08:42] <ogra_> hmm, no images and no build failure mails is worrying
[09:36] <infinity> ogra_: No images and no failures usually means things are still building.
[09:37] <infinity> ogra_: (Which seems likely, given the number of BuildLiveCDs I see)
[09:37] <cjwatson> Poor celbalrai.
[09:38] <xnox> =)
[09:38] <infinity> Yeah,
[09:38] <infinity> Also, I'm not seeing --f ext4 on those precise builds.
[09:39] <infinity> I suspect the if [ "$IMAGE_TYPE" = "daily-preinstalled" ]; bit isn't doing what it was meant to.
[09:40] <ogra_> infinity, we only have one preinstalled image left
[09:41] <infinity> ogra_: Not in precise.
[09:41] <ogra_> well, apart from server
[09:41] <ogra_> oh
[09:41] <ogra_> right
[09:41] <infinity> Methinks you broke that.
[09:42] <ogra_> did i ?
[09:43] <infinity> Well, I see 3 precise builds going, and none of them has -f ext4
[09:43] <ogra_> oh, i might actually
[09:43] <ogra_> well, the server building in quantal, not the precise builds
[09:46] <infinity> Actually, how is that broken?
[09:46]  * infinity scratches his head.
[09:47] <infinity> Those are buildlive daily-live processes.
[09:47] <infinity> Not daily-preinstalled.
[09:47] <ogra_> server ?
[09:47] <ogra_> there should be a server preinstalled build
[09:47] <ogra_> which my recent changes to etc/default-arches accidentially disable
[09:47] <infinity> Not server.
[09:48] <ogra_> *                       daily-preinstalled      maverick-precise        armel+omap armel+omap4
[09:48] <ogra_> that should cover it
[09:48] <infinity> mx5, omap4, omap currently.  All precise/ubuntu.
[09:49] <infinity> We shouldn't even have precise armhf builds at all, according to crontab.
[09:50] <infinity> Well, we wouldn't, if they weren't being triggered as daily-live jobs.
[09:50] <ogra_> looking at etc/default-arches i dont see how thats possible
[09:53] <infinity> cdimage@nusakan:~/cdimage$ bin/default-arches ubuntu daily-live precise
[09:53] <infinity> amd64 amd64+mac i386 powerpc
[09:53] <infinity> Certainly seems to DTRT.  So, WTF triggered all those builds?
[09:55] <infinity> The timing of them matches with the precise daily-live cronjob.
[09:55] <infinity> Bother.
[09:56] <ogra_> well, the quantal buildlive run is only 1h earlier
[09:56] <ogra_> are yousure it is not that one ?
[09:56] <infinity> I'm sure.
[09:56] <ogra_> weird
[09:56] <infinity> The quantal one also spawned a BuildLiveCD.
[09:56] <infinity> Which is, y'know, quantal.
[09:57] <infinity> And an hour earlier. :P
[09:57] <ogra_> yeah yeah
[09:58] <infinity> Meh, I should be sleeping, not trying to reason at 4am.
[11:05] <psivaa> apw, ping
[11:07] <psivaa> cjwatson, apw, I can not find amd64 and i386 desktop images in cdimage.u.c. Any idea why and where they are? :)
[11:08] <apw> psivaa, for which release
[11:08] <psivaa> apw,sorry for quantal
[11:09] <psivaa> apw, http://cdimage.ubuntu.com/daily-live/current/
[11:09] <infinity> He's not wrong, they seem to have walked away.
[11:10] <apw> psivaa, indeed they seem to be missing, i assume they failed to build last night
[11:10] <infinity> If they failed to build, it would copy the images from the previous day.
[11:10] <infinity> This is something more insidious.
[11:10] <psivaa> apw, ack, but i would have thought in that case the latest successful image be present there
[11:13] <cjwatson> Normally it is.
[11:13] <cjwatson> I think it's just been failing for long enough that they got expired.
[11:14] <psivaa> apw, infinity, cjwatson ack and thanks :)
[11:14] <cjwatson> And yet the livefs build here was fine.
[11:14] <infinity> It's not just livefs.
[11:14] <infinity> The whole world is missing x86.
[11:15] <infinity> server/daily, for instance.
[11:15] <cjwatson> Ah, I see
[11:15] <infinity> But thank god we have powerpc builds of everything.  We're saved.
[11:15] <cjwatson> no entry data.tar.gz in archive
[11:15] <cjwatson> debian-cd isn't too clever
[11:16] <infinity> Trying to unpack a goofy .deb?
[11:16] <cjwatson> data.tar.xz
[11:16] <infinity> Or, rath... Yeah.
[11:16] <infinity> grub?
[11:16] <cjwatson> Probably syslinux.
[11:16] <infinity> (or some other bootloa..)
[11:16]  * cjwatson goes to attempt to modernise that code.
[11:17]  * infinity tries once more to nap.
[11:22] <cjwatson> Should be fixed.  Trying an updated build now.
[15:11] <slangasek> ev: ok ;)
[16:00] <jbicha> could someone let libzapojit through the new queue? it's needed for gnome-documents
[16:04] <gema> cjwatson: the smoke testing failed on the new build, not sure why, though
[16:04] <gema> cjwatson: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-amd64_default/71/console
[16:04] <gema> cjwatson: that'd be 20120703.1
[16:16] <ogra_> it seems it tries to quit smoking
[16:16] <ogra_> so many broken pipes
[16:17] <cjwatson> Having trouble making sense of that :)
[16:17] <cjwatson> Does it fail manually?
[16:17] <ogra_> stdout not available somehow ?
[16:17] <gema> cjwatson: it does, look at bug 1020574
[16:17] <ubot2> Launchpad bug 1020574 in ubiquity "installing ubuntu on virtualbox" [Critical,Confirmed] https://launchpad.net/bugs/1020574
[16:17] <cjwatson> OK, approaching end of day but I'll see if I can have a quick look
[16:17] <gema> cjwatson: haven't tried HW, though
[16:19] <gema> cjwatson: I don't blame you for not being able to make sense of that log, I have trouble as well, there are more logs that may be interesting on jenkins , though
[16:19] <gema> cjwatson: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-i386_default/55/artifact/55/test-results/
[16:21] <cjwatson> Might as well reproduce locally
[16:21] <gema> cjwatson: plugininstall.py seems to give a systemerror
[16:21] <gema> cjwatson: 32: Broken pipe
[16:21] <cjwatson> Yeah, I can see that
[16:21] <gema> haha, I am glad I am looking in the right place :D
[16:22] <cjwatson> But as ogra_ suggests that implies some file descriptor or other going away but is very very unspecific
[16:23] <ogra_> and it could be anywhere down the chain
[16:23] <cjwatson> My guess would be an apt/python-apt regression from the uploads on 2012-06-29, but it will need disentangling
[17:31] <infinity> jbicha: Out of curiosity, do you do a large number of manual syncs to pad the numbers, or because you can't wait for the autosyncs? :)
[17:53] <jbicha> infinity: most of my syncs weren't autosyncable because they had Ubuntu changes
[17:54] <infinity> jbicha: Ahh.  There just seems to be a lot of them. ;)
[17:55] <seb128> infinity, hey!
[17:55] <seb128> infinity, will you do a round of SRU reviews today since you were off yesterday? ;-)
[17:55] <jbicha> yeah, I grabbed the easier ones, there won't be near as many for a while
[17:55] <infinity> seb128: I might do a few.  What's on your hitlist?
[17:57] <seb128> infinity, gwibber, apport (follow up for the current version which is failing verification), software-center and ubuntu-sso-client (they fix some of the top reported issues on errors.ubuntu.com), ubuntuone-client
[17:57] <seb128> infinity, check with bdmurray maybe before doing review, I tried to nudge him about some of those as well earlier ;-)
[17:57] <infinity> bdmurray: ^
[18:00] <bdmurray> seb128: software center has a couple of bugs not fixed in quantal afaict see #ubuntu-devel
[18:00] <seb128> can we stop being religious about those?
[18:00] <seb128> I'm sure mvo will do an upload to quantal soon enough with the fixes in the Vcs
[18:01] <bdmurray> oh I see the bugs do have upstream branches attached
[18:03] <seb128> doh, one day I will stop doing ctrl-R on xchat text entry
[18:04] <bdmurray> heh
[18:27] <infinity> Hrm.  sru-accept's '-s' switch doesn't seem to work as advertised.
[18:27] <cjwatson> How so?
[18:27] <infinity> Erm.
[18:27] <infinity> Nevermind.
[18:27] <infinity> Brain and eyes disagreeing.
[18:28] <cjwatson> OK :)
[18:28] <infinity> I want -p PACKAGE, but I'm so used to -s/S being for SOURCEPKG.
[18:28] <infinity> La la la.
[18:28] <cjwatson> Ah, yeah.  Let's use long options for everything. :-P
[18:30] <infinity> Entertainingly, this give me a URL of ubuntu/+source/None/1.2.3-1
[18:30] <infinity> SMRT.
[18:31] <bdmurray> infinity: I fixed the none url thing what revno are you on?
[18:31] <infinity> bdmurray: The current.
[18:31] <infinity> bdmurray: Oh.
[18:31] <infinity> bdmurray: Current NOW, wasn't on the first accept. :P
[18:31] <bdmurray> infinity: ah ha
[18:32] <infinity> bdmurray: What will it do if I call it without -p now? :)
[18:32] <bdmurray> infinity: not give a url for the build
[18:32] <infinity> Ahh.
[18:33] <infinity> So, given that we only expect sru-accept to be called by people with queue privs (right?), can we not make it actually do the accepting too?  Which would then let us just feed series/packagename, and not have to specify version, cause it can yank it from the queue, and do the accept?
[18:34] <infinity> (This also would make it feel more in line with sru-release)
[18:35] <slangasek> infinity: accepting my packages before I've even written the proper SRU blurbs? :)
[18:35] <infinity> slangasek: Quick, what's the regression potential?
[18:35] <infinity> slangasek: OH GOD, HOW DO I TEST?!
[18:35] <slangasek> infinity: see bug description for the answer
[18:35] <infinity> slangasek: I think we're covered.
[18:37] <infinity> slangasek: On the other hand, testing this could be a problem.
[18:37] <slangasek> 1) go back in time; start mysqld
[18:37] <infinity> slangasek: Unless you set up a fake stratum-1 server as your upstream and set your clocks back.
[18:37] <slangasek> alternatively, 1) fake a leap second, yeah
[18:38] <infinity> Though, in one of the lkml threads, there was a quick PoC for faking the leap second, I think.
[18:38] <infinity> So, no need to involve ntp.
[18:38] <infinity> Assuming you consider the synthetic test to be equivalent.
[18:38] <slangasek> ah, can you lay your hands on the relevant mail and stick a pointer in the bug description?
[18:39] <slangasek> I do consider the synthetic test equivalent, provided it triggers the futex-spinning issue in the first place
[18:39] <infinity> Should do.  Let me see if I can dig it up.  It was attached to the new-and-improved kernel patch.
[18:41]  * slangasek hehs, noticing that the one machine he has mysqld running on doesn't seem to be affected... except mythbackend
[18:42] <infinity> https://lkml.org/lkml/2012/7/3/37
[18:42]  * infinity slaps that in the bug.
[18:43] <slangasek> ta
[18:43] <infinity> It's under your Test Case bit now.
[18:44] <stgraber> "Dear Mr. Graber, During the night of 30.06.2012 to 01.07.2012 our internal monitoring systems registered an increase in the level of IT power usage by approximately one megawatt. The reason for this huge surge is the additional switched leap second which can lead to permanent CPU load on Linux servers." <- is what I got this morning from my DC hosting provider :)
[18:45] <infinity> stgraber: Nice.
[18:45]  * slangasek raises an eyebrow
[18:45] <elmo> stgraber: herzner?
[18:45] <slangasek> presumably that's not a 1MW increase in your personal power usage :)
[18:46] <infinity> Given that we've already been down this road a few years ago, this seems like a bit of egg-on-face situation for Linux in general.
[18:46] <infinity> RedHat having to amend their "we fixed it" announcements with "no, really, we mean it this time" is fun.
[18:46] <stgraber> elmo: yeah
[18:48] <elmo> stgraber: http://imgur.com/a/ykoup/noscript <-- pics because it happened
[18:48] <slangasek> well, the architecture of how we're handling leap seconds on Linux is fundamentally wrong... the kernel and filesystems should be keeping time with a monotonically incrementing time_t, and it should be glibc's problem to fix up the display :P
[18:48] <highvoltage> wait what
[18:48] <slangasek> *all* the problems we have with leap seconds are a result of this architecture bug
[18:49] <highvoltage> that's not really an increase of a megawatt then? it just went over a megawatt?
[18:49] <infinity> elmo: That graph was a lot more impressive before I realise it wasn't based at 0.
[18:49]  * highvoltage is dissapointed
[18:49] <infinity> slangasek: To be fair, we do what POSIX tells us to do WRT time_t.
[18:49] <infinity> slangasek: Not that that's necessarily right.
[18:50] <tumbleweed> we disobey posix, quite happily, elsewhere
[18:50] <slangasek> infinity: which part of POSIX?
[18:50] <infinity> slangasek: I do appreciate the Google solution to the problem, though.  I wonder if they've upstreamed that and I can toggle it in my ntp.conf.
[18:50] <slangasek> tumbleweed: not really
[18:50] <tumbleweed> not in such a fundamental way, sure
[18:51] <cjwatson> infinity: do the accepting - I'll do that once I've got a bit more of my queue API work landed
[18:51] <slangasek> tumbleweed: the kernel adheres quite closely to POSIX, and so does glibc
[18:51] <micahg> awesome, just have aptitude SIGSEGV on me :)
[18:51]  * micahg taps foot for fix for ntp issue :)...
[18:51] <infinity> slangasek: If I recall, the POSIX definition of "seconds since the epoch" doesn't actually match with real seconds (ie: doesn't account for leap seconds), but is rather just a function of number of days since the epoch, times 86400.
[18:52] <slangasek> infinity: ah, cute
[18:52] <slangasek> so yeah, can we fix POSIX kthx
[18:54] <cjwatson> infinity: which should actually be in a couple of days
[18:54]  * infinity crosses his eyes trying to double-check the version comparison of "5.0.0ubuntu<IP_ADDRESS>".
[18:55] <micahg> BTW, I don't think it's related to mysql/java processes, I seem have crashes all over the place (thunderbird, firefox, aptitude)
[18:55] <micahg> s/related/limited to/
[18:55] <infinity> micahg: Oh, it's not directly related to either.
[18:55] <slangasek> bdmurray: how does bug #1020529 fit as a dupe of bug #887892?
[18:55] <ubot2> Launchpad bug 1020529 in udev "package udev 173-0ubuntu4.2 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1 (dup-of: 887892)" [Undecided,New] https://launchpad.net/bugs/1020529
[18:55] <ubot2> Launchpad bug 887892 in udev "lucid->oneiric upgrades fail udev upgrade: unrecognized option '--convert-db'" [High,Fix released] https://launchpad.net/bugs/887892
[18:55] <infinity> micahg: It's just that some things tickle the bug more reliably than others. :P
[18:55] <slangasek> bdmurray: is that maybe a typoed bug #?
[18:56]  * micahg manually grabs base-files to hopefully end this nightmare
[18:56] <slangasek> bdmurray: (bug #937196 seems more likely)
[18:56] <ubot2> Launchpad bug 937196 in apt "10.04 LTS -> 12.04 upgrade failed: ifupdown depends on upstart and initscripts but they are not configured" [High,Confirmed] https://launchpad.net/bugs/937196
[18:57] <infinity> slangasek: That same output is in the term log for the first bug.
[18:57] <bdmurray> slangasek: there is a pattern for <re key="VarLogDistupgradeApttermlog">unrecognized option '--convert-db'</re>
[18:58] <infinity> micahg: Have you been intentionally letting it spin until we pushed out a fix?
[18:58] <micahg> infinity: sort of :)
[18:58] <infinity> micahg: If so, thanks for being a guinea pig?
[18:59] <slangasek> bdmurray: ah, ok - I had only looked at VarLogDistupgradeTermlog
[18:59]  * infinity fixed all his systems when he first noticed it.
[19:00] <infinity> Though, while all the servers I admin had the issue, the hilarious bit is that I noticed it first on my laptop.  Because it was burning my knee.
[19:00]  * slangasek wonders why VarLogDistupgradeTermlog and VarLogDistupgradeApttermlog are even separate files
[19:00] <infinity> True story.
[19:01] <infinity> I don't know, I just wish I could consistently click on them and have them always do the same thing.
[19:02] <stgraber> for some reason my laptop was the only system I admin not to be affected, my current guess is that the ifupdown ntpdate hook triggered soon after the leap second was added, updating the system time properly
[19:02] <infinity> Some zipped, some not, open in browser, open file-roller, hurts my brain.
[19:02] <infinity> stgraber: Or your laptop doesn't run ntp?
[19:03] <infinity> stgraber: Most don't.
[19:03] <infinity> (why mine does was examined shortly after the bug hit me, and ntp is now uninstalled)
[19:04] <slangasek> a computer without ntp? heresy
[19:04] <infinity> slangasek: I stopped to think about just how useful ntp probably isn't on a machine that spends ~50% of the day suspended, and.. Well.  Yeah.
[19:04] <infinity> Bye, ntpd.
[19:05] <stgraber> infinity: oh, I thought I had ntp running on that one too but apparently not, that explains it then
[19:05] <slangasek> infinity: but then how will the system know what time it is when it wakes up!
[19:06] <infinity> slangasek: ntpdate?  Also, batteries? ;)
[19:06] <stgraber> might have ntpd back on there soon though as I'm moving back to using kerberos (well, samba4) for authentication and well, kerberos is still picky about time...
[19:06] <infinity> slangasek: ntpdate gets me close enough, I'm sure, and if the all-magical HPET timer is so crap that it can't keep consistent time over the 2 or 3 hours between naps, I think this machine has bigger problems.
[19:07] <infinity> stgraber: Yeah, krb's a sticking point.  I don't use it internally.
[19:07] <slangasek> yes, kerberos is meant to be used topically
[19:07] <infinity> So, for me, consistent time on my laptop is just about time not going backward, and generally going forward at a sane rate.  The hardware can handle that.
[19:07] <infinity> (I hope)
[19:08] <stgraber> infinity: is your laptop using UTC then? (otherwise the going backward part might still happen ;))
[19:08] <infinity> stgraber: It's UTC at the hardware level, like any sane UNIX machine.
[19:09] <infinity> stgraber: Timezones are purely for display purposes.  Unless you're DOS.
[19:09] <slangasek> see above re: monotonic clocks :P
[19:10] <infinity> slangasek: Yeah.  There was a good write-up somewhere about your complaint.  Maybe I'll find it again later.
[19:10] <stgraber> infinity: right, DST isn't messing with the system time, just with everything else :)
[19:11] <infinity> slangasek: We even *have* the right timezone sets (though we don't use them) for adding the :60 second instead of repeating :59, but it's due to the internally inconsistent POSIX "hey, what exactly is time_t anyway?" issues that we don't.
[19:11] <slangasek> grmble
[19:11] <slangasek> so
[19:11] <slangasek> seriously
[19:11] <slangasek> how do we get POSIX fixed?
[19:11] <infinity> Time machine.
[19:11] <infinity> Except, then you'll go into an infinite loop.
[19:12] <infinity> *rimshot*
[19:12] <slangasek> :P
[19:12] <slangasek> cjwatson: efilinux uploaded
[19:12]  * infinity runs to the store to caffeinate.
[19:26] <mvo> seb128, bdmurray: right, let me double check the state of quantal, but its either in bzr or already in quantal and maybe the bug did not get closed for some reason :/
[19:32] <bdmurray> mvo: being in bzr was good enough for me this time
[19:32] <seb128> mvo, hey, thanks ... aptdaemon SRU testing, did you find anyone? Sorry to be nagging about it but it's in proposed for 19 days
[19:33] <infinity> stgraber: I just got a conffile prompt from netbase about /etc/services... In an sbuild chroot.  I have a hard time believing I modified it by hand.
[19:34] <stgraber> infinity: hmm, I didn't get that on my test upgrades, any chance you saved the delta?
[19:35] <infinity> stgraber: It was in an overlay, so yeah, the original state is still around.
[19:35] <infinity> stgraber: I'll poke you with details once I'm done doing what I was actually doing.
[19:35] <stgraber> ok
[19:36] <mvo> seb128: I know, gary is on vac right now and I didn't find time yet, I will try again tomorrow
[19:36] <mvo> seb128: and no worries, its not naging, its important :)
[19:36] <seb128> mvo, thanks
[19:36]  * mvo hugs seb128
[19:36]  * seb128 hugs mvo back
[19:36] <mvo> bdmurray: thanks a lot
[19:41] <slangasek> infinity: schroot itself has an annoying tendency to overwrite /etc/services as part of the chroot setup
[19:41] <slangasek> it does /etc/services, /etc/protocols, and a few other things
[19:41] <infinity> slangasek: Oh, that seems silly.
[19:41] <slangasek> yes, I agree
[19:41] <slangasek> I've taken to just blindly hammering the enter key when they come up
[19:41] <slangasek> feel free to respond more productively than I have, by filing a bug or something :)
[19:42] <infinity> Well, for sbuild builds, it just skips the conffile prompt anyway.
[19:42] <infinity> But why it's replacing it at all is a mystery.
[19:42] <slangasek> nss something something
[19:43] <slangasek> /etc/schroot/default/nssdatabases
[19:43] <slangasek> honestly, why would anyone think there are relevant differences in /etc/protocols between host and guest
[19:44] <infinity> Or services, in 99% of cases.
[19:44] <infinity> And, yet, it doesn't copy nsswitch.conf
[19:44] <infinity> Which one would think might be more useful.
[19:44]  * infinity shrugs.
[19:44]  * infinity just edits that file and moves on with life.
[19:44] <slangasek> except that nsswitch.conf requires additional package installations
[19:45] <slangasek> so copying that would be even MORE insane
[19:45] <infinity> slangasek: Perhaps, yes. :)
[19:45] <infinity> Well, copying it by default would be insane.
[19:45] <infinity> Perfectly sane to have a commented-out suggestion in there.
[19:45] <infinity> "If you use nss-db to keep the base system and chroots in sync, install it in your chroots, and uncomment the following mess"
[19:46] <infinity> Or something.
[19:46] <infinity> Anyhow.  I don't do that anymore.
[20:12] <slangasek> Daviey: glance SRU has been pending verification for 20 days; is anyone responsible for validating these fixes?  (bugs #981332, #983829, #980872)
[20:12] <ubot2> Launchpad bug 981332 in glance "Content-Length and Transfer-Encoding are mutually exclusive HTTP headers" [Undecided,In progress] https://launchpad.net/bugs/981332
[20:12] <ubot2> Launchpad bug 983829 in glance "[sru] notify_kombu incorrect message format for logging" [Undecided,In progress] https://launchpad.net/bugs/983829
[20:12] <ubot2> Launchpad bug 980872 in glance "[sru] 'unhashable type' when sending notifications via Qpid" [Undecided,In progress] https://launchpad.net/bugs/980872
[20:15] <slangasek> Daviey: similar situation for keystone (bugs #959294, #998137)
[20:15] <ubot2> Launchpad bug 959294 in keystone "[SRU] Can't delete users" [Undecided,Fix committed] https://launchpad.net/bugs/959294
[20:15] <ubot2> Launchpad bug 998137 in keystone "[SRU] Keystone user tenant membership not always removed" [Undecided,Fix committed] https://launchpad.net/bugs/998137
[20:16] <Daviey> slangasek: Yes.. we waited for all of the openstack sru's to get accepted before pursing it.  Then, because nova had a pending security update, that was made the priority
[20:16] <slangasek> hmm, ok
[20:16] <Daviey> We wanted to make sure the process was sound, and will target the rest this week
[20:16] <slangasek> ok cool
[20:16] <Daviey> nova was undoubtedly the hardest, so these should be easier
[20:17] <slangasek> anyone want to smoke test the libreoffice SRU on armhf?
[20:17] <slangasek> (bug #919659)
[20:17] <ubot2> Launchpad bug 919659 in libreoffice "SRU LibreOffice 3.5.4 for precise (was: Can't open/save document or spreadsheet with password, when mozilla profile has an absolute path)" [High,Fix committed] https://launchpad.net/bugs/919659
[20:35]  * slangasek squints.  why am I getting a wrong (sbin-less) path in my schroots all of a sudden?
[20:37] <infinity> slangasek: bug #984390 ?
[20:37] <ubot2> Launchpad bug 984390 in shadow "$PATH is taken from login.defs not /etc/environment" [Medium,Triaged] https://launchpad.net/bugs/984390
[20:38] <slangasek> infinity: how is shadow at all involved in running of schroot?
[20:38] <infinity> slangasek: Does it not su to your user?
[20:38] <infinity> (Or some equivalent)
[20:38] <slangasek> infinity: this worked before the latest schroot upgrade
[20:39] <slangasek> so whatever it's doing, it's doing something new and argh
[20:39] <infinity> Oh.  Hrm.  See, I'd never noticed one way or the other.
[20:39] <infinity> slangasek: And, wait.  Which schroot upgrade?
[20:39] <slangasek> looks like schroot calls setuid directly
[20:39] <slangasek> infinity: the one on 29Jun
[20:40] <slangasek> I'm /assuming/ it's the schroot update that was to blame
[20:40] <infinity> slangasek: In quantal?  I'm running precise's schroot and have no sbin in my path when I schroot.
[20:40] <slangasek> really?
[20:40] <infinity> Really.
[20:40] <slangasek> I'm sure I always had it
[20:40] <slangasek> I would've noticed this long before now if I didn't
[20:40] <infinity> (base)adconrad@cthulhu:~$ echo $PATH
[20:40] <infinity> /home/adconrad/build/ubuntu-archive-tools:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[20:40] <infinity> (base)adconrad@cthulhu:~$ schroot
[20:40] <infinity> (quantal-amd64)adconrad@cthulhu:~$ echo $PATH
[20:40] <infinity> /home/adconrad/build/ubuntu-archive-tools:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
[20:40] <slangasek> yeah, and what's that lightdm junk in there, too :P
[20:41] <infinity> You may have been setting it explicitly in your .bashrc before?
[20:41] <slangasek> no
[20:41] <infinity> (Which is why my schroot PATH helpfully has ubuntu-archive-tools in it, but no sbin...)
[20:42] <Laney> still WFM
[20:42] <Laney> (quantal-amd64)root@raleigh:/srv/home/laney# echo $PATH
[20:42] <Laney> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
[20:42] <slangasek> I actually am appending a few things to my path in .bashrc, and that part's working; but the base path is wrong and wasn't before
[20:42] <slangasek> Laney: when doing schroot as non-root?
[20:42] <infinity> Laney: Non-root is the key.
[20:42] <Laney> oh, yes. Silly c-r.
[20:43] <Laney> Does NOT wfm!
[20:43] <infinity> Although, that X11-having path isn't the one from login.defs either.
[20:43] <infinity> Cause what we needed was this bug in a new flavour.
[20:44] <slangasek> oh, har
[20:44] <slangasek> X11, wtf
[20:45] <slangasek> which is not in *any* file under /etc, host or guest
[20:45] <infinity> slangasek: I think it might be a compiled-in default for pam_env.
[20:46] <slangasek> I'll hear no more of this calumny
[20:47] <infinity> I wonder if we could perhaps set PATH in a few more places, just to spice up our lives a bit.
[20:49] <slangasek> so this path is hard-coded in schroot
[20:50] <infinity> Hahaha.
[20:50] <infinity> Well, that's not new, then.
[20:50] <infinity> Since it's equally broken here.
[20:50] <slangasek> yeah, it's not
[20:51] <slangasek> but it only started becoming an issue for me
[20:51] <infinity> But why doesn't even "su - adconrad" from a root schroot session DTRT?
[20:51] <slangasek> so something else changed
[20:51] <infinity> I'd expect that to get the readenv=1 from pam.d/su
[20:51] <slangasek> er, but wait, it *is* new
[20:51] <infinity> Oh, no, that goes back to the shadow bug.
[20:51] <infinity> Derp.
[20:52] <slangasek> ah, no, just code moving around
[20:52] <slangasek> grr
[20:56] <infinity> slangasek: Erm, so I'm reading sbuild-auth.cc... Did someone really just reimplement su there, instead of just effin' calling the chroot's version?
[20:56] <slangasek> dunno
[20:56] <infinity> (which would still break for us, due to our bug, but at least it would be broken in one place and would, like, start a PAM sessions and stuff)
[20:56] <slangasek> schroot is also pamified
[20:56] <slangasek> but it doesn't call pam_env :P
[20:57] <infinity> Oh, the pam bits must be elsewhere, then.
[20:58] <infinity> Or, I'm looking at an sbuild-specific chunk.
[20:58] <infinity> Cause I'm half asleep.
[20:58] <infinity> No, cause that's where the path comes from.
[20:58] <slangasek> well, it's possible that it's willfully not calling pam for some reason
[20:58] <infinity> Why is half this source called "sbuild-"?
[20:58] <infinity> I don't want to play anymore.
[21:00] <cyphermox> infinity: like we discussed Friday; we'll start uploading evolution-data-server 3.5 to proposed; along with empathy, folks, gtkhtml, evolution and other things that could make things not install
[21:00] <infinity> cyphermox: Cheers, thanks for the heads-up.
[21:00] <infinity> cyphermox: Go forth and break proposed.
[21:00] <infinity> cyphermox: Have you got a thunderbird to go with it?
[21:01] <cyphermox> the only thing that will be missing will be thunderbird, which chrisccoulson said would maybe upload tomorrow
[21:01] <cyphermox> aye
[21:02] <cyphermox> evolution still doesn't work though :/
[21:02] <cyphermox> sorry, that was meant for #u-desktop ;)
[21:02] <infinity> slangasek: Are you sure the "pam support" isn't just for outside the chroot?
[21:03] <slangasek> infinity: no?
[21:03] <infinity> cyphermox: No one uses evolution anymore, I'll just remove it from the archive.
[21:04] <cyphermox> that would take a load off my shoulders ;)
[21:04] <slangasek> infinity: I'm not sure what distinction you're drawing.  schroot never runs in the chroot.
[21:05] <infinity> slangasek: Well, yes, I suspect that's the problem.  If it's just cleaning the environment up and then dumping you unceremoniously in a setuid()/chroot(), we never get to set up a PAM session *in* the chroot, which would seem ideal.
[21:05] <infinity> slangasek: (When I do chroots by hand, this is why I "chroot chroot/ su -")
[21:06] <slangasek> I don't agree that's ideal at all
[21:06] <infinity> slangasek: But the distinction I was making was that it probably uses PAM to auth that you're allowed to do the things you want to do, not to set up your session.
[21:06] <slangasek> I don't want it to be running pam modules from *inside* the chroot
[21:07] <infinity> slangasek: No?  I'd be curious as to why not.  I want my chroot session to be from the target dist, not some random mishmash of inner and outer madness.
[21:07] <infinity> slangasek: At least, in a "wipe the environment" mode, which is, I think schroot's default?
[21:08] <slangasek> because I don't want to have to *configure* things inside the chroot, that's busywork
[21:08] <infinity> They all kinda Just Work anyway, unless you have an odd setup.
[21:08] <infinity> But fair enough.
[21:08] <infinity> ("schroot -u root su - slangasek" should, for instance, do what you expect)
[21:08] <infinity> Or vorlon, whatever your local user is. :P
[21:09] <infinity> Where "what you expect" is "not have X11 in the path, but unfortunately pull the PATH from login.defs" :P
[21:10] <infinity> In my little world, that behaviour (not the shadow bug, but the "su -" behaviour) should be the default.  But I dunno.  Clearly, a contentious topic.
[21:11] <infinity> Pretty sure that's more or less how the old skool dchroot behaved, before people decided it needed rewriting to be 100 times more clever.
[21:12] <ScottK> Isn't it well established though that your world is a strange place?
[21:12] <ScottK> ;-)
[21:12] <slangasek> ok, I've downgraded now to precise schroot and get the same behavior, so grr
[21:12] <slangasek> I *know* this was working previously
[21:16] <slangasek> and it's a consistent behavior change in all my chroots, so it's something that's changed in the host, not the guest
[21:18] <infinity> slangasek: Well, my entire base system on this machine is precise, so it's either something that also changed in an SRU, or... You're going slowly insane. ;)
[21:38] <slangasek> infinity: confirmed, I'm going slowly insane
[22:22]  * slangasek checks to verify that mountall will autosync from unstable, whe
[22:22] <slangasek> +e
[22:42]  * slangasek eyes the MIR explosion
[22:42] <slangasek> (c-m, rather)
[23:57] <Daviey> slangasek: For a change, it would be nice if it wasn't the server team causing explosions
[23:57] <Daviey> but hey, better now, than week before release :)


[22:45] <Pricey> !path
[22:45] <Pricey> !-help
[22:45] <Pricey> !-path
[22:46] <Pricey> Wow there's really no help for path..
[22:46] <IdleOne> plz2provide factoid
[22:47] <IdleOne> !$path
[22:47] <IdleOne> nope
[22:47] <Pricey> !path is The $PATH variable tells the shell where to look for the commands you tell it to run. See https://help.ubuntu.com/community/EnvironmentVariables#File-location_related_variables
[22:53] <Unit193> That's not right.
[22:53] <Unit193> !path


[01:06] <mup> PR snapcraft#2406 closed: project_loader: add git to build-packages for version: git (#2403) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2406>
[04:43] <mup> PR core18#91 opened: Make /etc/default/swapfile be writable <Created by musicguitar> <https://github.com/snapcore/core18/pull/91>
[06:03] <mborzecki> morning
[06:35] <zyga> good morning
[06:36] <zyga> more red in tests
[06:36] <zyga> oh well
[06:36] <mborzecki> zyga: hey
[06:36] <zyga> :-)
[06:41] <mborzecki> zyga: looking into some opencl stuff from the forum, looks like none of the interfaces allows accessing /etc/OpenCL to read icd files, and then there's libnvidia-opencl which we do not pick up in s-c
[06:41] <zyga> oh man
[06:41] <zyga> another file to add
[06:41] <mborzecki> i'll rebuild my debugging snap with clinfo and see how far i get there
[06:41] <zyga> looking forward to removing that mess
[06:42] <zyga> good luck!
[06:42] <mborzecki> idk maybe we should have a 'compute' interace to cover cuda and opengl
[06:42] <zyga> opencl?
[06:42] <mborzecki> opencl right
[06:42] <mborzecki> too many open suffixes :P
[06:42] <mborzecki> prefixes
[06:42] <mborzecki> damn
[06:42] <zyga> open wtf :)
[06:42] <mborzecki> should get coffee
[06:42] <zyga> I'll take the dog out and focus on snap-update-ns and snapd feature flag for per user mouts
[06:43] <zyga> i have plenty of PRs that depend on each other
[06:43] <mborzecki> zyga: i'll have some questions about mount and MNT_DETACH that we do
[06:43] <zyga> need to add some leafs :)
[06:43] <zyga> yes?
[06:43] <zyga> shoot, I'll answer
[06:43] <mborzecki> zyga: we can do HO later
[06:43] <zyga> ok
[06:43] <zyga> mborzecki: can we aim for 9:00?
[06:43] <zyga> for the talk
[06:43] <mborzecki> sure
[06:44] <zyga> otherwise I'll be in my pijamas ;)
[06:59] <icey> where should I take a slightly comical snapcraft.io bug? doesn't hinder functionality but would probably be something we want to get fixed (we call French Guiana France in the map showing snap distribution)
[07:35] <mborzecki> hmm 'Download snap "core" (5940) from channel "edge" (received an unexpected http response code (503) when trying to download https://fastly.cdn.snapcraft.io/download-origin/fastly/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_5940.snap?token=1542276000_dc14a149f1c3974949f187187a7bfd71ceacfad9)'
[07:50] <mborzecki> snapcraft does not allow layouts?
[07:51] <mvo> mborzecki: I saw the fastly 503 error in spread, probably something for the store team to look at (cc sparkiegeek maybe?)
[07:52] <mvo> mborzecki: it looks like layout: was added to git Oct 10 in snapcraft but I doubt this is released yet
[07:52]  * mvo checks
[07:52] <mborzecki> mvo: found some info in https://forum.snapcraft.io/t/snap-layouts/7207
[07:52] <mvo> mborzecki: I wish we had the "published-into-channel" metadata already :)
[07:59] <zyga> It allows layouts since 3.x but you must also use a base
[08:04] <mborzecki> so mesa OpenCL implementation is listed by clinfo now
[08:06] <mborzecki> and no denials, that's probably because layouts opens up /etc/OpenCL/vendor
[08:07] <pstolowski> morning
[08:09] <mborzecki> pstolowski: hey
[08:09] <Chipaca> moin moin
[08:12] <mvo> hey Chipaca and pstolowski !
[08:13] <pedronis> morning (me is up since a bit for a meeting)
[08:15] <pedronis> zyga: mborzecki: hi, we should just close #6099 for now? right?
[08:15] <mup> PR #6099: cmd/snap-confine: always put the snap process under a device cgroup <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6099>
[08:15] <mborzecki> pedronis: yes, let me close it
[08:15] <pedronis> thx
[08:17] <mup> PR snapd#6099 closed: cmd/snap-confine: always put the snap process under a device cgroup <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6099>
[08:17] <pedronis> Chipaca: hi, you are already working on the sanity check for epochs?
[08:17] <pedronis> Chipaca: I reviewed the send epochs one
[08:19] <Chipaca> pedronis: I am
[08:19] <Chipaca> pedronis: saw the review, will circle back in a bit
[08:19] <Chipaca> got distracted by the forum
[08:20] <Chipaca> and reddit
[08:20] <Chipaca> https://www.reddit.com/r/Ubuntu/comments/9x0b5r/and_this_is_one_reason_why_i_dislike_snaps/
[08:20] <Chipaca> somebody asks why we don't use a private mount namespace to hide these
[08:20] <Chipaca> I dunno if that'd work, but if it did, and it made people happy, maybe we should
[08:20] <pedronis> Chipaca: what are these?  (me not sure I want to get lost in reddit right now)
[08:21] <Chipaca> pedronis: nah, not worth your time, nothing actionable for us beyond the mount namespace question
[08:21] <pedronis> Chipaca: could you convert the card for the sanity check to doing otherwise I'll do it
[08:21] <Chipaca> uh, isn't it there already
[08:21] <Chipaca> i thought i'd put it in doing yesterday during the meeting
[08:22] <Chipaca> ah no 'send epoch' is doing
[08:22] <Chipaca> done
[08:23] <mborzecki> zyga: i got opencl & mesa to work, but there's some trouble with opencl and nvidia, i can get the libraries in, but the icd file is /etc/OpenCL/vendor/nvidia.icd in the host filesystem
[08:23] <Chipaca> done moving it to doing
[08:23] <Chipaca> not done done
[08:23] <mborzecki> zyga: though tbh as a workaround a snap could generte the file itself and use layouts to put it under /etc/OpenCL/vendor
[08:24] <pedronis> Chipaca: thank you
[08:31] <pedronis> pstolowski: hi, thanks for the checklist, making some cards for hotplug
[08:31] <pstolowski> pedronis: sure; i think we're stumbling on each other's feet right now, something unexpected just happend ;)
[08:32] <pedronis> pstolowski: oops, sorry
[08:32] <pstolowski> np
[08:32] <zyga> re
[08:32] <zyga> now to work :)
[08:32] <pedronis> mborzecki: I added some info to the "snap connections" card, I will look at plan/review the PR when I have gone through some slightly higher prio stuff
[08:33] <mborzecki> pedronis: thanks
[08:33] <zyga> mborzecki:I like the idea of snapd generating config files for hardware and injecting them in /etc
[08:33] <pstolowski> pedronis: can you explain "Doing" lane in the rules.. card? i'm abit unclear on that one (vs upcoming)
[08:34] <Chipaca> pedronis: I'm not sure I understand your comment on 6142: isn't amend _already_ an "install"?
[08:34] <pedronis> pstolowski: Doing means you are working on it,  upcoming for things you are planning to do but not working on yet
[08:34] <pedronis> some things might go straight to doing
[08:35] <Chipaca> pedronis: uh, now I see it
[08:35] <Chipaca> will fix
[08:35] <pedronis> Chipaca: :)
[08:35] <mup> PR snapd#6151 closed: snapd: allow snap-update-ns to read /proc/version <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6151>
[08:35] <pstolowski> pedronis: ok, thanks
[08:35] <Chipaca> pedronis: so the amend check is wrong in store
[08:35] <Chipaca> and maybe the amend test is also wrong
[08:35] <Chipaca> hmm hmm
[08:35]  * Chipaca stashes the checking work
[08:35] <pedronis> Chipaca: store as in our store package?
[08:36] <pedronis> or store store?
[08:36] <pedronis> anyway I'm quite sure we want that change
[08:36] <pedronis> and the rest should follow
[08:36] <zyga> one small trello tip
[08:36] <zyga> you can use the menu on the right to filter cards
[08:36] <zyga> e.g. to show all the cards you are a member of
[08:36] <zyga> very useful IMO
[08:36] <pedronis> yup
[08:37] <Chipaca> pedronis: the amend test i added in the store package
[08:37] <Chipaca> pedronis: sends the snap id (d'oh)
[08:38] <pstolowski> pedronis: ok, i created a couple of cards and left some in the checklist for hotplug for the time being
[08:38] <pedronis> pstolowski: thanks
[08:40] <pedronis> pstolowski: it looks reasonable, I think it matches what PR you have up etc, but indeed doesn't make sense having too much in doing or also in upcoming
[08:41] <pedronis> Chipaca: I admit I didn't look super closely at tests in the first pass
[08:41] <pedronis> also because I'm sure we were missing some or something (because of amend)
[08:43] <mborzecki> heh rebuilt my snap with core18 clinfo stopped working :/
[08:44] <mborzecki> anyone on 18.04?
[08:46] <zyga> mmm, no, 18.10
[08:47] <mborzecki> zyga: can you install clinfo package and run it?
[08:47] <zyga> sure
[08:48] <zyga> mvo: https://github.com/snapcore/snapd/pull/6153/files#diff-0eac7194db86098b8f1b2084fb732ec4
[08:48] <mup> PR #6153: tests: use mock-gpio.py in enable-disable-units-gpio test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6153>
[08:49] <mvo> zyga: oh, looks like there is a leftover [Install] - thanks for spotting
[08:49] <zyga> mvo: I left a suggestion to apply
[08:49] <mvo> zyga: yeah, like it
[08:50] <mvo> zyga: https://github.com/snapcore/snapd/pull/6153/files#diff-0eac7194db86098b8f1b2084fb732ec4L5 is also wrong, I need to fix/revert this
[08:50] <mup> PR #6153: tests: use mock-gpio.py in enable-disable-units-gpio test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6153>
[08:50] <zyga> oh
[08:50] <zyga> I didn't notice
[08:50] <zyga> yeah
[08:51] <zyga> mborzecki: clinfo has one line of output
[08:51] <zyga> "Number of platforms"
[08:51] <zyga> what did you want from that?
[08:52] <mborzecki> hm so it must be one of the libs
[08:52] <zyga> 	linux-vdso.so.1 (0x00007ffda4f1c000)
[08:52] <zyga> 	libOpenCL.so.1 => /usr/lib/x86_64-linux-gnu/libOpenCL.so.1 (0x00007f45ae00e000)
[08:52] <zyga> 	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f45ae008000)
[08:52] <zyga> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f45ade1e000)
[08:52] <zyga> 	/lib64/ld-linux-x86-64.so.2 (0x00007f45ae453000)
[08:52] <zyga> ldd ^
[08:53] <mborzecki> zyga: i've installed beignet and pocl opencl implementations in the snap and opencl exits with an error from llvm now :/ probably one of the libs is doing something wrong or loading both of them breaks things
[08:54] <mvo> zyga: does lp 1786889 is something we fixed recently? I vaguely remember this error
[08:54] <zyga> mvo: yes
[08:54] <mvo> zyga: I will set to fix commited then
[08:54] <zyga> 4.18.0-041800-generi
[08:54] <zyga> this is a mainline kernel
[08:54] <mvo> oh
[08:54] <mvo> zyga: so this is just not supported?
[08:55] <zyga> not exactly, it should work with 2.36.x
[08:55] <zyga> we added some extra rules for that
[08:55] <zyga> same thing was affecting TW
[08:55] <mvo> zyga: ta
[08:57] <mborzecki> zyga: btw. generating vulkan icd file for nvidia looks tricky, there is an api version listed in the file, need to check if it's required, but from the looks of it the drivers declare different versions (eg. nvidia 1.1.82, intel 1.1.80)
[08:58] <zyga> it depends on how we generate  them
[08:58] <zyga> I think this is something we should take from a driver snap
[08:58] <mborzecki> sholud probably summarize the vulkan/opencl/glvnd craziness in a forum topic
[09:09] <mborzecki> mvo: have you tried to run core18 base snap apps with --strace ?
[09:12] <mvo> mborzecki: I don't know - does it fail?
[09:12] <mvo> mborzecki: never conciously tried it
[09:12] <mborzecki> mvo: it's getting stuck, can you try snap install test-snapd-tools-core18 and then snap run --strace test-snapd-tools-core18.echo foo ?
[09:13] <mborzecki> mvo: maybe we need to update th list of skipped syscalls
[09:13] <mvo> mborzecki: let me try that - I bet we need to blacklist one more systemcall :/
[09:14] <mup> PR snapd#6082 closed: overlord/ifacestate: set hotplug-key of the connection when connecting hotplug slots <Hotplug 🔌> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6082>
[09:17] <mup> PR snapd#6146 closed: ifacestate/helpers: added SystemSnapName mapper helper method <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6146>
[09:20] <mvo> mborzecki: fun, when I try to run tests-napd-tools.echo I get "unexpected wait status 0x8b"
[09:20] <mborzecki> mvo: adding -e !nanosleep unblocks it here
[09:21] <mvo> mborzecki: cool! will you do a PR or shall I?
[09:21] <pstolowski> Saviq: hey, it seems that installing/refreshing/removing multipass snap disconnect network for a short moment (or at least NM thinks it does); i suppose it's brige setup or something?
[09:21] <mborzecki> mvo: zyga pasted me a log from his run, and teher's no nanosleep there, i'm probably running a newer kernel so maybe something new was added to vdso
[09:21] <mborzecki> mvo: i'll open a PR
[09:21] <mvo> mborzecki: ok
[09:27] <Chipaca> mborzecki: pedronis: Thank you for your reviews of #6142! I believe I've addressed your concerns.
[09:27] <mup> PR #6142: overlord/snapstate, store: always send epochs <Created by chipaca> <https://github.com/snapcore/snapd/pull/6142>
[09:27] <Chipaca> let me know if I should pull out any of those commits into their own PR
[09:28] <Chipaca> at least Epoch.Unset would stand alone if needed (but it's pretty trivial)
[09:29]  * Chipaca -> more coffee
[09:32] <pedronis> Chipaca: Unset is like Revision.Unset right? anyway the PR doesn't seem that big even after the changes
[09:36] <mup> PR snapd#6155 opened: cmd/snap: add nanosleep to blacklisted syscalls when running with --strace <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6155>
[09:36] <mborzecki> mvo: ^^
[09:37] <mvo> mborzecki: ta
[09:42] <pedronis> zyga: is there a easy way to use layouts to turn a read-only directory from the base into a writable directory into which things can get added?
[09:43] <Chipaca> pedronis: yes, exactly like Revision.Unset semantically
[09:43] <Chipaca> internal is different because different
[09:43] <Chipaca> also we had two places already doing that check so it's really less code :-p
[09:43] <zyga> pedronis: yes
[09:43] <Chipaca> anyway. I'd said I was getting more coffee and didn't. I shall now.
[09:44] <zyga> That’s available since improved content interface
[09:44] <pedronis> zyga: do you need to actually add a file in the layout? or just need to specify the directory?
[09:47] <mvo> hrm, it looks like our strace is not compatible with libnss-systemd, when I have this is installed the straced apps will segfault. oh well
[09:51] <zyga> pedronis: a directory is sufficient
[09:51] <zyga> We support both file and directory layout items
[09:51] <pedronis> zyga: apparmor would still need to le us through right, though. I'm thinking something like /etc/foo
[09:52] <pedronis> where foo exist in the base
[09:52] <Saviq> pstolowski: yeah, if NM is dumb enough
[09:52] <zyga> Yes, though the layout code does that too
[09:52] <Saviq> pstolowski: I never noticed it though, care to file a bug please?
[09:53] <pstolowski> Saviq: sure. could as well be a Mate NM indicator thing
[09:57] <Saviq> yeah if it doesn't filter the interfaces
[09:58] <Chipaca> hmmm. ssh -nNT -L ~/.snap/${remote}.snapd:/run/snapd.socket $remote
[09:58] <Chipaca> hmm
[10:00] <niemeyer> Guten Morgen
[10:01] <sparkiegeek> moin moin
[10:08] <pedronis> niemeyer: hi
[10:09] <pedronis> Chipaca: niemeyer: given that you worked/discussed this initially I would be interested in your input on this:  https://bugs.launchpad.net/snapd/+bug/1803212
[10:09] <mup> Bug #1803212: snap restart starts disabled services <snapd:New> <https://launchpad.net/bugs/1803212>
[10:09] <ondra> zyga about avahi, stable is one to use. I made pull request to upstream, but it has not been accepted yet, that's why git commit in version
[10:09] <Chipaca> pedronis: I think we fixed this recently
[10:10] <pedronis> Chipaca: ?
[10:10] <pedronis> Chipaca: fixed which way?
[10:10] <Chipaca> ah sorry no
[10:10] <ondra> zyga and once 2.36 lands, I current beta will go to stable to align it with classic, so clients can works same way on core and classic
[10:10] <Chipaca> pedronis: we fixed the "snap refresh restarts disabled services" one :-)
[10:10] <Chipaca> so close
[10:10] <pedronis> heh
[10:10] <pedronis> anyway
[10:11] <pedronis> I can think about it, but input from original design sources could be useful
[10:12] <niemeyer> pedronis: The way we cooked the commands gives a hint about what's reasonable there.. we can start something without it being enabled:
[10:12] <niemeyer>       --enable       As well as starting the service now, arrange for it to be started on boot.
[10:13] <Chipaca> why is launchpad so horrible at whitespace
[10:13] <niemeyer> ... for so long
[10:13] <sparkiegeek> Chipaca: because HTML, and backwards compatibility is hard?
[10:13] <niemeyer> pedronis: So IMO restart should not touch disabled services either
[10:14] <Chipaca> sparkiegeek: I've never not been frustrated by its handling of whitespace, so at least it's consistent
[10:14] <niemeyer> sparkiegeek: Given how many systems get this right, I don't buy it
[10:15] <pedronis> niemeyer: start should do though?
[10:15] <niemeyer> pedronis: If you specifically name it, yes
[10:15]  * Chipaca changes a <div> to a <pre> and is happier
[10:15] <niemeyer> pedronis: Sorry, let's explore this better:
[10:15] <pedronis> niemeyer: no, we are talking about <snap> here
[10:15] <pedronis> not single services
[10:16] <niemeyer> pedronis: If a service is running, it seems reasonable for it to be restarted
[10:16] <niemeyer> pedronis: No matter hwat
[10:16] <pedronis> I think the issue is what makes sense for restart <snap> vs overall consistency
[10:16] <niemeyer> pedronis: Same is true for stop
[10:16] <pedronis> niemeyer: what if something is not enabled but running, and one uses stop <snap>
[10:17] <niemeyer> pedronis: There's only one option that sounds sane from a user perspective, right?
[10:17] <pedronis> stopping it
[10:17] <niemeyer> Yep
[10:17] <pedronis> so we are left with snap start <snap>
[10:18] <niemeyer> That's the slightly tricky one, as there are two potentially valid expectations
[10:18] <pedronis> yes
[10:18] <pedronis> start everything (mimic stop), start only enabled
[10:18] <pedronis> (more like restart)
[10:19] <niemeyer> Yeah, except restart clearly makes some sense even for disabled services,  as long as they are running
[10:20] <pedronis> yes
[10:20] <pedronis> so stop stops everything running
[10:20] <pedronis> restart, restart everything running
[10:20] <pedronis> but start is trickier
[10:21] <niemeyer> I think there's way to define it
[10:21] <pedronis> notice also that the user asked for different behavior that these
[10:21] <niemeyer> There's one option which is more reasonable when running "snap stop" + "snap start"
[10:22] <niemeyer> Which is a pretty reasonable pair
[10:23] <niemeyer> I think we should make "snap start <snap>" only act on enabled services, and error out if all services are disabled
[10:23] <pedronis> ok
[10:23] <niemeyer> This way "snap stop <snap>" followed by "snap start <snap>" will tend to do the right thing
[10:24] <niemeyer> But "snap start <snap>.<app>" should work always, since it's a more clear request
[10:24] <pedronis> I can write something there, I also need to ask again if the user really meant what he wrote about restart disabled running doing nothing
[10:24] <pedronis> yes
[10:24] <niemeyer> snapctl should match
[10:24] <niemeyer> Otherwise it's error prone
[10:24] <pedronis> yea
[10:25] <Chipaca> should we add flags for the complimentary option?
[10:25] <Chipaca> ie snap start --all
[10:25] <Chipaca> or sth
[10:25] <Chipaca> snap restart --only-the-odd-numbered-ones
[10:25] <Chipaca> :)
[10:25] <Chipaca> complementary*
[10:25] <pedronis> Chipaca: snap start --enable <snap>  will imply all I think
[10:26] <pedronis> not sure it's enough
[10:26] <niemeyer> pedronis: What the user is asking for has little bearing unless the argument comes with rationale similar to the discussion we had above
[10:26] <pedronis> niemeyer: sorry, I'm not saying we should do what he says, but I just want to dig into the bit where il would diverge
[10:26] <niemeyer> pedronis: For example, the very first case suggested in the bug is already breaking reasonable expectations
[10:27] <niemeyer> pedronis: With a running service, having "snap restart <snap>" doing nothing is super awkward
[10:27] <niemeyer> pedronis: Yeah, makes sense
[10:30] <pedronis> Chipaca: given you worked on this how complicated would be restart only running ones?
[10:31] <mvo> mborzecki: when you have a moment I would love to talk about LP: #1791182 - I started a PR but your input would be great as this is something that happend with parallel installs changes
[10:31] <mup> Bug #1791182: Okular launcher present in Apps menu after removing Okular snap app <apps> <launcher> <menu> <okular> <snap> <snapd:In Progress> <https://launchpad.net/bugs/1791182>
[10:31] <Chipaca> pedronis: not too hard
[10:31] <Chipaca> pedronis: TOCTOU prone though
[10:32] <pedronis> Chipaca: mmh, there's try-restart (oddly named)
[10:33] <pedronis> which seems to do that
[10:35] <Chipaca> pedronis: and try-reload-or-restart
[10:35] <Chipaca> pedronis: this could work, for restart
[10:35] <Chipaca> if that's what's wanted :)
[10:36] <pedronis> Chipaca: just exploring
[10:37] <pedronis> no immediate action
[10:37] <pedronis> I need to answer/write a bit more in the bug
[10:37] <niemeyer> Chipaca: Yeah, given the name, try-reload-or-restart sounds like the right thing
[10:37] <niemeyer> Chipaca: It's the kind of command that likely made an appearance when people realized the default behavior was not the best one
[10:37] <mup> PR snapd#6156 opened: [RFC] wrappers: remove all desktop files from a snap on removal <Created by mvo5> <https://github.com/snapcore/snapd/pull/6156>
[10:38] <niemeyer> But it was too late to change get the default
[10:38] <Chipaca> to be clear: we'd do try-restart or try-reload-or-restart depending on whether --reload was given
[10:39] <Chipaca> on the other hand
[10:39] <Chipaca> if a service failed
[10:39] <Chipaca> 'snap restart' will stop starting it up again
[10:39] <pedronis> mmh
[10:42] <mvo> zyga: you mentioned you worked on a followup test in 6128 - is that in progress or shall I have a look at this?
[10:42] <mup> PR snapd#6127 closed: overlord/ifacestate: setup systemd backend in separate pass <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6127>
[10:42] <mup> PR snapd#6128 closed: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6128>
[10:43] <zyga> mvo: I'm working on that
[10:43] <zyga> mvo: just talking to maciej on HO now
[10:43] <mvo> zyga: cool
[10:46] <pedronis> Chipaca: restart if running, or enabled but failed doesn't roll on the tongue
[10:51] <Chipaca> so it'd be try- only if not specifying services (ie if specifying snaps)
[10:52] <Chipaca> i guess that's reasonable. We'd have to announce the behaviour change.
[10:52] <pedronis> yes
[10:56] <mup> PR snapd#6143 closed: cmd: install snap-discard-ns in "make hack" <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6143>
[10:57] <Chipaca> pedronis: https://pastebin.ubuntu.com/p/tcgQXFcvmC/ <- is this something we'd want?
[10:57] <Chipaca> pedronis: or should we consider adding a column?
[10:57] <pedronis> Chipaca: I would put it only in info for now
[10:57] <Chipaca> (adding a column sounds perilous)
[10:58] <Chipaca> pedronis: I'd thought maybe add it in notes if != "0"
[10:58] <pedronis> it can get complicated/long
[10:58] <Chipaca> yes
[10:58] <Chipaca> almost arbitrarily long
[10:59] <pedronis> yea
[10:59] <pedronis> epochs should be fairly transparent to the user in the normal case
[10:59] <pedronis> unless one is debugging or it's a db snap or something
[10:59] <pedronis> but then info seems ok
[11:01] <pedronis> Chipaca: I mean we might end up doing something in list but I wouldn't start there before we have snaps using this around
[11:01] <pedronis> to think about
[11:02] <pedronis> showing the whole epoch doesn't seem an option there
[11:02] <Chipaca> ok
[11:02] <Chipaca> FWIW the max epoch currently would have len 240
[11:03] <pedronis> Chipaca: you are not making your case, if you are making one to put it there :)
[11:03] <Chipaca> pedronis: no i'm explaining that I understand the problems
[11:03] <pedronis> ok
[11:03] <Chipaca> pedronis: today epoch isn't seen by the client at all, fwiw
[11:04] <pedronis> a saving grace actually
[11:04] <pedronis> so far
[11:05] <pedronis> I know
[11:05] <pedronis> if we want to show in info we need to change that
[11:08] <Chipaca> :)
[11:09] <pstolowski> pedronis: described autoconnect difficulties https://forum.snapcraft.io/t/hotplug-autoconnect/8526 ; i only mentioned 3 interfaces as i'm not sure what else that we currently have makes sense for hotplug
[11:11] <pedronis> pstolowski: thanks
[11:12] <pedronis> pstolowski: I'll do a pass myself over the interface types and see if I find others relevant to this
[11:14] <mup> PR snapd#6157 opened: userd: force zenity width if the text displayed is long <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6157>
[11:15] <clobrano> Hi all :), could anybody tell me whether the "version-script" stage is still supported (even if deprecated)? I'm having a weird Yaru build failure on Travis
[11:16] <mup> PR snapcraft#2402 closed: packaging: update requests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2402>
[11:23] <clobrano> ^ here is the log https://travis-ci.org/ubuntu/yaru/builds/454222505
[11:27] <cachio> zyga, hey
[11:27] <zyga> hi
[11:27] <cachio> after the images for bionic and cosmic were updated
[11:28] <cachio> systemd was upgraded
[11:28] <cachio> and now we can see the mount issue on those systems too
[11:28] <cachio> :(
[11:29] <cachio> zyga, most of the red builds are because of that issue
[11:29] <zyga> oh fun
[11:29] <zyga> I will be busy today
[11:29] <zyga> thanks for letting me know
[11:29] <mborzecki> yay
[11:29] <zyga> I will prioritise this
[11:29] <mborzecki> now we'll have to fix it :)
[11:30] <mvo> degville: hi, I subscribed you to bug lp 1745037 - hope you don't mind, looks like a relatively straightforward docs fix
[11:30] <cachio> mborzecki, sadly yes
[11:30] <cachio> :)
[11:33] <pstolowski> pedronis: in theory we could maybe have hotplug for e.g. removable media, but i'm not sure if it makes sense in practice
[11:34] <mup> PR snapd#6069 closed: ifacestate/hotplug: removeDevice helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6069>
[11:38] <Chipaca> mvo: cachio: do any of our test-snapd- snaps have branches ?
[11:39] <cachio> cachio, no
[11:39] <cachio> at least mine
[11:39] <cachio> Chipaca,
[11:39] <Chipaca> cachio: ta
[11:39] <Chipaca> cachio: is test-snapd-tools one of yours?
[11:39] <cachio> Chipaca, no
[11:39] <Chipaca> cachio: ok
[11:40] <degville> mvo: thanks - I'll take a look!
[11:40] <mup> PR snapcraft#2404 closed: cli: handle yaml errors for cleanbuild <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2404>
[11:40] <mvo> 5845 is green! a second review would be great (maybe from jdstrand  ?)
[11:41] <mvo> Chipaca: they are all(?) owned by the canonical account and shared
[11:41] <mvo> Chipaca: aren't branches not long lived? or is that controlled easily server side?
[11:42] <zyga> fun
[11:42] <Chipaca> um
[11:42] <zyga> two bugs
[11:42] <Chipaca> mvo: i meant tracks
[11:42] <zyga> well, two *new* bugs
[11:42] <Chipaca> cachio: sorry i meant tracks :-)
[11:42] <zyga> one in snap-confine and one in snap-update-ns
[11:44] <mvo> Chipaca: not afaik - lets create one for test-snapd-tools?
[11:45] <Chipaca> mvo: +1
[11:45] <Chipaca> mvo: i'm wanting to have something to test epochs from the store with
[11:45] <Chipaca> easiest, other than having a  snap just for that, is adding a track
[11:45] <Chipaca> otherwise I could just make a test-snapd-epoch snap
[11:46]  * mvo nods
[11:46] <Chipaca> mvo: which would you rather?
[11:52] <zyga> mborzecki: fixed
[11:52] <zyga> mborzecki: the 2nd bug
[11:52] <zyga> the 1st bug will be next shortly
[11:52] <mborzecki> zyga: ok, ping me for reviews, i'm keen to try it out on centos
[11:53] <sergiusens> icey: you might want to report an issue for the webteam
[11:58] <mvo> Chipaca: ups, missed the quesiton - either way is fine, sorry. maybe test-snapd-epoch is simpler as we don't need to ask the store for creating of a track
[12:04] <mvo> cachio: hey, so I would like to write a spread test for {personal,system}-files it needs a snap declaration to connect the interface, do we have test for similar interfaces already that I could use as a blueprint?
[12:06] <zyga> mborzecki: spread test in flight
[12:12] <mborzecki> are interface hooks supported by snapcraft?
[12:14] <Chipaca> mvo: can you register test-snapd-epoch and invite me to collaborate on it?
[12:14] <Chipaca> mvo: (in the Canonical account i mean)
[12:14] <mvo> Chipaca: sure
[12:14] <Chipaca> mvo: if you need to push a revision to collaborate, rename tests/lib/snaps/basic :-)
[12:14] <Chipaca> I don't intend it to do anything (for now at least)
[12:15] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6158
[12:15] <zyga> 2nd bug
[12:15] <zyga> now looking at 1st
[12:15] <mup> PR #6158: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <https://github.com/snapcore/snapd/pull/6158>
[12:15] <mup> PR snapd#6158 opened: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <https://github.com/snapcore/snapd/pull/6158>
[12:16] <cachio> mvo, and what does it do?
[12:16] <cachio> sh?
[12:16] <mvo> Chipaca: you should have mail
[12:16] <mvo> cachio: it allows access to files outside of the regular confinmement
[12:16] <mvo> cachio: e.g. $HOME/.my-folder
[12:17] <cachio> ok, so you can use the sh snap
[12:17] <cachio> one sec
[12:17] <cachio> mvo, test-snapd-sh
[12:18] <cachio> just add the app there
[12:18] <cachio> with the plug you want
[12:18] <cachio> and that's it
[12:19] <cachio> mvo, in the test then you can do test-snapd-sh.<your-app> "ls <path>"
[12:19] <cachio> i.e. test-snapd-sh.with-broadcom-asic-control-plug -c "cat /dev/$device"
[12:20] <cachio> mvo, does it work for you?
[12:23] <mvo> cachio: I will look into it some more after lunch, thanks
[12:23] <cachio> mvo, ok, I can create the test if you want
[12:23] <cachio> mvo, so you can take other stuff
[12:24] <cachio> I created many similar tests before
[12:25] <zyga> mvo: can you please review https://github.com/snapcore/snapd/pull/6123
[12:25] <mup> PR #6123: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <https://github.com/snapcore/snapd/pull/6123>
[12:25] <zyga> -4029
[12:25] <zyga> -402 +8 changes
[12:26] <Chipaca> mvo: thanks
[12:26] <mvo> cachio: that would be great, I'm not sure though if "deny-connection: true" will make things more complicated for the test
[12:26] <mvo> cachio: but either way, help with the spread test would be great
[12:26] <mvo> zyga: gladly
[12:27] <mvo> zyga: whats not to like about this amount of "-"
[12:30] <cachio> mvo, nice, I'll start with it today
[12:30] <cachio> mvo, "deny-connection: true" shouldn't be a problem
[12:51] <zyga> if anyone has review time, this is the only feature PR to review from my stuff: https://github.com/snapcore/snapd/pull/6145
[12:51] <zyga> +87 -10 so not terrible
[12:51] <zyga> mostly just tests
[12:51] <mup> PR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
[12:51] <zyga> actually not mostly just tests
[12:51] <zyga> but not much anyway :)
[13:10] <mborzecki> off to pick up the kids
[13:34] <pstolowski> Chipaca: i'd be happy to approve #6107 when you add the missing test case, then it could land
[13:34] <mup> PR #6107: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107>
[13:37] <pedronis> pstolowski: I was a bit surprised that it really did show the column, not even name
[13:37] <pedronis> I mean 6107
[13:40] <pedronis> also the prereq doesn't have two reviews
[13:40] <pedronis> Chipaca: I left a note in #6107, we should talk a sec on it
[13:40] <mup> PR #6107: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107>
[13:41] <mborzecki> re
[13:42] <zyga> mborzecki: first bug also fixed, spread test took longer to write
[13:42] <zyga> but I'm happy with the outcome
[13:42] <mborzecki> pstolowski: question about interface hooks, is the hooks executed under the security profile that comes from the interface?
[13:42] <zyga> much better than the original unit test
[13:42] <zyga> fired it up now, should be ready by standup
[13:42] <mborzecki> zyga: thanks for the fixes :)
[13:42] <zyga> thank you for finding bugs :)
[13:43] <mborzecki> heh
[13:43] <pstolowski> mborzecki: depends, prepare-slot-*, prepare-plug-* - are not. connect-plug-*, connect-slot-* yes
[13:43] <pstolowski> pedronis: hmm, i see what you mean
[13:44] <mborzecki> pstolowski: i'm using connect-plug-opengl, hm maybe i need to look into that further
[13:47] <pstolowski> mborzecki: let me know the details if you obseve anything suspicious. you might be the first one to make use of interface hooks..
[13:48] <mborzecki> pstolowski: i don't need to declare plugs for interface hooks, do I? i mean it's it's a connect-plug-opengl hook then it runs with opengl plug implicitly, doesn't it?
[13:53] <zyga> mborzecki: interesting but doubtful
[13:53] <zyga> mborzecki: the hooks have the snap-level interfaces only
[13:53] <sergiusens> zyga: I am getting this cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied when I try to run a snap try inside lxd
[13:53] <zyga> anything scoped will *not* affect hooks
[13:53] <zyga> sergiusens: what's the kernel version and snapd version?
[13:54] <zyga> sergiusens: please report a bug, I will investigate
[13:54] <pedronis> mborzecki: there is no code to make that implicit afaik, so either global plug, or the hook needs to list the plug
[13:54] <zyga> sergiusens: (we're now using bugs for ... bugs) :-)
[13:54] <sergiusens> https://www.irccloud.com/pastebin/SoCmFTkp/
[13:54] <sergiusens> zyga: I do not believe you!
[13:55] <sergiusens> I have been conned into reporting bugs before ;-)
[13:55] <zyga> sergiusens: thank you, the host is ~~~ 18.04 or newer, I presume?
[13:55] <zyga> sergiusens: and the host is xenial container, right?
[13:55] <sergiusens> yes, xenial
[13:55] <sergiusens> also, the snap uses bases
[13:55] <mborzecki> pedronis: yup, adding plug explicitly made it work
[13:56] <zyga> sergiusens: please report it, I'll check it out after writing tests for another fix
[13:59] <pstolowski> zyga: one question re 6145, otherwise +1
[13:59] <zyga> looking
[14:01] <zyga> pstolowski: replied
[14:01] <zyga> thank you for the review, this PR is the most important to move other mount stuff forward
[14:02] <pedronis> Chipaca: standup ?
[14:02] <pedronis> zyga: ^
[14:02] <zyga> oh, joining
[14:03] <sergiusens> zyga: got it to work by installing core...
[14:03] <zyga> sergiusens: interesting
[14:05] <mup> PR snapd#6159 opened: cmd/snap-confine: handle mounted shared /run/snapd/ns <Created by zyga> <https://github.com/snapcore/snapd/pull/6159>
[14:14] <om26er> popey: ping
[14:14] <popey> PONG!
[14:15] <zyga> echo echo echo
[14:15] <om26er> popey: the asciinema upstream wants to update its snap to latest version but the snap was uploaded by MarkS, so wanted to know what's the procedure to get that snap uploaded from their official account ?
[14:16] <om26er> https://github.com/asciinema/asciinema/issues/296#issuecomment-438025083
[14:16] <popey> Wimpress is about to be in the same physical location as sabdfl, maybe he could mention it :)
[14:17] <om26er> so basically they are willing to move the packaging under their github org and I am committing to maintenance there.
[14:17] <popey> (I think transferring the snap upstream is the best course of action)
[14:17] <om26er> yep
[14:18] <popey> i have let wimpy know, he's on a plane right now, but I'm sure he'll pass the message on when he gets there :)
[14:18] <popey> thanks for letting us know om26er
[14:18] <om26er> popey: sounds good to me, cheers!
[14:22] <mup> PR snapd#6160 opened: nvidia, interfaces/builtin: OpenCL fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6160>
[14:57]  * cachio lunch
[14:58] <Wimpress> At the airport. I'll mention to Mark.
[15:08] <zyga> quick break
[15:17]  * pedronis mostly eods (will be back for some meeting later)
[15:20] <mvo> mborzecki: heh, I was about to ask about 6160 and if we should pull it into 2.36 and then you added the milestone. thanks for this!
[15:21] <mup> PR snapd#6160 closed: nvidia, interfaces/builtin: OpenCL fixes <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6160>
[15:21] <mvo> mborzecki: could you please create a pr based on 2.36 for this? I tried to cherry-pick but the second commit does not apply cleanly
[15:22] <mborzecki> mvo: sure
[15:22] <mvo> ta
[15:24] <mborzecki> mvo: i think we shoud also pick https://github.com/snapcore/snapd/pull/5696
[15:24] <mup> PR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5696>
[15:24] <mvo> mborzecki: ok, let me see if I can cherry pick this
[15:25] <mborzecki> also that's what 6160 is conflicting with
[15:25] <mvo> mborzecki: done, this is in 2.36 now
[15:25] <mborzecki> mvo: ta
[15:26] <mborzecki> mvo: 6160 will now apply cleanly on top of 2.36, do you want to me open a PR?
[15:27] <mvo> mborzecki: no, thats fine then
[15:27] <mborzecki> ok
[15:28] <mvo> mborzecki: done, thanks again
[15:28] <mborzecki> np
[15:57] <zyga> re
[15:57] <zyga> taht was a longer quick break but I did handle both lunch and the dog :)
[15:57] <sparkiegeek> ate the dog and fed the lunch?
[15:58] <zyga> unfortunately no hot-dogs :)
[15:59]  * zyga sighs seeing a test fail on 14.04
[15:59] <zyga> "fun"
[15:59] <zyga> they said crying ;)
[15:59] <zyga> let's see
[16:01] <pstolowski> zyga: #6158 can land?
[16:01] <mup> PR #6158: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <https://github.com/snapcore/snapd/pull/6158>
[16:01] <zyga> pstolowski: yes, please
[16:01] <mup> PR snapd#6158 closed: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6158>
[16:02] <zyga> mvo: can we have milestones on launchpad?
[16:03] <zyga> now that we have bugs we could do that too :)
[16:03] <mvo> zyga: yeah
[16:03]  * zyga could use a 2nd review on https://github.com/snapcore/snapd/pull/6145
[16:03] <mborzecki> zyga: 6158 for 2.36 too?
[16:03] <zyga> mvo: I looked but I cannot add any
[16:03] <mup> PR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
[16:03] <zyga> mborzecki: so that's a good question, I can make a backport if mvo agrees
[16:04] <zyga> it's fairly simple and significant
[16:04] <mvo> zyga: I created one, how do you want to use it?
[16:04] <zyga> one sec
[16:04] <mvo> zyga: backport for what? sorry, miss context
[16:04] <zyga> mvo: sorry, two topics
[16:05] <zyga> mvo: one topic: the milestone, on lauchpad, I'd love to be able to set milestone for this bug: https://bugs.launchpad.net/snapd/+bug/1803535
[16:05] <mup> Bug #1803535: Certain layouts cannot be constructed correctly <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1803535>
[16:05] <mvo> zyga: added the milestone, go wild
[16:05] <zyga> mvo: topic two, shall I create a backport for this issue and propose it for 2.36 release branch?
[16:05] <zyga> mvo: I don't have the permission
[16:05] <mvo> zyga: yes please, also no need for a backport if it can be cherry-picked cleanly
[16:05] <zyga> mvo: so shall I just push into the release branch?
[16:05] <mvo> zyga: I created the milestone in LP now, do you need more?
[16:05] <zyga> it should be clean
[16:06] <mvo> zyga: yeah, if its clean cherry picks thats fine
[16:06] <zyga> mvo: yes, I cannot assign the milestone to the bug
[16:06] <zyga> not sure which LP permission governs that
[16:06] <mvo> zyga: I targed it to the series
[16:07] <mvo> zyga: but you should also be able to do that
[16:07] <zyga> milestone column was empty for me
[16:07] <zyga> thanks for doing that
[16:07] <zyga> I see "target to series"
[16:07] <zyga> and I can target it for "trunk"
[16:09] <mvo> zyga: that is confusing, let me check
[16:09] <zyga> mvo: cherry picked and pushed to the 2.36 release branch
[16:09] <zyga> mvo: I TG a screenshot of what I see
[16:10] <mborzecki> zyga: findmnt in ubuntu 14.04 cannot do --output=PROPAGATION
[16:14] <zyga> mborzecki: yeah, I just installed it to play
[16:14] <zyga> blast from the past :)
[16:14] <zyga> unity
[16:15] <zyga> mborzecki: there's RHEL 8 beta!
[16:16] <mborzecki> zyga: heh, which kernel version? 3.17? :)
[16:16] <zyga> hold on :)
[16:19] <zyga> mborzecki: downloading, I will let you know
[16:20] <mborzecki> zyga: hm don't see it on developers.redhat.com
[16:21] <zyga> you need to opt into the beta
[16:21] <zyga> hold on
[16:21] <mborzecki> aah there it is
[16:21] <zyga> https://access.redhat.com/products/red-hat-enterprise-linux/beta?extIdCarryOver=true&sc_cid=70160000000dJVaAAM
[16:22] <zyga> mborzecki: boot iso or binary dvd?
[16:22] <zyga> I'll get both
[16:22] <zyga> but weird...
[16:23] <mborzecki> zyga: signed up just now
[16:23] <thresh> at least 4 something cause it says bbr everywhere
[16:24] <thresh> you need binary
[16:24] <thresh> at least thats what they say in the mail
[16:25] <mborzecki> zyga: hm ppc64le, aarch64 :)
[16:25] <zyga> mborzecki: and there's a new raspberry pi!
[16:25] <zyga> Pi 3 A+
[16:25] <zyga> no eth, just wifi
[16:25] <zyga> 119PLN
[16:25] <mborzecki> no emmc?
[16:25] <ogra> yeah ... as poorly designed as the b+
[16:25] <zyga> 512MB ram
[16:25] <zyga> WTF
[16:25] <ogra> (high speed networking on a USB2 hub)
[16:26] <zyga> no emmc
[16:26] <ogra> indeed
[16:26] <zyga> I'll pass
[16:26] <ogra> only the cm3 has MMC
[16:26] <mborzecki> so still nothing more than a curiosity ;)
[16:26] <ogra> yeah
[16:27] <mborzecki> wish i could do something useful with my CHIP though
[16:27] <ogra> port core to it !
[16:27] <mborzecki> iirc there was a gadget for it
[16:28] <zyga> what's the HW inside the chip?
[16:28] <ogra> there is a chip inside the chip ;)
[16:29] <zyga> yes :D
[16:29] <mborzecki> zyga: https://en.wikipedia.org/wiki/CHIP_(computer)
[16:29] <mborzecki> the company went belly up :)
[16:30] <zyga> making products for $9 tends to make that happen
[16:31] <zyga> I think I know how to use findmnt and not cry a river over 14.04
[16:31]  * zyga tweaks
[16:34] <ogra> well, marketing it for $9 and producing it for $30 or so ...
[16:34] <ogra> wasnt the cleverest strategy :)
[16:35] <mup> PR snapcraft#2409 opened: python plugin: process deps before and separately from setup.py <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2409>
[16:43]  * zyga -> school
[17:02] <zyga> ok, fixed 14.04 tests (hopefully)
[17:08] <mup> PR snapd#6155 closed: cmd/snap: add nanosleep to blacklisted syscalls when running with --strace <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6155>
[17:10] <cachio> mvo, sorry, is it .dot files interface already merged?
[17:12] <mvo> cachio: it is still in review, one sec, let me find the pr number
[17:13] <mvo> cachio: 5845
[17:13] <cachio> mvo, I just discovered that
[17:13] <cachio> thanks
[17:14] <mvo> yw
[17:14] <mvo> thanks for looking into it
[17:15] <cachio> I could add the test to that PR, or create a new branch, what do you prefrer?
[17:16] <mup> PR snapd#6123 closed: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6123>
[17:25] <zyga> mvo: I didn't notice https://github.com/snapcore/snapd/pull/6128 is merged!
[17:25] <mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6128>
[17:25] <zyga> I'll push tests to a follow-up
[17:25] <zyga> can we get an edge build
[17:25] <zyga> and let the customer know
[17:34] <zyga> anyone for a 2nd review of https://github.com/snapcore/snapd/pull/6145 ?
[17:34] <mup> PR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
[17:42]  * zyga considers wrapping up
[17:43] <zyga> mvo: do you think you could look at https://github.com/snapcore/snapd/pull/6111 tomorrow, nothing binding, just tell me what you think
[17:43] <mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
[17:43] <zyga> mainly at the makefile path
[17:43] <zyga> as spec file is probably not terribly interesting
[19:09] <popey> Is there some env var I need to set for classic snaps to 'find' GL drivers? Where do I point it?
[19:09] <popey> (not using desktop helpers)
[20:02] <mup> PR snapd#6161 opened: tests: new test suite to run snapd tests on a google remote instance <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6161>
[20:22] <zyga> popey: dunno
[20:22]  * zyga came to check on PRs
[21:48] <mup> PR snapd#6162 opened: interfaces/greengrass_support: update accesses for GGC 1.6 <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6162>


[18:55] <wam> Hi, I'm trying out mir/unity8 on a convertible. Looks good so far, but I have an inverted x-axis on the touchscreen and would like 1.5 pixels per pixel due to hidpi. I'm unable to find anything on google about mir and such things. Any hints would be welcome!