[05:59] <didrocks> good morning
[07:05] <seb128> good morning desktopers
[07:07] <hikiko> hello...
[07:07] <hikiko> I just woke up :/ My mobile ran out of battery :/
[07:07] <hikiko> +no alarm today :)
[07:08] <RAOF> A fine morning, then! :)
[07:08] <RAOF> BAH! Who broke the compose key!
[07:08] <hikiko> hahaha
[07:08] <RAOF> Also, why is it suddenly 6pm.
[07:08]  * RAOF -> EOD.
[07:09] <hikiko> :DDD
[07:09] <hikiko> enjoy your rest of the day RAOF :)
[07:09] <didrocks> good morning hikiko, evening RAOF :)
[07:10] <seb128> RAOF, enjoy!
[07:13] <hikiko> good morning didrocks seb128 :)
[07:13] <pitti> Good morning
[07:16] <hikiko> good morning pitti :)
[07:18] <seb128> lut pitti
[07:18] <seb128> ça va bien ?
[07:18] <pitti> hey hikiko!
[07:18] <pitti> ça va seb128 -- oh, tu es plus tôt que moi :)
[07:18] <seb128> \o/
[07:18] <seb128> pitti, tu as bien dormi ?
[07:18] <pitti> seb128: je vais bien, jeu au basket hier était grand
[07:19] <seb128> "grand"?
[07:19] <pitti> seb128: "bon", Je suppose
[07:20] <seb128> c'est mieux oui
[07:20]  * pitti keeps being misled by "great" vs. "grand"
[07:20] <didrocks> hey pitti!
[07:20] <pitti> bonjour didrocks !
[07:20] <seb128> "grand" is "tall" usually
[07:21] <pitti> seb128: mais beaucoup de personnes là sont grand aussi :)
[07:21] <seb128> google translator seems a bit confused as well and suggest "great" as first translation for "grand"
[07:21] <seb128> pitti, c'est vrai !
[08:32] <darkxst> hey seb128 pitti didrocks
[08:37] <pitti> hey darkxst
[08:38] <didrocks> good evening darkxst
[08:39] <darkxst> anyone care if I drop obexftp from gnome-user-share? so far as I can tell its useless with bluez5 anyway
[08:39] <darkxst> gvfs dropped it ages ago
[08:40] <darkxst> I doubt it even works and there are no supported clients
[08:40] <darkxst> seb128, ^
[08:41] <seb128> hey darkxst
[08:41] <seb128> darkxst, I don't know enough about it to comment, what's the motivation for the change?
[08:43] <darkxst> seb128, merge gnome-user-share to 3.14, but keep the prefs panel
[08:43] <seb128> seems fine to me
[08:44] <darkxst> it has the binary split, and there are lots of bluetooth fixes in there, that mostly only affect you guys
[08:45] <darkxst> and even including apache 2.4 support ;) though could have just cherry-picked that
[08:46] <seb128> updating is better, if we can
[08:48] <darkxst> seb128, yes that was my thoughts also
[08:50] <darkxst> patches are done, I'll do a merge with debian over the weekend
[08:50] <seb128> great
[08:52] <willcooke> morning all
[08:52] <TheMuso> Hey willcooke.
[08:52] <darkxst> hey willcooke
[08:52] <seb128> hey willcooke TheMuso
[08:52] <TheMuso> Hey desktoppers.
[08:55] <didrocks> hey willcooke, TheMuso
[09:03] <Laney> ahoy
[09:04] <seb128> hey Laney!
[09:04] <seb128> how are you?
[09:05] <pitti> hey Laney!
[09:06] <Laney> hey seb128 and pitti
[09:06] <Laney> doing good, my fingers are feeling the burn from climbing yesterday \m/
[09:06] <Laney> how about you?
[09:07] <didrocks> morning Laney!
[09:07] <pitti> Laney: doing good as well, my body is aching (in a good way) from the 2.5 h basketball
[09:07] <didrocks> ah, you feel better enough for climbing? Nice!
[09:08] <Laney> woo!
[09:08] <Laney> hey didrocks!
[09:08] <seb128> doing good as well, played some double tennis yesterday (but only for an hour, wanted some relaxing as well and it started raining)
[09:10] <Laney> nice
[09:10] <Laney> getting cold for that :P
[09:11] <Laney> oh look, dezrt's new tests fail
[09:11] <Laney> https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=armhf&ver=2.47.3-1&stamp=1448490072
[09:12] <seb128> haha
[09:14] <Laney> https://buildd.debian.org/status/package.php?p=glib2.0&suite=experimental
[09:14] <Laney> all 32 bit arches
[09:14]  * Laney shakes head sadly
[09:15]  * TheMuso -> EOD, later folks. :)
[09:15] <willcooke> see ya TheMuso
[09:19] <seb128> RAOF, did you say you planned to update colord-gtk in Debian? ;-)
[09:28]  * willcooke remembered the tar command first time
[09:30] <didrocks> willcooke: it's easy, just tar cf <yourfile>.<your_ext> dir
[09:30] <didrocks> based on the extension, it will compress (hence the 'c'), the file (f) in the desired format
[09:30]  * willcooke uses cvfj
[09:31] <willcooke> oh
[09:31] <didrocks> no need for j, nor v :)
[09:31] <willcooke> when did it start doing that?  (expecting the answer 1998)
[09:31] <didrocks> just "tar cf foo.bz2 bla" for instance
[09:31] <didrocks> a year and half ago :)
[09:31] <didrocks> so not that outdated!
[09:31] <willcooke> oh phew!
[09:31] <didrocks> (of course, same for extracting)
[09:32] <willcooke> I didn't get a letter from the elders of the internet about this
[09:32] <didrocks> heh
[09:32] <didrocks> hum, we don't produce any more usb image, right?
[09:32] <Laney> I thought the omitting of the compression type only worked for 'x'
[09:33] <didrocks> Laney: oh, possible it's doing that silently, let me check
[09:33] <Laney> check with 'file' that it's actually compressing it :P
[09:33] <didrocks> Laney: ah, you are right
[09:33] <didrocks> willcooke: withdraw what I said for compress then ^
[09:33] <didrocks> it's just creating a tar
[09:34] <didrocks> extract works though
[09:34] <Laney> tar xvf foo.tar.whatever works though
[09:34] <willcooke> neat!
[09:34] <didrocks> Laney: yeah, I would have hope some fallback based on the extension…
[09:34] <Laney> doesn't mean you get to forget the letters
[09:34] <Laney> which is Good Unix Knowledge
[09:35] <didrocks> FYI, I'll have a look this afternoon on our language that we shipped by default, expect some seed changes :)
[09:35]  * didrocks wants to reintroduce the one we shipped at least in hardy
[09:35] <Laney> programming language or speaking language?
[09:35] <didrocks> (as no more size constraints…)
[09:36] <didrocks> speaking :p
[09:36] <didrocks> yeah, haskell on the CD of course! :)
[09:37] <Laney> how much space are you talking about?
[09:37] <didrocks> I need to remember how this works on install without Internet access. I guess we just needed to ship in live
[09:37] <didrocks> Laney: well, it's hard to know in advance
[09:37] <Laney> no limit but that doesn't mean go super wild
[09:37] <didrocks> Laney: hence, we need to look at
[09:37] <didrocks> yeah
[09:37] <Laney> sure it is, boot a live iso and install the new packages
[09:37] <didrocks> I won't ship a big extra number of them
[09:37] <didrocks> Laney: well, you will the know the extracted size
[09:37] <Laney> you know the size of the debs
[09:38] <Laney> which is more or less good enough
[09:38] <didrocks> then, we can still approx that package size == size in the squashfs
[09:38] <didrocks> yep
[09:38] <didrocks> that's what I'll look at, to see how many we can ship reasonably
[09:38] <didrocks> (more afraid about the install part, that this is still working as expected)
[09:38] <Laney> what install part
[09:39] <didrocks> like, you don't have any network connexion
[09:39] <didrocks> connection*
[09:39] <didrocks> you choose "de"
[09:39] <didrocks> which is part of the live task
[09:39] <didrocks> ensure that we have it installed
[09:39] <didrocks> and that other languages are removed when not selected
[09:40] <Laney> what makes you think it doesn't work?
[09:41] <Laney> we definitely touched this area with chinese stuff in wily
[09:41] <didrocks> did anyone test that no chinese package is installed after a fresh one?
[09:41] <didrocks> (if you select en)
[09:41] <Laney> yes
[09:41] <didrocks> good then :)
[09:42] <Laney> so I'm wondering what you have seen
[09:42] <didrocks> nothing
[09:42] <Laney> or is it just a random thing?
[09:42] <didrocks> just telling "we should ensure it's working"
[09:42] <didrocks> so unsure what this discussion is even about
[09:43] <davmor2> willcooke: next you'll be saying you know how to use vim, sed and regex ;)
[09:43] <willcooke> I've being using vim for years
[09:43] <willcooke> mainly because I can't work out how to quit it
[09:43] <willcooke> badum *tish*
[09:43] <Laney> unsure> you started it?
[09:44] <didrocks> Laney: the bikeshedding part? I don't think so :)
[09:44] <didrocks> Laney: just telling "I'm going to work on that and test it, just a warning"
[09:44] <Laney> bikeshedding?
[09:44]  * didrocks shrugs
[09:44] <Laney> I was trying to establish if you've seen something because I worked on the area
[09:44] <Laney> not really bikeshedding
[09:44] <davmor2> willcooke: wompwompwomp.com
[10:03] <Trevinho> Hi
[10:05] <seb128> hey trevinho, how are you? was the drive back alright yesterday?
[10:06] <larsu> where did you drive?
[10:06] <Trevinho> seb128: yes.... Alright. Then I hacked till late on unity / nautilus :-P
[10:06] <seb128> oh, larsu is there as well!
[10:06] <seb128> hey larsu ;-)
[10:07] <Trevinho> larsu: I was at my parents home wich is 1.5hrs far from Florence, and I had to go back to my place
[10:07] <didrocks> good morning Trevinho!
[10:07] <Trevinho> Hi didrocks
[10:09] <larsu> ah cool
[10:09] <larsu> and good mornigng I guess
[10:09]  * larsu forgot to say that earlier :)
[10:09] <larsu> hi seb128 & didrocks as well!
[10:09] <pitti> hey larsu, guten MOrgen!
[10:09] <didrocks> hey larsu ;)
[10:10] <larsu> moin pitti!
[10:13] <attente> good morning
[10:14] <willcooke> attente, O_o  early start?
[10:15] <seb128> hey attente
[10:15] <attente> willcooke: trouble sleeping...
[10:15] <seb128> willcooke, how is the gedit theming going btw?
[10:15] <willcooke> seb128, - spooky!  I was just about to ask you to try it
[10:15] <willcooke> there are two branches you will need
[10:16] <seb128> hehe
[10:16] <willcooke> https://code.launchpad.net/~willcooke/ubuntu-themes/geditspecific
[10:16] <willcooke> https://code.launchpad.net/~willcooke/ubuntu-themes/notebooktabs
[10:16] <willcooke> they address different issues, but the gedit changes need the notebook changes to look ok
[10:18] <willcooke> There are still some minor issues with the tabs (borders and such, but a) I don't have time to spend looking at it right now and b) I think we need to leave something for the Google Code In guys to work on
[10:19] <xnox> welcome seb =)
[10:19] <attente> seb128: good morning
[10:19]  * xnox should scroll down scrollback before replying
[10:19]  * xnox had the chat at seb saying good morning =)
[10:19] <darkxst> willcooke, heh, lets put everthing on hold, and leave it for the google code in, kids ;)
[10:20] <willcooke> darkxst, :)  We can try.  It's a good strategy
[10:20] <seb128> hey xnox!
[10:20] <attente> seb128: do you have time to review https://code.launchpad.net/~attente/maliit-inputcontext-gtk/trunk?
[10:20] <darkxst> yes, I am making a list of bugs I would rather not fix, just for that reason!\
[10:20] <xnox> ssshhhh. i have plenty of things for google code it to build ;-)
[10:22] <willcooke> oh, now I need to fix terminal as well
[10:22] <willcooke> so yeah, larsu or seb128 - gonna need some help getting the inspector to work with GNOME terminal.  I think I have to *shudder* build from source
[10:23] <Laney> I'm used to those bigger tabs now so will complain when they change back :P
[10:23] <willcooke> :D
[10:23] <darkxst> larsu,  are the css nodes in gtk+ going to be a problem for ubuntu themes?
[10:25] <seb128> willcooke, gedit looks fine to me, but can you include the
[10:25] <seb128> GeditStatusbar {
[10:25] <seb128>     border-top: 1px solid @borders;
[10:25] <seb128> }
[10:25] <seb128> as well?
[10:25] <seb128> willcooke, unsure why you discarded it, but without that the status bar is not well delimited from the document
[10:25] <seb128> willcooke, I included it in gedit as a workaround until the theme is updated but we shouldn't distro patch gedit for that
[10:25] <willcooke> seb128, I checked on the the old gedit and there is no border.
[10:26] <seb128> current xenial has that patch, see ^
[10:26] <larsu> willcooke: you can do it!
[10:26] <seb128> what do you call "old gedit"?
[10:26] <willcooke> erm, the version running in my W vm
[10:26] <larsu> darkxst: what do you mean by problem? They'll certainly need a lot of adjustment
[10:26] <larsu> just like adwaita
[10:26] <seb128> willcooke, well, it looks better with it :-)
[10:27] <willcooke> seb128, agreed
[10:28] <willcooke> one sec...
[10:29] <seb128> willcooke, there is something weird with the notebooktabs changes
[10:29] <seb128> they make the wm controls being wrong
[10:29] <Sweet5hark> moin
[10:29] <seb128> or quite different from ours themed ones at least
[10:29] <seb128> hey Sweet5hark!
[10:30] <Sweet5hark> seb128: heya.
[10:30] <seb128> the buttons borders as well
[10:32] <willcooke> seb128, sorry, don't understand
[10:33] <seb128> willcooke, http://people.canonical.com/~seb128/gedit.png
[10:33] <seb128> is what gedit looks like with the notebooks branch changes
[10:33] <seb128> seems like the wm decoration background color changed
[10:33] <seb128> like the minimize, restore ones were light
[10:34] <seb128> willcooke, http://people.canonical.com/~seb128/geditold.png
[10:34] <seb128> easier than words
[10:35] <seb128> I think you tab color change doesn't impact only tabs
[10:35] <seb128> ?
[10:35] <willcooke> hmm.  I suspect I copied something from Ambiance to Radiance that I shouldn't have ;)
[10:35] <willcooke> seb128, is it just gedit?
[10:36] <seb128> no
[10:36] <larsu> ah, the joys of css :)
[10:36] <larsu> "I wonder what else this rule *could* be affecting"
[10:37] <willcooke> seb128, just checked on here, and I can see the gedit b0rkedness but others seem ok
[10:37] <seb128> willcooke, you need something use GtkHeaderBar decorations
[10:37] <seb128> try gtk3-demo
[10:38] <seb128> using*
[10:38] <willcooke> hrm, hold on - it's fine on this machine.  I had a specific theme selected in the inspector
[10:39] <willcooke> can't reproduce
[10:39] <seb128> I applied the diff from your commit with patch, so maybe something weird with that :-/
[10:40] <willcooke> I'll reset everything to default here and try again
[10:51] <willcooke> seb128, hrm.  I deleted all Amb. and Rad. copied over a fresh version from the archive, reapplied my changes, and it all looks ok here
[10:51] <willcooke> :/
[10:51] <willcooke> also, http://bazaar.launchpad.net/~willcooke/ubuntu-themes/geditspecific/revision/457
[10:51] <willcooke> includes the status bar border and whitespace fixes
[10:52] <seb128> willcooke, you should mp the gedit one
[10:52] <willcooke> seb128, will do
[10:53] <seb128> I'm going to try again the other branch
[10:56] <willcooke> https://code.launchpad.net/~willcooke/ubuntu-themes/geditspecific/+merge/278682
[10:58] <seb128> willcooke, +1
[10:58] <willcooke> woo!  10 years later I finally have something in Ubuntu
[10:59]  * willcooke goes off to find some champagne
[10:59] <seb128> willcooke, how do you try?
[10:59] <seb128> willcooke, I opened http://bazaar.launchpad.net/~willcooke/ubuntu-themes/notebooktabs/view/head:/Radiance/gtk-3.0/gtk-widgets.css
[10:59] <seb128> clicked "download file"
[10:59] <seb128> copied over /usr/share/themes/Radiance/gtk-3.0/gtk-widgets.css
[11:00] <seb128> then "gedit -s"
[11:00] <seb128> (using the corresponding theme of course)
[11:00] <seb128> still get the issue
[11:00] <willcooke> hrm, lemme try that...
[11:02] <seb128> willcooke, oh, and congrats on getting changes landing in Ubuntu ;-)
[11:02]  * seb128 lunch, bbiab
[11:02] <willcooke> seb128, aha.  I got it now
[11:02] <willcooke> :/
[11:03] <willcooke> but only in a guest session
[11:03] <willcooke> oh no, there we go
[11:06] <willcooke> careless copying on my part
[11:16] <willcooke> seb128, fixed
[11:16] <willcooke> http://bazaar.launchpad.net/~willcooke/ubuntu-themes/notebooktabs/revision/457
[11:49] <willcooke> trying to build gnome-terminal from source...
[11:49] <willcooke> have installed build-deps
[11:49] <willcooke> have also done ./configure --enable-debug --disable-search-provider
[11:50] <willcooke> but it's saying aclocal.m4 failed with error 127
[11:50] <willcooke> ahh
[11:51] <willcooke> aclocal-1.13 is missing
[11:51] <willcooke> 1.15 is available
[11:51] <willcooke> oops, wrong keyboard
[12:04] <willcooke> oh, I think I fixed it
[12:04] <willcooke> I ran /usr/bin/gnome-autogen.sh
[12:04] <willcooke> and now it makes
[12:06] <darkxst> willcooke, that is obsolete though
[12:06] <darkxst> atleast upstream are trying to move away from using those scripts
[12:07] <darkxst> (i think)
[12:09] <Laney> there's probably an autogen.sh
[12:10] <willcooke> Laney, doesn't seem to be one
[12:10] <Laney> you using git or the package?
[12:11] <willcooke> apt-get source
[12:11] <willcooke> it's built not
[12:11] <willcooke> *now
[12:11] <willcooke> and then I did a sudo make install
[12:11] <willcooke> and things happened
[12:14] <Trevinho> iS there a way to enter in a recovery-mode like for lxc?
[12:16] <davmor2> Trevinho: how do you mean?
[12:16] <Trevinho> davmor2: my lxc container doesn't start anymore due to some journal daemon issues... I guess it was a wrong update..
[12:17] <Trevinho> davmor2: so I wanted to try to fix
[12:17] <Trevinho> davmor2: chrooting there and using apt is safe?
[12:17] <davmor2> Trevinho: ah okay no idea
[12:19]  * Laney stabs fontconfig
[12:19] <Laney> what the F
[12:20] <didrocks> Laney: what's up?
[12:21] <Laney> trying to fix/craft a snippet for the ubuntu arabic font
[12:21] <Laney> doesn't seem to work in LO write
[12:21] <Laney> r
[12:21] <Laney> does this even use fontconfig?
[12:21] <Laney> gedit is fine ._.
[12:21] <didrocks> Laney: that's what I was going to say, I'm unsure it's using fontconfig
[12:21] <didrocks> Sweet5hark: ? ^
[12:22] <Laney> oh actually
[12:22] <Laney> hmm
[12:23] <Laney> this is weird
[12:27] <Sweet5hark> yes, LibreOffice uses fontconfig ... somehow. at least we are shipping it even on windoze/osx
[12:28] <Laney> it has wrong spacing I think
[12:28] <Laney> but the right character
[12:28] <Laney> s
[12:29] <willcooke> Yyyyyeeeesssssssss!  I've got a terminal with the inspector working
[12:29] <Trevinho> willcooke: :😃
[12:41] <willcooke> Laney, did you see the blurb about Rasp. Pi Zero?  There's a "free" one on the front of Mag Pi magazine today./
[12:41]  * willcooke is off to the shops now....
[12:41] <Laney> nein
[12:41] <Laney> what is that?
[12:42] <didrocks> Laney: it's all over my rss feed!
[12:42] <Laney> bah, rss feeds
[12:42] <Laney> I've been writing XML!
[12:42] <didrocks> :p
[12:42] <Laney> ok, /me looks at plus
[12:43] <didrocks> as long as there is no xpath/xslt, you're safe :)
[12:43] <didrocks> (but arm11, as the first raspy…)
[12:44] <Laney> mmm
[12:50] <Laney> Sweet5hark: could you help me check this font?
[12:50] <Laney> install https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/ppa/+build/8346050 pkg, type some arabic in writer in the "Ubuntu" font
[12:51] <Laney> it should use Ubuntu Arabic via the fontconfig rule and does in gedit
[12:51] <Laney> i.e. if you pick Ubuntu Arabic from the selector explicitly there should be no change
[12:51] <Laney> but there is, the spacing changes (characters look the same to me but maybe I just can't tell)
[12:56] <Sweet5hark> Laney: *urgh* is that a regression? anyway the whole font rendering stuff in vcl is ... "interesting" ...
[12:57] <Laney> I don't know
[12:57] <Laney> just wrote this rule now
[12:57] <Laney> there's a chance I messed it up :(
[12:57] <Laney> but fc-match seems to agree with me
[13:06] <willcooke> meh - they dont' have it
[13:07] <willcooke> I did see a full on Vegas style Elvis doing his shopping though, so not a totally wasted trip
[13:08] <Sweet5hark> Laney: so http://opengrok.libreoffice.org/xref/core/vcl/generic/fontmanager/fontconfig.cxx has the fontconfig wrapping ...
[13:09]  * Laney blind
[13:09] <Sweet5hark> Laney: not sure, if we ever supported what you are trying to do though ...
[13:09] <Laney> basically substituting one font for another which has different spacing
[13:18] <Sweet5hark> Laney: there is also the fontsubst.cxx in the same dir as above.  I dont know how much we do that and if that would even be considered a feature. Rendering document content depending on system config is something most users do not consider, but a bug ...
[13:19]  * seb128 head -> desk
[13:19] <seb128> the new nautilus maintainer is weird
 csoriano___, btw you should make your editor display spaces/tabs, your commits seem to often alternate between those and it's looking weird/buggy
 seb128: I already do, what I'm trying is to slowly replace tabs by spaces, they drove me crazy
 so when it's a new line I use spaces, when it's an already line there I use tabs
[13:19] <seb128>  I'm not sure how good that approach is
[13:19] <seb128>  but really, tabs makes me crazy :)
[13:20] <Laney> Sweet5hark: what happens if I load it on a system with a different set of fonts installed?
[13:20]  * seb128 shrugs
[13:20] <Laney> it's shipped as part of the font, not really config
[13:20] <Sweet5hark> (usually those result in bugs filed as "my document renders wrong on $platform", then corrected to s/wrong/different/ ....)
[13:20] <Sweet5hark> k
[13:21] <Laney> just turns out to be in a separate file
[13:21] <Laney> kind of annoying actually
[13:22] <Sweet5hark> Laney: usually ODT documents specify their own font fallback in the document. Also LibreOffice can store font in the document these days.
[13:22] <Laney> bet that bit doesn't know about fontconfig
[13:23] <Laney> thinking about this makes me feel ill
[13:25] <Sweet5hark> ya, I dont think that highlevel stuff knows or cares much above fontconfig.
[13:25] <Laney> like you can type any name into the selector but it turns out to mean something else
[13:26] <Laney> even depending on things like the font size
[13:28] <Sweet5hark> (currently 365 open libreoffice bugs with "font" in the subject: crossplatform font rendering is hard)
[13:33] <Laney> just one bug per day!
[13:37] <Sweet5hark> well, there are also 790 resolved bugs with "font" in subject (198 of those with resolution: fixed).
[13:54]  * Laney lunch
[14:11] <desrt> good morning, desktop
[14:11] <didrocks> good morning desrt
[14:12] <desrt> hey didrocks
[14:12] <pitti> hey desrt, good morning
[14:12] <seb128> hey desrt
[14:12] <desrt> pitti: nice to see you around :)
[14:13] <desrt> seb128: good morning to you as well
[14:13] <pitti> desrt: heh, I'm here all the time :)
[14:13] <desrt> what's everyone up to this afternoon?
[14:13] <seb128> desrt, Laney was looking for you ;-)
[14:13] <desrt> pitti: but usually AFK during the good-morning round :)
[14:13] <desrt> seb128: uh oh...
[14:13] <seb128> indeed
[14:13] <seb128> hide!
[14:13] <desrt> what did i break now?
[14:13] <seb128> glib tests on 32 bits arch it seems
[14:14]  * desrt makes a face
[14:15] <seb128> https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=armhf&ver=2.47.3-1&stamp=1448490072
[14:17] <desrt> # GLib:ERROR:/«PKGBUILDDIR»/./glib/tests/overflow.c:100:test_checked_guint64_add: assertion failed (cases[i].c == result):<PHONE_NUMBER> ==<PHONE_NUMBER>)
[14:17] <desrt> tsk tsk tsk
[14:17] <desrt> it's actually my fault, too
[14:17] <desrt> installing a 32bit chroot now to take a look
[14:20] <desrt> pitti: what happened to our gnome CI? :(
[14:20] <desrt> nobody tests i386 anymore, unfortunately
[14:21] <pitti> desrt: that's been gone for years already, it was mostly a prototype back then but there wasn't enough interest upstream to keep it
[14:21] <pitti> I also thought it had pretty much been superseded by Colin Walter's os-tree builds
[14:21] <desrt> apparently not
[14:21] <desrt> if it's not amd64, it's not getting tested :p
[14:23] <desrt> Laney: all kinds of warnings even building that test :(
[14:27] <desrt> Laney: want to just pull the patch from the tip of master?
[14:27]  * desrt just pushed it
[14:27] <desrt> extremely silly error
[15:14] <Laney> desrt: indeed, I would have suggested that fix
[15:14] <Laney> thanks!
[15:23] <desrt> fek
[15:23] <desrt> $5 rasp pi
[15:23] <desrt> time to reconsider my cluster!
[15:23] <seb128> charles, hey, could you get an indicator-landing organized? there are 6 "ready to land" branches, some waiting since septembre
[15:26]  * desrt considers that the usb ethernet adaptors would probably cost several times more than the rest of the computer
[15:35] <willcooke> desrt, indeed, plus the cheapest SD card I found on ebay was 1.80 GBP
[15:36] <desrt> i think it would be possible to speak ppp over the gpio
[15:36] <willcooke> but still, the time where a computer being given away with breakfast cereal is pretty much with us
[15:36] <willcooke> start a ppp session over the UART
[15:36] <desrt> not sure if that's fast enough to support distcc or not
[15:37] <willcooke> :)
[15:38] <desrt> i guess it's probably also possible to wire in the power via pin headers instead of having to use microusb plugs
[15:39] <desrt> so that means you could get a network attached server running with ~4+ish wires soldered on
[15:41] <desrt> at this point i'd probably replace ppp+distcc with something that received .c source over the serial connection (with checksums) and wrote back the object code when it was done
[15:41] <desrt> free up a bunch of memory for the compiler
[15:41] <desrt> would want to add pipelining so that you could send the source of the next program (and receive the binary of the previous) while building
[15:45] <desrt> ...and would you look at that.. the uart pins on the gpio are immediately adjacent to the power rails
[15:49] <larsu> desrt: hi!
[15:50]  * larsu was in hiding hacking on nautknautlius
[15:51] <didrocks> larsu: I prefer "nonotilus" :)
[15:51] <Laney> naughtylus
[15:52] <didrocks> :p
[15:52] <didrocks> not bad
[15:52] <larsu> one of the problems I'm having is that many actions are in a "view" action group that I can't access from dbus :/
[15:53] <larsu> didrocks: meh. shitty connection and ssh+irssi don't mix well :)
[15:53]  * larsu is on a train
[15:53] <larsu> desrt: any idea how to quickly export those without copying them all to win.?
[15:54] <desrt> larsu: no good way, sorry.
[15:55] <larsu> ya that's what I figured
[15:55] <larsu> head -> desk
[15:55] <didrocks> larsu: you have a desk on the train?
[15:55] <didrocks> luxury larsu :)
[15:55] <larsu> didrocks: I do :)
[15:56] <larsu> fancy german ice
[15:56] <didrocks> heh
[15:56] <didrocks> just so that you can bang your head against it
[15:56] <larsu> this is what I'm doing right now
[15:56] <larsu> it's ridiculous how much time I spend on a stupid menu
[15:57] <Laney> something for the CV
[15:57] <larsu> ...
[15:57] <Laney> I am one of the world's foremost experts in menu exporting
[15:57] <larsu> ya no shit
[15:57] <didrocks> larsu: do you make home delivery as well? :)
[15:58] <didrocks> I want my menu at home!
[15:58] <larsu> haha
[15:58] <larsu> no sorry
[15:58] <didrocks> :(
[15:58] <didrocks> sad face
[15:58] <larsu> unless you live on the dbus womewhere
[15:58] <larsu> *somewhere
[15:58] <didrocks> I heard it's a busy place…
[15:58] <didrocks> with a lot of menu-related traffic
[15:58] <larsu> haha
[15:59] <larsu> not that much - turns out exporting some of them is really hard
[15:59] <didrocks> and you didn't tackle the java ones (yet)
[16:00]  * larsu hides
[16:04] <larsu> almost at the station - see you latwr!
[16:07] <didrocks> see you larsu
[16:59] <didrocks> good night guys!
[16:59] <willcooke> cya didrocks
[16:59] <didrocks> see you willcooke
[17:05] <Trevinho> seb128: I've just pushed this small change: https://code.launchpad.net/~3v1n0/nautilus/export-active-locations/+merge/278730
[17:11] <seb128> Trevinho, thanks, I'm going to have a look when I'm doing updating the patch I'm working on
[17:12] <Trevinho> seb128: it's not changing much, mostly I'm moving the active view as first listed... So at unity level I can know what's selected
[17:12] <seb128> Trevinho, ok
[17:12] <seb128> there are quite some changes in the new nautilus
[17:12] <seb128> I hope it's going to be fine as an user experience
[17:12] <seb128> like they removed the copy dialog
[17:13] <seb128> to make it part of the window
[17:13] <Trevinho> seb128: the thing is that... I might in some way support tabbed windows, and associate a window with multiple launcher icons, but I guess it's not the best thing... Maybe it's just better to focus on the selected tab... While other tabs are ignored
[17:13] <Trevinho> Oh, finally!
[17:13] <seb128> hehe
[17:13] <chrisccoulson> seb128, no one uses file managers though, right?
[17:13] <seb128> I updated the patch so we still get the launchpad progress bar
[17:13] <chrisccoulson> (and hi) :)
[17:13] <seb128> chrisccoulson, hey ;-)
[17:13] <seb128> right, users don't need a fs anyway
[17:13] <Trevinho> That might mean to remove even some workarounds in unity code... (Nothing really about "nautilus" is hardcoded, but  it's a condition that only nautilus has)
[17:13] <seb128> datas are owned by apps!
[17:14] <chrisccoulson> heh
[17:14] <Trevinho> seb128: lovely
[17:14] <Trevinho> (the launcher progresss)
[17:22] <seb128> Trevinho, merged your change, I still have a patch to update after the one I'm working on then we need larsu's menu work, then the update should be ready, but you can already build from bzr if you want to test the new version, it works fine, just lack some ubuntu bits
[17:23] <Trevinho> seb128: thanks, I'm writing a copule of other patches as well, to add timestamp support to some actions so that we can remove workarounds that caused some bugs...
[17:39] <willcooke>  right, gotta go.  Beavers helping tonight
[17:39] <willcooke> l8r
[17:43] <Trevinho> seb128: I've just pushed a new change to that branch, can you still merge it or want a new one (I've protected x11 calls, so that it won't crash in mir)?
[17:43] <seb128> Trevinho, I can uncommit and merge again I guess
[17:43] <Trevinho> nice
[17:44] <seb128> trevinho, let me know when you have pushed your commit
[17:44] <Trevinho> seb128: it's pushed
[17:44] <Trevinho> seb128: nooooo
[17:44] <seb128> trevinho, weird, https://code.launchpad.net/~3v1n0/nautilus/export-active-locations/+merge/278730 doesn't show it
[17:45] <Trevinho> seb128: in the wrong branch :/
[17:45] <Trevinho> seb128: it's now there
[17:47] <seb128> trevinho, still not ... or did you overwrite?
[17:47] <seb128> oh, it is now
[17:48] <Trevinho> :)
[17:48] <seb128> trevinho, ok, merged
[17:48] <Trevinho> cool
[21:03] <xclaesse> attente, are there documentation for the libapparmor API somewhere?
[21:07] <attente> xclaesse: i don't know
[21:08] <xclaesse> attente, any example code?
[21:09] <attente> xclaesse: what are you trying to do?
[21:10] <xclaesse> attente, test your dconf api
[21:11] <xclaesse> attente, first I need to take the "security context"
[21:14] <attente> xclaesse: please don't use my patches, they're superceded by the patchset jjohansen has written: https://lists.ubuntu.com/archives/apparmor/2015-October/008654.html, https://lists.ubuntu.com/archives/apparmor/2015-October/008655.html, https://lists.ubuntu.com/archives/apparmor/2015-October/008656.html, https://lists.ubuntu.com/archives/apparmor/2015-October/008657.html
[21:17] <xclaesse> attente, wasn't sure if those patches were superseeding yours of if it was aternative implementation that you didn't agree with
[21:22] <attente> xclaesse: those patches are superceding them, but from what i understand, the apparmor developers are too busy this cycle to merge this feature
[21:31] <xclaesse> attente, with that API we can only query permissions on a given path, we cannot query the list of ro/rw paths, rights?
[21:36] <attente> xclaesse: i'm also not sure about that, but looking at the new api, there seems to be a generic blob-getting function aa_query_label_data(), but i'm not sure if it's possible to extract the whole chunk and it seems pretty low level
[21:41] <xclaesse> attente, hm, not sure to understand what aa_label_data_info contains
[21:41] <xclaesse> I'll make tests to see
[21:41] <xclaesse> attente, a more basic question, in those APIs, how do I get the "label" ?
[21:42] <xclaesse> aa_getcon() ?
[21:43] <jjohansen> attente: well, very busy, can't commit to merging them, but if they happen to show up. I did promise I would spend weekend time to get them reviewed
[21:44] <jjohansen> I will work on getting the base apparmor lib patches in,
[21:44] <jjohansen> I've got another set of patches to send out for review that those will go in
[21:46] <attente> jjohansen: ok, thanks for updating us. xclaesse ^ it might be best to wait till the api is more final


