[00:00] <hackeron> Whoops, sorry that should be Chipaca
[07:28] <zyga> good morning!
[07:29] <zyga> Caelum: hey
[07:30] <zyga> Caelum: to answer your question, snappy used to do that in 15.04 days
[07:30] <zyga> Caelum: snappy used a/b updates exclusively
[07:30] <zyga> Caelum: but this method used way too much space
[07:31] <zyga> Caelum: snappy now uses a single writable space and can use any rootfs and kernel without unpacking them, if the architecture supports that
[07:31] <zyga> Caelum: so we can have any number of new core snaps, new kernel and new gadgets to test
[07:32] <zyga> Caelum: and choose the one to run in the boot loader
[07:32] <zyga> Caelum: this is especially important on devices with very littte storage
[07:32] <zyga> Caelum: but in general it means that you have all the space to use
[07:32] <zyga> Caelum: and as for mender, you can ask mborzecki next week, he used to work on mender before he joined canonical
[07:37] <zyga> hackeron: ^
[07:37] <zyga> hackeron: sorry, I'm not really awake yet it seems, this was the answer for your questions
[07:38] <zyga> hackeron: the way we can do this is that the boot loader can pick wich kernel to load and in turn the kernel can pick (based on bootloader data) which rootfs to mount (from squashfs)
[07:59]  * zyga -> breakfast
[09:19] <jamesh> zyga: hi.  w.r.t. my document-portal branch, the main issue at the moment is how to handle systems without the document portal available.  I don't want snapd trying to create missing directories, so what do you think of an extra mount option to tell it to ignore when there is a missing source path? (and maybe target path?)
[09:20] <zyga> hmm
[09:20] <zyga> x-snapd.no-create-{source,target} ?
[09:20] <zyga> something like this?
[09:20] <jamesh> I was just thinking of x-snapd.ignore-missing
[09:20] <jamesh> but no-create could work too
[09:21] <zyga> or x-snapd.skip-if-missing
[09:21] <zyga> something appropriate
[09:21] <zyga> but yeah, +1 on the idea
[09:21] <zyga> I'm wondering what's wrong with CI
[09:21] <zyga> everything is read
[09:21] <zyga> red
[09:21] <jamesh> I'm thinking doing the check on the source only would be sufficient
[09:21] <zyga> for this case, yes
[09:22] <jamesh> this could also be used for the host font mounts, where we currently check if the various font directories exist on the host before adding the mount entries
[09:22] <jamesh> we could just add them unconditionally with the ignore-missing option
[09:25] <zyga> yeah, that's a nice cleanup
[09:27] <jamesh> zyga: btw, CI finally passed on https://github.com/snapcore/snapd/pull/5082
[09:27] <mup> PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082>
[09:28] <zyga> did it pass just now?
[09:28] <jamesh> that was from earlier today
[09:28] <jamesh> 2 hours ago according to Travis
[09:28] <zyga> hmm, let's hope that whatever was slower/wrong is fixed now
[09:29] <zyga> I saw that some branches exceeded 49 minute mark
[09:29] <zyga> perhaps store downloads are much slower (or were) lately
[09:29] <jamesh> I haven't tried to prod https://github.com/snapcore/snapd/pull/5116 again: last time it failed with the debian backend timing out
[09:29] <mup> PR #5116: interfaces: move host font update-ns AppArmor rules to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5116>
[09:29] <jamesh> It's probably okay though
[09:34] <mup> PR snapd#5124 opened: many: add `snapd.seeded` service <Created by mvo5> <https://github.com/snapcore/snapd/pull/5124>
[09:45] <Odd_Bloke> \o/
[10:37] <doko> mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dpkg snapd autopkg test failures
[11:08] <cachio_> Chipaca, I have updated the arch image to avoid this problem when rebooting
[11:08] <Chipaca> cachio_: what was the issue?
[11:08] <cachio_> I found an issue in the snapd test code doing that
[11:08] <cachio_> the issue that the google shutdown script hungs
[11:09] <cachio_> more than 30 minutes when the machine is shuting down
[11:11] <cachio_> Chipaca, we don't configure that shutdown script, it already comes with the image and we don't use it
[11:11] <Chipaca> cachio_: and the state error?
[11:12] <cachio_> Chipaca, still working on the other error where snapd does not start properly after reboot
[11:12] <Chipaca> cachio_: ah ok
[11:13] <Chipaca> cachio_: i thought it was that one that you'd figured out :-D
[11:13] <cachio_> there are 2 issues around arch
[11:13] <Chipaca> cachio_: 1. ar, 2. ch
[11:13] <Chipaca> ?
[11:13] <cachio_> Chipaca, no, the other one
[11:13]  * Chipaca hides
[11:14] <mup> PR snapd#5125 opened: spread: add adt for ubuntu 18.10 <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5125>
[11:14] <cachio_> the other was more important beause it could leave headless machines also preparing the test suite because arch is also rebooted there
[11:15] <Chipaca> cachio_: and it gets expensive, also
[11:15] <cachio_> yes
[11:16] <cachio_> Chipaca, then I found our test code fails when we have an arch image which has not any package to install during the upgrade
[11:16] <cachio_> I need to talk to maciej about this
[11:17] <zyga> doko: addressed in master,
[11:24]  * Chipaca -> lunch, probably
[11:27] <zyga> Chipaca: #5125
[11:27] <mup> PR #5125: spread: add adt for ubuntu 18.10 <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5125>
[11:35] <mup> PR snapd#5126 opened: cmd/snap-update-ns: add support for ignoring mounts with missing source/target <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5126>
[11:36] <jamesh> zyga: ^^^ here's a branch implementing the ignore-missing logic
[11:36] <zyga> jamesh: ack, thank you
[11:42] <zyga> jamesh: reviewed
[11:45] <jamesh> zyga: thanks.  I've made the change
[11:45] <cachio_> Chipaca, https://paste.ubuntu.com/p/gcGHFVYYmf/
[11:45] <cachio_> Service hold-off time over, scheduling restart
[11:46] <cachio_> it is taking few minutes to start after reboot and I see this log
[11:46] <Chipaca> cachio_: the hold off is set to 0, ie no hold off afaik
[11:46] <Chipaca> cachio_: snapd is crashing
[11:47] <Chipaca> or otherwise not happy
[11:48] <cachio_> Chipaca, :(
[11:48] <Chipaca> cachio_: question is, why don't we see the debug messages
[11:48] <cachio_> I'll increase the journlal log to degug
[11:48] <Chipaca> cachio_: SNAPD_DEBUG=1 is set, right? (in the .conf.d thing
[11:48] <cachio_> yes
[11:48] <Chipaca> so we should be seeing them
[11:48] <Chipaca> ah, i don't know how our debug interops with journald's
[11:49] <Chipaca> anyway, i need to get lunch
[11:49] <cachio_> Chipaca, sure
[11:49] <Chipaca> bbiab
[11:49] <cachio_> enjoy it
[11:54]  * cachio_ afk
[11:58] <doko> zyga: I don't care, I need it in cosmic
[11:58] <doko> will haress mvo in person ... ;p
[12:03] <zyga> doko: is c- named now?
[12:13] <jamesh> zyga: I'm knocking off for the day.  I think all my PRs except the xdg-document-portal one (i.e. #5082, #5116, and #5126) should be ready to land if you're happy with the code.
[12:13] <mup> PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082>
[12:13] <mup> PR #5116: interfaces: move host font update-ns AppArmor rules to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5116>
[12:13] <mup> PR #5126: cmd/snap-update-ns: add support for ignoring mounts with missing source/target <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5126>
[12:14] <zyga> yeah, I really hope to get some 2nd review but today may be tough
[12:14] <zyga> thank you for this! it's very close to being all in
[12:15] <jamesh> yeah.  There's probably some more stuff needed to get portals working really well, but I think we're reaching the end of the mount related parts
[12:15] <jamesh> you've been a great help with all this
[12:18] <jdstrand> niemeyer: hey, the forum seems to be down
[12:20] <jdstrand> zyga: can you tg niemeyer? ^
[12:20] <zyga> ack
[12:20] <jdstrand> thanks
[12:21] <niemeyer> Will look into it
[12:22] <niemeyer> Seems back
[12:22] <niemeyer> jdstrand, zyga: ^
[12:22] <zyga> confirmed
[12:23] <doko> let's make it cockroach
[12:24] <jdstrand> huh, weird
[12:24] <jdstrand> niemeyer: it does indeed seem to be working again. it was several pages in the span of a few minutes
[12:24]  * jdstrand is curious if the snap got upgraded
[12:24] <niemeyer> jdstrand: Might have been a forced reboot
[12:39] <zyga> Chipaca: standup today?
[12:40] <zyga> my daughter just asked me to go to a coffee shop for a shake
[12:40] <Chipaca> zyga: I don't have anything
[12:40] <zyga> I'm preparing some code for next week
[12:40] <zyga> and I'm looking at the forum, one case is interesting again
[12:40] <zyga> the lowercase vs uppercase bug
[12:44] <mup> PR snapd#5125 closed: spread: add adt for ubuntu 18.10 <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5125>
[12:47]  * zyga preps laptop for the move
[13:18] <zyga> re
[13:19] <zyga> organizing kids == going into production :)
[13:36] <mup> PR snapd#5127 opened: HACKING: fix typos <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5127>
[13:38]  * zyga removed a bucket load of stale braches
[13:40] <Son_Goku> zyga, it looks like snappy is finally getting looked at in opensuse-factory
[13:40] <Son_Goku> in the ML
[13:41] <zyga> Son_Goku: oh, I need to check then
[13:41] <zyga> I have to file some bugs but I was looking for someone that would be interested in guiding me from the other end, I think we may finally got that
[13:42] <Son_Goku> zyga, well, I could have helped you too :P
[13:42] <Son_Goku> I've gotten my fair share of packages in openSUSE :)
[13:42] <zyga> Son_Goku: you _always_ help :-)
[13:42]  * zyga hugs Son_Goku 
[13:42] <zyga> thank you
[13:42] <zyga> and I'm sorry about that vodka
[13:42] <Son_Goku> haha
[13:42] <Son_Goku> it only took you a year to apologize :P
[13:43] <zyga> I was secretly hoping you would enjoy it after some time
[13:43] <Son_Goku> yeah, that didn't happen
[13:44] <zyga> Son_Goku: the systemd unit thing is a clear win for presets
[13:44] <Son_Goku> yes
[13:45] <Son_Goku> but fortunately that's easy to do
[13:45] <Son_Goku> we've done that rodeo before
[13:45] <zyga> Son_Goku: the rpmlint thing is a two fold case: one is easy (I suspect) - the polkit side
[13:45] <zyga> the other one is probably just us aking and waiting but I don't know
[13:45] <Son_Goku> Simon let me know that the FHS compliance check in rpmlint is going to turn from a warning to an error soon
[13:45] <Son_Goku> it's technically an error by policy
[13:45] <zyga> the /snap thing is something I'd like not to change and I would argue that it makes sense to do FHS aside (until FHS allows for /snap eventually when everyone will say "of course it should be /snap, read the FHS man" ;-)
[13:46] <zyga> Son_Goku: it's all about what suse wants
[13:46] <zyga> if they want it in, that's in
[13:46] <Son_Goku> what I never understood is why wasn't it /run/snap/ for snap mounts?
[13:46] <Son_Goku> the mounts are managed as systemd units, so they come up early enough anyway
[13:48] <zyga> Son_Goku: it could be but that's not what (I think) this is about
[13:48] <zyga> it's about the /snap being a first-class concept and the /snap/bin launchers being visible easily
[13:49] <zyga> Son_Goku: even with /run/snap/ with mount points, you need /snap/bin
[13:49] <Son_Goku> ah, right, you need a persistent place for the bin files
[13:49] <zyga> and the concept can be grown, maybe we will do /snap/man/
[13:49] <Son_Goku> that's why we put it in /var/lib/snapd/snap
[13:49] <Son_Goku> I feel like maybe we should split the two
[13:49] <zyga> yeah, which is a "unnice" place because it is "far", I think this is just that
[13:50] <zyga> Son_Goku: splitting it out would be fine IMO
[13:50] <zyga> they are managed by one variable today
[13:50] <zyga> but it should be non-painful to fix
[13:50] <Son_Goku> the location where the mounts are and where the persistent files are would make it better
[13:50] <Son_Goku> and less dumb for other reasons
[13:50] <zyga> what may be more painful is that snapd doesn't manage exisitng mount units
[13:50] <zyga> it doesn't update them in place
[13:50] <zyga> I would say that this is a prerequisite
[13:50] <Son_Goku> doesn't that happen on snap refresh?
[13:50] <zyga> it does
[13:51] <Son_Goku> we could force a refresh on upgrade
[13:51] <zyga> but it also affects unit names
[13:51] <Son_Goku> to migrate all the units
[13:51] <zyga> we would need some non-trivial code to get the transition correctly
[13:51] <Son_Goku> hmm
[13:51] <zyga> (should I stop snap-$SNAP_NAME-$SNAP_REVISION.mount
[13:51] <Son_Goku> maybe a helper program that would be executed for migrating legacy locations to the new split layout?
[13:51] <zyga> or that other ting)
[13:51] <zyga> well
[13:51] <zyga> in all cases
[13:51] <zyga> I think it sucks because it's a transition
[13:51] <zyga> and it can go south on us
[13:52] <Son_Goku> historically, transitions aren't handled very well in snapd :/
[13:52] <zyga> so I'd really do something this cosmetic only iff we had a solid framework for altering those units correctly
[13:52] <Son_Goku> right
[13:52] <Son_Goku> we probably should have it for other reasons
[13:52] <zyga> well, it depepnds on which one but yeah, it's complex to do
[13:52] <zyga> offtopic
[13:53] <zyga> deja-dup / duplicity suck at backups
[13:53] <zyga> they are so worthless I cannot believe there's nothing better that's also simple
[13:53] <zyga> I'm trying to backup while on my LTE data
[13:53] <zyga> and so far I'm streaming the backup back here
[13:53] <zyga> to "compare"
[13:53] <zyga> how moronic is that
[13:53] <zyga> it's been going on for an hour at least
[13:54] <Son_Goku> there's definitely good backup solutions
[13:54] <Son_Goku> I'd probably agree those two aren't it
[13:54] <zyga> Anything that is nice on a laptop and not highly complex?
[14:01] <popey> restic?
[14:05] <zyga> restic?
[14:06] <popey> snap install restic ;)
[14:06] <popey> https://restic.net/
[14:07] <popey> "Backups done right!" (apparently)
[14:19] <popey> cjwatson: I have a snap which appears to have gotten wedged in launchpad https://launchpad.net/~build.snapcraft.io/+snap/4b4138ec2bc6c3cd4339177e27938c64-xenial/+build/208186
[14:19] <popey> it says it's been building for 22 hours.  but looks stuck
[14:23] <kyrofa> zyga: I've been pretty impressed with the nextcloud clients
[14:23] <cjwatson> popey: I've cancelled it to free up the builder, but I don't know what the actual problem is
[14:24] <popey> I'll re-trigger if that's okay, to see if it was a one-time thing?
[14:30] <zyga> kyrofa: thanks for the advice
[14:31] <zyga> Texting while riding a bike is not safe
[15:45] <zyga> re
[16:27] <popey> diddledan: we're looking into the gimp 2.8 issue
[16:27] <mup> PR snapcraft#2120 closed: many: dedup environment entries <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2120>
[16:32] <popey> zyga: how can i find the revision number for a previous release of core, I'm trying to debug something and need to go backwards
[16:32] <zyga> popey: AFAIK you cannot easily
[16:32] <popey> that is frankly insane
[16:32] <zyga> popey: snap list --all
[16:32] <zyga> if you have it
[16:33] <zyga> if you are a contributor you can see the channel map
[16:33] <diddledan> what's the issue, popey ?
[16:33] <zyga> but there is no easy nice history
[16:33] <popey> gimp wont launch at all anymore
[16:33] <diddledan> oh
[16:33] <zyga> !
[16:33] <diddledan> fudge
[16:33] <popey> https://github.com/snapcrafters/gimp/issues/17
[16:33] <diddledan> I'm currently working on getting 2.10 building
[16:33] <popey> broken on 16.04, 17.10, 18.04. All on 2.32.5
[16:33] <popey> and I want to roll back to .4 but see no easy way to do that
[16:34] <zyga> popey: if you have it locally you can rollback
[16:34] <zyga> if you don't you cannot
[16:34] <zyga> .4 and .5 differ a bit
[16:34] <popey> this is not optimal behaviour
[16:34] <zyga> .5 and .6 a little
[16:34] <diddledan> can we just add the gtkrc file into the build (don't unstage it)
[16:34] <zyga> popey: this is the design
[16:34] <zyga> popey: unless you are a snap owner
[16:34] <popey> I _think_ core 4452 is amd64 2.32.4
[16:35] <popey> so how do I debug this?
[16:35] <zyga> no idea actually
[16:35] <zyga> do you have .4 on disk?
[16:35] <zyga> if not you cannot do it
[16:35] <popey> no
[16:36] <popey> i (as a reviewer) can find the snap in the store and manually download it
[16:37] <popey> ok, done it
[16:37] <popey> gimp works fine on 2.32.4, 2.32.5 broke it
[16:38] <popey> perhaps we were unfortunately relying on broken behaviour in 2.32.4 and that got 'fixed' in 2.32.5?
[16:38] <zyga> popey: hmm
[16:39] <zyga> http://people.canonical.com/~mvo/core-changes/html/stable/2.32.3r4407_2.32.5r4486.html
[16:39] <zyga> .4 was not published, was it?
[16:39] <zyga> 4->5 change was AFAIK tiny
[16:40] <popey> shall i file a bug in snapd?
[16:40] <zyga> please
[16:42] <zyga> popey: I bet it is something else
[16:42] <zyga> .4 and .5 are the same really
[16:42] <zyga> it must be something else that is changing
[16:45] <popey> well, it's something in between revision 4452 and 4486
[16:46] <popey> https://bugs.launchpad.net/snapd/+bug/1769210
[16:46] <mup> Bug #1769210: snapd 2.32.5 broke gimp <snapd:New> <https://launchpad.net/bugs/1769210>
[17:00] <diddledan> gimp is working for me on 2.32.5
[17:01] <popey> wat
[17:02] <diddledan> somehow the error message refers to files which are in a different location - it's trying to copy files from $SNAP/usr/etc when they're installed to $SNAP/etc
[17:02] <popey> try removing it completely and reinstalling
[17:02] <popey> perhaps you already had some of this in snap/gimp
[17:04] <zyga> popey: question, could gimp benefit from layouts?
[17:07] <cjwatson> popey: re-trigger> sure
[17:15] <mup> PR snapd#5128 opened: Revert "Skip test lp-1721518 for arch, snapd is failing to start afte… <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5128>
[17:55] <teward> is there a rule against snap applications requiring donation/payment before you can actually use the applications?
[18:17] <diddledan> super helpful errors for the win (AGAIN!)
[18:17] <diddledan> https://www.irccloud.com/pastebin/2wco9wZB/
[18:18] <diddledan> what kind of error is that? surely I need to know why it thinks lib isn't a directory and what it's trying to do with it to figure out what I did wrong?!!
[19:29] <kyrofa> diddledan: I'd need to see the YAML to help
[19:30] <diddledan> hah
[19:30] <diddledan> it's huge
[19:30]  * diddledan pushes it to git
[19:31] <diddledan> kyrofa: https://github.com/diddledan/gimp-snap/blob/2.10-gold/snap/snapcraft.yaml
[19:31] <diddledan> what's 1400 lines between friends
[19:34] <kyrofa> Oh darn, it's a remote part
[19:34] <diddledan> yeah it was fine until I added the pulseaudio part to that yaml
[19:35] <diddledan> alsa normally installs fine but I've tweaked it for this build to not install any prereqs in the `alsa-plugins` part
[19:35] <diddledan> instead the pulseuadio is supposed to be picked up from my shipped pulseaudio part in gimp's yaml
[19:36] <diddledan> I've got this in the gimp yaml:
[19:36] <diddledan> https://www.irccloud.com/pastebin/ZQQ9O5rq/
[19:37] <diddledan> so something with either the dependency on pulseaudio or the build-packages or stage-packages override is killing it
[19:37] <kyrofa> diddledan, from the error, it sounds like a part that gets staged ahead of alsa-plugins has a lib directory, but somehow alsa-plugins is providing a file there instead of a dir
[19:38] <diddledan> nope, there's no ./lib in parts/alsa-plugins/install
[19:38] <diddledan> there is a ./lib in stage, yes, which is why it's complaining, but what it's trying to do with it I can't tell
[19:39] <kyrofa> Is the lib in stage a directory or a file?
[19:39] <diddledan> it's a directory with libraries in it
[19:40] <kyrofa> diddledan, if there's no lib in parts/alsa-plugins/install, why does it have a `stage` keyword with `lib` in it?
[19:40] <diddledan> o_O
[19:41] <diddledan> ok, I see that now. thanks for the eyes :-) the remote part has a define to include ./lib while staging but that folder doesn't now exist because I overrode the stage-packages to be null
[19:42] <diddledan> we could do with an error condition for such cases, then, where stage: or prime: keywords include references to paths that don't exist
[19:43] <diddledan> that was a much simpler problem than I thought it was going to be
[19:44] <diddledan> I'm gonna clean my build and start it anew to be sure that it's definitely that
[19:45]  * diddledan cuddles kyrofa 
[19:51] <mup> PR snapd#5129 opened: cmd/snap-confine: allow any base snap to provide /etc/alternatives <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5129>
[19:51] <zyga> jdstrand: ^
[19:56] <mup> PR snapcraft#2122 opened: many: introduce variables for part src and build <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2122>
[20:02] <mup> PR snapd#5130 opened: interfaces/apparmor: allow bash and dash to be in /usr/bin/ <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5130>
[20:02] <zyga> jdstrand: one more
[20:03] <mup> PR snapd#5127 closed: HACKING: fix typos <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5127>
[20:06] <diddledan> yup, kyrofa , that was the problem - having a path specified in stage: that didn't exist
[20:06] <diddledan> (my build finally got there)
[20:07] <diddledan> twenty minutes of building to get to that point :-p
[20:07] <diddledan> it's not a small build by any means :-D
[20:17] <mup> PR snapcraft#1064 opened: pluginhandler: support colliding with directories <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1064>
[20:25] <kyrofa> diddledan, yeah... I'll never understand why you guys use cleanbuild to iterate :P
[20:26] <kyrofa> You could have just cleaned that one part and tried again
[20:26] <diddledan> :-p
[20:28] <kyrofa> Heck I still iterate on bionic before throwing to LP for final builds
[20:29] <kyrofa> I very rarely use cleanbuild
[20:29] <kyrofa> If I have larger projects, I have lxd containers dedicated to iterating on them so I don't dirty my host
[20:30] <kyrofa> With ccache installed on them, haha
[20:30]  * zyga found a bug in base snaps
[20:30] <zyga> (well, a new bug)
[21:35] <mup> PR snapcraft#2123 opened: file_utils: don't let FileNotFoundError escape <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2123>
[23:26] <mup> PR snapd#5131 opened: tests: fix interfaces-network test for systems with partial confinement <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5131>