[10:53] <mup> Bug #1697158 opened: MAAS not attach disk after commissioning <MAAS:New> <https://launchpad.net/bugs/1697158>
[14:06] <atm_it> Hello, I'm having issues deploying openstack from landscape. I noticed I cannot ssh to some nodes deployed by maas
[14:09] <atm_it> i get an "SSH Permission denied (publickey)" message. I think this is the reason why the deployment fails
[20:18] <mup> Bug #1697209 opened: Network testing fail - ntp <MAAS:New> <https://launchpad.net/bugs/1697209>


[02:06] <mup> PR snapd#8152 opened: managers_test: add uc20 kernel snap update happy and panic tests <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8152>
[06:15] <mborzecki> morning
[06:38] <mborzecki> school run, back in 30
[07:06] <mborzecki> re
[07:45] <mborzecki> mvo: morning
[07:48] <mvo> hey mborzecki ! good morning
[08:01] <pstolowski> morning
[08:14] <zyga> re
[08:14] <zyga> good morning
[08:16] <zyga> tests are somewhat unhappy
[08:16] <zyga> I've seen snapd-failover fail a lot yesterdat
[08:16] <zyga> I know Ian was looking into that but perhaps it needs more eyes
[08:18] <zyga> and snap-run hangs, oh my
[08:18] <pstolowski> zyga: right, i saw snapd-failower failures as well
[08:22] <zyga> so
[08:22] <zyga> I need bionic
[08:22] <zyga> and I need tests that run as user
[08:22]  * zyga gets to work
[08:40] <zyga> ok, test written, let's run it
[09:10] <zyga> mborzecki: do you expect https://bugs.launchpad.net/snapd/+bug/1863859 to be true given our environment generators?
[09:10] <mup> Bug #1863859: Using su removes /snap/bin from PATH <snapd:New> <https://launchpad.net/bugs/1863859>
[09:10] <zyga> mborzecki: I just noticed this in tests
[09:13] <mborzecki> zyga: su - ?
[09:13] <zyga> su test -c "snap run foo" vs su test -c "foo"
[09:13] <mborzecki> zyga: try su -l
[09:13] <zyga> mborzecki: k
[09:14] <mborzecki> or . $TESTSLIB/user.sh and then as_user_simple ?
[09:14] <mborzecki> zyga: simple will not load the profile
[09:16] <zyga> I'll look at some tests that suffer from this
[09:32]  * zyga loves calls with baby crying next door
[09:33] <mup> PR snapd#8153 opened: [RFC] "snap run --explain" with different formating <Created by mvo5> <https://github.com/snapcore/snapd/pull/8153>
[09:33] <zyga> mvo: I'll review in a moment, need to check what the crying is all about
[09:34] <mvo> zyga: no rush, thank you!
[09:55] <zyga> re
[10:10]  * zyga debugs all kinds of things through one failing test
[10:46] <zyga> mborzecki: quick question
[10:46] <zyga> https://www.irccloud.com/pastebin/B2mlykUV/
[10:46] <zyga> (this is test-snapd-sh without arguments
[10:46] <zyga> spawning endless loop of bad substitution
[10:46] <zyga> why would our argv[0] cause this?
[10:48] <zyga> I'm patching snap-exec to show what's going on at that layer
[10:48] <zyga> it is driving me crazy, I want to finally fix it
[10:53] <zyga> mborzecki: it's a dash specific message
[10:53] <zyga> that's interesting
[10:53] <zyga> I think we do something incorrectly
[10:53] <zyga> oh well, let me grab coffee
[10:55] <zyga> desktop 18.04 install in progress
[10:55] <zyga> I think we have a problem with systemd there :/
[10:55] <zyga> but I think my test setup is not doing what is right
[11:08] <zyga> brb
[11:14] <zyga> ha
[11:14] <zyga> got it
[11:14] <zyga> found a bug in spread
[11:17] <zyga> PS1 breaks dash
[11:17] <zyga> becuase SPREAD_PATH is unset
[11:18] <zyga> is it just me or is this a quiet channel?
[11:30] <sdhd-sascha> zyga: hey :-)
[11:30] <zyga> hey
[11:30] <zyga> how are you?
[11:30] <sdhd-sascha> zyga: i'm fine. thank you. Little bit tired. But fine :-) And you ?
[11:30] <zyga> a bit scared I missed something big that came up yesterday evening
[11:31] <zyga> debugging it now
[11:31] <sdhd-sascha> oh, good luck
[11:32] <sdhd-sascha> i'm just started to fix the snap for the github actions.
[11:34] <sdhd-sascha> zyga: on which point it's best to do chmod of a script ? I have a /run.sh and snapcraft says it's not executable. I use chmod at `override-build` currently.
[11:35] <zyga> sdhd-sascha: are you building on windows?
[11:35] <sdhd-sascha> `Failed to generate snap metadata: The specified command 'run.sh' defined in the app 'runner' is not executable.`
[11:35] <zyga> sdhd-sascha: it's best to keep it executable in the tree
[11:35] <sdhd-sascha> I wonder, why the generated tar isn't executable ... i will see
[11:38] <sdhd-sascha> zyga: if i go into `multipass exec ` ... Then inside of `/root/parts/runner/build/run.sh` it's executable.
[11:38] <sdhd-sascha> ```
[11:38] <sdhd-sascha> apps:
[11:38] <sdhd-sascha>   runner:
[11:38] <sdhd-sascha>     command: run.sh
[11:38] <sdhd-sascha> ```
[11:38] <sdhd-sascha> But i still get: `Failed to generate snap metadata: The specified command 'run.sh' defined in the app 'runner' is not executable.`
[11:39] <sdhd-sascha> hmm
[11:39] <zyga>  oh great
[11:39] <zyga> killing dash killed gnome-terminal
[11:39] <sdhd-sascha> wow
[11:40] <zyga> anyway
[11:40] <zyga> just more bugs
[11:43] <cmatsuoka> ijohnson: thanks for the PR
[11:43] <cmatsuoka> ijohnson: it seems that tests failed in a strange way
[11:46] <cmatsuoka> command systemctl is-active snapd.failure.service keeps failing after 30 attempts
[11:47] <cmatsuoka> and snapd.service: Failed to execute command: Exec format error
[11:47] <cmatsuoka> zyga: does that sound familiar to you?
[11:47] <zyga> cmatsuoka: hey
[11:47] <zyga> yeah, there's something really broken
[11:47] <zyga> it's worse recently perhaps the test is new or something related changed
[11:47] <zyga> it fails left and right
[11:48] <cmatsuoka> EXEC spawning /snap/snapd/x2/usr/lib/snapd/snapd: Exec format error
[11:48] <zyga> I haven't looked into it yet
[11:48] <zyga> cmatsuoka: yeah, the test is trying to install corrupt snapd
[11:48] <zyga> to check failover
[11:48] <zyga> but failover never kicks in
[11:48] <zyga> the exec format error is expected and harmless noise (for the test)
[11:49] <cmatsuoka> ah ok
[12:02] <mup> PR snapd#8154 opened: tests: reset PS1 before possibly interactive dash <Created by zyga> <https://github.com/snapcore/snapd/pull/8154>
[12:02] <zyga> mborzecki: ^
[12:02] <zyga> this caused me some grief
[12:02] <zyga> cmatsuoka: I can look after I investigate more systemd stuff
[12:03] <ijohnson> cmatsuoka: zyga: yes I was looking into this a bit yesterday, I think that the patch mborzecki recommended to snap-failure is useful here, I had that small change proposed in my larger core spread PR, but perhaps I should break it out just to get that merged
[12:03] <ijohnson> and morning folks btw
[12:03] <mborzecki> ijohnson: hey!
[12:03] <ijohnson> hey mborzecki
[12:03]  * ijohnson is here for real this morning
[12:04] <mborzecki> `The dash bug has been reported to the dash mailing list (there is no bug tracker).` hahah welp
[12:08] <zyga> mborzecki: oh well
[12:09] <zyga> mborzecki: it's very unixy
[12:09] <zyga> mborzecki: mailing list archive, CCing people
[12:09] <zyga> mborzecki: 3-character names
[12:09] <zyga> thank you for the review guys
[12:09] <mvo> I see a lot of red in the most recent spread runs, has anyone investigated yet?
[12:09] <zyga> mvo: snapd-failover
[12:09] <zyga> it's failing ... over and ... I'll shut up now ;)
[12:10] <cmatsuoka> :D
[12:10]  * zyga returns to debugging systemd
[12:14] <mup> PR snapd#8155 opened: tests: mv ubuntu-core-snapd{,-failover} to core/ suite <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8155>
[12:14] <ijohnson> mvo: I opened ^ which I think will help with the snapd-failover test
[12:15] <cachio> ijohnson, zyga failover test started failing a time ago but with external backend
[12:15] <cachio> now is started failing on travis too
[12:15] <ijohnson> cachio: interesting you mean on the lab machines ?
[12:15] <ijohnson> cachio: do you have logs?
[12:15] <cachio> ijohnson, http://paste.ubuntu.com/p/DXD9WN7CtJ/
[12:16] <cachio> this is from the 2.43.3
[12:16] <cachio> line v
[12:16] <cachio> 1330
[12:16] <cachio> I though it was related to our configuration for the external backend
[12:16] <cachio> because it was not possible to reproduce on travis
[12:16] <cachio> using gce
[12:17] <cachio> but seems to be something else
[12:17] <ijohnson> yeah that seems to fail the same it's failing on travis now
[12:17] <ijohnson> the issue is that snapd.failure.service is not being started ever by systemd
[12:17] <cachio> the weird part is that when using the external backend the test is not failing 100% of the times
[12:17] <cachio> right
[12:18] <ijohnson> yes I don't think it is failing 100% of the time on travis either, indeed when I tried reproducing yesterday I didn't hit it
[12:18] <cachio> a time ago I shared more info about the error, I am trying to find it
[12:19] <cachio> I remember I sent the error to mvo
[12:20] <cachio> failover was trying to find core and core snap was not installed
[12:20] <cachio> ijohnson, but I cant find the logs
[12:20] <ijohnson> cachio: hmm that sounds different
[12:21] <cachio> the error is the same you see in the log I sent you
[12:21] <cachio> I'll reproduce it
[12:22] <cachio> and share the logs again, give me 15 minutes
[12:22] <zyga> google:ubuntu-18.04-64 .../tests/main/cgroup-tracking# test-snapd-sh.sh
[12:22] <zyga> $
[12:22] <zyga> google:ubuntu-18.04-64 .../tests/main/cgroup-tracking#
[12:22] <zyga> ^ getting this feels like this day is already worth it
[12:24] <ijohnson> thanks cachio
[12:25] <zyga> mborzecki: but it was worth reporting, it's a known problem
[12:25] <zyga> https://patchwork.kernel.org/patch/11343121/
[12:25] <zyga> and there's a patch
[12:28] <mvo> nice
[12:40] <mup> PR snapd#8156 opened: [RFC] cmd/snap-bootstrap: subcommand to detect if we want a chooser to run <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8156>
[12:41] <mborzecki> mvo: ^^ the key-watching thing
[12:41] <mborzecki> pedronis: mvo: we should probably discuss the naming there
[12:46] <zyga> oh
[12:46] <zyga> I wanted to mention that yesterday
[12:46] <zyga> about recovery and prompt and stuff
[12:46] <zyga> something to keep an open mind
[12:46] <zyga> smart IOT bulbs
[12:46] <zyga> do recovery
[12:46] <zyga> if ...
[12:46] <zyga> you turn them on and off five times in a row with specific time delay
[12:47] <zyga> our discussion about key detection feels incorrect
[12:47] <zyga> it should not be something we mandate
[12:47] <codingpanic> Hello all. I instaleld snapd on a raspbian based pi today. Unfortunately, none of the built-in interfaces/slots are available. What creates these?
[12:47] <pedronis> zyga: we don't mandate it, we need a reference experience
[12:48] <codingpanic> Since they dont exist, snaps are unable to connect to anything
[12:48] <ijohnson> codingpanic: did you install snapd as a deb pkg ?
[12:48] <codingpanic> ijohnson: yes
[12:48] <ogra> hrm
[12:48] <ogra> ubuntu@localhost:~$ snap version
[12:48] <ogra> snap    2.43.3+git1047.g6b52b37
[12:48] <ogra> snapd   unavailable
[12:48] <ogra> series  -
[12:48] <ogra> ubuntu@localhost:~$ snap list
[12:48] <ogra> error: cannot list snaps: cannot communicate with server: timeout exceeded while waiting for response
[12:48] <ogra> ubuntu@localhost:~$
[12:48] <ijohnson> codingpanic: what's `snap list` ?
[12:48] <ogra> ubuntu@localhost:~$ ps ax|grep snapd
[12:48] <ogra>  8932 ?        Ssl    0:00 /snap/snapd/6521/usr/lib/snapd/snapd
[12:48] <ijohnson> ogra: why did you break your snapd
[12:49] <ogra> this is how i found one of my qemu machines this morning
[12:49] <ijohnson> well don't leave it like that :-)
[12:49] <ogra> seems it got some reboot-triggering update yesterday evening
[12:49] <zyga> ogra: journalctl -u snapd.service
[12:49] <ijohnson> ogra: anything in the system journal for snapd?
[12:49] <codingpanic> pi@raspberrypi:/var/log $ snap list
[12:49] <codingpanic> Name     Version   Rev   Tracking  Publisher     Notes
[12:49] <codingpanic> core18   20200124  1671  stable    canonicalâ    base
[12:49] <codingpanic> scummvm  2.1.1     3126  stable    snapcrafters  -
[12:50] <codingpanic> I've also tried retroarch
[12:51] <zyga> codingpanic: snap install core
[12:51] <ogra> https://paste.ubuntu.com/p/xvRDVNPW4S/
[12:51] <ogra> the last part simply repeats over and over
[12:51] <zyga> codingpanic: it's a known bug
[12:51] <codingpanic> zyga: got it, thank you!
[12:51] <zyga> ogra: Feb 19 08:11:22 localhost snapd[824]: panic: cannot checkpoint even after 5m0s of retries every 3s: write /var/
[12:52] <zyga> ogra: did you run out of disk space
[12:52] <zyga> ?
[12:52] <codingpanic> zyga: that fixed it
[12:52] <ogra> zyga, bah, yeah
[12:53]  * zyga hugs ogra
[12:53] <zyga> been there done that (too many times)
[12:53] <zyga> I need a coffee
[12:53] <zyga> brb
[12:54] <ijohnson> pedronis: I need to run an errand right after SU (3:30 PM your time to be specific), can we put something on the calendar for 4:30 PM your time ?
[12:54] <ijohnson> zyga: I thought we fixed that bug though ?
[12:54] <zyga> ijohnson: no, that's a separate bug
[12:54] <zyga> ijohnson: look at snap list output
[12:54] <zyga> ijohnson: according to our design you have 0 interfaces in that case
[12:55] <zyga> ijohnson: you must get snapd or core
[12:55] <ijohnson> zyga: but I thought we fixed the bug where the core snap was not installed when you to go install only a snap with `base: core18` ?
[12:55] <zyga> ijohnson: also this is raspbian so probably runs an older copy
[12:55] <ijohnson> zyga: ah right yes probably older version of snapd with the bug still in place
[12:55] <zyga> yep
[12:56] <ijohnson> zyga: we should probably update snapd in raspbian, seems to happen somewhat frequently now I think
[12:56] <zyga> ijohnson: I don't think we can
[12:56] <zyga> ijohnson: we should update snapd in debian
[12:56] <zyga> it very old
[12:56] <ijohnson> zyga: who handles snapd update in debian?
[12:56] <zyga> nobody
[12:56] <zyga> us
[12:56] <zyga> sometimes
[12:56] <zyga> when $fire
[12:57] <ijohnson> also doesn't raspbian have it's own archives based on, but separate from debian? perhaps I'm misremembering
[12:57] <ogra> hrm ... freeing up 120MB and rebooting just gets me back to that state :/
[12:57] <zyga> ijohnson: it does
[12:57] <zyga> ijohnson: but we don't have any way to change it
[12:57] <ogra> bah ... because it is secretly upgrading ... it just rebooted again
[13:00] <ijohnson> hooray now ogra's ephemeral qemu VM is more secure
[13:07] <jdstrand> zyga: hey, fyi, https://github.com/snapcore/snapd/pull/7825#discussion_r381277068
[13:07] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[13:07] <zyga> hye
[13:07] <zyga> hey*
[13:07] <zyga> ack
[13:07] <zyga> I'm still looking into this
[13:07] <zyga> and especially what happened to your interactive blackbox testing
[13:10] <jdstrand> zyga: that's fine. I just wanted you to be aware of that weird thing I saw where I semi-started a transient unit and couldn't get it to go away in case it saves you some time
[13:11] <zyga> thank you
[13:12] <jdstrand> zyga: otoh, can you also make sure that these tests aren't skipped on core? you mentioned trusty but I thought I remembered something about user sessions on sore.... that said, xenial is starting systemd --user so hopefully it is all ok
[13:13] <zyga> jdstrand: I will
[13:13] <zyga> jdstrand: I  think this approach was picked specifically to support 16.04 desktop
[13:13] <jdstrand> that sounds familiar :)
[13:13] <jdstrand> that was a long time ago :)
[13:14] <jdstrand> zyga: fwiw, I'm really bought into the technique and like the PR overall :)
[13:14] <jdstrand> just need to make sure systemd does what we need everywhere
[13:14] <zyga> jdstrand: yeah, I just hope I didn't miss anything
[13:17] <jdstrand> zyga: I did notice yesterday that runc was using StartTransientUnit for at least something... could look there to build confidence. but one of the things I like about this is we are just asking systemd to take care of things for us. so long as we use the api correctly (which it appears you are), we should be good (barring bugs (systemd or otherwise))
[13:17] <zyga> jdstrand: the only thing I'm worried about is --user
[13:17] <zyga> the API is sold and supported for a long time
[13:17] <zyga> but user session is more complex
[13:17] <zyga> systemd --user is asked to stuff
[13:17] <zyga> but cannot
[13:17] <zyga> so asks system systemd to do it
[13:17] <jdstrand> zyga: kinda like how we ask it to manage starting and stopping services. we tell it a little bit and say "thanks for doing this for me!". same here
[13:17] <zyga> and that path I believe is somewhat new
[13:18] <zyga> I'm digging into this now
[13:18]  * jdstrand nods
[13:18] <jdstrand> zyga: well, it isn't *terribly* new if it is in bionic (I didn't test xenial), but there is definitely some different behavior
[13:19] <jdstrand> which might be cherrypicks, etc
[13:19] <zyga> I think it's all the way back to xenial, but give me a moment to debug it
[13:19] <jdstrand> zyga: we always have in out back pocket runtime detection and gracefully degrading too (not saying we need it yet)
[13:19] <jdstrand> s/in out/in our/
[13:20] <zyga> yes, it's not essential in a way
[13:22] <cachio> ijohnson, this is the output https://paste.ubuntu.com/p/qNnRgrHktg/
[13:22] <mvo> mborzecki: thanks, looking
[13:23] <cachio> from a local run on core-18
[13:23] <cachio> ijohnson, at the end you can see the issue that I raised a time ago snap-failure[9015]: cmd_snapd.go:124: restoring invoking snapd from: /snap/core/current/usr/lib/snapd/snapd
[13:23] <ijohnson> thanks cachio, I'm looking now
[13:24] <cachio> also the error snapd.service: Failed at step EXEC spawning /snap/snapd/x1/usr/lib/snapd/snapd: Exec format error
[13:25] <ijohnson> cachio: the EXEC spawning issue is very odd, because it should be x2 that has the Exec format error
[13:26] <jdstrand> zyga: so it is crystal clear: the reproducer is: take a desktop vm install, install snapd/enable the feature/blah, in the graphical session, open a terminal, use hello-world.sh/snap run --shell/etc and it works (find /sys/fs/cgroup -name '*.scope'). ssh in/console login and try the same and it doesn't (but not errors in SNAPD_DEBUG=1 or anywhere else I could find
[13:26] <jdstrand> )
[13:26]  * zyga nods
[13:26] <zyga> let me check that quickly
[13:26] <zyga> I was going via spread and I hit another issue there
[13:26]  * jdstrand nods
[13:27] <cachio> ijohnson, I have a debug session opened
[13:27] <cachio> ijohnson, if you need any output please tell me
[13:27] <jdstrand> I figured it might be easier to see what to recreate if you saw the problem
[13:27] <ijohnson> I think there is a known issue in that snap-failure should be more robust in trying to restart the socket, and isn't
[13:27] <ijohnson> cachio: ^
[13:27]  * jdstrand leaves zyga to it
[13:28] <ijohnson> cachio: sorry let me keep reading I'm not sure what I would like you to run in the debug session
[13:32] <zyga> jdstrand: wwo
[13:32] <zyga> jdstrand: so
[13:32] <zyga> jdstrand: it works on a fresh install of bionic
[13:32] <zyga> jdstrand: desktop session
[13:32] <zyga> jdstrand: I recorded bustle (dbus traffic analyzer) dumps
[13:32] <jdstrand> zyga: right, in the desktop session, it works
[13:33] <zyga> and even confirmed it the simple way
[13:33] <zyga> https://www.irccloud.com/pastebin/pENvRQqK/
[13:33] <zyga> oh? I missed that
[13:33] <zyga> when didn't it work?
[13:33] <jdstrand> zyga: ssh in or do console login and it doesn't
[13:33] <zyga> ah
[13:33] <zyga> I see
[13:33] <zyga> okay that's much clearer now
[13:33] <zyga> thanks, I'll focus on that
[13:33] <jdstrand> zyga: that is what made it tricky for me to diagnose :)
[13:33] <zyga> jdstrand: but I'm 99% sure it's because there's no session bus there
[13:33] <zyga> and this is a dbus interaction
[13:34] <jdstrand> zyga: I saw systemd --user started with just ssh
[13:34] <zyga> jdstrand: ok, I'll debug both cases (console login and ssh)
[13:34] <zyga> jdstrand: were you logging into the same user as the interactive session?
[13:34] <zyga> jdstrand: or another user
[13:34] <jdstrand> zyga: but yeah. maybe there is an activation thing or something. idk
[13:34] <jdstrand> I sopped looking when I ran out of day
[13:34] <jdstrand> stopped
[13:34] <zyga> ok
[13:34] <zyga> I'll explore those
[13:35] <zyga> because previously it was a bit magic
[13:35] <jdstrand> zyga: I was
[13:35] <zyga> as to why it worked in places I checked
[13:35] <jdstrand> (same user)
[13:35] <zyga> ok
[13:35] <zyga> that would explain the systemd --user aspect
[13:36] <jdstrand> zyga: well, no. I logged into core a few minutes ago before asking about adding uc tests and there was --user
[13:36] <zyga> jdstrand: ok, please give me a day to get to the bottom of this
[13:36] <zyga> jdstrand: if you could review any of the other PRs I mentioned I could perhaps make progress on those
[13:36] <zyga> jdstrand: but for this one, I know what to do
[13:36] <jdstrand> that doesn't mean there is a dbus session bus...
[13:36] <zyga> jdstrand: right
[13:36] <jdstrand> yes, that was the plan
[13:36] <zyga> jdstrand: perhaps 18.04 doesn't have enough activation
[13:36] <zyga> testing is paramount
[13:37] <zyga> I'll try to cover those
[13:37]  * jdstrand nods
[13:42] <sdhd-sascha> mvo: fyi. github runner tries to create config files in the binary directory. This needs to be fixed first. Seems to be hardcoded path's.
[13:42] <sdhd-sascha> https://github.com/sd-hd/runner-snap/releases
[13:43] <zyga> jdstrand, mvo: fyi https://github.com/snapcore/snapd/pull/7825#discussion_r381296772
[13:43] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[13:46] <mvo> zyga: 0.05s? that is not bad :)
[13:48] <zyga> mvo: that's wall clock time
[13:48] <zyga> mvo: the actual new code is 1ms
[13:57] <ogra> you have a wall clock that measures 0.05s ?!?
[13:58] <roadmr> ogra: well if you look hard enough a lot of wristwatches measure 0.25s (seconds hand moves at 4hz)
[13:58] <roadmr> that's mechanical wind-up wristwatches mind you
[13:58]  * roadmr now looks really old and anachronistic ⌚
[14:00] <ogra> haha, yeah
[14:08] <zyga> jdstrand: reproduced
[14:08] <zyga> https://www.irccloud.com/pastebin/lg1cEV4Q/
[14:08] <zyga> jdstrand: ^ that's bionic over ssh as user
[14:08] <zyga> jdstrand: running systemd-run --user --scope ls
[14:09] <zyga> jdstrand: on the up side, I now have systemd --user running as my user (remote ssh activated it)
[14:09] <zyga> jdstrand: on the down side, no idea why it failed yet
[14:09] <zyga> but I can dig
[14:10]  * jdstrand nods
[14:10] <jdstrand> I <3 reproducers
[14:10] <zyga> jdstrand: but that's really weird, raspbian (older) works okay
[14:10] <zyga> jdstrand: but I'll dig
[14:12] <zyga> jdstrand: I'll check 20.04 and 16.04 as well
[14:12] <zyga> jdstrand: _complexity_ :)
[14:14] <jdstrand> zyga: yes. hopefully it isn't too deep (I recall how the snap_daemon spun out cause of bugs, bugs, bugs. I hope very much that isn't the case here (I don't think it is))
[14:16] <zyga> I think it's just configuration (famous last words?)
[14:18] <mborzecki> jdstrand: zyga: your ssh shell should already be part of a user slice/session scope (?)
[14:18] <zyga> it is
[14:19] <mborzecki> zyga: same when you log in on a tty, though no clue who arranges that, pam & logind maybe?
[14:19] <mborzecki> s/who/what/
[14:20] <zyga> mborzecki: the problem is why remote cannot systemd-run
[14:20] <zyga> smells like polkit to me
[14:20] <zyga> I'll look after the standup
[14:23] <mborzecki> hmm hmm intersting
[14:23] <roadmr> jdstrand, pedronis : is there a non-system-files interface that would allow write access to /etc/ssh/ssh{,d}_config ?
[14:24] <roadmr> if not, is it acceptable to grant system-files in this case (it's a device-specific snap in a brand store, so mostly well-scoped)
[14:30] <zyga> mborzecki: it's polkit
[14:30] <zyga> mborzecki: give me a while to get the bits in place
[14:30] <mborzecki> zyga: polkit?
[14:30] <zyga> yep
[14:30] <zyga> it's always polkit ;)
[14:30] <mborzecki> it's always /pluseaudio/polkit/snapd/
[14:30] <mborzecki> heh forgot systemd
[14:35] <zyga> I need to take the dog out
[14:38] <roadmr> who let the dogs out? woof wof...
[14:42] <mborzecki> zyga: doesn't look like polkit to me
[14:42] <mborzecki> openat(AT_FDCWD<EMAIL_ADDRESS>O_WRONLY|O_NOCTTY|O_CLOEXEC)
[14:42] <mborzecki> = 34
[14:42] <mborzecki> fcntl(34, F_GETFL)                      = 0x8001 (flags O_WRONLY|O_LARGEFILE)
[14:42] <mborzecki> write(34, "2821\n", 5)                  = -1 EACCES (Permission denied)
[14:42] <mborzecki> uh, w8 that's on focal ;)
[14:46] <mborzecki> hm weird, there's this sequence
[14:46] <mborzecki> openat(AT_FDCWD<EMAIL_ADDRESS>O_WRONLY|O_NOCTTY|O_CLOEXEC)
[14:46] <mborzecki> = 30
[14:46] <mborzecki> write(30, "2504\n", 5)                  = -1 EACCES (Permission denied)
[14:47] <mborzecki> close(30)
[14:47] <mborzecki> followed by opening *.scope directory and getdents()
[14:48] <mborzecki> anyways, the message is Failed to add PIDs to scope's control group: Permission denied which kind of makes sense in this context
[14:53] <zyga> re
[14:53] <zyga> mborzecki: which systemd is that?
[14:54] <zyga> ah, focal
[14:54] <zyga> mborzecki: systemd --user should ask system to to that write
[14:54] <zyga> mborzecki: that's what I read from sources
[14:54] <zyga> mborzecki: anyway, I'll keep digging
[15:01]  * zyga went outside for a moment and finally cooled the fever of his laptop while using google meet
[15:02] <pedronis> roadmr: I don't think there is one atm
[15:03] <roadmr> pedronis: :( any objections with using system-files for this then?
[15:03] <pstolowski> mvo:  thanks for the suggestion re version check!
[15:05] <zyga> dns timeouts ugh
[15:05] <zyga> Feb 19 07:03:47 bionic systemd-resolved[618]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server <IP_ADDRESS>.
[15:05] <pedronis> roadmr: no deep objections as long it's scoped, we might add something like sshd-control at some point but not immediately
[15:06] <jdstrand> roadmr (cc pedronis): there isn't one. if this is in a brand store, 'no', but they can certainly hurt themselves
[15:06] <jdstrand> pedronis: I might suggest 'snap set core' things instead of sshd-control
[15:07] <pedronis> jdstrand: yea, but we need clear use cases
[15:07] <pedronis> to get tehre
[15:07] <pedronis> get there
[15:07] <jdstrand> yes
[15:08] <jdstrand> pedronis: they can be added one by one to snap set. sshd-control is risky and security sensitive
[15:08] <jdstrand> imho
[15:08] <pedronis> jdstrand: I understand, the surface of the config is large though
[15:08] <jdstrand> roadmr: but yeah, no objections for system-files in a brand store so long as they know the risk
[15:08] <pedronis> anyway not something we'll do soon
[15:08]  * jdstrand nods
[15:08] <roadmr> jdstrand: yep, like pedronis said this can be scoped to the specific store to limit risk. I can tell them there is indeed a risk so they are super aware
[15:09] <roadmr> thanks jdstrand pedronis
[15:09] <pedronis> roadmr: but if they can tell use what kind of config they are changing it could help us design something later
[15:09] <pedronis> s/use/us/
[15:09] <roadmr> pedronis: sure thing, I'll also ask
[15:10] <pedronis> roadmr: thx
[15:44] <zyga> jdstrand: FYI https://github.com/snapcore/snapd/pull/7825#discussion_r381360336
[15:44] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[15:44] <zyga> github is kind of slow for me today
[15:44] <zyga> but new notifications are really cool, a big improvement over YOU HAVE NAN NOTIFICATIONS
[15:45] <jdstrand> github is both slow and broken for me today
[15:45] <jdstrand> 500 on the above url
[15:45] <zyga> also 500 often
[15:45] <zyga> haha
[15:45] <zyga> yeah, just reload a few times
[15:45] <zyga> it works eventually
[15:45] <jdstrand> not able to expand resolved conversations...
[15:45] <zyga> jdstrand: at some point we can say that github is slow because new core snap refreshes ;-)
[15:46] <jdstrand> heh
[15:46] <zyga> jdstrand: the comment says that cgroup v2 doesn't have pids, it's just one big flat tree
[15:46] <zyga> jdstrand: in v1 we _could_ scope it but current code doesn't require it
[15:46] <zyga> jdstrand: scoping it mainly requires us to know more about systemd, we could do it at a low cost but I deem it non-essential now
[15:46] <zyga> jdstrand: certainly something we can improve ahead of making this stable
[15:47] <zyga> jdstrand: I don't know how you develop locally but I find a desktop (workstation) installation (vm) of fedora 31 is very useful for exploring a full complex system that uses pure v2 mode
[15:52] <jdstrand> zyga: I obviously need some practical v2 experience since I can never remember how the layout is. I occasionally have a fedora vm, but I find by the next time I need to look at fedora, the one I have is eol ;P
[15:52] <jdstrand> zyga: I replied
[15:52] <zyga> jdstrand: :)
[15:55] <ijohnson> okay I think that I have the snapd-failover test working again
[15:55] <ijohnson> will push my fix up
[15:55] <zyga> ijohnson: great news
[15:55] <pedronis> great
[15:55] <zyga> ijohnson: cannot wait to see what it was
[15:56] <ijohnson> StartLimitInterval{,Sec}=0 doesn't play well with OnFailure, because the OnFailure only runs after the unit is in "totally really absolutely failed" state, which systemd only considers after it has exhausted the start limits
[15:57] <ijohnson> so in our spread tests we specifically set StartLimitInterval=0, which breaks the OnFailure
[15:57] <roadmr> jdstrand: how can I combine allow-installation constraints? I have used "on-store" by itself, and "plug-attributes" by itself but for this one I need both to apply (ANDing them). I can provide both snap.yaml and my partial snap-decl plugs thingy
[15:57] <ijohnson> It's unclear why this broke now, I think it may have been a systemd bug that this test worked at all on spread before, and they just now fixed the bug that makes it resiliently fail
[15:59] <jdstrand> roadmr: please supply both. feel free in privmsg
[15:59] <roadmr> jdstrand: coming up!
[16:01] <ijohnson> cachio: zyga: mvo: can y'all (re-)review #8155? I think the test is fixed now, but I want to be sure that there's not unintended consequences to setting StartLimitInterval=100
[16:01] <mup> PR #8155: tests: mv ubuntu-core-snapd{,-failover} to core/ suite <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8155>
[16:01] <zyga> y
[16:02] <zyga> another new github feature? https://usercontent.irccloud-cdn.com/file/m2oxIZH8/Zrzut%20ekranu%202020-02-19%20o%2017.02.13.png
[16:04] <mborzecki> zyga: the first bit was from focal, the sencod from bionic
[16:04] <zyga> ijohnson: I cannot find StartLimitInterval documentation
[16:04] <zyga> ijohnson: but there is StartLimitIntervalSec
[16:04] <zyga> ijohnson: and also StartLimitIntervalBurst
[16:04] <ijohnson> zyga: it was renamed to StartLimitIntervalSec in systemd 230 I think
[16:04] <zyga> ijohnson: are both names supported?
[16:05] <ijohnson> zyga: I'm pretty sure, but let me double check
[16:08] <zyga> ijohnson: interesting, I would love to understand why it worked before
[16:08] <zyga> ijohnson: perhaps there's more to it than that
[16:08] <zyga> ijohnson: I think that the explanation on how the value 0 interacts with OnFailure is good but I need to cross check it with documentation
[16:09] <ijohnson> leonard has some comments on bug reports explaining the interaction, does that count :-)
[16:09] <ijohnson> zyga: see comment 7 https://bugs.freedesktop.org/show_bug.cgi?id=87799
[16:10] <ijohnson> but then of course see comment 8 right below it :-)
[16:12] <zyga> ijohnson: indeed, we should reference in the code there
[16:12] <zyga> https://bugs.freedesktop.org/show_bug.cgi?id=87799#c7
[16:12] <ijohnson> should we add a comment in the code or the commit message ?
[16:12] <cachio> ijohnson, nice, reviewing it
[16:12] <zyga> in the code I think
[16:12] <zyga> easier to keep track of
[16:12] <ijohnson> hmm I guess if it was in the override I would have seen it much quicker in the running system
[16:13] <ijohnson> yeah good point I'll add it to the code
[16:17] <pedronis> pstolowski: I re-reviewed 8130
[16:18] <pstolowski> pedronis: just saw it, thank you!
[16:21] <ijohnson> okay I have it added to the override unit we put in the spread image, I will put it in a followup PR so that as soon as this one is green we can merge
[16:29] <pstolowski> ijohnson: can you take another look at #8003 when you have a moment?
[16:29] <mup> PR #8003: o/ifacestate, api: implementation of snap disconnect --forget <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8003>
[16:29] <ijohnson> pstolowski: I'll try to look this afternoon or tomorrow morning
[16:32] <pstolowski> thx
[16:32] <zyga> ijohnson: reviewed, please look
[16:32] <zyga> I'll be back shortly
[16:38] <ijohnson> zyga: it looks like StartLimitInterval is only valid in [Service] in systemd 229 and below, and for systemd 230 and above, StartLimitInterval is supported in systemd 230+ in [Service], but StartLimitIntervalSec is only supported in [Unit], so we are fine to keep using StartLimitInterval in [Unit] like the test does
[16:38] <ijohnson> see https://lists.freedesktop.org/archives/systemd-devel/2017-July/039255.html, but this is poorly documented in systemd docs
[16:38] <ijohnson> zyga: how would you like me to document that in the PR?
[16:40] <ijohnson> zyga: see the corresponding commit too https://github.com/systemd/systemd/commit/f0367da7d1a61ad698a55d17b5c28ddce0dc265a
[17:01] <zyga> ijohnson: a code comment will suffice
[17:01] <zyga> I just felt it is a bit too magic to leave as-is
[17:03] <mup> PR snapcraft#2948 opened: Regenerate the GDK pixbuf loaders cache file if for whatever reason it isn't there (LP: #1863801) <Created by oSoMoN> <https://github.com/snapcore/snapcraft/pull/2948>
[17:03] <ijohnson> zyga: a follow-up okay for the comment then?
[17:05] <zyga> ijohnson: is it green now?
[17:06] <ijohnson> Ah debian seems unhappy now
[17:07] <roadmr> 😞  <- debian
[17:08] <cwayne> I love how roadmr is just like the dad of all IRC channels
[17:08] <roadmr> I am everywhere.
[17:08] <roadmr> Iam inevitable 👌
[17:08]  * zyga needs a nap
[17:09] <zyga> ijohnson: feel free to discard my review and land with a comment
[17:09] <zyga> I will be back in 2 hours
[17:09] <zyga> So sleepy now
[17:30] <mup> PR snapd#8157 opened: tests: using google storage when downloading ubuntu cloud images from gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8157>
[17:43]  * cachio afk
[17:43] <cachio> going to the doctor
[19:22] <zyga> re
[19:22] <zyga> *ah, I needed that*
[19:23] <zyga> so now nfs-support fails
[19:24] <zyga> ijohnson: do you think that is related to the change?
[19:24] <zyga> that's an 18.04 failure
[19:24] <zyga> but actually, not
[19:24] <ijohnson> zyga: yes I noticed now that fails on the PR
[19:24] <ijohnson> zyga: I have a fix for that
[19:24] <zyga> across the board
[19:24] <zyga> do you know what happened?
[19:24] <ijohnson> I was setting StartLimitInterval wrong, that's just the, well, interval, not the number of times starts can happen
[19:24] <ijohnson> StartLimitBurst is the number of times it can start
[19:25] <zyga> aha
[19:25] <zyga> ok, let's try that
[19:25] <ijohnson> So I changed it to set both StartLimitBurst and StartLimitInterval and now it's good
[19:25] <ijohnson> let me push it up
[19:25] <zyga> thanks!
[19:25] <ijohnson> was in the middle of UC20 debugging
[19:25] <zyga> no worries, I just woke up
[19:39] <mup> PR snapcraft#2949 opened: Fix clean on Windows <Created by NickZ> <https://github.com/snapcore/snapcraft/pull/2949>
[19:55] <mup> PR snapd#8158 opened: tests: disable archlinux system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8158>
[19:56] <ijohnson> cachio: should we use the no-spread label on that PR?
[20:05] <mup> PR snapd#8158 closed: tests: disable archlinux system <Skip spread> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8158>
[21:16] <mup> PR snapcraft#2933 closed: remote-build: introduce --launchpad-snapcraft-channel option <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2933>
[23:36] <mup> PR snapd#8159 opened: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>