#snappy 2015-11-09
<liuxg> may I know who has build snap using docker with armhf ubuntu?
<dholbach> good morning
<zyga> good morning :)
<fgimenez> good morning
<soffokl> ogra_, do you remember, on Friday I asked you about high IOwait for stable Snappy on VirtualBox?
<soffokl> dmesg give me following output http://pastebin.com/M96u8Che
<mvo> ogra_: Chipaca found some interessting initrd sizes with recent rolling images, some where ~25mb big and that caused issues with the small /boot partition. were those accidents or will the initrd grow significantly
<mkarliner> trying to install snappy for RPi2 on mac. It says the image archive format is unsupported. Anyone else have this?
<dholbach> mvo, can you review https://code.launchpad.net/~dholbach/click-reviewers-tools/1514346/+merge/276961?
<dholbach> mvo, you can see the error in the connected bug report
<mvo> dholbach: sure
<mvo> dholbach: done, thanks
<dholbach> thanks
<JamesTait> Good morning all; happy Monday, and happy World Freedom Day! ð
<zyga> I've pushed my firsts bits of capabilitiy work https://github.com/ubuntu-core/snappy/pull/65
<zyga> please have a look, take apart and poke holes at, I'm still learning go
<ogra_> mvo, they were accidents, it should be back to normal i guess ... if not i have to fix it
<ogra_> mvo, hmm, no, it is still 29M ... i'll check
 * zyga repushed https://github.com/ubuntu-core/snappy/pull/65 with some golint fixes and goes for a quick coffee
<longsleep> ogra_: so my live-build did not got much faster when on tmpfs :/ - i guess qemu ist just not faster and i might try it on native arm
<ogra_> longsleep, find something with a fast disk then :)
<longsleep> ogra_: well we have an armhf cluster with ssd usb raid for compiling Iridium browser - that is probably the fastest i can find without buying anything new - its a shame that dpkg cannot be ccached :/
<longsleep> distributed dpkg would be nice as well :P
<woodrowshen> hi, how about the progress of snapcrart with deb plugin ? i saw longsleep has a PR but no actions after CI fonnd errors.
<longsleep> woodrowshen: sorry, did not have the time for that yet - i use the plugin on daily basis and the CI error is a minor one
<longsleep> woodrowshen: were are some other suggestions on that plugin i need to investigate
<longsleep> s/were/there
<woodrowshen> longsleep: ok, so if i'd like to try deb plugin, i need to patch the commit of PR #53, based on git master, right ?
<longsleep> woodrowshen: well if you want to try the plugin, just use my branch - sure you can rebase on master if you need some features not yet in my branch
<woodrowshen> longsleep: i see, thank you. :)
<ogra_> mvo, hmm, could it be that we didnt install linux-image-extra in the past ?
<ogra_> in our device tarball
<mvo> ogra_: that might be but I have not checked
<ogra_> comparing rolling and 15.04 i see that in the unpacked rolling initrd /lib/modules is 15MB bigger and /lib/firmware is 8M bigger
<ogra_> that might account for the extra 10M
<Chipaca> ogra_: in am image created with the latest rolling, initrd is 8MB
<woodrowshen> i have another question, snapcraft will happen errors when the snapcraft.yaml only set the field of seccomp for security-overwrites. Why did security-overwrites need to set both of apparmor and seccomp ?
<Chipaca> ogra_: um, are you talking about initrd? :-)
<ogra_> Chipaca, oh ?
<ogra_> yes, i'm talking about initrd
<Chipaca> let me build it again, just to confirm
<ogra_> i just downloaded the latest device tarball from http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ and it contains a 29M initrd
<ogra_> and unpacking it and comparing with one from 15.04 i see ~23M extra stuff in /lib/modules|firmware ...
<Chipaca> uff
<ogra_> when i moved th device tarball creation out of the build process into a clean chroot i just install "linux-generic" ... which pulls in linux-image-extra-* .... i assume that wasnt installe dbefore
<Chipaca> ogra_: so. 235 builds fine, 236 on (or at least, 236 and 238 :) ) don't, at all; no space left on device. But already 217 was weird: http://pastebin.ubuntu.com/13208129/
<Chipaca> you can get to 236+ from 235, but once you're there you can't update any further, either
<Chipaca> because two 236+-sized things don't fit
<ogra_> hmm, that 217 one is werid
<Chipaca> very wird
<ogra_> i only started touchin amd64 around wed.
<Chipaca> it might be a read herring, but even a red herring can tell you stuff
<Chipaca> :-)
<ogra_> oh, but i see when comparing my initrds that linux-firmware ships about 9M extra for amd/radeon gpu fw.
 * ogra_ checks when that was added to the package
<Chipaca> hold on
<Chipaca> 238 has the same size initrds as 235, once installed?
<Chipaca> 6.4M?
<ogra_> hmm, no, linux-firmware was 27MB the whole wily circle and recently grew to 29M
<ogra_> i'm pretyt sure its linux-image-extra
<ogra_> http://paste.ubuntu.com/13208164/
<ogra_> http://paste.ubuntu.com/13208169/
<ogra_> only /lib/modules and /lib/firmware have massively grown
<ogra_> hrm
<ogra_> but i see linux-image-extra being installed in a 15.04 build log
<ogra_> sigh, it doesnt help that some package added a new user over night it seems
<ogra_> mvo, were the last two xenial failures your attempts ?
<mvo> ogra_: I don't think so
<mvo> ogra_: looks like a passwd change again
<ogra_> hmm, someone started a build that failed
<ogra_> mvo, yeah
<ogra_> now where did the dnsmasq and tts users go ?
<ogra_> sigh, so all systemd related UIDs changed for no good reason .. fun
<ogra_> aha, because the input grouop disappeared ...
<ogra_> hmm, so lool added that group in february but the livecd-rootfs changelog doesnt say why
<ogra_> mvo, so when tryting to drop the initramfs generation bits from the rootfs on the weekend i found that ubuntu-snappy has a dep on initramfs-tools-ubuntu-core, could we drop that ?
<ogra_> (along with apparmor having a (seemingly useless) dep on initramfs-tools)
<mvo> ogra_: I think we can for snappy, not sure about apparmor I would have to check
<ogra_> mvo, apparmor is in the hands of the security team, they told me its not needed
<ogra_> i'll leave it to them to drop it
<ogra_> (or make it a recommends or so, which would help as well)
<ogra_> sigh, i dont really get how we end up with so many more modules
<ogra_> ogra@anubis:~/Devel/branches/livecd-rootfs/initrd$ grep -c lib/modules ramdisk-15.04.manifest
<ogra_> 506
<ogra_> ogra@anubis:~/Devel/branches/livecd-rootfs/initrd$ grep -c lib/modules ramdisk-rolling.manifest
<ogra_> 720
 * ogra_ slaps forehead 
<ogra_> oh man
<ogra_> so gzip vs lzma make 10M difference it seems :P
<longsleep> lvzm is pretty awesome for file system tarballs but it takes ages to compress
<ogra_> yeah, i dont really care how long it takes
<longsleep> s/lvzm/lzma
<ogra_> but i wonder why the default did silently switch to gzip
<ogra_> must be some live-build thing
<longsleep> yeah live-build generates tar.gz for me as well
<longsleep> system image then build tar.xz
<ogra_> i'm only talking about the initrd
<longsleep> ah
<Guest42341> :/
<mkarliner_> Anybody prepared to help a newbie?
<mvo> jdstrand: good news, https://github.com/ubuntu-core/snappy/pull/55 got a +1 from Chipaca - thats your (and mine) security policy generation branch
<Chipaca> mkarliner: don't ask to ask, just ask
<mkarliner> OK, I'm confused, is the only way to  develop snappy apps to create them on Ubuntu Desktop?
<mkarliner> Is there no native development on Snappy?
<ogra_> on an ubuntu system, yes ... doesnt need to be desktop
<ogra_> you can do it on snappy alone in a lxc container
<Chipaca> on snappy, i'd say no. some people are doing it, but it's complicated.
<ogra_> or in a chroot
<Chipaca> there's going to be a devel snap at some point
<dholbach> ogra_, mvo: do you all current snappy images have webdm installed?
<ogra_> stable definitely., yes
<ogra_> for rolling we dont provide dd'able images
<ogra_> so its up to the person running ubuntu-device-flash to build it
<dholbach> ok, thanks
<ogra_> s/build/include when building/
<mkarliner> Thanks guys. Its just that the getting started page makes absolutely no mention of cross development.
<longsleep> Chipaca: Do you have any news on bug #1511435 - it is starting to become a blocker for us soon
<ubottu> bug 1511435 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap" [Critical,Confirmed] https://launchpad.net/bugs/1511435
<Chipaca> gah. longsleep, i dropped that. On it now.
<jdstrand> sergiusens: before you rip out vendor, please see my comment in the bug
<longsleep> Chipaca: cool - i build my own snappy based rootfs images now - so let me know if you want me to test some fix to a specific package
<sergiusens> jdstrand, I saw it; but I have include beuno and niemeyer in that conversation. Long term vendor is going away in any case so I'm not sure how this is going to be enforced given that the store doesn't enforce it at all either
<sergiusens> as in as a developer I can upload with whatever vendor and have you think everything is good
<sergiusens> and still see this issue
<sergiusens> there is no check for, the vendor in this package does not match any of your account emails
<jdstrand> sergiusens: sure-- I'm not asking for you to change anything per se, however, it seemed that the bit of information I mentioned wasn't considered, and I think it should be. if we remove the check, it will lead to situations where there will be conflicting dbus services and frameworks won't be coninstallable
<jdstrand> sergiusens: right now, we have to manage the ones that fail the check, like nm and bluez, but those are Canonical provided
<jdstrand> sergiusens: but the idea was that the vendor could own that reverse namespace, so if they created two frameworks that competed for the bus-name, that is on them to control
<jdstrand> sergiusens: if we remove the check altogether, it is on the store to make sure there aren't coninstallability concerns
<sergiusens> jdstrand, maybe the use of bus-name needs to trigger a check on what bus name you actually choose
<sergiusens> jdstrand, in any case, the store still allowed having two snaps with conflicts here
<jdstrand> sergiusens: the store would, but it would be on the vendor
<jdstrand> sergiusens: ie, the vendor owned that slice of dbus namespace
<jdstrand> sergiusens: I'm not saying we can't change this, just that there is a subtle difference
<sergiusens> jdstrand, e.g.; I grab a snap you made that included a bus-name, kept vendor as you and I could potentially get into the store as there would be no vendor issue raised
<sergiusens> jdstrand, I understand fully
<jdstrand> sergiusens: because the review tools would 'warn' and trigger a manual review if the check failed
<jdstrand> sergiusens: but if the check passed, then the vendor was in control
<jdstrand> ok
<jdstrand> sergiusens: yes, I understand what you are saying too
<sergiusens> jdstrand, I am just saying we are not enforcing it as the store has no concept of vendor itself
<sergiusens> ah, good
<sergiusens> we enforce consistency locally to the snap but not against the ecosystem
<sergiusens> those are the words I guess that best describe what I wanted to say
<jdstrand> sergiusens: so what I am taking from this is that you are going to go back to the other guys with this info?
<jdstrand> and comment in the bug?
<sergiusens> jdstrand, yes, this also blocks the original bug in any case for moving vendor to an external snapcraft managed file
<elopio> zyga: I need help with templates. So I have to put this in testplans.pxu *and* in examples.pxu?
<elopio> http://paste.ubuntu.com/13209194/
<elopio> plars: I don't get why go get doesn't seem to be doing anything in the test agent. No error either.
<elopio> do you have a way to try this? go get launchpad.net/godeps
<plars> elopio: I don't see much output from your test... it looks like it just gets and runs http://people.ubuntu.com/~elopio/spi_scripts/snappy-tests-job2.sh right?
<jdstrand> woodrowshen: hey, you asked about security-overrides needing both-- that was for historical reasons, however 16.04 is going to make security-override much easier to use (ie, it'll be actually useful)
<elopio> plars: yup. I'm trying different things to debug why the go code is not downloaded.
<plars> elopio: trying it now
<plars> elopio: godeps: cannot parse "dependencies.tsv": open dependencies.tsv: no such file or directory
<plars> elopio: I got that when I ran 'godeps -u dependencies.tsv'
<elopio> right, that comes from go get github.com/ubuntu-core/snappy/...
<plars> elopio: I think it should be snappy/dependencies.tsv
<elopio> plars: I just wanted to check if go get downloads the code for you.
<plars> elopio: it's sitting in the dir underneath that when it runs it
<plars> elopio:  yes, go get launchpad.net/godeps works fine
<elopio> plars: what do you have in $GOPATH ?
<elopio> it could be that from my script it's donwloading it somewhere else.
<plars> elopio: I'm just running it from a test dir under tmp, so I have that
<plars> elopio: in a real job, it would have a tmpdir created by python tempfile module
<plars> that's the workspace that spi creates
<elopio> plars: I'm using export GOPATH="$(pwd)" to download the code in this temp dir for the job.
<plars> elopio: that's perfect
<elopio> perfect, except that it doesn't work.
<plars> elopio: I think it will if you fix that path
<elopio> plars: sorry, which path?
<plars> elopio: the one I mentioned earlier with the .tsv file... or is it not even getting that far? Where are you seeing where it gets stuck and what error are you seeing?
<Chipaca> longsleep: just to be clear, you get this error when making your own oem snap and preinstalling things there?
<elopio> plars: that was just a workaround for go get not working for me. On this workaround the path was alright, but the godeps binary was not downloaded. So not good.
<elopio> plars: this fails for me:
<elopio> export GOPATH="$(pwd)"
<elopio> go get -d -v github.com/ubuntu-core/snappy/...
<elopio> cd $GOPATH/src/github.com/ubuntu-core/snappy
<elopio> saying that the dir doesn't exist.
<longsleep> Chipaca: yes exactly
<plars> elopio: can you show me the error?
<elopio> sure. In about 5 minutes.
<longsleep> Chipaca: oem snap sideloaded by u-d-f and installing spreed-webrtc.longsleep from the store triggers it
<plars> elopio: I'm trying that on one of the spi agent hosts, and it's working fine for me
<longsleep> Chipaca:   software:
<longsleep>     built-in:
<longsleep>       - spreed-webrtc.longsleep
<Chipaca> longsleep: ta
<longsleep> Chipaca: let me paste you a complete example
<longsleep> Chipaca: http://paste.ubuntu.com/13209349/
<longsleep> Chipaca: so i want to preinstall something and apply config
<plars> elopio: one thing to be aware of, is that the SPI workdir path is quite long: example: /tmp/run/d5cc3aa6-6ef6-4615-9c7e-e57ca04cc992_2015-11-09T15:51:39.029430
<plars> basically uuid+datestamp
<plars> elopio: I ran the following in a dir just like that though, and it ran:
<plars> https://www.irccloud.com/pastebin/Q8q0bEhL/
<elopio> plars: and did that work?
<plars> elopio: yes
<elopio> plars: I'm trying this version now:
<elopio> export GOPATH="$(pwd)"
<elopio> go get -d -v github.com/ubuntu-core/snappy/...
<elopio> still waiting for results...
<elopio> this one either worked, or it's taking a long time provisioning.
<elopio> plars: here's the error: http://paste.ubuntu.com/13209409/
<elopio> can't cd to /tmp/run/3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15:53:58.859627/src/github.com/ubuntu-core/snappy
<plars> elopio: trying to reproduce
<elopio> plars: when I do this on my xenial machine, I get: go: GOPATH entry is relative; must be absolute path: "53".
<elopio> but the spi agent doesn't say anything about that.
<plars> elopio: haha, I know the problem
<plars> cd /tmp/run/3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15:53:58.859627/src/github.com/ubuntu-core/snappy
<Chipaca> longsleep: that's a lovely test
<plars> err
<plars> elopio: sec...
<Chipaca> longsleep: and i can confirm it fails even with a trivial example snap
<plars> GOPATH=/tmp/run/3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15:53:58.859627
<Chipaca> elopio: we haz breakage :-/ with a test case that could be added to integration
<plars> elopio: so the paths are 3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15     and    53    and    58.859627
<elopio> Chipaca: good. Tell me more.
<plars> elopio: so it's sticking src in /tmp/run/3a18d20c-9661-4bcd-961d-41dd43f4799e_2015-11-09T15 which is wrong
<plars> elopio: I bet
<elopio> ahhh, I get it plars.
<plars> ev: ^ something interesting to note about SPI with it's very long and flavorful working dir :). I'm sure it can be worked around, but it has led to several gotchas already
<Chipaca> elopio: https://bugs.launchpad.net/snappy/+bug/1511435/comments/4
<ubottu> Launchpad bug 1511435 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap" [Critical,Confirmed]
<elopio> plars: can we just remove the timestamp? UUID seems enough.
<plars> elopio: that's not something I create, that's done by the SPI agent, that's why I cc'd ev
<elopio> Chipaca: this would need a separate integration suite where we start the vm with a different oem.
<elopio> so, I'll add a task for that.
<ogra_> mvo, ok,. initrd is back to 19M now
<ogra_> and i added a ls -l to the build log so we can check there
<jdstrand> sergiusens: oh, I forgot, it isn't actually so bad with the vendor name check. if we have 'name: foo\nvendor: someone@example.com', the busname check verifies com.example.foo. also, only frameworks can specify bus-name. so, you and I can't upload 'foo', so even if you used example.com, you couldn't trample on com.example.foo
<noise][> plars: interesting - you can workaround for now probably by running the agent in âdebug which will use a fixed run/debug directory
<jdstrand> sergiusens: (just some more context for your conversation)
<noise][> plars: and i'll file a bug to remove the timestamp
<sergiusens> jdstrand, right, I got that from the start, but if we want busname to follow something, the conversation is, what should we make it follow for 16.04
 * jdstrand nods
<elopio> plars: do I have permission to run mktemp -d ? I also tried that during the weekend, but failed.
<elopio> I couldn't get an error from that either. I'll try again.
<plars> noise][: I don't think I want a fixed run dir, but I'd recommend that elopio either escape the special chars via sed or some such, or just create your own (and make sure to clean it up) for now
<plars> elopio: yes, you should be able to do that just fine
<plars> elopio: not sure why that would fail?
<noise][> plars - right, just offering that as a possible temp workaround
<plars> noise][: indeed
<elopio> plars: not sure either. I don't understand why running ./snappy-tests-job2.sh $1 $2 > output.txt 2>&1 doesn't put the errors in the output file.
<plars> elopio: if you'd like, you can just do something like: rm -rf /tmp/elopio && mkdir /tmp/elopio at the beginning, and put all your stuff there... then I could check on it if you like?
<plars> elopio: keep it really simple for now until we really understand what's going on
<elopio> plars: that makes sense. Let me finish this try.
<Chipaca> longsleep: i know how to unblock you, if you're blocked by this
<longsleep> Chipaca: that would be awesome yes please
<Chipaca> longsleep: it's a change to the snappy core filesystem though, not sure if you're building that from scratch or not
<longsleep> Chipaca: not yet, but we surely can
<longsleep> Chipaca: wait - do you mean the rootfs ?
<Chipaca> longsleep: yes
<longsleep> Chipaca: i am building that
<longsleep> Chipaca: i got livecd-rootfs with all the hooks + custom extensions
<Chipaca> if you weren't, changing the generated filesystem is also no sweat :)
<Chipaca> longsleep: /lib/systemd/system/ubuntu-snappy.run-hooks.service
<Chipaca> longsleep: change it from After=firstboot to Before=firstboot
<Chipaca> longsleep: \o/
<longsleep> lol ok thats simple
<longsleep> Chipaca: great!
<longsleep> so i will add a cheap hook to hack that on rootfs building
<Chipaca> for 15.04 that's enough
<Chipaca> 16.04 is a bit trickier, but not a lot
<longsleep> Chipaca: well, i assume it will be fixed when we switch to 16.04
<Chipaca> yes, you would assume that :)
 * Chipaca hopes so too
<zyga> elopio: looking at pastebin
<longsleep> Chipaca: great - thank you very much!
<Chipaca> longsleep: thank you for finding this :)
<Chipaca> and for your patience as always
<zyga> elopio: do you have a branch I can look at?
<zyga> elopio: that will be much faster
<elopio> zyga: one second.
<elopio> zyga: https://github.com/elopio/snapcraft/commit/a091059324765cb48807f237a9acccb8ab23fa72
<fgimenez> leaving have a nice evening o/
<zyga> elopio: looking
<zyga> elopio: use $PLAINBOX_PROVIDER_DATA instead of ${PLAINBOX_PROVIDER_DATA} -- easier and less to worry about on quoting
<zyga> elopio: in your code there's just one line missing
 * elopio waits for it...
<zyga> elopio: have a look
<zyga> elopio: I think technically only one line is needed
<zyga> elopio: but I'd apply all the changes I've listed
<zyga> elopio: have a look
<zyga> elopio: in the end you will only have two things in the examples.pxu
<zyga> elopio: the resource (id: examples_resource)
<zyga> elopio: and a template
<zyga> elopio: nothing else
<zyga> elopio: right?
<elopio> ah, you can comment on the diff even if it's not a pull request
<elopio> I didn't know that.
<elopio> zyga: right.
<zyga> elopio: yeah :)
<zyga> elopio: neat stuff
<elopio> zyga: so bootstrap_include instead of bootstrap_jobs?
<longsleep> Chipaca: i added a hook: http://paste.ubuntu.com/13209799/ - building a new rootfs now
<zyga> elopio: I think so, it's documented in the plainbox-test-plan-unit manual page
<zyga> elopio: manage.py validate should say
<elopio> zyga: ok, I think I got everything you proposed. Now it doesn't fail, but doesn't run anything either.
<elopio> pushed the commit
<longsleep> Is there any information what cloud-init actually is doing in snappy? I wish to remove it and wonder if i miss anything important aside from sshd key generation ..
<elopio> I still don't know if I should duplicate the entier examples_resource section, but I get the same result with or without
<mkarliner> Does anyone know if python pip is available on Snappy
<mkarliner> ??
<longsleep> mkarliner: See the examples in https://github.com/ubuntu-core/snapcraft/tree/master/examples to learn how to build a snap which includes python.
<mkarliner> @longsleep - thanks
<nothal> mkarliner: No such command!
<zyga> elopio: I'll check it out locally
<zyga> elopio: sorry for the lag
<elopio> zyga: don't worry. I'm in no hurry.l
<elopio> noise][: plars: I think that the result should include a field for the output of the test script. That's in addition to the results payload.
<elopio> the only ways I have to capture an error like this one are weird: http://paste.ubuntu.com/13209822/
<plars> elopio: you can put it in the test result json file, that gets picked up by spi. Otherwise, if it's just raw output, I do capture that in logstash for debugging purposes. Most of your output seems to be redirected to local output files though, so I don't see it (and neither would spi)
<elopio> plars: I'm redirecting it to files just to debug, because I don't get what the command runs.
<elopio> something like travis, for example, makes this a little easier.
<elopio> not a lot easier because you can't reproduce the run environment. But a little.
<rickspencer3> stgraber, o/
<stgraber> rickspencer3: hey
<rickspencer3> I am following instructions here: https://linuxcontainers.org/lxd/getting-started-cli/
<rickspencer3> I snappy installed lxd.stgraber
<rickspencer3> but then ...
<rickspencer3> $ lxd-images import ubuntu --alias ubuntu
<rickspencer3> LXD isn't running.
<rickspencer3> thoughts?
<stgraber> rickspencer3: what are you running snappy on?
<rickspencer3> stgraber, my rip2
<stgraber> that's probably the problem then
<stgraber> lxd 0.21 depends on a current symlink to exist under /var/lib/apps/lxd
<stgraber> and IIRC you need recent-ish snappy for that
<stgraber> you could try manually creating the symlink from /var/lib/apps/lxd/current to /var/lib/apps/lxd/0.21-1 (which is what recent snappy does for you)
<rickspencer3> stgraber, this core is the latest, from Sept. 25
<stgraber> then either reboot or bounce the systemd unit
<stgraber> rickspencer3: yeah, which is nowhere near "recent" when compared to x86, that's the problem
<rickspencer3> stystemd unit for ldx, I assume
<rickspencer3> ?
<stgraber> yup
<stgraber> systemctl -a | grep lxd
<rickspencer3> ln -s blah/current blah/0.21-1 ?
<stgraber> ogra_: any hope of getting new rpi2 images that match what we've got on x86? We have that problem where sideload on recent snappy gets us a random version string so we can't use the version dir anymore and current doesn't exist in current rpi2 images
<stgraber> rickspencer3: probably lxd/current to lxd/0.21-1 but yeah
<stgraber> (RaspberryPi2)ubuntu@localhost:~$ ls -lh /var/lib/apps/lxd
<stgraber> total 4.0K
<stgraber> drwxr-xr-x 5 root root 4.0K Aug 17 17:24 0.21-1
<stgraber> lrwxrwxrwx 1 root root    7 Nov  2 07:06 current -> 0.21-1/
<rickspencer3> thanks stgraber, that seemed to work
<rickspencer3> maybe add a note to the wiki?
<stgraber> great!
<stgraber> yeah, good point, making a note to update the instructions for rpi2
<rickspencer3> stgraber, so, looks like I am getting server-cloud image
<stgraber> correct
<rickspencer3> that should work fine for running snapcraft, etc..., right?
<stgraber> I guess so, it's a clean deb based Ubuntu
<stgraber> note that it's trusty by default unless you tell lxd-images otherwise, but I think the snappy guys have PPAs that work fine on trusty
 * rickspencer3 wishes he named his container at launch
<rickspencer3> stgraber, so, I am changing this image by installing things to it
<rickspencer3> I am not certain how I make that change stick, or do I have to make an image that has the changes in it, and import that into lxc?
<stgraber> rickspencer3: the container state is persistent so you won't be loosing it on reboot or anything. You can then either make new containers from that container (lxc copy source destination), or do "lxc publish source --alias some-name" which will get you a new image that you can use.
<rickspencer3> stgraber, is there a simple set of docs that I can look at so I do things right without asking you at each and every step? ;)
<stgraber> rickspencer3: outside of the getting started stuff, not really. I've got a todo for today (but will likely end up being tomorrow) to update our demo site with instructions similar to what I do in my demo (which covers all lxd features)
<rickspencer3> ack
<rickspencer3> basically, I want an ARM build environment for snapcraft
<rickspencer3> I wonder if I can make an image that people can easily import that has everything all set up
<rickspencer3> stgraber, soooo, I made the snap in the container
<rickspencer3> \o/
<rickspencer3> but, um ... what's the best way to get it off the container? just push it somewhere?
<rickspencer3> is there an easy way to copy it to the host?
<stgraber> lxc file pull container-name/path/inside/the/container
<stgraber> though I can't remember whether that works on snappy, we had some apparmor/path oddities related to that I believe
<rickspencer3> wow
 * rickspencer3 tries
<rickspencer3> stgraber, so, I have the file at /root/zork/whatever.snap
<rickspencer3> when I try to file pull, it says permission denied
<rickspencer3> and I get an even stranger error when I use sudo
<stgraber> right, that'd be the bug in question
<rickspencer3> ug
<stgraber> I wonder if doing something odd like "lxc file pull container-name/path/inside/the/container - > blah.snap" would workaround the problem
<stgraber> so basically have the client spit it out on stdout and then have your shell write it, working around the permission problem
 * rickspencer3 tries
<rickspencer3> stgraber, fyi ... the - > trick worked, thanks
<stgraber> cool
<josepht> rickspencer3: fwiw, I used scp from the host to grab files from the container
<rickspencer3> josepht, ack
#snappy 2015-11-10
<woodrowshen> jdstrand: noted, thank you for explanation.
<dholbach> good morning
<fgimenez> good morning
<woodrowshen> hi, good afternoon for Asia :p
<woodrowshen> i'm wondering why doesn't snapcraft delete the generated snap while `snapcraft clean` is executed ?
<longsleep> Good morning snappy
<longsleep> Did anyone ever try to run u-d-f in a Docker container? Miserably fails - i am tempted to give up and run it in Vagrant instead or does anyhone have a suggestion?
<Chipaca> longsleep: how does it fail?
<longsleep> Chipaca: it seems to be related to udev
<longsleep> Chipaca: http://paste.ubuntu.com/13214725/
<longsleep> i cannot make much sense of it ..
<longsleep> and i am running it with --cap-add=ALL --privileged=true
<longsleep> would be nice if that would work
<Chipaca> longsleep: in docker, does kpartx work?
<longsleep> Chipaca: let me try
<Chipaca> longsleep: e.g. scp an img in, kpartx -av the.img
<longsleep> Chipaca: yeah that works
<longsleep> add map loop0p1 (252:3): 0 131072 linear /dev/loop0 8192
<longsleep> add map loop0p2 (252:4): 0 2097152 linear /dev/loop0 139264
<longsleep> add map loop0p3 (252:5): 0 2097152 linear /dev/loop0 2236416
<longsleep> add map loop0p4 (252:6): 0 3280896 linear /dev/loop0 4333568
<longsleep> removing it works as well .. loop deleted : /dev/loop0
<Chipaca> well, that's good in one sense
<Chipaca> because it means the thing i thought wouldn't work, works
<longsleep> Well, from the trace it tries to connect(3, {sa_family=AF_LOCAL, sun_path="/run/udev/control"}, 19) = -1 ENOENT (No such file or directory)
<longsleep> which fails as there is no udev in the container
<longsleep> and then exit 2
<longsleep> what i do not get, is why it wants to connect to udev
<Chipaca> me neither, offhand
<Chipaca> unless i'm missing something it shouldn't need udev at build time
<longsleep> Chipaca: yeah, there is no udev stuff in the code what i could find
<Chipaca> question for sergio, then
<Chipaca> longsleep: the udev stuff will be from snappy
<Chipaca> but they shouldn't get called at build time
<longsleep> Chipaca: ok, let me check what i find there
<longsleep> starting udev is not an option though
<longsleep>  * udev does not support containers, not started
<zyga> elopio: I'll check out those templates in a sec
<livcd> so how does snappy play with docker ?
<JamesTait> Good morning all; happy Tuesday, and happy Area Code Day! ð
<longsleep> Chipaca: found the problem why u-d-f tries to connect to Docker .. http://git.intranet.struktur.de/debian/ubuntu-snappy/blob/ubuntu/trusty/snappy/oem.go#L241
<longsleep> I think this should not be called when snappy is used from u-d-f
<Chipaca> i don't think intranet links will work :)
<longsleep> err
<longsleep> sorry
<Chipaca> nm, got it
<longsleep> Chipaca: correct link is https://github.com/ubuntu-core/snappy/blob/master/snappy/oem.go#L242
<longsleep> Chipaca: It reloads udev rules when processing oem snaps
<Chipaca> yes, but it shouldn't run if inhibitHooks is there
<Chipaca> let me grab sergio
<longsleep> Chipaca: its called from here: https://github.com/ubuntu-core/snappy/blob/master/snappy/snapp.go#L812
<Chipaca> yeo
<Chipaca> it should, i think, instead be called from run-hooks
<Chipaca> or firstboot?
<longsleep> well it needs to run when a new snap is installed
<longsleep> on boot i thin udev will load all rules automatically
<longsleep> =k
<Chipaca> longsleep: so
<Chipaca> longsleep: easy workaround for you for now
<Chipaca> longsleep: ln -s /bin/true /usr/local/bin/udevadm
<Chipaca> longsleep: in the container
<longsleep> Chipaca: yep
<longsleep> Chipaca: lets see if i can get it running in the container then
<Chipaca> it's unclear to me atm whether the installOemHardwareUdevRules itself should be skipped, or just the reload, when calling it from u-d-f; sergio would know more but he's off for now
<longsleep> Chipaca: yeah almost there i think
<longsleep> xz: Cannot exec: No such file or directory
<longsleep> :/
<longsleep> there seems to be a dependency missing
<longsleep> i install u-d-f with apt
<longsleep> Chipaca: woot - it worked
<longsleep> New image complete
<longsleep> Summary: Output: test.img Architecture: amd64 Channel: stable Version: 9
<longsleep> (patched version though, let me try the symlink hack)
<longsleep> Chipaca: still struggle with dependencies .. "sc-filtergen": executable file not found in $PATH
<Chipaca> $ dpkg -S `which sc-filtergen`
<Chipaca> ubuntu-core-security-utils: /usr/bin/sc-filtergen
<longsleep> yeah
<longsleep> that package is a beast - pulls in perl and python
<Chipaca> :-(
<longsleep> having a large docker container is better than none
<Chipaca> i wonder about the perl
<longsleep> Chipaca: including like 50 perl module packages :)
<Shibe> so can snappy run on other distros that are not ubuntu based?
<Chipaca> Shibe: probably
<Shibe> okay
<Shibe> Chipaca: and with snappy we can have bleeding edge applications without breakage right?
<Chipaca> gah
<Shibe> ?
<Chipaca> longsleep: libssl -> debconf -> perl-base
<Shibe> also can snappy install things such as drivers?
<Shibe> or would we still use apt for that?
<longsleep> what libssl requires debconf?
<Chipaca> longsleep: http://people.canonical.com/~john/deps.svg
<longsleep> Chipaca: oh my
<Chipaca> longsleep: apt-rdepends -d ubuntu-core-security-utils | neato -Gsplines -Goverlap=scale -Tsvg > /tmp/deps.svg
<Shibe> what about storage? would snappy apps take up more space than regular apps?
<longsleep> Chipaca: well, u-d-f now fails with exit 1 when installing one of the preinstalled snaps from the oem definition .. so more debugging
<Chipaca> Shibe: drivers would be included in the kernel snap (which is a 16.04 thing)
<Chipaca> Shibe: there is no apt in a snappy system
<Shibe> Chipaca: so there will be no apt in ubuntu 16.04 or what?
<Chipaca> Shibe: which ubuntu 16.04?
<Shibe> wait
<Shibe> wont snappy become like the primary package manager in newer versions of ubuntu?
<Shibe> or is it only for mobile devices and servers?
<Chipaca> Shibe: no, it won't become the primary package manager in newer versions of ubuntu
<Chipaca> Shibe: and no, it is not only for mobile devices and servers
<Shibe> so there will be a seperate ubuntu called snappy ubuntu?
<Chipaca> Shibe: there already is
<Shibe> yeah
<Chipaca> Shibe: snappy ubuntu core
<Shibe> i was thinking that it was more of an experimental version of ubuntu before snappy becomes the default
<Chipaca> I wouldn't describe it that way
<Shibe> okay
<Chipaca> Shibe: https://developer.ubuntu.com/en/snappy/
<Shibe> Chipaca: but will the snappy ubuntu core ever become the default?
<Chipaca> *core* won't ever become the default, no
<longsleep> Chipaca: SeccompFilterGenException: \"Invalid template 'default'\ - any idea about this one?
<Shibe> ok
<Chipaca> Shibe: there might at some point be a snappy ubuntu desktop
<Chipaca> Shibe: but I can't see that far into the future
<Shibe> okay
<ogra_> well, i would assume that core might stay the default on all snappy installs
<longsleep> Chipaca: happens when /usr/bin/sc-filtergen is called
<ogra_> with icn on top for a snappy desktop or a snappy server
<ogra_> *icing
<ogra_> but nobody can really see far into the future on that level as Chipaca said :)
<Chipaca> ogra_: possibly, but we'd probably not call the resulting system a "snappy ubuntu core" system
<ogra_> yeah
<Chipaca> longsleep: you're missing ubuntu-core-security-seccomp
<longsleep> Chipaca: yeah - just found this package, lets see
<longsleep> Chipaca: yeah that was the last one, works now unpatched version, just symlink udevadm and install a bunch of debs
<Chipaca> huzzah
<longsleep> Chipaca: so green light for u-d-f in Docker - yay!
<longsleep> Chipaca: btw, not sure if i told you already, but changing run-hooks to run before firstboot fixes bug #1511435 and the booted system applies the provided oem config an all.
<ubottu> bug 1511435 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap" [Critical,In progress] https://launchpad.net/bugs/1511435
<Chipaca> longsleep: https://github.com/ubuntu-core/snappy/pull/72
<Chipaca> longsleep: and https://github.com/ubuntu-core/snappy/pull/71
<longsleep> Chipaca: nice yay \o/
<dpm> beuno, JamesTait, is there a field in the store API that contains a human-readable name for a snap that we could use to show a list of snaps such as the one in https://developer.ubuntu.com/en/snappy/guides/gadget-snaps?
<dpm> e.g. "BeagleBone Board" instead of "beagle.gumstix"
<JamesTait> dpm, you want the title field.
<dpm> JamesTait, but is that available from the API? I seem to remember dholbach mentioned we don't have access to such a field
<dholbach> I might be doing it wrong :)
<JamesTait> dpm https://search.apps.ubuntu.com/api/v1/search?q=download_url%3A%2A.snap&fields=name%2Ctitle%2Cdownload_url&page=1
<JamesTait> I think that's what you want: "name": "com.ubuntu.snappy.docker", "title": "The docker app deployment mechanism"
<dpm> davidcalle, dholbach ^
<dholbach> dpm, they're generally not looking prettier :-/
<dholbach> "title": "odroidc-community"
<dholbach> "title": "generic-i386"
<dpm> yeah, I just saw that too
<dholbach> "title": "beagle"
<dholbach> so I'm not sure it's worth changing right now
<dholbach> JamesTait, is the title field editable by people who upload apps to myapps?
<dholbach> and what is it called? :)
<ogra_> i think it is called Title in the store form
<Chipaca> dholbach: dpm: "title" is what you want
<Chipaca> dholbach: dpm: people might not be using it right, but that's where you're supposed to be putting the human-readable one
<dholbach> there's id_name and id_tagline
<dholbach> id_description
<Chipaca> bah
<Chipaca> something might be wrong :)
<Chipaca> for snappy, the title is the first line of the readme
<dholbach> yeah, I'm trying to piece it together
<Chipaca> so that's the "description" field in the store
<Chipaca> but only the first line fo it
<Chipaca> maybe
<Chipaca> i guess this is one of the things that the store does not get from the package?
<longsleep> Chipaca: so, do you want to hear about another service ordering poblem with firstboot and modules-load.d ?
<dholbach> Chipaca, it might be
<Chipaca> because for example, curl has a title in the manifest, that is not in the store data
<Chipaca> longsleep: yes, yes i would
<fancycode> Chipaca: thanks for your feedback on #67, is there some sort of roadmap available so I don't try to provide our changes upstream if they will be deprecated soon anyway ;-)
<longsleep> Chipaca: so, when an oem snap wants to load kernel modules, with config: ubuntu-core: load-kernel-modules, then this fails for the very first boot, because snappy firstboot runs after systemd-modules-load.service
<dholbach> JamesTait, do you know where the data for .title comes from?
<longsleep> Chipaca: second boot works fine, as the created modules-load.d file is there then
<Chipaca> longsleep: can you confirm adding systemd-modules-load.service to firstboot's Before: fixes it?
<Chipaca> longsleep: (as opposed to creating a cycle)
<longsleep> Chipaca: Let me try, i am still new to systemd and its ways
<Chipaca> longsleep: it's got a bunch of things on the Before: line, you can just append
<Chipaca> or add another Before: line
<Chipaca> both work
<Chipaca> fancycode: I don't think we have a roadmap per se, sorry
<fancycode> Chipaca: hmm, ok thanks
<longsleep> Chipaca: That results in an order cycle and systemd deleted it
<Chipaca> longsleep: feared as much
<Chipaca> longsleep: can you pastebin the bit of the log about the cycle?
<longsleep> Chipaca: sure / hold on
<longsleep> Chipaca: http://paste.ubuntu.com/13216046/
<jdstrand> mvo: just so we are in sync> I'll be pulling your changes into my branch later today, but don't push it yet-- there are still a few things to implement (see the card) and a lot I want to test
<jdstrand> mvo: and a bit to discuss :)
<jdstrand> but not atm
<mvo> jdstrand: ok. thanks. it seems like everything left is review-tools? except for apparmor_parser -p but I send a question about this :)
<mvo> jdstrand: and testing of course
<mvo> jdstrand: if you point me towards what else is missing I'm happy to have a look at it
<jdstrand> mvo: the card has a few things
<Chipaca> longsleep: on first boot, can you confirm whether "systemctl reload systemd-modules-load.service" loads the modules just added by firstboot? (once you removed systemd-modules-load.service from the Before of firstboot)
<longsleep> Chipaca: let me check
<Chipaca> longsleep: thanks!
<Chipaca> longsleep: i'm being lazy relying on you to test stuff, hope you don't mind too much
<longsleep> Chipaca: no problem, i just takes around 70 seconds to write a new image to the sdcard
<Chipaca> wow
<Chipaca> ok
<Chipaca> your sd writer is 5x faster than mine
<jdstrand> mvo: in terms of  snappy code there are two things: 1. "remove 'apparmor' and 'seccomp' keys from security-override and just have 'read-paths, syscalls, etc all directly under 'security-override'"
<longsleep> Chipaca: you have USB3?
<jdstrand> mvo: and 2. "regenerate-all should only regenerate svc/bin policy, not all policy within a snap"
<longsleep> 3899999744 Bytes (3,9 GB) kopiert, 73,5622 s, 53,0 MB/s
<Chipaca> longsleep: usb2 only for me
<longsleep> Chipaca: yeah well, that explains why you get only around 10MB/s
<Chipaca> although the sd card according to lshw is hung off of pci directly
<Chipaca> but, yeah, oldish laptop
<Chipaca> sandybridge iirc
<longsleep> Chipaca: Job type reload is not applicaple for unit systemd-modules-load.service
<Chipaca> longsleep: restart, then?
<Chipaca> and just checked, it's an arrandale, not sandybridge
<longsleep> Chipaca: ok, confirmed after restart the modules are loaded
<Chipaca> longsleep: that is 'systemctl restart systemd-modules-load.service', not a reboot, yes? :)
<longsleep> Chipaca: yes
<jdstrand> mvo: so '1' is probably pretty easy-- squash SecurityOverride into one thing rather than two
<longsleep> Chipaca: http://www.amazon.com/Transcend-Information-Card-Reader-TS-RDF5K/dp/B009D79VH4/ref=sr_1_2?ie=UTF8&qid=1447166144&sr=8-2&keywords=transcend+usb3+card+reader, connected into Dell USB3 hub integrated inside monitor :)
<longsleep> $6.95
<jdstrand> mvo: '2' maybe requires some explanation. right now, click-apparmor will only recompile policy for the services/binaries that are affected. snappy currently will regenerate all the policy if any are affected
<Chipaca> longsleep: :)
<jdstrand> mvo: for a few snaps, this isn't a big deal, but on personal where many snaps will ship both a scope and an app, we could halve the compile time for these snaps (eg, if the scope template changes, we don't have to regenerate things that use the app template)
<jdstrand> mvo: and that is an important optimization
<mvo> jdstrand: aha, thanks for explaining (2). but certainly not a blocker, right? I mean not a blocker for inclusion even if that lands later this week?
<jdstrand> mvo: and it would be felt on core too-- imagine something like the nm framework that ships some 10 binaries and a couple services. if only one of those needed to be updated, it would be wasteful to regenerate the other 11
<jdstrand> mvo: that wouldn't be a blocker-- it could land later
<jdstrand> mvo: but '1' is. we want to move straight to the cleaner/clearer yaml for security-override
<jdstrand> mvo: also, ubuntu-core-launcher needs an update for hwaccess
<jdstrand> mvo: and a systemd unit for regeneration
<jdstrand> mvo: and apparmor update for /var/lib/snappy/apparmor/profiles
<jdstrand> I'll handle that last one
<jdstrand> feel free to do any of the others
<mvo> jdstrand: what updated does u-core-launcher needs?
<mvo> jdstrand: I will try to look into (1) next
<jdstrand> mvo: if you recall, it is looking at the .json.additional file in /var/lib/apparmor/clicks
<jdstrand> ok, I have a meeting in a few minutes and I need to step away
<mvo> jdstrand: I did not, but now I do
<mvo> jdstrand: thank you!
<jdstrand> np
<jdstrand> mvo: there is one last thing that won't block this merge> click-apparmor has the concept of .override files. with them, you can add to or remove from the caps/security-override
<jdstrand> mvo: you can think of them as the user replacing security-template, caps and security-override from the package.yaml with their own
<jdstrand> mvo: what click-apparmor does doesn't translate to this new world exactly, but this feature was important for Touch since users could, for example, remove the 'networking' policy group from the security perms
<jdstrand> mvo: we'll want to design how this works. I mention it, cause I imagine it would be a 3rd file to merge into overrides. alternatively, the current hwassign file format could be keyed to handle both hwassign and user overrides
<jdstrand> mvo: funny how redoing policy generation seemed like an easy task, no? (there is a lot of thought that went into how we did things before-- it is good that we can reuse what makes sense and refine/redo what doesn't)
<mvo> jdstrand: thanks this makes sense. I slightly prefer that hw-assign does that, but have not put much thought into it yet
<seb128> mvo, ogra_, hey, https://code.launchpad.net/~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/bug-1435774/+merge/256562 seems to be stalled in the sponsoring queue, could you have a look if that's still relevant or if it should be rejected?
<JamesTait> dholbach, the title field in the metadata comes from the title field in the manifest for click packages. It sounds like that's not the case for snaps, though, so I'll have to check,
<jdstrand> mvo: well, the good thing is, whatever we come up with is not a user visible change (in terms of packaging yaml). and since no one is doing user overrides on snappy yet, we have some time
<dholbach> thanks JamesTait
<jdstrand> mvo: but I mention it because if you had a strong preference on one file or two, you could go with it and adjust the launcher once
<jdstrand> ok, gotta run for real
<Chipaca> longsleep: could you file a bug for the modules thing?
<mvo> jdstrand: thanks for your input
<longsleep> Chipaca: yes sure
<JamesTait> dholbach, Chipaca: do you have an example where the package title that's in CPI clearly isn't obtained from the package?
<Chipaca> JamesTait: curl.tetor
<JamesTait> Thanks, Chipaca.
<mvo> jdstrand: thanks, I implemented the flat "security-overrides" in my branch now
<JamesTait> dholbach, in answer to your previous question, yes, developers can override the values from the package metadata in the upload form - if they provide Application Name, I believe the package manifest is ignored for the title.
<dholbach> JamesTait, so "Application Name" gets mapped to .title?
<JamesTait> I'm just uploading a package to staging to verify this.
 * dholbach hugs JamesTait
<dholbach> thanks a bunch!
<longsleep> Chipaca: modules bug added as #1514890
<longsleep> Chipaca: bug 1514890
<ubottu> bug 1514890 in Snappy "Kernel modules from oem snap not loaded on first boot" [Undecided,New] https://launchpad.net/bugs/1514890
<Chipaca> taw
<elopio> fgimenez: please check if you like how I'm ignoring test messages, and if you like it I'll do the same for setup and tear down:
<elopio> https://github.com/ubuntu-core/snappy/pull/70
<fgimenez> elopio, sure, on it
<JamesTait> dholbach, http://people.canonical.com/~jtait/sample-snap.png is what I see if I fill in the Application Name, Tagline and Description fields in the form.
<dholbach> JamesTait, right... I was just wondering which of the fields is later on used in .title?
<JamesTait> That would be Application Name.
<fgimenez> elopio, nice, it would be great to express the regexp to know if we have to ignore in terms of the format constants, but it's fine as it is
<elopio> fgimenez: yeah, that's harder. Any tips? I didn't know how to escape the *.
<fgimenez> elopio, there's https://golang.org/pkg/regexp/#QuoteMeta, haven't tried it though
<elopio> let me try.
<elopio> fgimenez: should those constants be in the reporter package? or maybe in the base_test
<fgimenez> elopio, not sure, they are going to be used by the component that handles the reboot, whatever it is after the disection of common, and by the reporter pkg, maybe the data pkg as we have been doing so far for shared constants?
<jdstrand> mvo: thanks! so, one thing I've been a bit concerned about is upgrades. I think the systemd unit will handle nearly everything, but for hardware assignment, need to migrate .json.additional to /var/lib/snappy/apparmor/additional?
<jdstrand> mvo: also, security-override changes the yaml. I don't expect there to be anything that is using the current security-override (or at least nearly nothing)
<mvo> jdstrand: yeah, I think you are spot on, we need to migrate .json.additional. security.md needs an update indeed
<jdstrand> mvo: yeah, I'll do the security.md part
<jdstrand> mvo: but I was worried about existing snaps or sideloading
<jdstrand> mvo: well, worried, I'm not sure how I feel
<mvo> jdstrand: its rolling, its ok to break stuff I think
<jdstrand> mvo: ie, what happens if I sideload or snappy build with different versions of snappy
<jdstrand> mvo: yes-- I was thinking that, but I don't think you can have snaps in the store with one version that targets rolling and another stable, can you?
<jdstrand> I guess this is literally all the same questions as moving to squashfs
<jdstrand> mvo: would it make sense to have a nicer error if the user specifies 'apparmor' and/or 'seccomp' in the security-override?
<jdstrand> mvo: eg, if they do, then suggest using 'read-paths', 'write-paths' or 'syscalls' instead?
<mvo> jdstrand: we can do that  too
<mvo> jdstrand: fine with me
<jdstrand> I think that would ease my mind. that gets quite a bit easier now that you flattened it
<mvo> ok
<jdstrand> or at least-- it keeps the implementation cleaner (I think)
<Chipaca> what's the status of booting with a 32bit uefi? is that working?
<seb128> https://code.launchpad.net/~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/bug-1435774/+merge/256562 is in the sponsoring queue since april
<seb128> and James isn't around anymore
<seb128> could somebody have a look and say if that should be rejected or what?
 * ogra_ wonders what keeps the arm builders so busy 
<tbr> ogra_: wrestling tournament?
<tbr> arm wrestling? get it? get it?
<tbr> *badumtssssss*
<ogra_> hah, yeah ...
<ogra_> so funny !
<ogra_> :)
<longsleep> ogra_: Hey, has there been any development regarding update of the bootparts of the oem snap, plans for that?
<ogra_> update in what way ?
<ogra_> i'm still owing documentation for the uboot setup ... beyond that nothing is planned atm
<longsleep> ogra_: eg. write new u-boot or .env when the oem snap updates or when the system image is updating
<longsleep> as far as my understanding goes, the boot stuff is only written once and currently never updated - is that correct?
<ogra_> yep
<longsleep> ok - so i might have to work on this a bit soon
<ogra_> that might change when we go for "everything is a snap"
<longsleep> yeah - though that is tricky to make a safe operation, how does the user know that now would be bad to unplug power
<ogra_> right
<longsleep> at least he odroid does not have a backup location for alternate u-boot if the update screws it up or something
<longsleep> so i think the operation should be manual in any case so the user can be told, not to turn off the device
<ogra_> sudo snappy update-oem ?
<longsleep> yeah something like that
<ogra_> or rather "update-gadget" in future speak
<ogra_> (not sure the bootloader will stay in oem)
<longsleep> i think the snappy tool would be the correct place to put it
<ogra_> right
<longsleep> for now i might create something simple inside an unconfined snap - but i think this needs to be handled by snappy base software in the future
<ogra_> well, like the kernel, rootfs and whatever else snaps
<longsleep> yes - there could be a hook similar to the config hook which can be provided by the oem snap or by whatever snap owns the bootloader to precheck and generate a yaml for snappy to read the assets from
<aluft> Exploring snappy for first time, struggling to change an applications apparmor config to "read a file" here is the log: audit: type=1400 audit(1447176418.849:1694): apparmor="DENIED" operation="open" profile="system-status.victor_system-status_1.0.10" name="/etc/ubuntu-build" pid=4741 comm="cat" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<ogra_> you cant read stuff outside of your confined area
<aluft> thank you, can I change the confined area?
<ogra_> probably not enough to read that file ...
<Chipaca> longsleep: https://github.com/ubuntu-core/snappy/pull/76 and .../77 for the 15.04 cherry-pick
<kyrofa> ogra_, you still around?
<ogra_> only partially
<ogra_> whats up ?
<kyrofa> ogra_, quick snappy spec question: snappy/doc/meta.md implies that the description key is only for services. Is that true? Not for binaries?
<ogra_> uh, i dont know ... Chipaca might though
<rickspencer3>  hey all, I'm trying to use fswebcam in a snap on my rpi2, any ideas why I might get these errors: http://pastebin.ubuntu.com/13218060/
<ogra_> but i guess it would be rather useless for binaries
<ogra_> rickspencer3, you need to use hw-assign to enable the device access for the video device
<rickspencer3> ogra_, did that
<rickspencer3> in two ways
<ogra_> hmm
<ogra_> weird
<ogra_> the last line is even weirder
<kyrofa> Ah, sergiusens is around. Do you know the answer to my question ^^ ?
<rickspencer3> sudo snappy hw-assign rest-cam.sideload /dev/video0
<sergiusens> kyrofa, let me get back to you in a bit
<rickspencer3> then, out of desperation:
<rickspencer3> sudo snappy hw-assign rest-cam.sideload /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/input/input1
<ogra_> kyrofa, where would that description be shown ? i mean ... systemctl will sjow you a description for a service ... i dont see where you would show such a description for some random binary
<rickspencer3> ogra_, I would assume that for a binary, the description would be shown in the store
<kyrofa> rickspencer3, only the package description
<ogra_> rickspencer3, where exactly ? the store doesnt show any content of a snap
<kyrofa> ogra_, you're right, right now it wouldn't be used. But it will in the future (in GUIs etc.)
<rickspencer3> sorry, I thought that was what you referred to
<ogra_> kyrofa, so you expect guis that show snap content in the future ?
<ogra_> grrrr ... why does launchpad always lie to me about publishing status
<ogra_> \o/
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/42931
<sergiusens> kyrofa, hey, so what was your question? I don't have enought scrollback
<ogra_> raspi2 device tarballs now automatically from the normal rootfs build
<kyrofa> sergiusens, got the answer from the code-- ignore me! :)
<sergiusens> kyrofa, are you working on scopes still?
<kyrofa> sergiusens, man, I'm working on _everything_ :P
<sergiusens> kyrofa, it is sometimes like that ;-)
<sergiusens> kyrofa, to test that box you tick on job summaries "self manage multiple tasks" :-P
<kyrofa> sergiusens, hahaha :) . I love it though-- everything from kernel patches to scopes to the in-app purchase API
<kyrofa> sergiusens, what are you up to these days?
<kyrofa> Enjoying fatherhood?
<sergiusens> kyrofa, that and snapcrafting :-P
<kyrofa> Ahh, right, snapcraft. I knew you were on that
<kyrofa> sergiusens, I think you gave me your cold, by the way
<sergiusens> kyrofa, I didn't get a cold ;-)
<sergiusens> so it couldn't have been me :-)
<kyrofa> sergiusens, oh. Must have been my son's snotty kisses then
<ogra_> thats the proper opensource way ... share !
<sergiusens> lol
<sergiusens> I don't want to share what I had, it is rather painful ;-)
<wrd> hey
<rtg> sergiusens, mvo: can one of you take a look at my snapcraft.yaml at git://kernel.ubuntu.com/rtg/kernel-snap.git and tell my why I can't seem to get files copied from stage into snap ?
<rtg> p.s. - this is early work in progress
<ogra_> rtg, why do you use plugin: make ?
<ogra_> if you only want the binary debs
<rtg> ogra_, 'cause it is what I know
<ogra_> rtg, i'd just (ab)use the copy plugin
<ogra_> http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/files
<rtg> ogra_, you haven't looked at the Makefile, there is more to it then just copying
<ogra_> ah
<ogra_> yeah, i havent
<rtg> ogra_, can you point me at the code that sergiusens uses to build a device tarball ? I'd like to hijack the initrd bits.
<ogra_> i didnt know sergiusens builds device tarballs :)
<rtg> ogra_, well, somebody does. I thought he did the platform image creation code
<ogra_> rtg, for the fun of it, i replaced the whole code for building device tarballs today :) http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1227
<ogra_> you want the changes in live-build/auto/build there
<sergiusens> rtg, we use livecdrootfs today
<ogra_> thats exactly the code creating the device tarballs
 * sergiusens git clones
<rtg> hmm, seems like there ought to be a way to do this without having to chroot.
<ogra_> on the buildd ?
<rtg> ogra_, no, I was thinking more about building snaps
<ogra_> ah
<ogra_> yeah, snapcraft should work without chroot
<kyrofa> sergiusens, do you know what compression will be used for snappy's squashfs images?
<ogra_> i guess thats an mvo question
<sergiusens> kyrofa, the worst one (wrt to compression or speed I leave you to guess)
 * sergiusens trolls
<sergiusens> kyrofa, one sec
<kyrofa> :P
<rtg> ogra_, it looks like this code is just using the initrd created by the kernel deb. I was thinking snap images had additional scripts in the initrd
<rtg> for unconfinement, cloud-init, etc
<ogra_> rtg, these scripts are in the initramfs-tools-ubuntu-core package
<rtg> ok, I'll have a look there
<ogra_> no, cloud-init isnt in the initrd
<ogra_> rtg, if you want to ship an initrd i dont think you can get around a chroot ...
<sergiusens> kyrofa, https://github.com/ubuntu-core/snappy/blob/master/pkg/snapfs/pkg.go#L134
<rtg> ogra_, possibly. that'll make the initial snap staging take awhile to setup
<sergiusens> kyrofa, this implementation is going to be moving to snapcraft though
<kyrofa> sergiusens, XZ, perfect, thank you
<ogra_> well, debootstrap --variant=minbase is enough for that
<sergiusens> and snappy is losing its `build` command
<ogra_> see the code above ...
<ogra_> sergiusens, oh, really ?
<rtg> ogra_, right
<kyrofa> sergiusens, oh wow, I didn't know that
<ogra_> no more manually hacking together package.yaml and such ?
<sergiusens> no more package.yaml, no
<ogra_> rtg, alternatively just pull one of the tarballs from http://cdimage.ubuntu.com/ubuntu-core/daily/current/ ... (the buildd chroot (or close to it)) ... and untar it
<ogra_> thats faster than debootstrap
<ogra_> and below 50M
<ogra_> (well, indeed the right tarball for the right release)
<rtg> ogra_, yup
<mvo> kyrofa: we are using xz right now
<kyrofa> mvo, shouldn't you be in bed or something?
<sergiusens> kyrofa, it is not that late ;-)
<kyrofa> :P
<mvo> kyrofa: yes yes
<mvo> kyrofa: I will be soon
<mvo> sergiusens: well, trouble is that I need to get up early :(
<sergiusens> and he left :-)
<frecel> Hello
<frecel> Popey said that someone here might be working on a snappy release for intel edison
<popey> I heard a rumour, that's all :)
<popey> sergiusens, do you know if anyone is working on an Edison port? frecel has one on the way and is keen to play with snappy :)
<sergiusens> popey, frecel maybe lool
<sergiusens> I have an edison as well
<sergiusens> but it seems there are many versions of edison
<sergiusens> sort of like nexus 7 being grouper and flo
<frecel> sergiusens: As far as I know there is only one edison, but then there's gallileo and a couple of other x86 dev platforms from intel
<sergiusens> frecel, right, well I know lool got one to boot ubuntu core; the only issue back then was potential bricking as iirc some u-boot bits needed tweaking
<sergiusens> this was 5 months or so ago, so I don't recall that much
<frecel> sergiusens: well then maybe I should talk to lool before I do anything to drastic
<frecel> I wouldn't want to end up with a bricked edison
#snappy 2015-11-11
<bush> is there a set of comprehensive documentation on creating a ubuntu core port for a custom board that anyone knows of?
<frecel> bush: I couldn't find anything, it would be nice if something like this existed
<bush> I'm stuck trying to figure out how to include device specific bootloaders (FSBL, u-boot, etc.)
<frecel> bush: what device are you working on?
<bush> zynq
<frecel> bush: https://developer.ubuntu.com/en/snappy/guides/porting/
<bush> the target is ARM Cortex-A9, similar to BBB and RPi
<frecel> I managed to find something
<bush> I've followed that and exhausted a few other (outdated) guides, blogs, etc.
<bush> It seems the documentation isn't moving as quickly as the development, as I'm sure we've all been guilty of.
<frecel> yeah, this seems to be the common case for fast moving projects
<sergiusens> bush, where are you stuck wrt bootloader setup?
<jeffesquivels> bush: zynq? that's cool... I'm interested in the FPGA part of it
<jeffesquivels> bush: I think that's what the snickerdoodle has
<jeffesquivels> (sorry about being OT, he he)
<bush> sergiusens: I can't figure out how to specify a bootloader or .dtb within a device package when building an image with 'ubuntu-device-flash'
<sergiusens> bush, you need to create an oem snap and pass --oem to u-d-f
<sergiusens> one sec
<sergiusens> bush, something like http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/beagleblack/
<bush> sergiusens: I just include the oem snap within the device package under /assets?
<sergiusens> bush, hmm, /assets in a device package is long gone
<sergiusens> bush, where is this info coming from?
<sergiusens> jdstrand, do you know why I get this http://paste.ubuntu.com/13222977/ ?
<bush> sergiusens: One of the outdated guides I've been disecting: https://ograblog.wordpress.com/2015/01/25/porting-ubuntu-snappy-to-a-yet-unsupported-armhf-board/
<sergiusens> bush, oh, that is indeed old
<sergiusens> ogra_, add a not mentioning it is outdated :-P
<bush> sergiusens: Exploring the BBB package made me think the format was still relevant: https://developer.ubuntu.com/en/snappy/guides/porting/
<sergiusens> bush, you need to create a snap out of what I just gave you and do ubuntu-device-flash ... --oem <thesnap> ...
<sergiusens> the yaml is indeed outdated
<sergiusens> bush, use this as a base http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-armhf.device.tar.gz
<bush> seriusens: awesome, thanks.
<sergiusens> change $arch if relevant
<soffokl> Hey guys, we still have big problems with disk IO on Ubuntu Snappy for virtualbox.
<soffokl> Disk blocked sometimes without any reasons, even just copying file.
<soffokl> http://s23.postimg.org/byhfb9g57/Screenshot_from_2015_11_11_10_03_18.png
<soffokl> dmesg shows following http://pastebin.com/M96u8Che
<soffokl> We are using SSD only systems and disk on host system not loaded.
<soffokl> There is no such problems with other OS on virtualbox.
<soffokl> Checked on different hardware with 15.04, 15.10, 14.04, same results.
<soffokl> ogra_, Chipaca please help us, we have no idea about direction to dig
<liuxg> I have a simple snappy project at https://github.com/liu-xiao-guo/go-webserver. If I do not want to use "source: git://github.com/liu-xiao-guo/golang-http" in the snapcraft.yaml to compile the go. Instead, I want to make the source code locally.  how can I modify the snapcraft.yaml file?
<mvo> liuxg: hm, does the line "source: /home/liuxg/path/to/golang-http" work?
<liuxg> mvo, I am not sure about it. Let me try it. thanks
<liuxg> mvo, it does not seem to work http://paste.ubuntu.com/13225257/
<liuxg> mvo, we have examples to show how to pull the sources, but it does not show how to compile a project whose sources are local.
<mvo> liuxg: interessting, what version of snapcraft is that? the code has examples for local sources, e.g. "source: ." or "source: my-app". however no absolute paths in the examples, so maybe thats the problem
<mvo> liuxg: could you try a relative path and put the source inside the dir? let me try to find you an example
<liuxg> mvo, snapcraft (0.4). it shall be latest.
<mvo> liuxg: yeah, that should be fine. here is a trivial example with local source https://github.com/ubuntu-core/snapcraft/tree/master/integration-tests/data/local-source
<mvo> liuxg: and here is one that uses a subdir https://github.com/ubuntu-core/snapcraft/tree/master/integration-tests/data/simple-maven
<mvo> liuxg: maybe thats helpful? i.e. put the snapcraft.yaml directly into your go source and use "source: ."?
<liuxg> mvo, this is the result of it http://paste.ubuntu.com/13225279/
<liuxg> mvo, do you mean that i need to move my snapcraft to the source code directory?
<liuxg> mvo, for go, I need to have a directory name to come out the final binary name, right?
<mvo> liuxg: hm, something funny is going on there, let me finish my current task and branch your code, it really should not crash like this
<liuxg> mvo, ok. thanks for your help. I think it is a common practice to have the code locally. Once everything is fine, then it is pushed to the github or whatever.
<mvo> liuxg: yeah and its supported in general, seems like there is a bug in the detection of whats local
<liuxg> mvo, right. please let me the result of your testing.  thanks
<dholbach> good morning
<liuxg> mvo, do you have any findings?
<mvo> liuxg: sorry, got distracted. I think its a bug in the go plugin code, I'm investigating a bit now
<liuxg> mvo, oK. thanks for the help. by the way, do we need to report a bug for it?
<mvo> liuxg: I think a bugreport is prudent, yes. at least it should not crash
<liuxg> mvo, OK. so, I just report a bug against for snapcraft at https://bugs.launchpad.net/snapcraft/+filebug
<mvo> ta
<liuxg> mvo, I have reported the bug at https://bugs.launchpad.net/snapcraft/+bug/1515132
<ubottu> Launchpad bug 1515132 in Snapcraft "Snapcraft crashes after defining a local source for a golang project" [Undecided,New]
<dholbach> liuxg, I think snapcraft might more be a thing for sergiusens and tedg to answer
<liuxg> dholbach, it is alright. I will check it with them later on :)
<mvo> liuxg: yeah, I poked it a bit but it seems like there is more to it, i.e. seting up a go workspace or copying it into the go workspace etc
<liuxg> mvo, setting a go env is straightforward. apt-get install golang, it will install everything, I think.
<JamesTait> Good morning all; happy Wednesday, and happy Armistice Day! ð
<longsleep> What is the best way to report and discuss security issues with Snappy?
<ogra_> file bugs
<Chipaca> longsleep: use the 'security' flag when filing the bug
<Chipaca> soffokl: uh, ouch?
<Chipaca> soffokl: are these errors in the host's dmesg, or in the vm's dmesg?
<soffokl> Chipaca, on vm's dmesg
<Chipaca> soffokl: from googling the error it seems to have something to do with weird disc configurations
<Chipaca> bah. "weird" for a vm or an iot thing
<Chipaca> like raid 6 on sas
<Chipaca> soffokl: e.g. http://unix.stackexchange.com/questions/34173/mptscsih-ioc0-task-abort-success-rv-2002-causes-30-seconds-freezing
<ogra_> especially since you wouldnt have a raid6 in snappy :)
<ogra_> why is that driver even loaded inside the VM
<Chipaca> dunno if it's raid6 :)
<Chipaca> but it seems to be sas
<Chipaca> which, sure, should work, but no idea how good/bad virtualbox's sas driver thing is
<Chipaca> also, always be suspicious of expensive storage hardware that just happens to have the same name as a secret agency
<Chipaca> :-p
<soffokl> my vm is just OVA from Snappy website
<soffokl> on the host system only single ssd
<Chipaca> soffokl: i don't know who or how we build those; could you look up how it's set up? in the vb settings i mean?
<soffokl> Chipaca, I tried to change every settings that i found in vm configuration, nothing changed
<soffokl> Actually, we found workaround, we converting img for KVM from Snappy page to vmdk and using it for virtual box. And it works fine :)
<ogra_> hmm, interesting
<soffokl> for OVA even copying 500MB file into VM freeze several times
<Chipaca> ogra_: do you know who builds the ova?
<Chipaca> sounds like something they need to know about
<Chipaca> aha!
<Chipaca> soffokl: bug in virtualbox
<Chipaca> https://www.virtualbox.org/ticket/10031
<ogra_> Chipaca, no, i dont
<ogra_> i'd expect the cloud people
<soffokl> Chipaca, Opened 4 years ago, hmmm
<frecel> ogra_: do you know anything about anyone actively working on a snappy build for intel edison?
<ogra_> frecel, nope, i dont ... i know that lool took a look at it ages ago and there were probs
<frecel> do you know when loop tends to hang out on irc?
<longsleep> Is there some gear so a snap can run its own config hook, or should that be handled by the snap internall?
<longsleep> i have a chicken egg issue, and need to make sure the config hook was run at least once before start
<longsleep> before start of a service in the snap i mean
<ogra_> longsleep, make it touch a stampfile, add a check for the stampfile to the startup script
<longsleep> ogra_: yeah, but how do i run the config hook from the startup script? Directly?
<ogra_> thats what i do
<ogra_> if there is no initial config file i run the config.sh script once in my snap
<longsleep> ok, i was wondering if there is a way to trigger whatever "snappy config" is doing
<longsleep> yeah makes sense, i can certainly do that
<ogra_> snappy config only pipes strings into your hook anyway
<ogra_> or rather "a string"
<ogra_> :)
<longsleep> right, but maybe it does or will do something more
<ogra_> i think there was a bug open to restart the service once it applies a config, but that wont affect you on first start
<ogra_> thats the only planned enhancement i know about
<longsleep> ogra_: yes, i think i created that bug
<longsleep> ok
<longsleep> fair enough
<ogra_> ask Chipaca, he migh know more :)
<Chipaca> me? i know nothing
 * Chipaca <- in a meeting
<jdstrand> sergiusens: it might be a bug in the review tools. there is some pretty ugly code due to the click compat bits that I think might be getting confused (ie, it is trying to detect if the yaml and the click compat manifest are in sync cause if they aren't, the snap could be crafted)
<jdstrand> sergiusens: this won't be any issue once the pending feature branch mvo and I are working on lands (and I make the corresponding change to the review tools)
<jdstrand> sergiusens: Chipaca saw this too the other day. I think something changed in snappy that started triggering this issue
<jdstrand> sergiusens: can I have the snap?
<Chipaca> about what?
<Chipaca> jdstrand: is it about network-client?
<jdstrand> http://paste.ubuntu.com/13222977/
<jdstrand> it seems like snappy build isn't generating the compat apparmor profile correctly
<jdstrand> when you specify nothing, you are supposed to have the default template and 'network-client'
<jdstrand> oh, actually, I think I may know the issue
<jdstrand> this might be related to the networking -> network-client change
<jdstrand> I'll fix that real quick
<jdstrand> but again, all this compat code will be leaving both snappy and the review tools once mvo and I are down with the policy regeneration branch
<jdstrand> done*
<mvo> jdstrand: :-D indeed, thats going to be a glorious day. let me know how I can help further, I prepared the warning for the compatitbility if security-override.apparmor,seccomp is used and I wrote the ubuntu-core-launcher upate
<jdstrand> mvo: I saw! I think that is perfect. just ignore that it is there
<jdstrand> mvo: I'm preparing an apparmor upload that is related to snappy image policy uploads and the new /var/lib/snappy/apparmor/profiles dir
<jdstrand> mvo: I will have that done this morning and then get back to reviewing your changes
<mvo> yay!
<rickspencer3> stgraber, so, lxc is not working for me on my up to date (version 9) Beagle Bone Black: http://pastebin.ubuntu.com/13227521/
<jdstrand> man I hate this compat code in the review tools...
<mvo> jdstrand: it will be over soon
<mvo> jdstrand: soon we have it all replaced
<jdstrand> \o/
<sergiusens> mvo, well, well; there will be one more point of sync as snapcraft would be assembling the snap
<stgraber> rickspencer3: hmm, not completely clear what's the problem there. It looks like something's failing with lxc-net in there but then lxd itself is running or lxd-images would have failed differently...
<rickspencer3> stgraber, ok, what should I do?
<stgraber> rickspencer3: I'd recommend doing a reboot if you haven't yet, see if that gets things back in working order. If not, another possibility for that error would be that you're running out of disk space somehow.
<rickspencer3> stgraber, I did reboot
<rickspencer3> stgraber, what's a good way to check disk space?
<stgraber> rickspencer3: "df -a | grep writable" may do it, it's a bit of a mess with all the bind-mounts though
<rickspencer3> stgraber, http://pastebin.ubuntu.com/13227923/
<stgraber> that should be fine
<stgraber> ok, let me try to reproduce that issue on my beaglebone black here
<rickspencer3> thanks stgraber
<jdstrand> beuno: can you pull r543 to the store. this is needed to address the error in things like https://myapps.developer.ubuntu.com/dev/click-apps/3675/seq/4/
<jdstrand> beuno: beuno more review tools changes will be coming in the next week or so, but this one is kinda needed now
<beuno> jdstrand, yeap. cc/ pindonga
<jdstrand> beuno: also, I don't seem to be able to waive https://myapps.developer.ubuntu.com/dev/click-apps/3675/seq/4/ through
<sergiusens> jdstrand, beuno let me calm eveyone a bit though; only us devs see that as it is only in the tools-proposed area or xenial at most
<jdstrand> beuno: the first failure is what I fixed in the review tools. the second is Chipaca wanting access to snapd and I'm presuming he knows what he is doing :)
<stgraber> rickspencer3: fyi, I did manage to reproduce the issue here on my bbb, I'm trying to figure out what's going on now
<rickspencer3> thanks stgraber
<rickspencer3> stgraber, if you give me a link to the project, I will log a bug for you if you want
<stgraber> doh, found the issue
<stgraber> MemoryError
<stgraber> the bbb doesn't have enough RAM to process the cloud image :)
<rickspencer3> stgraber, ouch
<stgraber> looks like we could change lxd-images to use less RAM, it'd use more I/O though but probably still worth doing
<stgraber> I'll file an upstream bug for that
<stgraber> rickspencer3: https://github.com/lxc/lxd/issues/1300
<rickspencer3> stgraber, ok, doesn't sound like it will be fixed quickly
<rickspencer3> keep me posted
<stgraber> rickspencer3: fix should be pretty straight forward but it'll take another couple of weeks before it's in a release that hits snappy
<rickspencer3> stgraber, ack, I get it
<rickspencer3> np
<stgraber> rickspencer3: though you'll be able to grab the lxd-images script from git and manually use it until then
<rickspencer3> stgraber, ooh
<rickspencer3> ok, just let me know when you have something for me to try
<jdstrand> beuno, pindonga: actually, can you make that r544? r544 has the vendor checks removed too
<jdstrand> bug #1510522
<ubottu> bug 1510522 in Snappy "Remove vendor from meta" [Wishlist,In progress] https://launchpad.net/bugs/1510522
<jdstrand> beuno, pindonga: heh, make that r545 -- I missed sergiusens branch which I just merged
<stgraber> rickspencer3: https://github.com/lxc/lxd/pull/1301
<rickspencer3> stgraber, nice
<stgraber> testing on my bbb now (prepared it on x86 obviously :))
<rickspencer3> I'm working on something else right now, but if you want me to try your fix later, just post me some instructions
<stgraber> doh, /tmp is a tmpfs on snappy, so that's not helping much as it still ends up in memory
<stgraber> pretty sure /tmp on tmpfs is a bad idea for low-memory devices...
<stgraber> mvo: ^
<stgraber> rickspencer3: sure enough, the MemoryError is now replaced by a No space left on device :)
<rickspencer3> um
<rickspencer3> stgraber, so, I guess we need an image for a bigger sd card?
<stgraber> what we'd need is for snappy to detect that the board has low memory and setup /tmp as a path on /writable instead of an in-memory tmpfs
<stgraber> I'm basically doing that manually here now to confirm that this then all works
<mvo> stgraber: thanks! indeed, thats our default setup
<mvo> stgraber: i.e. use tmpfs
<stgraber> rickspencer3: http://paste.ubuntu.com/13228814/ <- confirmed that this works fine here
<stgraber> rickspencer3: so moving forward, hopefully snappy won't be using tmpfs for /tmp on beagleboneblack and LXD 0.23 will contain the lxd-images fix, at which point everything should just work (albeit very slowly, but that's because of the hardware)
<jerryG> how do i start mir manually?
<csanders> I'm running through the "your first app" tutorial. After building the example webcam .snap, can I locally install this on my Snappy Ubuntu Core VM?
<csanders> The guide moves on to "publishing apps" but doesn't mention installing this to test that it built correctly.
#snappy 2015-11-12
<csanders> Anyone here?
<liuxg> I am running a service in golang, in the code, there are some runtime outputs like fmt.Println. where can I find the output data?
<elopio> liuxg: sudo snappy service logs <name of the snap>
<liuxg> elopio, thanks. I just found it either :)
<elopio> that's good.
<liuxg> elopio, snapcraft does not support local file compilation for go, right?
<elopio> liuxg: not sure what you mean by that.
<liuxg> elopio, I have a webserver project, and it is source code is in a github project. is it possible to compile a local go file https://github.com/liu-xiao-guo/go-webserver/blob/master/snapcraft.yaml
<elopio> liuxg: sure, should be possible. There are two go projects in the examples: https://github.com/ubuntu-core/snapcraft/tree/master/examples
<liuxg> elopio, looking in the snapcraft.yaml file, all of the sources pointing to the github. they are not local..
<elopio> liuxg: so, I'm still not sure what you want. But you should be able a local path instead of a git location.
<elopio> plugin: go
<elopio> source: path/to/src.
<liuxg> elopio, I have changed path to local, it does not work.
<elopio> liuxg: then that's a bug. Can you paste the error?
<liuxg> elopio, https://bugs.launchpad.net/snapcraft/+bug/1515132
<ubottu> Launchpad bug 1499240 in Snapcraft "duplicate for #1515132 User friendly error missing when using go's source entry incorrectly" [Medium,Triaged]
<elopio> liuxg: ah, right. So it needs to ve a valid go path. Something you would use with go get.
<liuxg> elopio, so, how can I correct the issue?
<elopio> sorry for making it more confusing. I think we need to support your case, and that's a different issue.
<liuxg> elopio, yes, it is reasonable usage case for most the developers.
<elopio> liuxg: I'm not quite sure. In order to be importable, it needs to be in $GOPATH/src/
<liuxg> elopio, would you please make my bug as a valid request?
<elopio> liuxg: yes, tomorrow I'll talk about this with sergiusens.
<liuxg> elopio, ok. many thanks :)
<liuxg> elopio, do you mean that I need to set the $GOPATH myself to make it work?
<elopio> liuxg: I really don't know. I'd had to look at the go plugin source to understand how it works, but I'm having dinner :)
<liuxg> elopio, ok. thanks! have a nice dinner.
<elopio> liuxg: for now you can push your source to github or launchpad.
<elopio> if it's a valid source for go get, it should work with the git plugin.
<liuxg> elopio, the thing is that some projects may not be open projects :) and also, in order to build it, we have to always push it, it is troublesome. yes, for the short term, github works.
<elopio> yeah, your use case is valid. Take a look at the bug tomorrow morning
<Bluefoxicy> What's going on with snappy?
<Bluefoxicy> is this going to be the new thing?  Am I going to install ubuntu-gnome under snappy one day?
<elopio> Bluefoxicy: one day, sure.
<Bluefoxicy> elopio: want to see something from 2004?
<elopio> Bluefoxicy: I'm not particularly interested in 2004, no.
<Bluefoxicy> heh
<Bluefoxicy> so how does snappy work, anyway?  The root is read-only, you put an image on top, can roll back if it doesn't work?
<elopio> Bluefoxicy: you have two partitions. When you start, the two are the same, the latest image.
<elopio> When you update, you put the new image in the second partition.
<elopio> You reboot to that other partition, and if it fails the system reboots on the first partition.
<elopio> if it works but you don't like the new version, you can manually roll back to the first partition too.
<Bluefoxicy> finally.
<Bluefoxicy> Now maybe one day we'll get automatic just-in-time security updates.
<elopio> liuxg: GOPATH is set to builddir. And pull always does go get. So there's no workaround for your case, we'll need to extend the plugin.
<Bluefoxicy> elopio:  does the tech this runs on have the capability to detect and react to file access before it goes through, or is that still not part of the OS?
<liuxg> elopio, ok. got it. so the bug is a valid bug, right? I think it is a little different from the said bug.
<elopio> liuxg: I think it's valid, and shouldn't be duplicated. Need to convince Sergio, which shouldn't be hard.
<elopio> and you also pointed to a case we had not considered. If the github or launchpad repo is private, we need to handle credentials.
<elopio> Bluefoxicy: not sure what you mean. The snaps, as we call the packages for snappy, have a local working space. They can only touch files in their working space.
<liuxg> elopio, yes, thanks for your understanding
<Bluefoxicy> elopio:  back in 2005 I wrote about plans I never got to for making an OS that essentially isolated the base installation from the rest of the system by using unionfs to mount over it.  It was crude.  One of the things I described was detecting access to files and responding accordingly--notably, with an integrated package manager that would recognize when you tried to access an executable or library from a package with a secur
<Bluefoxicy> ity update, and immediately install the update.
<Bluefoxicy> don't ask me why I thought this was a good idea
<Bluefoxicy> at the moment, I still think it's an interesting idea; actual merits are debatable.
<elopio> Bluefoxicy: it's interesting to check for updates just-in-time. What we have is a daily autoupdate.
<Bluefoxicy> in any case, the technology going into things like coreos or snappy is ...better than what I Had on hand.
<Bluefoxicy> elopio:  yes, but you have the obvious problem of a program halting for 10 minutes while it downloads and installs a bunch of dependencies
<elopio> Bluefoxicy: it would be interesting to have push notifications for security updates.
<elopio> on the phone we have that.
<Bluefoxicy> haha.  Perhaps, but that's a whole different can of worms
<elopio> when there's a new update, you get a message and you can manually install it. Or configure your phone to autoinstall updates on wi-fi.
<Bluefoxicy> yeah.
<elopio> we'll have to get that working on top of snappy at some point.
<Bluefoxicy> delta debs would be great.
<Bluefoxicy> delta updates have been a topic of debate and salivation for over a decade
<Bluefoxicy> Has anyone thought of an unpatch-and-patch model yet, where you send the delta for both release base and installed, as well as the delta for current and release, so as to first build an as-installed deb, then make that a release deb, and patch that into a current deb?
<Bluefoxicy> I guess you can do the same with snaps
<Bluefoxicy> The ability to send half a megabyte to update LibreOffice would make JIT upgrades reasonable I think
<elopio> Bluefoxicy: delta downloads works on the phone already. Needs some more thinking on snappy, because of the format of the snaps.
<Bluefoxicy> nice
<elopio> but there is no patching in snaps. You apply the patches in your repository, and then generate the snap from that repo.
<Bluefoxicy> How will the desktop work?  Will it install all desktop applications in one container, or will it provide containers for Chromium and Thunderbird and such and somehow make application links in the desktop that just work?
<elopio> Bluefoxicy: that's still work in progress. There will be a snappy personal, which will work like the phone on desktop.
<elopio> we'll have to package thunderbird and chromium as snaps for them to work with all the security and isolation.
<elopio> there will be a classic mode in something more light than a container, that will let you install debs.
<elopio> also work in progress.
<Bluefoxicy> interesting.
<Bluefoxicy> I can't see why all this wasn't done years ago, other than that nobody thought of it.
<elopio> Bluefoxicy: go to github.com/ubuntu-core/snappy. You'll have fun there.
<elopio> Bluefoxicy: I think there were more important problems to solve years ago.
<Bluefoxicy> perhaps.
<elopio> the users of desktop were happy with apt-get upgrades and not really interested in a certified bullet proof machine
<elopio> and on the phone we were struggling to get linux running, like openmoko. Android changed everything.
<elopio> and there was no beaglebone or raspberry pi.
<elopio> this is a great momment to be developing for linux. Lots of things to do.
<Bluefoxicy> I always wanted computers to be magic.
<Bluefoxicy> I remember configuring my PC and laptop to trade processes between them.  OpenMosix would let them send stuff over the network to execute on other machines.  Dragonfly BSD has this thing where you can freeze a program, then thaw it later--dump its entire execution to a file, boot a new kernel, then continue executing.
<Bluefoxicy> and then there's Minix
<Bluefoxicy> now we have PCs the size of credit cards what can run programs in isolated contexts, pop them in and out, and cluster together to move applications around to wherever there's execution space.
<Bluefoxicy> elopio: and all this stuff is trying to target phones and desktops.
<Bluefoxicy> Do you know what I've been fantasizing in my head for the past 3 years?
<Bluefoxicy> You're running Chrome on your phone, that little browser interface set up for it, the way it runs on android
<Bluefoxicy> then, you pop it in the dock, and your 40 inch 4K display shows you an X or Wayland or whatever display, and taht little chromium window turns itself into a desktop window.
<Bluefoxicy> a phone display over here, a desktop display over there.
<elopio> Bluefoxicy: ah, but where have you been the past months? Let me look a video for you.
<Bluefoxicy> people are like, "We could have it reboot into a full desktop OS..." and I'm like "Screw that, you could have it reshape itself depending on what kind of terminal it's connected to!"
<Bluefoxicy> they're actually doing this?
<Bluefoxicy> I've been awake too long.
<elopio> Bluefoxicy: https://youtu.be/hLYvy1tPKtQ?t=10m4s
<Bluefoxicy> elopio:  I see that it plugs in and runs a program in a window
<Bluefoxicy> but I don't see everything already running suddenly exporting its display to a desktop display on connection
<elopio> my slimport cable hasn't arrived, so I haven't checked it.
<elopio> but that should work, if not now, soon.
<Bluefoxicy> cool
<Bluefoxicy> it's also weird that it gives that MegaBloks interface when plugged into an enormous tv with a mouse and keyboard, instead of a proper UI.  It's not a gigantic Android tablet.
<Bluefoxicy> I suppose the goal is eventually to make it behave like a PC when plugged into appropriate peripherals, instead of like a cell phone hooked up to a giant screen
<elopio> Bluefoxicy: that's because on a TV you will usually be far from it, so you need the icons and fonts to be big.
<elopio> when you connect it to a monitor, the pixel density is different. The fonts will be smaller because you are expected to be closer to the monitor.
<Bluefoxicy> I didn't mean size
<Bluefoxicy> I meant the visual style is that of a child's toy.  I guess that's a minor complaint, considering just how bad modern UI design has become from a functional perspective.
<elopio> well, yeah, that's the ubuntu sdk style.
<elopio> I like it.
<Bluefoxicy> There was a time when everything was a mess; then we learned to put things in nice groups in front of the user, where expected, and to have advanced functions tucked away with sane defaults you could revert to if the user decided to go hunting for things to tweak.  Now all those advanced features are completely removed, and you get stupid crap like a phone that only sends a 200kbyte MMS on a carrier who allows 1Mbyte MMS, becau
<Bluefoxicy> se nobody wants the user to raise the limit and break their MMS.
<Bluefoxicy> Android is particularly littered  with gems of bad UI design like that.
<Bluefoxicy> And here I am complaining about shiny boxes being too shiny.
<elopio> :)
<elopio> it's good. It's free software. If you don't like the shine, go and change it.
<elopio> some decissions are going to be hard to tweak. But even now you can put plasma movil on your ubuntu phone instead of unity.
<Bluefoxicy> You do understand that's a false choice unless somebody else does it first, right?
<elopio> other options will come too.
<elopio> Bluefoxicy: why somebody else?
<Bluefoxicy> Most people can't just go about changing things.  Hell, even Ubuntu and RedHat can't go about just changing things; they invest an immense amount of R&D into stuff like this.
<Bluefoxicy> elopio:  a lot of people would have to invest a lot of labor time up front to develop the skills required to make any specific changes to open source software
<Bluefoxicy> it's like saying if you don't like the trucks Chevrolet sells, why not build your own?
<elopio> I'm not saying that it will be easy. I'm not even close to say that your change will look good. But it's possible, the only thing you need is time and an itch.
<Bluefoxicy> Financial considerations aside, do you even know how to engineer an automobile?
<Bluefoxicy> right
<elopio> Bluefoxicy: that's different. The Chevrolet also involves money.
<Bluefoxicy> elopio:  even if it didn't, it would involve a lot of engineering knowledge.
<elopio> but if I have the money, I also have the potential to hack my car. And it will probably be a lot harder, because all the sources of it are closed.
<Bluefoxicy> I'll probably drive myself insane teaching myself to program so I can write video games.  Nothing I can't handle, although my mind is breaking under the strain already.
<elopio> Bluefoxicy: yeah, but engineering knowledge is something you can earn by investing time.
<elopio> so not *you*. But anybody else with the time can do it.
<Bluefoxicy> elopio:  to be precise:  anybody with the time and with nothing better to invest the time in can do it.  We're getting into an economics discussion, though.
<Bluefoxicy> which irritates me these days, ever since I figured out how to solve poverty and discovered nobody cares.  I've started to hate politics, but I guess I'm catching up to everyone else in that regard.
 * Bluefoxicy sleeps.
<elopio> bye.
<liuxg> elopio, ping
<elopio> liuxg: tell me.
<liuxg> elopio, I am now trying to cross-compile my project for armhf. I found a bug related to snapcraft at https://bugs.launchpad.net/snapcraft/+bug/1514650
<ubottu> Launchpad bug 1514650 in Snapcraft "Building golang project on ARM board gets "imports runtime: C source files not allowed when not using cgo or SWIG" error" [Undecided,New]
<liuxg> elopio, how do you normally compile a project for armhf so far? cross-compile is not supported by the tool.
<elopio> liuxg: and probably won't be supported. The discussions so far point to running snapcraft on the target.
<elopio> liuxg: so, get snappy running on an arm board, install lxd and start a lxc. Install snapcraft there.
<liuxg> elopio, yes, that is currently what I am doing. I am using a docker, inside it, I install a armhf ubuntu
<liuxg> elopio, lxd seems not supporting armhf so far.
<elopio> so let me look at the bug.
<liuxg> elopio, ok
<elopio> liuxg: what does gvm do? How is it fixing it?
<liuxg> elopio, I search for some posts, it asks me to do install sth go1.5. I just installed half way, and it started to work.
<liuxg> elopio, I think the installation must have some problem with it for the golang for the image.
<elopio> liuxg: could you try with an empty lxc, just with snapcraft installed? Just to rule out a problem in the docker container.
<liuxg> elopio, have you tried that solution before? if you have the guide for me, please send it to me. thanks
<elopio> liuxg: I have compiled some packages in lxc. I don't remember if I tried go.
<elopio> liuxg: https://plus.google.com/+St%C3%A9phaneGraber/posts/aX6vogzEQ1X
<liuxg> elopio, could you have a try for my project? it is a very simple one.
<liuxg> elopio, if it does not work, it won't work in my place as well.
<elopio> liuxg: I can triage your bug tomorrow. It's already midnight and flashing my bbb takes time.
<elopio> I've been trying to leave since your first ping :)
<elopio> damn tests that don't want to be green.
<liuxg> elopio, ok. many thanks. if you have any result of it, please update me :)
<elopio> liuxg: sure, I'll comment on the bug.
<liuxg> elopio, I am really sorry for that. have a good sleep!
<elopio> not yet, but soon.
<liuxg> elopio, :)
<chiluk> Hey guys is there a how to on how to cross-arch snap?
<chiluk> basically I'm trying to create a snap package on my amd64 machine that I'd like to put on my completely useless raspberry pi
<chiluk> pi 2 actually.
<chiluk> basically when I go to stage my snap it just gets created for my local architecture... as this is intended for embedded I assume you guys have this figured out already since only a small percentage of us are using arm-books
 * chiluk goes to sleep and hopes answer is awaiting him in the morning.
<liuxg> chiluk, I just got a Chinese article for it at http://blog.csdn.net/ubuntutouch/article/details/49780767? you may use google translate for help :)
<dholbach> good morning
<fgimenez> good morning
<davidcalle> Morning o/
<JamesTait> Good morning all; happy Thursday, and happy Pizza With The Works Except Anchovies Day! ð
<longsleep> So, since when does Snappy wait for networking on boot, seems like i missed that. snappy-wait4network.service does block until there is a default route .. :/
<mvo> ogra_: did you trigger a 15.04 build ? I noticed there is one running right now.
<mvo> ogra_: i.e. I would like to start with the stable release checklist and promote the current edge to alpha so that fgimenez can start the upgrade/rollback test process
<fgimenez> mvo, ogra_ ping me when ready
<mvo> fgimenez: amd64 is ready in 15.04/alpha now
<fgimenez> mvo, ok thanks, on it
<mvo> fgimenez: great, thanks
<mvo> fgimenez: armhf is ready in 15.04/alpha too
<mvo> fgimenez: and i386 in some minutes
<fgimenez> mvo, ok thanks, having them in alpha make things easier
<ogra_> mvo, see other channel
<fgimenez> mvo, the update -> rollback -> update -> rollback ... went well for amd64, from 16 to 17; but there are problems with the integration suite, 11 tests are failing with "Error: another snappy is running, try again later"
<fgimenez> mvo, i think that we hit this some days ago, i'll try to find the root cause of this, maybe we can make the tests more resilient
<mvo> thanks fgimenez, thats interessting, we did disable auto-pilot in the tests didn't we?
<fgimenez> mvo, yes, it's disabled at the beginning of the suite after each reboot
<fgimenez> mvo, it seems that the problem comes from https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/autoupdate-msg_test.go, we are not stopping snappy-autopilot after the test
<fgimenez> mvo, with that in place, and modifying the expected message, the suite seems to be running fine, i'll prepare a branch with the changes
<mvo> fgimenez: \o/
<mvo> fgimenez: thanks for digging and finding it!
<fgimenez> mvo, np :) let's see if all goes fine with the suite
<fgimenez> mvo, yes, the complete suite in amd64 is ok, i'm currently with rollback -> update -> rollback in bbb, fine too so far
<fgimenez> mvo rollback -> update -> rollback -> update .... worked well in bbb, now running the suite
<mvo> fgimenez: \o/
<mvo> fgimenez: I had to do another build for the image, its now in alpha for all arches. sorry for that, I'm afarid there is a re-test required. should be virtually identical to the last one but one never knows
<ogra_> well, we are waiting for a system-image merge, this wont be the last
<ogra_> and we really should only copy the last one to alpha since that is supposed to be for testing satble->stable updates
<fgimenez> mvo, ok, np
<fgimenez> mvo, the suite works fine in amd64 #18, now trying 16 -> 18 -> 16 -> 18...
<mvo> fgimenez: \o/
<fgimenez> mvo, update+rollback ok too, on to bbb
<jdstrand> beuno, pindonga: ok, there is one last change for the vendor bug. instead of pulling r545, please pull r547 (or later)
<jdstrand> mvo: hey, https://github.com/jdstrand/snappy/pull/6 has a merge conflict
<mvo> jdstrand: let me fix
<dholbach> STRAW POLL: Yes/No to a bot which shares new Askubuntu questions about Snappy in this channel?
<mvo> jdstrand: should work now, contains a bit of extra stuff because I merged master
<ogra_> dholbach, yes
<ogra_> (until the traffic gets high indeed)
<jdstrand> mvo: thanks
<fgimenez> elopio, the image validation goes good so far (suite and update+rollback on amd64), they are published in the alpha channel
<ogra_> fgimenez, dont forget there are two more arches to test this time
<ogra_> (once we actually have the final image)
<elopio> fgimenez: nice, thanks.
<elopio> ogra_: wait, why two more? not just armhf?
<fgimenez> ogra_, plano and raspi2_armhf right?
<ogra_> fgimenez, yeps :)
<fgimenez> elopio, ogra_ i can go for raspi2
<ogra_> cool
<elopio> we don't have planos to test.
<ogra_> we're just waiting for a final fix for system-image to actually make it pick the right device tarballs
<elopio> the certification team has been taking care of that.
<ogra_> right
<ricmm> mvo: did we ever land the u-d-f branches for 128 mb and the other thing?
<ricmm> the dst/target bit
<ogra_> ricmm, i dont think so
<ogra_> (or at least it didnt reach me ... my last weeks kvm image still has 64M)
<ricmm> ok
<ricmm> WARNING: this option should only be used to build azure images
<ogra_> yeah
<ogra_> ignore :P
<ogra_> we need to get rid of that
<longsleep> Hey, i just have the case where an snappy update did not clean up old systemd services from two snaps - so now there are the new and the old systemd service and the old fail to start - any idea what could cause this?
<longsleep> i typed snappy update, and it updated a new ubuntu-core and two snaps in that order
<fgimenez> elopio, the rollback test is failing on bbb 1504/alpha #17, could you please confirm? i'm going to try now the update + rollback from #15 to #17
<elopio> fgimenez: ok, let me flash it.
<fgimenez> elopio, there are other two errors, failover zerosize initrd (removing the check for mode=try works fine) and initramfs, but they are not related to the image
<mvo> ricmm: hrm, the branch did not land, there was a tarmac failure. *sigh* let me fix that
<ricmm> hurgh
<mvo> ricmm: so the dst change landed
<mvo> ricmm: I land the 128mb one now
<mvo> (or try to)
<ricmm> oh, those, I thought you meant image
<ogra_> mvo, there might be other u-d-f issues
<ricmm> err, snappy
<mvo> ogra_: hm?
<ogra_> i cant get the rpi2 to boot
<ogra_> it looks like the error i usually get if writable doesnt contain the cloud-init files
<ogra_> trying to verify that atm
<ogra_> yeah, writable is completely empty for me
<ogra_> mvo, afaik u-d-f usually puts the cloud-init stuff there when creating the img
<mvo> ogra_: uh, so thats a regression? but it was not released in a while iirc
<ogra_> yeah, thats werid
<ogra_> i dont understand that
<elopio> fgimenez: having problems here. The serial console only prints Cs. Have you seen that?
<elopio> trying again...
<fgimenez> elopio, nope, here works fine
<jdstrand> mvo: I'm unable to install docker with your branch
<elopio> tried 17 and 18, with two different bbb, two different sd cards.
<elopio> damn it, what did I break?
<fgimenez> elopio, 18? the tip of 1504/alpha is 17, right?
<elopio> fgimenez: ahhhh, stupid. I'm flashing 18 amd64...
<elopio> not enough breakfast today.
<fgimenez> ahh those Cs are pretty significant :)
<fgimenez> elopio, 15 -> 17 -> 15 -> 17 -> 15 ... works fine, btw i've confirmed that snappy_mode doesn't change after snappy update http://paste.ubuntu.com/13240185/
<fgimenez> leaving, have a nice day o/
<kyrofa> So say I'm developing an app to be packaged in a .snap and I'm running into apparmor denials when installed. Is there a Snappy way to debug this? Normally I'd just set it to complain mode, but ubuntu-core-launcher is the thing enforcing the profile...
<jdstrand> kyrofa: snappy install snappy-debug, then run in one console 'sudo snappy-debug.security scanlog' while exercising your app in another
<kyrofa> Ooo! Thanks jdstrand
<jdstrand> dpm_: fyi, that ^ is the sorta thing I'd love to point people to when the 15.04 developer doc is available (see snappy-app-devel@, 'Adding custom apparmor rules' thread (I was talking with dholbach, but he is eod now I guess))
<dpm_> jdstrand, there is an easy way to point people at this in the meantime: why not make it an ask ubuntu question?
<jdstrand> dpm_: well, sure, but the larger point isn't that specific question, but that we need the 15.04 dev doc out there so people can tie everything together
<plars> mvo: Hi, are there any details regarding the changes to core images that gustavo mentioned in his email?
<plars> mvo: I'd like to know sooner than later if they will break our automated provisioning in any way
<dpm_> jdstrand, gotcha, I hadn't seen the thread until now, now I can see the context of the question
<ogra_> mvo, triggering a new 15.04 edge build for a fixed raspi2 device tarball
<rickspencer3> jdstrand, hi, I am trying to run fsweb from a snap on my rpi2 and bbb, and fsweb says that it doesn't have permissions to open /dev/video0
<rickspencer3> does this look right for hw-assign?: sudo snappy hw-assign rest-cam.sideload /dev/video0
<jdstrand> rickspencer3: yes
<jdstrand> I actually have to step away for an appt. if you have other questions, please feel free to ask tyhicks (or ask me and I'll answer when I get back)
<rickspencer3> will do
<mvo> plars: d you use ubuntu-device-flash? if so, you may not need anything, or maybe change the parameters how u-d-f is called slightly the details are not fixed yet. essentially you need to tell it what os and kernel you want
<mvo> ogra_: ta
 * ogra_ twiddles thumbs waiting for the importer
 * genii makes sure ogra_ has enough coffee to stay awake
<ogra_> hah, always :)
<plars> mvo: yes, I do use udf, but just wondering if there were details yet
<mvo> plars: we may make it transparent
<mvo> plars: i.e. the gadget snap defines kernel/os so for you nothing changes
<ogra_> sudo ubuntu-device-flash core --oem pi2.canonical --channel edge --enable-ssh --device raspi2_armhf -o rpi.img 15.04
<ogra_> ...
<ogra_> Summary:
<ogra_>  Output: rpi.img
<ogra_>  Architecture: armhf
<ogra_>  Channel: edge
<ogra_>  Version: 59
<ogra_> \o/
<elopio> \o/
<genii> Hm
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ snappy list
<ogra_> Name        Date       Version Developer
<ogra_> ubuntu-core 2015-11-12 59      ubuntu
<ogra_> pi2         2015-11-12 0.16    canonical
<ogra_> and it BOOTS !
<ogra_> ok, rpi stable is ready for consumption :)
<elopio> ogra_: stable?
<ogra_> mvo, elopio, i just copied the raspi2 59 edge image to alpha for testing
<ogra_> alpha 3 is all yours :)
<elopio> ok.
<ogra_> yeah, stable
<ogra_> i'm not sure if rollback to 2 will or should work, given the images have been produced quite differently
<ogra_> (but you can try indeed and all future images should support rollback/install)
<mvo> ogra_: worth re-testing the other ones too, just in case?
 * jdstrand -> back
<ogra_> mvo, well, they shouldnt have any changes, but sure
<mvo> ogra_: did you promote the current candidates (latest build) to alpha?
<mvo> ogra_: nevermind, I just did that
<mvo> elopio: if you could do a validation of alpha that would be great, I just promoted the latest build from ogra to alpha, if all is looking good I will promote to stable later tonight or tomorrow morning
<elopio> mvo: I'm on it.
<ogra_> mvo, oops, not yet
<ogra_> thanks !
<mvo> elopio: thanks! keep me updated :)
<elopio> mvo: sure. Testing rpi alpha #3 now.
<kyrofa> jdstrand, snappy-debug only seems to work if apparmor is in audit mode... is that right?
<kyrofa> jdstrand, is there a reason for that?
<kyrofa> jdstrand, I don't know a ton about apparmor, but I needed to change the regex "audit: type=1400 audit" to just "type=1400 audit" . After that, life-saver tool man
<jjohansen> kyrofa: where is that regex?
<kyrofa> jjohansen, snappy-security-scanlog line 77
<jdstrand> kyrofa: oh, interesting
<jdstrand> kyrofa: what kernel is this on?
<jjohansen> kyrofa: ah, okay /me is not familiar with that tool, but it really shouldn't be directly scanning the log
<jdstrand> jjohansen: it uses libapparmor but it filters slightly to grab just the seccomp and apparmor stuff
<jjohansen> jdstrand: doesn't really matter, that change isn't a kernel thing
<jdstrand> oh I guess not
<jdstrand> I'll update the tool
<kyrofa> jdstrand, jjohansen before I lead you on a wild goose chase, this is part of the effort to get snaps running on the current phone image, so it may very well be a difference there
<jjohansen> jdstrand: ah
<jjohansen> kyrofa: not so much a wild goose chase, as a log prefixing issue that has been seen before in different configs
<jjohansen> so its not just a phone issue
<kyrofa> jjohansen, ah, good deal. Yeah perhaps making that regex a little less specific would be good, then
<jdstrand> that is what I'm working on now
<kyrofa> Thanks jdstrand :)
<jjohansen> jdstrand: I am not sure a prefilter at this level is worth it
<jdstrand> jjohansen: we need to choose between seccomp and apparmor and we do that by looking for the regex. but, we can just do ' type=1400 ' and ' type=1326 '
<jdstrand> rather than having the 'audit' bits around it
<jjohansen> jdstrand: obviously doesn't know about the subversive plans to bring seccomp log parsing into libapparmor
<jdstrand> heh
<jdstrand> kyrofa: would you mind testing this: http://paste.ubuntu.com/13241898/
<jjohansen> but sure, what ever you need
<kyrofa> jdstrand, doing now
<kyrofa> jdstrand, the spaces are an issue. Here's a typical log for me:  [ 7486.263143]type=1400 audit(1447364595.911:238): apparmor="DENIED"
<jdstrand> huh
<jdstrand> ok
<jdstrand> kyrofa: guessing this'll do the trick: http://paste.ubuntu.com/13241961/
<kyrofa> jdstrand, bingo! Works great
<jdstrand> kyrofa: ok, snappy update should get you 0.5 with the fix
<kyrofa> jdstrand, best service in the business
<jdstrand> hehe
<jdstrand> welcome to snappy :)
<kyrofa> Thanks : )
#snappy 2015-11-13
<liuxg> I am now using snapcraft to build my project. I find that if I change my source codes, it does not pull automatically. I can pull it, but it seems that it does not automatically build it upon the dependency. how to deal with this?
<elopio> liuxg: sounds like this one https://bugs.launchpad.net/snapcraft/+bug/1477904
<ubottu> Launchpad bug 1477904 in Snapcraft "snapcraft.yaml needs to make all stages dirty (was: the can't add file without recreating entire package)" [High,Triaged]
<liuxg> elopio, yes, I need to pull the code every time, it wastes time
<liuxg> elopio, in fact, I want to compile  local source codes instead of pulling the code every time from the github, which takes a lot of time. sometimes, bzr projects are huge as well. I have to use snapcraft clean every time for a little change.
<elopio> liuxg: yup, we have to fix that. sergiusens is working on sources, please leave your comments on the bug so he takes into account your use case.
<sergiusens> liuxg, you are talking specifically about the go plugin, right?
<sergiusens> liuxg, you are talking specifically about the go plugin, right?
<sergiusens> elopio, https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/1473333/+merge/277412
<elopio> sergiusens: omw, things are happening :)
<elopio> let me give it a try.
<Bluefoxicy> okay why is there an amd64+generic and amd64-generic?
<Bluefoxicy> http://releases.ubuntu.com/15.04/
<elopio> sergiusens: you have a mess with the license headers in that project :)
<sergiusens> elopio, you don't say? I copied this from go-dbus I think
<Bluefoxicy> aw crud.
<Bluefoxicy> there are no mirrors with snappy
<Bluefoxicy> Hence it takes 1 hour to download
<Bluefoxicy> oh wait it's 15.04 not 15.10
<Bluefoxicy> and apt does not work
<Bluefoxicy> neither does dpkg-reconfigure keyboard-configuration
<liuxg> I have a executable binary called fswebcam (/usr/bin/fswebcam) in a snappy package, I want to use it to capture a picture as described in the https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/. I want to use golang to invoke it to capture a picture. How can I do it? currently, I am using the way at https://github.com/liu-xiao-guo/webcam-http/blob/master/api.go, is there anything wrong with it? thanks
<fgimenez> good morning
<mvo> hey fgimenez, good morning
<fgimenez> hi mvo, how's the release going?
<mvo> fgimenez: I think we are good, I was reading trello/tg/mail so far only but nothing that looks like a blocker so I will go ahead and do the promotion next
<fgimenez> mvo, great! :) let me know if i can be of any help
<JamesTait> Good morning all; happy Friday, and happy Kindness Day! ð
<mvo> fgimenez: if you have a moment, it would be great if you could do some smoke testing with the new webdm http://people.canonical.com/~mvo/tmp/webdm_0.10_all.snap
<fgimenez> mvo, sure, on it
<fgimenez> mvo, i'm getting this on kvm http://paste.ubuntu.com/13247033/, both rolling/edge and 1504/alpha, is it built for armhf?
<mvo> fgimenez: checking, sorry, I just had build it before leaving for lunch
<mvo> fgimenez: I had a unclean build env that caused this package to be broken, I uploaded a new version now that should be better.
<fgimenez> mvo, ok thanks, i'll try it now
<mvo> fgimenez: ups, sorry
<mvo> fgimenez: the url is not quite correct, one sec
<mvo> fgimenez: its actually now http://people.canonical.com/~mvo/tmp/webdm_0.10_multi.snap
<fgimenez> mvo, ok thanks
<mvo> fgimenez: fwiw, I did a quick test install on my bbb and it was fine
<fgimenez> mvo all seems to be working fine except for the remove buttons, with any installed snap/framework, when i try to remove i get "ERROR: snappy package not found"
<fgimenez> mvo, this is the body of the response from the server http://paste.ubuntu.com/13247844/, with a 500 error code
<fgimenez> the status "uninstalled" is strange, i get this from the list of snaps http://paste.ubuntu.com/13247865/
<sergiusens> elopio, https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/1473333/+merge/277412
<sergiusens> I fixed all your comments
<mvo> fgimenez: hm, interessting. so any removal fails right now. let me try
<elopio> sergiusens: needs fixing.
<sergiusens> elopio, nah
<sergiusens> :-)
<elopio> just drop the test. It's friday and QA knows it.
<sergiusens> elopio, done ;-)
<elopio> (that's a joke, of course. Don't drop the test :)
<sergiusens> elopio, too late
<sergiusens> elopio, just kidding ;-)
<sergiusens> elopio, should be fine now
<elopio> sergiusens: +1.
<mvo> fgimenez: I can reproduce the error you see
<mvo> sergiusens, Chipaca: if someone could help with  https://code.launchpad.net/~mvo/webdm/new-snappy/+merge/277433 that would be cool, hopefully something simple but with that branch fgimenez and I get "Error: snappy package not found" when trying to remove any snap. this seems to be workng ok with 0.9.4
<fgimenez> mvo, sergiusens, Chipaca the server returns this http://paste.ubuntu.com/13247844/ with a 500
<kyrofa> jdstrand, found another bug in snappy-debug. Is there a place to file bugs/submit MPs?
<jdstrand> kyrofa: https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-debug
<jdstrand> but just against the snappy project, but an MP is good enough for me
<kyrofa> jdstrand, on its way!
<kyrofa> ... right after standup
<Chipaca> mvo: is it bad if I jot that down as a "do over the weekend" task?
<Chipaca> mvo: or is this a blocker?
<mvo> Chipaca: never
<mvo> Chipaca: no, no not at all
<longsleep> Chipaca: Do you have a minute, i might have found an issue with the firstboot service boot order change
<mvo> Chipaca: I will see what I can do to control the damage, but only the "edge" channel of webdm is affected
<mvo> Chipaca: and once the release is out I should have some cycles again
<Chipaca> longsleep: certainly sir
<longsleep> Chipaca: problem is that now some snap provided services can run before firstboot
<longsleep> Chipaca: To be exact, the services which have no external networking, start on ubuntu-snappy.frameworks.target
<sergiusens> Chipaca, mvo fgimenez maybe we can just start using the rest api for removal, DONE ;-)
<sergiusens> mvo, oh, this is very specific to webdm and its build against new snappy APIs
<Chipaca> longsleep: augh
<longsleep> Chipaca: so i think, the snappy services need to wait on firstboot or something, not sure what happens when the frameworks target is run after firstboot instead of after run-hooks
<mvo> sergiusens: heh, indeed, maybe I should venture a bit into JS land
<longsleep> Chipaca: a crude workaround could be to add a fake external port to the snap which has config applied by firstboot, that makes such snaps to start after snappy-wait4network.service
<Chipaca> it's starting to feel like a game of whack-a-mole
<Chipaca> but without the cute eep sounds
<Chipaca> i need to sit down with graphviz and some patience
<Chipaca> or, well, somebody does :)
<longsleep> Chipaca: i am adding the ugly details to bug 1511435
<ubottu> bug 1511435 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap" [Critical,In progress] https://launchpad.net/bugs/1511435
<kyrofa> jdstrand, https://code.launchpad.net/~kyrofa/snappy-hub/snappy-debug_escape_regex_strings/+merge/277463
<jerryG> any1 know about opengl on snappy?
<jdstrand> mvo: https://github.com/ubuntu-core/snappy/pull/55#issuecomment-156482348
<jdstrand> kyrofa: thanks!
<mvo> thanks jdstrand
<jdstrand> mvo: thank you :)
 * jdstrand hugs mvo
 * mvo hugs jdstrand
<longsleep> sweet
<jerryG> status of opengl support on snappy?
<davmor2> jdstrand, mvo: man get a room alerady
 * Chipaca hugs mvo and jdstrand
<Chipaca> let's land that sucker
 * mvo hugs Chipaca and davmor2
<Chipaca> davmor2: you're just jealous of our love
<longsleep> feel the love in snappy channel
 * jdstrand hugs Chipaca, davmor2, mvo (again) and longsleep :)
<Chipaca> jerryG: ç¡
<davmor2> okay okay I feel the love, /me hugs everyone
<jerryG> Chipaca: ä¸ºä»ä¹
<jerryG> Chipaca: https://lists.ubuntu.com/archives/snappy-devel/2015-October/001114.html
<jerryG> Chipaca: :{
<Chipaca> jerryG: you asked about âopengl supportâ. I can't even answer ânoâ to that question, because the question itself seems to assume things that aren't quite right
<Chipaca> jerryG: hence, mu
<Chipaca> jerryG: intel architecture snappy ships with the kernel-side gpu drivers, that are one part of what's needed for supporting opengl
<Chipaca> jerryG: there is a mir snap, that i think uses those drivers, but would you consider that âopengl supportâ?
<Chipaca> jerryG: there is no X in snappy, for example
<Chipaca> jerryG: not today; possibly never? I don't know
<jerryG> Chipaca: can i use sdl file with snappy ?
<Chipaca> jerryG: what's a sdl file?
<richmb> hello?
<Chipaca> richmb: o/
<zyga> hey
<richmb> I had some questions about the apt-get(non-snappy) version of ubuntu core
<richmb> https://wiki.ubuntu.com/Core
<richmb> this wiki page hasn't been updated in a while, but the releases seem upto date
<richmb> is this something that will be continued to be supported?
<Chipaca> no idea; i work on snappy itself Â¯\_(ã)_/Â¯
<richmb> we ran into some troubles trying to port snappy, but the ubuntu core rootfs was easy to bring up.
<zyga> richmb: what are you porting to??
<zyga> s/\?\?/?/
<richmb> an Altera Cyclone V arm Soc
<richmb> https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki
<liuxg> when I am trying to run a snappy command, it complains "another snappy is running, try again later". what is the reason for this? it happened a few times to me.
<ogra_> richmb, the ubuntu-core tarball has nothing to do with snappy, it is "just enough OS to run apt in a chroot" and is used for buildds and the like ... a snappy ubuntu-core rootfs has massively different content
<ogra_> snappy image currently come fron system-image.ubuntu.com
<ogra_> *images
<richmb> I understand that.  I wanted to know if the ubuntu-core tarballs would be available for future ubuntu versions.  As the wiki page hasn't been updated in a while.
<ogra_> richmb, you have to ask infinity in #ubuntu-devel ... it was never an official product i think
<Chipaca> liuxg: every so often a snappy update runs automatically
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ snappy list
<ogra_> Name        Date       Version Developer
<ogra_> ubuntu-core 2015-11-13 3       ubuntu
<ogra_> webdm       2015-11-13 0.9.4   canonical
<ogra_> pi2         2015-11-13 0.16    canonical
<ogra_> mvo, ^^^ looks all fine
<liuxg> Chipaca, i really do not want it to update. how can I stop it?
<Chipaca> liuxg: from memory: echo 'config: {ubuntu-core: {autoupdate: false}}' | sudo snappy config ubuntu-core - | grep auto
<richmb> thanks orga
<Chipaca> liuxg: although that might be autopilot instead of autoupdate, depending on what snappy you're running
<SaMnCo-desktop> getting the exact same situation, it seems the auto update features are active by default
<Chipaca> used to be called autopilot, becase we like confusing people ;-)
<Chipaca> SaMnCo-desktop: yes
<SaMnCo-desktop> Chipaca-  this is not cool. Back to Windows days where the system would reboot in the middle of an important task?
<liuxg> Chipaca, it seems it is an update. at one time, it prompted me there would be reboot sth like that.
<Chipaca> liuxg: yep
<Chipaca> SaMnCo-desktop: https://github.com/ubuntu-core/snappy/blob/master/docs/autoupdate.md
<Chipaca> SaMnCo-desktop: except, as i said, it might be called autopilot instead of autoupdate, depending on what you're running
<SaMnCo-desktop> Chipaca-  yeah, I have autopilot on my BBBs and Rpi2
<Chipaca> SaMnCo-desktop: and it's exactly like windows, except for everything
<Chipaca> SaMnCo-desktop: :-)
<SaMnCo-desktop> thx for the link, useful. Still, I would not have a behavior that forces the reboot of the system being active by default
<Chipaca> SaMnCo-desktop: i mean, it's an option you can turn off, and it prints out how to abort the reboot if you're logged in
<jerryG> Chipaca: sdl file is for opengl.  How do i make an image with intel opengl graphics drivers?
<SaMnCo-desktop> What if it's my drone in the sky?
<ogra_> SaMnCo-desktop, then turn it off :)
<Chipaca> SaMnCo-desktop: if you're putting the default image on a drone in the sky, you're going to have a bad time
<SaMnCo-desktop> ogra_-  I understand I can turn it off, I am just saying, something that reboots a device should not be active by default
<Chipaca> sigh
<liuxg> Chipaca, it will be finished once it is updated, right?
<SaMnCo-desktop> but well, we don't have to agree on everything ;)
<Chipaca> SaMnCo-desktop: yes, you're saying that. I disagree, because of several things
<ogra_> SaMnCo-desktop, if you produce a drone you likely use your own oem snap and will define what config options are on in it
<mvo> ogra_: \o/
<Chipaca> SaMnCo-desktop: the biggest is that it's not really on by default; it's on if and only if the gadget snap you used to build the image sets it
<mvo> ogra_: mail is out
<ogra_> mvo, yay
<SaMnCo-desktop> Chipaca-  so that means the images on the website have that active by default
<Chipaca> SaMnCo-desktop: the default image has it on, because the default image is for developers and clouds, where you most likely want to keep things up to date (and if you don't, you know you don't, and you disable it)
<SaMnCo-desktop> I just downloaded them this morning
<Chipaca> SaMnCo-desktop: and it's already on a drone in the sky? wow you're fast
<SaMnCo-desktop> :D
<SaMnCo-desktop> It's just I have 7 devices, downloading tons of stuff, and I didn't know about this thing, and it just means I have to run my scripts all over again
<SaMnCo-desktop> and it's slowww to run Docker / LXD stuff on BBBs...
<ogra_> err
<Chipaca> SaMnCo-desktop: why does an update mean you need to run your scripts again?
<ogra_> yes :)
<SaMnCo-desktop> Chipaca-  because it downloads stuff
<ogra_> everythin is slow on a BBB
<ogra_> except actual embedded stuff ...
<Chipaca> SaMnCo-desktop: but the download doesn't vanish on update
<SaMnCo-desktop> Chipaca-  it does on reboot though
<SaMnCo-desktop> anyway
<SaMnCo-desktop> that what scripts are for: automate stuff
<Chipaca> SaMnCo-desktop: why does the download vanish on reboot?
<SaMnCo-desktop> Chipaca-  I'm not following you. I had a docker image running, and a docker pull going on. The update killed Docker
<SaMnCo-desktop> as a consequence, both actions went down
<SaMnCo-desktop> and now the system is about to reboot. I can catch it (hopefully) but that means the system is not functional anymore
<SaMnCo-desktop> and I'll have to restart the commands
<SaMnCo-desktop> to start Docker and pull the images I want
<Chipaca> ah, the download was interrupted by the reboot, and it doesn't know to resume, now i got it
<Chipaca> i thought the download had finished
<SaMnCo-desktop> yeah, it's a trivial bash script
<SaMnCo-desktop> started remotely
<Chipaca> SaMnCo-desktop: well, a few things. one is that if you're on stable, updates are infrequent (not more than once a week, and that's pushing it)
<ogra_> well, supposedly once a month actually
<Chipaca> SaMnCo-desktop: the other is that you can disable it, but if you do it's on you to run update every so often to make sure you're current
<ogra_> we just had a few busy weeks
<Chipaca> yeah
<Chipaca> i said once a week because i think if we try to do more often than that mvo will undergo a phase change
<Chipaca> not sure if he'll melt or just evaporate
<Chipaca> but it won't be pretty
<SaMnCo-desktop> ok
<SaMnCo-desktop> the good side is that I now have a much more clever install / cluster management script for the next batch :)
<Chipaca> :)
<SaMnCo-desktop> if it had happened while I was afk, I would just have found things broken
<SaMnCo-desktop> now I know how to fix it :)
<Chipaca> SaMnCo-desktop: also, if you stop the reboot, the system isn't broken or inconsistent
<ogra_> you should just put it in a snap
<Chipaca> SaMnCo-desktop: the update is separate
<SaMnCo-desktop> ogra_-  yep, that's the plan
<Chipaca> SaMnCo-desktop: *also* also, note it updates everything, but only system updates cause the reboot
<SaMnCo-desktop> but right now it's for my talk at DockerCon, I don't have a lot of time
<Chipaca> ok, i'll stop chatting to you and let you get back to cussing the system into shape then
 * Chipaca goes for some more tea
<SaMnCo-desktop> :D have a good one
<longsleep> Reading the changes in the latest 15.04 stable release, what is actually the snappy REST API and how do i accesss it?
<longsleep> -s
<sergiusens> elopio, https://github.com/ubuntu-core/snapcraft/pull/97
<richmb> Are there any training or classes on snappy that could help with porting.
<tedg> richmb: We've done a few Snappy clinics that might help: https://www.youtube.com/playlist?list=PL-qBHd6_LXWYm8qttcXaosAIzejTa5IPj
<Chipaca> longsleep: wrt the REST API, hold on
<Chipaca> longsleep: there's a pull request with docs
<Chipaca> longsleep: but it is going to be revamped for 16.04
<Chipaca> longsleep: i'll get you the link of my internet holds up
<Chipaca> longsleep: https://github.com/chipaca/snappy/blob/rest-doc/docs/rest.md
<Chipaca> longsleep: i'll expect to get to merging that over the weekend, or early next week
<Chipaca> longsleep: in particular, the details of how to handle licensed snaps is going to be different real soon now
<bago> hi all
<frecel> bago: hey
<frecel> lool: ping
<bago> i have an android smart tv box and was wondering if it's ok to use the raspberry pi2 sd card ubuntu on it?
<bago> or the beaglebone 1
<bago> it is armv7 (cortex-a5)
<frecel> I see no reason why that wouldn't work since it's just another external input
<frecel> practically there is no difference between connecting a ps4 and a pi to your tv
<bago> so the snappy armhf rpi2 img using win32diskimager should boot from sd?
<frecel> bago: oh you just want to plug the sdcard to your tv
<frecel> without the rasperry pi itself?
<bago> no i want to run a persistent ubuntu on sd card but leave my android intact
<bago> i'm not sure what board my tv box has
<bago> it seems to be an odroid c1 with a tuner card
<bago> would it help if i linked the url to the box?
<bago> i basically want to run ubuntu on this http://www.smartvboxs.com/products/Amlogic-S805-Quad-core-1G-8G-Mali-450GPU-Android-4.4-VIGICA-C100S.html#.VkZgNHbhCJA
<bago> kodibuntu ideally but ubuntu would be a good start
<bago> is it possible to brick my device by trying?
<tedg> Yes, and it probably won't work.
<tedg> You really need to support the specific board when it comes to ARM stuff.
<tedg> It's not like x86 where the CPU and BIOS are rather standardized.
<bago> right so i'd have to port it to a new board?
<tedg> Correct, what ever CPU/configuration/etc that box is using.
<bago> how big would that be for an amateur?
<tedg> Reasonably large, but everyone needs to start somewhere. :-)
<bago> with a windows pc :)
<tedg> But if there's no CynogenMod port or ASOP tree, it'll be nearly impossible.
<bago> how would i find out if there is?
<tedg> Google :-)
<bago> i'm not really sure what board i'd google though tbh :)
<bago> i have had openelec boot from sd card so i assume it must be possible, it had no wifi but i think the driver is available it's just it was compiled on a similar device
<lool> frecel: pong
<frecel> lool: there are rumors going around that you were working on getting snappy to run on an intel edison
<frecel> did you have any succes with that?
<lool> frecel: yes and no; it's on the "nice to complete someday" list, but I'm happy to give you pointers if you'd like to resurrect
<frecel> I bought my edison to try building an ubuntu smartwatch so I would appreciate any help
<lool> frecel: so basically the top thing that was missing was initrd loading and someway to repartition the device safely; with latest released image and the new flashing tool, it's all doable, but I didn't have time to assemble an image
<frecel> lool: so at it's current state it just get's stuck in a reboot loop?
<lool> frecel: there is no current image for edison
<frecel> lool: did you document your work so far in any way? I have not done anything like this before so I'm not even entirely sure where to start to be honest
<lool> frecel: so the latest bootloader also added support for the external SD card
<lool> frecel: I'd start by creating an x86 SD card image and starting snappy manually with intel's kernel + snappy initrd + snappy rootfs from the u-boot prompt
<Chipaca> lool: the edison uses uboot?
<lool> Chipaca: yes
#snappy 2015-11-14
<bago> does anyone know a good guide for porting a new arm board?
<SamSpaces> Hi all, I've noticed a process called Rpigdnos. It returns after killing and deletion from /bin. Any ideas what that is?
<tbr> isn't that the NCTV backdoor?
<SamSpaces> I'm not a big on technical things, what's NCTV?
#snappy 2015-11-15
<JohnClare> Hi all. Trying to install docker on Snappy and keep getting hit with the following error: ERROR: Invalid policy version for 'docker_docker_1.6.2.005.json'. Skipping
<JohnClare> any ideas?
#snappy 2016-11-14
<darrenwu> store is not working right now. Web https://myapps.developer.ubuntu.com, "snap install" and  "ubuntu-image" cannot work.
<darrenwu> it's back now.
<foxmask> bonjello
<mup> PR snapcraft#902 opened: Snap revision prune <Created by seawaywen> <https://github.com/snapcore/snapcraft/pull/902>
<dholbach> good morning
<zyga> good morning
<crazyoldworld> what is a desktop app for snappy
<crazyoldworld> snapplets?
<crazyoldworld> snapple
<crazyoldworld> ok thanks
<mup> Bug #1641150 changed: snap hooks are not run with environment similar to apps: PATH, LD_LIBRARY_PATH <Snapcraft:New> <Snappy:Invalid by zyga> <https://launchpad.net/bugs/1641150>
<zyga> crazyoldworld: what do you mean?
<seb128> zyga, if I had to guess I would say he's asking how to call an application distributed as a .snap
<seb128> which is a "snap"  I guess
<mup> PR snapd#2271 opened: snap: add support for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/2271>
<davmor2> mwhudson: :(  still looping here on todays build
<MikeB_> I'm having trouble installing and running a system service in Classic mode on a Ubuntu Core.  I've changed /usr/sbin/policy-rc.d to allow the service to start by returning 104.  But invoke-rc.d complains the service file doesn't exist.  I checked, and it does exist in /lib/systemd/system.  Any idea why I'm having problems?
<mup> Bug #1641590 opened: snap --help outline text <Snappy:New> <https://launchpad.net/bugs/1641590>
<mup> PR snapcraft#896 closed: indicators: work with Content-Encoding set <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/896>
<mup> PR snapcraft#903 opened: store: download without login <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/903>
<zyga> dholbach: hey, do you remember that project that helped desktop snaps to run?
<zyga> dholbach: stuff like setting up gdk and themes?
<ssweeny> zyga: you mean https://github.com/ubuntu/snapcraft-desktop-helpers ?
<sergiusens> didrocks davidcalle is there anything to do with LP: #1618021
<sergiusens> ?
<mup> Bug #1618021: tour: cannot re-install hello-world-service without devmode <tour> <Snapcraft:Triaged by davidc3> <https://launchpad.net/bugs/1618021>
<zyga> ssweeny: yes, thank you!
<ssweeny> np
<dholbach> zyga, yes, that's the one :)
<didrocks> sergiusens: I guess davidcalle needs to reupdate the text to include --dangerous now
<davidcalle> didrocks: sergiusens: looking, but sounds likely, yes
<jamespage> ok so I really must be missing something obvious about organize/filesets
<jamespage> context is that there are a number of files in the release tarball that I'm snapping that are not installed by the python plugin
<jamespage> https://github.com/openstack-snaps/snap-glance
<jamespage> I basically need to push etc/*.conf|ini|json etc/glance/
<sergiusens> jamespage until I get the scriptlets for parts in place you will need to grab the source twice and use `dump` in one of them
<sergiusens> `organize` and `filesets` apply to the installed assets not the sources.
<jamespage> sergiusens, ok glad I had not missed something
<sergiusens> ogranize is like a dpkg-divert but both assets being valid
<sergiusens> err, I mean, the diverted asset being valid
<sergiusens> jamespage we have this same problem here https://github.com/snapcore/snapcraft/blob/master/demos/gopaste/snapcraft.yaml
<Exquisitus> hello everyone!
<Exquisitus> I have a question: my snapcraft maven plugin runs "mvn package" and pick up for the snap always the target/${app-name}.jar. Instead I want to wrap in the final snap a different jar executable
<Exquisitus> that is created in the root directory
<didrocks> sergiusens: any clue on the maven plugin? ^ (I never looked at it, only know about some hardcoded target paths). IIRC, you wanted some real world user experience
<mup> Bug #1641631 opened: Raspberry Pi images do not support boot from USB <Snappy:New> <https://launchpad.net/bugs/1641631>
<jamespage> sergiusens, ok I see got that working now
<jamespage> https://github.com/openstack-snaps/snap-glance/blob/master/snapcraft.yaml
<jamespage> sergiusens, one more question if I may - is there a nice easy way to extract something from the upstream release tarball/source to set as the version number?
<jamespage> pbr is quite good at generating versions based on tags
<jamespage> and I think that gets baked into the release and snapshot tarballs
<jdstrand> roadmr (cc, nessita): fyi, https://myapps.developer.ubuntu.com/dev/click-apps/5779/rev/373/ gives a 504 when clicking 'approve'. going back to the page seems to indicate it worked (ie, it is approved)
<jdstrand> roadmr (cc nessita): all of those should be approved, but there are only 4 left so I don't want to remove any more test cases
<nessita> jdstrand, checking
<jdstrand> roadmr: (for some wider context, see the plugs/slots thread I responded to today)
 * roadmr bumps into nessita while checking :D
<nessita> roadmr, I leave it to you, this sounds related to the approved interfaces/
<nessita> ?
<roadmr> jdstrand: btw, I see it has a nice payload; I'll deploy the stuff to auto-approve based on that this week
<roadmr> nessita: does it? do we have an oops?
<jdstrand> roadmr: ah great! :)
<nessita> roadmr, well, the package that is failing is the one with specific interfaces efined
<nessita> (is the first one I see)
<roadmr> nessita: the payload passing shouldn't cause a timeout, I'd suspect it's more related to number of published packages. But let's see
<nessita> roadmr, there are oopses for the soft timeout
<jdstrand> nessita: my reference to plugs/slots was not meant to indicate a problem there (/me has no insight on that) only that things are going to manual review cause plugs/slots being given to review tools hasn't landed yet
<roadmr> nessita: check the query count, https://oops.canonical.com/oops/?oopsid=OOPS-4c9cb191528bbc05f12c48a2abcaa764 we're running some queries over 300 times, this number matches the # of uploaded lxc snaps, so I suspect just some n+1 issue. Doesn't look related to the approved interfaces payload as IIRC we never iterate over all uploads for that
<nessita> yeah
<sergiusens> jamespage you can do it the other way around, $SNAPCRAFT_PROJECT_VERSION can be used in your `source` entry
<jamespage> sergiusens, oh neat
<jamespage> sergiusens, are there any conventions around use of numbers/codenames etc?
<sergiusens> for versions? not really, mostly up to you
<jamespage> great
<nessita> roadmr, any verdict?
<roadmr> nessita: there are 3 queries we run once for each upload of the snap, I need to track down where those come from and see if I can optimize them...
<nessita> roadmr, reindexing that package does not work either
<nessita> roadmr, so something broke regarding prefetching tables
<roadmr> nessita: oh was that already using prefetching?
<nessita> roadmr, yes, "a lot" :-)
<SuperJonotron> installing snap with --force-dangerous on a new system but complaining that --force-dangerous is an unknown flag now
<cwayne> try --dangerous
<SuperJonotron> cwayne, tried that too, same result
<SuperJonotron> i tired without either and no errors like I had before without that flat, maybe an update has relaxed something in the security  model for use of that flag?
<ogra_> --dangerous is set by default if your snap also uses --devmode IIRC
<SuperJonotron> yup, it does use devmode
<SuperJonotron> i guess the added --dangerous was in an update since i had to use both before
<SuperJonotron> not sure why it doesn't recognize the flag at all anymore though
<ogra_> yeah, that was a bit of a mess, but fixed for the image release two weeks ago
<roadmr> jdstrand: hello, the --plugs/--slots thing is now enabled in production in the store. Let me know if you have any questions about how it works or you find any bugs or problems
<roadmr> jdstrand: (it's controlled via a waffle flag so it's easy to disable if it gives trouble)
<jdstrand> roadmr: oh, that was quick. thanks! :)
<roadmr> jdstrand: haha yes :) we were just pending a deployment, I tested everything late last week
<mup> PR snapd#2246 closed: debian: add version 2.17 to changelog <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2246>
<jdstrand> roadmr: will you handle the lxd approvals or shall I (I don't want to remove the 504 test cases)
<mup> PR snapd#2272 opened: debian: add 2.17.1 to changelog <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2272>
<mup> PR snapcraft#866 closed: Login with option to agree to terms of service and human friendly errors <Created by psivaa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/866>
<mwhudson> davmor2: :(
<davmor2> mwhudson: see the email I sent out seems to only be on configured networks
<mwhudson> davmor2: ugh looks like i didn't upload the fix to the ppa :)
<mwhudson> s/:)/:(/
<davmor2> mwhudson: that's not gonna help then ;) So look again tomorrow then right?
<mwhudson> davmor2: yea
<mwhudson> davmor2: well, assuming my fix is right :)
<sea-gull_> hey #snappies! Do I understand correctly that anybody can now upload snappy packages without any kind of approval?
<mcphail> sea-gull_: anyone can upload a snap, but not all snaps can be uploaded by anyone
<Francesco_> Hi all
<roadmr> jdstrand: I think the reason for the 504s is clear, I guess it's ok if you handle those approvals
<Francesco_> sorry I am a noob can somebody please tell me what I have to enter to login to the ubuntu snappy store and install webdm
<jdstrand> roadmr: ok, thanks
<sea-gull_> mcphail: so who or how it's determined what can the given man upload?
<Francesco_> exit
<sea-gull_> for instance, I use latest git, and I would like to have it as a snap
<sea-gull_> what should I do to get or make it?
<sergiusens> sea-gull_ I wrote this on using snapcraft to get stuff onto the store if you want to check out http://blog.sergiusens.org/posts/Making-your-snaps-available-to-the-store-using-snapcraft/
<sea-gull_> sergiusens: thanks, looks useful
<sergiusens> sea-gull_ for more polished documentation, snapcraft.io is your go-to site ;-)
<sea-gull_> yep, I've skimmed through it already
<ahoneybun> bladernr`: heyo
<bladernr`> ahoneybun, howdy
<ahoneybun> let me open up the email on the desktop here and take a look
<bladernr`> Oh sure... no rush, by the way, it's a pet project.
<ahoneybun> it was for me as well
<ahoneybun> bladernr`: this is my current yaml file for it: http://pastebin.ubuntu.com/23477247/
<ahoneybun> I've recently restarted my effort to make it
<ahoneybun> so desktop/gtk3 or anything is deprecated
<ahoneybun> how do I write it?
<ahoneybun> without the " / ?
<mup> PR snapd#2267 closed: debian: add 2.17.1 to changelog <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2267>
<mup> PR snapd#2272 closed: debian: add 2.17.1 to changelog <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2272>
<ahoneybun> I just changed the desktop/qt5 to desktop/gtk3
<mhall119> Son_Goku: ping
<mhall119> zyga: Son_Goku: If we get snapd and snap-confine in to the CentOS repo you were planning on, what versions of CentOS would that be available on?
<Son_Goku> CentOS 7 only
<mhall119> ok, is there any possibility of getting it in 6.6?
<bladernr`> ahoneybun, so I've tried both by just staging the package from Ubuntu and your way, by pulling/compiling from source and both times I end up now with this
<bladernr`> http://pastebin.ubuntu.com/23477531/
<bladernr`> problem seems to be that the launcher (pithos) is still looking in /share, not $SNAP/share
<bladernr`> the configure.in file in the source has config options to specify the datadir and rootdatadir, so I wonder if there's a way to pass config options to snapcraft to force it to look in /snap/pithos/current/
<bladernr`> I don't understand how snapcraft prepends $SNAP in the environment though...
<bladernr`> but I don't have time to work on it anymore today, maybe later tonight or tomorrow or later this week.
<Son_Goku> mhall119, if it didn't require systemd, sure
<mhall119> what does CentOS 6 use, sysv or upstart?
<popey> mhall119: upstart surely?
<SuperJonotron> was working through a --force-dangerous or --dangerous issue earlier today, I removed it and the snap can install...the first time only
<SuperJonotron> every time after that the flag is required but rejected on the first install of a snap
<SuperJonotron> is there better syntax than that to install a newer version?
<mup> PR snapd#2273 opened: interfaces: add avahi-observe (LP: #1639967) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2273>
<popey> SuperJonotron: can you paste the entire terminal output of you doing the install?
<popey> SuperJonotron: also, what version of snapd package do you have, and what distro are you on?
<zyga> mhall119: I doubt that but let's get it into fedora first
<SuperJonotron> popey,  2.14.2~16.04+ppa215-1
<zyga> mhall119: checking one thing
<zyga> mhall119: I cannot say now, in any case it's a thing beyond the horizon today
<popey> SuperJonotron: what version of ubuntu you on?
<SuperJonotron> popeye, command "sudo snap install snap*.snap --devmode", error: error: cannot find signatures with metadata for snap "snapname.snap", adding the flag --force-dangerous works
<SuperJonotron> but will fail if it's the first installation of the snap
<SuperJonotron> popey, 16.04
<popey> right, I'd expect you to have to add --dangerous (or --force-dangerous in older versions of snapd)
<popey> 2.16 is the current version of snapd, so you probably need to "sudo apt dist-upgrade" your machine
<SuperJonotron> popey, thanks, i might just right into an installer script to try both to handle older versions
<mup> Bug #1641752 opened: request for snap interface that expose userspace device APIs <Snappy:New> <https://launchpad.net/bugs/1641752>
<Trevinho> jdstrand: hey, thanks for the fix for libappindicator...
<Trevinho> jdstrand: as for the setprocess policy, I've there's the process-control plug, but it has to be manually enabled... I guess UI will be there for handling such cases in the future... However, I was wondering wether it would be the case to make setpriorty to be allowed for snaps that want to control the child process with higher nice values...
<Trevinho> for example there are some tools for doing video rendering that reduce the priority of the child process (typically mencoder or ffmpeg)... That is a policy that I don't think would need any particular privilege.
<mup> Bug #1641758 opened: Allow to call setpriority on child processes when priority is lower than default <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1641758>
<jdstrand> Trevinho: yes, that will be coming soon (setpriority with nice values of greater than 0)
<jdstrand> Trevinho: hmm, but only on the current process. if for children, you are going to need process-control I think
<Trevinho> jdstrand: cool, I've opened a bug... I didn't find anything about that, so...
<Trevinho> jdstrand: mhmh, I see, but.. Why isn't that safe?
<Trevinho> if it's all inside snap...
<jdstrand> it would be safe
#snappy 2016-11-15
<jdstrand> it is that the sandbox doesn't have a way to express "setpriority for myself or children"
<Trevinho> mh, can't be something apparmor could be instructed to do?'
<jdstrand> neither apparmor nor seccomp have that ability, so you could set the priority of any other process to higher than your own
<Trevinho> mh, ok
<jdstrand> sure it could, that is just dev work and there is other stuff before that
<Trevinho> sure, sure... Just to give an idea :-)
<ahoneybun> bladernr`: yea the issue is that it's not looking at $SNAP/share/
<Trevinho> if it was feasible or not...
<ahoneybun>   /share/pithos
<ahoneybun> mhall119: any ideas?
<ahoneybun> http://pastebin.ubuntu.com/23477531/
<Trevinho> jdstrand: and... since you're here... is there anything going on for https://bugs.launchpad.net/snap-confine/+bug/1620442 ?
<mup> Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1620442>
<jdstrand> it should be. process-control will be there for while it isn't implemented
<jdstrand> it might be possible with PRIO_PGRP. it'll need investigating
<Trevinho> cool, let me know if there's somethiung possible... Otherwise maybe looking for procs coming from the snap as the possible targets would be maybe easier... dunnow
<jdstrand> Trevinho: as for auto-connecting process-control-- that is possible via snap declarations and the store. a reviewer can say 'sure this developer is trusted so I'll let this snap auto-connect process-control'
<Trevinho> ah, cool
<jdstrand> ok, I need to have some dinner
<jdstrand> Trevinho: see you later! :)
<Trevinho> jdstrand: as I was trying some electron apps... and well, the hack there is to just use browser-support plug, but... in theory once they've setpriority everything else would be unneed.
<Trevinho> jdstrand: sure, enjoy it!
<jdstrand> re https://bugs.launchpad.net/snap-confine/+bug/1620442, I've commented in the bug but haven't worked on it yet
<mup> Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1620442>
<jdstrand> I'll add that to my current policy work trello card
<jdstrand> Trevinho: ^
<jdstrand> ok, gone for real
<Trevinho> jdstrand: :-). Thanks.
<Pharaoh_Atem> mhall119: CentOS 6 uses upstart
<Pharaoh_Atem> mhall119: specifically, upstart 0.6.5
<mup> PR snapd#2254 closed: docs: fix path for source files location in HACKING.md <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2254>
<foxmask> bonjello
<liuxg> zyga, ping
<dholbach> hey hey
<mup> PR snapd#2250 closed: store: use range requests if partial files are available <Created by chipaca> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2250>
<zyga> liuxg: hey
<zyga> liuxg: how can I help you
<liuxg> zyga, thanks for your reply. today, I tried to duplicate your "reboot" interface. However, I did not find it after I successfully build the snapd following your instructions.
<zyga> liuxg: can you tell me more about the target device, did you perform all development locally?
<liuxg> zyga, your article at http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html is very informative. I am now trying it on Ubuntu Destkop 16.04. I want to understand how an interface/slot is implemented.
<zyga> ok
<zyga> liuxg: did you use refresh-bits to run snapd on your system?
<liuxg> zyga, I read yoru blog, and my reboot.go is like "http://paste.ubuntu.com/23479268/". is this correct?
<liuxg> zyga, yes, I followed your instructions at http://www.zygoon.pl/2016/06/making-your-first-contribution-to-snapd.html
<liuxg> zyga, after successfully build the code, but I did not see the "reboot" interface there.
<zyga> liuxg: ok, can you do two things please, first, pull new devtools, I made some improvements that I just pushed now
<zyga> liuxg: second, please pastbin your diff against master in snapd, that will help me to figure out what may be the problem
<liuxg> zyga, http://imgur.com/a/QCzcB, this the result
<zyga> liuxg: I suspect it might be related to the base asserrtion (maybe)
<zyga> liuxg: are you developing against master or against a particular tagged release?
<liuxg> zyga, ok.. thanks. I  will pull the latest devtool. By the way, reh previous ./restore-bit restore cannot revert back to the previous snapd. My colleauge also got this problem.
<liuxg> zyga, I am developing against the master
<mup> Bug #1641869 opened: openvswitch interface <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1641869>
<zyga> liuxg: ah, this is a known issue, it's related to the fact that snapd migrates the state format
<mup> PR snapd#2212 closed: spread tests: fix snap mode check <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2212>
<liuxg> zyga, so, do you have fix for it?
<zyga> liuxg: no, I don't know what the fix should be yet, backing up and restoring the state might be a simple start but it is hardly sufficient
<zyga> liuxg: snapd might grow support for reverting to older patch level (data format)
<liuxg> zyga, currently, I have to reinstall the snapd every time.
<mup> PR snapd#2065 closed: interfaces/builtin: use udev to export GPIOs to userspace <Blocked> <Reviewed> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2065>
<didrocks> zyga: jailmode not working with snap try or snap install in snapd   2.16ubuntu3 is a known issue?
<didrocks> I have a snap in devmode, installed it in jailmode and it's still allowed do listen to network or do similar things
<didrocks> mvo: any idea? ^
<zyga> didrocks: can you report a bug with all the details
<zyga> didrocks: and snap list output at the end please
<didrocks> zyga: I would like to have confirmation, but I can report a bug
<didrocks> as it's just a question of having a snap in devmode, install it with --jailmode
<didrocks> (and yeah, snap list confirms it's in jailmode)
<zyga> didrocks: hmm, can you look at /var/lib/snapd/apparmor/profiles/
<zyga> didrocks: and look at the head of the relevant profiles of the app
<zyga> didrocks: if you pastebin that I will have confirmation
<didrocks> zyga: http://paste.ubuntu.com/23479407/
<mup> PR snapd#2260 closed: tests: add test that ensures the right content for /etc/os-release <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2260>
<mup> PR snapd#2205 closed: snap, image: fix `snap download` and `snap prepare-image` running as user <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2205>
<mup> PR snapd#2207 closed: store: check hash in store.Download() (if we have a hash) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2207>
<zyga> didrocks: confirmed
<zyga> profile "snap.chuck-norris-webserver.node-service" (attach_disconnected,complain) {
<zyga> "complain" is the devmode trigger
<zyga> didrocks: can you report a bug with instructiosn on how to reproduce, I will fix it
<mup> PR snapd#2222 closed: tests: do not hardcode the size of /dev/ram0 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2222>
<didrocks> zyga: with some tests I hope for not regression again :p
<zyga> didrocks: obviously
<zyga> ogra_: he
<zyga> ogra_: hey :)
<zyga> ogra_: do you happen to have a gadget/kernel snap for beagle bone black?
<mup> Bug #1641885 opened: jailmode doesn't work with snap try or snap install <Snappy:New> <https://launchpad.net/bugs/1641885>
<didrocks> zyga: ^
<zyga> didrocks: thanks, I already triaged it
<zyga> tvoss: experimenting now
<zyga> tvoss: I hope to reproduce the issues you saw first
<tvoss> zyga: thanks
<mup> PR snapcraft#904 opened: WIP: Use pylxd instead of lxd command line (LP: #1641520) <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/904>
<shuduo> hello, i'm helping one customer to migrate their kernel snap from u-d-f to ubuntu-image. now we always meet timeout error as below:
<shuduo> sudo /snap/bin/ubuntu-image -c beta --image-size 4G --extra-snaps ./bubblegum96-gadget_0.1.0_arm64.snap --extra-snaps ./bubblegum96-kernel_3.10.0_arm64.snap -o bubblegum96.img bubblegum96.model
<shuduo> error: cannot fetch and check prerequisites for the model assertion: Get https://assertions.ubuntu.com/v1/assertions/account-key/6PVAOu6V-pOb7bCSIB9W0WRSnVZwySqShrne8zWWWhIh6oW65o1ynHD4XoT3wSzF?max-format=0:
<shuduo> net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
<shuduo> COMMAND FAILED: snap prepare-image --channel=beta --extra-snaps=./bubblegum96-gadget_0.1.0_arm64.snap --extra-snaps=./bubblegum96-kernel_3.10.0_arm64.snap bubblegum96.model /tmp/tmpk_f88lrl/unpack...subprocess.CalledProcessError: Command '['snap', 'prepare-image', '--channel=beta', '--extra-snaps=./bubblegum96-gadget_0.1.0_arm64.snap', '--extra-snaps=./bubblegum96-kernel_3.10.0_arm64.snap',
<shuduo> 'bubblegum96.model', '/tmp/tmpk_f88lrl/unpack']' returned non-zero exit status 1
<shuduo> is it a store problem or something mistake in command line of ubuntu-imag? thanks
<liuxg> zyga, this is the difference http://paste.ubuntu.com/23479536/ http://paste.ubuntu.com/23479540/ is there anything I missed?
<liuxg> zyga, Just now, I tried it again. I found that I missed the changes in the all.go, which was not mentioned in your blog. Here are all of the changes http://paste.ubuntu.com/23479617/. thanks for your help.
<jamespage> is there a good howto on writing and testing a new interface for snapd/snappy?
<jamespage> nm found http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html
<jamespage> pointed me to my error
<zyga> jamespage: hey
<zyga> jamespage: :-)
<jamespage> zyga, got me going in the right direction - I'd missed the addition to the implicit slots array
<zyga> jamespage: that's great, I'm planning on writing something new along the path there
<zyga> jamespage: suggestions on what would help are very much welcome
<zyga> liuxg: hey, I'm glad you sorted that out
<liuxg> zyga, yeah, I spent some time to figure it out. Frankly, I am not familar with the snapd design. Your blog is great!
<jamespage> zyga, I just need to figure out why openvswitch startup is trying to use systemctl :-)
<liuxg> zyga, I just tried the interface, and it truly rebooted my computer :)
<mup> PR snapd#2274 opened: interfaces: use sysd.{Disable,Stop} instead of sysd.DisableNow() <Created by mvo5> <https://github.com/snapcore/snapd/pull/2274>
<mup> PR snapcraft#902 closed: Snap revision prune <Created by seawaywen> <Closed by seawaywen> <https://github.com/snapcore/snapcraft/pull/902>
<mup> PR snapcraft#905 opened: Snap revision prune <Created by seawaywen> <https://github.com/snapcore/snapcraft/pull/905>
<wililupy> Question: Is it possible to make a snap auto-connect to slots? For example, my snap automatically consumes the network and network-bind slots, but I have to manaully connect network-observe and network-control.
<didrocks> wililupy: if you are a device owner, you can do that through assertions
<didrocks> but not on other devices, as those interfaces are considered privileges and not connected automatically on purpose
<didrocks> http://snapcraft.io/docs/reference/interfaces for the list
<tsdgeos> is this expected? http://paste.ubuntu.com/23479868/
<tsdgeos> or is it bad packaging?
<tsdgeos> shouldn't it be using the libs from the snap and not from / ?
<didrocks> tsdgeos: for base packages, if you don't ship them, it's using the system ones
<didrocks> like libc, opensllâ¦
<didrocks> ssl*
<Exquisitus> Hello, I have a problem publishing my snap
<Exquisitus> There has been a problem while analyzing the snap, check the snap and try to push again.
<Exquisitus> it is really too vague
<Exquisitus> what could be the problem?
<Exquisitus> thanks
<didrocks> Exquisitus: hey, that's the only message you are getting?
<didrocks> (mind doing a screenshot?)
<tsdgeos> didrocks: ok
<tsdgeos> didrocks: how is that going to work once those libraries get ABI changes? one won't be able to use the same snap in xenial and say zesty?
<didrocks> tsdgeos: in order to protect yourself against those, you need to stage them in your snap, indeed
<didrocks> (like the libc breakage we got between 15.04 and series 16)
<Exquisitus> yes it is
<Exquisitus> exquisitus@paponfix ~/P/iri-snapcraft> snapcraft push iri_1.1.0_amd64.snap  Uploading iri_1.1.0_amd64.snap. Uploading iri_1.1.0_amd64.snap [                                                                                                   ]   0% Uploading iri_1.1.0_amd64.snap [===================================================================================================] 100% Error while processing...|
<Exquisitus> There has been a problem while analyzing the snap, check the snap and try to push again.
<Exquisitus> I already tried to push 5 times
<Exquisitus> ...
<didrocks> ah, I guess sergiusens's branch will help getting more debug output
<didrocks> but I think you shuld see it as well on the web server
<didrocks> https://myapps.developer.ubuntu.com
<didrocks> do you have moreinfo there?
<didrocks> (I guess you created your snap with snapcraft snap?)
<mup> PR snapd#2275 opened: interfaces/builtin: allow additional shared memory for webkit <Created by zyga> <https://github.com/snapcore/snapd/pull/2275>
<Chipaca> jdstrand: poke
<Exquisitus> didrocks: exactly I did everything command line
<didrocks> Exquisitus: ok, so have a look at the web interface, it should give you more detailed information
<sergiusens> Exquisitus check your email, you will have a link to the failure
<didrocks> sergiusens: is that something your new branch will fix as well? Like you are getting more info from the store?
<mup> PR snapd#2276 opened: Add openvswitch-support interface <Created by javacruft> <https://github.com/snapcore/snapd/pull/2276>
<Exquisitus> ah thanks
<Exquisitus> https://myapps.developer.ubuntu.com/dev/click-apps/6305/rev/1/
<didrocks> Exquisitus: only you have access to it
<Exquisitus> lol
<Exquisitus> package contains external symlinks: usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts lint-snap-v2_external_symlinks
<Exquisitus> that's the error.
<didrocks> so, you have your answer :)
<didrocks> you have symlinks pointing outside of your snap, which isn't allowed
<sergiusens> didrocks which branch? The store needs to provide more information first :-)
<didrocks> sergiusens: the one you pointed to me last thursday
<sergiusens> didrocks I am so lost; sorry
<Exquisitus> oook... how I'm supposed to fix this? Jesus
<sergiusens> Exquisitus I don't think Jesus will help, we can though
<sergiusens> Exquisitus for the part adding this add a new entry `snap: [-usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts]`
<mup> Bug #1641631 changed: Raspberry Pi images do not support boot from USB <Snappy:Invalid> <https://launchpad.net/bugs/1641631>
<sergiusens> there's a bug for this too LP: #1617296
<mup> Bug #1617296: The JDK plugin results in a dangling symlink <Snapcraft:New for gnuoy> <https://launchpad.net/bugs/1617296>
<Exquisitus> @sergiusens: thanks a lot , you are better than Jesus
<nothal> Exquisitus: No such command!
<Exquisitus> Thanks sergiusens, you are better than Jesus
<Exquisitus> XD
<Exquisitus> sergiusens: only a thing, where actually I'm supposed to add snap: [-usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts]?
<didrocks> Exquisitus: you need to add it in the part shipping this file
<mup> PR snapd#2255 closed: tests: improve refresh-undo test <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2255>
<mup> PR snapd#2248 closed: tests: make refresh-undo wait a bit for the output of the restarted v1 service <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2248>
<Exquisitus> you mean in the yaml?
<didrocks> yes, in your snapcraft.yaml
<Exquisitus> source: https://github.com/iotaledger/iri.git     plugin: maven     snap: [-usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts]
<Exquisitus> that way?
<Exquisitus> sorry for bad formatting
<didrocks> well, I can't say if yes or no, but if snap: is at the same level than plugin:, yes
<didrocks> sergiusens: if the file is coming from the maven plugin, shouldn't be that one handle those symlinks and ignoring them?
<mup> PR snapd#2158 closed: many: remove unnecessary snap name parameter from buying endpoint <Created by pete-woods> <Merged by pete-woods> <https://github.com/snapcore/snapd/pull/2158>
<Exquisitus> exactly the symlink comes from maven that has the jdk dependency
<sergiusens> didrocks hence the bug
<didrocks> sergiusens: oh, I did miss your line about the bug, sorry, seeing it now
<didrocks> Exquisitus: do you mind opening another bug on lack of information from the store on snapcraft push?
<Exquisitus> https://github.com/snapcore/snapcraft/pull/761
<mup> PR snapcraft#761: Remove dangling symlink from JDK plugin <Created by gnuoy> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/761>
<Exquisitus> thanks it worked now
<didrocks> Exquisitus: do you mind opening the bug I asked about above? (the one about lack of information on snapcraft push)
<didrocks> happy that it's working now!
<Exquisitus> ok shall I open it on github?
<Exquisitus> because there's already one: https://github.com/snapcore/snapcraft/pull/761
<mup> PR snapcraft#761: Remove dangling symlink from JDK plugin <Created by gnuoy> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/761>
<Exquisitus> didrocks: sorry where should I open the bug? happy to do it
<didrocks> Exquisitus: https://launchpad.net/snapcraft
<didrocks> thx! :)
<didrocks> and not the JDK plugin bug
<didrocks> but the other one, what you came for first: "no information on snapcraft push on why it failed"
<sergiusens> didrocks we have a bug for push already
<sergiusens> didrocks LP: #1602095
<mup> Bug #1602095: Uploading a snap that requires a manual review shows an error that's not great <store> <Snapcraft:New> <Software Center Agent:New> <https://launchpad.net/bugs/1602095>
<didrocks> sergiusens: thanks you!
<didrocks> Exquisitus: no need then ^
<Exquisitus> ah ok
<sergiusens> didrocks OLS just needs poking ;-)
<didrocks> sergiusens: they don't look at bugs? :p
<ogra_> zyga, bbb and linux-generic-bbb in the store ...
<ogra_> zyga, and http://people.canonical.com/~ogra/snappy/all-snaps/stable/current/ for the image
 * ogra_ goes back into vacation mode
<mup> PR snapcraft#906 opened: indicators: support TERM=dumb <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/906>
<zyga> ogra_: thank you! woot :)
<zyga> ogra_: do you have one for beagle c4?
<ogra_> nope
<ogra_> (the kernel should work for the C4, i think there is a dtb for it in linux-generic)
<mup> PR snapd#2277 opened: snap: add new `snap prepare-image --devmode` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/2277>
<jdstrand> mvo: hey, so bug https://bugs.launchpad.net/snappy/+bug/1638656 is rather annoying for me. for various reasons, I am doing snappy development in an lxd container, but the snapd testsuite fails
<mup> Bug #1638656: snapd testsuite fails when run inside an lxd container <Snappy:New> <https://launchpad.net/bugs/1638656>
<jdstrand> mvo: which means I run tests manually, which leads to the issues in the avahi-observe PR. do you have a feeling for when that might be fixed if at all?
<mup> Bug #1641958 opened: The Cliqz snap will not run from either menu or CLI <Snappy:New> <https://launchpad.net/bugs/1641958>
<jdstrand> mvo: what is interesting about those failures is that they are all failing in /tmp
<jdstrand> mvo: and I know that lxd sets up a /tmp like snappy does. /me wonders if he can make lxd not do that as a workaround
<jdstrand> (I also don't know if that is the cause, it is just 'interesting')
<mvo> jdstrand: let me have a look
<mup> Bug #1641960 opened: Unable to locate package snapd in Debian RPi <Snappy:New> <https://launchpad.net/bugs/1641960>
<mvo> jdstrand: this rings a bell
<ypwong> Is it possible to put firmware in gadget snap? Because driver is already in kernel snap but firmware is not.
<Cameron_> I have a question
<willcooke> zyga, yo!  The Armbian guys are going to get a beta kernel with apparmour in for testing.  Will ping you as soon as I get it
<willcooke> zyga, @ OPi Zero ^
<zyga> willcooke: are you aiming for core or classic first?
<zyga> willcooke: and thanks for pinging back! exciting stuff
<willcooke> zyga, classic first, because they've done pretty much all the work already
<zyga> ok
<zyga> yeah, seems sensible
<Elleo> is there a way I can get the original $HOME value from within a snap (not the modified ~/snap/<snapid>/ version?)
<zyga> tvoss: is the util-linux SRU done?
<zyga> tvoss: I see  *** 2.20.1-5.1ubuntu20.11 0
<zyga> tvoss: from your PPA
<jdstrand> mvo: thanks! let me know if you want me to test something. I'd love to be able to run ./run-tests :)
<jdstrand> mvo: err, run-checks
<tvoss> zyga: in flight, whatever is in my ppa is going to be SRU'd though, plus version bump :)
<zyga> k
<zyga> tvoss: a big :'-( for not having nsenter tehre
<tvoss> zyga: not sure I'm following :)
<tvoss> oh, in util-linux
<zyga> tvoss: yes
<zyga> it's invaluable as an analysis tool
<tvoss> zyga: okay, time for another sru then
<zyga> yeah, no worries :)
<mup> PR snapd#2147 closed: asserts: validate optional account username <Created by emgee> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2147>
<mup> PR snapcraft#907 opened: readme: rocket instead of irc <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/907>
<mvo> jdstrand: ha! fun (or not), I created an lxd container and couldn't reproduce
<mvo> jdstrand: but I think I did not follow the instructions correctly, let me try again
<jdstrand> jdstrand: hmmm. that is 'fun' :)
<jdstrand> mvo: fyi, I am using the lxd snap
<mvo> jdstrand: I think I can lxc as root
<mvo> jdstrand: ohhhhh
<mvo> jdstrand: I'm using the package
<mvo> jdstrand: let me try with the snap
<jdstrand> mvo: http://paste.ubuntu.com/23481011/
<qengho> I'm looking for a migration path to config hook from old handmade config file. Can a configure hook call "snap set" safely? Assume the condition changes that makes it call snap-set in the first run, like config file moved aside and not detected thereafter.
<qengho> Oh, maybe it should be calling "snapctl set"?!
<didrocks> qengho: yeah, your configure script can only call snapctl, not snap
<didrocks> (and you don't need the snap name in snapctl)
<mup> PR snapcraft#903 closed: store: download without login <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/903>
<shuduo> slangasek: hi
<jdstrand> zyga: hey, ok, spread-test added to https://github.com/snapcore/snap-confine/pull/181 but it doesn't run due to something in the test infrastructure (see my comment in the PR)
<mup> PR snap-confine#181: add compatibility architectures for supported architectures (LP: #1592022) <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/181>
<zyga> jdstrand: looking
<zyga> jdstrand: ah I saw this myself
<zyga> jdstrand: I'll update packaging to take account of the merged patches
<mup> PR snapd#2278 opened: tests: add test that ensures that we do not garbage collect the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2278>
<zyga> jdstrand: I'll take a quick break and be back soon
<jdstrand> zyga: ok. note, this isn't an emergency PR. fine to pick it up tomorrow afaic
<slangasek> shuduo: hello
<shuduo> slangasek: hi, i notice you have reported a netowrk issue of store https://lists.ubuntu.com/archives/snapcraft/2016-October/001355.html
<shuduo> slangasek: i wonder if the issue is still exist or already fixed
<slangasek> shuduo: those snaps are on the stable channel now
<slangasek> shuduo: so that problem no longer exists
<shuduo> slangasek: i'm helping a customer to migrate their kernel snap from u-d-f to ubuntu-image and encounter network time out issue
<shuduo> sudo /snap/bin/ubuntu-image -c beta --image-size 4G --extra-snaps ./bubblegum96-gadget_0.1.0_arm64.snap --extra-snaps ./bubblegum96-kernel_3.10.0_arm64.snap -o bubblegum96.img bubblegum96.model
<shuduo> error: cannot fetch and check prerequisites for the model assertion: Get https://assertions.ubuntu.com/v1/assertions/account-key/6PVAOu6V-pOb7bCSIB9W0WRSnVZwySqShrne8zWWWhIh6oW65o1ynHD4XoT3wSzF?max-format=0:
<shuduo> net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
<shuduo> COMMAND FAILED: snap prepare-image --channel=beta --extra-snaps=./bubblegum96-gadget_0.1.0_arm64.snap --extra-snaps=./bubblegum96-kernel_3.10.0_arm64.snap bubblegum96.model /tmp/tmpk_f88lrl/unpack...subprocess.CalledProcessError: Command '['snap', 'prepare-image', '--channel=beta', '--extra-snaps=./bubblegum96-gadget_0.1.0_arm64.snap', '--extra-snaps=./bubblegum96-kernel_3.10.0_arm64.snap',
<shuduo> 'bubblegum96.model', '/tmp/tmpk_f88lrl/unpack']' returned non-zero exit status 1
<slangasek> shuduo: that thread is not about a network timeout issue at all.  If you are trying to do an offline snap prepare-image, I'm afraid that's not something I have knowledge about
<shuduo> slangasek: sorry just found Luke Williams reported a http 500 error. sorry my mistake
<zyga> tvoss: more green :)
<zyga> tvoss: I just pushed a few trivial patches back
<zyga> tvoss: I'll get some tea and see how this unfolds
<zyga> tvoss: I will also go over the diff and fix any small things I was thinking about
<jdstrand> mvo: note though that I have a complete setup in bug #1638656 where I was able to reproduce in an lxd container from a deb
<mup> Bug #1638656: snapd testsuite fails when run inside an lxd container <Snappy:New> <https://launchpad.net/bugs/1638656>
<mup> PR snapd#2225 closed: Implement lxd-client interface exposing the lxd snap (LP: #1634880) <Created by kalikiana> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2225>
<zyga> tvoss: not fully green but greener
<tvoss> Hi
<tvoss> zyga: sounds promising, I'll grab a quick bite, with you after that
<zyga> tvoss: so according to https://travis-ci.org/snapcore/snapd/builds/176117575 the only task that failed is *restore* on     - linode:ubuntu-14.04-64:tests/upgrade/basic
<zyga> tvoss: there are some faliures to prepare on other releases that need to be investigated and fixed
<zyga> tvoss: the restore failure is E: Packages were downgraded and -y was used without --allow-downgrades.
<zyga> tvoss: I think that's some of the assumption that doesn't hold in the ppa case
<zyga> tvoss: in any case, I think we are super close
<zyga> tvoss: I'm actually EOD now but I'll continue tomorrow
<zyga> tvoss: with my service tweak and small apparmor change it looks like everything really works now
<zyga> tvoss: I'll check which tasks are disabled on 14.04 and see if we can re-enable them, if any
<tvoss> Zyga, ack sounds good, I'll take a look at the upgrade failurr, have a good idea why it is failing
<mup> PR snapcraft#907 closed: readme: rocket instead of irc <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/907>
<mup> PR snapd#2279 opened: interfaces: add alsa (LP: #1598309) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2279>
<mterry> When I build a snap locally with snapcraft, I will see a more extensive LD_LIBRARY_PATH in its command-*.wrapper files than I see with a snap build in an LP bileto silo.  Is that simply becuase I'm not using cleanbuild and snapcraft is stuffing bits of my local environment in there?
<mterry> (and if so, is there a way to stop it doing that without doing the bother of cleanbuild?)
<balloons> ka
<balloons> kalikiana_, happy to see the interface landed :-)
<ahoneybun> mhall119: anyway to force a snap to look for a file somewhere>
<ahoneybun> GLib.Error: g-file-error-quark: Failed to open file '/share/pithos/pithos.gresource': open() failed: No such file or directory (4)
<ahoneybun> I think it needs to look in $SNAP/share/pithos/ for it
<mup> PR snapd#2280 opened: interfaces: miscellaneous policy updates (LP: #1639988, 1614269, 1639614, 1605216, 1629996, et al) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2280>
<sergiusens> mterry mind logging a bug for that?
<mterry> sergiusens: sure
<mterry> sergiusens: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1642041
<mup> Bug #1642041: LD_LIBRARY_PATH values are inconsistent when working with others <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1642041>
<sergiusens> mterry meh, not an Ubuntu bug! Those we sort of not keep track of ;-)
<sergiusens> mterry much less when we make snapcraft a snap :-)
<mterry> sergiusens: then close that bug tracker down
<mterry> move it where ya like
<mterry> I guess you can't close down an ubuntu tracker
<sergiusens> mterry I can't we use it for SRU bugs :-)
<sergiusens> mterry I'll make sure I move the bug
<mterry> sergiusens: ubuntu is where I get my snapcraft binary...
<sergiusens> mterry thanks for it!
<sergiusens> mterry yeah, but we have no one triaging ubuntu bugs
<sergiusens> so it sort of gets lost
<mterry> well. ok
<sergiusens> and we have no elegant way to close them as our debian/changelog only mentions the SRU bug per agreement with the release team
<mhall119> ahoneybun: it depends on the code how to tell it that
<mup> PR snapcraft#889 closed: cache: snap revision caching on 'push' <Created by squidsoup> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/889>
<mup> PR snapcraft#893 closed: Add a script to retry autopktests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/893>
<ahoneybun> mhall119: the yaml file you mean?
<ahoneybun> http://pastebin.ubuntu.com/23482554/
<mup> PR snapd#2281 opened: dirs,interfaces,overlord,snap,snapenv,test: export per-snap XDG_RUNTIME_DIR per user (LP: #1620442) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2281>
<mup> Bug #1620442 opened: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:In Progress by jdstrand> <Snappy:In Progress by jdstrand> <https://launchpad.net/bugs/1620442>
<flexiondotorg> sergiusens, Yo
<flexiondotorg> Is there an environment variable I can rely on being set to determine snapcraft is doing the build?
<flexiondotorg> I am adding some logic to one of my Python projects setup.py.
<flexiondotorg> So that is can be pip installed for non-snap users.
<flexiondotorg> But also not fail during the build step when being built on Launchpad as a snap.
<mup> Bug #1642082 opened: Timestamp error when we try to sign a model assertion <Snappy:New> <https://launchpad.net/bugs/1642082>
<liuxg_> hi
#snappy 2016-11-16
<Guest71571> I am trying to install ubuntu core on raspberry pi 3 and I am stuck at entering email address from account in store...
<Guest71571> frustrated, I have an error message for my email, no ssh keys found...
<Guest71571> can anyone help me??
<lool> mikedougherty: Hey!
<lool> mikedougherty: LoÃ¯c Minier here
<lool> mikedougherty: a real Ubuntu xenial environment will be better than a docker environment albeit I had success building snaps in there (perhaps not the docker snap though)
<lool> mikedougherty: the errors you reported wouldn't seem to relate to docker at all though
<mikedougherty> hiyo!
<lool> mikedougherty: it's pretty late here (CET) and I wont be around tomorrow morning, but otherwise IRC/email are all fine
<mikedougherty> right, in fact very strangely i couldn't even find part of that error string in the source that i have installed
<lool> mikedougherty: you'll also find lots of folks around here and on the snapcraft ML for generic questions not specific to docker
<mikedougherty> in a straight xenial environment, things seem to be working fine. i probably should have tried it sooner
<lool> that's good news
<lool> mikedougherty: there were some recent changes to the docker snap that I should keep you up-to-date on
<mikedougherty> definitely something with my docker env. i'll try now on the same system in a similar docker environment, if that works then i'll blame my local system. if not, then likely a snapcraft-in-docker issue.
<lool> mikedougherty: the two main environments I'm testing it right now are: 1) plain Ubuntu Core series 16 (image made only of snaps - https://www.ubuntu.com/core)  2) Ubuntu classis âÂ xenial + updates, comes with snapd preinstalled
<lool> with latest snapd (2.17), the docker interfaces get autoconnected
<mikedougherty> interesting
<lool> there's currently a bug breaking docker snap on Ubuntu Core; we think docker is trying to access the wrong cgroup mount point and confinement breaks it
<lool> this is to be fixed in the confinement but could also be fixed in docker snap for now
<mikedougherty> that likely would have been the next thing i run into, so good to know before i run into that wall
<mikedougherty> what would those changes be for the docker snap?
<mup> Bug #1642090 opened: crontab like snaps or interfaces <Snappy:New> <https://launchpad.net/bugs/1642090>
<lool> mikedougherty: https://lists.ubuntu.com/archives/snapcraft/2016-October/001382.html was the original announcement with reference to a google doc acting as a mini knowledge base for the docker snap
<mikedougherty> i'll have a look through
<lool> mikedougherty: I'm not sure how it's locating /sys/.../cgroups/cpuset from all mountpoints, perhaps try multiple ones or prefer a shorter path (both of which are a bit ugly); I haven't thought this through
<lool> mikedougherty: https://bugs.launchpad.net/snap-confine/+bug/1626019 is a bug describing the *opposite* problematic behavior which we worked aorund int he docker snap (see dockerd launcher), but that might not be needed anymore nowadays; the original issue of the mountpoints that should be cleaned up after confinement is setup stands
<mup> Bug #1626019: Docker snap cannot start containers in Classic (but does in Core) <Snappy Launcher:In Progress by zyga> <https://launchpad.net/bugs/1626019>
<lool> mikedougherty: (this cgroup finding issue is actually recent; this bug is much older)
<lool> mikedougherty: got to get some sleep, tty soon
<mikedougherty> sounds good! thanks for the info dump
<mup> Bug #1642117 opened: symlinks to snap commands no longer working <Snappy:New> <https://launchpad.net/bugs/1642117>
<mup> PR snapd#2266 closed: tests: run autopkgtests in the autopkgtest.ubuntu.com infrastructure <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2266>
<mup> PR snapd#2280 closed: interfaces: miscellaneous policy updates (LP: #1639988, 1614269, 1639614, 1605216, 1629996, et al) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2280>
<mup> PR snapd#2282 opened: interfaces: remove LegacyAutoConnect() from the interfaces  <Created by mvo5> <https://github.com/snapcore/snapd/pull/2282>
<dholbach> hey hey
<foxmask> bonjello
<seb128> hey dholbach!
<dholbach> salut seb128
<didrocks> good morning dholbach, re seb128, hey foxmask
<foxmask> didrocks: o/
<dholbach> salut didrocks
<seb128> re didrocks ;-)
<foxmask> mince ca speak french alors ? :)
<didrocks> foxmask: as dholbach speaks french very well, I would say yes :)
<dholbach> pas du tout :)
<didrocks> hÃ©hÃ©
<dholbach> j'ai oubliÃ© tout :-)
<foxmask> ok forget what I said :)
<zyga> good morning
<mup> PR snapd#2283 opened: osutil: make RealUser only look at SUDO_USER when uid==0 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2283>
<mup> Bug #1642183 opened: GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Snappy:New> <https://launchpad.net/bugs/1642183>
<flexiondotorg> Morning all :-)
<flexiondotorg> didrocks, I updated my podpublish snap last night.
<flexiondotorg> https://code.launchpad.net/~flexiondotorg/podpublish/+git/podpublish/+ref/master
<flexiondotorg> And ran into an issue.
<flexiondotorg> I can no longer build this snap on LP :-(
<flexiondotorg> Because the LP build step has no network capability.
<flexiondotorg> And it appears snapcraft is trying to download requirements it already had from the the pull step.
<flexiondotorg> https://launchpadlibrarian.net/293608654/buildlog_snap_ubuntu_xenial_arm64_podpublish_BUILDING.txt.gz
<flexiondotorg> I tried several things to work around this.
<flexiondotorg> Putting everything from 'pip freeze' from my virtualenv into requirement.txt
<flexiondotorg> Changing setup.py to not return any requirements when invoked for a bdist or build.
<didrocks> flexiondotorg: yeah, indeed, this change was wanted by the launchpad team. You need now to refactor to have this only in the pull step as you told
<flexiondotorg> I finally gave up at 2am and built a package locally and uploaded it to the store.
<didrocks> I don't think that's something which is going to change in the forseable future
<didrocks> but, the standards plugin should already comply with this, don't they?
<flexiondotorg> So I did refactor setup.py to not request any requirements in the build step.
<didrocks> hum, the issue is that you have multiple requirements.txt
<didrocks> the python plugin will pick one and install everything for you in the pull step
<didrocks> then, your requirements should be there once setup.py load them, shouldn't they?
<didrocks> (maybe your setup.py tries to be too clever?)
<flexiondotorg> But snapcraft appears to invoke pip bdist_wheel in the build step anyway.
<flexiondotorg> Which attempts to download requirement that were already gathered in the pull step.
<flexiondotorg> As far as I can tell, it is not possible to build a snap in LP for Python package that ships a requirements.txt.
<didrocks> flexiondotorg: I'm pretty sure with a standard setup.py that was tested (or I hope so), sergiusens did refactor the plugin recently
<didrocks> pip bdist_wheel doesn't redownload the requirements if they were already pulled (at least, on ubuntu make)
<didrocks> I wonder if the issue isn't somewhere else
<flexiondotorg> Download error on https://pypi.python.org/simple/cffi/: [Errno -2] Name or service not known -- Some packages may not be found!
<flexiondotorg>   Couldn't find index page for 'cffi' (maybe misspelled?)
<flexiondotorg>   Download error on https://pypi.python.org/simple/: [Errno -2] Name or service not known -- Some packages may not be found!
<flexiondotorg>   No local packages or working download links found for cffi>=1.4.1
<flexiondotorg> Those are lines from the build log in the build step.
<flexiondotorg> cffi was download in the pull step.
<flexiondotorg> I wonder if one the required packages is forcing a download.
<didrocks> flexiondotorg: did you try to remove all the "*_requires" for now?
<didrocks> in setup.py
<flexiondotorg> didrocks, Yes, I tried that last nights.
<didrocks> to at least test this isn't what causes distutils to repull
<didrocks> didn't work, still the same?
<flexiondotorg> That was how the process used to be.
<zyga> flexiondotorg: I saw sergio work on this issue at the last sprint
<zyga> flexiondotorg: ask him later today
<flexiondotorg> zyga, OK. Thanks.
<flexiondotorg> didrocks, To get podpublish building in LP (a couple of months back) I crippled setup.py to not return/request any requirements.
<flexiondotorg> But that no longer works in this case.
<didrocks> flexiondotorg: when was the last time you tried a build on launchpad which passed btw? I don't rememer when this change was deployed, but at least, it's a couple of months (just trying to find if we had an email announcement)
<didrocks> flexiondotorg: ok, is it exactly the same failure than th one you pasted above in that case? (without those _require statements?)
<flexiondotorg> June/July.
<didrocks> ok, that makes sense time-wise at least
<didrocks> let's see once Sergio is around as it seems he already worked on this for python
<flexiondotorg> kyrofa, Helped me do the initial publishing to LP.
<didrocks> (I only needed to change some things on npm/bower myself)
<morphis__> zyga: ping
<flexiondotorg> And this was required, which no longer works :-(
<flexiondotorg> https://git.launchpad.net/podpublish/commit/?id=ba69bf886f3125173af1b0b08d2862ab2f2e27d3
<didrocks> yeah, that should be what is working still nowdays
<didrocks> do you have the corresponding exact launchpad build log link?
<flexiondotorg> For when it worked?
<didrocks> no, the first build that failed
<didrocks> with those requires commented
<mup> PR snapd#2282 closed: interfaces: remove LegacyAutoConnect() from the interfaces  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2282>
<flexiondotorg> didrocks, I'll drop them again and rebuild to get a log.
<mup> PR snapd#2271 closed: snap: add support for classic confinement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2271>
<didrocks> flexiondotorg: thx!
<mup> PR snapd#2284 opened: tests: add debug to all flaky expect tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2284>
<zyga> morphis__: hey
<bert269> I installed Ubuntu core 16 on a Raspberry Pi and need to login local. How do I do tgat?
<morphis__> zyga: hey!
<bert269> I do not have another host I can SSH from. I  tried my SSO credentials and it's not working either
<bert269> Hi
<morphis__> zyga: I am wondering if there are any plans around better process/service management inside snaps
<morphis__> zyga: having the problem right now that I need to restart one of my services from another
<morphis__> zyga: talking to systemd isn't possible and kill(..) too as using the process-control interface is quite too priviledged
<zyga> morphis__: you can kill processes from your own snap
<zyga> morphis__: I think we should allow talking to systemd to manage just the subset
<zyga> morphis__: perhaps via snapctl
<zyga> morphis__: but I don't know of any plans yet
<morphis__> zyga: I get a permission denied for a kill -TERM $PID call
<morphis__> because the kill syscall is denied
<zyga> morphis__: odd, can you report that, I'll try to fix it today
<morphis__> zyga: I thought that is what we have https://github.com/snapcore/snapd/blob/master/interfaces/builtin/process_control.go for
<morphis__> zyga: so how is it supposed to work then if not using the process control iface?
<zyga> morphis__: process control was for unconstrained process control
<zyga> morphis__: you should be able to kill processes from your own apparmor label
<zyga> morphis__: that's easy to do
<morphis__> zyga: ok, that would be awsome
<zyga> s/kill/signal/
<morphis__> zyga: using snap-confine 1.0.43 here
<flexiondotorg> didrocks, Here you go:
<flexiondotorg> https://launchpadlibrarian.net/293648430/buildlog_snap_ubuntu_xenial_amd64_podpublish_BUILDING.txt.gz
<zyga> morphis__: that would be in apparmor profiles in snapd
<zyga> morphis__: I don't think we need any snap-confine changes
<morphis__> ah
<flexiondotorg> Built from:
<flexiondotorg> https://git.launchpad.net/podpublish/commit/?id=edd30ec9016840e870f1c8e4c2fca516231b351b
<morphis__> zyga: let me check, maybe I can fix that myself
<zyga> morphis__: look at the base profile, it should deny signals to unconfined labels
<zyga> morphis__: and it should also allow signals to the same label
<zyga> morphis__: same == the label of the snap
<morphis__> hm, it does already
<mup> PR snapd#2242 closed: tests: do not use hello-world in our tests <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2242>
<zyga> morphis__: what is the denial you see?
<morphis__> signal peer=(snap.@{SNAP_NAME}.*),
<morphis__> [73180.309289] audit: type=1400 audit(1479287611.329:127): apparmor="DENIED" operation="capable" profile="snap.wifi-ap.management-service" pid=11539 comm="ap.sh" capability=5  capname="kill"
<zyga> morphis__: is the service running as root and the signal sender as non-root?
<zyga> morphis__: this is a different denial
<zyga> morphis__: right?
<zyga> morphis__: that's CAP_KILL
<morphis__> zyga: snap.wifi-ap.management-service is a systemd service so running as root
<morphis__> yeah
<zyga> morphis__: so the signal is already allowed and this is a different problem
<zyga> morphis__: you'd need your own tiny service that kills the other one
<morphis__> zyga: its actually mgmt-service -> fork ap.sh -> fork hostapd
<morphis__> ap.sh calls kill -TERM $HOSTAPD_PID
<zyga> morphis__: in any case, I think you are good
<morphis__> zyga: why do I get then:
<morphis__> Nov 16 10:13:31 nirvana snap[11342]: ++ read DNSMASQ_PID
<morphis__> Nov 16 10:13:31 nirvana snap[11342]: ++ kill -TERM 11609
<morphis__> Nov 16 10:13:31 nirvana snap[11342]: /snap/wifi-ap/x7/bin/ap.sh: line 48: kill: (11609) - Operation not permitted
<morphis__> actually I am not dropping capabilities anywere
<zyga> morphis__: is the sender running as root?
<morphis__> yes
<zyga> hmm
<zyga> morphis__: the denial above is for permission bypass
<zyga>        CAP_KILL
<zyga>               Bypass permission checks for sending signals (see kill(2)).  This includes use of the ioctl(2) KDSIGACCEPT operation.
<zyga> morphis__: ah, is there an identical rule for signal reception?
<zyga> morphis__: that a process can receive a signal from the same snap?
<morphis__> you mean in apparmor?
<zyga> morphis__: if not, you are invincible ;-)
<zyga> yes
<morphis__> rule says, "Allow apps from the same package to signal each other via signals"
<morphis__> zyga: https://paste.ubuntu.com/23484812/
<morphis__> but looks like we need to allow cap_kill
<zyga> morphis__: that's only half of the rule
<zyga> morphis__: looks like a silly bug
<zyga> morphis__: look at...
<zyga> morphis__: no
<zyga> morphis__: cap_kill == kill anything
<zyga> morphis__: one sec
<zyga> hmmm
<morphis__> isn't that the capability to call kill at all and further limitations are done through the apparmor rule?
<zyga> I was partially wrong
<zyga> morphis__: no, because cap_kill is like sudo, it's not something you should need here
<morphis__> ok
<zyga> morphis__: https://github.com/snapcore/snap-confine/blob/master/src/snap-confine.apparmor.in#L318
<zyga> morphis__: the trouble is that signal implies singal (send,receive)
<zyga> morphis__: so something else (not apparmor) is in the way
<zyga> morphis__: can you tweak the profile locally
<zyga> morphis__: make it say signal (send,receive) explicitly
<morphis__> sure
<morphis__> still the cap_kill deny
<zyga> morphis__: can you triple check the UID of both processes?
<zyga> morphis__: if this fails I'd ask jdstrand, no idea but I think cap_kill is the wrong answer
<morphis__> zyga: both root
<morphis__> zyga: let me open a bug for this
<zyga> morphis__: thanks
<zyga> morphis__: unless we drop all caps?
<zyga> morphis__: and we're root but really without capkill
<morphis__> zyga: can I check the caps of a process somewhere?
<zyga> yes
<zyga> pscap
<morphis__> zyga: ah wait, there is a different problem
<morphis__> dnsmasq switches to nobody
<morphis__> hostapd not, but dnsmasq does
<zyga> ha
<morphis__> let me change that
<morphis__> zyga: one other thing I wanted to ask you about, what is the classic confinement mode going to be?
<zyga> morphis__: similar to no confinement at all
<zyga> morphis__: we're meeting today to discuss some aspects
<morphis__> zyga: ok
<morphis__> zyga: so a more official "devmode by default" thing
<zyga> morphis__: no, many changes apart from confinement
<zyga> morphis__: no rootfs change
<zyga> morphis__: and also (hopefully) snapcraft logic to use core snap for linker and libraries
<morphis__> ok
<zyga> ogra_: on bbb, the first boot tasks fail for me with
<zyga> 2016-11-16T10:46:47Z ERROR cannot deliver device serial request: unexpected status 400
<zyga> mvo, Chipaca, pedronis: docker seems down, this means travis fails bootstrap and we cannot test
<zyga> e.g. https://travis-ci.org/snapcore/snapd/jobs/176335410
<mup> PR snapd#2058 closed: interfaces: add ofono interface <Created by alfonsosanchezbeato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2058>
<abeato> \o/
<abeato> Chipaca, https://github.com/snapcore/snapd/pull/2252 was approved too ;)
<mup> PR snapd#2252: interfaces: add unconfined access to modem-manager <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2252>
<Chipaca> abeato: patience :-)
<abeato> Chipaca, lol, just in case you did not see that one :p
<abeato> and thanks
<mup> PR # closed: snapd#1613, snapd#2083, snapd#2087, snapd#2104, snapd#2112, snapd#2113, snapd#2120, snapd#2128, snapd#2129, snapd#2153, snapd#2193, snapd#2194, snapd#2199, snapd#2200, snapd#2202, snapd#2209, snapd#2211, snapd#2215, snapd#2223, snapd#2226, snapd#2230, snapd#2234, snapd#2236,
<mup> snapd#2249, snapd#2251, snapd#2252, snapd#2256, snapd#2262, snapd#2263, snapd#2264, snapd#2268, snapd#2269, snapd#2270, snapd#2273, snapd#2274, snapd#2275, snapd#2276, snapd#2277, snapd#2278, snapd#2279, snapd#2281, snapd#2283, snapd#2284
<Chipaca> abeato: currently looking at 2083, I'll get there soon enough
<abeato> cool
<zyga> mvo: does this look good to you http://pastebin.ubuntu.com/23485134/
<zyga> mvo: you were doing some changes to make various versions of systemd test the same
<oSoMoN> Iâm trying to use the ubuntu-app-platform content interface, and getting the following error message when launching my app:
<oSoMoN> cannot mount /snap/ubuntu-app-platform/8 at /snap/webbrowser-app/x1/ubuntu-app-platform with options bind,ro. errmsg: No such file or directory
<oSoMoN> any idea what the problem is?
<renato__> oSoMoN, hey
<oSoMoN> hey renato__
<renato__> oSoMoN, you need to install a empty directory with name "ubuntu-app-platform"
<oSoMoN> renato__, okay. Thatâs not mentioned anywhere in the instructions to use the content interface, the doc needs updating (or is it a bug that will eventually be fixed')
<renato__> oSoMoN, the interface you mount the content inside of this dir. The interface itself does not have permission to create dir on the app side.
<renato__> oSoMoN, yes probably the doc needs update
<oSoMoN> renato__, thanks for the help, Iâm trying that now
<renato__> mvo, hey could you help me with some apps that are stuck on store?
<renato__> jdstrand, hey, I saw that you approved my apps. Thanks.
<Chipaca> matteo: #2193 has conflicts
<renato__> guys I am trying to remove a snap app, and I am getting this error
<renato__> 2016-11-16T08:59:06-03:00 ERROR cannot remove snap file "ubuntu-calendar-app", will retry in 3 mins: umount: /snap/ubuntu-calendar-app/x1: not mounted
<renato__> ant it never get removed
<renato__> zyga, any hint about this ^^^
<zyga> renato__: looking
<zyga> renato__: were you using snap try?
<zyga> renato__: you can snap abort the change
<zyga> renato__: and (if it was snap try) restory the directory and the bind mount
<zyga> renato__: to remove the snap
<renato__> zyga, no I am not using snap try.
<renato__> should I use that?
<renato__> zyga, how to use that?
<zyga> renato__: no, if you are not using snap try then don't follow the rest of my advice
<zyga> renato__: can you tell me what you did prior to this failure?
<renato__> zyga, not, sure just reboot the machine
<renato__> zyga, it is a vm
<renato__> zyga, I was just installing and removing app as normal.
<renato__> zyga, any workaround that I can use to continue working? :D
<zyga> renato__: can you pastebin the output of "snap changes" please
<renato__> zyga, sure
<renato__> zyga, http://paste.ubuntu.com/23485397/
<renato__> zyga, I have been trying to fix that as you can see in the changes.
<zyga> renato__: how about "snap change 186"
<renato__> http://paste.ubuntu.com/23485400/
<renato__> zyga, ^
<zyga> renato__: hmm, can you look at /snap/ubuntu-calendar-app/x1
<zyga> renato__: is that a mount point?
<zyga> renato__: does "snap list" show it to be installed?
<renato__> zyga, ubuntu-calendar-app             x1               broken
<renato__> zyga, yes the dir exists
<zyga> renato__: is it empty
<renato__> yes
<zyga> renato__: can you look at /var/lib/snapd/snaps
<zyga> renato__: look for the sideloaded revision of this snap, is there a .snap file there?
<renato__> zyga, http://paste.ubuntu.com/23485419/
<renato__> yes there is a snap for x1 version
<zyga> renato__: ok
<zyga> renato__: can you do systemctl status and look for the mount unit for that snap
<zyga> renato__: (I don't remember the name)
<zyga> renato__: then do systemctl status name-of-that-unit.mount
<zyga> renato__: and see what the output is
<zyga> tvoss: re, how's stuff?
<renato__> zyga, what I should look for, exactly? http://paste.ubuntu.com/23485428/
<zyga> renato__: ah, sorry that doesn't list mount units
<zyga> renato__: can you go to /etc/systemd/system/
<zyga> renato__: you will be able to see the various .mount units
<renato__> yes
<zyga> renato__: use that as a hint to systemctl status the right one (careful with quoting)
<renato__> snap-ubuntu\x2dcalendar\x2dapp-x1.mount
<zyga> yes, that one
<zyga> (crazy systemd escape requirements)
<renato__> zyga, http://paste.ubuntu.com/23485437/
<zyga> renato__: very insteresting
<zyga> renato__: can you report that long with snapd version and kernel version please?
<zyga> renato__: and don't change your system for a while
<renato__> zyga, :(
<zyga> renato__: one more check, look at that snap file and see if it's empty by any chance?
<zyga> renato__: (truncated etc)
<zyga> renato__: I have to run to a standup now, ttyl
<renato__> zyga, yes it is empty: -rw-------  1 root root         0 nov 11 20:07 ubuntu-calendar-app_x1.snap
<zyga> renato__: please include that in your report
<zyga> renato__: I think this explains a lot
<tvoss> zyga: a step further, tests/upgrade/basic breaks in a different way now: http://pastebin.ubuntu.com/23485459/
<zyga> tvoss: looking
<zyga> hmm hmm
<zyga> tvoss: is everything pushed? I'll pull and see
<tvoss> zyga: yup
<zyga> k pulling
<renato__> zyga, https://bugs.launchpad.net/snappy/+bug/1642257
<mup> Bug #1642257: Fail to remove app <Snappy:New> <https://launchpad.net/bugs/1642257>
<zyga> renato__: thank you
<zyga> renato__: did you have a power failure or something like that?
<zyga> renato__: I wonder why that snap got empty
<tvoss> zyga: --allow-downgrades is certainly needed in tests/upgrade/basic/task.yaml when instaling the previous version
<renato__> zyga, welcome.
<mup> Bug #1642257 opened: Fail to remove app <Snappy:New> <https://launchpad.net/bugs/1642257>
<renato__> zyga, I am not sure. But since this is a vm. I could kill it by mistake
<zyga> renato__: how many times did you install that snap, what is the time snap (roughly)
<renato__> zyga, Im testing the plataform content share. I installed a lot of snap in the last days
<renato__> What do you mean by "time snap"???
<zyga> renato__: time span, roughly how many hours/days
<renato__> zyga, a lot, probably more than 20 times a day
<renato__> not the same snappy, but different versions
<davidcalle> timp, quick heads-up, I've changed the snapcraft docs link in your qt snap blog post, to direct to /docs instead of /docs/snaps, the latter is a pretty weak page that's pending an overhaul
<zyga> sergiusens: are you up for the meeting in 10 minutes?
<sergiusens> zyga I am awake, yes
<zyga> sergiusens: great, see you soon
<sergiusens> zyga thanks for the reminder, I am getting no notifications/reminders lately
<renato__> zyga, do I still need to keep my system freeze. Or can I somehow remove the broken package?
<Elleo> jdstrand: am I right in thinking there's nothing currently that does the equivelant of APP_ID_DBUS? The helper functions you pointed to me earlier in the week do the job of APP_PKGNAME nicely, but APP_ID_DBUS makes those values usable in dbus paths (e.g. snap.podbird.podbird -> snap_2epodbird_2epodbird)
<jdstrand> mvo: woot! nice find for the lxc bug. curious-- am I entering the container wrong?
<jdstrand> Elleo: let me check something
<Elleo> jdstrand: okay, thanks
<jdstrand> Elleo: when we last spoke I was thinking only of the security label and had forgotten that trusted helpers sometimes use the security label in their paths and need something like APP_ID_DBUS
<mvo> jdstrand: well, sort of. sudo -u keeps some SUDO_* vars around that confused snapd, but really its a bug in snapd
<pedronis> jdstrand: hi, we merged removing LegacyAutoConnect btw, mvo did the work
<jdstrand> Elleo: my recollection is that this was removed from snappy because at the time nothing was using it (I mentioned we would need it for personal but it was decided we would just add it back later
<jdstrand> pedronis: I saw that
 * jdstrand hugs mvo
<jdstrand> mvo: otoh, do you know of a better way to enter the chroot as non-root?
<Elleo> jdstrand: ah right, shall I write an equivelant helper function in utils.go to handle that then?
<jdstrand> Elleo: let me get you the commit that pulled it out
<Elleo> jdstrand: ah, cool, thanks
<pedronis> jdstrand: it was on my todo list but mvo graciously got there first
<jdstrand> pedronis: yeah, it came up in a PR the other day that it was adding confusion
<mvo> jdstrand: alternatively you could use "su -l -s /bin/sh"
<mvo> jdstrand: "su -l -s /bin/sh your-user" of course
<jdstrand> Elleo: dbus.SafePath() was not removed. 578d0c80f71c55c7b8a9e40382b62fd25dbd836d removed APP_ID_DBUS. you can add it back in interfaces/apparmor/template_vars.go. I think you should have SNAP_ID_DBUS for snap.name.app. I don't know if you need SNAP_NAME_DBUS for SNAP_NAME or not, but if you do, start with that name
<jdstrand> mvo: yeah-- I was more thinking of an lxc-y way of entering it. thanks!'
<liuxg> jdstrand, I have attached the .snap file for the input method. did you see it? thanks
<jdstrand> Elleo: so SNAP_ID_DBUS -> APP_ID_DBUS and if needed SNAP_NAME_DBUS -> APP_PKGNAME_DBUS
<jdstrand> liuxg: I haven't yet but will take a look
<jdstrand> liuxg: thanks
<liuxg> zyga, my colleague has a simple slot use case like http://paste.ubuntu.com/23485602/.. May I know whether it is fine for a snap app? thanks
<jdstrand> Elleo: I'm not in love with 'SNAP_ID_DBUS'
<liuxg> jdstrand, you are welcome. I think you probably did not build it successfully. the snap file is pretty big.
<jdstrand> Elleo: lets do SNAP_LABEL_DBUS. I think that will fly better
<jdstrand> liuxg: yeah, I ran snapcraft and a snap popped out. I didn't try to debug further
<liuxg> jdstrand, my colleauge and I both successfully built the project. I think the source code should be fine :)
 * jdstrand shrugs
<jdstrand> git clone followed by snapcraft
<Elleo> jdstrand: okay, cool; thanks very much :)
<liuxg> jdstrand, the UI is like http://imgur.com/a/fccq5, you can select the "search" button to input some Chinese characters. Should you have any problem with it, please let me know. thanks
<timp> davidcalle: okay, thanks.
<liuxg> jdstrand, if a snap uses "slot" instead of "plug" like the way in http://paste.ubuntu.com/23485602/, the snap will be subject to manual review, right? It in fact can access the audio hardware.
<zyga> slangasek: hey, just FYI, it looks like arm64 build of snapd in sid is not migrated/up to date
<matteo> Chipaca: I will rebase it
<Chipaca> matteo: 'k
<icey> I'm trying to use the rust plugin for snapcraft on launchpad, and I'm failing builds with a lot of missing dependencies: curl and file so far; should these be added to the rust plugin or somewhere else?
<jdstrand> liuxg: re slots-- most of the time, yes. this is all defined in the basedeclaration.go file. the reason why is that the slot side gives privileged access to the system and need a snap declaration to allow it
<jdstrand> liuxg: is this just a theoretical example or are you trying to work around a permissions problem that the pulseaudio slot happens to give you?
<jdstrand> I guess it is an example base on the text in the snapcraft.yaml
<mterry> If one of the packages in a stage-packages list is uninstallable, what does snapcraft do?  (I'm maybe seeing that it quietly doesn't include that package?)
<Elleo>   /22
<flexiondotorg> Best lxd name for a cleanbuild e-v-e-r - snapcraft-easily-secure-gnu
<icey> are the builders on launchpad restricting access to some egress? this builder grabbed the rust installer fine but couldn't resolve github.com to fetch dependencies: https://launchpadlibrarian.net/293675704/buildlog_snap_ubuntu_zesty_amd64_rust-hello_BUILDING.txt.gz
<liuxg> jdstrand, yes, it is a demo example from my colleague.  the script is like http://paste.ubuntu.com/23485745/, from my perspective, we normally only use plug instead of slot. I want to know what is the limitation of using slot in a snap app? thanks
<flexiondotorg> icey, There is no network connectivy during the build step on LP, only the pull step.
<popey> mterry: in my experience it just stops
<icey> flexiondotorg: that's unfortunate, but not exactly surprising
<mterry> popey: I see that for build-packages.  But have hints that does different on stage-packages
<flexiondotorg> icey, I'm hoping to discuss with sergiusens today.
<mterry> At least a silo snap build quietly skipped it
<flexiondotorg> I've got a Python package that won't build on LP, even though I've pulled everything in the pull step.
<sergiusens> flexiondotorg oh, really? :-)
<flexiondotorg> o/
<flexiondotorg> Yep.
<flexiondotorg> I discussed with didrocks earlier.
<flexiondotorg> I have a Python project.
<qengho> icey: bring your dependencies in as other "part"s.
<flexiondotorg> snapcraft pulls all requirements.txt in the pull step.
<flexiondotorg> And then pulls again in the build step.
<icey> flexiondotorg: what are the odds of network acecss during build? I can work around it by vendoring deps; qengho cargo (the tool used to build rust binaries) also generally handles dependency management and fetching
<flexiondotorg> And the build fails.
<flexiondotorg> icey, I've been told unlikey.
<icey> flexiondotorg: then I'll continue with the idea of vendoring the deps into the project :-/
<qengho> icey:   part: rustthing: after: [ partnamethatprovidesthethingyounormallydownload ]
<liuxg> jdstrand, what is the fundamental difference between using a slot and using a plug?
<qengho> One provides, one uses.
<sergiusens> flexiondotorg ok, now I can type better without a baby between keyboard and parent :-)
<flexiondotorg> sergiusens, Here is my snapcraft.yaml
<icey> qengho: is it possible to have a part that just runs a bash command?
<flexiondotorg> https://git.launchpad.net/podpublish/tree/snapcraft.yaml
<sergiusens> flexiondotorg is it using a VCS dependency? I have a tentative solution for that
<qengho> icey: Yes. You might have to make your own plugin, but yes, totally.
<flexiondotorg> sergiusens, Here is the failure log
<flexiondotorg> https://launchpadlibrarian.net/293648430/buildlog_snap_ubuntu_xenial_amd64_podpublish_BUILDING.txt.gz
<flexiondotorg> Which still happens even after doing this:
<flexiondotorg> https://git.launchpad.net/podpublish/commit/?id=edd30ec9016840e870f1c8e4c2fca516231b351b
<icey> qengho: I can pmodify the Rust plugin to pull deps in the pull step...?
<renato__> jdstrand, hey, can I auto-connect to content-share interface? Somehow specify the auto-connect on snapcraft file?
<flexiondotorg> sergiusens, I'm happy to help test/fix. I'm building snaps on my own computer like an animal right now ;-)
<sergiusens> flexiondotorg hmm, I thought I resolved this bug...
<sergiusens> flexiondotorg do we have a bug for this?
<flexiondotorg> sergiusens, Not yet. I was waiting to talk with you first.
<sergiusens> qengho icey we are going to allow scriplets in parts, stay tuned
<icey> is it possible to ship a custom plugin with a snap? I'd love to test a change on the LP builder
<icey> sergiusens: it kind of makes more sense (I think) in the rust plugin, as it's something that every rust snap will need to do on LP
<sergiusens> flexiondotorg I know what the problem is; I thought I had fixed it, I guess I didn't
<flexiondotorg> :-)
<sergiusens> icey you can add a custom plugin to your snapcraft project
<flexiondotorg> sergiusens, Do you want a new bug for this?
<sergiusens> not sure what a custom plugin for a snap would mean
<flexiondotorg> If so, on GH or LP?
<sergiusens> flexiondotorg there is no bug :-) LP; GH issues are closed ;-)
<sergiusens> flexiondotorg are you subscribed to snapcraft-announce? :-)
<icey> sergiusens: can I overwrite a normal plugin within my project? or will I have to wait on it getting into snapcraft proper?
<flexiondotorg> Yep, am subscribed.
<sergiusens> icey copy the plugin
<sergiusens> flexiondotorg https://github.com/snapcore/snapcraft end of page for link to tracker :-)
<icey> sergiusens: copy to where?
<sergiusens> icey http://snapcraft.io/docs/build-snaps/plugins
<qengho> icey: If you add a  parts/plugins/x-iceyplugin.py  to your project, then you can use "iceyplu" in your YAML.
<qengho> iceyplugin
<sergiusens> flexiondotorg btw, any updates on the app indicator hack you had for me?
<flexiondotorg> sergiusens, Trevinho see above ^
<flexiondotorg> sergiusens, Trevinho has been working on it.
<qengho> When should we expect the configure hook to work in snappy on classic?
 * Trevinho reads
<sergiusens> qengho once the latest snapd migrates into -updates
<qengho> thx.
<flexiondotorg> Trevinho, sergiusens is asking about the indicator icons in snaps.
<jdstrand> liuxg: slots provide resources and slots consume them
<jdstrand> liuxg: you might be interested in zyga's blog series: http://www.zygoon.pl/search/label/snappy
<flexiondotorg> sergiusens, Here's you bug :-) https://bugs.launchpad.net/snapcraft/+bug/1642281
<mup> Bug #1642281: Unable to build python based snap on Launchpad <Snapcraft:New> <https://launchpad.net/bugs/1642281>
<jdstrand> renato__: you cannot specify auto-connect in the snapcraft.yaml. content is supposed to auto-connect from the same publisher
<Trevinho> sergiusens: so, I'm currently fixing the various qt-sni, appmenu-qt and libappindicators to work propery... This last one still has some problems if confined because interface didn't cover properly all the dbus methods, but jdstrand fixed it... However the idea is to save icons in readable places such as ~/.cache (or better when possible in xdg runtime dir)
<Trevinho> so that unity can read them...
<Trevinho> for themed icons, instead, we can just pass to compiz the proper $SNAP/usr/share/icons as theme path (or ~/.local/share/icons), and that will work
<liuxg> jdstrand, yes, I have read that blog, and I even made the slot working. My question is whether it is fine to use a slot as the way in the snap example.. My understanding is that "slot" is normally used in a service provider, and it needs to be reviewed.
<Trevinho> howver, I'm loving how I can distribute snaps with my patched libraries without having to worry about them to reach the distro :-D.
<Trevinho> so sergiusens once I've the branches ready you could rebuild your telegram app properly
<sergiusens> Trevinho oh, the telegram app uses forked Qt ;-)
<Trevinho> sergiusens: well, appmenu-qt should be still there, isn't it?
<Trevinho> sergiusens:  I mean the implementation of the tray icon is still a plugin
<jdstrand> liuxg: you use a slot if you are providing an implementation for that slot. you used the pulseaudio slot. this snap would be expected to provide pulseaudio functionality such that if something on the system used 'plugs: [ pulseaudio ]' that that snap would be fully functional
<sergiusens> Trevinho http://paste.ubuntu.com/23485830/
<jdstrand> liuxg: think of interfaces as contracts between the slot side and the plugs side
<Trevinho> sergiusens: I don't see any qt bit there... statically linked I guess, right?
<jdstrand> liuxg: if the slots side isn't honring the contract (ie, in this case, using pulseaudio but (perhaps) not providing it, then it has broken the contract
<liuxg> jdstrand, an interesting thing is that http://paste.ubuntu.com/23485745/ shows the result if "pulseaudio" slot  is used that way.
<zyga> jdstrand: hey
<zyga> jdstrand: you may have noticed I pushed some patches into your branch
<liuxg> jdstrand, the snap does not provide the implementation for the slot, but just uses it. So, this snap breaks the contract, and it is not the normal use case of slot?
<icey> how long does it generally take for a commit that lands in master to be available on the LP builders?
<mup> PR snapcraft#908 opened: Let Rust plugin fetch dependencies in pull <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/908>
<jdstrand> liuxg: if the snap only uses the slot, you should use plugs, not slots
<jdstrand> liuxg: you are correct-- a snap that does not provide the implementation for the slot should not use slots
<jdstrand> zyga: I haven't circled all the way around yet, but yes
<liuxg> jdstrand, what happens if a developer uses this way in the app? should we have some check for this when publishing the app?
<jdstrand> liuxg: on upload, the snap would be flagged for manual review. then a reviewer would ask questions
<liuxg> jdstrand, if there is no implementation of the interface, the snap will be rejected? thanks
<qengho> Is there a way to safely ship a snap that has a configure hook? I'm worried that the current snapd poisons configure hooks for a while. I can never know if someone has a snapd that lets a hook exist.
<zyga> qengho: I think you can use assumes stanza
<zyga> qengho: "assumes: ..."
<zyga> qengho: that snap won't install unless snapd supports a given feature
<zyga> qengho: I think there's one for hooks
<qengho> zyga: like, it isn't selected for install from the store then, and falls back?
<zyga> qengho: but since 2.17 AFAIR we have dynamic assumes, so you can just say "assumes: snapd-2.17"
<jdstrand> liuxg: yes, it would be rejected
<zyga> qengho: if you add that to a snap and try to install it snapd will give you an useful message and stop
<coreycb> sergiusens, hi, for openstack the upstream python projects have tox targets for generating some of the config files.  they are typically just commands that are shipped either in the same source tree or in another python project.
<qengho> zyga: so once I ship a version with a configure hook, users with some versions of snapd are stuck. The difference is they might learn why if they go type "snap {refresh,install}" in a terminal?
<coreycb> sergiusens, we're thinking of extending the python plugin with an openstack plugin, but would be curious on your thoughts
<qengho> I guess if their snapd is old enough, it might also still work without configure interface.
<sergiusens> coreycb there's a feature coming that might help you out with this, but given you will have to copy paste this all over and an openstack plugin would be used in more than one project (it is openstack after all) a specific plugin would be just fine
<sergiusens> coreycb you can inherit from the python one if needed
<coreycb> sergiusens, what's the upcoming feature?
<sergiusens> coreycb scriptlets for parts, prepare, build, install
<sergiusens> err... parts: prepare, build, install
<liuxg> jdstrand, thanks for your explanation :)
<coreycb> sergiusens, ah right i've heard about that.  would i be able to get my hands on a dev version of that?
<zyga> qengho: well, core refreshes automatically
<zyga> qengho: and they will be stuck with the old version
<zyga> qengho: I think that is a very sensible behavior
<mup> Bug #1583514 changed: firewall-control and ip[6]table_filter module loading <snapd-interface> <Snappy:Fix Released by stolowski> <https://launchpad.net/bugs/1583514>
<jdstrand> liuxg: yw
<Trevinho> sergiusens: anyway telegram usess libappindicator under the hood.... https://github.com/telegramdesktop/tdesktop/blob/master/Telegram/SourceFiles/platform/linux/linux_libs.cpp#L119
<zyga> tvoss: one observation that is interesting
<zyga> tvoss: when the test failed, I ran "mount"
<zyga> tvoss: qemu:ubuntu-14.04-64 .../tests/main/interfaces-mount-observe# mount
<zyga> tvoss: that didn't show any of the preserved namespaces
<zyga> tvoss: (the bind mounts from nsfs)
<zyga> tvoss: ah, ignore me, it's just mount being dumb (smart)
<zyga> 143 47 0:3 mnt:[4026532106] /run/snapd/ns/mount-observe-consumer.mnt rw - nsfs nsfs rw
<zyga> it's there
<matteo> Chipaca: I've refreshed the PR, but I have to edit the wiki as I had edited interfaces.md
<matteo> but I'll do it only after the PR merge
<zyga> hmm
<zyga> tvoss: but interestignly, the /snap is not
<zyga> qemu:ubuntu-14.04-64 .../tests/main/interfaces-mount-observe# systemctl status snapd-mount.service
<zyga>    Active: inactive (dead)
<zyga> tvoss: maybe something eagerly cleans up
<zyga> tvoss: (purge test?)
<zyga> tvoss: and then we're broken
<zyga> tvoss: what do you think?
<zyga> tvoss: I'll remove the stop condition
<zyga> tvoss: and make this a oneshot service
<zyga> tvoss: just a longshot
<tvoss> zyga: without a stop condition, we will run into issues in snapd.postrm
<zyga> tvoss: will we? it's just a bind mount
<zyga> tvoss: though...
<zyga> tvoss: you mean removal of /snap?
<tvoss> zyga that tries to remove /snap and the removal fails
<tvoss> yup
<zyga> tvoss: did you change that to be opportunistic?
<tvoss> nope
<zyga> tvoss: ok, so when should this be applied
<zyga> tvoss: sorry, to rephrase
<zyga> tvoss: when should this unit be "up"
<zyga> tvoss: IMHO all the time (when snapd is installed)
<zyga> tvoss: but the effect is clearly undone
<tvoss> zyga: well, ideally before any snap specific mount job
<zyga> anything in the restore scripts that might do this?
<zyga> tvoss: yep
<zyga> tvoss: maybe we can tie it to snapd.service?
<tvoss> zyga: let me check @restore script
<zyga> tvoss: before
<zyga> tvoss: that would fix it
<zyga> as long as nothing manually changes /snap
<tvoss> are all mount units "after" snapd
<zyga> and the unit should be oneshot and remainafterexit=yes
<zyga> tvoss: .mount units? I think before actually
<tvoss> and cleanup of /snap should be opportunistic?
<zyga> snapd needs to read them
<tvoss> ah, so we want all mount units to be after snapd-mount.service
<zyga> tvoss: well... not strtictly, rbind should handle that
<zyga> tvoss: the problem I saw right now is that the effect was undone by something
<zyga> tvoss: I switched to oneshot units so that we can at least see if the unit is up or down next time it happens
<tvoss> +1
<zyga> tvoss: but I think we should be "before snapd.service"
<zyga> (not sure how to specify that yet)
<tsdgeos> any reason a dbus call would fail to an existing dbus service if it's running in a non confined snap?
<zyga> tvoss: I think the restore scripts do that
<zyga> tsdgeos: yes, because confined processes cannot reach out to arbitrary dbus endpoints (including unconfined)
<zyga> tsdgeos: look for apparmor denials in the journal
<tsdgeos> zyga: even between processes on the same "unconfined snap"?
<zyga> tsdgeos: there are no unconfined snaps
<tsdgeos> ok :D
<zyga> tsdgeos: a process in a snap cannot reach out to dbus services from outside that snap (confined or not)
<tsdgeos> zyga: a little more help with "look for apparmor denials in the journal" ?
<zyga> tsdgeos: look for the apparmor denials
<zyga> tsdgeos: grep for DENIED :)
<zyga> tsdgeos: and there's a snapd-debug snap AFAIK
<zyga> tsdgeos: it helps but there's always the raw log
<tsdgeos> zyga: where do i grep (yes i'm very newbie)
<tsdgeos> i.e. where's the journal?
<zyga> tsdgeos: journalctl | grep DENIED
<tsdgeos> ah, tx
<tvoss> zyga: aha, tests/lib/reset.sh purges a lot of stuff and only starts snapd.socket again
 * zyga looks
<tvoss> zyga: at the very least, we should run snapd.prerm before snapd.postrm purge
<tvoss> zyga: and do a systemctl start snapd-mount.service
<zyga> tsdgeos: crashed again, different test (aaargh, the ordering)
<zyga> er
<zyga> tvoss: ^
<zyga> tvoss: checking service status
<zyga>    Active: active (exited) since Wed 2016-11-16 17:27:00 CET; 2min 36s ago
<tsdgeos> sorry for starting with t :D
<zyga> qemu:ubuntu-14.04-64 .../tests/upgrade/basic# cat /proc/self/mountinfo | grep /snap
<zyga> 45 23 8:1 /snap /snap rw,relatime shared:1 - ext4 /dev/sda1 rw,data=ordered
<zyga> this time it looks good
<zyga> but the test still failed
<tvoss> argh
<zyga> tsdgeos: no worries :)
<tvoss> zyga: ignore upgrade/basic for now, I haven't fixed that, yet
<zyga> tvoss: so at least this much is better
<tvoss> zyga: investigating after a round of meetins
<zyga> internal error, please report: running "test-snapd-tools.echo" failed: cannot find installed snap "test-snapd-tools" at revision 3
<tvoss> zyga: yeah, thats the "snap list" reports broken packages
<zyga> broken == snapd cannot read meta/snap.yaml
<zyga> so unmounted or messed up mounts
<zyga> I'll return to that test, trying the rest
<zyga> so far, suspiciously green
<tvoss> green is the new black
<zyga> still good
<zyga> just ran 2016/11/16 17:50:33 Restoring qemu:ubuntu-14.04-64:tests/main/postrm-purge...
<zyga> so if stuff fails now it might be related
<zyga> still green
<zyga> tvoss: any idea if just doing this might have such a big impact?
<zyga> http://paste.ubuntu.com/23486289/
<zyga> tvoss: another idea, have snapd do it :)
<zyga> tvoss: before any any any operation
<zyga> tvoss: on early startup
<zyga> tvoss: read mountinfo and do the bind mount dance
<zyga> tvoss: or from snap-confine's code (we parse mountinfo already)
<zyga> tvoss: but that's after we are merged
<zyga> (into snapd)
<tvoss> zyga: yeah, so I think the unit is fine
<tvoss> a bit ugly, but it gets the job done quite reliably
<zyga> tvoss: it may bind mount /snap twice
<zyga> tvoss: semi harmless but still ...
<zyga> tvoss: ha
<zyga> tvoss: 2016/11/16 17:54:22 Failed tasks: 1
<zyga> tvoss: just the     - qemu:ubuntu-14.04-64:tests/upgrade/basic
<zyga> I'll run another loop and commit this
<tvoss> ack, great
<zyga> tvoss: if it breaks on the upgrade job again I'll dig into it
<zyga> tvoss: pushed
<tvoss> zyga: ack and thx
<zyga> the weird and invasive change made by github is probably the biggest collaborationi booster ever in foss community
<tvoss> zyga: I'm not following for the "bind mount twice" argument
<zyga> just push to all the pull requests!!
<tvoss> zyga: you mean actually collaborating on something?
<tvoss> ;)
<zyga> tvoss: if the service breaks after rbind /snap but before --make-rshared
<zyga> tvoss: exactly ;-)
<tvoss> zyga: hmmm, I'm taking a note, usually pitti has some good advice to offer, too
<zyga> tvoss: feels like a simple C program to write
<zyga> (conditions apply)
<tvoss> zyga: you mean to check mount info
<zyga> tvoss: yes
<zyga> tvoss: but snap-confine can
<zyga> tvoss: (or the sources have api for that)
<zyga> got an unrelated store failure, iterating
<zyga> tvoss: I'me EODing, tests in flight
<zyga> tvoss: what is the situation you see now?
<mterry> sergiusens: I'm seeing a weird bug. When I'm building the u8 snap locally, webbrowser-app (directly listed in stage-packages) is included just fine.  But when building in a silo, it's not included.  Build log doesn't even mention it.  https://launchpadlibrarian.net/293688704/buildlog_snap_ubuntu_xenial_amd64_unity8-session-silo_BUILDING.txt.gz
<mterry> Do you know of any reasons snapcraft would silently exclude a stage-package?
<kyleN> Hi. are qt apps snappable yet with strict? mine does not display without devmode and i notice devmode is common in playpen qt apps.
<popey> kyleN: yes
<kyleN> popey, is there an example snapcraft.yaml you can point me to?
<popey> not sure, I don't really work on desktop stuff
<popey> I have done a couple of personal snaps which include qt
<popey> and they don't need devmode, I'm not sure why you'd think qt would need it
<kyleN> popey. because when I set to devmode it displays, when I set to strict it does not actually display.  I do add: after: [desktop/qt5]. any further tips?
<popey> check what's failing with dmesg | grep DENIED
<popey> also snappy-debug.security scanlog
<popey> run ^ that, then start your app
<popey> (in strict)
<kyleN> popey, snappy-debug.security scanlog MYAPP | grep DENIED does not show much. wherease desmg shows a lot of DENIEDs.
<kyleN> popey, on closer inspection I don't think the dmesg DENIEDs are related to my snap
<popey> what exactly is appearing?
<popey> and what happens when you run the app?
<kyleN> I see evince and docker denieds which are not related.
<kyleN> when I run my app in strict, I simply do not see a window for it. in devmode I do
<popey> strace it?
<popey> see what it stops on
<kyleN> ok thanks for the tip
<kyleN> popey, hmm: QXcbConnection: Could not connect to display :0
<kyleN> popey, yet I do have this:  plugs: [unity7, x11, opengl, network-bind]
<kyleN> anyway, enough to go on for now
<popey> it's X11 I think?
<popey> I have a horrid feeling it's case sensitive
<sergiusens> kyleN popey you can always run `snap interfaces` to verify it is connected
<tvoss> zyga: catching up after dinner, hang on
<zyga> tvoss: I'm spending time with kids now, sorry, just drop me messages
<tvoss> Zyga, no worries, I'll keep you posted ð
<mwhudson> davmor2: hey, i assume from the lack of noise that console-conf works for you now?
<davmor2> mwhudson: no sorry got moved onto something else I'll have a look in a minute
<mwhudson> davmor2: ah ok
<icey> sergiusens: when I run the apt command to install test dependencies (in hacking.md), I get unable to locate package python3-responses
<icey> taking that out leaves me unable to run the unit tests
<davmor2> mwhudson: yeap works now
<Trevinho> sergiusens: hey, how do organize a remote part?
<Trevinho> I mean if I've a file locally that will override something on remote, I want not to stage the remote par t bits... but how can I do it?
<davmor2> mwhudson: damn you, you're fixing my bugs to quickly now I feel obliged to find more ;)
<elopio1> exit
<mup> PR snapcraft#906 closed: indicators: support TERM=dumb <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/906>
<sergiusens> Trevinho you use stage and snap keywords, not organize, unless you want to move it out of the way instead
<Trevinho> sergiusens: yeah, I meant organizing in a general term.. not in the keyword... But still, I can't apply a such thing to a remote part, isn't it?
<sergiusens> Trevinho yes you can
<sergiusens> Trevinho it overrides do, so snapcraft define <part> to see if it defines anything and aggregate to that
<Trevinho> sergiusens: mh, I'm missing the syntax then...
<sergiusens> icey HACKING.md does not mention python3-responses, just pip3 install -r ...
<sergiusens> icey debian/control however does, but it is not mentioned in HACKING.md
<icey> sergiusens: look at the top... in the section titled: Test Dependencies
<icey> - You'll need to add the following dependencies to run the tests.
<icey>     sudo apt install python3-flake8 python3-fixtures python3-testscenarios python3-mock python3-responses
<sergiusens> icey oh look at that :-(
<sergiusens> icey can I ask you to follow https://github.com/snapcore/snapcraft/blob/master/HACKING.md#installing-using-pip
<icey> sergiusens: and I just filed a bug on LP because I apparently can't get the tests running on clean xenial either
<icey> using the pip installer
<sergiusens> icey python3-responses should be on xenial though
<sergiusens> icey I am on xenial and reinstalled recently and did a test run on the pip instructions
<icey> sergiusens: I first ran into that trying to test on trusty (my goto test docker box)
<icey> sergiusens: following the pip instructions, I get AttributeError: python3: undefined symbol: archive_errno
<sergiusens> icey oh, deb deps on trusty would be really out of date
<sergiusens> icey you really want xenial
<icey> sergiusens: agreed, and my real machine is on Zesty
<sergiusens> icey oh... rpm support added that :-/
<icey> sergiusens: so... how do I run tests now?
<Trevinho> sergiusens: oh, so with "snapcraft define desktop-qt5" (say) i see the part definition, but... then?
<Trevinho> I mean I should redefine it locally?
<sergiusens> icey can you try installing libarchive13
<sergiusens> icey apt install
<sergiusens> Trevinho http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/
<icey> sergiusens: trying now
<sergiusens> icey if it works I'll fix hacking.md right now
<Trevinho> sergiusens: ok, great... thanks
<icey> sergiusens: I don't mind submitting a PR to update that :)
<icey> python3-pip would be a good suggestion as well, the base docker ubuntu:xenial image doesn't have it :)
<sergiusens> icey I want to do more than add that dep
<sergiusens> sounds good
<icey> sergiusens: I figure it's not bad for me to update that since I'm going through installing stuff on a clean box to get it to work :)
<Trevinho> sergiusens: just wondering why that isn't inside the official docs, though... :-)
<icey> sergiusens: tests haven't finished yet but are running: https://github.com/snapcore/snapcraft/pull/909
<mup> PR snapcraft#909: update dependencies for running the tests <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/909>
<mup> PR snapcraft#909 opened: update dependencies for running the tests <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/909>
<sergiusens> icey great and ^
<sergiusens> ah, icey you did 909? This is what I had in mind https://github.com/snapcore/snapcraft/pull/910
<mup> PR snapcraft#910: Update HACKING.md <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/910>
<icey> sergiusens: may want to look at my pull, there's 3 packages I've found so far needed to get tests happy on a clean xenial
<sergiusens> icey just missing squashfs-tools I guess
<icey> sergiusens: ack
<mup> PR snapcraft#910 opened: Update HACKING.md <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/910>
<mwhudson> davmor2: :)
<mup> PR snapcraft#911 opened: Remove the outdated all snaps image set up for snaps tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/911>
<mup> PR snapcraft#909 closed: update dependencies for running the tests <Created by ChrisMacNaughton> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/909>
<mup> PR snapcraft#910 closed: Update HACKING.md <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/910>
<pitti> sergiusens: FYI, I just implemented bug 164183 (elopio was asking about that)
<mup> Bug #164183: sata controller/drive reports exception Emask 0x10 SAct 0x0 SErr 0x40d0002 action 0x2 frozen <linux (Ubuntu):Expired> <https://launchpad.net/bugs/164183>
 * pitti appends a missing '1'.. bug 1641831
<mup> Bug #1641831: It's not possible to select the test to run from the github integration <Auto Package Testing:Fix Released by pitti> <https://launchpad.net/bugs/1641831>
<sergiusens> pitti nice!
#snappy 2016-11-17
<mup> PR snapcraft#912 opened: Add a gradle demo and test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/912>
<mup> PR snapcraft#652 closed: Demo/gradle <Created by ZenHarbinger> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/652>
<mup> PR snapcraft#911 closed: Remove the outdated all snaps image set up for snaps tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/911>
<mup> PR snapcraft#871 closed: Remove XXX comment from stage-packages <Created by nhandler> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/871>
<mup> PR snapcraft#913 opened: help: update stage-packages and build-packages <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/913>
<mup> PR snapcraft#914 opened: meta: icon is now dedeprecated <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/914>
<mup> PR snapcraft#761 opened: Remove dangling symlink from JDK plugin <Created by gnuoy> <https://github.com/snapcore/snapcraft/pull/761>
<HOAI> hello everyone, I just installed Ubuntu Snappy in Raspberry Pi3, However, I cannot build any packet such as apache2, sql, can someone help me please ??, I'm new in snappy
<zyga> good morning
<dholbach> hey hey
<foxmask> bonjello
<mup> Bug #1620560 changed: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released by stolowski> <https://launchpad.net/bugs/1620560>
<zyga> tvoss: I think I understand it now
<zyga> tvoss: testing a simple fix
<tsdgeos> is there a difference in what happens between
<tsdgeos> sudo snap install --devmode --force-dangerous mysnap.snap
<tsdgeos> and
<tsdgeos> sudo snap try path/to/mysnap/prime --devmode
<tsdgeos> ?
<zyga> yes
<zyga> tsdgeos: the difference is as follows:
<zyga> tsdgeos: snap install copies the snap (across the connection) and installs it just as any other snap from the store (dangerous option means that some assertion are ignored)
<zyga> tsdgeos: try on the other hand copies nothing and uses the directory indicated directly, ther'es a bind mount from that directory to /snap/$SNAP_NAME/$SNAP_REVISION
<zyga> tsdgeos: you cannot remove that directory (rename it, break meta/snap.yaml) without some consequences
<zyga> tsdgeos: the content is also live, you can change it and observe effects immediately
<tsdgeos> because i'm seeing what i think is a runtime difference,
<tsdgeos> do you think that's possible?
<zyga> tsdgeos: at runtime, perhaps still, the directory might be writable
<zyga> tsdgeos: I think we didn't fix that yet
<zyga> tsdgeos: what do you observe?
<Chipaca> matteo`: ping
<matteo`> Chipaca: pong
<tsdgeos> zyga: i think i'm seeing some dbus calls succeed in the install case and not in the try case
<Chipaca> matteo`: what happened to docs/interfaces.md in your #2193 ?
<zyga> tsdgeos: dbus is interesting, it is usually not affected by anything, can you show me the apparmor denial (journalctl | grep DENIED) please
<zyga> Chipaca: isn't that moved to the wiki now?
<Chipaca> ah!
<Chipaca> :-)
<Chipaca> zyga: and how is that kept in sync with the code?
<zyga> ironically editing the wiki with git is nice :)
<zyga> Chipaca: manually but the process is lighter
<zyga> Chipaca: we should just poke people to edit it
<Chipaca> zyga: so should there be a PR for the wiki for every PR that needs to update docs?
<tsdgeos> zyga: the thing is there's no denials, but i see code going further in one case than in the other, i think i'm wasting your time, let me do some more debugging, sorry for the noise
<Chipaca> tsdgeos: no denials but things not working usually means seccomp
<Chipaca> tsdgeos: but I have no context other than what you said just there
<zyga> tsdgeos: do you have an encrypted home directory, or home directory in some non standard location
<matteo`> Chipaca: I found this? https://github.com/snapcore/snapd/blob/master/docs/MOVED.md
<zyga> tsdgeos: I'm happy to help, bugs like this always show insight into what the real system is doing
<Chipaca> matteo`: yep! sorry, i forgot about that move (see my conversation with zyga)
<Chipaca> matteo`: but you're still on the hook for having the docs for this be in place once your branches land
<zyga> matteo`: the up side is that you just hit the edit button and type away :)
<zyga> matteo`: you can use git if you prefer
<matteo`> zyga: I wanted to edit the wiki only after the PR merge
<matteo`> otherwise I'll have documentation for a non existing feature
<zyga> matteo`: that's fine, it's a wiki :D
<zyga> matteo: just edit (you can say  "PENDING merge" or something)
<matteo> ok
<zyga> matteo: it'd be nice to indicate "since snapd 1.2.3" actually
<zyga> matteo: so you can just use the future version there
<matteo> ok
<Chipaca> matteo: rawusb is going to land in a few more minutes, unless i386 hates you
<zyga> Chipaca: raw usb interface?
<Chipaca> usb-raw
<matteo> yes, direct usb access, eg. for sane
<zyga> Chipaca: woot, I could use that for my test farm to drive some tools I have
<zyga> (now if only 14.04 wasn't so mysteriously failing on the upgrade test)
<Chipaca> zyga: woot at matteo; i'm just pushing it
<zyga> thank you matteo :)
<matteo> btw I have an example snap that uses it
<matteo> it contains lsusb
<Chipaca> zyga: and it might get renamed; jdstrand did ask niemeyer about the name, but that was 21 days ago
<Chipaca> in snapd time that's past the statute of limitations1
<zyga> matteo: perfect, I was thinking about a libusb based flash tool for STM devices
<zyga> Chipaca: that's like eternity ;0
<matteo> https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/examples/tree/usb-utils/snapcraft.yaml
<Chipaca> precisely
<matteo> do you have an STM MCU? Like STM324F?
<Chipaca> zyga: this thing about me being able to push branches at PRs to unbreak them is terrible
<zyga> matteo: yes, a few actually
<zyga> matteo: I briefly worked on the lm4tools that can flash them
<matteo> nice, I have some too
<zyga> Chipaca: terrible or terrific?
<matteo> did you flash them with gdb and openocd?
<zyga> matteo: no, just lm4tools, it was way easier and I think, at the time, the only supported way
<matteo> Chipaca: I alphabetizet everything in all.go and all_test.go, but you put NewAvahiObserveInterface after NewCupsControlInterface
<matteo> how much time the autopkgtest need to run?
<Chipaca> matteo: I don't think I did that?
<Chipaca> 	NewAlsaInterface(),
<Chipaca>   	NewAvahiObserveInterface(),
<Chipaca>  +	NewBluetoothControlInterface(),
<Chipaca>  +	NewCameraInterface(),
<Chipaca>  +	NewCupsControlInterface(),
<Chipaca>   	NewDcdbasControlInterface(),
<matteo> in all_test
<matteo> https://github.com/snapcore/snapd/pull/2193/commits/1b9586330a2bbdf7e3534fe3d511a86fa8871da3
<mup> PR snapd#2193: add usb-raw iterface <Created by teknoraver> <https://github.com/snapcore/snapd/pull/2193>
<Chipaca> matteo: gah
<matteo> maybe you did indirectly, while merging
<Chipaca> matteo: I noticed and fixed it in all.go, but missed it in all_tests.go
<Chipaca> when merging, yes
<Chipaca> matteo: I'll wait for all green, then fix this and wait for just spread green and land
<Chipaca> matteo: unless you'd rather do it yourself
<Chipaca> actually, this is strange
<Chipaca> in all_tests locally i have it ordered
<Chipaca> ah, no, wrong branch
 * Chipaca is tracking too many right now
<matteo> zyga: done the wiki
<matteo> Chipaca: I'm for the "wait just for spread and merge" thing
<Chipaca> zyga: you looked at 2249 before, could you +1 it if appropriate?
<gerry_> Hi I am thinking of making a snap of a java program I have written where would it be available I read something about a snappy strore but I can not find a trace of that?
<zyga> Chipaca: checking
<Chipaca> gerry_: the snap store doesn't have a web interface accessible from a non-snap system
<Chipaca> gerry_: (you could install snapweb)
<Chipaca> gerry_: the snap store is what `snap find foo` talks to
<Chipaca> mvo: https://travis-ci.org/snapcore/snapd/jobs/176656727
<Chipaca> mvo: :-D
<Chipaca> mvo: but also :-/
<gerry_> ok so I am using ubunutu it has a new menu item called software as well as the ubuntu software center would it become available in that?
<didrocks> gerry_: yeah, "sofware" (not ubuntu software center) displays snaps and deb packages
<gerry_> ok thank you for your help one more question at the moment I have a jar with all dependencies (one library) contained in it would this be the best way to make a snappy package with the jar ?
<didrocks> gerry_: I'm not particularly familiar with java based snap, but you sohuld give a look at the jdk snapcraft plugin IMHO
<gerry_> ok thank you very much for your help
<didrocks> yw! keep us posted :)
<zyga> tvoss: found one more issue, fixed it, trying
<zyga> tvoss: we didn't enable the mount unit
<zyga> tvoss: I switched the snapd-mount.sevice to a real snap.mount unit
<zyga> tvoss: fingers crossed, it also mkdirs the /snap directory for free ;)
<zyga> tvoss: ha, I think I begin to have something
<zyga> tvoss: Nov 17 11:59:20 autopkgtest mount[20017]: mount: according to mtab /var/lib/snapd/snaps/core_394.snap is already mounted on /snap/core/394 as loop
<zyga> tvoss: that's a lie, mtab is garbage
<zyga> tvoss: I'll patch the test setup to rm /etc/mtab and use a symlink to see if that changes
<tvoss> zyga, +1, I'll another version of snapd into the ppa
<tvoss> zyga: did you push your most recent changes?
<zyga> tvoss: no, none of them improve the state yet
<tvoss> zyga: ack, I'll push a new snapd package nevertheless
 * zyga -> break
<Odd_Bloke> ogra_: Could you give me an update on where we are with https://bugs.launchpad.net/snappy/+bug/1639878?
<mup> Bug #1639878: pc-kernel.snap missing drivers necessary for Hyper-v <Snappy:New for ogra> <https://launchpad.net/bugs/1639878>
<mup> PR snapcraft#891 closed: repo: apt-mark new build-packages as automatically installed <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/891>
<zyga> tvoss: trying one more thing now
<zyga> tvoss: I think systemd and /etc/mtab being a real file don't work
<tvoss> zyga: uploaded to ppa, waiting for accept/reject message
<tvoss> zyga: aha
<zyga> tvoss: the rshared on / hides the issue somehow but not sure how
<zyga> tvoss: the message I got was that systemd didn't do something it usually does (mount something) because it was apparently mounted (in the stale mtab file)
<zyga> tvoss: it's all a bit shoot-in-the-dark though :/
<tvoss> zyga: okay, let me find some help
<zyga> tvoss: nope, didn't help - still digging
<zyga> qemu:ubuntu-14.04-64 .../tests/upgrade/basic# systemctl status snap-core.mount
<zyga>    Loaded: error (Reason: No such file or directory)
<tvoss> zyga: I'm grabbing lunch, let's jump on a hangout with pitti right after that
<zyga> tvoss: ok
<zyga> tvoss: ah, silly me, the escaping causes my queries to systemd to give confusing messages
<zyga> tvoss: let's talk here so that pitti can be in the loop
<tvoss> v+1
<zyga> tvoss: testing that new util-linux from ppa:pitti/systemd-semaphore
<tvoss> ack
<tvoss> okay, grabbing a quick bite
<zyga> tvoss: no change
<mvo> Chipaca: haha, thank you!
<zyga> tvoss: thinking about what I'm seeing
<zyga> tvoss: across restart we just lose all the .mount units
<zyga> tvoss: is there anything that would keep them mounted?
<tvoss> zyga: across restart?
<tvoss> zyga: so that's snapd restart, correct?
<zyga> tvoss: across snapd update
<zyga> tvoss: that updates the package and runs some of the scripts
<zyga> tvoss: (presumably the postrm / prerm ones
<zyga> tvoss: I don't see anything starting mount units there
<tvoss> zyga: so snapd.postrm purge removes everything
<tvoss> hmmm, let me take a look at the actual test case
<zyga> tvoss: I see a clear failure
<zyga> the mount units are all stopped
<zyga> hmm, but we don't purge, do we?
<zyga> tvoss: is there an easy way to see the list of maintainer scripts / arguments across dpkg/apt transaction?
<zyga> mvo: ^^ perhaps you know
<tvoss> zyga: /var/lib/dpkg/info has got all the scripts of all currently installed versions
<mvo> zyga: I'm not sure I understand the question? do you want to see how they are called and in what order?
<zyga> mvo: yes
<zyga> mvo: something like that
<zyga> mvo: when a package update occurs, what gets called and with what arguments
<zyga> mvo: I understand some of the old scripts are called, then some of the new scripts are called
<zyga> mvo: but details elude me
<mvo> zyga: https://wiki.debian.org/MaintainerScripts has a flow diagram
<mvo> zyga: the interessting one is "upgrading"
<zyga> thanks
<zyga> tvoss: I pushed my local patches, have a look
<zyga> tvoss: some of those should be removed later (HACK)
<tvoss> looking
<zyga> mvo: I see, it is quite "interesting"
<zyga> tvoss: standup time for me
<tvoss> zyga: ack
<tvoss> zyga: probably makes sense if I join, too
<tvoss> do you have a link handy?
<zyga> tvoss: sent
<tvoss> zyga: thx
<zyga> pitti: http://pastebin.ubuntu.com/23490458/ <- is this indicating the thing is mounted or not?
<jhodapp> Anybody on the snappy team seen this issue? Generally this resulted from me building my own snapd/snap and running that but now I want to use the system one installed via apt: http://pastebin.ubuntu.com/23490401/
<sergiusens> jhodapp from what I read mvo mentioning; your db got migrated so you cannot go back
<jhodapp> sergiusens, is there a way I can start over? I don't care what's installed
<mvo> jhodapp: yeah, sorry for that, please use the version of snapd in xenial-proposed that should be fine and compatible
<mvo> jhodapp: starting over is also possible with "apt purge snapd" but its not really needed
<sergiusens> jhodapp you misunderstand, I only said mvo mentioned, not that I can help you further than that ;-)
<jhodapp> mvo, I tried apt purge snapd but that didn't seem to do it
<jhodapp> sergiusens, heh :)
<mvo> jhodapp: oh? what is leftover? did it fail?
<jhodapp> mvo, let me try it again and get you the output
<mvo> thank you
<mvo> jhodapp: fwiw, we use purge in our tests to clean stuff up, so it should work in general, but maybe you hit some corner case (or we have another bug)
<zyga> tvoss: that didn't change anything (not touching snap.mount in prerm)
<jhodapp> mvo, here's the whole session: http://pastebin.ubuntu.com/23490516/
<zyga> interestingly
<zyga> this is the journal for the core snap's mount unit
<zyga> qemu:ubuntu-14.04-64 .../tests/upgrade/basic# journalctl -u snap-core-394.mount
<zyga> -- Logs begin at Thu 2016-11-17 14:23:33 CET, end at Thu 2016-11-17 14:28:51 CET. --
<zyga> Nov 17 14:28:35 autopkgtest mount[19811]: mount: warning: /snap/core/394 seems to be mounted read-only.
<zyga> that's it!, it's not unmounted here
<himanshub16> I tried creating a sample snap using the tutorial on snapcraft.io (gnu-hello). On installing the snap created, it tried to connect to network ?
<zyga> ah, unmount doesn't generate any logs, bummer
<tvoss> totally unrelated: I think I will snap up icq
<zyga> is that still a thing? reminds me of windows 2000 and "I have a modem" days
<zyga> tvoss: I patched the mount unit to be read only, inclined to add something to them to just see when it is being mounted/unmonted
<zyga> unmounted*
<zyga> pitti: anything I can add to a .mount unit to make it verbose?
<tvoss> zyga: it's actually open-source, and available for linux
<tvoss> zyga: distributed as a tar.xz containing a single executable
<tvoss> zyga: code is here: https://github.com/mailru/icqdesktop
<zyga> tvoss: wow, is that the same "flower-logo" icq from two decades ago?
<tvoss> zyga: precisely that ;)
<tvoss> zyga: come on, install it, I wanna check if there is still the "uh-oh" sound :)
<zyga> lol :)
<jhodapp> mvo, any thoughts?
<zyga> let's fix stuff to run on 14.04 first
<zyga> then we can use icq as a trophy
<mvo> jhodapp: yes
<mvo> jhodapp: but sorry, was distracted by a meeting
<tvoss> zyga: sure
<zyga> tvoss: I think I will follow niemeyer's advice and build a small test case to experiment and repdocude the behavior
<jhodapp> mvo, np
<mvo> jhodapp: could you please do a "ls -al ~/.snap" and pastebin that?
<jhodapp> sure
<zyga> tvoss: I still don't get what stops those units and why this happens on 14.04 but not on 16.04
<tvoss> zyga: okay, I will instrument the maintainer scripts to be verbose and tell us what is actually called
<zyga> tvoss: thanks
<jhodapp> mvo, ls: cannot access '/home/jhodapp/.snap': No such file or directory
 * mvo scratches head
<jhodapp> lol
<mvo> jhodapp: is there anything unusal about the system? coudl I get the output of "id ; env" please?
<zyga> jhodapp: congratulations, welcome to the snappy team, you have just passed the secret test
<zyga> ;)
<pitti> zyga: no, inactive/dead says "not mounted"
<mvo> jhodapp: welcome on board!
<zyga> pitti: thanks!
<jhodapp> zyga, hahaha
<zyga> pitti: is there a way to see when systemd stops/starts mount units? (or just one for experiment)
<pitti> zyga: verbose> a mount unit is just a wrapper around bin/mount, so you'll see its output in the journal; mount itself isn't very chatty, but you should certainly be able to see the effects of it?
<mvo> jhodapp: the code tries to do a lookup of the current user but for some reason this fails here and I wonder how that could happen
<zyga> pitti: I'm looking for "this is where that unit was stopped and something got unmounted"
<pitti> zyga: sure, it's all in the journal; journalctl -f is useful
<pitti> Starting Mount unit for core
<pitti> Stopping Mount unit for core
<jhodapp> mvo, http://pastebin.ubuntu.com/23490552/
<jdstrand> Chipaca: I see you talking about docs and git, etc. where is that branch? I need to add some stuff
<zyga> pitti: hmm, is the 14.04 systemd doing that, I cannot see it
<jdstrand> doesn't seem to be in https://github.com/snapcore
<zyga> jdstrand: snapd wiki is a git repo, it's a github thing
<jdstrand> oh I see the link now
 * zyga tries and gets a quick coffee 
<jdstrand> funny, I just edited the wiki manually the other day
<jdstrand> Chipaca: nm
 * tvoss has test running with verbose maintainer scripts
<Chipaca> jdstrand: sorry, was in a hangout
<Chipaca> jdstrand: and then fixing a bug wrt resource consumption
<Chipaca> (IOW getting lunch)
<zyga> tvoss: first one that cracks this and fixes it gets a beer :)
<jdstrand> no worries at all :)
<tvoss> zyga: ;)
<mvo> jhodapp: I traced through the source and it looks like you get an EPERM in getpwuid_r() which is super strange. anything unusal about this system you are using? inside some container or anything else that might give a clue?
<mvo> jhodapp: an strace -f -s1024 snap list would be nice as well, but I suspect the sudo you need for this will alter the behavior
<jhodapp> mvo, nope, it's just my laptop running 16.04
<jhodapp> mvo, that requires sudo?
<Chipaca> jhodapp: no
<mvo> jhodapp: no, sorry
<mvo> (too much stuff going on at the same time)
<jhodapp> mvo, http://pastebin.ubuntu.com/23490606/
<jhodapp> mvo, no prob
<mvo> jhodapp: aha, there you go: "[pid  4186] open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)", what is "ls -al /etc/passwd"?
<mvo> jhodapp: on your system?
<jhodapp> mvo, -rw-r--r-- 1 root root 2954 Jul  7 09:17 /etc/passwd
<zyga> jdstrand: any chance your are over ssh
<zyga> er
<zyga> jhodapp: ^
<zyga> jhodapp: and ssh is confining all the sessions with apparmor like jdstrand does
<mvo> jhodapp: hmm, that looks fine, do you see something in "dmesg|grep DENIED"
<jhodapp> zyga, nope, I'm at the keyboard...no ssh
<mvo> jhodapp: its interessting, if I set it to 600 I get exactly the same error as you get
<zyga> jhodapp: any evil maids with hypervisor malware in sight?
<jhodapp> mvo, journalctl -f output for snap list: http://pastebin.ubuntu.com/23490617/
<zyga> pitti: since I don't get any of the stopping/starting messages on 14.04 does that mean I just don't have some journal glue to see this?
<jhodapp> zyga, lol, I have kvm and virtualbox installed on this system, but neither are running
<mvo> jhodapp: so we know now why it happens :) "Nov 17 08:54:51 smith audit[4327]: AVC apparmor="DENIED" operation="open" profile="/usr/bin/snap" name="/etc/passwd" pid=4327 comm="snap" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0"
<zyga> jhodapp: waaat
<zyga> profile="/usr/bin/snap"
<zyga> that's not something we confine
<mvo> zyga: exactly
<zyga> jhodapp: can you look at /etc/apparmor.d/ and grep for /usr/bin/snap
<zyga> jdstrand: ^ ?
<jhodapp> yeah, one sec
<mvo> jhodapp: sudo grep -r /usr/bin/snap /etc/apparmor.d
<zyga> you have that evil maid somewhere
<zyga> securing your snaps
<jhodapp> I feel so protected
<mvo> or the opposite, someone trying to make the system more secure :)
<jhodapp> lol
<jhodapp> mvo, http://pastebin.ubuntu.com/23490626/
<zyga> jdstrand: dpkg -S /etc/apparmor.d/cache/usr.bin.snap
<zyga> er
<zyga> sorry jdstrand, I hate irssi's tab completion
<zyga> jhodapp: dpkg -S /etc/apparmor.d/cache/usr.bin.snap
<zyga> maybe a missing conflicts with some other package
<mvo> jhodapp, zyga: probably without the /cache/ ?
<zyga> or missing maintainer script that removes that file when the package is removed
<jhodapp> zyga, dpkg-query: no path found matching pattern /etc/apparmor.d/cache/usr.bin.snap
<zyga> oh, I totally didn't see the cache part
<zyga> hmmm
<zyga> yep
<zyga> jhodapp: which release are you on?
<zyga> http://packages.ubuntu.com/search?searchon=contents&keywords=usr.bin.snap&mode=exactfilename&suite=yakkety&arch=any <- no hits
<zyga> jhodapp: can you please pastebin that file
<mvo> jhodapp: dpkg -S /etc/apparmor.d/usr.bin.snap please
<mvo> zyga: I can't find anything in apt-file on xenial or yakkety
<zyga> same here
<zyga> curious
<jhodapp> mvo, dpkg-query: no path found matching pattern /etc/apparmor.d/usr.bin.snap
<mvo> :(
<jhodapp> zyga, pastebin which file?
<mvo> jhodapp: could you please pastebin /etc/apparmor.d/usr.bin.snap ?
<zyga> yep
<mvo> jhodapp: this is a really interessting issue you found!
<jdstrand> since when is /usr/bin/snap confined?
<jhodapp> lol, I didn't do anything fancy
<zyga> jdstrand: it's not, something else is at play here and assumes the same name, perhaps one of the packages that conflict with snapd
<mvo> jdstrand: this is what we are trying to figure out :)
<jhodapp> mvo, http://pastebin.ubuntu.com/23490647/
<zyga> # Last Modified: Mon Oct 24 13:21:22 2016
<mvo> jdstrand, zyga -^
<zyga> what did you do on oct 24?
<mvo> super strange
<mvo> also the content isâ¦ very bare
<zyga> did you write that file? who's the owner
<mvo> I guess its root:root ;)
<jdstrand> /etc/apparmor.d/cache/usr.bin.snap isn't going to be shipped by anything
<jdstrand> /etc/apparmor.d/usr.bin.snap would be the thing that was shipped
<zyga> jdstrand: apt-file knows about neither
<jhodapp> mvo, -rw------- 1 root root 141 Oct 24 13:22 /etc/apparmor.d/usr.bin.snap
<zyga> so weird
<zyga> 600 is not typical
<mvo> jhodapp: do you have anything in /var/log/apt/history.log* around that time?
<jdstrand> what are the contents of /etc/apparmor.d/usr.bin.snap?
<mvo> jhodapp: anything that got installed on that date/around this time?
<zyga> jhodapp: anyway, fire your maid, remove that file, unload the profile with apparmor_parser -R usr.bin.snap # AFAIR
<mvo> jdstrand: http://pastebin.ubuntu.com/23490647/
 * jhodapp checks
<jdstrand> that looks like a test profile
<jdstrand> not as in something we ship, but as in, what one might start with to see what it needed
<zyga> pitti: any advice on journal / systemd on 14.04
<jhodapp> mvo, I installed apparmor-utils
<mvo> jdstrand: could apparmor-utils have created profiles somehow? is there a command to auto-generate such profiles?
<jhodapp> mvo, also dh-apparmor got pulled in from that
<jdstrand> mvo: no, it wouldn't have done any magic like that
<jdstrand> it too
<jdstrand> did you run aa-genprof?
<zyga> tvoss: I don't see any starting/stopping messages in syslog/journal on 14.04
<jhodapp> jdstrand, nope
<zyga> tvoss: do you know how I can get that wired so that we have diagnostics?
<jdstrand> jhodapp: apt-cache policy apparmor-utils
<jhodapp> jdstrand, http://pastebin.ubuntu.com/23490677/
<pitti> zyga: indeed, seems the start/stop of mount units isn't logged by that backport; but you can see it in e. g. forkstat
<pitti> $ cat /etc/systemd/system/opt2.mount
<pitti> [Mount]
<pitti> What=/opt
<pitti> Where=/opt2
<pitti> Options=bind
<pitti> sudo systemctl start opt2.mount
<pitti> 15:14:16 exit  1130      0    0.009 /bin/mount /opt /opt2 -t auto -o bind
<zyga> forkstat
<pitti> gosh, this whole thing is *such* a bloody hack
<zyga> what is that?
<pitti> zyga: global monitoring of forks/execs that happen
<pitti> great to track down "why is my system going mad" or finding what certain actions (like hotkeys etc.) do
<zyga> pitti: wow :)
<zyga> thanks, that's a gem and a keeper
 * pitti hands cking a â¥ for this nice tool
<jhodapp> jdstrand, thoughts on that?
<pitti> zyga: of course the second-best debugging tool is always to just attach strace to systemd :)
<cking> thanks pitti :-)
<zyga> netlink
<zyga> the source of magic and wonder on linux
 * zyga has to learn more about netlink
<pitti> it's like magic
<zyga> pitti: any quick advice on how to embed forkstat into a test to see what is going on
<pitti> it's everywhere, but nobody really understands it
<zyga> pitti: I can install it early on but I don't know what to run to see activity in a window
<pitti> zyga: run forkstat first, then your test?
<pitti> but it really depends what you are actaully looking for
<zyga> pitti: can I run forkstat in the background or something like t
<zyga> and have it dump stuff to a log
<zyga> pitti: I want to see all mount / unmount calls first
<pitti> it shouldn't be that hard to see whether some mount worked or failed, as at any point in time you can see /proc/self/mounts in your namespace
<zyga> pitti: my problem is that something stops a .mount unit
<jdstrand> jhodapp (cc mvo and zyga): I just installed apparmor-utils (and dh-apparmor, which wasn't pulled in with apparmor-utils) and it did not create /etc/apparmor.d/usr.bin.snap
<zyga> pitti: and I'm not sure what, I want to corelate that to other logs
<mvo> forkstat goes crazy when you run go ;)
<zyga> jdstrand: I bet it 's the maid, all reasonable explanations are now exhausted
<mvo> but its a wonderful tool
<zyga> doh :/
<pitti> zyga: so to answer "what is calling umount", forkstat is actaully an excellent tool, as that tells you
 * mvo hugs cking
<jdstrand> jhodapp (cc mvo and zyga): if I run 'sudo aa-genprof /usr/bin/snap' and immediately press 'f' (finish), it generates a file exactly like the one on your system, with 600 perms
<cking> :-)
<jhodapp> jdstrand, mvo, zyga: here's my entire history.log for that day: http://pastebin.ubuntu.com/23490708/
<pitti> zyga: I thought your woes were related to trusty still having an /etc/mtab?
<pitti> zyga: systemd uses libmount's monitor, and I think in trusty that still parses /etc/mtab
<pitti> (which of course is utterly and hopelessly broken for anything that snappy or systemd want to do)
<jhodapp> jdstrand, oh I was running aa-genprof!
<zyga> pitti: not sure what the woes are, I symlnked mtab to proc mounts but I'm still seeing something unexpected (not happening on 16.04)
<jdstrand> bingo
<jhodapp> jdstrand, I was trying to create a profile for media-hub
<zyga> jdstrand: nice!
<jdstrand> jhodapp: please do: sudo apparmor_parser -R /etc/apparmor.d/usr.bin.snap ; sudo rm -f /etc/apparmor.d/sur.bin.snap /etc/apparmor.d/cache/usr.bin.snap
<jdstrand> jhodapp: that will set you straight
<mvo> jhodapp: excellent! I'm happy we found the root cause and even more happy that its not a general problem. thank you
<jhodapp> jdstrand, better! :)
<jhodapp> jdstrand, mvo, zyga thank you much!
<jdstrand> jhodapp: you probably noticed the typo in my rm -f command
<jhodapp> jdstrand, so...we might want to caution people from using that tool when trying to do a interface
<jhodapp> jdstrand, yes
<jdstrand> jhodapp: well... a) we don't say to use it and b) you used it on the wrong command
<jhodapp> jdstrand, what do you mean on the wrong command?
<jdstrand> sudo aa-genprog /usr/bin/snap
<jdstrand> meh
<jhodapp> jdstrand, I was following some examples from the apparmor wiki
<jdstrand> sudo aa-genprof /usr/bin/snap
<jdstrand> yes, but you told genprof to profile 'snap', not media-hub
<jhodapp> jdstrand, hmm I don't see why I would have run that...must have been a fluke
<jdstrand> that's what I'm getting at
<jhodapp> jdstrand, would it install it into that spot under /etc/apparmor.d/ though?
<jdstrand> yes
<pitti> zyga: ah, that should help then
<jhodapp> that's weird...why wouldn't it just generate a profile and put it in '.' ?
<jdstrand> genprof is an apparmor tool, not a snappy one so it knows about /etc/apparmor.d, not /var/lib/snapd/apparmor/profiles
<jdstrand> jhodapp: because of how it works-- it creates a profile and loads it into the kernel so then you can use other tools on it, like logprof
<jdstrand> granted, the tooling isn't as nice as it could be-- but it is like a decade old
<jhodapp> jdstrand, yeah...I discovered that tool doesn't even work well with snappy
<jhodapp> err, snaps
<jdstrand> no, it wouldn't
<jdstrand> (it wasn't written or updated for snappy)
<jhodapp> apparmor tools need some doc love
<jdstrand> jhodapp: you mean for snappy?
<jhodapp> jdstrand, yeah
<jhodapp> centered around creating an interface from scratch
<jhodapp> geared towards someone not experienced with apparmor
<jdstrand> so that would be snappy documentation, not apparmor documentation
<jdstrand> but yes
<jhodapp> right :)
<jhodapp> I'm just saying in geneneral
<jhodapp> *general
<zyga> pitti: after snapd I want to work on kernel and plumbing :)
 * jdstrand nods
<zyga> pitti: forkstat is awesome
<jdstrand> normal snap developers shouldn't be fiddling with the guts of the sandboxing mechanism (apparmor, seccomp, etc). interface writers will need that of course
<jhodapp> jdstrand, yes indeed, but even though it's slightly more niche, there are a number of people who will write interfaces who have little to no apparmor experience
<jhodapp> like myself...and it's a frustrating experience
<jhodapp> jdstrand, so I definitely get where you're coming from, just stating my experience
<jdstrand> jhodapp: in the meantime, if you have questions, just ask. also, the interface writer can go very general and then we fine tune in the PR review
<jhodapp> jdstrand, we had talked about this before as well
<jhodapp> jdstrand, that's a very good point!
<jhodapp> jdstrand, appreciate your thorough reviews
<jdstrand> I can add something to https://github.com/snapcore/snapd/wiki/Security in the debugging section
<jdstrand> that will point in the right direction
<jhodapp> jdstrand, that'd be fantastic!
<tedg> jdstrand: So the store blocks uploads with interfaces that it doesn't know about.
<tedg> jdstrand: Would it be possible to disable that check for snaps that are in devmode?
<zyga> tedg: http://paste.ubuntu.com/23490892/
<zyga> tvoss: ^
<zyga> or http://paste.ubuntu.com/23490903/
<zyga> for the full log
<zyga> tvoss: interesting observation, umount is only called twice
<zyga> tvoss: and not on any of the snaps :/
<zyga> tvoss: only on /snap itself (mount -l) aka detach
<tvoss> zyga yup
<zyga> tvoss: this might explain what we're seeing
<zyga> tvoss: _might_
<zyga> not sure it does
<zyga> tvoss: ah, I now see both the snapd-mount.service and snap.mount
<tvoss> zyga: okay, so I did the following experiment: in a debug shell for upgrade/basic, purge snapd, install the local deb with dpkg -i, then snap install hello-world, verify that snap works, dpkg -i local deb again
<tvoss> zyga: for that experiment, if I remove systemctl stop/disable snapd.mount from snapd.prerm, the snap remains mounted
 * zyga wonders what mandb is doing
<tvoss> zyga: however, the rbind/rshared setup is altered, let me pastebin error msg
<didrocks> kgunn: hey! I have a small question on https://developer.ubuntu.com/en/snappy/guides/mir-snaps/. Do we have any Mir snap example that we could use to showcase Mir on the rpi2?
<tvoss> zyga: http://pastebin.ubuntu.com/23490920/
<zyga> tvoss: that looks like the core snap is empty
<zyga> tvoss: look at /snap/core/current, there's no /dev there, right?
<tvoss> zyga: nope
<zyga> tvoss: so that's snap-confine giving up, earlier it was snap-run
<zyga> tvoss: I think the difference is that snap-confine sees the real NS and sets a new NS
<zyga> tvoss: while snap-run (either run (before) or exec (after) ) sees the vanilla / confined namespace respectively
<zyga> tvoss: and because we only set up ns once, after that we just join it
<zyga> tvoss: you may see different error
<zyga> tvoss: thsi error says the core snap is not mounted in the outer namespace for sure
<tvoss> okay
<didrocks> jdstrand: zyga: do we have any known workaround for snaps using alsa in core 16?
<didrocks> As I'm getting:
<didrocks> ALSA lib conf.c:3750:(snd_config_update_r) Cannot access file /usr/share/alsa/alsa.conf
<didrocks> ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default
<didrocks> people used to patch it directly on the image in 15.04, but I'm unsure how we can tackle this in 16
<didrocks> this leads of course to:
<zyga> didrocks: patch alsa to be snap-aware?
<didrocks> Can't open pcm device 'default'.
<didrocks> Couldn't open ALSA pcm device (`s')
<didrocks> zyga: not an option, deadline is next week
<matteo> niemeyer: refactored
<zyga> didrocks: I don't know of any other workaround
<zyga> didrocks: maybe bind mount /usr/share/alsa to something in your snap as a test
<zyga> didrocks: but that's not sustainable
<tvoss> zyga: I fail to see where snap-specific mount units get unmounted in the upgrade case
<zyga> tvoss: it gets detached
<zyga> tvoss: with all of /snap
<didrocks> zyga: yeah, I was thinking about doing something like that, but it means I need to have a wrapper to do this bindmount in devmode thus
<zyga> tvoss: a bit unfortunate :/
<tvoss> zyga: I removed that #
<zyga> tvoss: what did you remove? in the tree I pushed I use a mount unit and that's done internally now
<mup> PR snapcraft#913 closed: help: update stage-packages and build-packages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/913>
<tvoss> zyga: prerm does not need to stop/disable snapd.mount
<zyga> (apparently)
<zyga> ah
<zyga> hmm hmm hmm
<didrocks> (hoping I can bindmount in devmode)
<zyga> do we ever stop snap.mount (not snapd.mount)
<zyga> didrocks: you might
<zyga> didrocks: I don't know if anything else happens if you do that though
<zyga> didrocks: or if you can even do that
<zyga> didrocks: is /usr/share/alsa in the core snap? if not then sorry :/
<tvoss> \o/
<zyga> tvoss: do I owe you a beer?
<tvoss> hang on, let me rerun this again
<zyga> tvoss: are you in sync with master/
<jdstrand> didrocks: the alsa interface was just committed
<zyga> jdstrand: alsa looks at /usr/share/alsa, is that handled by the interface?
<jdstrand> didrocks: oh, you need to see my comment in the bug
<jdstrand> there is a way to do it
<didrocks> jdstrand: oh nice! even on a core image. I guess it might be tight for next release though
<jdstrand> zyga, didrocks: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/5
<mup> Bug #1598309: The aplay command doesn't work <snapd-interface> <xenial> <snapd (Ubuntu):Fix Committed by jdstrand> <https://launchpad.net/bugs/1598309>
<zyga> ALSA_CONFIG_PATH
<jdstrand> zyga, didrocks: alsa could use a snapcraft part
<tvoss> zyga, yup
<zyga> we're in environment hell :/
<zyga> tvoss: ok, then I'm opening popcorn :)
<jdstrand> zyga: note that I have a snap that works
<jdstrand> zyga: see the above comment
<didrocks> jdstrand: oh nice! I guess that will unblock it
<didrocks> jdstrand: I need to look if there is alsa though on the ubuntu core rpi2 image first
<jdstrand> didrocks: between the interface and the technique I sketched out, yes, it can be unblocked without patching alsa or doing weird mount tricks
<didrocks> jdstrand: well, without the interface, devmode for next week will be enough
<didrocks> just need to ensure now that the core image has it
<jdstrand> didrocks: but the technique is somewhat error prone. a snapcraft part would be the way to go
<jdstrand> didrocks: right, devmode next week almost certainly. 2.17.1 isn't even in xenial yet and this would be 2.18
<didrocks> jdstrand: yeah, I guess though as a first rough approach, that would work
<didrocks> yeah
<didrocks> ah, no alsa on core
<nuclearbob> ogra_: when you have a minute, can you  help me with info on connecting a serial console on the dragonboard?
<zyga> nuclearbob: do you have the small daugther board?
<nuclearbob> zyga: I don't. I can get that if I need to
<zyga> nuclearbob: no, it's just easier this way
<zyga> nuclearbob: all 96 boards have the serial pins in the same spot
<nuclearbob> zyga: I'm hoping it's somewhere in the j8 connector, since that'd be easiest :)
<nuclearbob> I guess that's the low speed expansion
<zyga> nuclearbob: if you need this urgently I can probe the board I have working locally
<zyga> nuclearbob: I have the header but it's not populated now, usually I was using the daughter board that does everything
<zyga> nuclearbob: (incl board reset)
<nuclearbob> zyga: I wouldn't call it urgent, so don't worry about messing with yours. There's someone on my team that I'm pretty sure can help, she just won't be on for a few hours yet
<zyga> nuclearbob: feel free to ping me if you change your mind
 * zyga was hoping for some scope and serial action ;)
<nuclearbob> zyga: awesome, thanks. If you want to check out which pins I need to use, I can complain about how the hdmi isn't giving me anything, and this dragonboard is useless until I get something working, oh the wasted time, save us all
<tvoss> zyga: no logic analyzer fun for you today ;)
<didrocks> hum, even on classic server image, no alsa
<zyga> tvoss: there's always that scope bed-time real-life story with kids ;)
<zyga> tvoss: so what was the magic ingredient you found
<tvoss> zyga: oh yeah, once upon time, when your dad grabbed the scope and went out to fight all the low-level transport bugs ;)
<zyga> tvoss: tell me!
<zyga> tvoss: now hold the probe ... here
<tvoss> zyga: no spoilers until I can pastebin
<zyga> ;D
<zyga> ok
<zyga> tvoss: I'll switch to snap-confine for a sec then
<didrocks> jdstrand: hum, I'm unsure how to we could use that as a part btw, as the alsa config will defer depending on hw, wouldn't it?
<didrocks> jdstrand: like, if I'm using your snap, I have a device busy error message, because it doesn't use the proper id I guess
<didrocks> (I can play the same file with using aplay directly)
<didrocks> (listing the cards sound correct though)
<qengho> jdstrand: for store automated review, """declaration malformed (wrong type 'true' for attribute 'allow-sandbox') declaration-snap-v2_valid_plugs (browser-support, allow-connection_plug-attributes)""". Is it something other than boolean, or deprecated, or something?
<didrocks> kgunn: hey, unsure you saw my previous ping about MIR/rpi2?
<jdstrand> jhodapp: https://github.com/snapcore/snapd/wiki/Security#interface-development-and-security-policy
<mterry> What is the word on policykit support?  u8 snap wants to use it to talk to SnapdLoginService
<boriseto-work> Hello, how can I execute a snap from terminal (lets say VLC for example)? Can I bind it with other apps for opening directly a file or link? I have both the ppa version and the snap version.
<OerHeks> i'd like to know the answer too, boriseto-work :-)
<zyga> boriseto-work: just run the command name, look at /snap/bin
<boriseto-work> zyga: oh so it's that simple. So for binding it from another app (let's say I want to open a video from there), instead of "vlc" I should use "/snap/bin/vlc"
<jdstrand> qengho: sorry I missed your question. it might be a bug. what is the package?
<tvoss> zyga, mild optimism: upgrade/basic is green
<qengho> jdstrand: one of the browsers. I put it in the review queue because it's so hard to link.
<tvoss> zyga: kicked the full test suite again
<kgunn> didrocks: i might've fell of the internet....what was the ques again?
<zyga> boriseto-work: not sure what you mean by binding, I'll be back laster
<zyga> later*
<jdstrand> qengho: I don't see it in the review queue. is it the one I helped you with before?
<zyga> tvoss: tell me what was broken if you can, I'll gladly check it out in the evening
<boriseto-work> zyga: it's okay, made it work as I wanted now. Was trying to tell other apps that use the video player to use the snap vlc instead of the ppa one. Didn't even think of checking the /snap/bin folder. Thank you very much.
<tvoss> zyga: simple thing: prerm must not stop snapd.mount (specifically not with snaps installed)
<tvoss> zyga: a fixed up version is in the ppa
<didrocks> kgunn: the question was regarding https://developer.ubuntu.com/en/snappy/guides/mir-snaps/. Do we have any Mir snap example that we could use to showcase Mir on the rpi2? (on core)
<qengho> jdstrand: yes. ah! It took two presses of request-review button. First saves destination but doesn't submit. Weird.
<jdstrand> ok, I found it on my own
<kgunn> didrocks: sorry, answered on the mail.... and short answer, need a new kernel snap with relevant gfx kernel patches integrated
<tvoss> zyga: I'm grabbing dinner, back after that
<jdstrand> qengho: there is a bug in the review tools. it is easily worked around by adjusting the snap declaration. I've done that. I reran the checks and it passed. you may push the publish button whenever you are ready
<qengho> jdstrand: thank you!
<jdstrand> np
<qengho> jdstrand: Does my snapcraft.yaml need updating?
<jdstrand> qengho: no. it was a problem in the snap declaration parsing
<jdstrand> qengho: 'declaration malformed'. you don't have anything to do with declarations so you are all good
<mup> Bug #1642669 opened: Can't connect to SnapdLoginService from a snap <Snappy:New> <https://launchpad.net/bugs/1642669>
<didrocks> jdstrand: hum, I don't find what could be wrong in the way I built your alsa snap, install in devmodeâ¦
<jdstrand> niemeyer: hi!
<niemeyer> jdstrand: Heya
<jdstrand> niemeyer: I'm off W-F of next week. I was wondering if we could chat soonish to talk about dbus-app, ideally so that I could implement it for merging before my holiday
<niemeyer> jdstrand: Sure.. how about right now?
<jdstrand> niemeyer: this comment I think is the starting off point: https://github.com/snapcore/snapd/pull/1613#issuecomment-254050047
<mup> PR snapd#1613: interfaces/builtin: add dbus-app interface <Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<jdstrand> niemeyer: that would be great :)
<jdstrand> note my last comment for store uploads: https://github.com/snapcore/snapd/pull/1613#issuecomment-261056164
<mup> PR snapd#1613: interfaces/builtin: add dbus-app interface <Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<niemeyer> jdstrand: Ok, so this interface is supposed to encapsulate the decisions we make inside apparmor for read/write access to particular services
<jdstrand> niemeyer: the simplest form it could take is allowing the bind to a well-known name. however, this PR goes beyond that and allows connects to that well known name, which now that kde has weighed in, they want
<jdstrand> niemeyer: ie, they are binding for a reason, to interact. this allows them to do so
<niemeyer> jdstrand: Right, and which I think was the best path as we discussed earlier
<jdstrand> ok, good
<jdstrand> I do too
<jdstrand> off to a good start! :)
<niemeyer> jdstrand: My main concern now is whether this language is enough and proper to address the problem
<niemeyer> jdstrand: There are two unrelated issues I can see in the language used there.. the first related to that "api" parameter
<jdstrand> niemeyer: the apparmor policy would essentially be 'the slot with this label can talk to the plug with that label over dbus'
<jdstrand> is, slot side gets 'dbus peer=(label=plugside),'
<niemeyer> jdstrand: Where "label" is "api"?
<jdstrand> and the plug gets 'dbus peer=(label-slotside),'
<jdstrand> (we'd add the com.example. stuff too of course
<jdstrand> )
<jdstrand> niemeyer: no, those are apparmor rules so label means the security label. ie snap.foo.bar
<niemeyer> jdstrand: Okay, that's cool
<jdstrand> I would want to add interface=org.gnome.Rhythmbox{.*} as well to those rules
<jdstrand> and whether it is 'session' or 'system' of course
<niemeyer> jdstrand: That sounds misnamed
<jdstrand> niemeyer: as for 'api', yes, that I just tossed that out there for discussion
<jdstrand> niemeyer: before we name it, do we want something like that at all?
<jdstrand> niemeyer: there is precedence for something like that-- 'content' in the content interface
<jdstrand> but with content, it makes sense to have a tighter coupling
<jdstrand> I'm less sure here (I'm on the fence)
<niemeyer> jdstrand: Maybe.. we need a way to tell that we're connecting the proper plug to the proper slot
<jdstrand> that's true
<niemeyer> jdstrand: This may be done either explicitly, as in content, or it may be done implicitly based on existing metadata
<niemeyer> jdstrand: dbus already has such a concept internally
<jdstrand> with this for plugs:
<jdstrand> plugs:
<jdstrand>   rhythmbox:
<jdstrand>     interface: dbus-app
<jdstrand> if rhythmbox had two dbus-app slots, I don't think there is enough implicitly
<jdstrand> now, the plugs side doesn't have to be that simple
<jdstrand> (but that is how it is in my comment)
<jdstrand> so that is getting me to like this explicit name
<jdstrand> were you thinking of something else for implicit?
<niemeyer> jdstrand: Yes, dbus itself has resolution logic
<niemeyer> jdstrand: It has exactly the same problem internally, right?
<niemeyer> jdstrand: The client needs to talk to the server and they both need to know what they're talking about
<jdstrand> yes
<niemeyer> jdstrand: As there are many objects and many interfaces under the same endpoint
<jdstrand> niemeyer: so thinking maybe plugs side also has session and system?
<niemeyer> jdstrand: Adding a high-level label means we can match them both by just comparing that label, but that also means we're reinventing the same mechanism, and creating the potential for mismatching
<jdstrand> niemeyer: and we just use the intersection?
<niemeyer> jdstrand: E.g. if you and me create two different snaps with different "api" fields and a different selection of interfaces, our snaps cannot interact, although the thing we're abstracting away could in fact talk to each other
<jdstrand> niemeyer: it does seem natural for someone that wants to talk over dbus to declare what they want to talk to, yes
<jdstrand> niemeyer: yes, that makes sense
<jdstrand> niemeyer: are you then advocating for having session and system on both slots and plugs, or something else?
<niemeyer> jdstrand: There's also a related issue: we're not allowing the interfaces to specify a "path"
<jdstrand> path is tricky
<niemeyer> Why?
<jdstrand> because people don't always use it consistently
<jdstrand> I've seen a lot of applications just pick '/' as the path
<jdstrand> my goal is to not reinvent the apparmor language or dbus semantics in this area. maybe we have to, but ideally not
<niemeyer> jdstrand: Ok, but that means the client needs to use that path too if it expects to interact, right?
<niemeyer> jdstrand: Well, exactly.. I'm wondering if we can map it more closely instead of reinventing
<jdstrand> niemeyer: I was thinking simply omit the path and rely on interface, bus name and security label
<niemeyer> jdstrand: The code currently is doing "obj.path" => "obj/path", which is not what dbus does.. that's reinventing it
<niemeyer> jdstrand: It's not omitting the path.. it's guessing it
<jdstrand> eg: dbus bus=session interface=org.gnome.Rhythmbox{,.*} peer=(label=<the other side>)
<jdstrand> we just allow any path and member
<niemeyer> jdstrand: Can the client tell what the remote path is?
<jdstrand> which I think is fine. we want to allow the connection and not worry about carving out the apis
<niemeyer> jdstrand: To some degree, yes
<jdstrand> niemeyer: the client necessarily has to know it, yes, so it is possible to declare it. but I'm not sure how worthwhile that is since we are really just wanting to say "let these guys talk over this dbus interface"
<niemeyer> jdstrand: Can the client tell what the remote path is?
<niemeyer> jdstrand: Ok.. so just to be clear, that's not what is being done ATM, right?
<jdstrand> so, the client either has to know or there is dbus introspection
<jdstrand> niemeyer: re done ATM> the code in the PR does not reflect any discussiosn after the initial submission as dbus-app, if that is your question
<niemeyer> jdstrand: Ack
<niemeyer> jdstrand: So.. brainstorming idea:
<jdstrand> so, hoping to get the yaml nailed done and what that represents, then I can run with it
<jdstrand> s/done/down/
<niemeyer> jdstrand: What if we stripped out the snap "dbus" (not dbus-app) interface to *one* interface
<jdstrand> I'm not following
<niemeyer> slots:
<niemeyer>     my-dbus-interface:
<niemeyer>         interface: dbus
<niemeyer>         name: org.my.dbus.Interface
<niemeyer>         bus: session
<niemeyer> jdstrand: Consider the consequences..
<jdstrand> in terms of the problem this is trying to solve, that would work. you need one slot per org.my.dbus.Interface. the plugs side would also need 'name' and 'bus'
<mup> Bug #1642669 changed: Can't connect to SnapdLoginService from a snap <snapd-glib:Confirmed> <https://launchpad.net/bugs/1642669>
<jdstrand> then we have a clean way of connecting
<jdstrand> a thick snap could offer 10 things, and a plug could use just one of them
<jdstrand> (if it wanted)
<jdstrand> or 5 or all 10
<niemeyer> jdstrand: Right, exactly
<niemeyer> jdstrand: It also means we can have more fine-grained decisions about what is okay to auto-connect or not
<jdstrand> this could also be used to ease slot development in general for cases where we want to offer the entire api for a particular interface
<niemeyer> jdstrand: and we don't need "api", as dbus already tells us that via these fields
<jdstrand> eg, network-manager could move to this if desired since we know that its api can't effectively be carved (that is a more farther out thing)
<jdstrand> niemeyer: re not needing api> yes
<jdstrand> niemeyer: I like it
<niemeyer> jdstrand: The problem is finer grained access is a bit unclear to me.. we might add read and write fields with lists of methods in the future, I guess, and make auto-connection conditional on their content.. I suppose.
<niemeyer> jdstrand: Ah.. interestingly, these fields might be on the plug side only
<niemeyer> jdstrand: The slot of course doesn't care
<niemeyer> jdstrand: In the sense it offers it all
<jdstrand> niemeyer: possible, yes (for all of this). I suspect if we are carving out bits like that we can continue to do a dedicated interface
<jdstrand> but, it is possible to move everything out to this once we learn more how people want to use it
<niemeyer> jdstrand: Well, yes, but we can't be too confident we know where this will go ahead of time.. sometimes design takes its own direction when people love a feature
<niemeyer> jdstrand: I can imagine people wanting to simply keep using this for dbus, instead of having to create custom interfaces
<jdstrand> I just mean that if we have so much knowledge about a dbus api, eg, for location-service, we just offer an interface call location-observe and location-control, etc rather than making location-service use the dbus interface. that is still a viable approach while we learn how people use the dbus interface with just 'bus' and 'interface'
<jdstrand> niemeyer: re imagine> yes, me too. I think it would be helpful
<niemeyer> Yeah, sound good
<niemeyer> jdstrand: Okay, I think we have a plan
<jdstrand> ok, I'll summarize it and get this going
<jdstrand> (summarize in the PR)
<jdstrand> niemeyer: thanks!
<niemeyer> jdstrand: np, and thanks as well
<SciVision> I started Ubuntu Core on a Raspi 3 . Could run the setzp. Now I am prompted for localhost login. tried Ubuntu so key from another machine, tried 'ubuntu, but nothing worked. How can I login?
<SciVision> Sorry typos: I tried to login from another machine in the network with ssh and Ubuntu name@ip address. Did not work. How can I login?
<zyga> SciVision: you can login only over ssh, ther'es no password, you must use the ssh keys that are published in your sso (launchpad or ubuntu one) account
<SciVision> ok
<SciVision> the keys not user name
<SciVision> zyga: Sorry on https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ it says "ssh <Ubuntu SSO user name>@<device IP address>"
<SciVision> and I get Permission denied when I use my Ubuntu one account login id
<SciVision> zyga: Got it. Thanks
<jdstrand> niemeyer: fyi, https://github.com/snapcore/snapd/pull/1613#issuecomment-261350004. I'm running with it. please let me know if I got something wrong
<mup> PR snapd#1613: interfaces/builtin: add dbus-app interface <Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<Damian> hi everyone. I am trying to get core running on a raspberry pi 3, loaded the image on the card and booted up, configured the wifi if and it connected and got an ip address, then I get "Network configuration timed out; please verify your settings" error
<Damian> any ideas on how to get past this?
<ahoneybun> thanks for that update jdstrand
<jdstrand> ahoneybun: you're welcome
<ahoneybun> jdstrand: I know Pithos will hit that issue later once I found out how to tell it to look in a space for a file
<ahoneybun> *place
 * jdstrand nods
<cwayne> hey guys, is there a way to allow a snap to auto-connect to an interface (in this case, log-observe)?
<ahoneybun> can I use filesets to fix this issue? : http://pastebin.ubuntu.com/23477531/
<ahoneybun> GLib.Error: g-file-error-quark: Failed to open file '/share/pithos/pithos.gresource': open() failed: No such file or directory (4)
<ahoneybun> the .gresource is in /share/pithos
<ahoneybun> so I need something like $SNAP I guess
<linuxhiker> I am trying to improve the postgresql snap packages and have run into an issue.  On compilation we can call world which will make the contents of the contrib directory. However, I can't figure out how to get the finalized contents of the contrib directory to be properly installed into the snap packages (postgresql proper, without contrib works)
<mup> PR snapcraft#905 closed: Snap revision prune <Created by seawaywen> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/905>
<mup> PR snapcraft#914 closed: meta: icon is now dedeprecated <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/914>
<mup> PR snapcraft#915 opened: cache: cleanup logic to pass project name <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/915>
#snappy 2016-11-18
<mup> PR snapcraft#915 closed: cache: cleanup logic to pass project name <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/915>
<mup> PR snapcraft#916 opened: sources: missing command instead of package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/916>
<mup> PR snapcraft#917 opened: wip <Created by elopio> <https://github.com/snapcore/snapcraft/pull/917>
<mup> PR snapcraft#918 opened: create the deltas package/class with xdetal generation implementation <Created by seawaywen> <https://github.com/snapcore/snapcraft/pull/918>
<foxmask> bonjello
<tvoss> zyga: o/
<oSoMoN> Mirv, when running the webbrowser-app snap that depends on ubuntu-app-platform, Iâm seeing the following message at app shutdown: "libgcc_s.so.1 must be installed for pthread_cancel to work"
<oSoMoN> Mirv, and indeed, usr/lib/x86_64-linux-gnu/libgcc_s.so.1 is not included in the ubuntu-app-platform snap, do you know why? It should be, given that itâs a direct dependency of liboxideqt-qmlplugin
<Mirv> oSoMoN: the whole usr/lib is being exported, but it's not there. I guess you mean /lib/ ...
<Mirv> oSoMoN: it should be part of Ubuntu Core
<Mirv> oSoMoN: at least it looks to be for me
<Mirv> oSoMoN: so on my platform using snap there is /lib/x86_64-linux-gnu/libgcc_s.so.1
<oSoMoN> Mirv, indeed itâs part of ubuntu-core, but it looks like the app is not seeing it for some reason
<oSoMoN> Mirv, Iâve reverted to the version of the webbrowser-app snap that ships all its dependencies (including oxide), and Iâm not getting the error message about libgcc_s.so.1
<Mirv> oSoMoN: I don't know how it'd be even possible to remove the Core's /lib path from the library search path. looking at the desktop-launch launcher, that also just adds new directories http://pastebin.ubuntu.com/23494754/
<Mirv> oSoMoN: I assume your dep including snap has the $SNAP/lib/arch/libgcc_s.so.1 however?
<Mirv> oSoMoN: I could export the /lib too from platform snap and add it to LD_LIBRARY_PATH, but I was under impression that would make no sense
<oSoMoN> Mirv, I donât think this should be necessary, it looks to me more like a bug in snappy itself, Iâm filing a bug so we can track/investigate it
<oSoMoN> Mirv, https://bugs.launchpad.net/snappy/+bug/1642900
<mup> Bug #1642900: libgcc_s.so.1 not found by app using ubuntu-app-platform content snap <Snappy:New> <https://launchpad.net/bugs/1642900>
<mup> Bug #1642900 opened: libgcc_s.so.1 not found by app using ubuntu-app-platform content snap <Snappy:New> <https://launchpad.net/bugs/1642900>
<binchen> hi, i have one question.. how a snap actually call the interface in another snap? I assume there should be some sort of IPC, right?
<tvoss> binchen: it depends on the interface, some interfaces sit on top of IPC mechanisms (say DBus), others sit on top of the filesystem
<binchen> tvoss: and they are transparent to the user?
<tvoss> binchen think about an interface as a means to describe an interaction (arbitrary on purpose) and the permissions that are required to carry out the interaction
<tvoss> binchen: transparent as in?
<binchen> I mean the user don't aware of or care about what the actually ipc is
<binchen> and the producer thus are free the change the way the method is called..
<binchen> I come from a Android backgroud, and kind of trying to do a analogy here
<binchen> in Android, a component can expose a service/interface through binder
<binchen> and will always through binder..
<binchen> I'm not sure if it is correct to equivalent a snap interface to the Binder interface though
<binchen> http://docs.ubuntu.com/core/en/reference/interfaces
<tvoss> binchen: not really, binder would be just another transport
<tvoss> binchen: and yes, to a user, the underlying implementation is transparent
<binchen> tvoss: pierrchen@localhost:~$ snap interfaces camera
<binchen> Slot  Plug
<binchen> is this expected? I'm using a kvm , and was trying to see what are included for the camera interface
<binchen> I'm expecting see some kind of APIS.
<binchen> but may be that expectation is wrong ..
<tvoss> binchen: it's not apis, more like functional blocks
<tvoss> binchen: an example would be location-observe
<binchen> hmm...
<binchen> so there is no need to know what are the APIs provided by a snap
<binchen> or we just treat them as a whole function??
<tvoss> binchen: well, as a package if you want so (to draw an equivalent to Android's java runtime)
<tvoss> binchen: so in the snap world, interfaces help to wire functional requirements together
<binchen> basically, I'm trying to see how snaps are talk to each others
<tvoss> binchen: there is no canonical answer, depends on the functional block
<binchen> especially, talk to the core snaps - iiuc, core snaps provided the core functionalitys such as camera, bluetooth,
<tvoss> binchen: trying to rephrase: there is not the IPC as in Android, but apps and services are free to use to cover their requirements
<binchen> OK, what about the core snapps
<tvoss> binchen: nope, the core snap is really lightweight, camera, bluetooth and friends all come in via additional snaps
<binchen> how a core snaps provided services to other "user snaps"?
<binchen> OK
<tvoss> for the core snap specifically, that happens on a filesystem level. the core snap mostly exports libc (I'm oversimplifying here, but I think you get the message)
<binchen> is it possible we have two camera snaps, all declare provide camera functionality?
<tvoss> binchen: sure
<binchen> hm....won't there be problem, say both two camera snaps trying to use the /dev/vidoe nodes?
<binchen> and they aren't aware of each other?
<tvoss> ah, now we get to an interesting point. sure, but that's where interfaces come in handy, too
<binchen> I may still didn't get the exactly meaning of interface here. I thought it is just a interface as it normal mean in java, for example
<tvoss> nope, it is not an interface in the software engineering sense
<binchen> yeah, I guess that is my biggest confusion so far :)
<binchen> as  a software person :)
<binchen> it is hard to get my head around that..
<tvoss> okay, so let me follow up on your camera example: simultaneous access to /dev/video* whatever is not possible, so you would need an intermediate service, right
<tvoss> binchen: no worries :)
<binchen> "Interfaces allow snaps to communicate or share resources according to the protocol established by the interface. Each connection has two ends, a "plug" (consumer) and a "slot" (provider). A plug and a slot can be connected if they use the same interface name. The connection grants necessary permissions for snaps to operate according to the protocol."
<binchen> from here http://docs.ubuntu.com/core/en/guides/build-device/interfaces
<tvoss> the intermediate service, e.g. camera-service snap, would use an interface camera-hw-access
<binchen> so what exactly happen after the plug?
<binchen> I can understand the concept of plug/slot
<tvoss> the interface camera-hw-access would contain code to make sure that camera-service can access /dev/video*
<tvoss> applications using the camera would then use camera-service, which in turn could provide a slot for camera-access (note the missing hw :))
<binchen> that make sense
<binchen> just to make sure I understand you correctly, camera-hw-access is a snap right?
<binchen> and it is not provided by canonical? could be anyone?
<tvoss> nope, camera-hw-access is an interface, that describes how security policy has to be setup to allow a snap with a camera-hw-access plug to access /dev/video*
<binchen> how about camera-service snap? who will provided it? Can we have two?
<tvoss> binchen, sure, you can have two camera-service snaps, they both would have a plug for camera-hw-access
<binchen> hha..
<binchen> so what exactly is the pierrchen@localhost:~$ snap interfaces
<binchen> Slot                    Plug
<binchen> :bluetooth-control      -
<binchen> :camera
<binchen> the camera interface here?
<binchen> is that the camera-hw or camera-service, or neither?
<tvoss> in that list, there is something providing a slot for interface camera
<tvoss> that's camera-hw
<tvoss> binchen: for reference: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/camera.go
<binchen> cool!!!
<binchen> I guess that is whant I want to check out
<tvoss> ack
<tvoss> so camera.go is obviously hw and super simple (just access to a bunch of device nodes)
<tvoss> a hypothetical camera-observe interface would be more sophisticated, capturing ipc specific requirements etc (in the example of camera service <-> apps)
<binchen> is the only operation we can do to interface is to connect and disconnect?
<binchen> and after connect it, you are able to access the resource (e.g the dev nodes in camrea interface)  in that package>
<tvoss> yup, exactly
<binchen> so, it's about security only
<binchen> I checked other buildin interfaces
<binchen> seems all AppArmor, SecComp related
<binchen> so, what is the way to implement normal functionality/API exposing?
<binchen> say one snap can do add(), substract()
<binchen> and aonther snap want to use that functionality?
<tvoss> binchen: so we typically use dbus for that, but the choice is ultimately up to you :)
<tvoss> binchen: say you had your own idl/ddl and framework, you could use a unix socket as a transport
<binchen> OK..
<binchen> I get it
<binchen> so the snap is more focus on the security side of things
<binchen> its not about the idl/binder/dbus stuff
<tvoss> binchen: the key thing really is: snappy does not have an opinion on the way communication is established, it just wants to know certain aspects about the connection (like security) to be able manage connections between plugs and slots for a given interface
<tvoss> binchen: precisely that
<binchen> I finally get that!
<tvoss> binchen: *ideally* existing software would run unmodified.
<binchen> yeah, otherwise, much bigger changes
<binchen> to the legacy code
<binchen> so snap is more a package innovation
<binchen> not how you write your software :)
<binchen> tvoss: really appreciate you taking your time answer my dumb questions!
<tvoss> binchen, happy to, and there is no such thing as a dumb question :)
<binchen> I'm heading for bed now. it is 10:30PM.  See you
<tvoss> binchen: see you :) have a good night
<binchen> have a good day!
<tvoss> thx
<mup> PR snapcraft#916 closed: sources: missing command instead of package <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/916>
<mup> PR snapcraft#912 closed: Add a gradle demo and test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/912>
<iliv> what are other variables similar to $(DESTDIR) that can be used in custom Makefile's? specifically, I'm wondering if there is a variable that points to parts/$PAR_NAME/build directory?
<didrocks> iliv: it's a good question, by convention, this is BUILDDIR in the debian world, but it doesn't seem that snapcraft has anything like this
<didrocks> iliv: maybe time to open a feature request, you can override this in a custom plugin (inherited) meanwhile
<iliv> didrocks, https://launchpad.net/snapcraft is this the project?
<didrocks> iliv: correct!
<iliv> diddledan, okay, I'll create a feature request. What are other variables besides $DESTDIR, though? And where can I look them up?
<sergiusens> davidcalle dholbach and/or didrocks mind looking at https://github.com/snapcore/snapcraft/pull/919
<mup> PR snapcraft#919: docs: update GUI related integrations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/919>
<didrocks> iliv: I just grepped in the snapcraft code directly, like the cmake plugin at snapcraft/plugins/cmake.py
<didrocks> sergiusens: davidcalle will have a look (finishing a meeting right now) I think, thanks for the ping!
<sergiusens> wait wait, are you a marketting manager now ? :)
 * sergiusens does his Friday trol-lol-lol :-)
<didrocks> rohlalala :)
<mup> PR snapcraft#919 opened: docs: update GUI related integrations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/919>
 * didrocks files more bugs on snapcraft as a revenge :)
<sergiusens> didrocks I can just do what other projects do ;-)
<sergiusens> wrt bugs
<davidcalle> sergiusens: thanks, will have a look in a moment :)
<sergiusens> davidcalle great, this will be fluctuating in the coming days as I implement declarative desktop files
<davidcalle> sergiusens: ð
<didrocks> sergiusens: tsssss, you wouldn't go that easy path, would you? :)
<sergiusens> didrocks nah
<Chipaca> tyhicks, jdstrand, is https://bugs.launchpad.net/snappy/+bug/1611078 actually fixed in xenial via #1628285 or is that separate?
<mup> Bug #1611078: Support snaps inside of lxd containers <landscape> <lxd> <nova-lxd> <verification-failed-xenial> <Snappy:Fix Released by stgraber> <apparmor (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu):Fix Released by jjohansen> <lxd (Ubuntu):Fix Released by stgraber> <apparmor (Ubuntu
<mup> Xenial):Confirmed> <linux (Ubuntu Xenial):Fix Released by jjohansen> <lxd (Ubuntu Xenial):Fix Committed> <apparmor (Ubuntu Yakkety):Fix Released by tyhicks> <linux (Ubuntu Yakkety):Fix Released by jjohansen> <lxd (Ubuntu Yakkety):Fix Released by stgraber> <https://launchpad.net/bugs/1611078>
<mup> Bug #1628285: apparmor should be allowed to start in containers <lxd> <verification-done> <apparmor (Ubuntu):Fix Released by tyhicks> <upstart (Ubuntu):Invalid> <apparmor (Ubuntu
<mup> Trusty):Incomplete by tyhicks> <upstart (Ubuntu Trusty):Incomplete by tyhicks> <apparmor (Ubuntu Xenial):Fix Released by tyhicks> <https://launchpad.net/bugs/1628285>
<Chipaca> stgraber, and is it fixed in lxd on xenial?
 * jdstrand defers to tyhicks 
<Son_Goku> sergiusens, any luck on the pluggable engines for (stage|build)-packages?
<jjohansen> mup: 1611078 is the bug the kernel portion was done under, I believe tyhicks is also doing the user space sru for under that as well
<mup> jjohansen: I apologize, but I'm pretty strict about only responding to known commands.
<jjohansen> however you will note that the apparmor userspace component is not currently marked fix released for xenial
<Chipaca> jjohansen, hence me asking
<jjohansen> even the full set of srus, apparmor, kernel, lxd, and fuse there are still some bugs to iron out for some snaps
<jjohansen> Chipaca: iirc there was still some verification to be done on the sru
<Chipaca> fgimenez was trying to see if https://bugs.launchpad.net/snappy/+bug/1630789 was done, but to verify that from a xenial host is not possible because of this
<mup> Bug #1630789: normal users can't run snaps inside of LXD containers <verification-needed> <Snappy Launcher:Fix Released by jdstrand> <Snappy:In Progress by tyhicks> <snap-confine (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu):Fix Released by tyhicks> <snap-confine (Ubuntu Xenial):Fix Committed>
<mup> <snap-confine (Ubuntu Yakkety):Fix Committed> <https://launchpad.net/bugs/1630789>
<Chipaca> that is, there's no way for this one to be fixed before that one is fixed :-)
<jjohansen> Chipaca: yeah, I would not call this fixed on xenal yep
<Chipaca> fgimenez, I think I deserve a cookie for saving you some work. Shame I didn't notice you were doing this before... :-)
<jjohansen> which does mean 160789 is not fixed either
<Chipaca> jjohansen, that's fine, it's hairy but we'll get it sorted eventually
<Chipaca> i don't mean to be rushing anybody, just that we know where we are
<jjohansen> Chipaca: we are close
<jjohansen> I'm not sure exactly what is left as tyhicks has been handling that while I try to squash bugs
<zyga> jjohansen: hey, nice to see you again :)
<jjohansen> hey zyga :)
<fgimenez> Chipaca, a very big cookie, yes :)
<didrocks> jdstrand: hey! so, I'm wondering why your alsa snap doesn't work for me as a snap and works for you (and seb). My only plausible explanation is that the system aplay is using the gstreamer backend and forward it to it, while the version you are shipping don't have that backend and sends directly to the cardâ¦ My card may not support multiple streams hence the "device is busy" message?
<didrocks> s/gstreamer/pulseaudio/
<jdstrand> didrocks: I don't know. I git cloned it, snapcrafted it, installed it and it worked
<didrocks> jdstrand: you didn't embeeded the pulseaudio configuration files on purpose though, right?
<didrocks> or that may be ubuntu patches?
<jdstrand> didrocks: I don't know how the locking on all of that works. no I didn't. did they end up there?
<jdstrand> didrocks: you saw the snapcraft.yaml, right? I literally stage-packages and ship a few alsa config files. that's it. no source code, nothing fancy
<didrocks> jdstrand: they are not in the snap while there is /usr/share/alsa/pulse-alsa.conf and /usr/share/alsa/alsa.conf.d/
<didrocks> yeah, the alsa config files are cloned from upstream?
<didrocks> (not from our ubuntu package)
<didrocks> I thought you copied files from /usr/share/alsa and so, omitted the pulse thingy on purpose
<jdstrand> didrocks: /usr/share/alsa/pulse-alsa.conf isn't going to be in the core snap though
<jdstrand> didrocks: no. I grabbed those files from the ubuntu packaging
<didrocks> I was thinking on the file that you copied in etc/
<didrocks> ah interesting
<didrocks> they are surely in the pulseaudio package
<jdstrand> didrocks: and modified them to work well enough here
<didrocks> hum libasound2-plugins:amd64: /usr/share/alsa/alsa.conf.d/50-pulseaudio.conf
<didrocks> yeah
<jdstrand> $ ls -lR /snap/alsa-utils/current/|grep pulse
<didrocks> jdstrand: I really wonder if this isn't card dependentâ¦ some accepting multiple streams, other not
<jdstrand> [1]
<jdstrand> there is nothing in the snap about pulse. I'm confused why you keep talking about pulseaudio files in /usr/share
<didrocks> sorry, I probably misexplained myself
<jdstrand> I mean, feel free to try to put the pulseaudio file in there-- maybe that works, but since this was about accessing the device directly I was keeping pulseaudio out of it
<didrocks> so, my system aplay works well, but not the one from the snap "device is busy" with exactly the same parameters
<jdstrand> I see. yeah, I don't know :)
<didrocks> the only difference I can think of is that the system aplay, in /usr/share/alsa/ has those pulseaudio config and so, forward it to pulseaudio
<jdstrand> like I said, I'm not claiming anything about that snap except that it worked here enough to develop security policy for the interface
<didrocks> contrary to the one in the snap, and maybe my card isn't capable of handling multiple stream
<didrocks> yeah
<didrocks> if I can get it work and forward in pulseaudio, we may need 2 parts
<didrocks> once with alsa-with-pulseaudio
<didrocks> and one with alsa-only
<jdstrand> ah, you are working on the part. ok, now things are making more sense to me :)
<didrocks> (one of the example is timidity, which only has alsa support)
<didrocks> yeah, but before working on the part, I need to get it working on my desktop :)
<jdstrand> I suspect that would make sense-- to try to emulate what we are doing on Ubuntu
<didrocks> that's why, out of this theory, I don't understand why it's working for you and not for me
<jdstrand> I just don't really have any experience with alsa
<didrocks> yeah, same :/
<jdstrand> didrocks: perhaps start by forking my branch and then adding those pulse files in usr/share/alsa (modifying as needed)
<didrocks> yeah
<didrocks> I need to add a lot of pulseaudio libs as well
<didrocks> for the module
<sergiusens> davidcalle so are we good with snapcraft#919
<mup> PR snapcraft#919: docs: update GUI related integrations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/919>
<sergiusens> ?
<didrocks> jdstrand: I will just cross fingers that my theory is the correct one :)
<jdstrand> didrocks: it wouldn't surprise me if it was. that is a big reason why things like pulseaudio exist-- limitations of hardware
<didrocks> yeah, let's cross fingers. I'll keep you posted
<tyhicks> Chipaca: Hi - the apparmor userspace fix of bug #1628285 has already landed - I've just updated the bug
<mup> Bug #1628285: apparmor should be allowed to start in containers <lxd> <verification-done> <apparmor (Ubuntu):Fix Released by tyhicks> <upstart (Ubuntu):Invalid> <apparmor (Ubuntu
<mup> Trusty):Incomplete by tyhicks> <upstart (Ubuntu Trusty):Incomplete by tyhicks> <apparmor (Ubuntu Xenial):Fix Released by tyhicks> <https://launchpad.net/bugs/1628285>
<tyhicks> Chipaca: last I checked, there was still a kernel change needed to allow fuse filesystems to be mounted inside of user namespaces
<tyhicks> Chipaca: you'll probably want to check with stgraber on that remaining issue because, AFAIK, he was handling the squashfuse stuff
<stgraber> I believe you still need to manually install squashfuse, that's not something I can do much about though, I've requested the snapd team to make it a dependency quite a while ago...
<stgraber> for my part, I made sure squashfuse is available in xenial, yakkety and zesty
<stgraber> that's https://bugs.launchpad.net/snappy/+bug/1628289 which is still marked as New against snappy...
<mup> Bug #1628289: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:New> <squashfuse (Ubuntu):Fix Released by stgraber> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289>
<davidcalle> sergiusens: yes, wfm
<mterry> So I filed bug 1642350 about snapcraft in Launchpad silently ignoring a stage-package.  Does anyone know why that would happen?
<mup> Bug #1642350: webbrowser-app silently being excluded from stage-packages <Snapcraft:New> <https://launchpad.net/bugs/1642350>
<stgraber> so quick question, related to https://github.com/snapcore/snapd/pull/2225, what happens if I add a "slots" entry which snapd doesn't know about yet?
<mup> PR snapd#2225: Implement lxd-client interface exposing the lxd snap (LP: #1634880) <Created by kalikiana> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2225>
<stgraber> I'd like to add "slots: [lxd]" to the lxd snap to make that ^ interface useful, but I don't want to suddenly break anyone who doesn't have a recent enough snapd
<didrocks> jdstrand: I think the only way to get something clean is to rebuild alsa-lib (but I don't know how to not hardcode /snap). There is no way to define a dynamic plugin directory (for the pulse one)
<didrocks> even adding to LD_LIBRARY_PATH, it's still looking at it in /usr/libâ¦
<jdstrand> didrocks: boo :)
<jdstrand> didrocks: at least that can be done in a part...
<didrocks> jdstrand: yeahâ¦ I have a very very big hammer workaround for the deadline at least
<zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/183
<mup> PR snap-confine#183: Detach the hostfs version of /sys <Created by zyga> <https://github.com/snapcore/snap-confine/pull/183>
<zyga> jdstrand: a trivial branch that may unbreak docker
<zyga> jdstrand: the diff is long because of test data changes (but in very expected ways)
<zyga> jdstrand: looking at this I'd like to do /dev and /proc as well, this would cut down on weird filesystems showing up twice
<zyga> jdstrand: once this lands I'll run a pass of snapd tests against snap-confine master
<zyga> jdstrand: and a related apparmor question, is there a confinement option for umount to say unount but only when MNT_DETACH was passed?
<zyga> lool: ^^ any opinions on /dev and /proc
<lool> zyga: I'd suggest doign the same on devpts, dev and proc
<lool> seems consistent since these aren't accessible anyway
<zyga> lool: all of /dev (includes devpts)
<zyga> lool: yeah, I'll follow up after I get a +1 from jdstrand
<zyga> (or tyhicks if he wants to look)
<lool> ok; I usually have to bind mount devpts separately in chroots, but I dont know about mount namespaces behavior there
<zyga> lool: we have that in /dev
<zyga> lool: this is the one from "outside" that nobody is supposed to use anyway
<zyga> lool: I think that it makes sense, we want access to host / classic files (e.g. fonts) but not to the duplicated fileystems like /proc which we bind mount anyway
<lool> can I get an unconfined shell in the right namespace with snap run?
<zyga> lool: easily with nsenter
<zyga> lool: not with snap-confine
<zyga> lool: just try nsenter -m/var/lib/snapd/ns/$SNAP_NAME.mnt
<zyga> lool: very useful!
<zyga> lool: you cannot have a space after -m, it's totally annoying
<zyga> er
<zyga> sorry
<stgraber> zyga: can you answer my earlier question? Is it safe to add "slots: [lxd]" to the lxd snap even if some/most snapd don't know what that interface is yet?
<zyga> lool: that path is /run/snapd/.ns/$SNAP_NAME.mnt
<zyga> stgraber: sorry I didn't see that earlier, the answer is 1) yes 2) it must not clash with any plug (plug and slot names must be unique in one snap) 3) the store will choke on that
<zyga> stgraber: snapd ignores unknown interfaces
<stgraber> zyga: sounds good
<lool> zyga: that's great, cause I could now confirm that this fixes docker
<lool> umount --lazy /var/lib/snapd/hostfs/sys
<zyga> lool: great to know, please add this to the pull request
<jdstrand> zyga: ack, I'll look. I don't see anything in man apparmor.d about detach
<zyga> lool: I plan to work on live namespace mutation soon after classic confinement, what you just did will be done by snapd on interface changes :)
<lool> zyga: and also that unmont dev along is enough
<jdstrand> zyga: jjohansen would know for sure (he'll be back later)
<zyga> lool: thanks
<jdstrand> zyga and lool: note that snap-confine has special handling of devpts
<zyga> right
<lazyPower> Hey, do we know if there is a weechat snap or a WIP of one?
<lazyPower> i checked uappexplorer, not sure if there's a better place to look
<lazyPower> before i tackled snapping up weechat i thought it would be best to ask the community at large
<lool> zyga: these are the fses I would expect apps to try to access, but there might be more and generally this pollutes mount output; would you be able to simply unmount everything under /var/lib/snapd/hostfs?
<didrocks> lazyPower: not that I know of. I would be interested by it, running weechat currently :)
<lazyPower> didrocks patch-pilot me? :D
<jdstrand> zyga: ok, approved. now can you reciprocate and review 181 and 182?
<zyga> lool: I could detach all of hostfs
<jdstrand> zyga: :)
<zyga> jdstrand: yes!
<zyga> jdstrand: taking my laptop on the go and going to review those two
<didrocks> lazyPower: heh, with pleasure! (but not today, EOW now ;))
<didrocks> lazyPower: I don't think it would be complex
<lazyPower> ack, i'll circle back on Monday with my WIP didrocks
<didrocks> (famous last wordsâ¦)
<didrocks> yeah ;)
<lazyPower> i tried this before and ran into issues with the addons
<lazyPower> it was the perl/tcl backend stuff iirc
<jdstrand> zyga: sure, please don't have it interrupt your evening or weekend
<didrocks> right, that's my fear
<lazyPower> but i nuked that disk and didnt have it pushed anywhere, like a swell developer making swell decisions :|
<didrocks> lazyPower: classical :)
<didrocks> lazyPower: good luck then and talk to you on Monday! :)
<zyga> jdstrand: no worries, I'm not working today but since I love my job I'm doing it anyway :)
<jdstrand> zyga: ok, well, only if you love my PRs can you work on them :)
<jdstrand> zyga: seriously though, thank you :)
<zyga> jdstrand: my pleasure :)
<snap_question> I am building a snap that has a package that build 7 tools in the /usr/local/bin and /usr/local/sbin and would like to expose all of them. Is there a way to wildcard the the app command? I have done this already with filesets and stage being $binaries and snap being $binaries.
<jdstrand> roadmr: can you pull r798? no code changes, just an update to the base declaration that has the new interfaces that were committed this week
<zyga> snap_question: no, you have to mention each one separately
<snap_question> so I tried to do that but I ran into an issue where I would have to do packagename.executable1 , packagename.executable2
<snap_question> and so on to get each executable to run
<jdstrand> snap_question: yes, that is a limitation of the current implementation. you get one 'top' command such that if the command name is the same as the snap name, you may refer to it as 'snapname' rather than 'snapname.command'
<jdstrand> snap_question: work is actively underway to make it possible to remove that restriction
<roadmr> jdstrand: sure thing
<jdstrand> there may be a bug on it
<jdstrand> snap_question: https://bugs.launchpad.net/snappy/+bug/1607748
<mup> Bug #1607748: Ability to use two registered names for the same snap <lxd> <Snappy:Confirmed> <https://launchpad.net/bugs/1607748>
<jdstrand> snap_question: in the short term, you might use an alias as a workaround until this is implemented. eg alias bar=foo.bar
<snap_question> Was knocked offline but just asked the question regarding publishing all the apps using the apps: flag in yaml
<snap_question> Was there an updated message about running the executable without listing the snappackage.executable1, snappackage.executable2, etc...
<zyga> 18:42 < jdstrand> snap_question: yes, that is a limitation of the current implementation. you get one 'top' command such that if the command name is the same as the snap name,
<zyga>                   you may refer to it as 'snapname' rather than 'snapname.command'
<zyga> 18:42 < jdstrand> snap_question: work is actively underway to make it possible to remove that restriction
<zyga> 18:42 < roadmr> jdstrand: sure thing
<zyga> snap_question: ^^
<zyga> 18:42 < jdstrand> there may be a bug on it
<zyga> 18:44 < jdstrand> snap_question: https://bugs.launchpad.net/snappy/+bug/1607748
<mup> Bug #1607748: Ability to use two registered names for the same snap <lxd> <Snappy:Confirmed> <https://launchpad.net/bugs/1607748>
<jdstrand> roadmr: thanks!
<snap_question> <zyga> thanks for restating the responses
<snap_question> <jdstrand> looks like the LXD issue is exactly what I'm seeing.
<snap_question> Some of the tool suites I am looking to put into snap have like 7-10 or more executables in them, hopefully a compromise is found
<zyga> dillema: should I spread test locally in qemu and get less battery life or send them to linode and use more data?
<jdstrand> snap_question: well, as mentioned, people are working on that so it works better for people
<zyga> snap_question: it's just a matter of non-conflicting namespaces, many projects have a myriad of tools that could be better aggregated (this is a simplification but it's not uncommon). snapd supports one top-level command per project now because it was easier (snap name registration doubles as top level command registration) but we're working on unconstrained support for additional top level cmmands
<zyga> commands*
<zyga> jdstrand: offtopic, I'm working on a new tool that allows to inspect squashfs files at a raw level, analyzing each byte on disk and mapping it to some data structure
<zyga> jdstrand: it's in very early stages of development now but if you'd like to see a specific feature please let me know
<snap_question> zyga: understood, is the best place to keep an eye on this on the bug#1607748 page or is there a different status page to watch
<zyga> jdstrand: the goal is visual inspection, forensics and looking for hidden data or maliciously crafted files
<zyga> jdstrand: it's a pure python codebase for now
<jdstrand> zyga: this is something that tyhicks and I might want to see inre store reviews
<zyga> snap_question: I think that one is the best, also look for announcements of new snapd releases
<zyga> snap_question: my magic ball says 2.20
<zyga> jdstrand: the code associates each data structures with particular intervals in the analyzed object and can do simple reporting and human readable dumps
<zyga> jdstrand: plus, fun way to learn squashfs :)
<jdstrand> I bet!
<jdstrand> it might mean we can skip the resquash test or it might show what is wrong with the resquash test
<zyga> jdstrand: quick question https://github.com/snapcore/snap-confine/pull/181/files#diff-e6f0d601e8a1dea1cff5b48e16c13661R512 -- why are you using strncmp for the rest but not for x86_64 and i686?
<mup> PR snap-confine#181: add compatibility architectures for supported architectures (LP: #1592022) <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/181>
<jdstrand> zyga: because uname will return longer strings and we want them to match. eg, armv7l
<jdstrand> zyga: that should be 'arm'
<jdstrand> this is the methodology lxc uses
<zyga> jdstrand: I see
<zyga> jdstrand: I added a few comments, look at https://github.com/snapcore/snap-confine/pull/181#discussion_r88708613
<mup> PR snap-confine#181: add compatibility architectures for supported architectures (LP: #1592022) <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/181>
<zyga> jdstrand: other than that I'll merge it and iterate with tiny tweaks and some unit tests
<jdstrand> zyga: thanks!
<sergiusens> davidcalle so I merged, how often are the docs updated?
<Kurdiez> I had to install Ubuntu Core on regular Ubuntu I had on PC to start using snappy. I am kind of having hard time understanding the Ubuntu Core. Does it also become a layer on top of the OS like JVM and you are forced to program with the SDK given by the Ubuntu Core?
<Kurdiez> For example, opening socket connection or writing files to disk.
<mup> PR snapcraft#919 closed: docs: update GUI related integrations <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/919>
<tptr> hi, release question: the latest image here http://cdimage.ubuntu.com/ubuntu-snappy/16.04/ does not have the  mmcblk driver. (so cannot be installed on an Intel stick pc for example). This is the place where the latest stable snappy release is published, right?
<kyrofa> Kurdiez, no, not at all. The OS itself is structured a bit differently though, and applications need to abide by a certain set of rules. That's not to say that they need to use a specific SDK to write a file, they just need to write files in a specific location
<Kurdiez> Well, I understand the whole contain snaps file activities within its own folder
<Kurdiez> due to security reasons, I like that part
<kyrofa> Kurdiez, right. Not folder, more like "area" (since it's multiple folders), but you get the idea
<kyrofa> Kurdiez, but yeah, no special SDK needed, no specific language needed, etc
<Kurdiez> but i'm just worried about any other run time restrictions I would get
<Kurdiez> It seems like you are given a way to talk to snaps using some kind of sdk that is provided to you
<kyrofa> Kurdiez, so snaps are confined in a number of different ways. One is filesystem access (there are a limited number of places snaps can write), the other is syscall access (there are a limited number of things a snap can do)
<kyrofa> Kurdiez, by default, it's quite restrictive, i.e. you can't open sockets, etc. But if you declare in your snap that you need such a capability (i.e. by utilizing "plugs") you can expand your sandbox a bit
<Kurdiez> what if I want process from one snap to manually signal the process in another snap?
<kyrofa> Kurdiez, that's likely the `process-control` interface
<Kurdiez> ok... is there document that tells me what is restricted?
<Kurdiez> I read their website but couldn't find it
<Kurdiez> it'd be nice to know up-front what i can't do
<Kurdiez> before deciding to use it
<Kurdiez> If I am to migrate current code into snap packages.
<kyrofa> Kurdiez, this might be helpful: https://github.com/snapcore/snapd/wiki/Interfaces
<kyrofa> Kurdiez, by default you can run apps and services and read/write files in specific areas. Beyond that, you need to use those interfaces to expand the capabilities
<Kurdiez> oh snap...
<Kurdiez> so anything not provided by these interfaces here
<Kurdiez> I can't do
<Kurdiez> that's the idea behind snappy platform?
<kyrofa> Kurdiez, essentially. And new interfaces are being added all the time, so if you find something missing, please log a bug
<Kurdiez> Thanks for the help kyrofa. You are the man.
<kyrofa> Kurdiez, need to hit the network? Use network/network-bind. Want to play sound? Use pulseaudio. You get the idea :)
<Kurdiez> so if I write C code, i still have to manage garbage collection myself
<kyrofa> Kurdiez, and then, since interfaces are connections, a user can simply break the connection at any time (see your current connections via `snap interfaces`)
<kyrofa> Kurdiez, yeah, snaps don't change the game there :)
<Kurdiez> which I like. If I wanted garbage collection, I would probably install jvm snap and run java code I guess
<kyrofa> Kurdiez, indeed
<Kurdiez> thank you
<kyrofa> Kurdiez, any time-- let us know if you have any questions as you explore!
<jjohansen> zyga: not atm, there is an out of tree patch that could give that ability but nothing currently in yakkety/xenial kernels. It would be possible to drop it onto those kernels in an sru, but any such work would need to be scheduled with ty hicks and ratliff
<Ardinis> Hello, is there any limitation for using snappy on ubuntu core?
<jdstrand> mhall119: hey, I'm working on https://github.com/snapcore/snapd/pull/1613 and since apachelogger isn't here, I'm coming to you. do you know of two kde snaps that talk to each other over dbus in the manner that this PR is trying to address?
<mup> PR snapd#1613: interfaces/builtin: add dbus-app interface <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<jdstrand> I've solved the binding to a well-known name case fine but would like to verify the connection policy
<zyga> jjohansen: I don't think this is required, I was just curious, thank you for the explanation
<_markfeatherston> How would I go about mounting a snap rw?  I need to tweak a file in the core snap for a test and I'm assuming this is the simplest way to do it.
<_markfeatherston> the obvious mount -o rw,loop doesn't seem to work
<_markfeatherston> nm, found unsquashfs
<mup> PR snapcraft#920 opened: Ensure staged files are included in the prime step <Created by josepht> <https://github.com/snapcore/snapcraft/pull/920>
<kyrofa> _markfeatherston, yeah, you can't actually mount squashfs images as rw
<kyrofa> _markfeatherston, you can use unsquashfs and re-squash a modified version, as you found, or you can use overlayfs for temporary tweaks
<_markfeatherston> good to know there is another option, I'll remember overlays next time.  Thanks
<_markfeatherston> I found a bug in probert bringing up new hardware, trying to fix that
<tedg> jdstrand: Did you see my ping the other day about disabling interface checking on devmode snaps?
<tedg> jdstrand: WRT uploading to the store.
<lzyPwr> Silly question that i cant seem to find in the docs or the playpen. I'm working on a weechat snap and i need to pass some args to the cmake builder. is there a way for me to pass these args to the cmake build process?
<kyrofa> lzyPwr, indeed, run `snapcraft help cmake`
<lzyPwr> ah, thanks for the pointer
<kyrofa> lzyPwr, you'll see a description of the `configflags` option
<kyrofa> lzyPwr, sure thing :)
#snappy 2016-11-19
<mup> PR snapcraft#921 opened: Add support for hooks <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/921>
<mup> Bug #1643155 opened: No easy way to see if an auto-refresh made changes <Snappy:New> <https://launchpad.net/bugs/1643155>
<vadrian> hello
<vadrian> can someone tell me if there is a package containing qt's webengine for snapcraft ?
<gerry_> hi I am trying to make a snap of my java program. A copy of my yaml is here http://pastebin.com/BdX2W3xw and my wrapper is a single line $JAVA_HOME/jre/bin/java -jar $SNAP/highlighterpdf.jar. When I try to run it I get "unable to access jarfile"
<gerry_> the full error message is "Error: Unable to access jarfile /snap/highlighterpdf/x34/highlighterpdf.jar"
<mup> Bug #1643220 opened: ubuntu terminal app (edge) Unrecognized OpenGL version <Snappy:New> <https://launchpad.net/bugs/1643220>
<sonic> Hi, does anyone knows if there's an interface that allows me to read /sys/devices/virtual/dmi/id/product_serial ???
<sonic> is there anyone here?
<sonic> this is the quietest chat I've ever seen
<sonic> don't even know what all this people are doing logged here
<sonic> meditation chat
<sonic> let's use telepathy
#snappy 2016-11-20
<Kurdiez> when I use the snapstore to host my own snap store, I get an error from the snapd with signature mismatch
<Kurdiez> I looked at the sources of the current snapstore and it does not do any kind of signature attachment to the JSON response it sends back to the snapd.
<Kurdiez> Is there an updated SnapStore that works with the latest snapd?
<Kurdiez> I got the SnapStore link from the Ubuntu Core official site.
<foxmask> bonjello
<mup> Bug #1643292 opened: /snap/bin/hello - fails to execute with apparmor error. <Snappy:New> <https://launchpad.net/bugs/1643292>
<gerry_> hi I am trying to package my java app and receiving this error "Error: Unable to access jarfile /snap/highlighterpdf/x48/highlighterpdf.jar"
<gerry_> sorry forgot to mention I get this error when I try to use it after I have installed it
<OnkelTem> Hi all
<OnkelTem> I've just discovered Snaps things :)
<OnkelTem> thing*
<OnkelTem> I wonder is it more a future technology or I can make use of it right now?
<OnkelTem> I'm trying to create a portable workstation and currently targeting on docker images
<OnkelTem> I'd like to up and run a workstation with all needed (developer) environment as fast as possible
<OnkelTem> in some sense I dream of a thin workstation :)
<OnkelTem> well technically it will be thick of course, but from administration pov it would require almost zero efforts to get it working
<OnkelTem> Can snaps help me in this?
<gerry_> hi I am trying to package my java app. This is my yaml http://pastebin.com/7K241tTf . When I try to run it  I get "A fatal error has been detected by the Java Runtime Environment:"
<gerry_> I am using this one line wrapper "$JAVA_HOME/jre/bin/java -jar $SNAP/usr/bin/highlighterpdf.jar"
<Guest58894> does anyone knows where $SNAP_DATA writes to? to which directory? thanks
<foxmask> Guest58894: /usr/lib/snap* ?
<foxmask> or /var/lib/snap*
<foxmask> not sure
<Guest58894> hum, because I'm writing my logs to $SNAP_DATA and I have no idea where it is
<Guest58894> in the reference they had an example with a format like: /var/snap/<snap-name>/<version>
<Guest58894> but I didn't see the logs there :/
<foxmask> Guest58894: my poor friend, i a noob like you :/
<Guest58894> :D
<foxmask> :D
<foxmask> try a find / -name yourlogfile.log
<foxmask> you'sll spot the $SNAP_DATA folder :)
<foxmask> you'll spot the $SNAP_DATA folder :)
<Guest58894> no luck :/
<Guest58894> maybe nothing is getting written in the file :D
<Guest58894> and I got no bugs, so there's no need to write a log of a problem that didn't happen :D
<Guest58894> thanks anyways :)
<Guest58894> good luck out there too
<blackout24> Hi, I'm running the ubuntu-terminal-app on Arch Linux as a snap. The only issue is that it asks for authentication, but doesn't accept my standard password. What does it need authentication for?
#snappy 2017-11-13
<gsilvapt> Hello. I was running a Snapcraft tutorial to refresh my memory and for some reason it assumes the command is snap_name.the_name_I_wrote_In_yaml_file
<gsilvapt> Did I do something wrong?
<ikey> https://plus.google.com/+Solus-Project/posts/5Cn3P26tbtK <- coolness :D
<ikey> first soul to run lsi on ubuntu
<ikey> gsilvapt, from what i understand, if the name in apps: matches the snap name, the original name is preserved
<ikey> if the app name is different, and no automatic aliasing is permitted for it (by vote), it'll go to $snap.$app
<gsilvapt> I just tried that and I think it is not working
<gsilvapt> I will try keep $snap and $app name equal and add bin/hello to the command field
<ikey> right
<mup> PR snapcraft#1727 closed: integration tests: remove ruby version <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1727>
<gsilvapt> Nope, I get "[...] hello can be found in following packages[...]" error
<ikey> ah right so the alias thing
<ikey> the name exists in the ubuntu archive so it wont alias it
<ikey> is my understanding
<gsilvapt> well, it should somehow, that's why the tutorials mentions it
<ikey> probably best to poke one of the proper snap guys when they're around, timezones permitting
<gsilvapt> When you install the snap, it gives this error. Then you add the app part and it should work after "snapcraft prime" and "snap try"
<diddledan> the app needs to be named the same as the snap for it to use that name as the command
<diddledan> so snapcraft.yaml:
<diddledan> https://www.irccloud.com/pastebin/RaiHmrXU/
<diddledan> note the position of the hello
<gsilvapt> Please, let me know where they differ because I can't tell the difference: https://pastebin.com/kkrEKGnT
<gsilvapt> I've also tried removing the bin part in the command
<diddledan> your command isn't "hello"
<diddledan> your command is "gsilva-test-snap"
<diddledan> so trying to run "hello" won't work
<gsilvapt> the only way it works is gsilva-test-snap.hello
<gsilvapt> and that configuration doesn't even work
<ikey> the snap would need to be named hello too, right?
<diddledan> no. in that yaml your snap will install a command in /snap/bin called "gsilva-test-snap"
<gsilvapt> gsilva-test-snap.hello only works if apps: hello: command: hello is there
<ikey> sure but it'd just be "hello" if all those were "hello"
<diddledan> the command: bit doesn't affect the name of the command it installs
<diddledan> command: is to tell snapd which executable to call when "gsilva-test-snap" is run
<gsilvapt> diddledan, then you're basically telling snapcraft changed its functionality along the way and all guides are out-dated?
<diddledan> if you change apps: gsilva-test-snap to apps: hello then your app name will be "hello" which differs from the name of your snap so it gets appended with a dot
<diddledan> no
<diddledan> I'm not saying that at all
<gsilvapt> diddledan, it doesn't work, I already mentioned that. When I put hello instead, the only way I can run the command is if I run gsilva-test-snap.hello - which is basically $snapName.$snapApp
<diddledan> https://www.irccloud.com/pastebin/ArgrTEEO/
<gsilvapt> Moreover, if I change the snap name to hello, then the command hello works alone
<gsilvapt> AHH
<gsilvapt> I think I got it
<ikey> ow i didnt realise that snapd bind mounts the nvidia driver into the target on multiarch
<diddledan> ouch
<ikey> thats gonna slightly ruin my plans for /var/lib/snapd/gl/32 on ubuntu
<ikey> er lib/gl/32
<diddledan> that sounds like something to be changed in snapd to support cores other than ubuntu?
<ikey> well right now the mount-support-nvidia.c only exposes 64-bit driver to the "guest"
<diddledan> it's an assumption of filesystem layout which shouldn't be assumed
<ikey> i could perhaps change to something like..
<ikey> /var/lib/snapd/lib/gl/vulkan /var/lib/snapd/lib/gl32 /var/lib/snapd/lib/gl
<ikey> er
<ikey> *lib/vulkan
<gsilvapt> Thanks for the help, diddledan and ikey
<ikey> np
<ikey> yep i think i like that schema more
<ikey> in which case ill pull my PRs and send new ones
<ikey> and do both multiarch + biarch together
<mup> PR snapd#4199 closed: cmd/snap-confine: Add support for 32-bit NVIDIA on biarch <Created by ikeydoherty> <Closed by ikeydoherty> <https://github.com/snapcore/snapd/pull/4199>
<mup> PR snapd#4206 closed: cmd/snap-confine: Make the vulkan ICD definition available <Created by ikeydoherty> <Closed by ikeydoherty> <https://github.com/snapcore/snapd/pull/4206>
<robert_ancell> jamesh: Perhaps you might be able to help in https://bugzilla.redhat.com/show_bug.cgi?id=1509586
<ikey> what sounds better, "/var/lib/snapd/lib/gl32" or "/var/lib/snapd/lib/gl.x86" ?
 * ikey is tending towards gl32
<ikey> can't start monday without a bit of bikeshedding :p
<robert_ancell> Son_Goku: I'm assuming you've gone? The Fedora issue is definitely in snapd, possibly due to missing polkit config (that definitely should be fixed) and some SELinux permissions needing updating?
<King_InuYasha> robert_ancell: I'm still here
<King_InuYasha> I've just been playing a video game for the last few hours :)
<robert_ancell> Don't let me interrupt you then :)
<King_InuYasha> is there a new polkit config I'm supposed to add
<King_InuYasha> ?
<King_InuYasha> because this sounds like something new no one told me about
<robert_ancell> King_InuYasha: yes. This means we no longer need snapd-login-service 9o/
<King_InuYasha> oooo
<King_InuYasha> that'd be nice
<King_InuYasha> would you be willing to throw the deets into the bugzilla bug so that I can fix it later?
<robert_ancell> King_InuYasha: already there
<robert_ancell> I'm struggling to understand the SELinux stuff though, you might know better there
<King_InuYasha> I suspect that the introduction of snap-seccomp is probably breaking things
<King_InuYasha> what was *supposed* to happen (and is clearly not) is when stuff like this is introduced, something would flag zyga and myself about things like this that'd break snapd in SELinux
<King_InuYasha> since snapd _still_ can't generate SELinux policies itself, I have to "unlock the gates" so to speak
 * King_InuYasha is super annoyed that after a year, still no one has started working on supporting SELinux properly
<King_InuYasha> it's things like this that make me reticent to ship snapd in EPEL
<King_InuYasha> like, what's the _point_ in shipping snapd for CentOS if I know everything is going to be broken
<King_InuYasha> and the malarkey about stacked LSMs isn't going to help me at all, because *even if* we stacked AppArmor on SELinux in Fedora, that still doesn't help me for RHEL/CentOS where they're *not* going to do that
 * King_InuYasha has a bone to pick with the security people about this, as this is what keeps diverting attention towards even getting this resolved
<King_InuYasha> robert_ancell: basically, at some point, I need to collect all the AVC denials _again_ and fill them back into the snapd SELinux policy
<robert_ancell> King_InuYasha: just keep iterating until it works?
 * King_InuYasha sighs
<King_InuYasha> yeah, basically
<King_InuYasha> it's exhausting, though
<King_InuYasha> and it's so bloody tedious
<King_InuYasha> this is the shit work that makes me wonder if it's worth doing all this
<King_InuYasha> because _no one_ ever helps
<King_InuYasha> robert_ancell: anyway, it's not your fault
<robert_ancell> :(
<King_InuYasha> you've been pretty helpful whenever I've encountered issues with snapd-glib, so for that I thank you
<King_InuYasha> but snapd is *hard*
<King_InuYasha> and on top of this, I *still* need to do the work on snapcraft
<King_InuYasha> but where's the time?
<robert_ancell> King_InuYasha: what's the challenges with snapcraft?
<King_InuYasha> writing the DNF backend to complement the APT one takes time and effort
<robert_ancell> oh, for pulling in deps
<King_InuYasha> and it's not helping that Snapcraft does weird things with packages
<King_InuYasha> and on top of it, someone needs to package LXD for Fedora because the lxd snap is garbage and it makes no sense that it isn't in Fedora
<King_InuYasha> without a working lxd, snapcraft cleanbuild is broken
<robert_ancell> I see
<King_InuYasha> there's already somebody packaging it in COPR (equivalent to PPA), but it should be migrated to the main Fedora repositories
<King_InuYasha> but the problem is that I'm just one person, and I have so many things I need to do
<robert_ancell> oh, at least there's that
<King_InuYasha> and more stuff keeps piling up
<robert_ancell> Sure, please don't burn out! You've been a huge help getting everything working in the Fedora/RH land
<King_InuYasha> I'm drowning...
<King_InuYasha> I've been asking for help in the last few sprints, but aside from that short period where morphis was helping zyga, I've got nothing
<King_InuYasha> and nowadays, I don't even have zyga
<robert_ancell> King_InuYasha: where's the snapd packaging stored? I'll try and write the polkit patch for it
<King_InuYasha> https://src.fedoraproject.org/rpms/snapd
<King_InuYasha> I've been putting off the 2.29.x rebase for a while, because I know a whole bunch of things have changed
<ikey> ubuntu has /usr/lib32 right?
<King_InuYasha> ikey: no
<ikey> as a link
<King_InuYasha> it shouldn't anymore
<ikey> https://github.com/solus-project/linux-steam-integration/issues/35#issuecomment-343777346
<King_InuYasha> unless your system is old as shit and you've been upgrading from pre-debplatformlibdirs
<ikey> because the nvidia bit looks for "/usr/lib/nvidia-%d" and im tryna figure out how to get the 32-bit equivalent
<King_InuYasha> you can't
<ikey> i suspect it means directly prodding "/usr/lib/i386-linux-gnu" or some nonsense
<King_InuYasha> yes
<King_InuYasha> if it's installed there, it'll be there
<King_InuYasha> 32-bit libraries go into nonsense /usr/lib/<platform-triple>
<ikey> that person is on ubuntu 17.10
<King_InuYasha> yeah, so the {multiarch} keyword in AppArmor should already take care of that
<ikey> i dont think that qualifies as "old as shit"
<ikey> thats apparmor
<ikey> not C
<ikey> i need the actual directory
<King_InuYasha> oh fuck me
<ikey> the fuck is your problem?
<ikey> some attitude on you
<King_InuYasha> something just broke on my end
<ikey> ill work it out myself
<King_InuYasha> my UPS just died
<King_InuYasha> ... and there goes my beefy rig :/
<King_InuYasha> ikey: anyway, the ubuntu multiarch *should* be /usr/lib/i386-linux-gnu
<King_InuYasha> it *could* also be i686-linux-gnu since Debian did that transition between jessie and stretch
<King_InuYasha> lemme check real quick
<King_InuYasha> nah, it's i386-linux-gnu
<ikey> https://packages.ubuntu.com/artful/amd64/nvidia-384/filelist
<King_InuYasha> ugh
<ikey> it would appear someone made a legacy-jank-concession
<King_InuYasha> yeah
<King_InuYasha> I suspect they didn't realize that it was supposed to go into $(LIBDIR) not $(LIBEXECDIR)
<ikey> i feel offended for it and i dont even use multiarch
<King_InuYasha> so they accidentally borked it for multiarch
<King_InuYasha> so unfortunately, this is an Ubuntu problem
<King_InuYasha> there's not really a nice way to deal with this, since they don't set this up correctly: https://packages.ubuntu.com/artful/i386/nvidia-384/filelist
<ikey> hm
<King_InuYasha> In Debian, you're supposed to use platform libdirs to make this work correctly
<ikey> ok so i could prod lib and allow fail, and prod lib32, and allow fail
<King_InuYasha> yeah
<ikey> and in apparmor allow lib{,32}
<ikey> because apparmor is nice for that
 * King_InuYasha shrugs
<King_InuYasha> you'd also want to allow lib64, right?
<ikey> eehm
<King_InuYasha> or is that already allowed?
<ikey> multiarch is debian only
<ikey> really
<ikey> and its already doing from "just lib"
<ikey> for the biarch stuff then yeah sure
<King_InuYasha> right, that's what I mean
<ikey> we want lib{,32,64}
<King_InuYasha> and it's not like /usr/lib64 doesn't exist in Debian
<ikey> right
<King_InuYasha> it just only has one library in it
<ikey> im thinking something like this
<ikey>   /var/lib/snapd/lib/gl{,32}/** rm,
<ikey> and on the nvidia code mount the 32-bit and 64-bit directories
<ikey> on the biarch you'd get two tmpfs's
<ikey> with symlink farms
<King_InuYasha> right
<ikey> as opposed to my old method of /32 subdir
<ikey> which.. was somewhat short sighted
<ikey> now i think of it
<King_InuYasha> and on deb platform libdirs, you get a single tmpfs
<ikey> yeah
<ikey> ok so this "allow all the 32bits" should be technically trivial and i think my change is sane
<ikey> and ill do vulkan separate
 * King_InuYasha gives ikey a thumbs-up
<ikey> because thats probably gonna be a copy the icds into tmpfs jobby
<King_InuYasha> how do you deal with UsrSplit?
<ikey> so biarch in the nvidia code means "/usr/lib" "/usr/lib32"
<King_InuYasha> aka, the arbitrary moving of libs between / and /usr?
<ikey> i.e.:
<ikey> 	"/usr/lib/libEGL.so*",
<ikey> we're only dealing with those dudes there
<ikey> so no potential for /lib vs /usr/lib jank
<ikey> fwiw solus only has ld-linux symlinks in /lib for libraries
<ikey> and everything else is in /usr/lib64 (lib -> lib64 link)
<King_InuYasha> right
<King_InuYasha> and you have /usr/lib32 for your i686 libs, iirc
<ikey> right
<ikey> all of this for darned steam eh
<King_InuYasha> meh
<King_InuYasha> it's Valve's fault :D
<ikey> mm
<King_InuYasha> they should fix it
<ikey> https://hastebin.com/yatafacebe.cs <- seems half sane
<ikey> ill need to actually compile it now and test but ya
<King_InuYasha> to clarify, there should never be a case of /lib/gl64?
<ikey> nah
<ikey> "lib" is considered "native arch"
<ikey> in this context
<ikey> and "lib32" is "oh hey i found a lib32 variant lets add him too"
<ikey> on 32-bit system "lib" would be 32-bit and lib32 would never mount
<ikey> cuz it wouldnt exist
<King_InuYasha> ... you'd hope
<ikey> well i mean it'd be harmless if it did
<King_InuYasha> technically, on 32-bit Debian and Ubuntu, it does
<ikey> lets say someone got cocky on i686 and symlinked lib32 to lib
<ikey> so it exists twice
<King_InuYasha> nothing bad really happens then
<ikey> worst case scenario you now have the same tmpfs twice
<ikey> and its in LD_LIBRARY_PATH
<ikey> well SNAP_LIBRARY_PATH and *potentially* LD_LIBRARY_PATH
<ikey> but totally harmless
<ikey> ld will just break at the first usable dude
<King_InuYasha> right
<ikey> and for all the other nastiness, liblsi-intercept.so can kick it in the face and say "no"
<King_InuYasha> :)
<King_InuYasha> sounds like a plan
<ikey> i can add a sanity test to LSI on entry too
<ikey> i.e. if /var/lib/snapd/lib/gl/libGL.so.1 exists, but /var/lib/snapd/lib/gl/32/libGL.so.1 *doesn't* exist, start complaining
<ikey> if we're 32-bit, complain that store wont work
<ikey> if we're 64-bit - complain that nothing will work
<ikey> instead of steams entirely unhelpful "libGL.so.1" error dialog
<robert_ancell> King_InuYasha: what command do you use to build from git src branches?
<robert_ancell> and what's the equivalent of dch?
<King_InuYasha> robert_ancell: the tool fedpkg is what you're looking for
<King_InuYasha> and as for bumping changelogs, that rpmdev-bumpspec
<King_InuYasha> "sudo dnf install /usr/bin/fedpkg /usr/bin/rpmdev-bumpspec"
<robert_ancell> King_InuYasha: ta
<King_InuYasha> for reference: https://www.mankier.com/1/fedpkg & https://www.mankier.com/1/rpmdev-bumpspec
<robert_ancell> King_InuYasha: and the equivalent of apt build-dep?
<robert_ancell> ah dnf builddep
<King_InuYasha> yep
<King_InuYasha> though you can do clean chroot builds by using fedpkg mockbuild when you're in the git repo top dir
<King_InuYasha> ahh, a couple of hours of Sonic Forces have made me feel a lot better :)
 * ikey flinches at mere mention of games
<ikey> cmd/configure:1183:55: "includ" is a misspelling of "include"
<ikey> Crushing failure and despair.
<ikey> *snort*
<ikey> the tests dislike a dirty tree :p
<King_InuYasha> haha
<King_InuYasha> ikey: well, if it makes you feel better, Sonic Forces isn't a Linux game
<King_InuYasha> I have it on Nintendo Switch :)
<ikey> aah ok
<King_InuYasha> I do wish SEGA would release Sonic games for Linux
<King_InuYasha> but it's unlikely to happen unless someone has an "in" with SEGA
 * King_InuYasha stares intently at ikey
<ikey> xD
<ikey> nah not me
<King_InuYasha> :'(
<King_InuYasha> you don't secretly have someone who knows someone who works on Sonic Team in your back pocket? :P
<ikey> naaah
<ikey> besides i wouldnt wanna be in my back pocket when i sit down..
<ikey> "ln -s /home/ufee1dead/Projects/snapd src/github.com/snapcore/."
<ikey> >_>
<Son_Goku> haha
<ikey> go doesn't know... shhh :p
<Son_Goku> it's the dumbest part about go
<ikey> FAIL	github.com/snapcore/snapd/cmd/snap-seccomp	1.255s
<ikey> Crushing failure and despair.
<ikey> aw what
<Son_Goku> sometimes I wonder what the fuck Google was thinking when they made that language
<ikey> user: unknown user daemon
<ikey> sudo useradd daemon -s /bin/true -c "lol" -g daemon
<ikey> >_>
<ikey> Son_Goku, they played it safe tbh
<Son_Goku> >_<
<ikey> oh cmon seccomp cruft
<ikey> this is just silly now
<ikey> now i get https://hastebin.com/raw/omukojuzok
<ikey> and i had to create that daemon user
<ikey> so - im just gonna ignore all seccomp failures from hereon out
<ikey> ^_^
<ikey> ok that change actually works nicely, now to test its apparmor side is ok
<ikey> then to stick on vulkan and opencl
<ikey> and we're all happy
<ikey> bash-4.3$ ls /var/lib/snapd/lib/vulkan
<ikey> 10_nvidia.json	10_nvidia_wayland.json
<ikey> \o/
<ikey> gah denials.. :D
<mup> PR snapd#4207 opened: Flesh out NVIDIA support for biarch and multiarch systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4207>
<mup> PR snapcraft#1728 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1728>
<mborzecki> morning guys
<mborzecki> mvo: hi
<mvo> hey mborzecki, good morning
<mborzecki> how was your weekend?
<mvo> mborzecki: good, weather was a bit annoying, gray and rainy but everything else was fine :)
<mborzecki> great
<mvo> mborzecki: and yours?
<mborzecki> we had indenepdence day on the 11th, unfortunately the weather was so bad :/ a bit of rain, a bit of snow and windy
<mborzecki> didn't even try to take my kids to see the festivities
<mvo> mborzecki: meh, sounds like we had about the same weather (except no snow here :)
<mborzecki> need to think of a scheme where you stay half a year in europe (the nicer half of the year) and then in the winter you move to southern hemisphere or at least somewhere south there it's cheap and warm
<mvo> mborzecki: ask zyga about that, he might have some ideas ;)
<mborzecki> malta should be nice this time of year
<mvo> mborzecki: yeah, gosh, malta is nice
<mvo> mborzecki: don't tempt me, when I look outside I really want to fly immediately :)
<mborzecki> hahaha
<zyga-ubuntu> I will send kids to school and I'll be back soon
<mvo> zyga-ubuntu: do you know if 4202 needs a jamie review still?
<zyga-ubuntu> looking
<zyga-ubuntu> mvo: I think so, he had a look already
<mvo> ok
<zyga-ubuntu> mvo: today I will do some code reviews and I'll return to 14.04 / lxd issue
<zyga-ubuntu> mvo: I also plan to resume looking at brave browser not working on 14.04
<mvo> zyga-ubuntu: sounds good, lets try to fix this for 2.30
<mborzecki> zyga-ubuntu: posted SNAPD_DEBUG from running brave browser
<zyga-ubuntu> mborzecki: thank you, at the forum?
<mborzecki> yup
<zyga-ubuntu> I see it now
<zyga-ubuntu> I tried running it but it didn't crash outright
<zyga-ubuntu> but it didn't start up either
<zyga-ubuntu> needs some more digging
<mborzecki> also, have you seen the problem with teleconsole that popey had?
<zyga-ubuntu> mborzecki: no, I have not
<mborzecki> https://forum.snapcraft.io/t/brave-and-other-apps-dont-launch-on-arch/2770/9
<zyga-ubuntu> mborzecki: well, I'll be busy today :)
<mborzecki> he's running it in a vm, I tried running in locally and works just fine
<zyga-ubuntu> mborzecki: I wonder if that is CPU age difference
<zyga-ubuntu> mborzecki: perhaps you just have the specific instruction implemented
<mborzecki> yup, my rough guess is that ld.so does some optimized mmx/sse/avx code and it's not there in the vm
<mborzecki> anyways, it's super weird
<mup> PR snapd#4208 opened: packaging/arch: do not quote MAKEFLAGS <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4208>
<zyga-ubuntu> mvo: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1679191
<mup> Bug #1679191: Download snap "conjure-up" from channel "stable" (snap not found) <snapd (Ubuntu):New> <https://launchpad.net/bugs/1679191>
<ikey> zyga-ubuntu, got some toys uploaded :p
<zyga-ubuntu> ikey: oh? :-)
<ikey> i scrapped my 2 PRs and did another last night
<zyga-ubuntu> I saw two closed
<ikey> which adds multiarch nvidia support
<ikey> https://github.com/snapcore/snapd/pull/4207
<mup> PR #4207: Flesh out NVIDIA support for biarch and multiarch systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4207>
<zyga-ubuntu> I didn't go through all of github.com/notifications yet
<ikey> it just fixes up nvidia into a nice state
<zyga-ubuntu> aha, nice, I'll have a look soon
<ikey> i added a link there to the snaps built against that PR if anyone fancies testing them and playing around at some point
<ikey> (quite literally "playing" :))
<zyga-ubuntu> haha
<zyga-ubuntu> nice, I don't have anything beefy for gaming though
<zyga-ubuntu> well, not nvidia
<ikey> from my angle I can't see why this PR won't work on ubuntu but id love to have the confidence in that assertion
<ikey> oh fwiw open sauce drivers will Just Work â¢ on master
<ikey> as it contains its own mesa etc
<zyga-ubuntu> ikey: we made sure we can now test nvidia a little bit more than before
<ikey> oh ok
 * ikey is rocking a 1060 on the laptop so gets to test that stuff
<zyga-ubuntu> ikey: both mvo and me have oldish nvidia GPUs for testing
<ikey> ah ok
<ikey> well if you ever need me to prod anything with a new gpu lemme know
<zyga-ubuntu> thank you, I think we will test each candidate core snap this way from now on
<zyga-ubuntu> to avoid issues like we had during the last release
<ikey> yea
<ikey> gonna pick your brains at some point about execution permissions on mount points under snap
<ikey> or "why i get EPERM on hostfs mounts"
<ikey> but not on ~
<ikey> its gotta be the lower apparmor stuff
<zyga-ubuntu> sure
<ikey> but > some point
<zyga-ubuntu> I'll do my best to help
<ikey> i just watched a god awful film and cant brain
<zyga-ubuntu> which one?
<ikey> "Fallen"
<ikey> its on netflix atm
<ikey> stinks like a fanfilm of twilight
<ikey> and maybe written by a 12 year old
<zyga-ubuntu> ikey: I just checked, not available in .pl on netflix
<zyga-ubuntu> ikey: likely a feature then :)
<ikey> lol ya
 * zyga-ubuntu didn't realize ubuntu had a /usr/lib32 directory
<ikey> yeah we were all a bit astonished by that one
<zyga-ubuntu> I wish someone wrote a blog explaining the semantics of the FS
<ikey> the nvidia driver packages have the lib32 dirs
<zyga-ubuntu> is it all just a bunch of legacy
<ikey> i was expecting multiarch stuff
<zyga-ubuntu> and more legacy
<zyga-ubuntu> and compat glue and symlinks on top?
<jamesh> lib32 is for the x32 pseudo-architecture, IIRC
<ikey> nah thats libx32
<zyga-ubuntu> jamesh: yeah, that's not x32
 * zyga-ubuntu played with x32 last week for some pet project
<ikey> https://packages.ubuntu.com/zesty/amd64/nvidia-375/filelist
<ikey> *shrug*
<jamesh> zyga-ubuntu: I think I've got everything addressed in my snap-update-ns PR.  It now removes even more lines of code
<mborzecki> huh, weren't these supposed to be under /lib/<arch-tuple> ?
<ikey> im guessing theres a reason for it
<ikey> more than likely due to the subdirring
<ikey> and update-alternatives and all that junk
<ikey> or the more elegant name of "compounded beastliness"
<ikey> on the other hand it made my PR a whole bunch simpler :P
<ikey> fwiw i figured these changes will allow me to follow up with a very simple cuda/opencl enabling PR at some point when i have the ocl-icd patch ready
<ikey> as it'll be a clone almost of the vulkan change
<ikey> then we can enable opencl/cuda in snaps trivially
<ikey> (handy for games and blender / nvcc etc)
<zyga-ubuntu> jamesh: hey, I'll gladly look shortly
<mwhudson> zyga-ubuntu: i finally poked at snapd 2.29.3 for debian, turns out we need a newer golang-dbus but that should be easy enough
<zyga-ubuntu> mwhudson: thank you! I have my debian box back but I wasn't doing any packaging for a good while now
<ikey> wondering if i could export some parts of LSI shim as part of an entry point for normal snaps..
<ikey> ive seen the desktop-helper bash scripts..
<ikey> got quite a bit of bootstrap code here https://github.com/solus-project/linux-steam-integration/blob/master/src/shim/shim.c#L189
<ikey> might come in useful
<zyga-ubuntu> ikey: entry point .. hmm
<zyga-ubuntu> ikey: you could just put that in a base snap and provide something like lsi-run ...
<ikey> yeah
<ikey> ive been considering an lsi-exec fwiw
<ikey> for other non-steam stuff
<ikey> mostly for fixing old busted stuff and for the shim side of it..
<ikey> its certainly been an interesting experience really getting into the guts of how all this works
<ikey> like figuring out how to make .desktop files actually work work
<ikey> without snapcraft
<zyga-ubuntu> yeah :-)
<zyga-ubuntu> I really like the largely free-form of packaging this offers
<ikey> we're doing a bit of evil in building our snaps atm
<ikey> we're using the solus tooling to emit the roots and then snap packing them
<zyga-ubuntu> nothing is evil there
<ikey> but then we can do this: https://github.com/solus-project/runtime-snaps/tree/master/support_packages
<ikey> and we're overlaying even the normal solus pkgs
<ikey> so we stuck a brand new mesa in, some compat libs, etc
<ikey> and fwiw, the "make this root good for snapd" isn't that hard
<ikey> https://github.com/solus-project/runtime-snaps/blob/master/round1.sh#L28
<ikey> that one function cleans it up and makes it appropriate for use
<ikey> i reversed the lib64 directories to make the apparmor stuff happy for now
<ikey> im confident i could modify that script to spit out a base for any given distro
<zyga-ubuntu> darn, this brave snap doesn't work anywhere
<mborzecki> anywhere, but my laptop
<zyga-ubuntu> mborzecki: I get nothing, ranging from "some spewing errors" to exiting silently
<mborzecki> I get a bunch of logs and a browser window
<zyga-ubuntu> woot
<zyga-ubuntu> mborzecki: it just started on 17.10 natively on nvidia
<zyga-ubuntu> that's interesting
<zyga-ubuntu> but it failed on 17.10 with much more recent cpu on intel!?!
 * zyga-ubuntu looks
<zyga-ubuntu> the old one is i7 though
<zyga-ubuntu> the new one is i5
<mborzecki> 'snap run brave' vs 'brave' shouldn't be a problem?
<zyga-ubuntu> mborzecki: no, it's the same thing
<zyga-ubuntu> brave is "curious"
<zyga-ubuntu> it gets brave-download.globa.ssl.fastly.net/multi-channel/releases/dev/0.19.89/linux64/Brave.tar.bz2
<mborzecki> https://i.imgur.com/AR0oW6U.png
<mborzecki> would that be much of a problem if run-checks became #!/bin/bash rather than #!/bin/sh script?
<zyga-ubuntu> mborzecki: I think it's fine
<zyga-ubuntu> mborzecki: but consider /bin/env/python3 :)
<mborzecki> you could make it a go script :) #!/usr/bin/env go run
<ikey> is it just arch that its busted on?
<zyga-ubuntu> ikey: no, it works on arch
<mborzecki> for once
<ikey> o
<zyga-ubuntu> ikey: I think it's only affected by CPU features
<ikey> works here on solus fwiw
<zyga-ubuntu> ikey: it's a strictly confined snap
<ikey> https://ibin.co/3h8KV3PWG8Qr.png
 * zyga-ubuntu is still digging
<ikey> --edge, w:
<zyga-ubuntu> how do you do those pictures?
<ikey> CPU:       Quad core Intel Core i7-7700HQ (-HT-MCP-) cache 6144 KB
<ikey>            clock speeds max 3800 MHz 1 3701 MHz 2 3609 MHz 3 3502 MHz 4 3703 MHz 5 3799 MHz 6 3600 MHz
<ikey>            7 3601 MHz 8 3600 MHz
<ikey> Graphics:  Card NVIDIA GP106M [GeForce GTX 1060 Mobile 6GB]
<ikey>            Display Server x11 (X.Org 1.18.4 ) driver nvidia Resolution 1920x1080@60.00hz
<ikey>            OpenGL renderer GeForce GTX 1060/PCIe/SSE2 version 4.5.0 NVIDIA 384.98
<ikey> imagebin.ca for le pics
<zyga-ubuntu> 7700HQ, faaast
<ikey> this is a laptop believe it or not
<ikey> xD
<ikey> terrified to unplug it
<zyga-ubuntu> I'm on Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
<ikey> ah nice
<zyga-ubuntu> but...
<ikey> does look like brave has some bugs though tbh
<zyga-ubuntu> something is fishy
<zyga-ubuntu> as fish and chips
<zyga-ubuntu> ;-)
<ikey> my terminal spam is cranky
<zyga-ubuntu> on my W510 it runs in 17.10 native
<zyga-ubuntu> and doesn't start in a 16.04 vm
<ikey> ive learned to not expect quality from anything that based itself around chromium
<zyga-ubuntu> on that same box
<ikey> error handling is a lost artform
<zyga-ubuntu> G
<zyga-ubuntu> I'm sleepy
<zyga-ubuntu> it was 14.04
<ikey> heh
<zyga-ubuntu> ok, I'll look at 16.04
<ikey> chromium error handling ~= java error handling..
<ikey> try { noShitsGiven(); } catch (Error e) { /* Still not caring */ }
<ikey> exception, w/e it is
 * ikey has been lucky to not java in a long time :P
<zyga-ubuntu> err := doStuff()
<ikey> if err != nil ..
<ikey> lol
<zyga-ubuntu> if err != nil { err = nil } // suck it
<ikey> or my fav
<ikey> if err != nil { err2 = err }
<ikey> for the deferred return error swaps
 * ikey shudders a bit
 * ikey hugs C
<zyga-ubuntu> I'll look at debian sid now
<zyga-ubuntu> and then go to 16.04
<zyga-ubuntu> yeah, I love C too
<ikey> :D
<mwhudson> zyga-ubuntu: lolwhut
<mwhudson> (sid-amd64)root@aeglos:/build/snapd-CzeWTt/snapd-2.29.3.1# strings _build/bin/snapd|grep  -E "public-key-sha3-384: [a-zA-Z0-9_-]{64}"
<mwhudson> public-key-sha3-384: d-JcZF9nD9eBw7bwMnH61x-bklnQOhQud1Is6o_cn2wTj8EYDi9musrIT9z2MdAa
<mwhudson> public-key-sha3-384: -CvQKAwRQ5h3Ffn10FILJoEZUXOv6km9FwA80-Rcj-f-6jadQ89VRswHNiEB9Lxk
<ikey> "if you blow your foot off, its your own damn fault. you told me to" = C
<zyga-ubuntu> mm?
<zyga-ubuntu> there are two keys now
<zyga-ubuntu> one for generic something something
<zyga-ubuntu> and one root key
<zyga-ubuntu> something something is something that pedronis is deeply familiar with
<mup> PR snapd#4209 opened: run-checks, tests/lib/snaps/: shellcheck fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4209>
<mwhudson> zyga-ubuntu: ah ok so this is a change i need to bring over to my d/rules i guess
<zyga-ubuntu> mwhudson: yes, it's a desired thing
<ikey> does it make you cry a bit inside having to package up something intended for easy packaging, with something as god awful as debian/rules?
<ikey> xD
<zyga-ubuntu> man, I need to find a better VGA cable
 * ikey ducks out
<zyga-ubuntu> ikey: snappy is the $MESSIAH of packaging
<zyga-ubuntu> endure the pain once
<zyga-ubuntu> bring salvation to everyone
<ikey> oooo idk i think i got you beat there
<zyga-ubuntu> oh
<zyga-ubuntu> shiny
<ikey> whatdat?
<zyga-ubuntu> https://twitter.com/zygoon/status/929997883583160320
<ikey> wow
<ikey> yknow thats systemd speak for "I have no idea what I'm doing anymore, I'm kinda hoping udev is gonna bail me out here"
<zyga-ubuntu> "jinle bells jingle bells, system-s up-to-date"
<zyga-ubuntu> this is the offline update
<ikey> oh what fun it is to write
<zyga-ubuntu> I just never saw it before
<mvo> zyga-ubuntu: hrm, hrm, second test this morning that exceededthe time limit for jobs, maybe we need to do something about it
<zyga-ubuntu> hehe
<ikey> how much you love systemd on void linux forums
<ikey> jingle bells..
<zyga-ubuntu> mvo: maybe we need to bump the number of machines again?
<mup> PR snapd#4201 closed: tests/lib: handle distro specific grub-editenv naming <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4201>
<mvo> zyga-ubuntu: yeah, lets see if it was a fluke, otherwise its a topic for the standup
<zyga-ubuntu> agreed
<mup> PR snapd#4191 closed: cmd/snap-update-ns: do not assume 'nogroup' exists <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4191>
 * ikey goes to bed.. damn timezone switch
<zyga-ubuntu> ikey: o/
<ikey> \o
<zyga-ubuntu> ikey: not in europe anymore?
<ikey> i am
<ikey> 4 years working for a US employer and being on their timezones will permanently screw your internal clock
<zyga-ubuntu> mvo: when do we promote 2.29.3?
<zyga-ubuntu> hmmm
<mvo> zyga-ubuntu: depends on cachio and CE giving us green light
<zyga-ubuntu> 2.27.6 in debian doesn't work very well now
<zyga-ubuntu> (in sid)
<mvo> zyga-ubuntu: but hopefully today or tomorrow
<pstolowski> mvo, hey, #4177 needs your re-review, I think it's very close to land
<mup> PR #4177: state: add change.LaneTasks helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/4177>
<zyga-ubuntu> mvo: debian is broken now
<zyga-ubuntu> mvo: we probably didn't notice because our image is really tracking debian-9
<mwhudson> wow snapd.postrm is lots of fun
<zyga-ubuntu> mwhudson: I just posted about debian on the forum
<zyga-ubuntu> mwhudson: I wonder if it's any better with 2.29.3?
<mwhudson> oh apparmor
<mwhudson> well 2.29 _should_ be better right
<mwhudson> ?
<mwhudson> it has all that graceful apparmor degradation stuff
<mwhudson> i'm a bit surprised because snap-confine was working with apparmor enabled
<zyga-ubuntu> mwhudson: well, not sure, the "graceful" aspect was for apps, not snap-confine
<mwhudson> but i guess a new kernel enforces more rules now?
<zyga-ubuntu> mwhudson: what does it do for you?
<mwhudson> eh i haven't tried it in a while
<zyga-ubuntu> mwhudson: note that this is still 4.13, 4.14 will have more features
<mwhudson> zyga-ubuntu: yes, everyone in the whole world saw the enormous flamewar about that
<zyga-ubuntu> mwhudson: you mean "security and linus" thread or something else?
<mwhudson> i guess i don't mean a flamewar, i mean linus shouting at people yes
<zyga-ubuntu> right, I just wanted to ensure there's nothing _else_ :-)
<zyga-ubuntu> it's not a flamewar when you are being nuked from orbit
<mup> PR snapd#4177 closed: state: add change.LaneTasks helper <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4177>
<pstolowski> mvo, thanks!
<mvo> pstolowski: thank you!
<mwhudson> zyga-ubuntu: yeah i get the same denials
<zyga-ubuntu> mwhudson: thank you for confirming that
<zyga-ubuntu> mwhudson: looks like we need some love there
<mwhudson> zyga-ubuntu: we could go back to the hack that installs an empty /etc/apparmor.d/usr.lib.snapd.snap-confine.real
<mwhudson> but i don't want to
<mup> PR snapd#4208 closed: packaging/arch: do not quote MAKEFLAGS <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4208>
<mup> PR snapd#4152 closed: snapd: fix snap cookie bugs <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4152>
<mwhudson> zyga-ubuntu: the installed file looks like it's trying to grant snap-confine the ability to ptrace things :/
<mwhudson> zyga-ubuntu: is it possible the debian kernel maintainers screwed something up?
<mwhudson> zyga-ubuntu: maybe you can ask jd-strand in a few hours?
<mwhudson> :)
<zyga-ubuntu> mwhudson: I think this is how the old kernel reacts to open /proc/1/ns/mnt
<zyga-ubuntu> mwhudson: I'll try to fix this today
<mvo> zyga-ubuntu: hey, quick question, do you have an opinion about the question here https://github.com/snapcore/snapd/pull/4161#discussion_r149996883 ?
<mup> PR #4161: snapstate: add support for refresh.schedule=managed <Created by mvo5> <https://github.com/snapcore/snapd/pull/4161>
<zyga-ubuntu> looking
<zyga-ubuntu> mvo: replied
<mvo> ta
<mvo> zyga-ubuntu: thanks, I like the reply :)
<zyga-ubuntu> JamieBennett: man, that is one interesting thread
<zyga-ubuntu> thank you for sharing
<JamieBennett> zyga-ubuntu: Indeed, AppArmor on Debian will be great.
<mborzecki> is it possible to update review sprint page withouth niemeyer around?
<zyga-ubuntu> mborzecki: no, I think not
<zyga-ubuntu> AFAIK there's a cron thing that refreshes it
<zyga-ubuntu> but ask gustavo later today
<mborzecki> zyga-ubuntu: did you get a chance to look at? https://github.com/snapcore/snapd/pull/4185#issuecomment-343520761 :)
<mup> PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
<andyrock> hey are snaps mounted always under /snap
<andyrock> ?
<zyga-ubuntu> mborzecki: not yet
<zyga-ubuntu> andyrock: hey
<zyga-ubuntu> andyrock: no, not always
<zyga-ubuntu> andyrock: some distributions don't like that and move the mount point to /var/lib/snap
<zyga-ubuntu> andyrock: however for all snaps that are not using classic confinement, at runtime, the snap will be mounted in /snap/
<andyrock> zyga-ubuntu mmm I'm working on a fix to hide the snap loop devices from gnome-disk-utility
<zyga-ubuntu> andyrock: I see
<zyga-ubuntu> andyrock: we can add a mount option, perhaps, that would say "dont show me"
<zyga-ubuntu> andyrock: but I'm not aware of any
<zyga-ubuntu> andyrock: x-app-container x-snapd.snap, or somthing like that
<zyga-ubuntu> *something
<andyrock> zyga-ubuntu: 'x-app-container x-snapd.snap' didn't get this part
<zyga-ubuntu> andyrock: ah, sorry, there's a trend to annotate mount entries using mount options named x-...
<zyga-ubuntu> andyrock: they don't do anything for the kernel but they are picked up by userspace
<zyga-ubuntu> andyrock: for instance, gnome-disks makes heavy use of this
<zyga-ubuntu> andyrock: allowing the use of specific mount flags to choose how the mount point is represented in the UI
<zyga-ubuntu> andyrock: (icons, labels, show/hide, etc)
<andyrock> oh nice
<andyrock> yeah that would be useful
<andyrock> let me check
<zyga-ubuntu> I was proposing that we simply come up with a "this is not a filesystem users care about" flag
<zyga-ubuntu> maybe there is one we can reuse already, I didn't look
<andyrock> let me ask upstream
<zyga-ubuntu> andyrock: thank you, let me know if there's something we can adapt in snapd to make this easier
 * zyga-ubuntu will soon go AFK to relocate to a different site
<mvo> pedronis: hey, good morning. a quick question, I'm looking at https://github.com/snapcore/snapd/pull/4161#discussion_r149998237 right now (for the refresh.schedule=managed branch) and assertstate is a circular import from snapstate. should I create overlord/assertstate/db and move the ReplaceDB,DB code in there and import from snapstate? (similar to what we did for the iface repo access)?
<mup> PR #4161: snapstate: add support for refresh.schedule=managed <Created by mvo5> <https://github.com/snapcore/snapd/pull/4161>
<popey> zyga-ubuntu: is there a typo in https://forum.snapcraft.io/t/brave-browser-snap-on-14-04-wont-launch/2767/7 ?
<popey> "Arch starts", did you mean the snap starts?
<zyga-ubuntu> popey: yes
<zyga-ubuntu> popey: I'll edit the post with some new data soon, I'm still working on this
<popey> kk
<zyga-ubuntu> popey: question for you, what was the CPU you used?
<popey> it's a vm
<popey> so whatever virtualbox makes available?
<popey> I can cat cpuinfo in the vm if that helps?
<zyga-ubuntu> popey: yes
<zyga-ubuntu> popey: though outside can help too
<popey> added to the thread
<zyga-ubuntu> popey: hmm, you have a much newer CPU than I do
<zyga-ubuntu> popey: so I don't think I'm missing instructions
<zyga-ubuntu> s/I'm/you are/
<pedronis> mvo: I don't know, it's a bit a unclear what belongs where
<zyga-ubuntu> ok I need to get going
<zyga-ubuntu> ttyl
<mvo> pedronis: ok, I ignore it for now while working on a spread test
<mvo> pedronis: we can talk later
<pedronis> mvo: IÂ added a comment to the PR about what IÂ think
<mvo> ta
<niemeyer> mborzecki: That's how it ought to work.. I'm waiting for timer services to get this somewhere else..(wink wink)
<niemeyer> mborzecki: There's also a small issue with not publishing my key in a random machine, but that's easy to solve by creating a user just for that
<niemeyer> mborzecki: It was updated half an hour ago or so, btw
<zyga-ubuntu> re
<zyga-ubuntu> :-)
<niemeyer> Hellos :)
<zyga-ubuntu> niemeyer: hey :)
<zyga-ubuntu> niemeyer: it's raining but I decided not to stay indoors, there's some noise around and it was driving me nuts
<zyga-ubuntu> I'm in a coffee shop nearby, really nice mood with lots of laptop-bearing people
<zyga-ubuntu> I wonder if they are all remote workers like me
<niemeyer> Nice
<niemeyer> I may still build an open-ended co-working place around me some day
<niemeyer> Quite like the idea
<zyga-ubuntu> niemeyer: ara did that back a few years ago
<zyga-ubuntu> niemeyer: she used to run the place for a few years
<niemeyer> Wow, nice.. didn't know that.. would like to have asked her about details
<niemeyer> (in person)
<niemeyer> I've been to places elsewhere that I quite enjoyed for the atmosphere and facilities
<zyga-ubuntu> yeah, I recall she said people matter a lot, I mean having a group of people that want to do this and would be the inhabitants
<zyga-ubuntu> it seems obvious perhaps but the people make it or break it
<zyga-ubuntu> as if just that :)
<zyga-ubuntu> re, had to reboot for my modem suddently died
<zyga-ubuntu> jdstrand: hey
<zyga-ubuntu> jdstrand: I have two questions for you today:
<zyga-ubuntu> jdstrand: first of all, I recall the recent changes to SUBSYSTEM=usb vs SUBSYSTEMS=usb, we did that for some interfaces but not all of them, is this intentional?
<zyga-ubuntu> jdstrand: second question is how do you think we should proceed on debian as sid has recently enabled apparmor by default and the profile for snap-confine no longer works (ironically I think this is related to linus' opinion on breaking userspace)
<zyga-ubuntu> jdstrand: the question is: should we generate an extra snippet for "4.13 vanilla" for snap-confine so that things still work or should we instead alter the profile to be more permissive in general?
<zyga-ubuntu> jdstrand: I'd like to fix this as soon as we can and include it with 2.29.3 update that mwhudson is working on
<ogra_> or fix linus :)
<zyga-ubuntu> ogra_: I'll buy him a mac and a gameboy
<ogra_> haha
<ogra_> i didnt say "bribe"
<zyga-ubuntu> no no, it's just a gift to keep him busy
<zyga-ubuntu> look at this new zelda episode
<ogra_> heh
<zyga-ubuntu> 100 hours of gameplay
<zyga-ubuntu> ;-)
<zyga-ubuntu> use the wiimote to aling the frying pan while you make scrambled eggs in the wilderness
<mup> PR snapcraft#1729 opened: sources: use arfile to extract debs <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1729>
<zyga-ubuntu> sergiusens: oh, going low-level I see
<ogra_> hardcore !
<zyga-ubuntu> sergiusens: did you implement arfile?
<zyga-ubuntu> I had a copy somewhere...
<sergiusens> zyga-ubuntu I reused the one in debian
<sergiusens> zyga-ubuntu the debian python pkg that is
<zyga-ubuntu> ah, it's in debian module nowadays, easy
<zyga-ubuntu> I impemented one in python2.x days for command-not-found
<zyga-ubuntu> (eons ago)
<sergiusens> zyga-ubuntu import DebFile loads up apt_inst for some "$reason" which expects /etc/apt to exist
<zyga-ubuntu> sergiusens: is that package easy to install on !ubuntu?
<sergiusens> zyga-ubuntu according to Son_Goku it is in fedora
<zyga-ubuntu> sergiusens: interesting, cool
<sergiusens> zyga-ubuntu but this is mostly a problem when we run as a snap
<Son_Goku> geez: https://apps.fedoraproject.org/packages/python3-debian
<Son_Goku> it's not even hard to verify
<Son_Goku> you say it as if you don't believe me
 * zyga-ubuntu hugs Son_Goku 
<sergiusens> Son_Goku no, I say it as you being the point of verification ;-)
<ogra_> you didnt bribe him enough ...
<Son_Goku> the problem is that our apt is too old to support python-apt
<zyga-ubuntu> ogra_: but he already has a gameboy :(
<Son_Goku> so python-debian is a bit gimped
<ogra_> zyga-ubuntu, but no mac
<Son_Goku> after all, this is the apt we have: https://apps.fedoraproject.org/packages/apt
<zyga-ubuntu> ogra_: what do you mean, he uses a mac all the time
<ogra_> uh
<zyga-ubuntu> last time I looked at least
<zyga-ubuntu> ogra_: not macos though :)
<sergiusens> I really hope we could get rid of this apt stuff in our code, it is somewhat messy
 * ogra_ sdmittedly didnt pay attention to that 
<sergiusens> but I am not sure we'd do a better job going down our own path
<ogra_> *admittedly
 * ogra_ hands bitbake and meta-debian to sergiusens 
 * sergiusens rejects any offering of more work
<jdstrand> zyga-ubuntu: re SUBSYSTEM vs SUBSYSTEMS> it was all in how we used SUBSYSTEMS. I checked for other wrong uses of it and there were none that I saw. SUBSYSTEMS is a perfectly valid directive with the right usage; where I changed it we were using it wrong. in other words, I don't think there is anything else we need to worry about wrt that
<zyga-ubuntu> jdstrand: thank you for clarifying that
<zyga-ubuntu> CC mvo ^ you asked about that a while ago
<zyga-ubuntu> mvo: tl;dr version is that we're okay and no action is required for 2.29.3
<jdstrand> zyga-ubuntu: I'd like to see the denial for snap-confine to decide
<sergiusens> zyga-ubuntu read you used gnome boxes, does solus work for you on it? I can get through a live session installing, but x doesn't seem to be coming up correctly after the install
<zyga-ubuntu> jdstrand: it's right here: https://forum.snapcraft.io/t/snapd-2-27-6-2-in-debian-sid-blocked-on-apparmor-in-kernel-4-13-0-1/2813/3
<zyga-ubuntu> sergiusens: solus is native for me
<zyga-ubuntu> sergiusens: as for gnome-boxes
<zyga-ubuntu> sergiusens: it's all _rough_, install virt-manager
<zyga-ubuntu> sergiusens: and change display type to virtio (from qlx)
<zyga-ubuntu> sergiusens: then things work better
<zyga-ubuntu> sergiusens: some of my VMs work with qxl (is it qxl or qls) some don't
<zyga-ubuntu> sergiusens: the rest work ok with virtio
<zyga-ubuntu> sergiusens: it's a hit/miss, sometimes switching virtual VTs around helps
<zyga-ubuntu> sergiusens: but in general nothing I tried failed when I used the fallback
<zyga-ubuntu> sergiusens: I use it for a range of systems now, having abandoned vmware
<jdstrand> zyga-ubuntu: I'm puzzled why snap-confine is ptracing itself
<zyga-ubuntu> sergiusens: vmware was much more mature if you are on windows or on older LTS
<zyga-ubuntu> jdstrand: it's not, this is, IMO, the open/stat on /proc/1/ns/mnt
<zyga-ubuntu> jdstrand: I recall seeing this
<zyga-ubuntu> jdstrand: as we were implemeting the feature
<jdstrand> no, it is
<zyga-ubuntu> jdstrand: of breaking out of snap ns
<jdstrand> there are different things about ptrace, but it is doing 'trace' and 'tracedby'
<jdstrand> ptrace read/readby I might've expected
<zyga-ubuntu> jdstrand: it's also doing that on /proc/self/ns/mnt
<zyga-ubuntu> jdstrand: so maybe _that_ is causing itt?
<mborzecki> + echo 'ERROR: test-snapd-requires-base should not be installable without test-snapd-base'
<mborzecki> ERROR: test-snapd-requires-base should not be installable without test-snapd-base
<zyga-ubuntu> jdstrand: in general it's trivial to reproduce, sid just always triggers it now and any snap is good to test
<mborzecki> expected?? ^
<zyga-ubuntu> mborzecki: probably no, mvo's topic I think
<jdstrand> it might be that the kernel reorganized things to group that open/stat into tracec/tracedby
<jdstrand> zyga-ubuntu: this says it is with 2.27.6. what about a modern snap-confine?
<zyga-ubuntu> jdstrand: interestingly it's 4.13 bit without out-of-tree apparmor patch
<zyga-ubuntu> jdstrand: same
<zyga-ubuntu> jdstrand: mwhudson confirmed that shortly after I reported it
<zyga-ubuntu> (on IRC)
<zyga-ubuntu> s/bit/but/
<zyga-ubuntu> jdstrand: so "same as ubuntu exept for patch" ~~ mostly
<jdstrand> zyga-ubuntu: I think we should have Tyler or jj weigh in. they would probably be able to comment better on the missing out of tree patches
<zyga-ubuntu> jdstrand: ack, I'll look out for them
<zyga-ubuntu> jdstrand: I'd like to fix this as it will affect every distribution that is on the same kernel and pulls in apparmor
<ogra_> andyrock, did you consider hiding the snap loop mounts on a lower level ... i.e. udev ... like it does for vendor recovery partitions etc in /lib/udev/rules.d/80-udisks2.rules
<zyga-ubuntu> jdstrand: jjohansen ^^ can you please comemnt on https://forum.snapcraft.io/t/snapd-2-27-6-2-in-debian-sid-blocked-on-apparmor-in-kernel-4-13-0-1/2813 -- the context is that debian is now shipping apparmor and enabled by default and we are seeing some unexpected denials on their stock 4.13 kernel; we are looking for possible solutions to overcome the problem but would like your insight into what may
<jdstrand> zyga-ubuntu: is it not using mount-namespace-capture-helper for some reason?
<zyga-ubuntu> be causing the trace/tracedby mediation there
<zyga-ubuntu> jdstrand: it definitely does that but that's later
<zyga-ubuntu> jdstrand: this stage is before we even fork, to see if we are in the right ns
<jdstrand> zyga-ubuntu: we have 'ptrace trace peer=unconfined,' for that now
<zyga-ubuntu> jdstrand: is the peer confined if we are tracing ourselves?
<jdstrand>     # allow snap-confine to read /proc/1/ns/mnt
<jdstrand>     ptrace trace peer=unconfined,
<zyga-ubuntu> I mean, snap-confine does look at itself then
<zyga-ubuntu> (after looking at PID 1)
<jdstrand> zyga-ubuntu: the peer is us if we are ptracing ourselves, so, yes
<zyga-ubuntu> jdstrand: so ptrace trace peer=$LIBEXECDIR/snapd/snap-confine,
<zyga-ubuntu> ?
<jdstrand> the rule would be:
<jdstrand> ptrace (trace, tracedby) peer=$LIBEXECDIR/snapd/snap-confine,
<zyga-ubuntu> I'll test that
<jdstrand> but why doesn't Ubuntu need the patch if that has always been the case?
<zyga-ubuntu> it looks like something to go into the regular profile
<zyga-ubuntu> yes, I was wondering that myself
<zyga-ubuntu> I was about to ask
<zyga-ubuntu> can we see via --some-magic-option
<zyga-ubuntu> when apparmor_parser says, yeah fine but not understood/implemented so I'll skip this rule
<zyga-ubuntu> this question came up in the debian thread
<jdstrand> I don't know, we need jjohansen to comment now I think. 4.13 and Ubuntu shouldn't be acting differently in this regard I don't think. there seems to be a bug somewhere
<zyga-ubuntu> and I was wondering if you know if that's accurate enough to find bugs in our profile
<jdstrand> zyga-ubuntu: oh
<zyga-ubuntu> jdstrand: yes, looks like so
<jdstrand> zyga-ubuntu: so on Debian with 4.13, the ptrace rule is not recognized?
<jdstrand> zyga-ubuntu: by the parser?
<zyga-ubuntu> jdstrand: not sure, I didn't try as I found about that that in the opposite order
<zyga-ubuntu> jdstrand: I found the bug and then read on the thread that jamie bennett linked to
<zyga-ubuntu> jdstrand: I just made the connection now recalling this
<jdstrand> zyga-ubuntu: I didn't read all of your comment. there is no option like that, no
<zyga-ubuntu> (my ram is a bit used up by 16.04/lxd experiment but I can try shortly)
<zyga-ubuntu> jdstrand: I see
<jdstrand> what the parser does is look at the sysfs and makes decisions. you could mock up a sysfs without the ptrace rule if you wanted, but I'm not sure why that is interesting for this
<zyga-ubuntu> jdstrand: I'll look around, I have two more debugging runs to do
<zyga-ubuntu> jdstrand: lxd is top priority for now
<zyga-ubuntu> jdstrand: then weird works on 16.04, breaks on 14.04 for strict snap
<zyga-ubuntu> jdstrand: btw, as we are talking, I could use your review on https://github.com/snapcore/snapd/pull/4163
<mup> PR #4163: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <https://github.com/snapcore/snapd/pull/4163>
<zyga-ubuntu> jdstrand: it's just a re-factor but I wanted to make sure you ack it
<zyga-ubuntu> jdstrand: I need it to build other features on top
<zyga-ubuntu> (not a refactor just for the sake of it)
<zyga-ubuntu> it has two +1s alredy
<jdstrand> zyga-ubuntu: yes, this is the one from last week that is at the top of my list
<zyga-ubuntu> jdstrand: thank you
<zyga-ubuntu> jdstrand: I commented on the debian thread and I'll look into it again today to verify if the extra rule makes things work
<andyrock> ogra_: UDISKS_IGNORE is ignored by gnome-disk-utilities
<ogra_> andyrock, uuh, why is that ?
<andyrock> it makes sense
<andyrock> UDISKS_IGNORE is used on a bunch of partitions
<ogra_> to be able to wipe something essential ?
<zyga-ubuntu> andyrock: is that a variable we have the udev tag it with
<zyga-ubuntu> andyrock: or something we can set in the mount option?
<jdstrand> jjohansen: to summarize backscroll, see https://forum.snapcraft.io/t/snapd-2-27-6-2-in-debian-sid-blocked-on-apparmor-in-kernel-4-13-0-1/2813/3
<jdstrand> jjohansen: a ptrace rule is popping out in vanilla 4.13 on Debian and not on Ubuntu 4.13 on Ubuntu
<andyrock> ogra_: UDISKS_IGNORE is used e.g. on windows recovery partitions
<andyrock> and other partitions that should be shown
<ogra_> zyga-ubuntu, Ã®t is used by udisks2 to actually hide something like "dell recovery" and other super essential vendor stuff ... take a look at the bottom of  /lib/udev/rules.d/80-udisks2.rules
<andyrock> I tried to propose this solution upstream but they will not accept it
<zyga-ubuntu> ogra_: that's ok, we can piggy back on this
<zyga-ubuntu> andyrock: what did upstream say?
<ogra_> zyga-ubuntu, right, that was my suggestion
<andyrock> zyga-ubuntu: upstream is ok with a x-gdu-hide/ignore whatever option
<ogra_> zyga-ubuntu, its a pretty common mechanism, but if gnome-disk-utilities ignores it it wont help much
<zyga-ubuntu> andyrock: is one supported now?
<zyga-ubuntu> andyrock: or is that something we need to implement and send upstream
<andyrock> nope but I can implement and send without problem
<andyrock> that's what they told
<zyga-ubuntu> andyrock: that's great
<zyga-ubuntu> andyrock: please document this on the forum, we need to do something to mount units anyway and that fits in nicely
 * ogra_ would still do it on a udev level instead of a mount option ... the latter smells slightly hackish
<ogra_> i.e. introdusce a new udev variable and make that one actually accepted by gnome-disk-utilities
<andyrock> ogra_: how do you specify that at udev level?
<ogra_> via a rules file that snapd can ship then
<andyrock> like how do you are sure that what you're hiding is actually a snap partitions
<andyrock> *partition
<andyrock> for what I know you can just say
<andyrock> ok if it's a loop device and it's a squashfs
<andyrock> than hide it
<andyrock> but there is no other way to say, if the mount point is in /snap
<ogra_> KERNEL "loop" ... then check for filesystem and for /var/lib/snap in the source mount
<ogra_> and ignore the target
<ogra_> not all distros use /snap
<andyrock> is the source mount available?
<ogra_> i guess there is an attribute with the path somewhere ...
<andyrock> just monitoring the events I was not able to find it
<ogra_> there is ENV{ID_FS_TYPE} ... so i guess there is also a path somewhere
<andyrock> https://www.irccloud.com/pastebin/HFhhonyX/
<andyrock> e.g. this is what I get
<ogra_> hmm, funny, it actually sets UDISKS_IGNORE=1
<ogra_> you could build on top of that ...
<ogra_> if "UDISKS_IGNORE=1" and "loop" and "squashfs" it is most likely a snap ... so set "GDISKS_IGNORE=1" and have gnome-disk-utilities catch that
<ogra_> or if you want it really exact you wrap in a script ... like:
<ogra_> ogra@styx:~$ losetup -l /dev/loop4 -n -O BACK-FILE
<ogra_> /var/lib/snapd/snaps/core_2898.snap
<ogra_> (to wrap a script into the udev rule you use: IMPORT{program} "/bin/sh -c 'losetup -l ENV{DEVANME} -n -O BACK-FILE'" or some such )
<andyrock> ogra_: it sets that because I had a rule to do that\
<ogra_> ah
<ogra_> well, then go without it
<andyrock> but I want that upstream
<ogra_> why ? it is a snapd thing ... so have snapd ship a rule that sets your var
<ogra_> all you need upstream is to have gnome-disk-utilities use that var to ignore the mounts
<andyrock> sorry I didn't read everthing
<andyrock> reading now
<zyga-ubuntu> koza: bluetooth still doesn't let me switch to a2dp
<zyga-ubuntu> koza: on artful
<ogra_> zyga-ubuntu, use wried speakers ... better quality anyway :P
<zyga-ubuntu> ogra_: one less cable while on the go
<zyga-ubuntu> ogra_: and being a gunea pig helps others :)
<zyga-ubuntu> ogra_: not everyone knows a BT developer
<koza> zyga-ubuntu, i know, still remember about this one. it is in the queue just after the commercial related things
<zyga-ubuntu> koza: AFAIK you said it should work, it's just the default is wrong
<zyga-ubuntu> if this is still expected unfixed then no news :)
<koza> zyga-ubuntu, it should not crash, this was fixed last time
<zyga-ubuntu> koza: it doesn't crash, just doesn't switch
<koza> zyga-ubuntu, it will however mess the hsp/a2dp things
<zyga-ubuntu> aha
<zyga-ubuntu> ok
<zyga-ubuntu> :-)
<koza> zyga-ubuntu, this is still being worked on, hopefully PA 11 will land in bionic which should improve things
<zyga-ubuntu> koza: I'll gladly switch when that is there
<koza> anyways regardless of the PA version in bionic this one will be tackled as well
<ogra_> FWIW https://forum.snapcraft.io/t/connecting-bluetooth-audio-devices-pulseaudio-bluez/2669
<ogra_> (we recently landed the PA changes)
<ogra_> (but that wont help with the general issue of messing hsp/a2dp ... only with the pulse snap using BT audio in general)
 * zyga-ubuntu heads back home, see you shortly
<mborzecki> zyga-ubuntu: pushed a commit to https://github.com/snapcore/snapd/pull/4185 hopefully this will resolve the concerns of stat()ing /etc/shadow frequently
<mup> PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
<zyga-ubuntu> mborzecki: sure, I'll look now
<zyga-ubuntu> pstolowski: two unanswered questions on https://github.com/snapcore/snapd/pull/4108#discussion_r150541232
<mup> PR #4108: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108>
<mborzecki> i'm leaving to pick up my kids and then on to a 3h drive to wroclaw
<pstolowski> zyga-ubuntu, sorry, meant to answer those and forgot. doing
<zyga-ubuntu> mborzecki: commented on 4185 now
<mup> PR snapd#4173 closed: corecfg: validate refresh.schedule when it is applied <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4173>
<sergiusens> elopio you around ?
<mup> PR snapd#4209 closed: run-checks, tests/lib/snaps/: shellcheck fixes <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4209>
<elopio> sergiusens: I'm here
<sergiusens> zyga-ubuntu btw, I edited '.config/libvirt/qemu/snapshot/boxes-unknown' andchanged te value from qqxl to virtio in the xml i there and got it going.. my machine crawling now though (I canoot see what I am typing at the moment ;-) )
<sergiusens> elopio snapcraft#1717, mind just making the change yourself wrt location?
<mup> PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717>
<elopio> sergiusens: sure
<sergiusens> elopio also, any update on that ruby issue?
<elopio> sergiusens: oh no, this needs the bigger refactor. Otherwise adding a catkin plugin to the plugins suite can get us back to timing out.
<elopio> that's why kyrofa and I haven't moved it.
<elopio> sergiusens: for ruby I'm setting up my rpi. The permission error doesn't make any sense to me.
<elopio> it worked on arm64 on the dragonboard, so it's not likely that we don't support the arch.
<zyga-ubuntu> elopio: what issue are you seeing?
<zyga-ubuntu> ikey: hey, can you please "make fmt" in https://github.com/snapcore/snapd/pull/4207
<mup> PR #4207: Flesh out NVIDIA support for biarch and multiarch systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4207>
<sergiusens> elopio snapcraft#1729 could use a peek as well
<mup> PR snapcraft#1729: sources: use arfile to extract debs <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1729>
<sergiusens> elopio oh, your comment was somewhat loosely phrased then
<elopio> zyga-ubuntu: http://paste.ubuntu.com/25954649/
<sergiusens> snappy-m-o autopkgtest 1717 xenial:armhf artful:amd64
<snappy-m-o> sergiusens: I've just triggered your test.
<zyga-ubuntu> elopio: where is this running?
<zyga-ubuntu> elopio: do you see any apparmor denials?
<elopio> zyga-ubuntu: it's running on autopkgtest infrastructure, armhf. It's running the snapcraft deb, so I would expect no denials, but I could make a branch to collect more information.
<zyga-ubuntu> elopio: didn't we recently changed how those run?
<zyga-ubuntu> elopio: perhaps cjwatson knows more
<zyga-ubuntu> elopio: please try to collect apparmor denials if you can
<mup> Issue snapcraft#1448 closed: snapcraft build using manifest.yaml <design-required> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1448>
<mup> Issue snapcraft#1628 closed: record lxc image used <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1628>
<mup> PR snapcraft#1633 closed:  recording: record information from the image in container builds  <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1633>
<cjwatson> zyga-ubuntu: autopkgtests aren't me.  Try Laney
<cjwatson> elopio: ^-
<pstolowski> damn, my spread test issue with service restarts tasks taking too long is fixed with st.EnsureBefore(0) after all..
<sergiusens> zyga-ubuntu also, why do you assume apparmor? :-)
<zyga-ubuntu> cjwatson: thank you!
<zyga-ubuntu> sergiusens: permission denied is now engraved in my mind
<sergiusens> zyga-ubuntu I think this is a much more mundane error related to gems and lack of testing on arm
<zyga-ubuntu> wow, so I'm on 17.10
<zyga-ubuntu> and I don't have $DISPLAY set
<zyga-ubuntu> no qemu sdl
<zyga-ubuntu> wow, that's a new thing for me
<jdstrand> sergiusens: I'm curious if maybe something started as root and then later accessed as the user
<jdstrand> elopio: ^
<jdstrand> just putting it out there-- I have no particular insight (just sorta looks like that)
 * zyga-ubuntu -> dinner
<sergiusens> jdstrand yeah, maybe; but I would suspect it would affect amd64 as well unless we have quirked the system and put ourselves into a corner
<pstolowski> pedronis, zyga addressed your comment to 4163, I think it can land
<pedronis> pstolowski: fine by me
<andyrock> SUBSYSTEM=="block", KERNEL=="loop*", IMPORT{program}="/bin/sh -c '/sbin/losetup -l $env{DEVNAME} -n -O BACK-FILE | /bin/grep -c ^/var/lib/snapd/snaps/ | /bin/sed s/.*/GDISKS_IGNORE=\\0/'"
<andyrock> ogra_: ^^^ this is the only way I found to make it work
<andyrock> there are several limitations with udev rules
<zyga-ubuntu> andyrock: note that we can generate some rules from snapd itself
<mup> PR snapd#4163 closed: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4163>
<zyga-ubuntu> andyrock: and ideally we could do something at systemd.mount level
<ogra_> yeah
<ogra_> but good to see that it is possible even with that slightly hackish approach
<zyga-ubuntu> pstolowski: jdstrand wanted to review that but that's not a big problem, I'll wait for the review and address anything that may come up
<pstolowski> zyga-ubuntu, arghh, a second too late
<andyrock> zyga-ubuntu: I don't mind how the rule is generated :D
<andyrock> just that can be generated
<pstolowski> zyga-ubuntu, just landed this and 4166
<mup> PR snapd#4166 closed: cmd/snap-update-ns: detect and report read-only filesystems <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4166>
<pstolowski> zyga-ubuntu, sorry
<ogra_> zyga-ubuntu, i wonder if just adding an environment stanza to the systemd.mount unit would do (udev might just pick it up so you could check for the var in the env then)
<zyga-ubuntu> pstolowski: no worries :)
<zyga-ubuntu> pstolowski: thank you, no worries :)
<ogra_> (there must be some advantage of the close systemd and udev integration )
<zyga-ubuntu> ogra_: worth a try :)
<pstolowski> 1 PR left to get down to 1 page ;)
<zyga-ubuntu> ogra_: yeah, bugs go to the same person ;)
<ogra_> lol
<andyrock> ogra_: zyga-ubuntu let me give it a try
<mup> PR snapd#4205 closed: add spread test for allocating TUN/TAP devices with network-control <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4205>
<zyga-ubuntu> pstolowski: btw, https://github.com/snapcore/snapd/pull/4169 is a nicer and shorter diff to review now
<mup> PR #4169: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <https://github.com/snapcore/snapd/pull/4169>
<pstolowski> zyga-ubuntu, great, will take a look
<zyga-ubuntu> pstolowski: thank you
<mup> PR core#63 closed: 25-create-generic-initrd.chroot: use symlink instead of copy <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/63>
<andyrock> ogra_,zyga-ubuntu if  you want to use sytemd.mount at this point is better to use the mount options
<andyrock> mount options can be easily retrieved using udisk2
<zyga-ubuntu> andyrock: yep, I agree
<andyrock> are  /etc/systemd/system/snap*.mount generated or what?
<zyga-ubuntu> andyrock: yes
<zyga-ubuntu> andyrock: well, "generated" not via systemd-generate or anyrthing
<zyga-ubuntu> andyrock: snapd manintains those
<andyrock> kk
<niemeyer> sergiusens: Heya
<niemeyer> sergiusens: Curious about two updates:
<niemeyer> sergiusens: The clean behavior improvements
<niemeyer> sergiusens: and the interpreter fix for classic snaps
<niemeyer> sergiusens: How're those going?
<zyga-ubuntu> wow, PRs fit one one page :D
<zyga-ubuntu> just a little more and we'll be under 20 :D
<niemeyer> And I'm still way behind
<zyga-ubuntu> niemeyer: but we have interesting rsync /snap posts that saw some eye-opening comments :)
<niemeyer> zyga-ubuntu: I wonder how to make that more clear, or at least more well known
<niemeyer> zyga-ubuntu: I've seen multiple people going from disappointment to awe just by being enlightened about that point
<zyga-ubuntu> niemeyer: yeah, I was thinking if there's a way for rsync to say "OMG multiple filesystems" and bail out or something
<niemeyer> zyga-ubuntu: Well, we won't be able to touch rsync or du which are the tools people normally use for that
<niemeyer> zyga-ubuntu: Not in a way that solves the perception problem
<zyga-ubuntu> niemeyer: /snap/bin/du ;-)
<zyga-ubuntu> just sayn ';-)
<zyga-ubuntu> niemeyer: I think it's a problem of doing something new and finding that people are not familiar with the concept
<zyga-ubuntu> niemeyer: hard to say if there's a technical solution
<niemeyer> zyga-ubuntu: Perhaps a /snap/NO_THAT_SPACE_IS_NOT_BEING_CONSUMED as a text file
<zyga-ubuntu> actually
<zyga-ubuntu> /snap/README.txt could go a very long way
<zyga-ubuntu> it could have a paragraph of text in 5 most popular language and a forum link
<niemeyer> Or /snap/DISK-SPACE
<niemeyer> zyga-ubuntu: But yeah, /snap/README is likely more friendly
<zyga-ubuntu> niemeyer: something we could manage and update over time, not packaged I assume
<niemeyer> zyga-ubuntu: Yes, synched on snapd runs
<zyga-ubuntu> right
<zyga-ubuntu> niemeyer: I may just do that quickly
<zyga-ubuntu> niemeyer: I'm bored by reviews and it's late
<niemeyer> zyga-ubuntu: +1
<niemeyer> sergiusens I promise to send you a cake if the clean "High priority" bug becomes two years old
<niemeyer> sergiusens: Actually, I'll deliver it personally in the next sprint
<zyga-ubuntu> niemeyer: the cake is a lie
<zyga-ubuntu> niemeyer: but I want pics if you do
<niemeyer> zyga-ubuntu: A lie?
<kyrofa> niemeyer, you've never played Portal?
<kyrofa> I'm disappointed in you
<niemeyer> kyrofa: Oh, I did.. but way too long ago
<kyrofa> Hahaha
<niemeyer> kyrofa: I didn't play the sequel, though
<niemeyer> Is it any good?
<ogra_> https://www.gnu.org/software/guix/
<ogra_> hmmm
<zyga-ubuntu> niemeyer: it's very very good
<zyga-ubuntu> niemeyer: if you have debian commit access you can get a copy for free
<kyrofa> They're both great, although I only ever did the coop version (of both), not sure if it's different
<ogra_> "in addition to standard package management features, supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and more."
<zyga-ubuntu> niemeyer: valve use do thave a promo for all debian developers and maintainers
<niemeyer> ogra_: Gnu luck
<niemeyer> I mean.. good luck
<ogra_> heh
<zyga-ubuntu> lol
 * ogra_ only just stumbled over it 
<zyga-ubuntu> This is GNU luck, there is no warranty
<zyga-ubuntu> so meta
<ogra_> stallman snaps ....
<ogra_> stall-snaps
<ogra_> or is it flat-stall
<niemeyer> snap stall
<niemeyer> OMG, we should have an alias
<ogra_> lol
<niemeyer> snap stall --man
<ogra_> is that the long version of "snap rms" ?
<sergiusens> niemeyer the clean bug has many subtasks hidden in comments, the just clean dependent parts that need cleaning is done; the re-pull and un-pull stuff has not started
<zyga-ubuntu> niemeyer: I can smell the LWN article already
<zyga-ubuntu> niemeyer: ubuntu taunts the father of free software with snapd, tied to proprietary store ;-)
<sergiusens> niemeyer interpreter fix should be on track, but I cannot provide tangible updates as we are still trying to cut a release
<zyga-ubuntu> and OMG SKY IS FALLING
<niemeyer> sergiusens: It's going to be two years soon.. it's really time to tackle it
<mup> PR snapcraft#1722 closed: unit tests: reset log level after test <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1722>
<niemeyer> sergiusens: Being able to clean a cache is a fundamental part of any cache implementation
<ogra_> you mean over print("buy bigger disk !!!") ?
<niemeyer> sergiusens: We need to look for the intuitive behavior in those areas
<niemeyer> sergiusens: We should probably not even do "rebuild"
<niemeyer> sergiusens: The intuitive action is simply to do the action in the first place
<niemeyer> sergiusens: So "snapcraft pull foobar" should pull it
<niemeyer> sergiusens: Cached or not
<niemeyer> sergiusens: We're all used to the warts, but I regularly see people stumbling upon just making things work at all, which is a typical issue with caching that is on the way
<niemeyer> Was reminded of that again by https://forum.snapcraft.io/t/use-of-home-and-network-plugs/2587/33
<sergiusens> niemeyer so `snapcraft pull` would basically redo and leave you in that state? I thought the bigger problem was local sources changing and running `snapcraft` with no specific target which is another task we are working on
<sergiusens> but working on this will put us behind on some roadmap items
<niemeyer> sergiusens: Note that initially the poster apparently had no idea that there was even caching involved.. the report is "snapcraft refuses to work"
<niemeyer> sergiusens: Yes, snapcraft would basically do what is on the label
<niemeyer> sergiusens: pull pulls
<niemeyer> sergiusens: build builds
<niemeyer> sergiusens: If you want caching of step X then don't ask to run step X
<niemeyer> sergiusens: Right now we're harshly responding "Nope!" when asked to do a step
<sergiusens> ok, I'll update you next week on the progress of that item
<niemeyer> sergiusens: Thanks, and sorry for the joke.. we should really just fix this
 * sergiusens starts making his way to physiotherapy
<sergiusens> niemeyer no worries
<kyrofa> elopio, talk to me about adt. I see pexpect timeouts on armhf and arm64 on the beta PR. Were you able to reproduce the Ruby issues there?
<kyrofa> Should I fire up my rpi?
<sergiusens> kyrofa yes!
<kyrofa> sergiusens, you were able to reproduce them?
<sergiusens> no, I was focusing on other items ;-)
<kyrofa> Okay, I'll try to reproduce
<elopio> kyrofa: yes please, my sd cards make everything hard.
<elopio> kyrofa: I ran in dragonboard with no issues.
 * ikey has mental image of a DBZ surfboard
<kyrofa> I'm flashing now
 * ogra_ shades his eyes
 * zyga-ubuntu implemented the readme thing, waiting for spread 
<kyrofa> Hmm... it seems snapd isn't running on my newly flashed rpi. I can't create an initial user as a result
<kyrofa> I'll try rebooting
<kyrofa> Huh. Still no luck
<kyrofa> zyga-ubuntu, did you make any headway with the lxd issue?
<kyrofa> Last I heard, you thought you had a solution, but it didn't work?
<zyga-ubuntu> kyrofa: yes, but I had some network issues that wreaked havoc in my iteration
<zyga-ubuntu> kyrofa: I tried and failed with two approaches
<zyga-ubuntu> kyrofa: and I got a 3rd one going that is likely to work
<zyga-ubuntu> kyrofa: stay tuned, I'm still working on this
<kyrofa> zyga-ubuntu, alright, any sort of estimated timeline?
<zyga-ubuntu> kyrofa: I'll tell you tomorrow
<zyga-ubuntu> kyrofa: if it works it's in 2.30
<kyrofa> Alright, thanks zyga-ubuntu :)
<ikey> uploaded some new LSI images which should have compatibility with ubuntu nvidia libraries now..
<ikey> we were missing `pthread_setname_np`@GLIBC_2.0 ...
<ikey> ABI. fun and games. :D
<zyga-ubuntu> ikey: this project of yours is such a fantastic learning experience for me
<ikey> oh and me
<ikey> finding all those weird corner cases
<ikey> does show how malleable linux can be though
<ikey> (with the right hammer)
<ikey> ive dropped the vendored glibc ABI version to 3.2.0 which should be compatible with ubuntu now
<zyga-ubuntu> ikey: you just need a couple of kilos of unobtanium
<zyga-ubuntu> aka documentation
<ikey> lol yea
<ikey> for the whole "how to create a snap" bit or the lsi bit or all of it?
<ikey> s/snap/base snap.
<ikey> gdi keyboard
<zyga-ubuntu> for the low level libc and linker magic mostly
<ikey> aah abusing glibc for fun and profit
<ikey> fwiw i tried to create a rudimentary LD_AUDIT module a few months back (or more) and it failed miserably
<ikey> this is the 2nd time doing it
<zyga-ubuntu> niemeyer: https://github.com/snapcore/snapd/pull/4210
<mup> PR #4210: many: add magic /snap/README file <Created by zyga> <https://github.com/snapcore/snapd/pull/4210>
<zyga-ubuntu> niemeyer: just a RFC
<zyga-ubuntu> :-)
<mup> PR snapd#4210 opened: many: add magic /snap/README file <Created by zyga> <https://github.com/snapcore/snapd/pull/4210>
<niemeyer> Looking
<zyga-ubu1tu> niemeyer: the text is mostly a placeholder, please wordsmith
<zyga-ubu1tu> niemeyer: there's also a forum link there that needs smilar treatment
<kyrofa> elopio, while this is going, are there other failures I can help look into?
<niemeyer> zyga-ubu1tu: Check it out
<kyrofa> elopio, all the other arm adt results seem to be pexpect timeouts
<kyrofa> Should I propose bumping them up?
<zyga-ubu1tu> niemeyer: I think there's some issue on github, your text is empty
<zyga-ubu1tu> niemeyer: now it's there, reading
<niemeyer> zyga-ubu1tu: No, there'a an issue with Gustavo
<zyga-ubu1tu> I'll update the text
<niemeyer> I can't believe the day is going by that fast..
<niemeyer> Can I get some extra hours please?
<kyrofa> sergiusens, elopio alright, I'm able to duplicate here. Looking at it now
<kyrofa> Kinda slow going, obviously :P
<sergiusens> kyrofa question is. Did it ever work? If not I would expect failure on the test and carry on if it becomes too time consuming
<kyrofa> sergiusens, given the error, I doubt it. Want me to just expect failure, then?
<kyrofa> sergiusens, I think I know what the problem is
<kyrofa> Should be an easy fix. I'll try it, but keep an eye on the time. If things don't work out, I'll expect
<kyrofa> (failure)
<zyga-ubu1tu> niemeyer: tell me that
<zyga-ubu1tu> niemeyer: it's alreday DARK outside for about 5 hours
<zyga-ubu1tu> niemeyer: days run out faster than time at a roller-coaster
<kyrofa> Reminds me when I used to work in a windowless lab during the winter. I left home when it was dark, and left the lab when it was dark
<zyga-ubu1tu> kyrofa: welcome to the submarine
<kyrofa> No kidding
<ikey> https://www.youtube.com/watch?v=3m3JfmExzsQ
<ikey> xD
<zyga-ubuntu> ok
<zyga-ubuntu> so I need someone who speaks Mandarin or Spanish
<zyga-ubuntu> to translate a tiny snippet of text :)
<genii> Maybe someone in #ubuntu-locoteams or #ubuntu-cn would
<sergiusens> kyrofa so what is the suspicion?
<kyrofa> sergiusens, ruby has a super convoluted arch detection when it comes to generating its arch-specific libdirs
<kyrofa> sergiusens, and the pattern is inconsistent depending on arch
<kyrofa> So we're not setting up the RUBYLIB correctly on arm
<kyrofa> thus it can't find files
<sergiusens> kyrofa hah, so it probably never worked on $arch ;-)
<kyrofa> Indeed
<kyrofa> Probably only amd64 and i386
<kyrofa> Which means we haven't run adt on those archs since ruby landed... ages ago
 * genii ponders aarch64 vs arm64
<sergiusens> kyrofa we probably have, no one was looking ;-)
<sergiusens> kyrofa can I get a veridict on #1729 ?
<mup> PR #1729: tests: spread all-snap test cleanup <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1729>
<sergiusens> the snapcraft one though
<sergiusens> :-)
<kyrofa> sergiusens, yeah, I just need to actually test it, it's next
<kyrofa> Code looks good, though
<sergiusens> tell you what, I'll make it easy. Hey ikey do you still get a crash if you `snap refresh snapcraft --channel stable/pr-1729`? I don't on solus, but triple confirmation is always better :-)
<ikey> omg --help works
<ikey> ..big help xD
<ikey> ty!
<mwhudson> morning
<sergiusens> ikey thanks for corroborating; turns out running `import debian.debfile` causes that as it loads apt_inst which expects /etc/apt to exist (I might be repeating myself here, sorry if I am)
<mup> PR snapcraft#1730 opened: ruby plugin: be smarter about arch-specific paths <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1730>
<kyrofa> elopio, I just got the ""GET /v2/snaps HTTP/1.1" 200 79" failure again
<kyrofa> sergiusens, elopio ^ that however should fix the ruby issues no arm
<kyrofa> s/no/on/
<kyrofa> snappy-m-o, autopkgtest 1730 xenial:armhf
<snappy-m-o> kyrofa: I've just triggered your test.
<ikey> sergiusens, oh cool
<ikey> sorry was afk there for podcast cruft
<sergiusens> okey sad that to use the logic to extract an ar archive one would need the full apt machinery by default
<sergiusens> Oops autocorrect
<elopio> kyrofa: did you get the "GET" print on the same test?
<sergiusens> kyrofa what do libdirs look like on armhf and arm64?
<kyrofa> sergiusens, lib/ruby/2.4.0/armv7l-linux-eabihf, on amd64 it's lib/ruby/2.4.0/x86_64-linux
<kyrofa> sergiusens, so we made the assumption it was <machine>-<linux> but it's not. I dug into Ruby's autotools stuff and it's... yucky
<kyrofa> sergiusens, not sure what it is on arm64, but elopio said it worked
<kyrofa> So I'm guessing aarch64-linux
<kyrofa> elopio, snapcraft.tests.test_lifecycle.ExecutionTestCase.test_dependency_recursed_correctly
<kyrofa> elopio, I'm having trouble remember which one it was last time, but I know it was in the lifecycle tests
<elopio> kyrofa: yes, that's the same one. :/ Maybe we should try your fix, but I'm still not understanding what's going on.
<kyrofa> Me neither :(
<elopio> my experiment with the nuke argument was not successful, because by default we are nuking.
<kyrofa> I rebased on top of my fix and it's running fine now, though
<kyrofa> If I'm the only one hitting it I can continue to do that
<elopio> it's working for me, but might be luck.
<kyrofa> elopio, are there any other known issues that I could be looking at? All the arm failures I see are pexpect timeouts, so I don't know what the current issues are
<ikey> is snapd forcing a host os-release into the snap?
<gsilvapt> Any tips on finding the needed files to implement a change suggested in LP? For instance, https://bugs.launchpad.net/snapcraft/+bug/1590349. How do I know (as an outsider and unfamiliar person to the project) where this section lives?
<mup> Bug #1590349: snapcraft should have a 'version' command <bitesize> <ui> <Snapcraft:Triaged> <https://launchpad.net/bugs/1590349>
<kyrofa> elopio, ever seen this before? https://pastebin.ubuntu.com/25957073/
<kyrofa> We tease out all sorts of fun things running in lxc
<kyrofa> Hey there gsilvapt
<gsilvapt> hi kyrofa
<kyrofa> gsilvapt, really the only way to determine where things are is to start hacking on things until you get a good idea of it, haha
<kyrofa> gsilvapt, or ask one of us to point you in the right direction until you get enough experience with the codebase to know
<gsilvapt> Hum, I figured that could be a possibility. It's just that I feel lost looking at any code base like this and I thought there could be some pro tips I could ask for from you guys
<kyrofa> gsilvapt, for that one, start with the snapcraft/cli package
<kyrofa> gsilvapt, yeah anyone feels lots on a new large project, don't feel overwhelmed. Typically I start by grepping for a string I know if part of the problem, then tracing around in the code from there
<gsilvapt> Are you telling just from experience or are there any pointers right out of the box?
<kyrofa> gsilvapt, I just gave you one. Here's the flow I'd take for that particular issue
<kyrofa> $ grep -r "\-\-version" *
<gsilvapt> Ok, lets try figuring out where is that package
<kyrofa> That will return several things, one of which is an entry in the changelog. Interesting!
<kyrofa> So let's look for that string in `git log`
<kyrofa> That leads us to commit be4a92ad709e98975301a19a15025154bd10d8b2
<kyrofa> `git show be4a92ad709e98975301a19a15025154bd10d8b2` would give you a great start toward what files are involved in this
<kyrofa> gsilvapt, see what I mean?
<gsilvapt> Yes, I'm following
<kyrofa> That brings you to the snapcraft/cli package that I mentioned
<kyrofa> Look at a few files in there, you'll see how other commands are structured
<kyrofa> You'll also see how --version works, and you should be able to sort of combine the two
<gsilvapt> So the file to be changed is actually snapcraft/__init__.py
<gsilvapt> is that correct?
<mup> PR snapcraft#1729 closed: sources: use arfile to extract debs <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1729>
<kyrofa> No, maybe snapcraft/cli/__init__.py, but more likely snapcraft/cli/help.py or create a new file in there
<kyrofa> (I would suggest a new file)
<sergiusens> ikey in devmode and strict you are pivot rooting into the base snap, so os release would be what that is (unless I got your question wrong)
<ikey> yeah its not
<sergiusens> kyrofa elopio the correct fix for the logging is to use a named logger and not getdefaultLogger
<ikey> someone testing my snap is showing a report of Ubuntu 17.10 from steam
<kyrofa> sergiusens, named logger where? In the log package?
<sergiusens> kyrofa https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/log.py#L55 make sure logger_name is not None there
<gsilvapt> kyrofa, considering the method to retrieve snapcraft version exists when --version is passed in as arguments, is it bad practice if we change it to just be version?
<sergiusens> kyrofa for the callers of that
<kyrofa> sergiusens, ah, I see
<gsilvapt> Or rather, version and --version should return the same value. They both exist so we could adjust the respective code bits, right?
<sergiusens> kyrofa but this is not an easy fix, as all the random getLogger calls would need to change as well
<sergiusens> then, setting a log level will only affect our stuff
<kyrofa> gsilvapt, according to the bug, looks like both --version and version are desired
<sergiusens> kyrofa your fix is fine, but I'd do it at the start of the tests and not at the end
<sergiusens> kyrofa baseline the loglevel for all the tests
<kyrofa> sergiusens, fair enough. Shall I repropose and log a bug about the loggers?
<gsilvapt> kyrofa, yes, both are desired to print the version of snapcraft and not the snap itself. Again, if both methods exist, why not convert them to return the same value?
<kyrofa> gsilvapt, hmm, I'm a bit confused-- they don't both exist. But I agree that, when we add `version` it should return the same value as `--version`
<sergiusens> kyrofa sounds good, but lets get this release out of the way; also, we should stop checking for strict output
<gsilvapt> Hum, I thought version would return the snap's version
<gsilvapt> So basically it needs a new class. Ok, this could be tricky for me to implement and it is getting late but I will sketch something to work this one out
<kyrofa> gsilvapt, check the bug again, that discussion was had there
<kyrofa> sergiusens, agreed on both counts, although this is sort of FOR this release since it's in the way of my running adt locally, but we can hack around it for now
<sergiusens> ikey is this written somewhere? some people run things straight from the innards of things (which makes me think sometimes that we should blackbox the snap itself by default...)
<gsilvapt> Yes, I just thought both existed but did different things. They both should return the same thing which is the snapcraft version number.
<sergiusens> kyrofa we are almost there https://github.com/snapcore/snapcraft/milestone/10 (I am not sleeping until this is tagged btw)
<kyrofa> gsilvapt, you got it-- `snapcraft version` doesn't exist today
<kyrofa> sergiusens, nice
<gsilvapt> Ok, I will work on this for the next couple of days. Need to read a bit more about how is this feature working before implementing a new one
<gsilvapt> Thanks for helping, kyrofa
<kyrofa> sergiusens, elopio do we to move all the catkin integration tests into snapd tests?
<kyrofa> do we WANT rather
#snappy 2017-11-14
<kyrofa> That makes the snapd suite far more than just hello-type snaps
<kyrofa> But I'm fine with it as long as running the snaps doesn't add a lot of time
<elopio> kyrofa: some of them should be in the plugins integration suite, right?
<elopio> the ones that don't require execution.
<kyrofa> Yeah that would be better... but then we have problems :P
<kyrofa> Just trying to figure out what we want to do about snapcraft#1717
<mup> PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717>
<elopio> kyrofa: I haven't seen that plainbox error before, but permission denied in tmp isn't it the same we get in ruby?
<kyrofa> elopio, I've never seen that for ruby, I just saw an inability to find rbconfig.rb
<elopio> kyrofa: http://paste.ubuntu.com/25954649/ line #4
<kyrofa> elopio, that's probably shebang rewriting etc. Yeah, not sure why permission would be denied there
<kyrofa> But it's a separate issue from the breakage a few lines below
<kyrofa> (which I've fixed)
<kyrofa> elopio, note that I see those warnings as well
<kyrofa> (just checked)
<kyrofa> elopio, looks like ruby sets gems to 444 (read-only)
<kyrofa> So, non-fatal indeed
<kyrofa> We can ignore those
<elopio> kyrofa: ahh, I was looking at the wrong place then. Where are you getting those plainbox errors? to try to reproduce
<kyrofa> elopio, on xenial, adt running in xenial lxc
<kyrofa> I'll be running another one in a minute, see if it happens again or if it was a fluke of some kind
<elopio> kyrofa: amd64?
<kyrofa> elopio, yes indeed, sorry
<elopio> yeah, I haven't seen that one.
<kyrofa> sergiusens, elopio, both of those PRs depend on making a call on where we want that test to be
<kyrofa> I vote for leaving it alone until we can split the plugins suite
<elopio> kyrofa: +1. Make the move after we have the reorg branch, probably to snapcraft/integration/plugins/catkin
<elopio> the hard part is to define where to put all the ones that are not catkin, naming those directories "general" is kind of sad.
<elopio> maybe, we can make a filter, and run everything except catkin.
<kyrofa> elopio, hmm, aren't the filters regex though?
<elopio> kyrofa: they could be.
<kyrofa> Negative regex gets gross
<elopio> yes. I don't have a solution for this, but I'm happy to push it for later.
<sergiusens> reorgs later
<kyrofa> Good
<kyrofa> I'll run a zesty test on 1717
<kyrofa> elopio, thanks for the --setup-commands hint, by the way. I'll propose that for our testing doc once this release is out the door
<kyrofa> Running 1719 zesty:amd64 on my server as well
<kyrofa> elopio, how do you feel about upping the ROS timeouts for arm adt?
<elopio> kyrofa: I'm ok with that
<kyrofa> Every time it happens they're priming or snapping, so we're so close
<kyrofa> It also means it's not a legit hang, it's just taking a little longer
<elopio> kyrofa: also, they can be moved to integration tests, right?
<kyrofa> elopio, oh, are we talking about the demos?
<kyrofa> elopio, yes they can, but then we run into the same question of where to put them
<kyrofa> Seems pointless to move them until we have a place they can stay
<elopio> kyrofa: they will be slow snapd integration tests, so they will only run on adt
<kyrofa> Oh riiight
<elopio> we haven't set a timeout for those, but we probably should.
<kyrofa> I'd still rather just tweak the timeouts here so I don't need to retest them
<kyrofa> (for release I mean)
<elopio> kyrofa: ah, yes, for now, just bump that.
<elopio> I would hate to cause a timeout in a different place, again.
<kyrofa> No kidding
<kyrofa> I just wanna get this thing out the door
<mup> PR snapcraft#1731 opened: demo tests: bump catkin timeout by ten minutes <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1731>
<kyrofa> elopio, ^
<sergiusens> kyrofa elopio fwiw I am not fond of timeouts
 * sergiusens looks for a clever blog post with why
<sergiusens> meh, I cannot find any. I wouldn't use timeouts on test hardware that is shared or out of our control
<sergiusens> there are so many things that can go wrong
<mup> PR snapd#4211 opened: tests: adding tests for time*-control interfaces <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4211>
<kyrofa> sergiusens, fine by me, they do cause issues
<kyrofa> sergiusens, we can remove them after this release, when we slurp them into the snapd suite
<kyrofa> (which doesn't have timeouts)
<kyrofa> (at least, I don't think they do. Maybe they have shorter timeouts though, we'll have to check)
<sergiusens> kyrofa \o/
<kyrofa> sergiusens, bug #1732065 is probably for you
<mup> Bug #1732065: dotnetplugin: use of xenial-only stage-packages <Snapcraft:New> <https://launchpad.net/bugs/1732065>
<sergiusens> kyrofa heh, the dotnet plugin will not work on anything but xenial
<kyrofa> sergiusens, alrighty, more skips!
<sergiusens> kyrofa seems the tests for snapcraft#1730 went rather well
<mup> PR snapcraft#1730: ruby plugin: be smarter about arch-specific paths <bug> <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1730>
<kyrofa> snappy-m-o, autopkgtest 1731 xenial:armhf
<snappy-m-o> kyrofa: I've just triggered your test.
<kyrofa> sergiusens, armhf is red, let me see...
<kyrofa> Ugh. Network problems
<sergiusens> kyrofa ros test and python, network related and unrelated to this, but please double check
<kyrofa> sergiusens, indeed, both network related
<sergiusens> kyrofa is snapcraft#1717 good when looking at the errors?
<mup> PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717>
<kyrofa> sergiusens, for zesty anyway, yeah. But that skips some tests... would sure like xenial armhf to run
<kyrofa> But then we hit the timeout issue
<sergiusens> kyrofa is that the 10 thing?
<kyrofa> sergiusens, yep
<kyrofa> armhf is running there now
<kyrofa> Or queued at least
<sergiusens> kyrofa be more ambitious, triple it
<kyrofa> Hahaha
<kyrofa> You got it
<sergiusens> as if there were no timeout
<sergiusens> really
<sergiusens> I asked elopio a year ago to remove these timeouts
<sergiusens> the only thing we do when we reach them is increase it
<mup> PR snapcraft#1730 closed: ruby plugin: be smarter about arch-specific paths <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1730>
<sergiusens> and we already have the timeouts imposed by the machinery running the tests anyways
<kyrofa> snappy-m-o, autopkgtest 1731 xenial:armhf
<snappy-m-o> kyrofa: I've just triggered your test.
<kyrofa> sergiusens, done
<sergiusens> great
<kyrofa> sergiusens, my adt run on snapcraft#1719 blew up, unfortunately, it seems like it doesn't like running in nested containers. I'm starting it again here, but it takes about two hours
<mup> PR snapcraft#1719: many: account for python shebang args in rewrite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1719>
<kyrofa> (zesty:amd64)
<kyrofa> Would be nice to see xenial:armhf there as well but there seems little point in queuing that up until the timeout fix lands
<kyrofa> I'll check back in a bit
<sergiusens> kyrofa one sec
<sergiusens> can you review something real quick?
<kyrofa> Sure
<sergiusens> kyrofa #1732
<mup> PR #1732: many: respect dirs.SnapSnapsDir in tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1732>
<sergiusens> kyrofa hmph, snapcraft#1732
<mup> PR snapcraft#1732: tests: dotnet only works on 16.04 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1732>
<kyrofa> sergiusens, haha, I got it. Always gets ya, though!
<sergiusens> kyrofa I am doing it on purpose sometimes, maybe enough "incorrect" people get pinged that it gets removed as the implicit default :-P
<kyrofa> Hahahahaha
<kyrofa> sergiusens, +1
<kyrofa> Alright, back soon
<mup> PR snapcraft#1732 opened: tests: dotnet only works on 16.04 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1732>
<HazWard> Is there a guide to package Wine programs into snaps? I want to try out some windows programs but I don't want to have all those dependencies
<mup> Issue snapcraft#1492 closed: Support for advanced filtering for build-packages <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1492>
<sergiusens> snappy-m-o  autopkgtest 1732 artful:amd64
<snappy-m-o> sergiusens: I've just triggered your test.
<ikey> had to push a fix to the full-nvidia-support PR
<ikey> turns out Ubuntu uses a slightly different filename convention for vulkan ICDs (it doens't start with 10_ so i glob without the 10 now..)
<kyrofa> Tests still running...
<kyrofa> The timeout-increasing PR has its armhf run going though, looks like
<kyrofa> I suspect things will come together tomorrow
<mup> PR core#64 opened: 30-fix-timedatectl.chroot: fix quoting issues <Created by mvo5> <https://github.com/snapcore/core/pull/64>
 * zyga-ubuntu is doing some tax work in the morning, sorry about that
<mup> PR snapd#4212 opened: tests/interfaces-network-control-tuntap: disable on debian-unstable for now <Created by mvo5> <https://github.com/snapcore/snapd/pull/4212>
<zyga-ubuntu> mvo: hint: all of debian unstable is broken
<zyga-ubuntu> mvo: because of https://forum.snapcraft.io/t/snapd-2-27-6-2-in-debian-sid-blocked-on-apparmor-in-kernel-4-13-0-1/2813/12
<zyga-ubuntu> mvo: so perhaps we need to refresh the debian image and fix this for real, disabling all of debian while this happens
<mvo> zyga-ubuntu: I see only the failures in tun/tap so far
<mvo> zyga-ubuntu: but those are quite consitent
<zyga-ubuntu> mvo: what is the error there?
<mvo> zyga-ubuntu: permission denied
<mvo> zyga-ubuntu: I have not checked (yet) for the details, just want to unblock master for now
<mvo> zyga-ubuntu: there are some PRs ready otherwise
<pedronis> pstolowski: hi, I re-reviewed #4158
<mup> PR #4158: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/4158>
<pstolowski> pedronis, ty
<mvo> pedronis: hey, good morning. can I run an idea by you? I have created https://github.com/snapcore/snapd/compare/master...mvo5:refresh-candidates-managed?expand=1 as a starting point for the work for the refresh.schedule=managed PR. my idea was that if the refresh schedule is managed there is code that calls store.ListRefresh() with the RefreshControlManaged flag. do you think this makes sense or would you suggest a different approach?
<mvo> also 4212 would unblock master
<mvo> if it gets reviews
<mup> PR snapd#4212 closed: tests/interfaces-network-control-tuntap: disable on debian-unstable for now <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4212>
 * mvo hugs zyga
<mvo> zyga-ubuntu: lets try to merge in a controlled way so that we don't cause a travis congestion
<zyga-ubuntu> mvo: ok, let's coordinate here
<mvo> zyga-ubuntu: I will push 4204 as this should be ready now
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4207 can land
<mup> PR #4207: Flesh out NVIDIA support for biarch and multiarch systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4207>
<mvo> zyga-ubuntu: also 4202
<zyga-ubuntu> 4202 has some comments
<zyga-ubuntu> if you add those that's fine
<mvo> zyga-ubuntu: I think he addressed them, no?
<pedronis> mvo: we are trying not do add new headers
<pedronis> because we are redesigning all of them
<mvo> pedronis: aha, happy to use json then, any suggestions for a straw-man?
<pedronis> mvo: IÂ mean it's ok if first iteration doesn't flag this anyway
<pedronis> it's really a question for cprov tbh
<mvo> pedronis: what the json should look like
<mvo> pedronis: oh, you mean in the first iteration we don't need this flag send? fair enough, I can hold back then if it does not make sense to add it at this point (because of the store API work)
<pedronis> mvo: IÂ don't know, the issue is also that if we send something like this probably we need to send it with all calls
<pedronis> not just the extra calls
<mvo> pstolowski, zyga-ubuntu: is there anything controversial in 4120? it looks quite mechanical, if this is the agreed interface it seems we want to merge it. or does it need a gustavo +1?
<pedronis> mvo: I don't think it make sense to add a flag without discussing how it will be used
<pedronis> for that we probably need cprov
<mvo> pedronis: all refresh calls or all all calls, i.e. install etc as ewll?
<pedronis> all refresh calls at least
<pedronis> but see general point
<zyga-ubuntu> mvo: I'll look in  a sec
<mvo> pedronis: adding it to all refresh calls was my plan, but happy to hold off for now and discuss wider first. sorry for the rush, was mostly because we want the managed mode in 2.30 but if we can life without the flag for v1 all is well
<mvo> pedronis: I followup in the forum
<pstolowski> mvo, i hope there is nothing controversial
<pedronis> that was the agreed direction,  Permanent takes Info sanitized at read time
<Chipaca> mo'in
<mvo> pedronis: great, then its just a second review and it can go in. thanks for your feedback
<mvo> hey Chipaca
<pedronis> mvo: yes, please write something in the topic
<ackk> Chipaca, hi, could you please have another look at https://github.com/snapcore/snapd/pull/3916 ? I think I addressed the remaining comments
<mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
<Chipaca> sure
<ackk> thanks
<cprov> mvo, pedronis: Hi! how can I help ?
<mvo> cprov: hey, good morning
<cprov> mvo: morning
<mvo> zyga-ubuntu: you did say that you want to have a look at 4207, right?
<mvo> zyga-ubuntu: it has two +1 already but you are the expert in this area so your review will certainly not hurt :)
<zyga-ubuntu> mvo: I will look again and merge it
<zyga-ubuntu> thank you :)
 * zyga-ubuntu is almost done with taxes
<zyga-ubuntu> mvo: +1 to land https://github.com/snapcore/snapd/pull/4120
<mup> PR #4120: repo: use PlugInfo and SlotInfo for permanent plugs/slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/4120>
<pstolowski> thanks1
<mup> PR snapcraft#1731 closed: demo tests: bump catkin timeout by a lot <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1731>
<mup> PR snapd#4120 closed: repo: use PlugInfo and SlotInfo for permanent plugs/slots <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4120>
<mup> PR core#64 closed: 30-fix-timedatectl.chroot: fix quoting issues <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/64>
<sergiusens> snappy-m-o autopkgtest 1717 xenial:armhf
<snappy-m-o> sergiusens: I've just triggered your test.
 * zyga-ubuntu goes to the doctor with his son 
<Chipaca> ackk: +1; merged
<Chipaca> ackk: thank you!
<mup> PR snapd#3916 closed: snap,wrappers: add support for socket activation <Created by albertodonato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3916>
<ackk> Chipaca, \o/ thanks :)
<ackk> Chipaca, are the blockers for the snapcraft PR to alow that syntax?
<Chipaca> ackk: je ne sais pas
<Chipaca> ackk: that's a snapcrafter question :-)
<Chipaca> (i haven't been following that particular thing)
<Chipaca> ackk: have you checked with review tools also?
<ackk> Chipaca, wdym?
<ackk> yeah I should probably ask kyrofa about that one
<ackk> (https://github.com/snapcore/snapcraft/pull/1617 FTR)
<mup> PR snapcraft#1617: Add options to configure applications socket activation <Created by albertodonato> <https://github.com/snapcore/snapcraft/pull/1617>
<Chipaca> ackk: there's a sanity checker / enforcer that's run as part of a store upload that might block this (i don't know, but somebody should check)
<Chipaca> ackk: it used to be called click-review-tools (it might still be called that)
<ackk> I see
<Chipaca> rabble rabble proud heritage rah rah
<cjwatson> Chipaca: hey, so man pages :-)  I've been putting some weekend/evening time into getting man-db set up with apparmor and seccomp
<cjwatson> Chipaca: at the moment the state of play is that I've got committed-but-not-uploaded changes to add an apparmor profile to /usr/bin/man that confines various groff-related processes that it starts, plus decompressors and other misc filters
<cjwatson> Chipaca: I've also got work in progress to do seccomp confinement in other simpler cases - groff can't really be seccomp-confined because we need to be able to do path filtering (to let it open temp files but not other things)
<cjwatson> Chipaca: how widely deployed would we want all this to be before we could be comfortable turning it on in snaps, though?
<cjwatson> Chipaca: the main issue here is that seccomp confinement requires some new API in libpipeline, so it'd be difficult to SRU.  the apparmor confinement on its own would probably be quite easy to SRU.  might we be comfortable if we just had apparmor for groff-related processes called by man, which it seemed to me before was the main concern?
<Chipaca> cjwatson: wrt whether apparmor would be enough for us to be happy, that's a question for jdstrand
<cjwatson> OK, hopefully he'll see that.  I did run the profile past him
<Chipaca> cjwatson: wrt SRU, i'll check what mvo thinks; worst case we might look at rolling it into 18
<cjwatson> AIUI from Gustavo at the rally, 18 is more of a future escape hatch than a concrete plan
<cjwatson> so yeah, that's a worst case, seems like quite a bad one though :)
<Chipaca> cjwatson: wrt how widely deployed, i'm ok with letting the packager decide whether their target distribution supports it or not
<Chipaca> cjwatson: 18 is many things :-) but we'll be switching to an 18.04-based default at _some_ point
<Chipaca> as opposed to our current 16.04-based default
<Chipaca> and that's what i meant
<cjwatson> right, if you mean 18.04 base snaps rather than series 18 assertions or whatever, then sure
<Chipaca> series:18 is the thing that's an escape hatch
<cjwatson> hopefully should be able to get the apparmor profile SRUed to xenial after some bake time, though
<Chipaca> yes (for moost non-devs, a 18.04 base snap defaut is as 18 as it gets)
<Chipaca> that would be ideal, agreed
<Chipaca> cjwatson: the change in libpipeline, it's a new API, not a changed one?
<cjwatson> the main hole this leaves would be man-db's own scanning of manual pages to figure out what their NAME headers are.  there's literally never been a vulnerability in that, though, so I'm not too worried
<Chipaca> so it can be made ABI-compatible?
<cjwatson> it's a new API, yes, but it'd effectively be a new upstream version
<cjwatson> also new ABI, so not quite sure what you mean by ABI-compatibile
<cjwatson> *compatible
<Chipaca> maybe i misunderstood -- i thought if you just added new symbols you didn't need to bump the abi
<Chipaca> but my knowledge of that part of the stack is very hazy :-)
<Chipaca> (i've never had to learn it)
<cjwatson> Chipaca: well, it's not a new SONAME so doesn't require a library transition or anything, sure
<Chipaca> right, that's what i meant, thank you
<Chipaca> cjwatson: taking a step back, that's great news, and thank you for your work on this! I'll try not to get too excited until more bits get put in place, but it's hard :-)
<cjwatson> right, it'll take a week or two more until everything lands in bionic, probably, since the seccomp stuff requires some care about portability.  Just mainly wanted to check whether I was missing anything important
<Chipaca> Son_Goku: o/
<Son_Goku> hey
<Chipaca> Son_Goku: question for you: if you set MANPATH to include, say, /var/lib/snapd/snap/man, and that directory contained manpages, would your man pick it up, or would its confinement block that?
<Son_Goku> it'd probably get blocked
<niemeyer> o/
<Son_Goku> niemeyer: hi
<Son_Goku> man can only access files labeled as "man_t"
<Son_Goku> I'd probably have to fiddle with the SELinux policy to make sure any files in /var/lib/snapd/snap/man were marked as man pages
<Son_Goku> or at least could transition from type snappy_var_t to man_t
<Chipaca> Son_Goku: could snapd do that labeling?
<Son_Goku> it *should*
<mvo> pedronis: I think I'm at the point now where I would like to use the fakestore with a fake snapDeclaration for my snapd refresh managed PR, maybe we can have a quick chat after the standup? happy to work on it just want to make sure things are aligned
<Son_Goku> the fact it doesn't is super annoying
<Chipaca> Son_Goku: ok, i'll keep it in mind
<Son_Goku> it should be generating all of these policy things
<Chipaca> Son_Goku: tell me more
<Chipaca> about "all of these policy things"?
<Chipaca> i mean, i have no idea how to label something, but i presume it's something that could in worst case be done via a command
<Chipaca> so snapd could do it as part of install
<Son_Goku> sure
<Son_Goku> there are a few ways to do it
<Chipaca> so my question is more what needs labeling
<Son_Goku> libselinux provides a programmatic way to do it, but you can also use chcon to do it
<Son_Goku> it does run the risk of being reset unless a policy is generated and loaded
<Son_Goku> so snaps need to be labeled correctly on install and mount
<Son_Goku> matching the label in the snapd policy profile for them
<Son_Goku> assuming man is confined, man pages on install need to be labeled correctly, too
<Chipaca> Son_Goku: what would do that resetting? and how does a policy loading stop the reset?
<pedronis> mvo: yes, it's almost lunch here, we can chat after the standup, this morning I looked around about what is the current situation about that
<Son_Goku> and snapd should be generating policies to enforce these so that when the user runs restorecon, it doesn't get reset by policy
<Son_Goku> the restorecon command can be used to reset all filesystem labels to match what's in the loaded SELinux policy
<Chipaca> Son_Goku: is the policy something like "everything under /foo/bar has label baz"?
<Son_Goku> yes, it can be
<Chipaca> Son_Goku: so we could instead have that and do restorecon?
<Son_Goku> yes
<Chipaca> or would that be frowned on
<Son_Goku> no, that's fine
<Son_Goku> you can tell restorecon to restore only within a set of paths
<Son_Goku> rather than the whole filesystem
<Chipaca> Son_Goku: and how does restorecon affect running processes?
<Son_Goku> it doesn't
<Chipaca> ok
<Son_Goku> processes get their SELinux context from when they're initialized
<Son_Goku> that comes from the label they were on disk
<Chipaca> Son_Goku: thanks (i'll ask and dig more when i'm closer to the feature)
<Son_Goku> :)
<Chipaca> this gives me a general feel of what needs to happen :-)
<Son_Goku> for SELinux, there are two "languages" for them: a high level language (you can see that here: https://github.com/snapcore/snapd/tree/master/data/selinux), and an intermediate language that you can use to build another language to compile to: https://github.com/SELinuxProject/cil/wiki
<Chipaca> cjwatson: is the libpipeline work being done upstream? would fedora be picking that up as well?
<cjwatson> Chipaca: I am upstream for libpipeline
<cjwatson> so yes
<mvo> pedronis: same here, lunch and meetings, looking forward for your ideas :) enjoy lunch
<Chipaca> cjwatson: thank you
<Son_Goku> Chipaca, since snapd has its own high level language for security constructs, any programmatic SELinux enablement would probably be done by leveraging the CIL
<Son_Goku> CIL constructs can be directly loaded into the kernel
<Chipaca> Son_Goku: I know some of those words! I'll see how much I need to learn down the road (not now though)
<Son_Goku> :D
<Chipaca> Son_Goku: the context is that we'll be adding manpage support at some point, and want man to be able to load manpages from snaps while minimising risk
<Son_Goku> right
<Son_Goku> the CIL structure more closely resembles how AppArmor profiles are written, so that might be helpful for you ;)
 * Chipaca goes back to reviewing stuff
<Son_Goku> also... restorecon: https://www.mankier.com/8/restorecon
 * kalikiana tea break
<cjwatson> the in-progress apparmor profile is https://anonscm.debian.org/cgit/pkg-man-db/man-db.git/tree/debian/apparmor/usr.bin.man FWIW
<cjwatson> definitely not perfect but it protects the bits that deal with untrusted data most directly
<andyrock> ogra_:  regarding the problem of snaps mounts appearing in gdu
<andyrock> the mount options 'x-gdu.whatdever' cannot be used because it requires that to be in fstab
<andyrock> an enviroment variable cannot be used because cannot be get using udisk2
<zyga-ubuntu> re
<zyga-ubuntu> JamieBennett: I'm home now
<andyrock> zyga-ubuntu: http://paste.ubuntu.com/25960186/
<andyrock> I asked upstream if we can just mark them as udisk2 ignored
<andyrock> and maybe gdu can avoid displaying an ignored loop device
<andyrock> and show all the other devices (even if ignored)
<zyga-ubuntu> andyrock: looking
<zyga-ubuntu> andyrock: I don't understand why x-gdu.whatever cannot be used
<andyrock> because it's not passed around
<zyga-ubuntu> andyrock: is it because the custom mount unit data is lost and cannot be accessed?
<andyrock> not written in mtab
<andyrock> nowhere
<zyga-ubuntu> I see
<andyrock> it can be that i'm doing something wrong
<andyrock> but I don't think so :D
<andyrock> https://www.irccloud.com/pastebin/qWM7FlOw/
<andyrock> it can be that I'm using an old version of util-linux
<andyrock> let me check on bionic
<zyga-ubuntu> andyrock: I think you are right
<andyrock> https://www.irccloud.com/pastebin/8i62fxih/
<andyrock> zenial has 2.27
<andyrock> *xenial
<andyrock> bionic should be fine
<andyrock> and it's ok to not target X
<JamieBennett> zyga-ubuntu: OK, see you at the stand-up
<zyga-ubuntu> mvo: hello, did you consider increasing the number of workers?
<zyga-ubuntu> ok
<zyga-ubuntu> mvo: I just +1d https://github.com/snapcore/snapd/pull/4207
<mup> PR #4207: Flesh out NVIDIA support for biarch and multiarch systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4207>
<zyga-ubuntu> not sure if you think jamie should see it as well
<zyga-ubuntu> Chipaca: hey
<zyga-ubuntu> Chipaca: FYI, there's a C rewrite of c-n-f
<Son_Goku> zyga-ubuntu: eh?
<zyga-ubuntu> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881692
<zyga-ubuntu> hey Son_Goku
<Son_Goku> yet another c-n-f thing?
<Son_Goku> jeez
<Son_Goku> why
<zyga-ubuntu> Son_Goku: I'd love one upstream cnf that's not tied to gnome-software/packagekit
<zyga-ubuntu> Son_Goku: that can work anywhere
<Son_Goku> and of course, it's debian specific, though I shouldn't be surprised since it's a rewrite of the debian c-n-f tool
<zyga-ubuntu> but it's world vs reality
<Son_Goku> zyga-ubuntu: suse's scout uses libsolv
<zyga-ubuntu> Son_Goku: why debian specific?
<Son_Goku> which can parse literally anything
<zyga-ubuntu> Son_Goku: I don't want to use libsolve
<zyga-ubuntu> Son_Goku: this is not a merit
<Son_Goku> why is that not a merit?
<zyga-ubuntu> Son_Goku: cnf has a very simple goal: deliver useful hint quickly
<Son_Goku> yes
<zyga-ubuntu> Son_Goku: it has a very simple data format
<zyga-ubuntu> Son_Goku: that can be fed by anything
<Son_Goku> you want a cnf framework?
<Son_Goku> then make one
<zyga-ubuntu> Son_Goku: no, I don't want a framework, we have one already, it just needed a C rewrite for speed
<zyga-ubuntu> Son_Goku: app name -> list of info about hints
<zyga-ubuntu> that's literally the whole thing
<zyga-ubuntu> Son_Goku: I'm sure each distribution had a reason to come up with something similar but I was trying to make a point about simplicity and speed
<zyga-ubuntu> Son_Goku: using complex libraries for complex tasks is not improving the situation
<zyga-ubuntu> Son_Goku: there's nothing to solve for
<Son_Goku> the debian c-n-f calls apt directly
<Son_Goku> that's basically the same problem then
<zyga-ubuntu> Son_Goku: ?
<zyga-ubuntu> Son_Goku: is the debian cnf the same as ubuntu's cnf?
 * Son_Goku shrugs
<zyga-ubuntu> Son_Goku: note that "calling $packaging tool" directly is a simple build thing that can be tweaked form same source
<zyga-ubuntu> Son_Goku: in fact the code I wrote a decade ago did that
<zyga-ubuntu> Son_Goku: (though it was my very early python so it's pretty terrible)
<Son_Goku> zyga-ubuntu: it looks like it reads apt metadata
<Son_Goku> Contents and Packages, specifically
<zyga-ubuntu> Son_Goku: the debian one? that's too bad, sorry about that (I didn't write that)
<zyga-ubuntu> Son_Goku: my implementation was always about data, any package can add additional data files that contain hints
<zyga-ubuntu> Son_Goku: and with minimal dependencies it is sane for servers and desktops and embedded alike
<Son_Goku> the goal of most c-n-f tools is to identify what you need to install to make the missing command available
<zyga-ubuntu> Son_Goku: and the data can come from whatever format, can be packagekit, gnome-software, apt, dnf, whatever
<Son_Goku> that's what PK-cnf, scout, etc. all do
<Son_Goku> the problem in your case is you want to inject foreign applications into the cnf
<zyga-ubuntu> ?
<zyga-ubuntu> no, there's no problem here
<zyga-ubuntu> anyway, not sure what we are arguing about
<zyga-ubuntu> the many implementations
<zyga-ubuntu> the design of a particular one
<zyga-ubuntu> or something else
<Son_Goku> we're not arguing
<Son_Goku> I'm just telling you what the stuff has been forever
<Son_Goku> and your problem space (adding snaps to cnf) is not easy because most don't have a way to do it
<zyga-ubuntu> Son_Goku: well, I know there were, I tried to unifiy it after writing the first one
<zyga-ubuntu> Son_Goku: that's fine, we'll go little by little
<zyga-ubuntu> Son_Goku: (actually not sure if I wrote the first one or just the one that got used in ubuntu)
<Son_Goku> I think you just wrote the one that went into ubuntu
<zyga-ubuntu> Son_Goku: but my point is that it's hard to unify everyone now as they all have their own quirky versions
<zyga-ubuntu> Son_Goku: but was it also the first one?
<Son_Goku> I recall cnf systems existing since before Ubuntu's existence
<Son_Goku> Mandrake had one, iirc
<zyga-ubuntu> aha, I didn't know that
<zyga-ubuntu> Son_Goku: in my problem the actually interesting/hard part was data collection
<Son_Goku> my memories of Mandrake are super-foggy though, it was 15 years ago
<zyga-ubuntu> the display part was really not that hard
<Son_Goku> sure
<zyga-ubuntu> nowadays it's (maybe) better with better repo-side meta-data
<Son_Goku> yeah
<zyga-ubuntu> but when you cannot get "vim" (because it's vim.real) or gcc (because $REASONS) I had to do some very ugly things to collect better source data
<Son_Goku> well, Mandrake's urpmi was one of the first easily searchable metadata formats
<Son_Goku> it had a binary index called synthesis
<Son_Goku> that made things super-fast for queries
<Son_Goku> right
<zyga-ubuntu> Son_Goku: the index is not a problem, I built one too, the problem were postinst scripts
<Son_Goku> this wasn't a problem in RPM land, because we had %ghost
<Son_Goku> we can just say a file *will exist* and it would show up in the file lists anyway
<zyga-ubuntu> Son_Goku: dpkg-divert and dpkg-alternatives
<Son_Goku> I don't know how debian solved that problem
<Son_Goku> alternatives has and will remain, garbage fire
<zyga-ubuntu> Son_Goku: I think they now describe command line applications explicitly
<zyga-ubuntu> Chipaca: hey, about the README file, I'm thinking if it should be a standalone file && symlink
<zyga-ubuntu> Chipaca: and about the complexity tradeoff
<zyga-ubuntu> not sure
<zyga-ubuntu> Son_Goku: have you seen that PR?
<Son_Goku> which one?
<Son_Goku> I follow lots of PRs for lots of projects...
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4210
<mup> PR #4210: many: add magic /snap/README file <Created by zyga> <https://github.com/snapcore/snapd/pull/4210>
<zyga-ubuntu> yesterday's experiment to help users
<zyga-ubuntu> this was caused by https://forum.snapcraft.io/t/a-more-graceful-way-for-snapd-to-fail-when-snap-is-missing/2712/31 (which is very eye-opening)
<Chipaca> zyga-ubuntu: question is, where do you symlink it to / copy it from
<zyga-ubuntu> Chipaca: yeah, complexity
<zyga-ubuntu> Chipaca: this is blissfully simple
<Chipaca> zyga-ubuntu: make it readonly i'm +1 on it :-)
<Chipaca> zyga-ubuntu: the others are wishful dreaming
<zyga-ubuntu> Chipaca: could be i18n if we had core locale handling :D
<zyga-ubuntu> Chipaca: ok, I'll check if that doens't upset the ensure code and do it
<zyga-ubuntu> *doesn't
<Son_Goku> zyga-ubuntu: umm wtf?
<Son_Goku> you're dynamically generating a readme?
<zyga-ubuntu> Son_Goku: yes, like everything else there
<Son_Goku> alright then
<Son_Goku> man page like readmes should be treated like man pages :)
<zyga-ubuntu> Son_Goku: I mean it's a bit of a stretch
<zyga-ubuntu> Son_Goku: but it has some advantages
<Son_Goku> I'm not saying it's bad
<Son_Goku> it's just out of left field
<zyga-ubuntu> Son_Goku: yeah but this is for users who don't really read man pages
<Son_Goku> yes, yes
<zyga-ubuntu> out of left field?
<Son_Goku> something I didn't expect anyone would do
<zyga-ubuntu> aha :)
<Chipaca> Son_Goku: this is to address a problem we saw in the forum
<Son_Goku> "out of left field" is an English idiomatic phrase coming from baseball
<Chipaca> Son_Goku: somebody rsync'ed /snap and then mounted that and wondered why everything was terrible
<zyga-ubuntu> I almost think we could have WHAT-IS-THIS.desktop that runs browser and goes to the forum
<Son_Goku> zyga-ubuntu: https://en.wikipedia.org/wiki/Out_of_left_field
<zyga-ubuntu> with gustavo movie explaining things
 * zyga-ubuntu reads
<Son_Goku> the forum is a bad reference for these things
<Son_Goku> it's too dynamic and people are allowed to freely edit and delete things
<Son_Goku> as the information is relatively static, it makes little sense to not incorporate it into the README file if that's its purpose
<zyga-ubuntu> Son_Goku: that topic is in the "doc" section
<zyga-ubuntu> Son_Goku: so it should be curated
<Son_Goku> it can just as easily not be
<Son_Goku> that is *not* a good enough indicator in my mind
<zyga-ubuntu> Son_Goku: what would you add to the file that is not there already/
<Son_Goku> actually, I think the readme itself is fine
<Son_Goku> but if there's supposed to be more information, don't cop-out to link to the forum
<Son_Goku> it's a bad habit
<Son_Goku> it already happens too much when it really shouldn't
<Son_Goku> documentation topics should probably be regularly exported from the forum into something that can be bundled and shipped as a static site
<zyga-ubuntu> Son_Goku: maybe, I think it could be done if the forum has an API
<zyga-ubuntu> Son_Goku: I like the appeal of offline, curated docs
<zyga-ubuntu> Son_Goku: but nowadays people mostly just google stuff
<Son_Goku> I'm more concerned that the docs aren't really forkable
<zyga-ubuntu> aha
<Son_Goku> they *were* when they were managed in a github wiki
<Son_Goku> but they're not anymore
<Son_Goku> and we have problems from time to time with people being unable to edit their own topics/posts
<mvo> zyga-ubuntu: I don't think I can do that myself, I can do a PR though, but I have no analyized why things are slow currently
<zyga-ubuntu> mvo: I mean, we can just do a PR with some extra nodes in it to see how timing works
<niemeyer> Son_Goku: Don't overthink it too much.. it's a link to a place which can be publicly edited and maintained. The link can change, the content in the forum can change, everything can change if it has to. For now this approach is good enough, and it's visible both to the community and to people maintaining it.
<zyga-ubuntu> Son_Goku: I addressed your comments now, thank you!
<jdstrand> zyga-ubuntu: hey, so 4163 was committed before I looked at it, but I looked at it yesterday. while the code appears to have the end result we want, I felt that it was a bit confusing as an api and hard to read. it's approved and it works so not a blocker, but 2 cents
<zyga-ubuntu> jdstrand: hey thank you for reviewing that
<zyga-ubuntu> jdstrand: yes, it got merged by accident really
<jdstrand> ok
<zyga-ubuntu> jdstrand: I did that to reuse code / testing for similar features, if you think it'd be better to just get it in one function like before that's useful data for me
<jdstrand> zyga-ubuntu: if you agree and wanted to do a followup PR, I'm happy to review it
<zyga-ubuntu> jdstrand: did you add the feedback on github?
<zyga-ubuntu> or is that just the remark here about the api complexity
<jdstrand> zyga-ubuntu: it isn't so much about reuse (which is fine). my comments are in the PR, yes
<zyga-ubuntu> ok, i'll have a look; thank you!
<jdstrand> surprised you didn't get an email...
<jdstrand> wonder if github is 'smart' and doesn't send reviews after it is merged...
<jdstrand> in that light...
<ogra_> yeah, GH mail handling for PRs sucks
<ogra_> they should implement the launchpad one ;)
<jdstrand> ackk: hi! not sure if you noticed, but I added a few comments to https://github.com/snapcore/snapd/pull/3916#pullrequestreview-76430191
<mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3916>
<jdstrand> ackk: summary: I thought input validation was good but requested a few extra tests
<zyga-ubuntu> jdstrand: I think it didn't email me, I'll have to check the branch directly
<jdstrand> zyga-ubuntu: https://github.com/snapcore/snapd/pull/4163#pullrequestreview-76253522
<mup> PR #4163: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4163>
<jdstrand> zyga-ubuntu: (and the inline comments below that ^)
<zyga-ubuntu> ah, I see your notification now
<zyga-ubuntu> thanks!
<jdstrand> np
<jdstrand> zyga-ubuntu: again, if you disagree, and feel it is fine, that is 3 against 1, so it is for your consideration
<zyga-ubuntu> jdstrand: I'll take it into account and integrate parts into other RPs, the rest will be in a separate PR most likely, I need to read this carefully first
<zyga-ubuntu> jdstrand: I think partially it is just naming as I was trying to have code that I can reuse for <prefix>/<leaf> where there are N leaf functions and one function for prefix
<zyga-ubuntu> mvo: I'm looking at the tuntap test failure now
<zyga-ubuntu> cachio: hey
<cachio> zyga-ubuntu, hi
<zyga-ubuntu> cachio: how can we refresh the debian sid image we have in linode
<zyga-ubuntu> cachio: and ideally unbreak the sid vs debian 9 issue
<zyga-ubuntu> cachio: so we have the same distro in qemu and in linode
<cachio> we need to use spread-images for that
<zyga-ubuntu> do I have permissions for that? i can have a look at fixing htis if I do
<cachio> zyga-ubuntu, which kind of refresh should we do?
<zyga-ubuntu> cachio: we need to dist-upgtrade, including the new kernel, essentially
<cachio> you need to download the spread-images
<cachio> then execute with spread tasks/update
<zyga-ubuntu> aha
<zyga-ubuntu> https://github.com/snapcore/spread-images I assume
<cachio> with the image you want to update
<cachio> then you can manually install want yuou need
<cachio> and then gustavo will replace that image that you created
<cachio> I can start the image and give you the credentials
<cachio> so then I make the tear down lo clean up the image
<cachio> zyga-ubuntu, just giveme 5 minutes to start the machine
<zyga-ubuntu> ok
<zyga-ubuntu> cachio: I forked the repo
<zyga-ubuntu> er
<zyga-ubuntu> cloned it
<cachio> I am running the test
<cachio> I'll have that machine in few minutes
<ogra_> pedronis, did the behaviour of the "snap download... ; snap ack ... ; snap install ..." triplet change recently ? i was just told by someone that he didnt need to ack but could just do download and install
<mvo> zyga-ubuntu: \o/
<Chipaca> ogra_: if they've previously acked they don't need to re-ack
<zyga-ubuntu> mvo: ha, the test just passed?!?
<pedronis> ogra_: no, didn't change,  IÂ had some discussion that we might ack for you but it didn't happen
<pedronis> so far
<ogra_> well, Chipaca's answer might explain it
<mvo> zyga-ubuntu: race?
<mvo> zyga-ubuntu: did you ran it on linode?
<zyga-ubuntu> yes
<zyga-ubuntu> inside linode
<zyga-ubuntu> I doubt it is racing
<zyga-ubuntu> I'll retry
<zyga-ubuntu> Son_Goku: Fedora 27 is now released :)
<Son_Goku> yes
<Son_Goku> the fedora 27 VM needs to be distro-sync'd to GA package set
<zyga-ubuntu> mvo: it passed again, I'll send a PR re-enabling that
<mup> PR snapd#4213 opened: tests: re-enable tun/tap test on Debian <Created by zyga> <https://github.com/snapcore/snapd/pull/4213>
<roadmr> jdstrand: good morning! tools r939 is in prod as of 2 hours ago \o/
<zyga-ubuntu> mvo: I worked with cachio on an updated pair of debian images, a proper debian-9 image (new) and separately from that debian-unstable (as today) that represents a current snapshot of sid
<mvo> zyga-ubuntu: nice
<zyga-ubuntu> mvo: the stretch/9 image will be a good baseline for testing snapd in stable
<mvo> zyga-ubuntu: yeah, debian-9 will be less volatile
<zyga-ubuntu> mvo: and the refreshed image will show us the issues with mainline kernel apparmor
<zyga-ubuntu> mvo: I'll focus on resolving those with jjohansen and jdstrand
<mvo> thanks zyga-ubuntu
<cachio> zyga-ubuntu, machines are clean, now we need to wait until those are updated in linode
<jdstrand> roadmr: thanks!
<zyga-ubuntu> mvo: can you please merge https://github.com/snapcore/snapd/pull/4213
<mup> PR #4213: tests: re-enable tun/tap test on Debian <Created by zyga> <https://github.com/snapcore/snapd/pull/4213>
 * Chipaca goes to have lunch before it's tea
<elopio> nessita: I need help sending an oauth request to an SSO authenticated URL. Can you help me?
<roadmr> oauth?
<roadmr> elopio: does "surl" help here? it takes care of authentication
<ogra_> only if you dont use 2fa though
<sergiusens> kalikiana hey, how's that container work going?
<sergiusens> elopio notice a problem here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-snapcraft-daily/artful/amd64/s/snapcraft/20171114_144114_e9c38@/log.gz ?
<sergiusens> :-)
<elopio> sergiusens: ugh, I will fix it.
<mup> PR snapd#4213 closed: tests: re-enable tun/tap test on Debian <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4213>
<sergiusens> elopio thanks
<sergiusens> elopio would be good to not check the output of commands we do not control; imagine people using ours as a result of test if you cannot see my point :-)
<sergiusens> unless it is supposed to be machine readable output
<elopio> roadmr: I didn't know about surl, I will check that. I was trying with the ssoclient and requests_oauth: http://paste.ubuntu.com/25961322/
<elopio> but last time I did this was years ago, I'm not sure if I'm doing it wrong.
<roadmr> elopio: that's probably rotten :( surl does the macaroon dance, not really oauth, so depending on what you want it for, it may or may not work
<kalikiana> sergiusens: anything specific? I've got a branch for the matter of injecting the core snap but didn't propose it as to avoid taking resources off Travis
<nessita> elopio, i think so!
<nessita> elopio, tell me more
<elopio> nessita: I've just sent my script to roadmr: http://paste.ubuntu.com/25961322/
<elopio> oh, there's a bad import there, but well, that's the idea.
<nessita> elopio, what's the goal of the script? I don't think https://autopkgtest.ubuntu.com/request.cgi supports oauth authorization?
<nessita> elopio, ie SSO is not an oauth provider, is an openid provider
<nessita> elopio, the OAuth that SSO supports is not rfc compliant and works with sso APIs (its own)
<sergiusens> kalikiana have you seen your email inbox as of late?
<elopio> nessita: so, more context. I copied some bash from pitti that triggers the autopkgtests in a PPA. It uses a cookie for the request:
<elopio> https://github.com/elopio/snapcraft/blob/ppa-autopkgtest/tools/run_ppa_autopkgtests.py
<kalikiana> sergiusens: oh, were you asking about the release stuffs I guess. "that container work" sounded like some PR you were looking for. My bad.
<kalikiana> sergiusens: I'm getting myself acquainted with asciinema
<elopio> nessita: Instead of the cookie, I thought it might be better to use oauth. But, it didn't work, so I started asking and they haven't tried that. Maybe, you are right and it's not supported.
<nessita> elopio, SSO has not API for other sites to do OAuth validation
<nessita> has no* API
<elopio> nessita: so, do you know of a way to do this user/password instead of thte cookie?
<CoderEurope> http://www.rightrelevance.com/search/articles/hero?article=8461f06abc90aa4816d85711cc78e4f09d2a5bb0&query=ubuntu&emaildigest=true
<nessita> elopio, I don't think there is a way, SSO supported openid dance only which is browser/cookie based
<CoderEurope> nessita: https://help.launchpad.net/API
<CoderEurope> last edited 20-11
<elopio> nessita: well, thanks for the info. I will stop trying :)
<elopio> nessita: the script mentioned that the cookie is valid for a month. Is that a month without use? Or will I always have to refresh the cookie manually?
<elopio> omw to the meeting
<Chipaca> CoderEurope: ?
<cjwatson> CoderEurope: that's not super-relevant to autopkgtest or SSO APIs.  Launchpad uses SSO, yes, but its APIs won't help in this case.
<mup> PR snapcraft#1597 closed: pluginhandler: warn about migrated system libraries <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1597>
<mup> Issue snapcraft#1733 opened: Apply guidelines from design to error messages with commands that fix <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1733>
<zyga-ubu1tu> ok, now debian tests will probably all fail, I'll work on a PR to update them
 * zyga-ubu1tu tries
<pedronis> mvo: we haven't released 2.29 to stable right?
<cachio> pedronis, no yet
<mvo> pedronis: no, still waiting for CE for the final test-ok
<mvo> pedronis: why? any last minute issues?
<pedronis> mvo: there are store issues
<mvo> pedronis: store issues because of overload?
<mvo> pedronis: that is a good point actually, I need to tell the store about the immanent release. but if you say there are issues we should hold back with the release (cc cachio )
<pedronis> https://forum.snapcraft.io/t/snap-store-apis-outage/2832
<cachio> mvo, pedronis sure
<cachio> pedronis, is there any test that we can do
<pedronis> no, but yes, don't think it makes or is sensible to release until the store is back to normal
<cachio> pedronis,  ok
<zyga-ubu1tu> yeah, store is down for me too :?
<zyga-ubu1tu> I guess time to focus on something else
<zyga-ubu1tu> some new code :)
<mvo> heh, and I was thinking my fakestore refactor was broken
<ppisati> https://travis-ci.org/snapcore/snapcraft/jobs/301966989
<zyga-ubu1tu> mvo: I guess someone's feet are burning today
<zyga-ubu1tu> mvo: but not ours (this time)
<ppisati> this unit test fails when checking CLA check
<ppisati> do anyone know why?
<mvo> zyga-ubu1tu: maybe ours, if our client code goes crazy
<zyga-ubu1tu> mvo: interesting, yes, let's see what happens
<mup> PR snapd#4214 opened: fakestore: add go-flags to prepare for `new-snap-declaration` cmd <Created by mvo5> <https://github.com/snapcore/snapd/pull/4214>
<ppisati> kalikiana: ^
<ppisati> kyrofa: ^
<ppisati> not sure who is the most appropiate guy fo this kind of stuff
<ogra_> ppisati, i'd interpret that as 'marius@ubports.com' has not signed the CLA (though it is weird that it doesnt say that and just dies quietly)
<ogra_> i'm pretty sure he has signed (he contributed a lot to phone code before he started ubports) it but most likely not under this email address
<ppisati> ogra_: yep, but why it's failing in my test? if he didn't sign the CLA, his commits shouldn't be part of snapcraft at all - my branch is based off origin/master + my own commits
<ogra_> yeah
<ogra_> elopio, ^^^ any idea ?
 * ogra_ wonders if the snapcraft team is on a team excursion today :P
<ogra_> hiking and picnic ...
<sergiusens> ogra_ what's up? just got out of our team meeting
<ppisati> sergiusens: this failure - https://travis-ci.org/snapcore/snapcraft/jobs/301966989
<ogra_> :)
<sergiusens> ogra_ ppisati that happens on merge instead of rebase with our CLA checker tool, as the "squash and merge" functionality sets the email to the one set on github
<ppisati> sergiusens: ok, how do i fix it?
<ogra_> ppisati, obviously with a lot of patience :)
<zyga-ubu1tu> my tweet was liked/retweeted by @systemdsucks and I have lots of notifications all the time
<kyrofa> ogra_, team meeting this morning, took a little while. So you're not far off! Hahaha
<ogra_> haha
<kalikiana>  :-D
<davidcalle> elopio: kyrofa: hola, I'm looking for fresh pair of eyes on a new snap tutorial, are you interested? hhttps://github.com/canonical-websites/tutorials.ubuntu.com/pull/412
<kyrofa> sergiusens, is this the only store API doc we have? http://search.apps.ubuntu.com/docs/
<kyrofa> It doesn't seem to cover snap uploads, for example
<kyrofa> davidcalle, sure!
<kyrofa> Let me get a few reviews out of the way here, first
<mup> PR snapd#4215 opened: Fix path in snap install <Created by asalminen> <https://github.com/snapcore/snapd/pull/4215>
<CoderEurope> davidcalle: wat am I looking at ?
<CoderEurope> davidcalle: Iam here - http://tutorials.ubuntu.com-pr-412.run.demo.haus  Wat tutorial is it ?
<pedronis> kyrofa: there is this https://dashboard.snapcraft.io/docs/api/snap.html
<mup> PR snapcraft#1734 opened: recording: don't log the command when image info fails <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1734>
<kyrofa> Thanks pedronis!
<pedronis> I'm not sure how up to date it is though
<davidcalle> CoderEurope: it's in the PR description: http://tutorials.ubuntu.com-pr-412.run.demo.haus/tutorial/snap-a-website
<mup> PR snapd#4154 closed: overlord/snapstate: support completion for command aliases <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4154>
<davidcalle> CoderEurope: thanks for having a look!
<CoderEurope> davidcalle: its says some basic command line know-how --- do you want me to PM you about sugestions ?
<davidcalle> CoderEurope: feel free to leave feedback directly on the PR
<CoderEurope> davidcalle: I have never done that before - is the PR just meanings That I need a github account ?
<CoderEurope> & whois caldav ?
<davidcalle> CoderEurope: yes, once you have an account, you can leave comments there: hhttps://github.com/canonical-websites/tutorials.ubuntu.com/pull/412
<davidcalle> That's me
<CoderEurope> k
<CoderEurope> it just says I cannot comment at this time.
<kyrofa> snappy-m-o, autopkgtest 1717 xenial:armhf
<snappy-m-o> kyrofa: I've just triggered your test.
<sergiusens> kyrofa why again?
<kyrofa> sergiusens, it hasn't run without them timing out yet
<kyrofa> sergiusens, it's not enough now that you reminded me that it doesn't actually run the snaps, so I'm also running xenial:amd64 locally
<kyrofa> sergiusens, the next one doesn't need arm, though
<sergiusens> kyrofa but you retriggered an armhf test
<sergiusens> should be arm64
<CoderEurope> davidcalle: ^
<CoderEurope> nothing, http://paste.ubuntu.com/25962234/
<kyrofa> sergiusens, does arm64 run snaps?
<sergiusens> kyrofa yes
<kyrofa> Darn, I misunderstood
<kyrofa> snappy-m-o, autopkgtest 1717 xenial:arm64
<snappy-m-o> kyrofa: I've just triggered your test.
<sergiusens> kyrofa btw, what you just did was cancel the armhf test I had triggered around 6am my time as armhf is what I had triggered
<sergiusens> kyrofa did you check why it failed?
<kyrofa> sergiusens, oh! No, I just assumed it was failed from the previous run, ugh
<kyrofa> sergiusens, elopio this is the regression to which you were referring this morning, I assume? https://pastebin.ubuntu.com/25962350/
<zyga> re
<zyga> (dinner done)
<kalikiana> kyrofa: there's an extra "." there it seems
<kyrofa> kalikiana, right
<kyrofa> Or not enough, depending on your frame of reference
<kyrofa> Just wondering if I should fix it or if that's what's elopio is working on
 * kalikiana wondering to have dinner now, it's been a long day
<elopio> davidcalle: great! I'm adding it to my todo.
<elopio> davidcalle: great! I'm adding it to my todo.
<elopio> davidcalle: great! I'm adding it to my todo.
<elopio> davidcalle: great! I'm adding it to my todo.
<elopio> davidcalle: great! I'm adding it to my todo.
<elopio> upps, sorry David!
<elopio> kyrofa: yes, there's already a pr ready for review.
<kyrofa> elopio, ah ha! Okay very good, I see it now
<sergiusens> elopio do not take it out on the wrong person ð
<sergiusens> kyrofa, yeah, I had rebased your branch as it was conflicting with the timeout one
<sergiusens> kyrofa ask elopio I'd there is a way to retrieve the previous run. Should be confidence enough
<kyrofa> elopio, yeah, do you know if it's possible to see the previous adt run of a PR?
<elopio> kyrofa: Not really. Sometimes you can click the red/green button in github, and the link will be there. But not always, not sure why. The index has all the results, but it's hard to tell which corresponds to the PR. My script in progress might help.
<elopio> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-snapcraft-daily
<kyrofa> Hey zyga you mentioned that you might have more lxd info today?
<elopio> the index ^
<kyrofa> Haha, that is hilariously unparsable
<zyga> kyrofa: yes, good progress just stalled with some random (other) issues
<kyrofa> zyga, so the new solution is looking promising?
<zyga> kyrofa: yeah, it's just *annoying*
<zyga> kyrofa: the hardest one I thought of
<zyga> kyrofa: but doable
<zyga> kyrofa: so +1 :)
<kyrofa> Haha, isn't that always the case
<zyga> kyrofa: I need to unbreak debian first and then I can try to wrap that up
<kyrofa> Good deal, thanks
<zyga> kyrofa: yes, reality is fantastic at correcting assumptions
<sergiusens> elopio snapcraft#1734 failed
<mup> PR snapcraft#1734: recording: don't log the command when image info fails <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1734>
<ikey> should i wait for new snapd to be released with my changes before uploading my snaps to store?
<sergiusens> elopio retriggered the one failing test
 * ikey wonders if the snap yaml supports: assumes [works-for-me]
<sergiusens> ikey are you using assumes? If so I'd guess not... or maybe leave them on edge
<sergiusens> lol
<ikey> oh id only have them in edge
<ikey> and atm i have assumes on 2.29.2
<sergiusens> ikey then it probably is fine
<ikey> the problem im having is testing
<ikey> each time i have to remove the snap and reinstalla
<ikey> and it nukes my data
<ikey> i did also figure out that i shouldnt be using SNAP_USER_DATA
<ikey> and switched to SNAP_USER_COMMON
<ikey> dont really want gigabytes of data being transferred on update
<sergiusens> good call
<ikey> it still has nasty $SNAP_USER_COMMON/.local/share but meh
<ikey> the LSI snap exists only to support steam
<ikey> and steam.sh looks for XDG_CONFIG_HOME/XDG_DATA_HOME/etc
<sergiusens> is that because that is the default path to install steam games?
<ikey> yeah
<ikey> ~/.local/share/Steam
<ikey> or $XDG_DATA_HOME/.local/share/Steam
<elopio> sergiusens: thanks
<ikey> so im overriding the environment to suit
<ikey> shim has a magical shim_init_user function: https://github.com/solus-project/linux-steam-integration/blob/master/src/shim/shim.c#L114
<ikey> we call it further down in shim_export_extra
<ikey> passing it the value of SNAP_USER_COMMON
<ikey> its uh, pretty comprehensive.
<ikey> also meant i was able to "avoid" having a shell script entry point
<kyrofa> sergiusens, elopio what on earth is this? Failure on arm64: https://pastebin.ubuntu.com/25962979/
<kyrofa> Oh, looks like a warning is leaking
<kyrofa> That weird ResourceWarning
<elopio> kyrofa: I couldn't understand that open socket, so reported this https://github.com/msabramo/requests-unixsocket/issues/36
<elopio> but no reply :(
<kyrofa> elopio, yeah I've tried looking into the code as well, which seems just fine. I never see that warning in prod, so something is weird in adt
<kyrofa> elopio, oh dang, you can reproduce?! Nice
<elopio> I learned that the tests set that default warning filter. We could remove that as an ugly workaround
<kyrofa> elopio, do we need to dig into the unixsocket code? Although even if we propose a PR I don't have confidence it'll be noticed at this point
<kyrofa> This thing looks pretty much orphaned
<kyrofa> elopio, think that will go away if I re-run?
<elopio> kyrofa: yes, most certainly. And maybe it will also go away with your pr to reset the log.
<kyrofa> Okay, I'll re-run, and also propose that PR
<elopio> I'm fine ignoring it for 2.35.
<kyrofa> Alright
<kyrofa> snappy-m-o, autopkgtest 1717 xenial:arm64
<snappy-m-o> kyrofa: I've just triggered your test.
<mup> PR snapd#4216 opened: interfaces/time*_control: explicitly deny noisy read on /proc/1/environ <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4216>
<sergiusens> kyrofa why?
<kyrofa> sergiusens, it failed with a log leak error before it could even build the deb
<kyrofa> sergiusens, I'm rerunning since those are typically flaky, and also testing the PR I'm about to propose to fix
<sergiusens> kyrofa so it looks like a release is not happening today either...
<kyrofa> sergiusens, I'm still hoping, but given how long these tests take...
<kyrofa> sergiusens, for what it's worth, I got a successful xenial:amd64 run locally on that one
<kyrofa> And that PR doesn't _explicitly_ touch multi-arch bits
<kyrofa> Depends on how risk-adverse you're feeling
<kyrofa> How odd. sergiusens setting the log level at the beginning of the test instead of resetting it in cleanup actually doubles up the prints when it comes to tests/test_log.py
<kyrofa> It seems doing it in cleanup is the only thing that works consistently
<sergiusens> kyrofa something like snapcraft/internal/remote_parts.py:logging.getLogger("urllib3").setLevel(logging.CRITICAL) (which is manifestation of what we discussed yesterday)
<kyrofa> sergiusens, oh interesting. We should be going that in the log module alongside requests
<sergiusens> kyrofa this is only needed because we are doing things wrong
<elopio> snappy-m-o github subscribe 1734
<snappy-m-o> elopio: I'll send you a message if a test fails in the pull request #1734 (recording: don't log the command when image info fails).
<mup> PR #1734: boot: add missing udevadm mock to fix FTBFS <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1734>
<kyrofa> Yeah we need to fix
<ikey> can someone help me review my yamls before i get them ready for store upload pls? :3
<ikey> pure meta, no build instructions
<mup> PR snapd#4217 opened: interfaces/browser-support: add shm path for nwjs <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4217>
<kyrofa> sergiusens, do you want me to propose this cleanup log reset thing?
<kyrofa> I'd rather not see more test failures because of this
<sergiusens> kyrofa if you have the time, yes
<sergiusens> ikey review in what sense?
<ikey> check for jankiness
<sergiusens> jdstrand is crt available as a snap so that ikey could validate his snaps?
<mup> PR snapcraft#1735 opened: unit tests: reset log level after test <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1735>
<kyrofa> sergiusens, sure, it was already done ^ . Running adt xenial:amd64 locally on it now
<elopio> sergiusens: all green.
<kyrofa> Though I'm not sure I even need to do the whole thing given that it's only units
<kyrofa> (units have already passed)
<kyrofa> snappy-m-o, subscribe github 1717
<snappy-m-o> Command "," / ", subscribe" not found.
<snappy-m-o>  Did you mean "/snappy-m-o github subscribe" ?
<kyrofa> snappy-m-o, well look at you being so helpful!
<snappy-m-o> Command "," / ", well" not found.
<kyrofa> snappy-m-o, github subscribe 1717
<snappy-m-o> kyrofa: I'll send you a message if a test fails in the pull request #1717 (catkin plugin: check for pip packages in part only).
<mup> PR #1717: daemon,overlord: add subcommand handling to snapctl <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1717>
<kyrofa> Wow, what's the changes both PRs would be by me
<kyrofa> Uh. Chances
<kyrofa> sergiusens, uh oh. Ever tried the asciinema snap on trusty?
<kyrofa> I can't upload :P
<kyrofa> Thankfully it captured. Guess I'll just scp it over
<sergiusens> kyrofa from the snap? you need my version which has the compiled python
<kyrofa> sergiusens, I don't see one from you in snap find. Is it stable?
<sergiusens> kyrofa oh, I don't have it pushed even
<kyrofa> Hahaha
<kyrofa> You should make a PR for sabdfl
<sergiusens> I don't know where that code is, and I'd rather have it as the experiment snap to test out the classic stuff
<mup> PR snapd#4211 closed: tests: adding tests for time*-control interfaces <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4211>
<mup> PR snapd#4218 opened: tests: adding tests for time*-control interfaces <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4218>
<sergiusens> elopio I have a question on your PR
<sergiusens> kyrofa do you think my question on snapcraft#1734 is a concern?
<mup> PR snapcraft#1734: recording: don't log the command when image info fails <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1734>
<kyrofa> sergiusens, it's a good question, but I feel like elopio answered it, no?
<sergiusens> kyrofa ah, I hadn't seen the reply; still would like to see some corroborration
<kyrofa> Gah, thunderbird sucks. It doesn't upload my folders
<kyrofa> I didn't see that he answered my question either
<kyrofa> s/upload/update/
 * ikey adds handy debug tools to lsi..
<ikey> https://ibin.co/3hJKqbCtvh86.png ^^
<mup> PR snapcraft#1736 opened: recording: pass the build info flag to the container <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1736>
<elopio> sergiusens: kyrofa: I found a recording bug ^
<kyrofa> elopio, ah, good catch
<kyrofa> elopio, is that required for this release, though?
<kyrofa> Seems like an issue we've probably had for a while
<mup> PR snapcraft#1734 closed: recording: don't log the command when image info fails <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1734>
<sergiusens> snappy-m-o autopkgtest 1732 artful:amd64
<snappy-m-o> sergiusens: I've just triggered your test.
<sergiusens> elopio kyrofa I am fine with snapcraft#1736
<mup> PR snapcraft#1736: recording: pass the build info flag to the container <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1736>
<sergiusens> sort of needed to show off the feature neatly
<kyrofa> Alright
<sergiusens> kyrofa stop living in the past, go in all webapps ð©
<kyrofa> sergiusens, hahaha
<elopio> kyrofa: sergiusens: the past is the new future! Use mutt
<sergiusens> elopio can you open calendar invites there?
<sergiusens> everything is so embedded with "the web" these days that it is hard to use something that doesn't support it
<kyrofa> Apparently it's just too much to ask for decent system integration
<elopio> I would love to use a text browser. But I always give up too soon.
<elopio> sergiusens: I copy the calendar link from mutt to firefox
<elopio> but I haven't been able to configure gmail there. I need to get back to bother m vo.
<elopio> ok, I will have lunch while my new branch is green, then come back to continue recording with asciinema
<sergiusens> elopio cannot do much in text browsers theses days
<ikey> how do i go about signing a snap?
<sergiusens> ikey https://forum.snapcraft.io/t/isv-questions-about-signing-a-snap/2546
<ikey> sign-build doesn't work
<ikey> does it?
<ikey> Native builds aren't supported on Solus. You can however use 'snapcraft cleanbuild' with a container.
<ikey> nay
<sergiusens> ikey once you have the snap, you should be able to `snapcraft sign-build`, it should work and if it doesn't we can make it work
<sergiusens> btw, you read fast
<ikey> lol
<ikey> yeah i mean the main thing is i just wanna sign the snaps but i have my whole ugly manual build process
<sergiusens> snapcraft sign-build <snap-file> given all the keys are in place should be doable
<ikey> (its hella inefficient and i need to fix that)
<ikey> yea
<ikey> so i assume i have to create keys via the API only
<ikey> not my own local keys
<ikey> so they're registered in some fashion
<sergiusens> ikey internally they are just gpg keys, but I think the system is very strict on poor keys (not saying yours are); you might get away with using your current keys by means of symlinking the directory the snap command looks for
<ikey> ah ok
<sergiusens> ikey yes, snapcraft register-key pushes it to some vault on the store for corroboration
<sergiusens> ikey I am being vague on the store side, and keys for that matter, as this is not my best area of expertise
<ikey> sub   rsa4096 2016-02-22 [E] [expires: 2018-02-21]
<ikey> lol
<sergiusens> also, once you sign snaps, I don't think you can go back to unsigned ones
<sergiusens> cprov care to expand on my ignorant comments? ^
<ikey> gotcha
<ikey> fwiw in the initial stages we've no need to sign them
<ikey> as they'll be in the store on --edge only
<sergiusens> ikey fwiw, help for snapcraft says: `Usage: snapcraft sign-build [OPTIONS] <snap-file>`
<ikey> oh do i need to explicitly set grade/confinement to edge/devmode for now?
<ikey> gotcha
<ikey> er grade devel
<ikey> even
<cprov> sergiusens: what you say is true, once signed there is no reason to pull it back
<sergiusens> ikey no, no need; but if it requires devmode I would and if you do not want to accidentally have that same snap build make it to candidate or stable then set grade to devel
<ikey> yea
<ikey> ty
 * ikey was worried about that
<ikey> do base snaps have confinement..?
<cprov> the key might be revoked or expired and the signature won't be valid anymore
<ikey> ack
 * ikey is muchly looking forward to having snap updates instead of doing the whole reinstall doflicky
<cprov> sergiusens: "once you sign snaps, I don't think you can go back to unsigned ones", not true thou, there is nothing enforcing snaps to continue to be signed. 'snap-build' is per-snap-revision
<sergiusens> cprov wait I am confused, it seems you said the opposite just above :-P
<cprov> sergiusens: the scope is the snap revision, once signed it cannot be unsigned (mainly because a snap revision is immutable)
<cprov> sergiusens: in terms of workflow, subsequent revisions can be either signed or unsigned, there is nothing enforcing "signed from now on" (or anything similar)
<cprov> there are proposals like https://forum.snapcraft.io/t/isv-questions-about-signing-a-snap/2546
<cprov> sergiusens: un-confused ?
<cprov> sergiusens: and yes, I've misinterpreted your comment at first, sorry.
<sergiusens> no worries
<sergiusens> all good
<sergiusens> ikey wrt base snaps, if they have no apps entries in snap.yaml there is no reason for them to be confined, essentially what ends up being confined is what is under `apps`, so the "users" of the base snap will drive the confinement
<cprov> sergiusens: ð
<sergiusens> that said, I am not authoritative on this matter either, just using my spider senses
<ikey> sergiusens, ack :]
<sergiusens> elopio please make sure snapcraft#1736 is bullet proof
<mup> PR snapcraft#1736: recording: pass the build info flag to the container <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1736>
<sergiusens> it looks like it is, but we have been fooled before
<elopio> I tested it to confirm the fix. It's no different than the existing var, so I see no room for failure.
<elopio> But, I appreciate thorough reviews.
#snappy 2017-11-15
<kyrofa> sergiusens, snapcraft#1717 armhf had network problems during one of the ROS tests... so that won't tell us anything. Waiting on arm64
<mup> PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717>
 * ikey is doing his last clean local builds ready for upload :3
<ikey> so uhm
<ikey> Pushing solus-runtime-gaming_0.0.0_amd64.snap [===========================] 100%
<ikey> [1]    9686 segmentation fault  snapcraft push solus-runtime-gaming_0.0.0_amd64.snap
<ikey> idk what happened
<ikey> processing went kersplat
<ikey> and i believe thats because it never expected to need a manual review
<sergiusens> ikey it is python, I don't expect a segmentation fault but a traceback instead
<ikey> python is special
<sergiusens> this is much worse of a thing to track down I fear
<ikey> yeah
<sergiusens> I will look into it
<ikey> so who manually reviews snaps? :D
<sergiusens> ikey among them is jdstrand
<ikey> oh ok
<ikey> my assumption is i can't actually upload my lsi snap until the base snap is in as it depends on it
<sergiusens> ikey so the one that failed to push is the one with a base decl?
<ikey> yeah
<ikey> (NEEDS REVIEW) type 'base' not allowed lint-snap-v2_snap_type_redflag
<ikey>  0 Warnings
<ikey>  22 Passes
<sergiusens> kyrofa the arm64 test might take for ever and ever
<ikey> full error: https://hastebin.com/raw/vayobosulu
<ikey> setuid binaries won't be usable inside there anyway
<ikey> it also dislikes symlinks :p
 * ikey will nuke them for the next build to clean it up
<ikey> wtf i cant use bin in my snap
<ikey> bin/linux-steam-integration.exec glxgears does not exist lint-snap-v2_command (glxgears)
<ikey> ok the review system is dumb.
<ikey> like clinically stupid
<ikey>     command: bin/linux-steam-integration.exec linux-steam-integration.settings
<ikey> it won't accept that
 * ikey is unable to upload snaps at all, woo.
 * ikey made a workaround ^^
<sergiusens> ikey we in snapcraft wrap those in scripts
<sergiusens> the `command`
<ikey> yeah i just made it do the same
<ikey> https://github.com/solus-project/runtime-snaps/commit/3cdf7f2d9f06187a76e26465551f470561be3de2
<ikey> "tada"
<sergiusens> I don't think that review tool is geared toward reviewing base snaps
<ikey> oh that rejection was for LSI itself
<ikey> ive now got LSI actually uploaded and accepted
<ikey> but yeah it hates base snaps and forbids them
<ikey> so the solus-runtime-gaming is still pending
<ikey> ive cleaned up my base runtime for those other errors so im actually going to abandon the initial review and upload the cleaner guy
 * ikey is totally OCD
<ikey> there, rejected
 * ikey builds the new clean guy
<sergiusens> kyrofa your arm64 adt run started!
<mup> PR snapcraft#1736 closed: recording: pass the build info flag to the container <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1736>
<kyrofa> sergiusens, yeah you're right... still waiting on that :(
<kyrofa> Oh! Haha
<kyrofa> Well that's good. Another four hours...
<sergiusens> kyrofa I am going to go to bed though or I will be toast tomorrow
<kyrofa> sergiusens, yeah not worth it
<kyrofa> We'll pick it up again in the morning. Almost there
<sergiusens> kyrofa I might wake up super early though
<sergiusens> I forgot I need to prepare my presentation for pyconar this weekend too
<sergiusens> oh, and Monday is a holiday
<sergiusens> so many things to do, so little time
<kyrofa> Yeah I hear you!
<kyrofa> sergiusens, sleep well, talk tomorrow :)
<ikey> o wat dashboard has download stats
<ikey> i bet i could build a tiny bit of machinery for these lsi bits and have it automate a lot of stuff like the wrappers snapcraft style..
 * ikey creates more work for himself
<ikey> ok linux-steam-integration rev3 is on edge now
<ikey> devmode
<mup> PR snapcraft#1732 closed: tests: dotnet only works on 16.04 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1732>
<sergiusens> kyrofa I think you looked at the execution location incorrectly snapcraft#1717 armhf -> https://pastebin.ubuntu.com/25964709/ this might be a thing for elopio
<mup> PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717>
<ikey> i fixed the remaining issues with the solus-runtime-gaming, has 0 warnings now
<ikey> just 1 error
<ikey> its a base snap
<ikey> and it requested review by itself
<elopio> kyrofa: sergiusens: found it: https://github.com/snapcore/snapcraft/pull/1717/commits/b1768cc851adc1c94e08a063b2479269805a4580
<mup> PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717>
<elopio> snappy-m-o autopkgtest 1717 xenial:armhf xenial:arm64
<snappy-m-o> elopio: I've just triggered your test.
<kyrofa> sergiusens, elopio nooooooooooooo
<kyrofa> sergiusens, I didn't scroll back that far, just saw some errors in the middle of catkin tests
<kyrofa> Well, should be done by morning-ish anyway
<kyrofa> elopio, thanks for pushing a fix :)
<elopio> snappy-m-o autopkgtest 1717 xenial:armhf xenial:arm64
<snappy-m-o> elopio: I've just triggered your test.
<elopio> snappy-m-o autopkgtest 1717 xenial:arm64
<snappy-m-o> elopio: I've just triggered your test.
<zyga> o/
<zyga> mvo: hey, good morning; I'm just waking up here, any fires related to debian image update?
<mvo> zyga: good morning. all quiet on the debian image
<mvo> zyga: at least afaict, not many PRs since last night it seems
<mvo> zyga: but at least some from jamie that did succeed
<zyga> interesting
<zyga> I'll boot sid and see if anything was reverted
<zyga> last night cachio helped me refresh the image so in theory we should be running apparmor now
<kalikiana> moin moin
<mvo> zyga: cool
<mvo> zyga: yeah, I have some 2.30 tasks and need to chase why 2.29 is not in stable yet
<zyga> mvo: any fires there or just unknown?
<mvo> zyga: I'm trying to find this out now
<mvo> zyga: looks like it was a test that was giving unexpected results but upon re-testing its all good and the original traces of the issue are no longer available (which is slightly sad)
<jibel> hi, vlc from stable is no installable. I reported bug 1732359 in LP but I am not sure it's the right place.
<mup> Bug #1732359: installation snap vlc / stable fails with: ERROR open /snap/vlc/7/meta/gui/vlc.desktop: no such file or directory <amd64> <apport-bug> <bionic> <third-party-packages> <VLC media player:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1732359>
<jibel> not* installable
<mvo> jibel: thanks, looking
<mvo> jibel: and good morning :)!
<mvo> jibel: I can reproduce, its a broken symlink in the snap
<jibel> Good morning mvo
<jibel> it's weird it reached stable and no one noticed it is not installable
<mvo> jibel: yeah, also it seems like stable->edge all have the same revision of vlc
<mvo> jibel: version says "daily"
<mvo> jibel: I guess we need to reach out to them and suggest to use "daily" for "edge" and not stable :)
<zyga> mvo: note the revision, 7, meaning it's not daily
<zyga> mvo: unless they count days at pluto frequency
<mvo> zyga: why not?
<mvo> zyga: maybe they just started 7 days ago, I have no insight into this
<zyga> mvo: it was "daily" and ~5 in heildenberg
<mvo> (I honestly don't know when they started to publish it)
<zyga> (sorry for spelling that wrong)
<mvo> zyga: uhhhh, ok. so daily for a day long ago
<zyga> it's just "not actively maintianed"
<mvo> :(
<zyga> hmm, debian seems to be working
<zyga> I'll check if we get the right image for real
<zyga> eh :)
<zyga> mvo: so cachio or gustavo mixed up the two
<zyga> mvo: and "sid" and "stretch" are swapped
<mvo> zyga: heh
<mvo> zyga: ok, mystery solved
<zyga> mvo: hmm, actually, it's the same old image
<zyga> mvo: I changed sources.list in both
<zyga> we are not on the new images yet
<zyga> I guess I'll just talk to cachio later today
<Son_Goku> zyga: so I feel slightly proud of myself
<Son_Goku> I delved into the world of ELF deps and didn't drown
<Son_Goku> I didn't really like messing around with ELF data, though :/
<mwhudson> top elf tip: alias readelf='readelf --wide'
<Son_Goku> mwhudson: oh if only it were that simple
<Son_Goku> I was using libelf directly
<mwhudson> ah
<mwhudson> i actually quite like go's debug/elf
<Son_Goku> it doesn't support reading all the attributes, but it's a nice API
<zyga> Son_Goku: what are you trying to do?
<Son_Goku> do you really want to know?
<zyga> yes
<zyga> I like elf and things like tat
<Son_Goku> https://github.com/rpm-software-management/rpm/pull/360
<mup> PR rpm-software-management/rpm#360: elfdeps: Add full multiarch deps support <Created by Conan-Kudo> <https://github.com/rpm-software-management/rpm/pull/360>
<zyga> that
<zyga> is rpm going multiarch?
<Son_Goku> well, rpm is going to support it
<Son_Goku> it's up to distributions if they want to do a multiarch scheme of some kind
<Son_Goku> elfdeps is actually the only bit of rpm that wasn't multiarch-safe already
<Son_Goku> as it predates rpm's own multiarch support
<zyga> thank you for pushing that in your spare time :)
<Son_Goku> the only thing I'm not sure about is if this handles x32 properly
<zyga> Son_Goku: I played with x32 lately, I'm actually very fond of this idea
<zyga> Son_Goku: object size is very compact and you have all the instructions and registers
<Son_Goku> I don't know what it looks like from ELF
<zyga> Son_Goku: for vast majority of my work x32 is sufficient
<zyga> Son_Goku: in which sense?
<Son_Goku> oh interesting
<Son_Goku> it comes up as x86-32
<Son_Goku> that's probably not good
<zyga> I think it's called x32 more often
<zyga> but naming and off by one and so on :)
<Son_Goku> so here's the interesting bit
<Son_Goku> it is elfclass32
<Son_Goku> but machine is x86_64
<zyga> right, because that probably defines various pointer sizes and what not
<Son_Goku> right
<zyga> and I also suspect nobody thought of this when elf was designed
<Son_Goku> I think that's a pretty safe assumption
<zyga> as people thought it would just grow and grow
<Son_Goku> oh god, this means I need to special-case this
<zyga> offtopic, meld and gnome look really amazing
<sergiusens> snappy-m-o autopkgtest 1717 xenial:arm64
<snappy-m-o> sergiusens: I've just triggered your test.
<Son_Goku> zyga: and now I added handling for x32
<zyga> Son_Goku: given that an average consumer PC has 4GB of ram or less, I'd love to see windows use x32
<Son_Goku> not going to happen
<zyga> Son_Goku: so that linux folks with their 32GB machines would notice
<zyga> Son_Goku: never say never
<Son_Goku> I probably should add support for x32 to the regular elfdeps mode
<zyga> Son_Goku: microsoft is quite a surprise source lately
<Son_Goku> since I am touching that code...
<zyga> Son_Goku: and on that sense it would also make sense in arm phone world
<Son_Goku> there, absolutely
<zyga> Son_Goku: and by extension in iot
<zyga> 512MB board with 64bit CPU running in x32-like mode
<zyga> brb
<mup> PR snapd#4204 closed: store: enable "base" field from the store <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4204>
<mwhudson> eh all phone cpus just implement aarch32 still don't they?
<mwhudson> it seems noone can quite decide if arm64ilp32 is worth it yet
<zyga> mwhudson: I think the trend is clear for aarch64 being used by most now
<mwhudson> zyga: i mean, 64-bit phone cpus implement the old arm 32-bit instruction set as well
<mwhudson> there are server cpus that don't but they also have gobs of ram
<zyga> mwhudson: yes, that's true
<ikey> :( my base snap is already outdated and needs redoing
<mup> PR snapd#4219 opened: snap/validate: extend socket validation tests <Created by albertodonato> <https://github.com/snapcore/snapd/pull/4219>
<ackk> jdstrand, hi, just saw your messages from yesterday, I pushed ^^ with the changes you requested since the branch was merged already
<Chipaca> i've just logged on to not miss out on anything, but i've got to go off to the doc's for a 10:30
<Chipaca> so i won't be around until ~midday, assuming they're on time
<mvo> Chipaca: good luck!
<mup> PR snapd#4210 closed: many: add magic /snap/README file <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4210>
<sergiusens> snappy-m-o autopkgtest 1717 xenial:arm64
<snappy-m-o> sergiusens: I've just triggered your test.
<imexil> Hi, I thought to look at the yaml file of the new "official" pulsemixer snap. Anyone can point me where to find it. There isn't any kinf of docker hub equivalent website for snaps, is there?
<mup> PR snapd#4217 closed: interfaces/browser-support: add shm path for nwjs <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4217>
<mup> PR snapcraft#1735 closed: unit tests: reset log level after test <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1735>
<mup> PR snapd#4207 closed: Flesh out NVIDIA support for biarch and multiarch systems <Created by ikeydoherty> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4207>
<sergiusens> snappy-m-o autopkgtest 1717 xenial:i386
<snappy-m-o> sergiusens: I've just triggered your test.
<kalikiana> hrm, asciicasting is harder than it looks, when you make stupid mistakes like leaving a folder around after the dry run
<pedronis> mvo: is master broken? I got a couple of emails about it, though recent merges seemed innocent enough
<mvo> pedronis: yeah, it was a prepare problem that looked like a fluke but I just got the second error mail, I'm looking now
<mup> PR snapd#4220 opened: snapd: allow hooks to have slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/4220>
<mvo> pedronis: it looks like the opensuse repo has a hickup, I will disable opensuse for the moment I think
<mvo> 4214 needs a second review - should be easy peasy
<zyga> mvo: done
<mvo> zyga: \o/
<mup> PR snapd#4214 closed: fakestore: add go-flags to prepare for `new-snap-declaration` cmd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4214>
<mvo> pedronis: I am updating the roadmap right now, anything I need to add to 2.29 from your side except "make --ignore-validation sticky"? (I was looking for tags "pedronis" :)
<pedronis> mvo: for 2.29 that's it, and some improvement bits on that are in 2.30
<mvo> pedronis: thank you
<mvo> a bit of a meta question, it would be nice to have a way to tag topics from upcoming to "done" (or done-2.29) this would make writing the roadmap much simpler
<mvo> (or "done", "2.29")
<mvo> "upcoming" "2.29"
<pedronis> interesting, I tend to put in topic  "this will be avaliable in 2.xx+"   when things have landed, but not easy to search on that
<pedronis> mvo: in theory we (Gustavo) put stuff in the roadmap topic that we know will come
<pedronis> but there's often more/smaller stuff too
<pedronis> also don't know how that process will change
<pedronis> mvo: I would be ok to have further tags personnaly
<pedronis> mvo: I think I wrote already that I fell we have too many things in upcoming and is a bit unclear what is really upcoming (next 2 releases or so)
<pedronis> s/fell/feel/
<mvo> pedronis: yes
<mvo> Chipaca: silly question, do we have a forum topic describing the new ansimeter?
<kalikiana> sergiusens: I sent you my gist. also note the bug I just found... I'll make a PR for it asap
<pedronis> mvo: btw there is something weird with  roadmap topic links,  many don't work for me but if I retype the last bits they work
<mvo> pedronis: I have the same problem, when I click on them directly they give me an error but when I open them in a new tab thinks work as expected
<pedronis> mvo: wonder if it's the syntax or something about perms we don't understand
<mvo> Chipaca, zyga, pstolowski please double check if https://forum.snapcraft.io/t/the-snapd-roadmap/1973 for 2.29 and 2.30 reflects reality or if I forgot anything (cc niemeyer :)
<mvo> pedronis: yeah, worth raising during the standup I think, maybe gustavo knows (he knows the software best afaict)
<niemeyer> pedronis: It's okay to have further tags.. the main concern (mine, at least) is always that when it gets too fiddly in general it gets forgotten over time
<niemeyer> pedronis: As long as we can stick to it, more metadata is good
<niemeyer> pedronis: As long as it's useful as well, obviousy
<niemeyer> ... and on that note, I really need to get driving or we won't get there today
<niemeyer> o/
<pedronis> yea, I tend to be ok with process (within reason), but yes unclear we follow already current process
<niemeyer> Ah, last note, per forum note, if you have some headshot/upper body pictures you're comfortable with (core team), please send it along so I can build a nice slide for the talk
<pedronis> mvo: this is also 2.30  https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774 and needs more work ?
<mup> PR snapcraft#1737 opened: cli: pass remote from container_config to clean method <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1737>
<axino> hi
<axino> would anyone know how to deal with https://paste.ubuntu.com/25967274/ ?
<zyga> axino: hey there
<ogra_> did you manually tinker with the mount ?
<zyga> axino: it's a known bug, I looked at it extensively though I don't know if there's something simple that would work around it for you
<axino> not that I know of
<zyga> ogra_: it's a bug in 14.04 and inside containers
<ogra_> ah, 14.04 ...
<axino> (this is a xenial container yes)
<zyga> ogra_: this is a container here actually
<zyga> axino: not sure if this will help you, but:
<ogra_> yes, i noticed the container
<zyga> axino: you can unmount those things manually (all the mounts in /snap/*/*)
<zyga> axino: then you should be able to: sudo mount --bind /snap /snap; sudo mount --make-rshared /snap;
<axino> FWIW I found I could "snap changes" and "snap abort" but it doesn't help
<zyga> axino: then you should be able to sudo systemctl start each of the mount units
<zyga> axino: and then it should recover
<zyga> axino: that's roughly what my in-progress fix is trying to do
<axino> zyga: should I stop snapd first ?
<zyga> axino: you can but it doesn't (should not) matter
<axino> zyga: now the core snap is broken :x
<zyga> axino: did you mount everything back?
<zyga> axino: ideally paste the steps you took
<zyga> axino: look at /etc/systemd/system and start all the mount units back (or mount them manually)
<axino> zyga: https://pastebin.ubuntu.com/25967312/
<axino> (what I used to start the mounts back)
<ikey> who can i beg or bribe for snap store review? :)
<axino> err
<axino> the units I started are gone
<mvo> pedronis: yes
<mvo> pedronis: thank you
<zyga> axino: hmm
<zyga> axino: what is actually mounted?
<axino> zyga: it was looking like this https://pastebin.ubuntu.com/25967315/
<zyga> no
<zyga> I mean moubted
<zyga> not what systemd things
<zyga> thinks*
<axino> zyga: https://pastebin.ubuntu.com/25967318/
<mvo> niemeyer: how would you feel about adding a "2.30" tag (and same for subsequent releases)? then we could tag topics as "upcoming", "2.30" and the roadmap would be slightly simpler to build
<zyga> axino: how about /proc/self/mountinfo
<axino> zyga: https://pastebin.ubuntu.com/25967323/
<pedronis> mvo: he answered, I think he said ok if we manage to stick to it
<mvo> pedronis: aha, cool. sorry missed the reply
<zyga> axino: ok this looks good now
<zyga> axino: now go to /etc/systemd/system and look at the mount units you see
<mvo> niemeyer: thanks about your reply for the tags
<zyga> start the core one
<axino> zyga: https://pastebin.ubuntu.com/25967332/
<axino> OK starting the last core one
<zyga> axino: ok, start each one one by one
<zyga> axino: then start snapd
<axino> zyga: OK we're back in business
<zyga> axino: and that should work
<axino> zyga: thanks o/
<zyga> axino: and my fix is doing essentially that, just working on some details
<axino> ok
<zyga> axino: thank you for testing this! :)
<axino> zyga: will that impact every "snap remove" under LXD ?
<zyga> axino: no
<zyga> axino: well, the bug affects a lot of things
<zyga> axino: the fix I made is changing the mount sharing for /snap before the very first app ever runs on a given system/container
<zyga> axino: then it's all good
<axino> ok
<zyga> axino: what we did here was the more costly/complex recovery process
<Chipaca> mvo: i did not write about ansimeter
<mup> PR snapcraft#1738 opened: unit tests: make the check for output less strict <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1738>
<pedronis> Chipaca: did you see this: https://forum.snapcraft.io/t/do-not-print-the-progress-bar-when-running-snap-commands/2816 ?
<Chipaca> pedronis: i hadn't; commented
<zyga> jdstrand: around?
<cachio> mvo, PR #4218
<mup> PR snapcraft#1739 opened: Lxd refresh remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1739>
<mup> PR #4218: tests: adding tests for time*-control interfaces <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4218>
<cachio> this is the new one
<cachio> I closed the other one before more people look at it
<cachio> mvo, https://travis-ci.org/snapcore/snapd/builds/302294954#L4740
<cachio> this is the error I see in ubuntu core, with timezone = n/a
<pedronis> mvo: will you create the 2.30 2.31 tags ?
<sergiusens> kalikiana how confident are you in your PRs?
<sergiusens> kalikiana can you add notes on what you tested?
<kalikiana> sergiusens: I tested only from git - building snaps for testing takes a while... even if theoretically it shouldn't be relevant here, it seems best to check that
<kalikiana> lemme document what I did
<sergiusens> kalikiana please check
<zyga> tea
<ackk> jdstrand, updated the PR, thanks for the review
<om26er> flexiondotorg: around ?
<jdstrand> zyga: hey, yes
<jdstrand> ackk: thanks!
<zyga> jdstrand: I updated the secure-file PR
<Chipaca> pstolowski: what snap can i use to play with config?
<Chipaca> was looking for 'test-snapd-conf*' but that's not it
<mvo> pedronis: sorry for the slow reply, I am still trying to figure out how to define new tags
<Chipaca> pedronis: where?
<Chipaca> um
<Chipaca> mvo: where?
<Chipaca> :-)
<pstolowski> Chipaca, do you need something for a spread test?
<mvo> Chipaca: in the forum
<Chipaca> pstolowski: for playing with snnapshots
<Chipaca> mvo: you need admin
<Chipaca> i think
<mvo> Chipaca: I have this (I think) - maybe not enough of it
<Chipaca> mvo: what tag do you want to create? mind if i do it for you?
<mvo> Chipaca: sure, 2.30
<mvo> Chipaca: the tag should be "2.30", then we can tag topics as "upcoming", "2.30", "chipaca"
<mvo> etc
<Chipaca> mvo: so, there isn't an explicit CRUD for tags; you create the tag when you use it
<Chipaca> mvo: is there anything i can tag for you?
<Chipaca> mvo: also: no dots in tags
<jdstrand> zyga: I saw. it is on my list for today
<zyga> thanks!
<flexiondotorg> om26er: Hello
<pstolowski> Chipaca, ondra may have some examples for you. i think there are still very few of them. you can always package one of our tests/lib/snaps/ for local testing; if you only need to check that config is stored/restored, then you don't really need any logic in configure hook
<Chipaca> pstolowski: right, that's what i was asking: what in tests/lib/snaps is a good one to use for playing with config
<pstolowski> Chipaca, any of those I guess - http://pastebin.ubuntu.com/25967995/ - probably those with empty configure will be best
<pstolowski> Chipaca, and looks like config-versions spread test may be an inspiration?
<Chipaca> ok, i'll look, thank you
<om26er> flexiondotorg: re my Android Studio snap, any update ?
<om26er> https://forum.snapcraft.io/t/classic-confinement-for-android-studio/2634/9
<pedronis> Chipaca: 2_30 then ? 2dot30 ?
<pedronis> can then start with a number?
<pedronis> *they
<kalikiana> Hrm. `error: cannot refresh []: cannot refresh snap-declaration for "core": Get
<kalikiana>        https://api.snapcraft.io/api/v1/snaps/assertions/snap-declaration/16/99T7MUlRhtI3U0QFgl5mXXESAiSwt776?max-format=2:
<kalikiana>        dial tcp: lookup api.snapcraft.io on [::1]:53: read udp [::1]:35870->[::1]:53:
<kalikiana>        read: connection refused`
<kalikiana> This is "snap refresh" in a LXD container
<elopio> popey: flexiondotorg: can you please review https://github.com/snapcrafters/vault/pulls
<pedronis> Chipaca: I'm confused, afaict you cannot create them on the fly
<zyga> kalikiana: is it just temporary?
<popey> elopio: looking now
<kalikiana> zyga: I've reproduced it a few times now.
<kalikiana> I'm checking if it has anything to do with the particular server
<Chipaca> pedronis: you can't; I can
<Chipaca> pedronis: neener neener
<pedronis> that's good
<Chipaca> it's super dangerous, for fat-fingered me :-)
<Chipaca> pedronis: 2-30 would work
<pedronis> Chipaca: this for example would need 2.30:  https://forum.snapcraft.io/t/do-not-print-the-progress-bar-when-running-snap-commands/2816
<pedronis> Chipaca: and the things in the roadmap under 2.30
<Chipaca> I'll tag that one
<pedronis> heh sorry
<pedronis> I miscopied
<Chipaca> 2_30, or 2-30?
<pedronis> Chipaca: IÂ meant this one: https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774
<pedronis> Chipaca: I'm partial to2_30
<Chipaca> boom
<kalikiana> zyga: seems to be fine in one but not the other... now to wonder what's happening there
<kalikiana> zyga: now it works
<mvo> thanks Chipaca
<kalikiana> sergiusens: I documented my steps for both PRs. First one ran into network issues on Travis so tests re-triggered. Second one still pending.
<Chipaca> mvo: pedronis: ftr jdstrand can also do this
<kalikiana> elopio: perhaps you could sanity-check my test code? snapcraft#1737 and snapcraft/pull/1739
<mup> PR snapcraft#1737: cli: pass remote from container_config to clean method <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1737>
<mup> PR snapcraft#1739: Lxd refresh remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1739>
<Chipaca> mvo: and so can you! :-) heh
<Chipaca> mvo: and ev and noise
<Chipaca> Â¯\_(ã)_/Â¯
<mvo> Chipaca: oh, we can create tags now?
<Chipaca> mvo: you should've been able to do it before
<mvo> Chipaca: what is the magic to do it? I just create one on the fly?
<Chipaca> mvo: yes
<mvo> ta
 * kalikiana tea break
<mup> PR snapcraft#1738 closed: unit tests: make the check for output less strict <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1738>
 * sergiusens is having an excellent time with 39 Celsius and a power outage
<Chipaca> sergiusens: ffffffantastic
<ogra_> i'd happily trade the 7Â°C for that
<Chipaca> ogra_: nuh uh
<Chipaca> ogra_: you can always put on more clothes
<Chipaca> ogra_: you can't get more naked than naked
<ogra_> putting your feet into a bucket of water helps though ...
<Chipaca> ogra_: especially if the bucket is in a pool
<ogra_> +1
<zyga> Chipaca: have you seen that gallery with skinless ppl?
<Chipaca> zyga: i've had lunch in a museum with skinless people, does that count?
<Chipaca> also babies in formaldehyde
<kalikiana> skinless sounds great for hot days
<zyga> Chipaca: does "cool" qualify as an answer?
<Chipaca> zyga: Â¯\_(ã)_/Â¯
<Chipaca> zyga: my secondary school was next to a medical science school that had a museum you could just walk into
<Chipaca> lots of weird stuff
<Chipaca> anyhoo
<zyga> Chipaca: "do your homework or you end up in a barrel like the rest of exhibits" the biology teacher said ;-)
<Chipaca> pstolowski: config doesn't have the idea of per-user data, right?
<pstolowski> Chipaca, correct
<zyga> Chipaca: per user snaps would be interesting but also hard
<Chipaca> zyga: yeah, i think i'm going to store snap's config only if i'm storing the system data, otherwise no
<Chipaca> (there's a per-user aspect to snapshots, and a system aspect)
<Chipaca> makes sense to me :-)
<sergiusens> Chipaca ogra_ I'll take the 7 Celsius any day of the year
<sergiusens> power just came back! \o/
<kyrofa> sergiusens, man we can't catch a break on snapcraft#1717
<mup> PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717>
<kyrofa> sergiusens, why i386 though? I already got a local pass on amd64
<sergiusens> just to see if that log error showed up
<kyrofa> Ah okay. Well I noticed you merged the PR that's supposed to fix that
<kyrofa> But it looks like this needs to be merged with master first
<sergiusens> kyrofa wait for it
<kalikiana> grrr, network errors on pip on both PRs
<kalikiana> FYI I need to hop on a train in a few minutes so I can't work late tonight- but I'll check back in for a bit later
<kyrofa> kalikiana, want me to run one locally?
<kyrofa> Assuming it's for 2.35
<kalikiana> kyrofa: the first one passed on the second attempt, second one pending... so, it works, it's just a waste of time...
<kyrofa> Okay
<kalikiana> kyrofa: this is concerning snapcraft#1737 and snapcraft/pull/1739 which are fixing an issue with remote lxd - if you can have a looksie that'd be appreciated
<mup> PR snapcraft#1737: cli: pass remote from container_config to clean method <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1737>
<mup> PR snapcraft#1739: Lxd refresh remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1739>
<kyrofa> kalikiana, sure thing, reviewing now
 * zyga made small progress on layouts :)
<mup> Bug #1732494 opened: Impossible to manage package after Trusty --> Xenial upgrade <apport-bug> <i386> <third-party-packages> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1732494>
<ppisati> elopio: can you help me with the CLA check failing for this pull req?
<ppisati> elopio: https://github.com/snapcore/snapcraft/pull/1720
<mup> PR snapcraft#1720: kernel plugin: introduce kernel-channel to select from which channel â¦ <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1720>
<kalikiana> kyrofa: Grand, thanks!
<ppisati> elopio: i think you are the keeper of the 7 keys^W^W^W... i mean unit tests :)
<mvo> ppisati: heh, you just made me switch my music
<ppisati> mvo: at least someone got the joke :)
<mvo> ppisati: :-D /me hums along
<Chipaca> hahahaha
<Chipaca> hhaa
<Chipaca> hqa
<Chipaca> dhe391edcf :flips table:
<elopio> ppisati: how weird, it shows no error. I hate this CLA check, like a year ago I asked if it would be possible to move to the github integrated CLA check, but nothing happened :(
<Chipaca> so... golang on 32-bit archs can only see half of the users on the system
<Chipaca> of all the *possible* users i mean
<elopio> ppisati: let me updated your branch, that at least will reduce the number of checks
<zyga> Chipaca: ?
<zyga> Chipaca: ??
<zyga> Chipaca: why is that?
<Chipaca> getuid and co return an int
<Chipaca> uid_t and co are 32 bit unsigned
<mup> PR snapd#4221 opened: tests: new test for interface network status <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4221>
<Chipaca> zyga: https://github.com/golang/go/issues/22739
<zyga> Chipaca: well that will show those 32 bit users ;)
<Chipaca> zyga: we are going to be using uids somewhere in that space
<Chipaca> for our per-snap uids
<zyga> Chipaca: well, that ended quickly
<zyga> Chipaca: can we use negative integers? ;-)
<Chipaca> zyga: no, that's the problem
<Chipaca> syscall.Getuid returns a negative number
<Chipaca> and then that's looked up in /etc/passwd
<Chipaca> guess how well that works
<Chipaca> :-)
<kyrofa> Chipaca, oops
<diddledan> I've got really weird behaviour. I have created a patch which I'm trying to apply in a snapcraft prepare script. Doing the steps manually works, but when I try to do it via snapcraft the git apply call just silently does nothing
<Chipaca> and the reason you can't create a user with uid -1 is because that's a special flag value that means "don't change the uid"
<Chipaca> (by -1 i mean 0xf...f obvs)
<diddledan> my prepare script is: git apply --stat $SNAPCRAFT_STAGE/unrar.patch
<diddledan> I've confirmed the patch is at $SNAPCRAFT_STAGE/unrar.patch, and I've confirmed that I'm in the build folder with the source I'm trying to patch
<elopio> popey: one more, please https://github.com/snapcrafters/vault/pull/6
<mup> PR snapcrafters/vault#6: Update the grade to stable <Created by elopio> <https://github.com/snapcrafters/vault/pull/6>
<popey> elopio: done
<elopio> thank you
<Chipaca> diddledan: are you in the directory you think you are when you try to do that?
<diddledan> yes, I've confirmed that
<diddledan> trying to replicate it in a minimal build doesn't recreate the problem. It's only on my complex build that's failing
<kyrofa> diddledan, which plugin?
<diddledan> make
<kyrofa> diddledan, remember that the prepare scriptlet runs in the build dir, not the source dir
<diddledan> it's this part that fails on my attempt to build calibre, but pulling it to it's own snapcraft.yaml doesn't fail:
<diddledan> https://www.irccloud.com/pastebin/wqlPNJXA/
<diddledan> the patch is:
<diddledan> https://www.irccloud.com/pastebin/Mv9VK6TH/
<kyrofa> Hmm, yeah I don't see anything wrong there
<diddledan> full calibre snapcraft.yaml which FAILS (the above parts don't fail when isolated like that) is:
<diddledan> https://www.irccloud.com/pastebin/MTOl6x2y/
<kyrofa> diddledan, dumb question: do you have git installed?
<kyrofa> (it's not a build-package)
<mup> PR snapd#4222 opened: tests: add new `fakestore new-snap-{declaration,revision}` helpers <Created by mvo5> <https://github.com/snapcore/snapd/pull/4222>
<kyrofa> ah, yeah that one will install git
<diddledan> snapcraft installs git itself automatically. it doesn't need to be manually specified. even if it did need to be specified it's working enough that git is responding in both scenarios
<diddledan> specifically the behaviour is : when the parts are isolated, the `git apply` works. when in the calibre full yaml the `git apply` silently returns with exit code 0 indicating success but the source is not patched
<cachio> jdstrand, https://paste.ubuntu.com/25968840/
<cachio> Running the test to check network-status interface
<cachio> https://github.com/snapcore/snapd/pull/4221/files
<mup> PR #4221: tests: new test for interface network status <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4221>
<cachio> jdstrand, any idea why it could happening?
<kyrofa> diddledan, and you're checking the source in the build dir, not the src dir?
<sergiusens> elopio kyrofa I am beginning to thing that we should cut where we are; that test is breaking on i386 as well
<kyrofa> sergiusens, wait, no, that's the plainbox bug I logged
<kyrofa> I thought I was only seeing it locally though
<kyrofa> This is the first time I've seen it in the real adt
<kyrofa> I'll investigate now
<kyrofa> sergiusens, catkin tests look good there
<sergiusens> kyrofa ok, thanks
<Chipaca> ok, EOD'ing
<kyrofa> I think that PR is probably good, then
<sergiusens> kyrofa please rebase so that other one can get in
<kyrofa> Of course
<mup> PR snapcraft#1717 closed: catkin plugin: check for pip packages in part only <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1717>
<mup> PR snapcraft#1737 closed: cli: pass remote from container_config to clean method <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1737>
<sergiusens> kyrofa you are in charge of the boat, I need to go to physiotherapy now... my dream is to see those last remaining PRs merged and the changelog branch updated ;-)
<kyrofa> sergiusens, you got it
<kyrofa> snappy-m-o, autopkgtest 1739 xenial:i386
<snappy-m-o> kyrofa: I've just triggered your test.
<kyrofa> elopio, I'm not clear on your comment-- do you feel like snapcraft#1739 needs to change?
<mup> PR snapcraft#1739: lxd: refresh remote container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1739>
<kyrofa> elopio, hmm.... don't the debian/tests/* scripts run as root?
<kyrofa> Which means /home/ubuntu/autopkgtest_tmp is owned by root?
<kyrofa> Although you give it mode 777 I suppose
<elopio> kyrofa: I'm happy if the message on 1739 is added later.
<elopio> and yes, you wanred about that so it's 777 now.
<elopio> we could set the owner to ubuntu if there's any problem.
<kyrofa> elopio, wondering if the plainbox issue traces back to that, poking now
<kyrofa> The message on 1739 being the one I mentioned as well?
<elopio> kyrofa: yes.
<kyrofa> Agreed
<elopio> kyrofa: and this is what we do on integrationtests -> mkdir --parents /home/ubuntu/autopkgtest_tmp --mode 777
<kyrofa> elopio, oh man... see all the old snapcraft xenial:amd64 PRs running now...
<elopio> kyrofa: now the bottleneck is our fault ::(
<kyrofa> Yeah that hurts
<kyrofa> Why can we not cancel these?!?!?!
<elopio> turn it off and on again.
<zyga> Chipaca: around?
<kyrofa> elopio, do you know how adt creates lxc containers?
<kyrofa> It must be special, because I'm getting confinement issues trying to run the plainbox test
<jdstrand> cachio_afk: what is the specific apparmor denial?
<zyga> can I get a quick +1 for a trivial: https://github.com/snapcore/snapd/pull/4223
<mup> PR #4223: cmd/snap-update-ns: misc cleanups <Created by zyga> <https://github.com/snapcore/snapd/pull/4223>
<mup> PR snapd#4223 opened: cmd/snap-update-ns: misc cleanups <Created by zyga> <https://github.com/snapcore/snapd/pull/4223>
<kyrofa> elopio, although looking at the config of the running container, doesn't look special at all. Looks default
<kyrofa> Alright, plan B
<elopio> kyrofa: this is the provisioner https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/tree/virt/autopkgtest-virt-lxd#n135
<kyrofa> elopio, interesting. Sucks, I can't reproduce the same error outside of the adt suite, so I've paired that suite down to only the single snapd test, but it still needs to run the units and build the deb, haha
<kyrofa> That's alright, I'll get there
<kyrofa> But yeah, that proves that there's nothing special about it
 * zyga is hyped by https://teletype.atom.io/
<Chipaca> zyga: for a little bit
<Chipaca> zyga: wassup
<zyga> Chipaca: can you please +1 https://github.com/snapcore/snapd/pull/4223
<mup> PR #4223: cmd/snap-update-ns: misc cleanups <Created by zyga> <https://github.com/snapcore/snapd/pull/4223>
<elopio> kyrofa: my hack to do it faster is change setup.py. Also, use the ppa instead of building from source, but just if you are not changing the deb.
<zyga> I'll merge it when green and push a feature PR on top
<zyga> I just didn't want this noise in the same one
<kyrofa> Oh the setup.py, duh
<kyrofa> elopio, okay, tests disabled. But how do I tell it to use the PPA?
<elopio> kyrofa: that's what I'm working on now. I think I'm close: https://github.com/snapcore/snapcraft/pull/1643/files#diff-bc66fbdb036f79e9f15bcbf47a6bc67cR44
<mup> PR snapcraft#1643: [WIP] tests: run daily autopkgtest in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1643>
<kyrofa> Ah yes, nice
<zyga> jdstrand: FYI: a formal +1 on https://github.com/snapcore/snapd/pull/4170 would help :)
<mup> PR #4170: cmd/snap-update-ns: add planWritableMimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4170>
<Chipaca> zyga: +1 (beyond the "silly wrapper is silly" comment)
<zyga> Chipaca: thanks, I just wanted to highligh the mocking aspect, I can reword that if you have ideas
<zyga> highlight*
<Chipaca> zyga: i understood it purpose, but the wrapper isn't needed
<zyga> oh?
<zyga> aaah
<zyga> I see now
<zyga> thanks, I'll do that
<zyga> Chipaca: seeing this brings back classmethodwrapper horrors
<Chipaca> mbuahahaa
<jdstrand> zyga: it is also on the list
<Chipaca> zyga: if it's any consolation, at least you're not fiddling with the glob table
<zyga> Chipaca: oh, about that
<zyga> Chipaca: a puzzle
<zyga> Chipaca: I failed, maybe you can do better
<zyga> https://twitter.com/fijall/status/930744285728735232
<zyga> Chipaca: ^
<zyga> jdstrand: thank you!
<zyga> ah, the answer is in the responses below now
<Chipaca> zyga: it's a hacky way of having a global that survives (re)imports
<Chipaca> e.g. if you do reload() or if you import it with two different paths
<zyga> I was trying the two different paths idea
<zyga> I must have remembered this wrong
<zyga> but inter-package imports did something funky
<zyga> from .foo import bar
<zyga> vs from pkg.foo import bar
<zyga> wow, when did github start doing this: https://github.com/snapcore/snapd/blob/master/COPYING
<Chipaca> zyga: it's probably just reload() if the importer doesn't trip up
<Chipaca> zyga: or! it could be for re-exec
<cachio> jdstrand, https://paste.ubuntu.com/25969363/
<cachio> these are the denials that I saw
<kyrofa> Dang, now adt is failing with that new error as well. I'm starting to hate plainbox
<kyrofa> Either it or the way we're using it makes it such a moving target
<Chipaca> mmm
<Chipaca> zyga: Â¯\_(ã)_/Â¯ can't make it work outside of a plain reload -- which might be enough
<Chipaca> some apppservers reload() the modules of your app when you edit it
<zyga> Chipaca: I recall using reload but very rarely
 * elopio <- lunch
<sergiusens> kyrofa how are things going?
<kyrofa> sergiusens, tests still running. I'm having trouble reproducing plainbox all of a sudden as well
<kyrofa> It's a different error today :P
<kyrofa> "cannot create freezer cgroup hierarchy for snap plainbox-simple"
<kyrofa> Researching now
<kyrofa> That's coming from snap-confine
<kyrofa> zyga, any idea why I might be getting "cannot create freezer cgroup hierarchy for snap X" ?
<kyrofa> zyga, it's in a normal lxd container
<kyrofa> And then it's so broken I can't remove it
<zyga> kyrofa: no,
<zyga> kyrofa: any denials?
<kyrofa> zyga, crap. Now it succeeded. What the heck...
<zyga> post on the forum please
<kyrofa> Software is so quantum. It does X until you look at it, then it does Y just because you're looking at it
<kyrofa> zyga, did you recently release a new core snap by any chance?
<zyga> yes
<zyga> today
<kyrofa> Yeah this was working yesterday
<kyrofa> And it just happened again
<kyrofa> sergiusens, getting THAT error in adt now ^
<kyrofa> I'll make a forum post
<mwhudson> zyga: do you have any ideas for the debian breakage yet?
<kyrofa> This is interesting: "kernel_os.go:192: cannot get boot vars: open /boot/grub/grubenv: no such file or directory"
<zyga> mwhudson: I didn't look after that, jjohansen needs to say if this is a bug that we should fix in debian or in the kernel
<mwhudson> ok
<zyga> mwhudson: all I know is in the forum for that topic
<mwhudson> i guess it still makes sense to get 2.29.3.1 ready for uploading to debian even if it's not going to work for a while
<zyga> yes
<mwhudson> zyga: --enable-nvidia-multiarch, do we want that on debian?
<jjohansen> zyga: sorry I haven't figured that out yet. I'm working on it
<mwhudson> zyga: also should we stop passing --disable-apparmor now?
<mup> PR snapd#4220 closed: snapd: allow hooks to have slots <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4220>
<zyga> jjohansen: thank you!
<zyga> mwhudson: I think so
<zyga> mwhudson: the core was ablt to handle that for some time now
<zyga> mwhudson: (since ~august)
<mwhudson> zyga: which of my two questions are you answering? :)
 * mwhudson acquires coffee
<zyga> mwhudson: <should we stop passing --disable-apparmor>
<zyga> mwhudson: as for nvidia, ... not sure, perhaps yes but I never tried it because debian doesn't (AFAIK) ship proprietary drivers
<zyga> mwhudson: probably doesn't hurt
<mwhudson> mm ok
<mwhudson> there was a guy in the forum complaining about nvidia problems i think
<mwhudson> but i don't understand how any of that works :)
<zyga> mwhudson: I can explain if you want
<kyrofa> sergiusens, scratch that... I'm getting that error on _every single_ snapd test
 * mwhudson considers if he cares
<mwhudson> zyga: i've used intel graphics for years and have no intention of changing any time soon :)
<zyga> mwhudson: fair enough :)
<zyga> I think I should EOD, I'll check some PRs later and try to merge
<kyrofa> snappy-m-o, autopkgtest 1719 xenial:i386
<snappy-m-o> kyrofa: I've just triggered your test.
<kyrofa> zyga, to be clear, you released to stable today?
<mwhudson> zyga: pushed something that might build to alioth
<mwhudson> zyga: now go to bed :)
<mwhudson> kyrofa: yes, stable was updated today, according to mvo in the forum
<mwhudson> kyrofa: https://forum.snapcraft.io/t/2-29-release-cycle-started/2562/9
<diddledan> kyrofa: sorry, had to pop out. the source isn't patched ANYWHERE. neither the src directory nor the build directory. The git apply simply silently exits without patching any files, despite checking that there is a copy of that file in the directory it's executed within.
<diddledan> kyrofa: the point I've been trying to state is that the exact same bits work correctly when I pull them into their own snapcraft yaml
<zyga> kyrofa: not me personally but yes, we as a team pushed 2.29.3 to stable toda
<kyrofa> zyga, forum post published
<diddledan> so I know that it works. it doesn't work when I use my full calibre build snapcraft yaml despite the parts being identical to those that work on their own
<zyga> kyrofa: thank you
<zyga> kyrofa: after lxd bug, which is close to being fixed, I will look at this
<kyrofa> Thanks zyga
<kyrofa> elopio, can you think of any reason why I would get that error when running the test, but not when installing the snap by hand?
<diddledan> in fact, even separated it doesn't patch anything, so I was wrong there
<diddledan> the following snapcraft.yaml doesn't patch anything
<diddledan> https://www.irccloud.com/pastebin/5rktodoh/
<diddledan> same patch as before: https://www.irccloud.com/pastebin/Mv9VK6TH/
<diddledan> patch lives in ./patches/unrar.patch and snapcraft.yaml lives in ./snap/snapcraft.yaml
<nacc> "Instead of applying the patch, output diffstat for the input. Turns
<nacc>            off "apply"."
<nacc> diddledan: why are you passing --stat ?
<nacc> diddledan: seems like user error to do so :)
<diddledan> it doesn't work either way
<zyga> jdstrand: hey, just a word of caution: the tun/tap test is failing randomly
<zyga> jdstrand: we've seen it fail in lots of branches
<nacc> diddledan: well, it definitley will not (and should not) do anything with --stat
<zyga> jdstrand: it goes away on retry sometimes, not sure if you can think of anything in particular that would be specific to that test
<diddledan> https://www.irccloud.com/pastebin/MTOl6x2y/ is the full project which is failing
<nacc> diddledan: but wait
<nacc> diddledan: reading...
<nacc> diddledan: (tbh, i fid it confusing to use a source that's not git with a git command)
<nacc> diddledan: i don't think there's any guarantee provided that you actually have git
<nacc> diddledan: it probably works in general, but just a note
<nacc> diddledan: did you try to do the build interactively? e.g., stage patches, then try to stage unrar and see what happens?
<diddledan> I don't know what you mean "do the build interactively"
<nacc> diddledan: like you can run `snapcraft` and it will build all the steps of the snap (I recommend in a LXD or vm) or you can do `snapcraft stage <part>` and just ahve it stage that part
<nacc> diddledan: so maybe stage patches, take look at hte stage directory
<nacc> diddledan: then stage unrar and see what it does
<diddledan> without --stat I get no feedback, which is expected. BUT the simplified testcase reverts to my assumption in that it works fine, but the complex calibre build fails
<diddledan> it's the same damned part definition in both casess!
<nacc> diddledan: do you have a repository i can clone?
<diddledan> I can make one
<nacc> diddledan: might be easier (although i'm not a snap expert myself -- i can at least try and recreat your issue)
<diddledan> https://github.com/diddledan/calibre-snap
<nacc> diddledan: so i'm not sure if i follow -- is there a simple snapcraft yaml that does show the issue?
<diddledan> no
<nacc> ok
<diddledan> the simplified testcase works fine
<diddledan> with the same bloomin part definitions!?!
<diddledan> I'm bashing my head against a wall here :-(
<diddledan> it doesn't make any sense whatsoever
<jdstrand> zyga: it is only debian-unstable-64, right?
<sergiusens> kyrofa subprocess.check_call by hand and see what happens
<sergiusens> kyrofa why is adt running for snapcraft#1739 ?
<mup> PR snapcraft#1739: lxd: refresh remote container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1739>
<kyrofa> sergiusens, I figured we wanted to get at least one pass on everything, no?
<sergiusens> kyrofa travis already does that ;-)
<kyrofa> sergiusens, haha, feel free to merge if you're happy with it, but the number of problems we built up because of exactly that is, well, not good
<zyga> jdstrand: no, it also happened on 16.04-32 once
<zyga> jdstrand: mvo thinks it is a race
<zyga> jdstrand: or perhaps a sequence issue where earlier test is causing this one to fail
<mup> PR snapd#4223 closed: cmd/snap-update-ns: misc cleanups <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4223>
<jdstrand> zyga: if you want to disable the test and then assign me to fix it, I can look into it
<mup> PR snapd#4224 opened: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4224>
<zyga> jdstrand: I think that's fine, I'll send a PR
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/4224 is interesting, there are a few lines of changes there and lots of tests
<mup> PR #4224: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4224>
<zyga> jdstrand: reading the description will make the context for other layout PRs richer
<nacc> diddledan: sorry, but your yaml makes very little sense to me :)
<nacc> diddledan: how woudl `git apply` work if you're not i na git repo?
<diddledan> it works fine
<nacc> diddledan: you are giving it a raw tarball and asking it to treat it as a git repo? you should be using patch
<jdstrand> zyga: added to list
<nacc> diddledan: i don't see how it can (in general) ... the source isn't a git repo
<diddledan> except in this particular case. if I pull everything except the patches and the unrar parts it works correctly. it only fails in situ with the rest of the yaml
<nacc> diddledan: if you just use patch, does it work?
<diddledan> git apply doesn't require a git repo
<diddledan> I've proven the concept works. it is only in that full yaml that it fails
<nacc> diddledan: ok
<mup> PR snapd#4225 opened: cmd/snap-update-ns: tweak changePerform <Created by zyga> <https://github.com/snapcore/snapd/pull/4225>
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/4226 this is the tuntap test, please merge that when green
<mup> PR #4226: tests: disable interfaces-network-control-tuntap <Created by zyga> <https://github.com/snapcore/snapd/pull/4226>
<mup> PR snapd#4216 closed: interfaces/time*_control: explicitly deny noisy read on /proc/1/environ <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4216>
<mup> PR snapd#4226 opened: tests: disable interfaces-network-control-tuntap <Created by zyga> <https://github.com/snapcore/snapd/pull/4226>
<mup> PR snapcraft#1739 closed: lxd: refresh remote container <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1739>
<mup> PR snapd#4202 closed: cmd: use a preinit_array function rather than parsing /proc/self/cmdline <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4202>
<zyga> jdstrand: if you want to please collect logs from https://travis-ci.org/snapcore/snapd/builds/302045926?utm_source=github_status&utm_medium=notification
<zyga> jdstrand: this is where the test failed
<zyga> jdstrand: the sequence number could be useful for reproducing this
<zyga> jdstrand: once you collec that, please re-trigger the test
<zyga> another instance is here: https://travis-ci.org/snapcore/snapd/builds/302478451?utm_source=github_status&utm_medium=notification on ubuntu-core this time
<nacc> diddledan: so i staged everythinng, actually tried ot build it, got an error
<diddledan> bingo
<nacc> i went into the parts/unrar/src directory
<nacc> ran `git apply ../../patches/install/unrar.patch` and it did nothing
<zyga> the denial here is [Wed Nov 15 13:41:22 2017] audit: type=1400 audit(1510753282.329:205): apparmor="DENIED" operation="open" profile="snap.test-snapd-tuntap.tuntap" name="/dev/net/tun" pid=9534 comm="tuntap.py" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
<nacc> not a snapcraft problem, afaict, git doesn't want to apply the patch
<nacc> diddledan: patch works
<diddledan> now, nuke the parts, stage and prime directories and try again with this yaml (which is the same yaml with everything except unrar and the patch removed):
<diddledan> https://www.irccloud.com/pastebin/to0fUZYt/
<diddledan> and your git apply command was missing a ../ which is why your manual apply failed
<nacc> diddledan: no it wasn't?
<nacc> parts/patches/install/unrar.patch is what i wanted
<diddledan> oh maybe not missing a ../ - you're using the one copied into parts/
<nacc> diddledan: which is what snapcraft would be doing
<diddledan> nope, snapcraft is using the one in stage/
<nacc> well, in this case the same file
<nacc> diddledan: so, i'm going to say it one last time, because i've wasted way too much time on this
<nacc> diddledan: i jsut did exactly what you said
<nacc> the patch is also not applied
<nacc> the parts happen to build
<nacc> but http://paste.ubuntu.com/25970392/
<nacc> git-apply fails to apply the patch
<nacc> patch succeeds
<nacc> stop using git-apply :)
<diddledan> seriously, git apply WORKS ON IT'S OWN!
<nacc> no, it doesn't
<nacc> look at the above output
<diddledan> ffs
<nacc> diddledan: please, just try with plain patch
<nacc> see if it works
<nacc> diddledan: if `git-apply` worked, i can provide another paste for this, thenn running git-apply, then running patch would result in patch reporting an error. It does not
<nacc> diddledan: i will admite freely, i didn't know you could `git-apply` outside of a git repository. I don't know why you would want to, or what it gains you, but I am seeing a difference in behavior between git-apply and patch. I trust patch.
<kyrofa> +1 on patch
<nacc> diddledan: http://paste.ubuntu.com/25970412/ ... that's the paste i mentioned
<diddledan> because you refuse to believe it works: https://paste.ubuntu.com/25970413/
<diddledan> that is using the tarball snapcraft downloads and the patch I'm trying to apply
<diddledan> like I said, it works damned fine until I put it in the calibre snapcraft.yaml
<nacc> diddledan: is the patch actually applied?
<diddledan> yes
<diddledan> or rather it is once I remove the --check because that kills apply like --stat does
<diddledan> from the source that I just applied the patch to which isn't in a git repo, and had the patch applied with git apply:
<diddledan> https://www.irccloud.com/pastebin/mXdBs4WB/
<diddledan> that is what I want the patch to do, make those two lines look like that!
 * zyga looks at Nov 15 12:32:38 Pandora kernel: [15491.386617] audit: type=1400 audit(1510777958.562:790): apparmor="DENIED" operation="capable" namespace="root//lxd-brave-muskrat_<var-lib-lxd>" profile="/snap/core/3440/usr/lib/snapd/snap-confine" pid=28464 comm="snap-confine" capability=2  capname="dac_read_search"
<zyga> stgraber: (if around) does lxd/lxc do something special to systemd freezer cgroup?
<nacc> diddledan: ok, i can see the bheavior you are seeing but I don't know why
<nacc> diddledan: and i don't konw why in the snap directories, the same does not work
<diddledan> don't use --check
<nacc> diddledan: i would still be curious if just patch would work, if it's a weird thing with git (corner case)
<nacc> diddledan: i wasn't
<nacc> diddledan: if you really can't get it to work, just fork it on github and patch your source?
<diddledan> oh frak me. I've just had a lightbulb and it's too damned bright it hurts
<nacc> diddledan: what's that?
<diddledan> my snapcraft is in a git repo. git recurses to all your subdirectories. previous uses of git apply had been in their own git repo checked out by snapcraft which overrode the snapcraft repo. you're right in that it's because it's not a git repo, but not just that, it's because it's not a git repo and THEREFORE INSIDE MY SNAPCRAFT git repo
<nacc> diddledan: ah
<nacc> diddledan: so it seems like ither use a git repo as the source, or use patch?
<diddledan> so because it detected the .git dir way back up the chain it decided "I don't care that you were in that subdir, I'm going to apply your patch to the top-level where .git is!"
<nacc> right
<nacc> i thikn that's configurable -- i wonder if that should be set by snapcraft when it invokes git
<nacc> since it can non-git nested inside git
<nacc> should be relatively easy to make a testcase that shows the issue
<diddledan> this looks to be the correct incantation for such an occurance: git apply --directory=. --unsafe-paths ../../../stage/unrar.patch
<diddledan> or as you said, just use patch
<nacc> diddledan: fun :)
<diddledan> fudge me, that was confusing
<nacc> diddledan: we were both right and wrong :)
<diddledan> and of course it worked in my testcase because I made the testcase in a new dir that wasn't a git repo
<nacc> right
<mup> Bug #1732555 opened: Installing bad snap has snapd crashing <Snappy:New> <https://launchpad.net/bugs/1732555>
<mup> PR snapd#4227 opened: tests: adding test for interface frame buffer <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4227>
<diddledan> that incantation doesn't work actually. reverting to patch :-)
<diddledan> wow, I am glad I know what was happening now, but boy what an idiot was I!?! :-p
<diddledan> anywho, tis sleepytime methinks
<kyrofa> elopio, do the bot subscriptions actually work for you? It never pings me on failures
<kyrofa> snappy-m-o, github subscribe 1719
<snappy-m-o> kyrofa: I'll send you a message if a test fails in the pull request #1719 (many: account for python shebang args in rewrite).
<mup> PR #1719: firstboot: add firstboot assertions importing <Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1719>
<kyrofa> I'll try again anyway
<elopio> kyrofa: it worked last time I tried, but haven't in a long time
<elopio> kyrofa: please let me know if you don't receive it, and I'll debug.
<kyrofa> elopio, will do
<kyrofa> elopio, is it technically possible for it to ping me when it finishes, regardless of success, and TELL me whether it succeeded or not?
<kyrofa> Or is there no trigger for that?
<kyrofa> (totally don't know how the bot works)
<mup> PR snapd#4226 closed: tests: disable interfaces-network-control-tuntap <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4226>
<elopio> kyrofa: the bot doesn't know how many tests are running. It just sees when one finishes.
<elopio> so to report success, you would have to give it the number of tests you expect. Or something more clever than that. Currenly, we have nothing like that.
<kyrofa> elopio, you mean like the number of tests in a single adt run?
 * kyrofa makes a google code-in task to count all our tests
<elopio> kyrofa: no, the number of tasks reported to the pr.
<kyrofa> Haha, oh
<kyrofa> elopio, so say I trigger both xenial:amd64 and xenial:i386
<elopio> currently, what it does is to listen on the updates to the PR. If one is a failure, it will ping you. Or something like that, I don't remember all the details
<kyrofa> Regardless of success or failure, will it get two reports back from adt?
<kyrofa> If so, I'd love to have it ping me twice, once with each result
<elopio> kyrofa: well, you could subscribe also to successful results. Not implemented, but that is easy.
<elopio> https://github.com/elopio/snappy-m-o/blob/master/plugins/snapcraft_github/snapcraft_github.py#L57
<kyrofa> elopio, ah, nice! Now I can make PRs when I want stuff?
<elopio> kyrofa: do you mean, PRs to the bot? Of course!
<kyrofa> Definitely
<kyrofa> And it looks like it's a snap?
<kyrofa> github_build is an interesting looking function
<kyrofa> elopio, how do you test this, though?
<kyrofa> elopio, first PR made
<mup> PR snapd#4228 opened: interfaces,tests: skip unknown plug/slot interfaces <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4228>
<mup> PR snapd#4229 opened: interfaces,tests: skip unknown plug/slot interfaces <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4229>
 * zyga EODs
<sergiusens> kyrofa elopio why have the tests restarted? Can you at least add notes to the PR?
<kyrofa> sergiusens, which ones? I didn't restart any
#snappy 2017-11-16
<kennyloggins> What is the command to install two snaps in sequence ?
<sergiusens> kyrofa snapcraft#1719
<mup> PR snapcraft#1719: many: account for python shebang args in rewrite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1719>
<kyrofa> sergiusens, that didn't restart, it's been going for two hours
<nacc> kennyloggins: not sure i understand? `sudo snap install <snap1>; sudo snap install <snap2>` ?
<sergiusens> bummer, why did it start only two hours ago?
<kyrofa> sergiusens, I had to start it because snapd toasted my local adt runs
<kyrofa> sergiusens, https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850/12
<kyrofa> sergiusens, also, I did comment in the PR :)
<sergiusens> kyrofa yeah, that I did see; do we need this though?
<kyrofa> sergiusens, up to you, I'm fairly confident given that I had successful runs before the rebase, but they were on zesty
<sergiusens> kyrofa elopio we need less tests, or broader ones; how many of the catkin tests could be merged into one?
<sergiusens> same for all the other components
<sergiusens> they could be condensed into on with multiple parts/apps
<sergiusens> unless it warrants a separate one
<sergiusens> but I am going to be pragmatic here, many are only separate because it looks good on paper
<kyrofa> sergiusens, remember we're still not re-using the cache
<kyrofa> Simpler tests are way easier to maintain
<kyrofa> But yeah, we can definitely combine some catkin ones if that's the direction we want to go
<kyrofa> This normally doesn't hurt quite so badly, we simply need to get in the habit of running them more often and paying attention to the result. I suggest caution in making decisions about our tests in our current state of pain
<sergiusens> kyrofa well, tonight is your night and tomorrow is your morning, right?
<sergiusens> :-)
<kyrofa> Indeed
<kennyloggins> What is test-snapd-cups-control-consumer , exactly ? Is it for printers ?
<nacc> kennyloggins: you can read it's description in `snap info test-snapd-cups-control-consumer`
<nacc> but as the name implies, it's a test snap for snapd to test the cups-control interfcase
<nacc> *interface
<kennyloggins> >  A basic snap declaring a plug on cups-control
<kennyloggins>  so its for printers ?
<nacc> kennyloggins: it doesn't do anything, afaict
<nacc> kennyloggins: it's a test snap
<kennyloggins> okay thanks
<nacc> kennyloggins: to test an interface's functionality, in this case the cups-control interface (which is an interface for printing, yes)
<kennyloggins> nacc, thanks by the way - can now install 15 snaps ; one after another in one command, cheers pal.
<nacc> kennyloggins: sure, that's not really snap specific :)
<nacc> kennyloggins: i'm not sure if instll can take multiple snap names or not
<nacc> seems like it probably could
<kyrofa> elopio, another PR to snappy-m-o
<kyrofa> nacc, `snap remove` certainly can
<kyrofa> Haven't tried on install
<nacc> kyrofa: yeah, me neither :)
<nacc> kyrofa: never had a reason, tbh
<kyrofa> nacc, me neither
<kennyloggins> nacc: that kinda worked ( http://paste.ubuntu.com/25971109/ ) Althou, I think I may have boken pastebin (on the right) :(
<nacc> kennyloggins: not sure what you mean by 'right'? it's just a long linne
<elopio> snappy-m-o, github subscribe 1719
<snappy-m-o> elopio: I'll send you a message if a test fails in the pull request #1719 (many: account for python shebang args in rewrite).
<mup> PR #1719: firstboot: add firstboot assertions importing <Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1719>
<elopio> snappy-m-o, github subscribe 1719
<elopio> snappy-m-o, github subscribe 1719
<snappy-m-o> elopio: I'll send you updates as tests complete in pull request snapcraft#1719 (many: account for python shebang args in rewrite).
<mup> PR snapcraft#1719: many: account for python shebang args in rewrite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1719>
<sergiusens> snappy-m-o github subscribe 1719
<snappy-m-o> sergiusens: I'll send you updates as tests complete in pull request snapcraft#1719 (many: account for python shebang args in rewrite).
<mup> PR snapcraft#1719: many: account for python shebang args in rewrite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1719>
<mup> PR snapcraft#1719 closed: many: account for python shebang args in rewrite <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1719>
<stgraber> sergiusens: hmm, so just noticed something funny... "version: 2.20" results in a snap of version "2.2" rather than "2.20"
<stgraber> sergiusens: updating now to be 'version: "2.20"' which hopefully will fix that issue :)
<sergiusens> stgraber oh, yaml; pyyaml parses that as a number; we should probably just update our jsonschema (commented) and enforce the type
<sergiusens> kyrofa elopio take a look at snapcraft#1650 again please and I'll merge and tag after the travis tests are done
<mup> PR snapcraft#1650: Release changelog for 2.35 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1650>
<kyrofa> sergiusens, bug #1732076 will still bite us
<mup> Bug #1732076: Plainbox snapd test failure <Snapcraft:New> <https://launchpad.net/bugs/1732076>
<sergiusens> kyrofa I'll skip the install part in packaging
<sergiusens> kyrofa fwiw, i386 runs on lxd
<sergiusens> kyrofa actually, I won't skip it, just document it as part of the SRU
<sergiusens> at this point I am more interested in releasing a snap
<mup> PR snapcraft#1740 opened: tests: add the home plug to the plainbox snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1740>
<elopio> snappy-m-o autopkgtest 1740 zesty:amd64
<snappy-m-o> elopio: I've just triggered your test.
<elopio> snappy-m-o github subscribe 1740
<snappy-m-o> elopio: I'll send you updates as tests complete in pull request snapcraft#1740 (tests: add the home plug to the plainbox snap).
<mup> PR snapcraft#1740: tests: add the home plug to the plainbox snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1740>
<elopio> snappy-m-o autopkgtest 1740 artful:amd64
<snappy-m-o> elopio: I've just triggered your test.
<mborzecki> morning everyone
<zyga> hey
<zyga> how are things?
<mborzecki> zyga: hey
<mborzecki> things are good, the conference was very nice
<mborzecki> did you watch the video streams?
<zyga> no, but I'd like to later
<zyga> fighting release stuff
<zyga> https://forum.snapcraft.io/t/2-29-release-cycle-started/2562/7
<mborzecki> uhh
<mborzecki> what else have i missed?
<zyga> mborzecki: not much I'd say
<zyga> mborzecki: we could use some help debugging lxd issues today
<zyga> mborzecki: I know about one issue that I'll try to finally address but it seems we have one more
<zyga> https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850
<mborzecki> looking
<zyga> I'm slowly waking up, I was working past midnight
<zyga> after kids are in school I'll probably take a nap
 * zyga is grumpy because everything fails and needs to be restarted 
<zyga> we could use some time on stabilizing those tests
<mborzecki> travis again?
<zyga> mborzecki: some of our spread tests are flaky
<zyga> mborzecki: https://github.com/snapcore/snapd/pulls/ all they yetllow ones failed on some random thing
<mborzecki> i'll quickly look through those and see if there's anyting with the tests or just the CI was flaky
<mborzecki> zyga: will artful cloud image be good enough for reproducing lxc problem that kyrofa reported?
<zyga> mborzecki: I think so
<mborzecki> ok
<zyga> mborzecki: not sure if he used 16.04 or 17.10
<zyga> mvo: good morning
<zyga> mvo: some ungood news: https://github.com/snapcore/snapd/pull/4228
<mup> PR #4228: interfaces,tests: skip unknown plug/slot interfaces (2.29) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4228>
<zyga> mvo: though please look at the diff, we need to see if this actually makes sense
<zyga> (I made it after midnight so not super sure)
<zyga> I was under the impression that the new load-time validation would handle this
<zyga> this is a regression caused by that patch
<zyga> it seems we validate a snap and then say "yeah it's broken but I'll load it anywy"
<zyga> and this is probably a wider hole to fill
<zyga> mvo: other than that we also have the LXD regression, mborzecki and I will look at that (though I'm so sleepy I plan to take a nap for an hour as soon as kids leave)
<mvo> zyga: god morning
<mborzecki> mvo: hey
<mvo> zyga: thanks for the update
<mvo> and good morning mborzecki
<mvo> zyga: do we know anything more about the lxd issue? does it affect every snap ?
<mvo> zyga: I also wonder why our lxd-test did not catch it :/
<zyga> mvo: I have some ideas
<zyga> mvo: the namespace didn't exist so snap-update-ns just bailed out
<zyga> mvo: and there were no content changes to apply
<zyga> mvo: this really requires the content interface test
<mvo> zyga: and plainbox is using that iface?
<zyga> mvo: I'm very convinced that we need to try to run the full test suite on lxd and see what is broken
<zyga> mvo: I don't know actually,
<zyga> mvo: it's possible
<zyga> kissiel: ^
<zyga> kissiel: is the checkbox/plainbox snap using content interface?
<zyga> mvo: though AFAIK this was a test in snapcraft so perhaps an artificial one
<zyga> and obviousl I could be wrong and there's something lurking deeper about why this failed
<mvo> zyga: thanks, that is already quite helpful!
<mvo> zyga: hm, kyrofa reproduced it for hello-world in lxc so I doubt its the content iface
<mvo> zyga: it works via sudo
<mvo> zyga: which is also strange but it explains why our test did not catch it, it means a regression test should be simple at least
<zyga> mvo: sudo will fix it because the denial was on cap_read_search
<zyga> mvo: we are apparently trying to traverse a directory that is not readable to us
<zyga> mvo: and then fail on the missing capability
<zyga> mvo: sudo will just give us that
<zyga> mvo: (not the capability but the read permission)
<zyga> mvo: the freezer cgroup setup insie containers is something worth looking at
<mvo> zyga: right, I'm trying to modify the lxd test so that we have a reproducer/regression test
<zyga> I feel like it's time to crash now, I'll be back closer to 10AM
<mvo> zyga: sleep well
<mup> PR snapd#4230 opened: tests: add test to run snap inside lxd as a user <Created by mvo5> <https://github.com/snapcore/snapd/pull/4230>
<mborzecki> mvo: can i force remove core snap?
<mvo> mborzecki: unfortunately not, you can "dpkg --purge snapd" (or fedora has a snap-mgr.sh script that does the same) to remove all snaps
<mvo> zyga: just fyi, adding "capability dac_read_search" is not sufficient to fix the lxd issue
<mborzecki> hmm cgroup freezer directories are left behind once a snap runs (is that ok?), anyways, when a snap is run with sudo, it will be possible to create a directory under /sys/fs/cgroup/freezer
<mvo> mborzecki: yeah, see 4230, we have a lxd test but unfortunately it runs as root so it did not catch the bug
<mborzecki> omg, broke lxd
<mborzecki> i restarted an ephemeral container, now i can't remove it nor stop if
<mborzecki> exec doesn't work either
<mup> PR snapd#4231 opened: interfaces: add "refresh-schedule" attribute to snapd-control <Created by mvo5> <https://github.com/snapcore/snapd/pull/4231>
<zyga> re
<zyga> mvo: any news?
<mborzecki> zyga: snap-confine is setuid root right?
<mvo> zyga: not much, we have a reproducer
<mvo> zyga: in spread
<zyga> mborzecki: yes
<zyga> mvo: aha, that's good
<mborzecki> https://paste.ubuntu.com/25973100/
<mborzecki> i build this, make it chown root:root, u+s, and cannot create a frezer group
<mvo> zyga: and the apparmor denial is not it, I added it for testing to snap-confine.appamor.in and it still fails
<mvo> zyga: with permission denied but no apparmor denial anymore
<zyga> mvo: I'm running your test locally now
<mvo> zyga: cool
<mup> PR snapd#4232 opened: store: add support for flags in ListRefresh() <Created by mvo5> <https://github.com/snapcore/snapd/pull/4232>
<mvo> zyga: silly question, could we revert the freezer group in 2.29? or would that cause havoc?
<zyga> mvo: I think a bit havoc, I'd have to look
<mvo> zyga: hm, then lets see if we can do a proper fix
<zyga> mvo: hmm, the container is weird
<zyga> I cannot switch to "ubuntu" user
 * kalikiana coffee
<zyga> mvo: I know what the problem is, I think
<zyga> stgraber: around?
<zyga> mvo: http://pastebin.ubuntu.com/25973198/
<zyga> mvo: so two ideas for quick "solution":
<zyga> mvo: 1) make that step optional and let it fail, this means mount changes are not atomic in lxd
<zyga> mvo: 2) talk to stgraber and figure out why lxd sets up containers this way and what we can do about it
<zyga> mvo, mborzecki: opinions?
<mborzecki> hmm that's why g+s works i guess
<zyga> mborzecki: correct
<zyga> mvo: it's actually a deeper problem:
<zyga> root@my-ubuntu:~# ls -ld /sys/fs/cgroup/devices/
<zyga> drwxrwxr-x 5 nobody root 0 Nov 16 09:13 /sys/fs/cgroup/devices/
<zyga> mvo: unless we somehow disabled all udev tagging inside containers
<zyga> mvo: it will break on when creating the device cgroup
<zyga> s/on//
<mborzecki> that's perhaps silly, but could we g+s snap-confine too? we're dropping both anyway right after setting up
<zyga> mborzecki: that's another option, indeed
<zyga> though I'd like to understand the motivation behind lxd choices
<Chipaca> moin moin
<zyga> Chipaca: hello
<mborzecki> Chipaca: hey
<zyga> Chipaca: welcome to the fire dept
<zyga> Chipaca: pick your hose and let's put out the fires ;)
<Chipaca> oh dear
<Chipaca> zyga: what's on fire?
<zyga> Chipaca: lxd
<zyga> https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850/12
<zyga> Chipaca: also snapd crashes:
<zyga> https://bugs.launchpad.net/snappy/+bug/1732555
<mup> Bug #1732555: Installing bad snap has snapd crashing <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1732555>
<zyga> Chipaca: that one needs some love from pstolowski and perhaps you, something went south very much whe we switched to "validate on load"
<mvo> zyga: hm, reading backlog. sorry, my laptop came back from repair just now (doorbell and all that)
<zyga> Chipaca: I'm a bit sleepy still
<zyga> mvo: great, did they hide that cable?
<Chipaca> zyga: both of those claim to have a fix in a pr; is the fire putting out effort needed from me to review those prs?
<zyga> mvo: btw I opened mine and I think I know why your cable was sticking out, there's a compartment for that cable where it's supposed to be held and be attached, if that part is loose it can easily slide through the hinge
<mvo> zyga: yeah, its not longer visible, I wonder where they put it, I'm inclined to open the machine to see what happend to it. but opening the modern ones is a pita (IMO) so I probably won't
<zyga> Chipaca: lxd is not fixed yet
<mvo> zyga: aha, nice
<zyga> Chipaca: and the snapd crash is just fixing the immediate problem, the deeper problem is not addresed
<zyga> Chipaca: it seems the validate-on-load concept is validate-and-log-but-continue-anyway
<mvo> zyga: I had it open before and tried to figure out where it belonged but couldn't find an obvious place and was too impatient then
<zyga> mvo: I bought a x240 for a family member and I opened it to clean it and replace the heatsink thermal glue
<zyga> mvo: (interestingly no internal battery there)
<zyga> anyway
<pstolowski> zyga, i'll look into this, thanks for the intermediate fix
<zyga> pstolowski: thank you
<mup> PR snapd#4229 closed: interfaces,tests: skip unknown plug/slot interfaces <Critical> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4229>
 * zyga is doing code reviews
<zyga> mvo: offtopic, do you remember that zesty issue with the repair systemd unit?
<zyga> mvo: is that something that needs love?
<zyga> pstolowski: FYI: https://github.com/snapcore/snapd/pull/4228
<mup> PR #4228: interfaces,tests: skip unknown plug/slot interfaces (2.29) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4228>
<zyga> pstolowski: 2.29 backport of that PR
<mvo> zyga: I remember it, I thought it was conditionally dislabed and that would not put things into degraded state
<mup> PR snapd#4228 closed: interfaces,tests: skip unknown plug/slot interfaces (2.29) <Critical> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4228>
<mvo> zyga: iirc I checked on a fresh VM
<zyga> mvo: aha, thank you
<zyga> mvo: I requested your review on https://github.com/snapcore/snapd/pull/4227 as you looked into framebuffers on pi recently
<mup> PR #4227: tests: add test for frame buffer interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4227>
<mvo> zyga: sure, I have a look
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/4225
<mup> PR #4225: cmd/snap-update-ns: tweak changePerform <Created by zyga> <https://github.com/snapcore/snapd/pull/4225>
<Chipaca> zyga: +1
<ackk> zyga, addressed all your comments on https://github.com/snapcore/snapd/pull/4219
<mup> PR #4219: snap/validate: extend socket validation tests <Created by albertodonato> <https://github.com/snapcore/snapd/pull/4219>
<zyga> ackk: thank you, I'll look now
<mup> PR snapd#4225 closed: cmd/snap-update-ns: tweak changePerform <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4225>
<mup> PR snapd#4185 closed: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4185>
<pstolowski> zyga, i think i've a proper fix for the bad plugs/slots. interestingy it uncovered an small issue with api tests after all these change
<pstolowski> s
<zyga> pstolowski: interesting
<zyga> pstolowski: I'll gladly review the PR
<mvo> a second review for 4232 and 4231 would be great
<zyga> mvo: I could use a few reviews
<mborzecki> i can take a look
<zyga> mvo: this one is interesting: https://github.com/snapcore/snapd/pull/4224
<mup> PR #4224: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4224>
<zyga> mvo: the code change is tiny in one function, the rest are just tests
<mvo> zyga, ok, looking. was about to jump to reviews anyway while me laptop restores its backup
<mup> PR snapcraft#1740 closed: tests: add the home plug to the plainbox snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1740>
<mup> PR snapd#4233 opened: interfaces: remove invalid plugs/slots from SnapInfo on sanitization <Created by stolowski> <https://github.com/snapcore/snapd/pull/4233>
<pstolowski> zyga, ^
<zyga> pstolowski: looking
<mborzecki> ok, conference report sent, back to snapd now
<zyga> pstolowski: reviewed
<mborzecki> zyga: so what do we do with lxd?
<zyga> I'd like to discuss this with stgraber
<zyga> setuid is problematic in itself
<pstolowski> zyga, thanks!
 * Chipaca ~> haircut, and lunch
<Saviq> popey: hey, what GUI snaps would you recommend to try out?
<popey> What's the goal?
 * Chipaca aborts haircut plans
<mborzecki> TestExecInCoreSnapUnsetsDidReexec fails on me with arch
<zyga-solus> mborzecki: maybe it assumes ubuntu and lacks mocking?
<zyga-solus> mborzecki: thank you for running that on arch
<zyga-solus> let me try on solus
<mborzecki> in ExecInCoreSnap(), should SNAP_DID_REEXEC be unset in all early exit paths?
<zyga-solus> mborzecki: I don't know, sorry
<zyga-solus> ikey: any chance for F57 soon? ^_^
<Saviq> popey: evaluating X11 over SSH
<ikey> its in unstable zyga-solus
<ikey> we sync on fridays
<zyga-solus> ikey: thank you! :) I cannot wait to see that
<ikey> its pretty banging
<mborzecki> mvo: you fixed the bug, so I assume ou know something about SNAP_DID_REEEXEC ;)
<zyga-solus> ikey: so I heard
<ikey> https://plus.google.com/+Solus-Project/posts/LGDbWGGnGs2
<zyga-solus> mborzecki: FYI, that test passes on solus
<ikey> unfortunately we couldn't do a simple cherry-pick for firefox to get it in early
<ikey> depends on new stuff like dbus + xcb + x11 + co
<ikey> big chain
<ikey> and right now im rebootstrapping the solus toolchain
<mborzecki> zyga-solus: thx for checking
<popey> Saviq: pycharm-community, mailspring, wavebox, ohmygiraffe, chromium.. good enough to get on with?
 * zyga-solus sees one unit test failing on solus, let's fix that
<zyga-solus> but while tests run, it's tea time!
<Saviq> popey: sure, thanks
<zyga-solus> pstolowski: +1
<zyga-solus> pstolowski: can you please do a 2.29 backport as well, feel free to rebase+squash this PR for simplicity
<zyga-solus> mvo: can you do a 2nd review of 4233 with the extra changes, for sanity please?
<zyga-solus> jdstrand: good morning :)
<mborzecki> zyga-solus: SnapMountDir must be /snap in solus apparently
<zyga-solus> mborzecki: yes, that's right
<mborzecki> the test should fail on fedora too then
<zyga-solus> mborzecki: perhaps neal patched it, I haven't used fedora actively lately
<ikey> SnapMountDir never wasn't /snap in our snapd
 * ikey is confused
 * ikey also can't english today
<zyga-solus> ikey: it's all good
<zyga-solus> ikey: just chasing an unit test without mocking that mborzecki found while running arch
<ikey> ah
<diddledan> ikey: English you good done!
<ikey> thanks much they have do
 * diddledan looks to see what podcasts he has waiting to be heard
<diddledan> ah there we go. a nice shiny new bad voltage
 * ikey occupies himself with watching llvm build
<diddledan> ooh, that sounds almost like Gentoo :-p
<ikey> nah gentoo is for newbs
<ikey> :P
<ikey> someone else has already done the packaging for you at that point :p
 * ikey wouldn't object to someone else doing this for him though.
<ikey>  12:46:18 up 13:26,  1 user,  load average: 10.95, 9.48, 6.76
<ikey> ow. xD
<zyga-solus> ikey: are you on gentoo now? :D
<ikey> nah on solus
<ikey> the laptop is taking offence to being used as a build machine
<zyga-solus> ikey: maybe get one of those $9 chip clusters ;)
<ikey> heh
<ikey> fwiw ive already built gcc on this thing today as well
<ikey> running out of compilers to compile..
<zyga-solus> ikey: think about the gcc CI machine
<zyga-solus> poor thing :)
<ikey> lo, ya
<ikey> *lol
<ikey> then again they use SVN
<ikey> so they kinda bring pain on themselves
<zyga-solus> again?!?
<zyga-solus> next up: more shards of glass under our fingertips
<ikey> yeah i was checking out https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=248032 earlier
<jdstrand> zyga-solus: good morning :)
<jdstrand> zyga-solus: or rather, good afternoon :)
<zyga-solus> jdstrand: we had some drama in the morning, the interface part seems to be addressed now but we are still in the red in lxd
<jdstrand> yeah, saw that
<Chipaca> is https://forum.snapcraft.io/t/snapd-fails-to-update-lxd/2858 the same lxd issue?
 * ikey adds appropriately topical and dramatic musical backdrop to zyga-solus's words
<diddledan> emerge glibc binutils gcc && emerge glibc binutils gcc <-- back in the day that was the required encantation to ensure Gentoo consistency (IIRC)
<ikey> https://www.youtube.com/watch?v=Wmc8bQoL-J0
<diddledan> incantation*
<ikey> diddledan, yeah ive done binutils already lol
<diddledan> \o/
<ikey> 2.29.1
<zyga-solus> ikey: just say everything I write with hollywood trailer voice
<mvo> mborzecki, I have a look at this reexec in a little bit but strange that it fails on arch and not ubuntu
<ikey> lol
<mup> PR snapd#4234 opened: snap: use field names when initializing composite literals <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4234>
<zyga-solus> Chipaca: not sure, I just saw that
<mborzecki> trivial PR ^^ if anyone wants to take a look
 * ikey will send off binutils and gcc again once this llvm finishes..
<mborzecki> mvo: opening PR in a minute, added some mocks to workaround this
<diddledan> I hope your laptop is on a desk rather than your knees :-p *hothothot*
<ikey> not sure the battery would last the time it took to move between the desk and the sofa
<ikey> nowadays its permanently plugged in
<ikey> and hooked up to my 4k monitor
<ikey> (keyboard/mouse/everything external)
<ikey> its like the most ironic laptop
<Chipaca> mborzecki: i thought that was written `snap.R(20)`
<pedronis> yes
<mborzecki> Chipaca: yes/no/maybe, let me check
<pedronis> at least that is what we usually do
<pstolowski> zyga-solus, thanks. will do 2.29pr
<mborzecki> yup, i'll update the PR
<Chipaca> hmm, ho seems stucjk
<mup> PR snapd#4235 opened: cmd: pretend we're running on Ubuntu in TestExecInCoreSnapUnsetsDidReâ¦ <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4235>
<mup> PR snapcraft#1650 closed: Release changelog for 2.35 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1650>
<Chipaca> niemeyer: https://www.youtube.com/watch?v=BHTxzn4YL6o
 * kalikiana taking a short break
<kyrofa> Mornin folks
<kyrofa> sergiusens, things finally looking up this morning?
<pedronis> mvo: I did mark the things in the roadmap for 2.30 with 2_30
<pedronis> Chipaca: is this done https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives/2268 ?Â considering that we have also this one now https://forum.snapcraft.io/t/support-for-snapctl-stop-start-restart-services/1908
<mvo> pedronis: excellent, thank you
 * kalikiana waves at kyrofa 
<pedronis> mvo: Chipaca: this is done for now:  https://forum.snapcraft.io/t/should-we-use-polkit-for-local-auth/1206  ?
<mvo> pedronis: yes, that has landed
<mvo> pedronis: iirc 2.28
<Chipaca> pedronis: it is not done
<Chipaca> pedronis: the first one i mean, not even started
<kyrofa> Hey there kalikiana
<pedronis> Chipaca: ah, I confused what it was, sorry
<Chipaca> =)
<Chipaca> pedronis: 2.30 for that one might be too soon though
<pedronis> Chipaca: yes
<Chipaca> not sure i'm going to get to it (pretty sure i'm going to be elbow-deep in snapshots)
<pedronis> Chipaca: are aliases the last bit missing for tab completion for snaps?
<pedronis> Chipaca: feel free to put to backlog if that's the case
<Chipaca> pedronis: aliases are done
<abeato> mvo, jdstrand, hi, I have a question about the emergency repair assertion, does it need to be signed by Canonical? Or not necessarily and it can be created by the brand-id that signed the model assertion?
<Chipaca> i don't think there's anything else
<pedronis> Chipaca: but not released? so 2.30, right?
<Chipaca> pedronis: correct
<pedronis> thanks
<Chipaca> it even says as much :-)
<Chipaca> âTab completion of aliases is enabled transparently from snapd 2.30 (the completer should only see the dealiased command).â
<pedronis> pstolowski: what's the status of this https://forum.snapcraft.io/t/declaratively-defining-environment-variables/175/23 it's marked backlog but worked happened on it
<pstolowski> pedronis, right, it's done
<pstolowski> pedronis, hold on
<pstolowski> pedronis, i need to check entire thread in case there was more than just this bugfix
<pedronis> yea, np
<pedronis> also there's snapcraft part to it
<zyga-solus> Chipaca: I requested your review on two PRs
<jdstrand> abeato: I defer to mvo
<abeato> ok
<zyga-solus> mvo: I replied to brauner on the thread
<zyga-solus> mvo: not sure how to understand what we should (or not) do
<mvo> abeato: currently it needs to be signed by canonical. phase-2 would allow others to sign it but we are not there yet
<mvo> zyga-solus: thank you
<abeato> mvo, got it, when is phase-2 planned to happen?
<mvo> abeato: we have no firm timeline for this yet unfortunately
<pedronis> it also depends how self-service it needs to be
<mvo> abeato: indeed, what pedronis said -^
<abeato> pedronis, mvo I would expect that the owner of the model (creator of the image) would be able to send emergency fixes as required, from their own store
<pedronis> there is no timeline on that, it would also need store work
<abeato> got it, thanks
<mup> PR snapd#4236 opened: Reject bad plugsslots 229 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4236>
<Chipaca> zyga-solus: i'm not seeing the notification for that
 * Chipaca pokes
<kyrofa> sergiusens, the release notes are missing the "using a remote lxd instance" demo
<kyrofa> Ah, I got it
<kyrofa> sergiusens, dumb question: is it actually "dotnet" or .NET ?
<kyrofa> The plugin name is obvious, but when used in a phrase
<kyrofa> I thought it was .NET
<zyga-solus> Chipaca: you should be able to on: https://github.com/snapcore/snapd/pulls/review-requested/chipaca
<Chipaca> zyga-solus: ! thank you
<zyga-solus> it's an useful link :)
<zyga-solus> mvo: hey
<zyga-solus> mvo: around?
<zyga-solus> mvo: I'm playing with containers
<om26er> jdstrand: I think that android studio is now good to be allowed 'classic' following Alan's reply.
<sergiusens> kyrofa dotnet
<sergiusens> kyrofa err, the command is dotnet... the infra is .NET core
<sergiusens> kyrofa the release notes are in draft for a reason :-)
<sergiusens> kyrofa waiting on kalikiana for that video link (unless I missed it)
<kyrofa> sergiusens, I fixed it
<kyrofa> sergiusens, I'll fix the .NET ones as well
<sergiusens> kyrofa elopio btw, `snap install mailspring` and email problems will be a problem of the past
<elopio> sergiusens: so, this was all because we didn't make a lot of noise when we implemented that "snap install core || echo ignoreerror" workaround?
<elopio> sergiusens: isn't mailspring just as nylas? They have your emails on their server?
<sergiusens> elopio it is local
<sergiusens> elopio no, this is different
<ikey> and less JS heavy than the old thing
<elopio> I will check it out.
<sergiusens> elopio it is faster than any other email client I've used and it actually does not lie about unread emails as I have been seeing on other clients using imap
<mvo> zyga-solus: back now, I was in a meeting
<kalikiana> sergiusens: I sent it in email yesterday
<kalikiana> in the gist
<ikey> [Package] Creating /home/build/work/llvm-32bit-5.0.0-53-1-x86_64.eopkg ...
 * ikey sobs with relief
<sergiusens> ikey failed, out of space
<ikey> no dont lol
<ikey> it failed the first time
<sergiusens> cleaning up
<sergiusens> lol
 * ikey almost cried
<kalikiana> sergiusens: wait, I see it in the "is here"...  did you mean another video?
<sergiusens> kalikiana I am not following on that last comment
<kalikiana> sergiusens: you said "waiting on kalikiana for that video link"
<zyga-solus> mvo: thank you for the notice, I wanted to say that the issue with LXD is not so clear cut anymore
<sergiusens> kalikiana no, no other video
<kalikiana> sergiusens: I see the video on the "snapcraft 2.35 is here" page
<mvo> zyga-solus: how do you mean?
<Chipaca> mvo: +1! and then suddenly -1
<zyga-solus> mvo: I don't think I know what's really going on
<Chipaca> mvo: (on #4232)
<mup> PR #4232: store: add support for flags in ListRefresh() <Created by mvo5> <https://github.com/snapcore/snapd/pull/4232>
<zyga-solus> https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850/33
<zyga-solus> mvo: look at the last few posts
<zyga-solus> and lxd itself is fun (for unmagic regular software)
<mup> PR snapd#4237 opened: debian: add missing udev dependency <Created by mvo5> <https://github.com/snapcore/snapd/pull/4237>
<mvo> Chipaca: uh, thank you! I will fix this
<Chipaca> :-)
<mup> PR snapd#4231 closed: interfaces: add "refresh-schedule" attribute to snapd-control <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4231>
<mvo> zyga-solus: just read the backlog, did you see brauners suggestion about the mount-namespace-capture-helper profile?
<kalikiana> sergiusens: btw if it was you who made my bits 10 times better, thank you so much for that. Tons better!
<zyga-solus> mvo: no, where was that?
<kalikiana> sergiusens: are the "empty" sections still to be filled in?
<mvo> zyga-solus: just 2min ago, maybe you need to reload
<zyga-solus> ah, not here on IRC
 * zyga-solus looks at the forum
<mvo> Chipaca: thanks for the suggestions in the PR - so you suggest that I use "type RefreshOptions struct {RefreshManaged bool}' instead?
<mvo> Chipaca: instead of bit-flags?
<Chipaca> mvo: yep
<Chipaca> mvo: or if you think the bitfield means a smaller refactor, give it a IsRefreshManaged() bool, that does the check
<Chipaca> either is fine, but over time we've moved to structs for flags
<Chipaca> (there might be bitfields still somewhere though)
<Chipaca> (dunno, haven't hunted)
<mvo> Chipaca: I go for the struct, the fact that I messed up the bitfield sounds like a good reason against it
<Chipaca> :-)
<Chipaca> mvo: memorywise it's the same
 * kalikiana needs to hop on a tram, will be back in a bit
<mvo> Chipaca: interessting
<mvo> Chipaca: anyway, refactoring now, thanks for your input!
<jdstrand> om26er: I'll take a look, thanks
<zyga-solus> mvo: I'm running out of ideas on LXD
<mvo> zyga-solus: what are we using the freezer group for in 2.29? is it allready criticial (I assume yes but want to double check)
<zyga-solus> mvo: it's done so that mount changes are atomic
<zyga-solus> mvo: and we also use it to detect (but not yet act on) stale namespaces when the base snap changes revision
<mvo> zyga-solus: what did we do in 2.28 for mount changes?
<zyga-solus> mvo: we didn't do certain kids
<zyga-solus> mvo: and they were racy
<mvo> zyga-solus: right, mostly asking to see if revert is an option until we have a handle on this. but lets keep digging and hoping that stgraber has an idear
<mvo> idea
<zyga-solus> mvo: I think it's a jdstrand question
<zyga-solus> mvo: the base snap staleness we can ignore for now (it's not live)
<zyga-solus> mvo: the race prevention was a direct request from him
<mvo> zyga-solus: ok
<mvo> zyga-solus: well, I think of course ideally we would make it work under lxd, but the lack of ideas is slightly worrying :)
<zyga-solus> mvo: I don't know what's going on really
<zyga-solus> mvo: it feels like apparmor but I don't even see the capability dac_read_search denial anymore
<mborzecki> this may sound crazy but I tried using this: https://paste.ubuntu.com/25975053/ then on the hose enable trace basically all, and then kill -CONT in the container
<mborzecki> zyga-solus: maybe this will give you some ideas
<zyga-solus> mborzecki: sorry, I don't understand
<mborzecki> that paste is a minimal sample that fails under lxd, extracted from our code
<zyga-solus> aha
<mborzecki> then in the container i run this process and tell it to create a frezer cgroup, it will stop with SIGSTOP
<Chipaca> mvo: you made it a pointer to keep the refactor down?
<zyga-solus> and you ran this setuid root?
<zyga-solus> as a user
<mborzecki> yup
<zyga-solus> mborzecki: can you please add that to the thread on the forum where brauner reads this?
<mborzecki> then on the host i try trace-cmd -e all -P <pid-translated-to-global-ns>
<mvo> Chipaca: yeah, I can change it to by value if you prefer, will make the call sites looks a bit more ugly (or a bit more clear depending on POV)
<mborzecki> zyga-solus: ok
<mvo> Chipaca: do you prefer the non-pointer approach?
<Chipaca> mvo: 's fine
<Chipaca> mvo: very marginal preference for passing by value (with a for-convenience default flags object maybe)
<Chipaca> mvo: i already +1'ed before asking, that's how much i care about this :-)
<mvo> Chipaca: ok, I don't mind either way so lets go with it until someone else objects :)
<mvo> pedronis: your input on 4222 would be great
<mup> PR snapd#4219 closed: snap/validate: extend socket validation tests <Created by albertodonato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4219>
<stgraber> zyga-solus: what's up?
<zyga-solus> stgraber: hello
<zyga-solus> stgraber: we're trying to understand an issue we found after 2.29.3 went to stable
<zyga-solus> stgraber: it's happening here: https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850/48 -- brauner is helping us
<stgraber> yeah, he just sent me that link
<zyga-solus> jdstrand: hey, if you have a sec please look at the forum thread linked above
<zyga-solus> mvo: I think the issue is understood and we have a solution on our plate
<pedronis> mvo: was in  a meeting
<mup> PR snapd#4237 closed: debian: add missing udev dependency <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4237>
<zyga-solus> jdstrand, mvo, stgraber: I'm running a spread run with g+s, let's see what happens
<pedronis> mvo: added some comments
<zyga-solus> mvo: the outlook on LXD issue (the more recent one) is that we'll have a patch later today and will need to go through a round of review
<zyga-solus> mvo: expect it to be semi-landable tomorrow
<Chipaca> mvo: zyga means through a security review there i think
<pedronis> mvo: was this fixed:  https://forum.snapcraft.io/t/spread-cron-is-not-running-snapd-vendor-sync/2739 ?
<zyga-solus> Chipaca: I think the review will be very detailed as it's not a minor change
<zyga-solus> well
<zyga-solus> it's a small change with major consequences
<kyrofa> sergiusens, can we start landing PRs for 2.36?
<mvo> zyga-solus: yay, understood sounds great
<zyga-solus> :)
<zyga-solus> that single test case passes, I'm running all of main and adjusting for this (some parts need to go)
<sergiusens> kyrofa I thought first came elopio's testing one and then we'd all rebase
<sergiusens> elopio ETA for that?
<kyrofa> sergiusens, sounds lovely
<elopio> sergiusens: let me finish the council meeeting, and I'll rebase.
<elopio> so, 1 hour. Hopefully the merge is easy
<popey> Guys, I have a snap which is doing my head in. Files (executables) are not being copied from stage to prime. They exist in stage just fine, but never end up in prime or the resulting snap.
<popey> Is there some rule about what gets copied from stage to prime which will eliminate things?
<nacc> popey: i think that would be plugin specific? (/me is not a snap developer)
<nacc> popey: do you have the yaml handy?
<popey> plugin specific? I dont understand how
<nacc> popey: i though the plugins implement the lifecycle, e.g. what actually happens at each point, so stage, prime, snap: https://docs.snapcraft.io/build-snaps/plugins
<nacc> (going by docs)
<sergiusens> popey things in stage have to come from a part
<popey> I'm using autotools plugin but overriding with prepare, build and install
<popey> yeah, the part builds the app, it gets to stage just fine
<popey> but then gets lost between stage and prime
<sergiusens> it should just work then; does it exist in parts/<part-name>/install ?
<popey> yes
<sergiusens> popey wait, is it a file which would be considered hidden?
<sergiusens> starts with dot
<popey> no, bunch of executables
<kyrofa> popey, any chance this is public?
<popey> i haven't investigated all the missing files, but the primary executable is the main one missing and that's a big problem
<popey> it can be. it takes ~20+ mins to build on my 64GB i7
<kyrofa> even just a peek at the YAML would be interesting
<sergiusens> hmm, out of quick ideas and heading out to rehab (knee, don't get ideas); so I'll leave it to kyrofa to continue the "interrogation"
<kyrofa> sergiusens hurt his knee doing drugs, FYI
<sergiusens> popey teleconsole ftw ;-)
<popey> hehe
<popey> funnily enough wimpy is teleconsoled in right now watching it
<popey> i did cleanbuild though so all thrown away in this build
<mcphail> sergiusens: "don't do snaps kids"
 * popey seals up the woodwork, less more come out
<popey> *lest?
<kyrofa> sergiusens, we call that "physical therapy" around here :P
<popey> ok, am kicking off another build as a container build so I can keep the artifacts
<Chipaca> zyga-solus: jinx!
<Chipaca> zyga-solus: except instead of commenting i cherry-picked and pushed
<Chipaca> and now I'll kinda-EOD; will check back to merge that if it's green
<zyga-solus> Chipaca: :D
<zyga-solus> Chipaca: thank you!
<zyga-solus> Chipaca: I saw that just a few seconds after I commented
<zyga-solus> Chipaca: I'll do that :)
<zyga-solus> Chipaca: enjoy your evening
<mup> PR snapd#4233 closed: interfaces: remove invalid plugs/slots from SnapInfo on sanitization <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4233>
<mup> PR snapd#4232 closed: store: add support for flags in ListRefresh() <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4232>
<mup> PR snapd#4215 closed: HACKING: fix path in snap install <Created by asalminen> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4215>
<zyga-solus> jdstrand: do you have some time for 2nd look on https://github.com/snapcore/snapd/pull/4169 today?
<mup> PR #4169: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <https://github.com/snapcore/snapd/pull/4169>
<jdstrand> zyga-solus: I'm trying
<jdstrand> zyga-solus: for the setgid. I think the coding changes are that we limit setguid to that own chown. so, as early as possible we temporarily drop, then right before the fchown, we raise, then right after, we temporarily drop. we then let the current code let us drop permanently
<jdstrand> s/own chown/one chown/
<zyga-solus> jdstrand: ah, interesting, so effectively minimize the changes to the current behaviour
<jdstrand> zyga-solus: that happens to be the safest thing to do, but also will have the smallest code impact
<jdstrand> exactly
<zyga-solus> jdstrand: I was thinking about going all the way in by dropping the chown code entirely
<zyga-solus> jdstrand: we can consider that for future improvement
<jdstrand> zyga-solus: I was thinking of that too, but its hard to think through setuid, sudo, non-sudo for both inside and outside of lxd
<zyga-solus> yes, it certainly needs more time
<jdstrand> it would have to be carefully and methodically worked through
<zyga-solus> jdstrand: I'll prepare the patch as you suggested initially for tomorrow
<zyga-solus> (today I'm just gardening PRs)
<jdstrand> zyga-solus: you probably recall that we temp drop uid and reraise in the codebase. you can look at that for inspiration
<mvo> pedronis: thanks for your review. I addressed the raised points now
<zyga-solus> jdstrand: yes, totally
<mvo> zyga-solus: silly question, I commented out the fchown code as a test but that was not enough, but I guess thats known, right?
<zyga-solus> mvo: for the cgroup issue?
<mvo> zyga-solus: yeah
<zyga-solus> mvo: no, that's not enough
<zyga-solus> mvo: you also need the packaging changes to make us setgid root
<zyga-solus> mvo: and some assorted code that jdstrand described above
<mvo> zyga-solus: aha, ok
<mvo> zyga-solus: I keep an eye on it (but not now :/
<zyga-solus> mvo: are you EOD?
<mvo> zyga-solus: well, sort of, I can be around in ~2h again or so
<mvo> zyga-solus: or 1.5h
<zyga-solus> mvo: no worries, I just beg for code reviews :)
<magicaltrout> alright folks, stupid question cause i've not built anything in a while
<magicaltrout> if i use a plugin, like ant. Can I run a command to copy a file before running the build?
<nacc> magicaltrout: see the prepare scriptlet
<magicaltrout> ah thats the word that had escaped me!
<mup> PR snapcraft#1741 opened: TESTING: adt on lxc requires squashfuse <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1741>
<kyrofa> ogra_, you around
<kyrofa> ?
<elopio> kyrofa: sergiusens: The massive diff looks good to me. You can review while the tests run.
<zyga-solus> koza: thank you!
<zyga-solus> jdstrand: thank you, I'll address those items immediately
<sergiusens> elopio 2.35 is in beta; test away and tell me when to promote to candidate (so you can make the cft)
<elopio> sergiusens will start after lunch.
<mup> PR snapd#4236 closed: many: reject bad plugs/slots 2.29 <Created by stolowski> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4236>
<mup> PR snapd#4238 opened: interfaces/browser-support: adjust base declaration for auto-connection <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4238>
 * kyrofa runs some errands, back later
<pedronis> jdstrand: thanks for #4238, I pushed a test there too
<mup> PR #4238: interfaces/browser-support: adjust base declaration for auto-connection <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4238>
<mup> PR snapd#4234 closed: snap: use field names when initializing composite literals <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4234>
<jdstrand> pedronis: thanks!
<jdstrand> roadmr: hi! can you pull in r943 of the review tools. no rush
<mwhudson> er does snapcraft's python plugin look at requirements.txt files?
<ikey> soo did we figure out some kind of rules to make up to apply to base snaps? :)
 * ikey isn't tryna rush stuff but would love to spread social medias :p
<nacc> mwhudson: i think so?
<nacc> mwhudson: oh wait, you tell it to (requirements: requirements.txt)
<mwhudson> nacc: yeah i just found that bit
<nacc> mwhudson: the help doesn't indicate it has any default value, so i guess it must be specified to use it
 * mwhudson tries that
<nacc> mwhudson: i use it to build gbp in my snap
<zyga-solus> cachio: you missed one const
<zyga-solus> cachio: look at my comments please
<cachio> zyga-solus, ouch
<zyga-solus> cachio: added one more comment and reading the rest
<cachio> zyga-solus, looking
<mwhudson> ha no i get two versions of pyudev in my snap
<mwhudson> (Well priming fails)
<zyga-solus> cachio: done
<zyga-solus> cachio: tweak a few things and merge, approved
<cachio> zyga-solus, tx
<zyga-solus> cachio: thanks :)
<sergiusens> elopio something s wrong with snapcraft#1638
<mup> PR snapcraft#1638:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1638>
<mup> PR snapcraft#1741 closed: TESTING: adt on lxc requires squashfuse <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1741>
<roadmr> jdstrand: hi! sorry for the delay. r943 of tools coming up
<sergiusens> kyrofa have you reviewed that ^?
<jdstrand> roadmr: thanks!
<ikey> any answer to my Q?
<sergiusens> ikey what Q? rules for base snaps? I guess that would involve jdstrand and other specific folks
<ikey> i asked yesterday and got no response, thought id check in and see where we're at
<ikey> otherwise its kinda a waste of time for me to be uploading snaps
<ikey> i.e. ill save doing the uploads until i know its working
<ikey> save triggering the system :p
<zyga-solus> ikey: I do think that's jdstrand, just be patient please
 * ikey just had to be awkward and use the new shiny
<ikey> zyga-solus, im being patient - id just like communication
<ikey> and ive asked here for 2 days without being acknowledged
<ikey> i dont care how long it takes i just dont like talking into the void
<ikey> as i have to juggle my own work and time
<zyga-solus> ikey: I think you asked on the forum and there was a response there, no?
<nacc> are base snaps that close to existing?
<ikey> they exist-ish
<ikey> as in i have one
<nacc> heh
<nacc> right, i have followed what you've been doing, ikey  (here)
<ikey> zyga-solus, even if i get told that ill be emailed or something when a decision is made, thats fine
<ikey> i just dislike limbo - then i can plan to put off all LSI work for now :P
<zyga-solus> ikey: I understand, I'll try to get you a response quickly
<mcphail> ikey: we're loving your work, but you need to change that name - https://www.youtube.com/watch?v=Yvpbm37OLiU
<ikey> no no - thats not what im tryna accomplish :P im not tryna hurry things up i just wanna know that there is process, and whether i need to check up, or ill be told, etc
 * ikey blinks at video
<ikey> o.
<ikey> tbf i mean thats basically the topic of any FPS discord mcphail
<ikey> so it *kinda fits* ? >_>
<mcphail> kinda ;)
 * ikey renames it boney m just to be ambiguous altogether
<mup> PR snapd#4169 closed: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4169>
<zyga-solus> jdstrand, pedronis: https://travis-ci.org/snapcore/snapd/builds/303226031?utm_source=github_status&utm_medium=notification
<mup> PR snapd#4222 closed: tests: add new `fakestore new-snap-{declaration,revision}` helpers <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4222>
<mwhudson> ah haha you can work around the "cleanbuild always uses xenial" thing by creating a container with the right name ahead of time and then using SNAPCRAFT_CONTAINER_BUILDS=1 :-)
<zyga-solus> cachio: one more comment on https://github.com/snapcore/snapd/pull/4171/files
<mup> PR #4171: tests: adding test to test physical memory observe interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4171>
#snappy 2017-11-17
<kyrofa> sergiusens, elopio snapcraft#1638 looks good (I reviewed it previously as well), but I notice no adt has run. It's kind of a big re-org, think it's a good idea?
<mup> PR snapcraft#1638:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1638>
<elopio> kyrofa: let me update the other one so they run on the nightly
<kyrofa> elopio, so don't land this yet?
<elopio> kyrofa: ah, I thought it was landed already. Well, I guess we are in no hurry because it's already EOD. Let me trigger a few, and we land tomorrow morning.
<kyrofa> Yeah that seems reasonable. And gives me an opportunity to test the new subscriptions
<elopio> where's the bot?
<elopio> snappy-m-o autopkgtest 1638 xenial:armhf xenial:amd64
<snappy-m-o> elopio: I've just triggered your test.
<elopio> snappy-m-o github subscribe 1638
<snappy-m-o> elopio: I'll send you updates as tests complete in pull request snapcraft#1638 ( tests: reorganize unit and integration suites to make them easier to split for travis).
<mup> PR snapcraft#1638:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1638>
<elopio> I'm now sure if the subscribe thing is working.
<kyrofa> snappy-m-o, github subscribe 1638
<snappy-m-o> kyrofa: I'll send you updates as tests complete in pull request snapcraft#1638 ( tests: reorganize unit and integration suites to make them easier to split for travis).
<kyrofa> elopio, yeah me neither, but I wasn't before, either
<kyrofa> Now we know that is MUST ping us either way
<sergiusens> snappy-m-o, github subscribe 1638
<snappy-m-o> sergiusens: I'll send you updates as tests complete in pull request snapcraft#1638 ( tests: reorganize unit and integration suites to make them easier to split for travis).
<mup> PR snapcraft#1638:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1638>
<sergiusens> elopio kyrofa by default I think the bot should just go ahead and ping (all of us or at least the author)
<kyrofa> sergiusens, it's not smart enough to tie github users to IRC nicks
<kyrofa> I guess it would work for us though, just use the same
<kyrofa> sergiusens, we recently updated it to ping us on failure OR success though
<sergiusens> kyrofa we can make a manual "team" map.
<kyrofa> Yeah that would be easy as well
<mborzecki> good morning
<mborzecki> mvo: morning
<mvo> hey mborzecki
<mvo> mborzecki: how are you?
<mborzecki> good, thank you
<mborzecki> sorry to bugging you early morning but would you mind taking a look at https://github.com/snapcore/snapd/pull/4235 ?
<mup> PR #4235: cmd: pretend we're running on Ubuntu in TestExecInCoreSnapUnsetsDidReâ¦ <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4235>
<mvo> mborzecki: sure
<mborzecki> this is the last thing that's currently blocking unit tests on arch
<mvo> mborzecki: aha, ok. sure, I have a look. I'm still slightly puzzled why its needed but I will poke at it a bit (and may come back with questions)
<mborzecki> ok
<mvo> pedronis: thanks a lot for 4222!
<mvo> mborzecki: I just checked the test, the issue is that the test is using /snap unconditionally when it needs to use dirs.SnapMountDir (silly test). so http://paste.ubuntu.com/25979289/ fixes the test for me without the need to do the mocking (its also more correct). could you please double check and if it also works for you just patch -R the current diff and force push the smaller diff?
<mvo> mborzecki: or not force push just keep it as a regular commit
<mvo> mborzecki: and when can squash-merge it
<mborzecki> thanks, i'll check it locally and let you know
<mvo> thanks
<mborzecki> mvo: the snippet you posted works locally ;) i'll push changes shortly
<mvo> mborzecki: yay, thank you
<mborzecki> mvo: revert & patch are pushed now, thanks for the hint on fixing this, no need to go through the silly mock/restore trampoline :)
<mvo> mborzecki: thanks! indeed but the real silliness was in the test to hardcode the /snap prefix
<kalikiana> o/
<pedronis> mvo: hi, was this fixed:  https://forum.snapcraft.io/t/spread-cron-is-not-running-snapd-vendor-sync/2739  ?
<mvo> pedronis: yes, this is working again.
<mvo> pedronis: cachio fixed it some days ago and it seems to be ok, I just checked the build history
<mvo> mborzecki: btw, do you know the status of the lxd issue? I guess zyga worked late(?)
<mborzecki> mvo: https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850/62 we're waiting for a patch from zyga
<mborzecki> other than that g+s
<mvo> mborzecki: thank you
<mborzecki> what's the plan for .4 release?
<mvo> mborzecki: we do it as soon as we have a patch, ideally today
<pedronis> mvo: are you going to do a separate PR for checking pending refreshes when refreshes are managed?
<pedronis> mvo: using #4232 basically
<mup> PR #4232: store: add support for flags in ListRefresh() <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4232>
<mvo> pedronis: either way is fine with me, I can separate it out or put it into the main one, whatever is easier to review for you
<pedronis> mvo: it's going to be a separate cycle, right?  separate PR would seem better in that case
<mvo> pedronis: I hope we can get it in for 2.30
<pedronis> ?
<mvo> pedronis: but separate is fine with me, probably easier to review
<pedronis> I don't think we can merge the rest without that, afaiu, so it needs to be in 2.30
<mvo> pedronis: yes, then we are in agreement. I misunderstood when you said separate cycle
<pedronis> I mean separate cycle
<pedronis> in the sense of the scheduling inside snapd
<mvo> pedronis: yes, I think so
<mvo> pedronis: that seems to make most sense
<pedronis> ok
<pedronis> I think we are in agreement
<mvo> pedronis: cool, its my next task, I hope to get something ready by EOD
<mvo> pedronis: firefox 57 happend and all my extension (not all, but almost) are dead so I had a bit of unplanned fixtime on this this morning :(
<mvo> pedronis: anyway, I get back to schedule (and review feedback fixing and code reivews)
<pedronis> it's ok, anyway it's still a bit until 2.30 beta? or I'm reading the roadmap wrong?
<pedronis> s/I'm/am I/
<mvo> pedronis: we still have a bit of time yes
<mvo> pedronis: its adjusted for .4 :/
<pedronis> mvo: is just me of mborzecki  stuff seems a bit unlikey for 2.30
<mvo> pedronis: also autopkgtests on i386 are failing access the board for unknown reasons
<mborzecki> pedronis: refresh timers?
<mvo> pedronis: its unlikely :) but reflecting what is being worked on, I think its ok if it moves to 2.31
<pedronis> time servers
<pedronis> services
<pedronis> mvo: ok, was just confused
<mvo> pedronis: no worries :)
<mborzecki> time servers... you made my hear skip a beat :)
<pedronis> mborzecki: it's was a comment on you or anything, just a bit confused because it will take a while to code and get through review, especially given we would like to clean up the current stuff too
<mborzecki> no worries :)
<pedronis> mvo: I want to produce a couple of small PRs about things IÂ mentioned yesterday at standup then IÂ will look at your main PR again
<mvo> pedronis: sounds good
<mup> PR snapd#4239 opened: tests: more debug info for classic-ubuntu-core-transition <Created by mvo5> <https://github.com/snapcore/snapd/pull/4239>
<mup> PR snapd#4240 opened: spread.yaml: increase workers for opensuse to 3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4240>
<mup> PR snapcraft#1638 closed:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1638>
<zyga-ubuntu> o/
<zyga-ubuntu> sorry for being so late, I need to balance my sleep/wake cycle :/
<mborzecki> zyga-ubuntu: hey
<jamesh> zyga-ubuntu: hi.  I pushed through some changes to my user-mounts PR (rebasing on master and converting it to use snap-update-ns).  It probably still isn't quite right, but it seems to handle the simple cases I tried.
<mvo> hey zyga-ubuntu ! good morning
<zyga-ubuntu> jamesh: hey! thank you for doing that, I saw the notification and I'll have a look today
<zyga-ubuntu> jamesh: what are your next plans?
<zyga-ubuntu> mvo: hey, sorry :|
<zyga-ubuntu> mvo: but but, were on one page of PRs :)
<jamesh> zyga-ubuntu: I'd like to try and get portals working
<zyga-ubuntu> jamesh: what bits are missing?
<jamesh> so updating those branches from months back, probably folding it into the desktop interface
<mvo> zyga-ubuntu: :)
<mvo> zyga-ubuntu: we just need to merge one, e.g. the opensuse one and we are back on a single page
<jamesh> zyga-ubuntu: the user-mounts thing is the main missing infrastructure.  We might run into some issues with how we change $XDG_RUNTIME_DIR though
<jamesh> parts of document portal expect certain paths to be the same inside and outside the mount namespace.
<zyga-ubuntu> jamesh: please update the forum thread with your plans; I'm slowly getting layout code in place and I can help
<zyga-ubuntu> today I'm a bit dizzy for complex things but I should have fresh head on Monday
<zyga-ubuntu> mvo: not sure if you were following the LXD discussion last night, I'll do what we agreed with jdstrand; make snap-confine setgid, drop the gid part early on and only restore it for that single freeze operation
<zyga-ubuntu> mvo: I should have that ready in ~1.5 hours
<zyga-ubuntu> mvo: hopefully by EOD we can push to beta
<mvo> zyga-ubuntu: \o/
<mvo> zyga-ubuntu: I'm trying to understand a pkgtest failure on i386 in parallel, worst case is that we need to disable one test in autopkgtest (ubuntu-core-transition is failing *only* on i386)
<mvo> zyga-ubuntu: so +1 for a .4
<zyga-ubuntu> only on i386, curious
<zyga-ubuntu> mvo: thank you, good luck
<pstolowski> mvo, hey, what's up with https://github.com/snapcore/snapd/pull/4063 ?
<mup> PR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>
<mborzecki> zyga-ubuntu: took a deeper look into https://forum.snapcraft.io/t/installing-vscode-snap-on-arch-linux/2871/5 imo there's something wrong with what's shipped in the snap, my best guess those libs are pieces of fedora userspace
<zyga-ubuntu> mborzecki: vscode is a classic snap
<zyga-ubuntu> mborzecki: no namespace magic, problems
<pedronis> zyga-ubuntu: hi, what's the status of #4109
<mup> PR #4109: cmd/libsnap: fix parsing of empty mountinfo fields <Created by zyga> <https://github.com/snapcore/snapd/pull/4109>
<zyga-ubuntu> pedronis: it's not critical, just something I found while hacking
<zyga-ubuntu> pedronis: there's a cleanup that I could move out of the function
<zyga-ubuntu> pedronis: and a fix itself
<zyga-ubuntu> pedronis: other than that not sure
<mvo> pstolowski: meh, no time yet for this
<pstolowski> mvo, ah, ok, no pressure, just checking
<cachio> zyga-ubuntu, hey
<cachio> zyga-ubuntu, I have defined for a test this snap https://github.com/sergiocazzolato/snapd/blob/tests-interface-network-status/tests/lib/snaps/test-snapd-network-status-provider/snapcraft.yaml
<cachio> zyga-ubuntu, but I am getting some denials when I do "sudo systemd-run --unit dbus-provider-2 test-snapd-network-status-provider.provider"
<zyga-ubuntu> cachio: hmm
<zyga-ubuntu> cachio: what kind of denials
<cachio> zyga-ubuntu, https://paste.ubuntu.com/25980351/
<zyga-ubuntu> aha
<zyga-ubuntu> is this blocking the test?
<zyga-ubuntu> it seems that snap wants to look at the mount table
<zyga-ubuntu> that should be handled by mount-observe
<zyga-ubuntu> not sure why it needs it, just saying
<cachio> zyga-ubuntu, I already tried that
<zyga-ubuntu> owner @{PROC}/@{pid}/mounts r,
<zyga-ubuntu> mount-observe grants this
<zyga-ubuntu> what did you try?
<cachio> yes, let me try again
<pstolowski> Chipaca, hello! is this clear what we want wrt to environ in commands here https://forum.snapcraft.io/t/papercuts-mouth-sized-bugs/228 ?
<cachio> zyga-ubuntu, I plug mout-observe and I see this https://paste.ubuntu.com/25980371/
<zyga-ubuntu> cachio: is this test looking at its own mount table?
<zyga-ubuntu> the rule says 'owner'
<cachio> no
<cachio> it is trying just to own the com.ubuntu.connectivity1.NetworkingStatus dbus interface
<zyga-ubuntu> cachio: I'm sorry but I don't know why it would also try to access the mount table
<Chipaca> pstolowski: what do you mean?
<cachio> zyga-ubuntu, I have to go to the doctor
<zyga-ubuntu> cachio: ok
<cachio> zyga-ubuntu, I'll be 5-10 minutes late for the standup
<Chipaca> pstolowski: the one about them being too restrictive?
<pstolowski> Chipaca, no; do we want to interpolate "command: FOO=$SNAP/bar actual_command" or "command: env PATH=$SNAP/usr/local/bin:$PATH desktop-launch" ?
<Chipaca> pstolowski: me, i'd explore something like: first, support having env vars as arguments to commands (even the first argument). Second, support arbitrary arguments but with no quoting nor escaping (so just disallow '"\)
<Chipaca> pstolowski: and third, make commands be either a string, or a list; if a list, pass to exec as is
<Chipaca> the reason for not getting into quoting and such is because it's a nightmare
<Chipaca> and the list approach makes it not needed
<Chipaca> (the list would take quotes and backslashes and pass them through)
<Chipaca> um
<Chipaca> pstolowski: answering your question there, no that's not the idea at all
<Chipaca> pstolowski: commands already have an environment
<Chipaca> that is, apps have an environment
<Chipaca> pstolowski: this is about support âcommand: foo $BAR $BAZâ
<mup> PR snapcraft#1742 opened: lxd: always remove tmp_dir after execution <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1742>
<Chipaca> it's possible that work is already done though; not sure
<pstolowski> Chipaca, ok, that should work if I read the code correctly
<Chipaca> that post is old
<pstolowski> Chipaca, yeah, and it originated from https://forum.snapcraft.io/t/declaratively-defining-environment-variables/175/6
<pstolowski> Chipaca, I'm trying to understand if what's done or not, there were a couple of aspects discussed there, I'm unclear what do we want at the end
<Chipaca> pstolowski: I think there is still work to be done here, but i've not looked in a while as i say
 * kalikiana time for a break
<Chipaca> popey: is the mailspring snap doing something wrong, or do none of the desktop integration bits work for anybody?
<Chipaca> i mean system tray and notifications, in particular
<Chipaca> (my indicators don't even work for regular apps for whatever reason but that's another discussion))
<pstolowski> Chipaca, I see, thanks
<sergiusens> Chipaca indicators fail completely for me, OSD works fine for mailspring
<popey> Chipaca: what version of Ubuntu?
<Chipaca> popey: 16.04
<popey> zyga-ubuntu / mvo your favorite topic! https://forum.snapcraft.io/t/vdpau-support-in-snaps-on-nvidia/2876
<popey> :)
<Chipaca> popey: i thin right now lxd is more favourite
<Chipaca> also my keyboard is dying :-(
<jdstrand> ikey|zzz: hey, regarding your forum post (https://forum.snapcraft.io/t/manual-review-of-base-snaps/2839/4), both zyga and I responded to you (so not talking into the void). we need an architect to participate in the discussion, hence the open question to niemeyer in that topic
 * ogra_ hands Chipaca https://www.massdrop.com/buy/xmit-hall-effect-mechanical-keyboard
 * popey bans ogra_ for posting massdrop links, which will cause the collapse of the economy as we all buy them
<ogra_> hahaha
<Chipaca> also, that import duty
<Chipaca> ogra_: i've got a lot of nice keyboards! the one that's dying is the one for my tablet (that i'm currently on)
<ogra_> ah, thats bad indeed
<ogra_> well, the above is indistructable ... (at least the switches)
<jdstrand> pedronis: hey, I think that the base declaration is correct and the spread test failure, while real, is the right behavior
<pedronis> jdstrand: my point is mostly that people that were testing snaps doing this will need to change their tests
<jdstrand> pedronis: "Then the plug is connected by default"
<jdstrand> the test should be adjusted
<pedronis> because they don't get autoconnection for their --dangerous install anymore
<jdstrand> I understand that
<pedronis> just making clear this will be  a "regression"Â for them
<jdstrand> that is the correct behavior. there are 5 snaps that use this
<pedronis> I know
<jdstrand> so I can communicate that to them and in documentation
<pedronis> ok
<pedronis> I fixed the integration test already
<jdstrand> but it does mean the spread test needs to be adjusted
<pedronis> I did that
<pedronis> I think we are getting other spurious failures now
<jdstrand> oh I missed that
 * jdstrand looks
<pedronis> it's just taking too long
<pedronis> there's a PR by mvo that could help with that
<pedronis> mvo: we still got prepare failures in you add opensuse workers PR :/
<pedronis> *your
<Son_Goku> pedronis, have we sync'd the Fedora 27 VM base image to the current Fedora 27 GA?
<Son_Goku> and resync'd Rawhide to a recent snapshot of it?
<pedronis> no clue
<pedronis> I'm not on top of that
<mup> PR snapd#4241 opened: store: bit less aggressive retry strategy <Created by pedronis> <https://github.com/snapcore/snapd/pull/4241>
<Son_Goku> who is?
<pedronis> mvo, zyga-ubuntu, cachio
<pedronis> maybe
<pedronis> Chipaca: could you look at #4241 (it's tiny)
<mup> PR #4241: store: bit less aggressive retry strategy <Created by pedronis> <https://github.com/snapcore/snapd/pull/4241>
<zyga-ubuntu> Son_Goku: cachio is working on updating the debian images, we alredy said that other images must follow
<Chipaca> sure
<Chipaca> pedronis: +1
<pedronis> thx
<mup> PR snapd#4242 opened: panic early if snapd is pointed to staging but staging keys are not compiled-in <Created by pedronis> <https://github.com/snapcore/snapd/pull/4242>
<zyga-ubuntu> mvo: I'll push the branch in a moment, just want to see it work one more time
<pedronis> mvo: do we need to disable the opensuse tests until we understand more?
<zyga-ubuntu> pedronis: +1, also for fedora if that is broken and would impede release
<cachio> Son_Goku, zyga-ubuntu the new fedora images will be ready early next week
<Son_Goku> cool
<cachio> mvo, zyga-ubuntu the debian images are not updated yet
<sborovkov> Hi
<sborovkov> No matching distribution found for python-distutils-extra (from snapcraft)
<sborovkov> I am getting this when doing pip install snap craft on ubuntu
<sborovkov> How do I work around this?
<zyga-ubuntu> mvo: can you look at https://github.com/snapcore/snapd/pull/4230/commits/7722c0404b97fa0ac119acb495caa62c3f5ab321 please
<mup> PR #4230: tests: add test to run snap inside lxd as a user <Created by mvo5> <https://github.com/snapcore/snapd/pull/4230>
<sergiusens> sborovkov `pip install -r https://raw.githubusercontent.com/snapcore/snapcraft/master/requirements.txt`  python-apt and -distutils-extra are not on pypi
<sborovkov> sergiusens, thanks
<mvo> zyga-ubuntu: sure, looking
<cachio> jdstrand, hey
<mvo> zyga-ubuntu: looks good, thank you
<cachio> jdstrand, I am creating s snap with this https://paste.ubuntu.com/25980439/
<cachio> jdstrand, this is the python code: https://paste.ubuntu.com/25981110/
<cachio> jdstrand, and when I do "sudo systemd-run --unit dbus-provider-2 test-snapd-network-status-provider.provider"
<cachio> I see this denial
<cachio> jdstrand, https://paste.ubuntu.com/25980371/
<cachio> jdstrand, any idea what could be the reason?
<zyga-ubuntu> jdstrand: can you look as well please, that's the thing you suggested last night
<jdstrand> cachio: does the snap fail to work with that? most often that is a noisy denial and not a problem. The snap could plugs the mount-observe interface to get rid of it
<jdstrand> cachio: python is one of those environments that does that (noisy denial but works otherwise)
<cachio> jdstrand, ok
<cachio> I'll check that
<jdstrand> zyga-ubuntu: sure
<cachio> jdstrand, https://paste.ubuntu.com/25981162/
<cachio> jdstrand, it is not from a snap
<mborzecki> i'm calling it a day, have a nice weekend everyone
<mvo> cachio: thanks for checking 4240 - is there something we can do to help the opensuse tests to run faster again?
<mvo> cachio: i.e. caching the downloads and storing that in our test-image or something?
<cachio> mvo, I think the best we can do is to update regularly the images
<cachio> so all the provisionning part is reduced almost to 0
<cachio> mvo, I'll work on that next week
<cachio> I'll need a new key for this
<mvo> cachio: ok, thanks
<mvo> cachio: should we disable opensuse until then?
<sergiusens> elopio kyrofa updating the tests from other branches takes a bit
<cachio> mvo, I'll take a look to opensuse
<mvo> cachio: thank you
<cachio> mvo, not sure why it is failing noe
<cachio> now
<cachio> it is a timeout in the prepare trying to install dependencies
<cachio> mvo, it shouldn't happen
<mup> PR snapd#4243 opened: tests: disable classic-ubuntu-core-transition on i386 temporarly <Created by mvo5> <https://github.com/snapcore/snapd/pull/4243>
<zyga-ubuntu> mvo: tests/main is green, let's release this
<zyga-ubuntu> can everyone available please review 4230
<mvo> zyga-ubuntu: which one is green?
<zyga-ubuntu> mvo: (tests/main ran locally)
<mvo> zyga-ubuntu: for what PR (sorry, I lack context somehow)
<zyga-ubuntu> mvo: 4230
<mvo> zyga-ubuntu: don't we need a +1 from jamie first?
<zyga-ubuntu> mvo: right, that's why I asked for reviews :)
<mvo> zyga-ubuntu: aha, ok. yeah, +1 for releasing asap
<elopio> good morning.
<mvo> zyga-ubuntu: but it looks like your PR will fail on opensuse :/ only 3 min left and
<mvo> 80 tests to run
<zyga-ubuntu> oh drat
<zyga-ubuntu> mvo: well, this is master
<mvo> zyga-ubuntu: yeah
<zyga-ubuntu> mvo: shall we disable suse or shall we bump the number of workers by one?
<zyga-ubuntu> mvo: we can do a tailored PR in 2.29
<mvo> zyga-ubuntu: adding a worker was not enough, I'm in favor of disabling
<mvo> zyga-ubuntu: but cachio said he is looking into it
<zyga-ubuntu> mvo: ok
<cachio> mvo, zyga-ubuntu I am reproducing the error here
<cachio> we can disable it until the problem is fixed
<zyga-ubuntu> do we have any idea why it might be slower?
<cachio> no yet, waiting for the timeout yet
<cachio> zyga-ubuntu, let's disabe opensuse, then we can enable it again
<cachio> zyga-ubuntu, mvo I tested here and it worked
<cachio> perhaps is a temporal issue
<zyga-ubuntu> cachio_lunch: did oyu test on linode?
<kyrofa> sergiusens, do we want to determine a landing order for these other PRs?
<kyrofa> (so we know which ones to fix first)
<mvo> zyga-ubuntu: you have review feedback for 4230
<zyga-ubuntu> looking
<mvo> zyga-ubuntu: let me know if you want help :)
<jdstrand> yes, was just going to ping you on that :)
<mvo> zyga-ubuntu: but looks straightforward
<zyga-ubuntu> thank you jdstrand
<zyga-ubuntu> mvo: testing and I'll push in a sec
<mup> PR snapcraft#1743 opened: catkin plugin: support building entire workspace <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1743>
<zyga-ubuntu> mvo: did you disable suse?
<zyga-ubuntu> mvo: I'd like to pull master and then push this
<zyga-ubuntu> mvo: you can, I think, just git push the backend to manual
<zyga-ubuntu> mvo: to save us some time
<zyga-ubuntu> mvo: I pushed, please merge/squash
<zyga-ubuntu> jdstrand: https://github.com/snapcore/snapd/pull/4230/files
<mup> PR #4230: tests: add test to run snap inside lxd as a user <Created by mvo5> <https://github.com/snapcore/snapd/pull/4230>
 * zyga-ubuntu needs to play with those real/effective/saved ids thing more 
<cachio> zyga-ubuntu, I tested on linode
<cachio> zyga-ubuntu, I executed again the change to add a new worker for suse
<cachio> let's see if it fails again
<cachio> if it fails I'll disable opensuse
<jdstrand> zyga-ubuntu: done. sorry I forgot something in my suggestion (teeny change)
<zyga-ubuntu> jdstrand: aha
<zyga-ubuntu> jdstrand: pushed :)
 * zyga-ubuntu needs to run
<cachio> jdstrand, https://paste.ubuntu.com/25981162/
<cachio>  jdstrand, it is not from the tests
 * kalikiana dinner time
<zyga-afk> mvo: please get this to beta tonight if we can
<zyga-afk> mvo: I'll be back in some hours
<mvo> zyga-afk: I will push for it
<kyrofa> elopio, one issue with the refactor now that I'm using it: it tells me tests are skipped, but doesn't say it's because they were slow
<kyrofa> Before the refactor it was helpful and said "skipping slow test" or something like that
<mvo> zyga-afk: once tests are in I will run the machinery
<mvo> zyga-afk: thanks a bunch of fixing this!
<pedronis> mvo: I did another pass on managed,  but didn't see your last commit, now I saw, I think the placement of that code is problematic
<pedronis> *saw it
<sergiusens> kyrofa oh, if that is happening, I'd agree
<kyrofa> Alright, fixing
<sergiusens> kyrofa also, rebase on top of new master
<sergiusens> kyrofa I did minor piggybacking on that last merge (sorry, but sorry)
<kyrofa> cratliff, catkin-tools has finally landed!
<sergiusens> kyrofa and take extra care on your rebases/merges as things need to manually move on your side for tests to keep on running ;-)
<kyrofa> sergiusens, yeah I'm working through the ament one now
<kyrofa> Basically, if you added any new test files, they need to move, but if you modified ones that were already there, you're mostly there
<mup> PR snapcraft#1593 closed: catkin tools plugin: add catkin tools support <Created by cratliff> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1593>
<pedronis> mvo: we can discuss options on Monday
<pedronis> mvo: do you need anything more from me today?
<mvo> pedronis: thank you, I think I'm fine, I will baby-sit the build and do 2.29.4
<elopio> kyrofa: how weird. Please report a bug, and I'll look at it as soon as I'm over with the call for testing.
<elopio> flexiondotorg: popey: can I send a coschedule post linking to the call for testing? https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-35/2880
<mup> PR snapd#4244 opened: disabling opensuse until timeout issue is fixed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4244>
<cachio> mvo, failed again on opensuse, this is the PR https://github.com/snapcore/snapd/pull/4244
<mup> PR #4244: disabling opensuse until timeout issue is fixed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4244>
<cachio> I am still trying to reproduce it for here
<mvo> cachio: thanks
<mvo> cachio: once its green I will merge and push into the other two 2.29 prs
<cachio> mvo, good
<popey> elopio: great idea!
<pedronis> cachio: thanks
<popey> elopio: make sure you use the link button to give you a tagged link :)
<popey> get them vaulable internet points!
<kyrofa> sergiusens, alright, ament plugin is up to date
<popey> https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-35/2880?u=elopio <-
<elopio> popey: what is a tagged link? Does my user get internet points?
<popey> Yes!
<popey> see the url above, got your name in it
<elopio> oh man, I've been stripping that u everywhere! So much karma lost :(
<popey> sad4u
<cachio> mvo, https://paste.ubuntu.com/25982089/
<cachio> it took 5 minutes to install python3-docutils in opensuse
<elopio> https://en.wikipedia.org/wiki/Success_Kid#/media/File:SuccessKid.jpg
<cachio> it is in linode
<cachio> mvo, it should take few minutes
<cachio> mvo, few seconds
<cachio> <30s
<mvo> cachio: woah
<mup> PR snapd#4245 opened: interfaces/screen-inhibit-control: handle ScreenSaver/Screensaver in DBus API <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4245>
<cachio> mvo, testing in a vm on aws to compare
<mvo> cachio: thanks. 4244 has not even started yet, slightly annyoing
<mvo> jdstrand: does 4230 looks good to you now?
<cachio> mvo, in aws works pretty fast
<cachio> mvo, the problem is in linode
<mup> PR snapd#4243 closed: tests: disable classic-ubuntu-core-transition on i386 temporarly <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4243>
<cachio> mvo, any idea why I could get this error?
<cachio> https://paste.ubuntu.com/25981162/
<cachio> mvo, I have a snap running as a service, this is the snapcraft.yaml
<cachio> mvo, also getting this denial when I start the service
<cachio> https://paste.ubuntu.com/25980351/
<mup> PR snapd#4230 closed: tests: add test to run snap inside lxd as a user <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4230>
<mup> PR snapd#4246 opened: snap-confine: fix snap-confine under lxd <Created by mvo5> <https://github.com/snapcore/snapd/pull/4246>
<mvo> jdstrand: -^
<mvo> cachio: new beta is still 1-2h away, tests are slow :(
<cachio> np
<cachio> mvo, any idea about the problem with the network-status-provider snap?
<kyrofa> sergiusens, pip extraction has also been updated
<magicaltrout> hello folks
<magicaltrout> how do you install a classic snap from a local build?
<magicaltrout>  sudo snap install --classic ./my-snap-name_0.1_amd64.snap
<magicaltrout> error: cannot find signatures with metadata for snap "./my-snap-name_0.1_amd64.snap"
<nacc> magicaltrout: --dangeours
<nacc> *dangerous
<magicaltrout> winning
<nacc> magicaltrout: it basically says there is no store data for it
<jdstrand> mvo: yep, done (as per other channel)
<mvo> jdstrand: thank you
<jdstrand> mvo: is 2.30 already branched?
<jdstrand> I guess I can figure that out myself
<jdstrand> doesn't look like it
<mvo> jdstrand: not branched yet, why?
<jdstrand> mvo: just wanted to know if I needed to send up 2.30 branches too
<mvo> thanks
<cratliff> kyrofa  That's great.  I saw the .36 milestone and thought it would be a while.  Glad to see it's in.  I should try checking out the extended workspaces sometime soon.
<sergiusens> kyrofa I have a new branch up too which could use a look
<kyrofa> sergiusens, as do I-- the catkin-build-entire-workspace one
<mup> PR snapcraft#1744 opened: elf: conversion from libraries <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1744>
<sergiusens> kyrofa I saw it ;-)
 * kyrofa reads PEP 484
<mup> PR snapd#4244 closed: disabling opensuse until timeout issue is fixed <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4244>
<kyrofa> Darn, autopkgtest queue has built up a bit again
<kyrofa> elopio, pretty sure the bot is not pinging subscribers
<kyrofa> I don't think it's ever pinged me
<elopio> kyrofa: yup. Pretty sure you broke it ;)
<kyrofa> Nu uh! It NEVER pinged me, I swear
<elopio> kyrofa: so, I think next week I can add tests, and then it should be obvious what's wrong. No hurries there, right?
<kyrofa> elopio, yeah, no rush other than curiosity, haha
<kyrofa> elopio, kinda fun to poke at it. It'll be even better with tests
<kyrofa> elopio, let me know? Happy to review
<kyrofa> Does errbot have some sort of testing lib?
<elopio> kyrofa: yes, it has. Should be easy to fake integration tests.
<kyrofa> Sweet
<kyrofa> man this new firefox is ugly
<kyrofa> snappy-m-o, autopkgtest 1583 xenial:i386
<snappy-m-o> kyrofa: I've just triggered your test.
<kyrofa> snappy-m-o, autopkgtest 1607 xenial:i386
<snappy-m-o> kyrofa: I've just triggered your test.
<brunosfer> Hi
<pdefreitas> hi
<brunosfer> hi
<pdefreitas> snapamos
<brunosfer> hi
<brunosfer> hi
<brunosfer> hi
<pdefreitas> hi
<brunosfer> I'm trying to build a snap for offline connectivity. Do you know any good tutorial on how to begin with that?
<nacc> brunosfer: "for offline connectivity"?
<sergiusens> kyrofa it is not pinging
<sergiusens> and never worked in this irc form either
<cachio> mvo, news about the beta?
<mup> PR snapd#4247 opened: interfaces: allow /bin/chown and fchownat to root:root <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4247>
<jamesbenson> chipaca?
<sergiusens> kyrofa is my use of mypy your only concern in the PR?
<mvo> cachio: unfortunately not, tests still not finished :(
<kyrofa> sergiusens, not done looking through it yet
<cachio> mvo, np
<om26er> jdstrand: thanks for the approval. One question: since I filed that Android Studio request, I made many changes to the packaging and the latest revision(15) is what we want to release. Will that need a separate approval from you ?
<om26er> https://dashboard.snapcraft.io/dev/snaps/8605/rev/15/
<om26er> oops, it seems that got approved just now.
<jdstrand> om26er: no. you are good to go
<mup> PR snapcraft#1745 opened: static tests: upgrade to the newest flake8 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1745>
<kyrofa> sergiusens, variable annotations are python 3.6 only
<sergiusens> kyrofa do they fail for you?
<sergiusens> kyrofa snapcraft is 3.6
<kyrofa> sergiusens, not in the deb :)
<sergiusens> unless you mean 3.5, for which they would be silently ignored
<kyrofa> I've not tried, was concerned they'd be syntax errors
<sergiusens> kyrofa does it fail? it says 3.5 here -> https://docs.python.org/3/library/typing.html
<sergiusens> where did you get 3.6?
<kyrofa> sergiusens, comment on the PR. I'm specifically talking about syntax like this: ldd_out: List[str] = []
<kyrofa> Annotations on variables, not functions/classes
<sergiusens> oh, ic
<sergiusens> kyrofa ok, enough with static checking, what about the rest?
<zyga-afk> re
<zyga> mvo: still here?
<mvo> zyga: yes
<sergiusens> the comment notation is sad
<zyga> mvo: how are things? I saw the PR
<mvo> zyga: we have unhappy tests, otherwise all is well
<zyga> mvo: unhappy with LXD or random annoying failing test?
<mvo> zyga: random
<mvo> zyga: opensuse
<mvo> zyga: and also random
<sergiusens> elopio snapcraft#1745 is for you btw ;-)
<mup> PR snapcraft#1745: static tests: upgrade to the newest flake8 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1745>
<sergiusens> kyrofa after that I'll propose a general mypy sanity fix and rebase my branch on that
<kyrofa> Alright. Noticed mypy isn't in the archives, too bad
<zyga> mvo: drat
<zyga> mvo: restart-travis-as-a-service
<kennyloggins> do I just apt update to get the new snapd ?
<zyga> "one does not just apt update to get new snapd" (with the mordor thing meme)
<zyga> kennyloggins: it depends
<zyga> kennyloggins: sometimes a core-reexec issue is faster than apt update
<kennyloggins> IDK - i just went with stable - tell me what to do ?
<zyga> kennyloggins: stable is usually fine unless a specific issue is affecting you
<kennyloggins> Iam just a user.
<sergiusens> kyrofa why would that matter?
<sergiusens> we don't depend on the archives for any of the static tests
<zyga> kennyloggins: in that case I'd suggest sticking to stable
<mup> PR snapd#4248 opened:  snap-confine: fix snap-confine under lxd <Created by mvo5> <https://github.com/snapcore/snapd/pull/4248>
<kyrofa> sergiusens, just makes things easier, that's all. Makes our dev guide harder
<kennyloggins> okay - I shallnot do anthing then. just saw this post:
<kennyloggins> https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-35/2880/5
<kyrofa> Not a big deal
<zyga> kennyloggins: that's for snapcraft, right?
<zyga> kennyloggins: I usually think about snapd, not snapcraft, sorry, my bias
<kennyloggins> zyga: coolbeans. No idea wat I am doing ! Weeeeeeeeee
<kennyloggins> https://v.gd/4vCGRy
<sergiusens> kyrofa but it doesn't change, it still is `pip install -r requirements-devel.txt`
<mup> PR snapd#4241 closed: store: bit less aggressive retry strategy <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4241>
<mup> PR snapd#4248 closed:  snap-confine: fix snap-confine under lxd (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4248>
<zyga> mvo: what happened with that merge btw? why did you have to open a new PR?
<mvo> zyga: yes, messup
<kyrofa> Haha, sergiusens you need to start using a github mobile app or something
<kyrofa> The emails are never threaded
<mvo> zyga: when I merge the opensuse fix something strange happend
<sergiusens> kyrofa oh, but why, I am using mailspring ;-)
<mvo> zyga: 2.29.4 is building in the ppa now finnaly
<mvo> finally
<sergiusens> threads are a thing of the past :-P
<kyrofa> Hahaha
<zyga> mvo: thank you :-)
<zyga> mvo: so, tomorrow morning my lxd container should work ok
<zyga> mvo: (well, until I fix the other bug it will be affected by reomve)
<zyga> mvo: but that should give us a chance to releas next week
<kyrofa> What the heck... sergiusens all of a sudden libpython2.7-minimal is including a sitecustomize in /etc/python2.7/
<sergiusens> kyrofa darn, I got distracted with your comment :-P focused the window to say ... er just that
<kyrofa> I didn't know that was a valid location!
<mvo> zyga: yeah, I hate to leave this broken over the WE, it needs to be at least in beta imo
<sergiusens> kyrofa but, there has been no updates to python in a while on 16.04 https://launchpad.net/ubuntu/+source/python2.7
<sergiusens> kyrofa did you shuffle code around?
<kyrofa> It was one of the PRs I rebased
<kyrofa> Not sure why they're clashing anyway... I suspect I broke something
<kyrofa> Oh. No, that's where we're placing ours now. What...
<kyrofa> Eh, I'll figure it out
<kyrofa> Oh it's a symlink. How interesting
<zyga> mvo: if you manage to let's also write something on the forum
<zyga> mvo: (I can do that if you'd like)
<gsilvapt> Hello all. I want to follow elopio suggestion on the forum to test the latest snapcraft version
<gsilvapt> I can do it by cloning the repo and using the snapcraft's binaries to perform stuff, right?
<zyga> gsilvapt: did his post include instructions?
<zyga> gsilvapt: sorry for a naive question, I didn't read it
<gsilvapt> https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-35/2880
<gsilvapt> zyga, kind of. I bet my question is fairly simple but the problem is I already have snapcraft installed
<gsilvapt> But I know there is a way to have 2 installations working
<kyrofa> gsilvapt, you can just test the snap if you like
<kyrofa> But yes, you can also run it from source
<zyga> gsilvapt: I'm sure that's true, I'm sorry I canont help you more
<gsilvapt> kyrofa, under the snapcraft folder, right?
<gsilvapt> I need to get used to these things if I want to contribute to snapcraft :P
<gsilvapt> no worries, zyga :D
<kyrofa> gsilvapt, here you go: https://github.com/snapcore/snapcraft/blob/master/HACKING.md
<kyrofa> gsilvapt, I suggest doing it that way
<gsilvapt> ok, I have that installed. I need to checkout to branch 2.5 and perform the steps there, right?
<gsilvapt> s/2.5/2.35
<gsilvapt> ok, nevermind, I'm using the version I need :-=)
<gsilvapt> ok, nevermind, I'm using the version I need :-)
<mvo> jdstrand, zyga store upload of 2.29.4 core fails because of the review scripts apparently, the error is "found errors in file output: unusual mode 'rws...
<zyga> ah
<zyga> drat
<zyga> mvo: store checks for setgid
<zyga> mvo: we need a fix from jdstrand and roadmr
<roadmr> zyga: hi! which version of the review tools do you need for this?
<zyga> roadmr: the one unwritten :)
<roadmr> zyga: I have 2 in the queue right now, aiming for a Monday rollout
<roadmr> zyga: dagnabbit :D
<zyga> roadmr: in reality we need one off approval
<mvo> roadmr, jdstrand, zyga here is an example https://launchpad.net/~snappy-dev/+snap/core/+build/108281
<zyga> roadmr: we can fix this properly next week
<zyga> but it would be good if that upload was approved
<gsilvapt> kyrofa, are you available in 30 minutes? I would like to implement the `snapcraft version` command requested that we discussed in the other night. I haven't tried any further but I think tonight is the night :)
<roadmr> zyga: so do you indeed want that weird mode?
<roadmr> mvo: ^^
<roadmr> zyga: I'm not really sure what to do :( because the status on the store is "failed review", not "awaiting manual review". The latter, I could possibly review and approve; but the former, and it being core, and it being Friday evenight, sounds like a recipe for getting yelled at :(
<mvo> roadmr: yes, its a long story
<mvo> roadmr: right, yes, I think your concerns are sensible
<mvo> roadmr: the backstory is https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850/40 and we are quite eager to fix this regression but if its complicated/dangerous its not the best time on friday :(
<roadmr> mvo: I think it is, for reasons explained above :( I might chance it if I had more experience with reviews, but in truth, jdstrand handles those hairy bits so I'd be doing it for the first time.
<mup> PR snapd#4246 closed: snap-confine: fix snap-confine under lxd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4246>
<kyrofa> gsilvapt, yes, I'll be here :)
<kyrofa> Happy to help
<zyga> mvo: it's kind of depressing we dind't realize this yesteray
<mvo> zyga: yes, slightly depressing
<zyga> roadmr: can we make the modification to the store to allow that different mode?
<roadmr> zyga: it's click-reviewer-tools rejecting the mode
<roadmr> it just spits out an error in the review results, and that's what causes the store to consider the upload rejected
<mvo> zyga: please send me a tg if this lands in the store, then I will promote to beta tomorrow morning, otherwise it will be monday (slightly sad)
<zyga> ok
<zyga> roadmr: who maintains c-r-t?
<roadmr> zyga: jdstrand does
<zyga> jdstrand: can you make that modification?
<zyga> ok, I modified c-r-t
<zyga> roadmr: would you deploy my change or is that too outside of protocol?
<roadmr> zyga: I can't even deploy it myself, we'd need complicity from a webop
<zyga> the non-test diff is: http://paste.ubuntu.com/25984118/
<roadmr> one-character diff :)
<zyga> hmm, setup.py test on clean master seems to fail
<zyga> FAILED (failures=4)
<roadmr> :(
<gsilvapt> kyrofa,I'm just not getting how the method to get the version is called using --version
<gsilvapt> If you could help understand that bit, perhaps I could work on a solution to have it printing snapcraft's version using version and --version
<kyrofa> gsilvapt, sure, let me look, here
<gsilvapt> When I look at the internals/__init__.py, I understand the method that gets the version number is the _get_version and that method can be reused. I'm just not understanding where is that method called
<zyga> ok, I give up
<kyrofa> gsilvapt, we use a library called "click" for our CLI handling
<zyga> jdstrand: if you make that modificaiton please leave me or mvo a message
 * zyga waves good night
<kyrofa> gsilvapt, one of its features is that it has a `version_option` decorator accepts a version number, and adds a --version option
<gsilvapt> Hum, I remember seeing some bits of code with that somewhere
<kyrofa> gsilvapt, this is done in snapcraft/cli/__init__.py
<kyrofa> gsilvapt, so I suggest you continue using the snapcraft.__version__ attribute
<kyrofa> gsilvapt, but you'll need to add a new command
<gsilvapt> Ah, I see it. I once stepped into this when I was trying to find what was going on
<gsilvapt> Hum. So there is no chance of re-using the click library? I haven't look at the code but lets see if I can figure this out with these instructions
<kyrofa> gsilvapt, I suggest doing that in a new file, snapcraft/cli/version.py
<kyrofa> Oh yes, you'll use the lib, but I had a quick look and it doesn't look like it supports magically adding a "version" command like it did for the --version option
<mup> PR snapcraft#1745 closed: static tests: upgrade to the newest flake8 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1745>
<kyrofa> But that's okay, adding a command is still pretty easy
<kyrofa> gsilvapt, I suggest you refer to snapcraft/cli/help.py
<kyrofa> Yours should look pretty similar
<kyrofa> But even simpler
<gsilvapt> Just to check: This line is the one that actually adds the --version option, right? `@click.version_option(version=snapcraft.__version__)`
<gsilvapt> kyrofa, would it make sense to have both commands in the same file?
<kyrofa> gsilvapt, indeed, that line
<kyrofa> gsilvapt, that wouldn't follow the convention established for other commands
<kyrofa> gsilvapt, sticking to established conventions is one way we're all able to share a codebase
<kyrofa> gsilvapt, so no, I suggest putting it in snapcraft/cli/version.py
<gsilvapt> kyrofa, that's not my suggestion, I did not use the most correct words. Shouldn't --version and version commands be established in the same file? i.e, should I move the --version option to this new file so that they stay together?
<kyrofa> gsilvapt, ah, I see
<kyrofa> gsilvapt, as far as I can see, that's not actually possible, as the --version option must be specified on the root command, `snapcraft`, which is defined right there in __init__.py
<gsilvapt> Hum, ok I see
<gsilvapt> So, lets get some implementations done and hopefully running
<kyrofa> Just look closely at how help is done
<kyrofa> snappy-m-o, autopkgtest 1743 xenial:arm64
<snappy-m-o> kyrofa: I've just triggered your test.
<kyrofa> snappy-m-o, autopkgtest 1743 artful:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<gsilvapt> I think I may have found a working solution but I think I have a poor configuration of lxc
<gsilvapt> tried running ./runtests.sh snapcraft/tests/unit/commands and got this in the first lines: https://pastebin.com/GSvYFCt1
<gsilvapt> Well, I keep getting those after a few tests
<kyrofa> Hmm.... not seen that before
<gsilvapt> unittest generates a full report when it's done, am I correct? It's hard to keep looking at all these tests
<kyrofa> gsilvapt, it'll die if it errors
<kyrofa> Although I suspect it won't if all you did was add a new command. Did you write tests for it as well?
<gsilvapt> yes, it said it failed anyway. And my test failed :-D
<gsilvapt> Too bad I can't use Pycharm's test feature to just test the one I wrote
<gsilvapt> yes, I did a similar test to the existing one using version
<kyrofa> You can always try `python3 -m unittest snapcraft.tests.unit.commands.test_version (or whatever you called it)
<gsilvapt> hum, right
<gsilvapt> but is there an actual reason why PyCharm can't compile snapcraft?
<gsilvapt> I have I feeling I have lots of tools poorly configured :|
<kyrofa> gsilvapt, I'm afraid I don't know-- I don't use pycharm
<gsilvapt> kyrofa, vim user?
<kyrofa> A mixture of vim and atom
<kyrofa> When atom decides not to crash X
<gsilvapt> I used to use Vim but recently started using IntelliJ for Java and just fell in love with its features. So I decided to give a try to PyCharm. I still use Vim modal editing style. I can't go back to not use it
<gsilvapt> By the way, I think I have some dependencies missing, even after installing requirements and requirements-devel
<gsilvapt> kyrofa, elopio, in case you have seen anything like this before: https://pastebin.com/BDZFzmrQ
<gsilvapt> I'm considering removing and reinstalling lxc/lxd
<elopio> gsilvapt: weird. I have seen weird lxd errors in the past, but now It's pretty much stable for me.
<elopio> I'm on xenial, using the lxd snap. If the snap doesn't work for you, you can try the deb.
<gsilvapt> So, purge lxd/lxc, reinstall and try again
<gsilvapt> ok, glad I chose a free night for this, ehehe
<gsilvapt> But that basically means it is failing to start containers somehow
<elopio> gsilvapt: if you installed with the deb, you need to purge lxd and lxd-client
<gsilvapt> I think the system is lxd clean
<gsilvapt> elopio, do I need a particular version of Ubuntu in the container?
<gsilvapt> I previously had 17.10
<gsilvapt> Since you're here and the expert using lxd, should I remove the containers after using them?
#snappy 2017-11-18
<gsilvapt> Well, it did not work. Reinstalling lxd/lxc still returns loads of errors
<gsilvapt> I was avoiding a clean installation for the up coming months but I guess I will have to do it regardless...
<ikey> this ppa would have my nvidia stuff in right? https://launchpad.net/~snappy-dev/+archive/ubuntu/edge
 * ikey wants to find some victims for new snap builds
<ikey> er *helpers
<elopio> gsilvapt: for your container, I recommed xenial. And there are many containers at play, if you use SNAPCRAFT_CONTAINER_BUILDS, then it's better to delete them only when you are done packaging the snap.
<gsilvapt> I still was getting all the errors, I tried removing all and reinstalling snapcraft
<gsilvapt> Lets see if this fixes anything
<gsilvapt> elopio, here's another bug message for you: https://pastebin.com/5Dec0waa
<gsilvapt> Any sugegstions? :P
<elopio> gsilvapt: did you run all the steps in HACKING.md?
<gsilvapt> I'm pretty certain I did but I'll double check
<elopio> you are missing a dependency that's installed in the virtualenv, so it's very likely that you skipped something important.
<gsilvapt> annnddd I'll have to start from scratch because it says it installs snapcraft successfully but snapcraft --versions fails
<gsilvapt> Just tried a clean install and keeps saying invalid command 'bdist_wheel'
<gsilvapt> I'm trying a suggestion I saw online to install wheel
<gsilvapt> Apparently it seemed to work out
<gsilvapt> I keep getting  Failed building wheel for python-apt
<gsilvapt> and now I'm stuck in the same loop: Can't install snapcraft. No files were found to uninstall
<jdstrand> while mvo, roadmr, zyga are out, I'll mention for others following along that I made the review tools change and sent them an email
<zyga-ubuntu> good morning
<zyga-ubuntu> meh, this is saturday!
<zyga-ubuntu> I can sleep
<mup> PR snapd#4238 closed: interfaces/browser-support: adjust base declaration for auto-connection <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4238>
<mup> PR snapcraft#1607 closed: python plugin: use extracted pip <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1607>
* popey changed the topic of #snappy to: Join the forum: https://forum.snapcraft.io/t/when-to-use-forum-vs-irc/38 |
<gsilvapt> sergiusens, I also tried that but then got new errors
<gsilvapt> I have a feeling this is somehoe related with python 2 and python 3
<gsilvapt> maybe I should try this stuff using Python 3
<gsilvapt> Well, runing eveything with pip3 and uso worked
<gsilvapt> s/uso/sudo
<gsilvapt> Nope, new bugs. I'm getting quite desperate about this. Don't know what I should do
<gsilvapt> If anyone could have a look at check if there is anything missing: https://pastebin.com/uBVR3cXV
<gsilvapt> And yes, I've done all the things in the hacking.md file
<gsilvapt> I moved this over a new discussion thread to see if someone knows how to fix this issue quicker
<kennyloggins> >
<kennyloggins> Where is the github page for the snappy website (the actual github for the webpage itself) located ?
<kennyloggins> found it : https://github.com/canonical-websites
<gsilvapt> I'm an idiot. I was using an old repo and obviously the commands weren't working...
<gsilvapt> After implementing, I should run the tests AFAIK. Do I have to bring those to the PR or the CI will take care of that for me?
<gsilvapt> What does it mean when exit code = 2?
<gsilvapt> In the testing script
#snappy 2017-11-19
<Harish_> hey i am getting an error
<Harish_> error: cannot communicate with server: Post http://localhost/v2/snaps/anbox-installer: dial unix /run/snapd.socket: connect: no such file or directory
<Harish_> please help me
<Harish_> this is the command i ran snap install --classic anbox-installer && anbox-installer
<kennyloggins> afternoon \o
<gsilvapt> Anyone around with some experience writing tests for Snapcraft?
<Son_Goku> eek
<Son_Goku> it's taken the better part of the day to go through the work of rebasing snapd versions
<Son_Goku> I'm *still* not done and I started ~3 hours ago
<mwhudson> er does snapcraft 2.35 require a newer lxd than is in the archive for xenial?
<Son_Goku> mwhudson: that would surprise me
<mwhudson> yeah me too
<mwhudson> but it seems to call lxc image info --format=json which isn't supported by my lxd
<mwhudson> i haven't tried to run it yet, mind, just read the code
<mwhudson> (well, rebased a branch of mine)
<mwhudson> oh it only triggers a warning i think
#snappy 2018-11-12
<doko> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/s/snapcraft/20181108_122554_7d4c2@/log.gz
<doko> raceback (most recent call last):
<doko>   File "/tmp/autopkgtest.P8IYeA/build.5xT/src/tests/integration/plugins/test_rust_plugin.py", line 107, in test_cross_compiling
<doko>     self.assertThat(binary, HasArchitecture("aarch64"))
<doko>   File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 498, in assertThat
<doko>     raise mismatch_error
<doko> testtools.matchers._impl.MismatchError: Expected 'aarch64' to be in ' x86-64'
<doko> ----------------------------------------------------------------------
<doko> Ran 26 tests in 2831.729s
<doko> FAILED (failures=1, errors=1)
<doko> autopkgtest [11:08:32]: test integrationtests-plugins: -----------------------]
<doko> autopkgtest [11:08:33]: test integrationtests-plugins:  - - - - - - - - - - results - - - - - - - - - -
<doko> integrationtests-plugins FAIL non-zero exit status 1
<doko> zyga: ^^^ and armhf fails due to some cross compilation stuff
<pitfd> test
<pitfd> hi everybody, can somebody be of any help with the following question?
<pitfd> when I install Firefox via snap infrastructure, will it touch home directory of my currently installed FF ESR?
<pitfd> still running FF ESR 52 because of much needed adddon
<doko> mvo: so snapcraft autopkg tests still fail trying to build some obscure rust code downloaded from the net, and due to some cross compile failure
<mvo> doko: good morning! this is probably best discussed with sergiusens - but let me have a quick look, maybe something trivial could be done to unblock things
<mvo> hey Chipaca ! good morning
<Chipaca> mvo: hey! how're you doing?
<mvo> Chipaca: good, thank you! had a nice and refreshing weekend
<mvo> Chipaca: didn't play hockey for family reasons, that made me slightly sad
<mvo> Chipaca: but otoh family  made me happy so a overall a net plus :)
<mvo> Chipaca: and you?
<Chipaca> mvo: :-)
<Chipaca> mvo: I didn't play hockey either!
<Chipaca> :-D
<mvo> lol
<doko> mvo: well, at least he's highlighted
<Chipaca> mvo: but a good weekend, yes. Planning a break early december though.
<mvo> doko: I think he got highlighted last week already :/
<mvo> Chipaca: uh, I need to plan my break as well
<pedronis> last week was the summit though
<mvo> pedronis: aha, good point
<pedronis> Chipaca: when?
<Chipaca> pedronis: i've got 15 days to use-or-lose. Do you remember if it was 3, or 5 that could be carried over?
<Chipaca> pedronis: in any case: the week from 3-7 december, for sure
<mvo> doko: quite a few errors, I think I leave this best to sergio, I could disable some of the tests that look like upstream changes but other bits look like they have different causes :/
<mvo> Chipaca: 5
<Chipaca> mvo: ta
<mvo> Chipaca: sounds like you will enjoy a long vac in dec then :)
<mvo> Chipaca: good for you (not so good for us ;)
<Chipaca> mbuahaha
 * Chipaca takes all december off
<Chipaca> (no)
<mvo> fwiw 6127 needs a review, apparently this helps bringing a machine  back to life that got into a bad state by disabling a snap on arm that uses gpio
<pedronis> mvo: it has so tests atm tough,  zyga said he was working on some
<mvo> pedronis: :( ok, I can look at this, zyga is off today
<pedronis> mvo: we also need to decide how to distribute the fix
<Chipaca> pedronis: mvo: what's the bug?
<mvo> pedronis: my understand is that putting it into the edge core is ok for now. then the user can snap refresh --edge core, snap enable affected snap and snap refresh --stable core
<pedronis> Chipaca: gpio interface require some order dependency across the systemd and the apparmor backend for slot and plug
<pedronis> seems we fix some part of that, but enable/disable of affected snaps atm is broken
<Chipaca> ah
<pedronis> mvo: ok, that assumes they are happy to try edge for this
<pedronis> anyway we need on edge to start either way
<Chipaca> reminds me, from the summit: we need a way to install a snap with its services disabled
<mvo> pedronis: it does, we could use a hotfix branch, not sure if all the bits are in place for this though
<pedronis> ?
<mvo> pedronis: sorry if I was unclear, a store branch in a channel
<pedronis> yes
<pedronis> those are supported
<pedronis> you mean building it on our side?
<mvo> I think we have not used one for us yet
<mvo> pedronis: yeah, we could take a stable core and do a one-off build for them, its a bit of work though (mostly because we need this for arm)
<mvo> so not sure its really worth it
<pedronis> as I said we need to ask
<mvo> ok
<mvo> Chipaca: I updated 6039 with your suggested error message (I think its a good choice)
<Chipaca> mvo: over the weekend I was reminded of #1669000
<mup> Bug #1669000: classic snap can't use confinement override <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1669000>
<mvo> Chipaca: is jacknorriswebserver a classic snap?
<mvo> Chipaca: we need to adjust our error message here, correct?
<mvo> Chipaca: or is there more to it?
<Chipaca> mvo: ignore the last comment, i think they're off piste
<mvo> Chipaca: ok
<Chipaca> mvo: it's very close to 6039, but from the other side
<Chipaca> mvo: yes we probably should check and return a better error, like with --classic, but i'm not sure how current the problem is
<Chipaca> i haven't tried
<Chipaca> i just saw it, thought "oh that's similar to 6039" and went on with my weekend
<mvo> Chipaca: heh, ok
<pedronis> Chipaca: heh
<pedronis> anyway doesn't sound super urgent
<Chipaca> correct
<Chipaca> talking about urgent, i'm off to epochs land
<pedronis> Chipaca: let me know how that goes,  we should chat about how to do the further requests bit
<pedronis> soon
<Chipaca> pedronis: yep
<zyga> hey
<zyga> I'm off, just wanted to say a few words
<zyga> I ran into some interesting bugs while reinstalling my devices
<zyga> https://bugs.launchpad.net/snapd/+bug/1802773
<mup> Bug #1802773: Cannot refresh from ubuntu-core 2.15.2 on raspberry pi "ubuntu core 16" image - snap-declaration for "snapweb": parsing assertion headers: expected 4 chars nesting prefix after multiline introduction "plugs:": "  network:" <snapd:Confirmed> <https://launchpad.net/bugs/1802773>
<zyga> our stable images cannot update
<zyga> with that I'm off to fix the printer
<zyga> ttyl
<pedronis> zyga: that's a store problem I think
<zyga> yes
<Chipaca> pedronis: the action context does need to carry epochs always, right?
<pedronis> Chipaca: correct
<pedronis> afaiu
<Chipaca> pedronis: a lot of the test changes are going to remain Â¯\_(ã)_/Â¯
<pedronis> oh well
<pedronis> we still want the change
<pedronis> saner api use
 * Chipaca ~> afk
 * Chipaca ~> really afk
<ackk> Chipaca, hi, FWIW I filed https://bugs.launchpad.net/snapd/+bug/1802721 about that issue I'm having with bash completion
<mup> Bug #1802721: bash-completion not working on core18-base classic snap <snapd:New> <https://launchpad.net/bugs/1802721>
<pedronis> Chipaca: were snapshots done in 2.36 or will in 2.37 ?
<cachio> mvo, hey
<mvo> hey cachio
<cachio> mvo, about beta validation
<cachio> there were some issues on dragonboard
<mvo> cachio: oh, tell me more please
<cachio> mvo, first I saw this error
<cachio> on 2 executions
<cachio> same error
<mvo> cachio: do you have a link to the error text?
<cachio> https://paste.ubuntu.com/p/jZbsWd7x36/
<cachio> next execution 13 tests failed
<cachio> mvo, I am gonna debug nor
<cachio> now
<cachio> mvo, I go slow with the db because mine is broken so I am using a remote one
<cachio> mvo, now I'll try to use mine with external display and usb keyboard
<mvo> cachio: hm, Cannot access MTD device /boot/uboot/uboot.env: No such file or directory look scary
<cachio> mvo, the rest of the devies are ok
<cachio> mvo, yes
<mvo> cachio: please check if /boot is mounted once you have a debug session
<mvo> I check back after lunch
<cachio> mvo, I could reproduce that in 2 different devices
<cachio> mvo, sure
<cachio> I'll continur with this
<jamespage> sergiusens: o/
<jamespage> sergiusens: does snapcraft support use of the before/after stanzas for daemon application startup ordering within a snap yet?
<jamespage> or have I got the wrong end if the stick on that feature being implemented
<pedronis> cachio: mvo: what were the errors during the weekend about snapd-vendor-daily?
<cachio> pedronis, checking
<cachio> pedronis, I dont see any error on snapd-vendor-sync
<cachio> at least the spread cron branches worked
<cachio> and all of them are in green
<pedronis> cachio: I'm talking about the recipes on LP
<pedronis> [recipe build #1985875] of ~snappy-dev snapd-vendor-daily-cosmic in cosmic: Failed to build
<pedronis> etc
<cachio> pedronis, ahh, ok, the recipe failed to build
<cachio> I'll check that
<cachio> I am gonna add a new spread cron branch to check the result of that recipe
<cachio> currently we are just triggering but not checking the resutls
<cachio> pedronis, seems to be a infrastructure issue
<cachio> failed doing "git fetch"
<cachio> on xenial and cosmic as well
<Chipaca> ackk: yes that issue is true. For now, install core to get tab completion even if your snap is core18
<Chipaca> ackk: #6126 addresses it
<mup> PR #6126: dirs, wrappers, overlord/snapstate: make completion + bases work <Created by chipaca> <https://github.com/snapcore/snapd/pull/6126>
<ackk> Chipaca, as noted in that LP bug, even with core it doesn't work
<Chipaca> ackk: with core, it works
<ackk> Chipaca, not in my case, see the bug
<Chipaca> sigh
<Chipaca> ackk: the bug just says "it doesn't work"
<Chipaca> ackk: https://forum.snapcraft.io/t/debugging-tab-completion/4198
<ackk> Chipaca, well, no also says I followed the forum thread, and everything except step 4 works
<ackk> Chipaca, including the last step, if I load completion in the snap manually
<Chipaca> ackk: ah sorry
<Chipaca> ackk: I'd misread and misremembered it and just scanned it and jumped to conclusions and now I feel terrible and I'm sorry
<Chipaca> give me a sec to recover and i'll walk through it with you in a moment
<ackk> Chipaca, heh, np
<Chipaca> ackk: for step 4, where's the -x output?
<ackk> Chipaca, you want the full output or just the output of  compelte -P?
<ackk> Chipaca, https://paste.ubuntu.com/p/wdfXH7yHcf/
<mup> PR snapd#6128 opened: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
<Chipaca> ackk: right
<Chipaca> ackk: so there's something missing
<Chipaca> ackk: in that pastebin, see how the returned string points to a "cannot"
<ackk> Chipaca, yeah but that's in the script
<ackk> I mean that's not the output of complete, it's the script tha compares with "cannot"
<Chipaca> ackk: so there _probably_ is a "cannot find completion specification for yadda.yadda"
<Chipaca> hmm
 * Chipaca looks
<Chipaca> ackk: you're right
<ackk> Chipaca, the problem I think is that complete -P only returns "default" and empty lines (as mentioned in the bug )
<ackk> Chipaca, but if I run it in the --shell it works
<ackk> (hence I was suspecting that --command=complete does something different
<Chipaca> ackk: so
<Chipaca> ackk: if you run snap run --command=complete sshoot 9 9 7 1 ' ' 'sshoot ' sshoot ''
<Chipaca> ackk: what do you get?
<Chipaca> ackk: because I get a clear indication of where the problem is
<Chipaca> ackk: so I was wondering what you saw :-)
<ackk> Chipaca, https://paste.ubuntu.com/p/tntr3dNtSW/
<ackk> Chipaca, with multiple blank lines
<Chipaca> gah pastebin is very slow here
<Chipaca> not sure why
<Chipaca> ackk: https://dpaste.de/jr9h
<ackk> Chipaca, are you running on bionic?
<Chipaca> ackk: no
<ackk> Chipaca, that's another bug I filed, that mvo is fixing, classic bionic snaps don't work on xenial
<Chipaca> ah this is the bad symlink thing?
<ackk> yeah
<Chipaca> mvo: is that fixed on core18 edge?
 * Chipaca checks
<Chipaca> i'm on edge
<Chipaca> so probably no :-)
<pedronis> Chipaca: standup? :)
<Chipaca> gah, standup o'clock
<Chipaca> pedronis: omw
<Chipaca> ackk: so the next step would be to do the 'snap run --shell', and run etelpmoc.sh
<Chipaca> ackk: which takes a lot of arguments, but it's got a comment explaining them
<Chipaca> ackk: that's what 'snap run --command=complete' thing does, once it's 'inside'
<ackk> Chipaca, /snap/core/current/usr/lib/snapd/etelpmoc.sh is not executable, is that right?
<ackk> does snap run run it with "bash" ?
<Chipaca> ackk: yes
<ackk> Chipaca, https://paste.ubuntu.com/p/PYy443Xw9S/
<ackk> Chipaca, note that if I actually source the sshoot-completion script inside a --shell, it works
<ackk> Chipaca, why is it not found?
<Chipaca> ackk: because I don't think the arguments are right
<ackk> uhm
<Chipaca> ackk: dunno
<Chipaca> ackk: i'm technically in a meeting
<ackk> I passed the same as the --command=complete, plus the completion script name at the beginning
<Chipaca> ackk: half a neuron on this
<ackk> Chipaca, ok sorry
<Chipaca> :-)
<Chipaca>     _die "USAGE: $0 <script> <COMP_TYPE> <COMP_KEY> <COMP_POINT> <COMP_CWORD> <COMP_WORDBREAKS> <COMP_LINE> cmd [args...]"
<Chipaca> ackk: OTOH if the arguments are wrong, that'd be consistent with what it's seeing
<Chipaca> dunno
<ackk> Chipaca, is there a way to grab the actuall command that snapd runs?
<Chipaca> ackk: let me look at the plumbing
<ackk> Chipaca, found it from strace: /bin/bash /usr/lib/snapd/etelpmoc.sh /snap/sshoot/78/sshoot-completion 9 9 7 1 "sshoot " sshoot ""
<ackk> Chipaca, this returns empty lines when run in the snap
<Chipaca> ackk: was about to say, you just need the abs path on the completion script
<Chipaca> ackk: time to bash -x it :-)
<ackk> Chipaca, https://paste.ubuntu.com/p/xBZ6j7Gqvm/
<Chipaca> ackk: could you copy etelpmoc.sh somewhere, and set -x after it sources bash-completion?
<Chipaca> ackk: because at least I can't make sense of the whole thing :-)
<ackk> Chipaca, https://paste.ubuntu.com/p/qGfvRhqVHR/
<Chipaca> ackk: there's a problem with the complete -p call
<Chipaca> ackk: +++ complete -p ''
<Chipaca> ackk: that '' should be 'sshoot'
<ackk> Chipaca, yeah but it's called with "$1" after a whole lot of shift's
<Chipaca> ackk: ah!
<Chipaca> ackk: you're missing a " " between the 1 and the "sshoot "
<Chipaca> COMP_WORDBREAKS
<ackk> Chipaca, https://paste.ubuntu.com/p/gHbdhWyxqW/
<ackk> Chipaca, hold on, sorry, wrong arg
<ackk> Chipaca, https://paste.ubuntu.com/p/yX6bdF29Kx/ should be the one
<ackk> __python_argcomplete_run '' looks suspicious
<mvo> ackk: the core18 thing should be fixed with core in edge (the bug you mentioned friday)
<Chipaca> ackk: yes
<ackk> Chipaca, because _python_argcomplete is called with no argument
<ackk> it should get "sshoot" afaiu
<Chipaca> ackk: try it -- you have all the args it gets
<ackk> Chipaca, what should I try?
<ackk> mvo, ah thanks
<Chipaca> ackk: IFS=$'\v' COMP_LINE='sshoot ' COMP_POINT=7 COMP_TYPE=9 _ARGCOMPLETE_COMP_WORDBREAKS=' ' _ARGCOMPLETE=1 _ARGCOMPLETE_SUPPRESS_SPACE=1 __python_argcomplete_run ''
<ackk> Chipaca, I need to source the completion file first right?
<Chipaca> ackk: yes
<ackk> Chipaca, ok, so that returns empty, if I pass 'sshoot' as argument, it returns the options
<ackk> Chipaca, the first argument is the command
<Chipaca> ackk: so why is that getting lost?
<popey> degville: I'm trying to find a link at https://docs.snapcraft.io/snap-documentation/3781 which helps me help a developerrequest classic.
<popey> degville: I have clicked everywhere I think, and can't find a doc, should that not be exposed?
<ackk> Chipaca, IDK, that's snap's autocompletion I think
<Chipaca> ackk: could you pastebin the script that's generated?
<popey> degville: never mind, I'll file a bug :)
<ackk> Chipaca, well actually it's basically what you see in the previous pastebin, those two __python_* functions
<Chipaca> ah obvs
<degville> popey: yes, it should be. The publishing side is next on my todo list (I promise)...
<popey> :)
<ackk> Chipaca, https://paste.ubuntu.com/p/rFVJpP84yn/
<Chipaca> ackk: what happens if you add "$@" to $_compfunc ?
<ackk> Chipaca, sorry, where?
<Chipaca> ackk: etelpmoc.sh, after the $bounce check
<Chipaca> $_bounce
<ackk> Chipaca, that works
<Chipaca> ackk: dammit
<Chipaca> ackk: so I need to fix this, but you can fix it at your end as well
<Chipaca> ackk: so if instead of calling the python generator you generate the script, and edit it to not need $1 but hardcode sshoot, it will work
<Chipaca> ackk: also you'll avoid a python code in completion which will make it suck less :-)
<ackk> Chipaca, sure, but that's bound to happen to any python script :)
<Chipaca> ackk: oh, i'm fixing it, but it'll be a month at least before you get it in stable
<Chipaca> ackk: OTOH I'd tell anybody using python there to stop :-)
<ackk> why, argcomplete is so nice
<Chipaca> ackk: agcomplete yes
<ackk> you get autocompletion for free
<Chipaca> ackk: i'm not saying don't use argomplete
<Chipaca> ackk: i'm saying don't call python to generate a shell script that calls python
<ackk> ah yeah I see, I can call it on snap build I guess
<Chipaca> ackk: that will easily put you below the 200ms threshold of "fast"
<ackk> Chipaca, why does this only seem to affect this case?
<Chipaca> ackk: because most completion scripts don't look at $1 i guess :-)
<Chipaca> _complete_potato doesn't check that it's called as potato
<ackk> sure but if $1 isn't there, everthing is shifted  ?
<ackk> ah you mean it's only using vars
<Chipaca> ackk: no because everything the completer looks at is in COMP_ variables
<ackk> ok
<ackk> I see
<Chipaca> exactly
<Chipaca> I didn't even know bash passed $1
<Chipaca> it's not like any of this is specced anywhere
<Chipaca> :-)
<ackk> Chipaca, ok, thanks for the help debugging, I'll workaround it
<Chipaca> i'll push a fix in a bit
<ackk> Chipaca, it makes sense, if you have multiple commands that use the same completion
<Chipaca> first i'll get a cuppa tea and i'll turn on the heating because somebody turned off the sun
<ackk> I see how it's not widely used
<cachio> mvo, this last run is running well on dragonboard
<cachio> mvo, perhaps we need to build our image in another way
<cachio> instead of using beta channel
<mvo> cachio: interessting, what did you change?
<cachio> in general
<cachio> we can use just core from beta
<cachio> an the rest from stable
<cachio> mvo, it is a new image
<cachio> mvo, do you know if there was any change for the kernel snap?
<cachio> mvo, I am havin lunch
<cachio> I'll research a bit about the diff on the images
<cachio> to see what could happen
 * cachio lunch
<mvo> cachio: not sure, let me check if the kernel has changed recently
<pedronis> niemeyer: here's the discussion I mentioned about service order: https://forum.snapcraft.io/t/cross-snap-service-ordering/8319
<mvo> cachio: one week and 5 days ago was the last upload
<mup> PR snapd#6129 opened: data/completion: pass documented arguments to completion functions <Created by chipaca> <https://github.com/snapcore/snapd/pull/6129>
<Chipaca> ackk: ^
<ackk> Chipaca, nice, thanks
<Chipaca> ackk: a big difference that makes argcomplete's eval(<some python>) approach slow with snaps is that the whole environment is discarded every time
<Chipaca> ackk: whereas outside of snap you'd only do the eval the first time you tap tab
<ackk> Chipaca, sigh, I was trying to put the generated completion file in snap/local, but snapcraft looks for it before actually filling snap/
<ackk> Chipaca, ah yeah I had noticed completion was slow
<Chipaca> ye
<sergiusens> jamespage: you can use passthrough. I would explain more but I am sitting on a plane waiting on news on my diverted flight due to failed landing
<ackk> is there a way to access the snap/ dir (IOW $PWD/snap from where "snapcraft" is run) inside a part?
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
<ackk> Chipaca, got it working with the generated shell completion
<Chipaca> ackk: woo
<Chipaca> ackk: any faster?
<ackk> Chipaca, can't really tell 'cause I haven't been using the old one, but it seems fast enough
<Chipaca> ackk: fair enough
<Chipaca> ackk: next you may want to look into whether passing some of the don't-load-site-libaries options still works and speeds up your python, or not
<Chipaca> ackk: in the http snap I found it sped things up by quite a bit
<Chipaca> (but i had to fiddle with sys.path in the script)
<ackk> mvo, in which core18 version is the ldd link fixed?
<ackk> I still see it broken in edge
<ackk> (449)
<mvo> ackk: yeah, its not merged yet, I was hoping for a review from foundations. if there is none by tomorrow I will merge, could you please remind me in our morning again?
<ackk> mvo, ah I see, I thought it was pushed to edge already
<ackk> mvo, sure, thanks
<mvo> ackk: this fix is not, just the other one in core when there "core18" only and no core (the fix for the configure script)
<ackk> mvo, oh, that one, I see
<cachio> mvo, I am making some tests to see how it works changing the way we create the image
<mvo> ok
<cachio> mvo, because the test process is the same, what could change is the image we use
<cachio> mvo, or testflinger is having some troubles to build the image
<cachio> but no error shown in the logs
<mvo> cachio: hm, thanks. is it worth checking with plars  if there might be any testfilinger issues?
<plars> cachio: we don't typically build images, we install them from url
<plars> cachio: I'm happy to try it out if you email me some info though... I'm sprinting right now though, so email preferred since it's 12:30am
<cachio> plars, sure
<cachio> plars, I'll write an email
<mup> PR snapd#6130 opened: snap: make Epoch's MarshalJSON not simplify <Created by chipaca> <https://github.com/snapcore/snapd/pull/6130>
<pedronis> mvo: mmh, we are getting timeouts in travis, for example your #6039
<mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<mvo> :/
<cachio> pedronis, mvo checking
<pedronis> cachio: thx
<cachio> pedronis, mvo it is the opensuse issue I mentioned on friday
<cachio> I was trying to update it today but still getting some errors
<cachio> pedronis, in case I can't create a new image today I'll move to manual until it works again properly
<pedronis> thanks
<cachio> np
<mup> PR snapd#6131 opened: store:  remove unused currentSnap and currentSnapJSON <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6131>
<mup> PR snapd#6132 opened: many: some small doc comment fixes in recent hotplug code <Created by pedronis> <https://github.com/snapcore/snapd/pull/6132>
<mvo> zyga: for tomorrow - I pushed a spread test for 6128 (the gpio bug). it hopefully simulates things good enough, fails on master (so triggers the bug), I'm waiting for the successful run and will check after hockey
<cachio> mvo, last run on dragonboard passed
<cachio> it is running on my device
<cachio> the diff as I said the the source image
<mup> Bug #1803002 opened: Multiple SELinux alerts on install / uninstall on Fedora 29 <Snappy:New> <https://launchpad.net/bugs/1803002>
#snappy 2018-11-13
<mup> PR snapd#6133 opened: tests: fix how pinentry is prepared for new gpg v 2.1 and 2.2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6133>
<mup> PR snapd#6134 opened: tests: skip opensuse from interfaces-openvswitch-support test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6134>
<mborzecki> morning
<zyga> good morning
<mborzecki> zyga: hey, i usually stay away from the computer over the weekends, but i tried 2.36.1 snapd in opensuse TW, seems to be working fine, nvidia, basic AA
<zyga> that's great, thank you for trying!
<kjackal> hello snappy people, did we do a core release?
<mvo> kjackal: we have not made a stable release yet, 2.36.1 is still under QA
<zyga> hey mvo
<mvo> zyga: good morning!
<zyga> hey, just getting into the office
<mborzecki> mvo: hey, had to restart travis job in 6039 as it timeouted
<mvo> mborzecki: :( ok
<mvo> mborzecki: thank you
<mborzecki> mvo: heh, and another restart, was it the same yday?
<zyga> mvo: what should I attack first? the bug that a customer found or anything else?
<mvo> zyga: please check my PR on top of yours, it has a spread test. I'm cleaning the mock gpio a bit more as we speak but the basic idea is the same. but you can also wait for ~10min, then I shall push this small cleanup. either way is fine
<zyga> super, I'll check it out
<mvo> zyga: we should probably also switch the other gpio spread tests to the new method (6128). I pushed the updated code I may need to tweak a bit more, spread test is still running but this should allow you to see what is going on
<pstolowski|afk> morning
<zyga> mvo: thanks, I'm reading reviews and should get to yours in a moment
<zyga> hey pawel
<zyga> mvo: https://github.com/snapcore/snapd/pull/6128/commits/dd08e0ed21fe2dd9030887d386f0971391dd0459 hmm
<mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
<zyga> mvo: the reason I did it that way was to not change the behaviour of other code
<zyga> that's not something we catch in tests today
<zyga> but this changes the order of setup in all the interfaces
<zyga> whereas the initial branch was just changing it for gpio (in practice, because that is the only consumer)
<zyga> I'd like to postpone that tweak to 2.37
<mvo> zyga: my PR is aimed for edge
<pstolowski> zyga: hey, we need to talk about the mapper and implicit slots, can we have a chat in 10-15 mins?
<mvo> zyga: we need to find out if the user who is affected is fine with refreshing to edge or if we wants something else
<mvo> zyga: but unless we know that I think its ok to build something for edge
<zyga> mvo: I think edge might be okay for them but regardless I think we should do a deeper inspection of the impact of the change in ordering
<zyga> note that I fused the setup of the principal snap and the affected snaps
<zyga> so now we do things in quite a different order in practice
<mup> PR snapd#6135 opened: packaging/arch: fix bash completions path <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6135>
<mvo> zyga: fair enough, I feel slightly uneasy about this too. is gpio the only thing that uses systemd?
<zyga> yes
<mborzecki> trivial PR ^^
<zyga> don't get me wrong, I think what you did is _desired_
<zyga> it's just that I wanted to do that separately, once the fire is put out
<zyga> because it has bigger impact
<mvo> zyga: yeah
<zyga> and it may not be as fully tested
<mvo> zyga: ok
<zyga> since our unit tests use one test backend
<zyga> they don't exercise those interactions
<mvo> ok
<zyga> so we only have spread tests to, hopefully, catch any issues
<mvo> pstolowski: 6132 should be an easy merge
<pstolowski> looking
<mvo> zyga: ok, lets cherry pick the spread test to your PR and we can discuss the approach in the standup
<zyga> ok
<mup> PR snapd#6132 closed: many: some small doc comment fixes in recent hotplug code <Created by pedronis> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6132>
<zyga> mvo: one thing I don't get about the spread test, where is the GPIO pin definition?
<zyga> the slot that is
<mvo> zyga: in prepare.sh
<mup> PR snapd#6136 opened: tests: run interfaces-openvswitch-support on arch again, the arch bug is fixed <Created by mvo5> <https://github.com/snapcore/snapd/pull/6136>
<mvo> zyga: it is part of the core snap
<zyga> ah, I din't notice thatt
<mvo> zyga: we unpack and modify the core snap during setup to add one
<mvo> zyga: its quite hidden :(
<mvo> zyga: also it is not done for core18 so there is work there as well, I want to look at this too
<mvo> zyga: plus we have some existing gpio tests which can also be simplified
<mvo> zyga: thanks for the review, I address your points now :) I pushed a small tweak already
<zyga> mvo: thank *you* for writing this :)
<zyga> I didn't think about mocking the whole thing this way
<mborzecki> mvo: one more fix needed in 6039, will push it in a bit
<mvo> mborzecki: what is the fix ? spread test that checks the error message? thanks for handling this!
<mborzecki> mvo: yup, the spread test
<mup> PR snapd#6131 closed: store:  remove unused currentSnap and currentSnapJSON <Simple ð> <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6131>
<pedronis> pstolowski: hi, I finished reading the already landed hot plug code, thanks for looking at my small doc tweaks. Of that the only bit I wasnt sure about is hotplug/spec.go,  it makes it look like a backend but it's not, also not sure why it's organized exactly like it is, but anyway nothing deep, can be reconsidered when I get further. I will start reviewing new code today, when I'm not in meetings :)
<pstolowski> pedronis: thanks. sure, we can discuss if hotplug spec should be re-organized. it's an API for interfaces, not sure if this is clear from what already landed, but the camera interface is an example of how this is used - https://github.com/snapcore/snapd/pull/6098 ; i've done it like that to follow the general pattern of *.Specifificaton objects that we pass to interfaces, this was from suggestions from early reviews
<mup> PR #6098: interfaces/builtin: support hotplug for camera interface <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6098>
<pedronis> pstolowski: yes, I understand but is used very differently, I'm not sure if the similiraty helps or is confusing
<pedronis> anyway there is no action atm
<pedronis> just pointing out that I wondered a bit about this bit
<pstolowski> sure, i see
<mvo> zyga: updated 6128
<zyga> mmm
<zyga> neat, thank you!
<pstolowski> zyga: do you have some time to talk about mapper/implicit slots?
<pstolowski> #6124 is trivial, needs 2nd review
<mup> PR #6124: tests: simple reproducer for snap try and hooks bug <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6124>
<zyga> pstolowski: I think so
<pstolowski> zyga: standup HO?
<mvo> pstolowski: occupied ;)
<pstolowski> :)
<zyga> pstolowski: can we have a call on tg?
<zyga> pstolowski: just need to print one last invoice
<zyga> sorry, monthly accounting time
<pstolowski> zyga: sure. nb, i recommend switching to queterly ;)
<zyga> queterly?
<zyga> ah
<zyga> I get it
<pstolowski> telegram is fine
<zyga> one sec, printer didn't respond
<mup> PR snapd#6130 closed: snap: make Epoch's MarshalJSON not simplify <Simple ð> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6130>
<zyga> pstolowski: ok, you have my full attention now
<zyga> pstolowski: is the HO still used?
<zyga> seems to be
<pstolowski> zyga: yep
<zyga> pstolowski: how about https://meet.google.com/fsz-xtpa-xqb?ijlm=1542101675152&adhoc=1&hs=125&authuser=0
<mup> PR snapd#6039 closed: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<mborzecki> yay!
<popey> double yay
<mvo> mborzecki: yay indeed - thank you!
<mborzecki> mvo: thank you for picking it up in the first place :)
<mvo> mborzecki: silly question about 6136 - the bug that prevented the openvswitch-support test to run is now fixed. but the test still fails. do we just need to blacklist it or is it something simple (like a missing package dependency)?
<mborzecki> mvo: i think we may need to start uuidd.socket before the test (at least on arch)
<mvo> mborzecki: aha, right - this does not happen on package install automatically
<mup> PR snapd#6137 opened: snap: make Epoch default to {[0],[0]} on load from yaml <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6137>
<zyga> I will need to work from the road one more time today
<zyga> need to sign the paperwork and say goodbye to my car today
<zyga> I will focus on reviews while on the road
<mup> PR core18#88 closed: hooks: make ld-so symlink in /lib64 relative <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/88>
<zyga> random test failure from reviews:
<zyga> https://www.irccloud.com/pastebin/6mMG7HK9/
<mup> PR core18#83 closed: add swapfile support (ported from ubuntu-core-config) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/83>
<zyga> pedronis: question about an error I saw over weekend:
<zyga> zyga@pi2-2:~$ sudo snap refresh
<zyga> error: too early for operation, device not yet seeded or device model not acknowledged
<zyga> pedronis: I updated the timezone, time shifted one hour forward
<pedronis> that check is not time dependent afaik
<zyga> pedronis: that device then went into "busted mode"
<zyga> not sure what happened
<pedronis> ah
<zyga> I have it disconnected to inspect
<zyga> perhaps some tasks didn't run
<pedronis> it's really busted if it thinks is not seeded anymore
<pedronis> or it lost its model
<zyga> it went from "stable released on cdimage" to stable
<zyga> just flash and refresh
<zyga> I'll collect more data and report it
<mvo> doko: hey, could you please click on "Request builds" in https://code.launchpad.net/~ubuntu-core-service/+snap/core18  and do an amd64 build for me? I don't have permissions to do this myself anymore :/ (or someone else from foundations maybe?)
<Chipaca> zyga: if you're in review-mode, 6137 is nice an' easy :-)
<Chipaca> it was a tiny part of #6052 but stands on its own
<mup> PR #6052: snap, store, overlod/snapstate: always send epochs <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6052>
<Chipaca> and will make the actually-send-epochs pr that much easier to review
<mborzecki> hmm fake store does not send snap type :/
<mup> PR snapd#6124 closed: tests: simple reproducer for snap try and hooks bug <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6124>
<mvo> mborzecki: uh, I thought we fixed that :(
<zyga> Iâm in review mode but signing papers now
<Chipaca> mvo: isn't there more than one fake store?
<mup> PR snapd#6138 opened: overlord/ifacestate: use remapper when checking if system snap is installed <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6138>
<pstolowski> zyga: does this make sense? ^
<Chipaca> this epoch vs *epoch things gets annoying
<mup> PR snapd#6134 closed: tests: skip opensuse from interfaces-openvswitch-support test <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6134>
<mup> PR snapd#6129 closed: data/completion: pass documented arguments to completion functions <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6129>
<zyga> pstolowski|afk: done
<zyga> Chipaca: 6137 ready
<mup> PR snapd#6137 closed: snap: make Epoch default to {[0],[0]} on load from yaml <Simple ð> <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6137>
<mup> PR snapd#6139 opened: snap, store, overlord/snapshotstate: drop epoch pointers <Created by chipaca> <https://github.com/snapcore/snapd/pull/6139>
<Chipaca> zyga: you'll like 6139 but it's not simple
<Chipaca> bah. It's simple. It's also long.
<Chipaca> relatively
<ogra> cjwatson, i have a prob with stage-packages when cross building, i have tired three variants yet: https://paste.ubuntu.com/p/XpRF9ND5tf/ the first one gets me a build error telling me i need "dpkg --add-architecture armhf", the latter two are completely ignored, am i doing anything wrong or do i need a pecial part that calls dpkg --add-architecture first ?
<ogra> *special
<ogra> note this works fine with a local build
<ogra> (i had the impression with the recent architecture changes on the buildds such things should be possible without extra hacks)
<cjwatson> ogra: I really have no idea, I'm sorry.  I would not have expected this to be at all affected by recent changes
<cjwatson> All we did in LP was arrange to understand the syntax enough to dispatch builds to the right architectures
<zyga> Looking
<cjwatson> This is mostly on the snapcraft side AFAIK
<ogra> ok, but we dont automatically add all possible arches to the sources.lists
<cjwatson> We do not, at present
 * Chipaca ~> lunch
<ogra> i'll try a part that call "dpkg --add-architecture armhf" then, lets see
<ogra> *calls
<cjwatson> Maybe also apt update, not sure
<ogra> yep
<ogra> (was to lazy to type that out :) )
<pstolowski> pedronis: can you take a look at https://github.com/snapcore/snapd/pull/6138 (it's trivial)?
<mup> PR #6138: overlord/ifacestate: use remapper when checking if system snap is installed <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6138>
<pedronis> pstolowski: in a bit, about to go to my dentist appt
<pstolowski> sure
<zyga> Chipaca: reviewed
<Chipaca> who's best to pick up a custom store contact?
<zyga> Dunno
<Chipaca> JamieBennett: ^?
<Chipaca> zyga: thanks
<JamieBennett> Chipaca: feel free to pass them on to me
<Chipaca> JamieBennett: @'ed you on the forum
<Chipaca> JamieBennett: thanks
<ogra> cjwatson, FYI ... seemss to have worked
<Chipaca> now yes, lunch
<ogra> ARGH !
<ogra> Store upload failed:
<ogra>     ('Connection aborted.', gaierror(-3, 'Temporary failure in name resolution'))
<ogra> i hate when that happens !!
<cjwatson> You and me both
<cjwatson> I've asked for the haywire worker to be killed
<mup> PR snapd#6140 opened: tests, fakestore: extend refresh tests with parallel installed snaps <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6140>
<zyga> mborzecki: will you have time to look at https://github.com/snapcore/snapd/pull/6111
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> Nothing urgent
<mborzecki> zyga: i'm going out to pick up the kids in a bit, i can do that later or during the standup
<zyga> Sure
<zyga> Looking at https://github.com/snapcore/snapd/pull/6104 now
<mup> PR #6104: snapctl: add "services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6104>
<Chipaca> zyga: I need to tweak that pr
<Chipaca> also i need to actually go do something about lunch
<Chipaca> drat
 * Chipaca rips himself away
<mup> PR snapd#6136 closed: tests: run interfaces-openvswitch-support on arch again, the arch bug is fixed <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6136>
<cachio> plars, cwayne, hey, could you please confirm if 2.36.1 is ready for candidate?
<cachio> thanks
<zyga> Chipaca: sure, let me know
<mborzecki> Chipaca: standup
<popey> cjwatson: got a developer reporting the name resolution error on build.snapcraft.io
<popey> apolitech is the developer account
<popey> hello APolihron :)
<cjwatson> popey: how long ago?
<mup> PR snapcraft#2403 opened: project_loader: add git to build-packages for version: git <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2403>
<popey> APolihron: ^ When did it happen?
<cjwatson> never mind
<pedronis> Chipaca: did you see my pm with the link?
<APolihron_> hey all! so i've change the yalm file from my github projects to build only for a amd64 , bump up the release number and the grade to stable but i get build, fail to release when using snapcraft.io build serv
<APolihron_> this is one of the project that will not release
<APolihron_> https://github.com/apolitech/Udemy/blob/master/snap/snapcraft.yaml
<APolihron_> and this is the error Error:('Connection aborted.', gaierror(-3, 'Temporary failure in name resolution'))
<cjwatson> APolihron_: This is https://bugs.launchpad.net/launchpad/+bug/1792920 - I've asked for the worker to be killed
<mup> Bug #1792920: celery workers sometimes end up cursed and produce OOPSes for all SnapStoreUploadJobs <oops> <Launchpad itself:Triaged> <https://launchpad.net/bugs/1792920>
<APolihron_> so how can i help or what i need to do?
<cjwatson> APolihron_: wait until I tell you to try again, then try again
<cjwatson> (I'm waiting for a sysadmin to get back to me)
<APolihron_> ok
<APolihron_> thanks
<cjwatson> APolihron_: try again now
<mborzecki> heh, our file.sh helpers are not eally working well with char devices, the checks all use `if [ -f ... ]` which is onviously not true for paths that are not regular files
<mup> PR snapd#6141 opened: interfaces: export gpio pin in AppArmorConnectedPlug <Created by mvo5> <https://github.com/snapcore/snapd/pull/6141>
<pstolowski> mborzecki: oh wow, nice finding!
<mvo> pedronis: sorry to put more burden on your shoulders - I pushed 6141 which contains an alternative fix for the gpio problem. your input on this would be most welcome
<mvo> pedronis: it sidesteps the problem entirely by avoiding the dependency between appamror and systemd on the expense of some extra code in the gpio interface
<pedronis> mvo: so we understand we are both exporting it permanently (across reboots) via systemd units, and explicit in the app armor backend?
<pedronis> s/we/I/
<mvo> pedronis: correct
<mvo> pedronis: this way we avoid the dependency that the systemd backend needs to start the unit before the apparmor backend can stat the symlink
<pedronis> mvo: ok, I left a question there
<APolihron_> cjwatson working, thanks
<mvo> pedronis: thanks, I will look at this and reply inline there is a tocttou race here I think, both places check. otoh we don't run this is parallel yet so it should be fine
<pedronis> mvo: as I said we let go of the lock for backends, so whether is run in parallel or not is a bit unclear
<mvo> pedronis: so the race would be if two tasks both want to export gpio30 ?
<pedronis> or we might have the unit
<pedronis> and systemd is doing strange things
<pedronis> or the user
<pedronis> mvo: it seems at least that if you fail to write, you need to check if by chance the link is there
<pedronis> if it is ignore the error
<pedronis> that's my 2cts
<mvo> pedronis: indeed, that is a good suggestion
<mvo> pedronis: we have the same problem with the unit, there is also a test || write in there which might race
<mvo> pedronis: I look into it, thanks!
<pedronis> np
<cachio> niemeyer, hey, I need to save the images we use for beta/edge validation
 * pedronis break
<mvo> pedronis: on a meta level (not urgent) we need some suggestion which of the approaches we should take to fix the actual bug. zyga and I are not of the same opinion about what approach is the one to pick :)
<mvo> pedronis: enjoy your break, not urgent
<cachio> niemeyer, do you think we can store them in the gcloud filestorage?
<cachio> niemeyer, we are not gonna use more than 5GB
<micah> hi, i need to symlink /snap to /rw/snap on my system, but if I do that, then the core mount job fails because of: snap-core-5742.mount: Mount path /snap/core/5742 is not canonical (contains a symlink) -- is there some way I can override that?
 * cachio lunch
<micah> starting with systemd 238, mount units will fail if the mount point needs to follow a symbolic link
<ppisati> ogra: for the wifi issue you were mentioning some time ago, could you test this kernel snap? -> https://code.launchpad.net/~p-pisati/+snap/raspi2-test/+build/377679/+files/pi2-kernel_4.4.0-1101.109_armhf.snap
<ogra> ppisati, will do
<pedronis> mvo: what are main zyga objections about?  the duplication, the fact that is new unproven code, the fact that is on the plug side?
<zyga> That it feels like layering violation. No other interface code modified the system
<pedronis> zyga: modified in which sense?
<zyga> That it feels like layering violation. No other interface code modified the system
<pedronis> ?
<pedronis> zyga: modify in which sense? they all touch files on the system? and for sure the systemd code is creating a unit that modifies the system?
<zyga> Writing to sysfs
<zyga> Exporting GPIO from the kernel to userspace in a method that computes apparmor snippet
<pedronis> ok, that's clearer
<zyga> Systems unit is just defined
<zyga> Not on disk
<zyga> All changes are done by backend
<mup> PR snapd#6139 closed: snap, store, overlord/snapshotstate: drop epoch pointers <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6139>
<zyga> Systemd specification holds units in memory
<pedronis> zyga: I understood
<mup> PR snapd#6142 opened: overlord/snapstate, store: always send epochs <Created by chipaca> <https://github.com/snapcore/snapd/pull/6142>
<pedronis> zyga: mvo: at the moment all considered #6128 seems my favorite fix, but it depends whether we think we need this also for 2.36.x
<mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
<zyga> pedronis: that's fine though this implementation has slightly bigger impact than the first one I pushed (with the special casing of systemd backend)
<zyga> pedronis: after a QA pass I don't mind landing that at all
<pedronis> zyga: that's why I said it depends whether we need something to backport
<pedronis> zyga: anyway I think mvo is offline changing location
<pedronis> atm
<zyga> ack
<zyga> I'll get onto other things
<zyga> I'm happy to discuss this when needed
<pedronis> zyga: what are you working on atm?  back to user namespaces?
<zyga> yes
<pedronis> ok, thanks
<zyga> I will do some reviews of pawel's work as well
<pstolowski> zyga: ty!
<Chipaca> error: cannot install snap file: cannot refresh snap "basic" as new epoch (2) can't read old epoch (0)
<Chipaca> looks like it might work
<roadmr> epochs ftwwwww
<Chipaca> that's from a local install
<pedronis> roadmr: yes, Chipaca is progressing on them
<roadmr> yya :)
<zyga> Chipaca: _neat_
<zyga> snaps get serious ð
 * Chipaca mostly EODs
<Chipaca> a little early because the chorizo + split lentil stew smell is distracting me too much
<zyga> o/
 * cachio afk
<mvo> zyga: you had a chat about gpio? can you point me to a pastebin or give me a tl;dr summary?
<zyga> with Samuele?
<mvo> zyga: yes
<mvo> zyga: i.e. should I stop messing around with 6141 ?
<zyga> I only said what my objections are
<pedronis> I wrote this: <pedronis> zyga: mvo: at the moment all considered #6128 seems my favorite fix, but it depends whether we think we need this also for 2.36.x
<pedronis> <mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
<pedronis> <zyga> pedronis: that's fine though this implementation has slightly bigger impact than the first one I pushed (with the special casing of systemd backend)
<pedronis> <zyga> pedronis: after a QA pass I don't mind landing that at all
<mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
<pedronis> <pedronis> zyga: that's why I said it depends whether we need something to backport
<pedronis> <pedronis> zyga: anyway I think mvo is offline changing location
<zyga> we did not discuss more than that
<pedronis> we can chat more in the morning, but we do need to try to converge, and also decide about 2.36.x
<zyga> I agree
<mvo> zyga: ok, thanks
<mvo> pedronis: thank you as well
<mvo> it looks like they all need reviews anyway, so lets sync up in the morning
<mvo> ackk: core18 with the ld-so symlink fix is in edge now, please let me know if you it is not sufficient
<jdstrand> roadmr: hi! whenever its convenient, can you pull 1155 of the review-tools?
<mup> PR #1155: integration-tests: remove the integration daemon tests <Created by elopio> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1155>
<roadmr> jdstrand: sure thing!
<jdstrand> roadmr: thanks
<Caelum> zyga: thank you so much for finally doing the snapd update, to be honest I've been using flatpak spotify in the meantime
<Caelum> zyga: if you ever want help with anything, just ping me
<mup> PR snapcraft#2404 opened: cli: handle yaml errors for cleanbuild <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2404>
<mup> PR snapd#6143 opened: cmd: install snap-discard-ns in "make hack" <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6143>
<mup> PR snapd#6144 opened: cmd: handle tumbleweed and leap in autogen.sh <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6144>
<ijohnson> zyga: sorry I forgot but I just filed https://bugs.launchpad.net/snapd/+bug/1803210 for you to look at
<mup> PR snapd#6145 opened: cmd/snap-confine: capture initialized per-user mount ns <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
<mup> Bug #1803210: snap's device cgroup is not discarded upon uninstall <snapd:New> <https://launchpad.net/bugs/1803210>
<ijohnson> no rush it's a low priority
#snappy 2018-11-14
<mup> Bug #1774509 changed: system-user assertion should allow change-pw to be set <Snappy:Fix Released> <https://launchpad.net/bugs/1774509>
<mborzecki> morning
<mup> PR snapd#6140 closed: tests, fakestore: extend refresh tests with parallel installed snaps <Parallel installs â> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6140>
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mup> PR snapd#5897 closed: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5897>
<mup> PR snapd#6135 closed: packaging/arch: fix bash completions path <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6135>
<mborzecki> mvo: can you take another look at https://github.com/snapcore/snapd/pull/6133 ?
<mup> PR #6133: tests: fix how pinentry is prepared for new gpg v 2.1 and 2.2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6133>
<zyga> Hey
<zyga> I will be up within the hour
<zyga> I pushed the essential snap confine patch for user mounts, I hope to move faster now
<mvo> mborzecki: sure, will do
<mvo> zyga: good morning and thank you
<mborzecki> zyga: hey
<zyga> Hi :-)
<zyga> I want to fix prefix handling in packaging today
<zyga> Iâll bug you about reviews
<mborzecki> spread tests caught some errors downloading snaps
<mborzecki> looks like cdn is slow/unresponsive
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mup> PR core18#90 opened: Placeholder files <Created by mvo5> <https://github.com/snapcore/core18/pull/90>
<zyga> Hey PaweÅ!
<BlackDex> Hello there, can you install an older version of a snap by providing the version or something of a snap? And if so, how
<mvo> BlackDex: if its your own snap (or a snap shared with you) you can "snap install --revision=xyz your-snap". snapcraft list-revisions your-snap will give you the mapping of revision and version
<pstolowski> BlackDex: snap revert --revision=.. as long as it's still on the disk
<zyga> BlackDex: if the snap belongs to someone else we respect their choice to offer only published versions
<zyga> BlackDex: this way developers have a more predicable support target
<zyga> BlackDex: and there are fewer old releases with known bugs used
<pedronis> mvo: hi, thanks for answering Jamie S posts about core18
<mvo> pedronis: sure, yw
<zyga> mvo: I must say I like Trello :)
<zyga> is there a native app for it?
<zyga> pedronis: what is the significance of the various trello labels?
<mborzecki> oh, is trello up already/
<zyga> mhm
<zyga> I got a ping from mvo
<mup> PR snapd#6141 closed: interfaces: export gpio pin in AppArmorConnectedPlug <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6141>
<mvo> zyga: wuut? a ping from me?
<zyga> mvo: yep, Trello said you added me to the board
<zyga> so I noticed :)
<mvo> zyga: that was a bit of an accident but its fine
<mvo> zyga: I guess it happend when I added you to one of the cards
<zyga> haha, I didn't know :)
<mvo> zyga: but its not a secret so its fine, we all will get access soon (samuele is organizing this :)
<zyga> super
<zyga> I added two cards based on stuff that's happening
<zyga> and added minimal info to the one you added me to :)
<mup> PR snapd#6133 closed: tests: fix how pinentry is prepared for new gpg v 2.1 and 2.2 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6133>
<pedronis> zyga: I added a couple of labels to one of your cards,  do we have a forum topic about user namespaces?
<zyga> pedronis: we have multiple separate topics about various aspects of it
<zyga> but not one specific post
<mvo> zyga: ideally we don't keep state in the cards, so the nice explaination you put there would be ideally in the forum and the card just links to it (right pedronis?)
<zyga> do you want me to make a post in the #docs category?
<pedronis> mvo: yes
<pedronis> zyga: not immediately, but when is close to done yes
<zyga> mvo: is putting PR links and small status updates ok or should all of those be elsewhere?
<pedronis> I mean about user namespaces
<zyga> pedronis: ok, will do
<pedronis> zyga: PR links are fine
<mvo> zyga: I think pr links, forum links etc are great
<zyga> pedronis: last night I really got it moving, I was stuck on one aspect and fixed that
<pedronis> attachment, PR links, checklists are fine
<mvo> zyga: but updates I'm hesitant because the trello is not public so we lock out people, ideally its just a tool for us to track flow and all the information we track is public
<pedronis> descriptions, better if there's a forum post for anything that is large, needs to be visible (which is almost all things)
<zyga> ok
<zyga> I think we'll figure out what the right balance is in the next few days
<pedronis> anyway that one is a bug, it should have a link to the bug at least
<mvo> zyga: yeah, I think we will also talk about it during the standup
<zyga> ok
<zyga> which one is a bug?
<pedronis> gpio stuff
<zyga> ah
<zyga> right
<zyga> mvo: thanks for merging master into TW branch
<zyga> we should see if this passes now
<mup> PR snapd#6138 closed: overlord/ifacestate: use remapper when checking if system snap is installed <Hotplug ð> <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6138>
<pedronis> zyga: I added a skeleton checklist to your card
<pedronis> feel free to tweak
<zyga> looking
<zyga> Thanks!
<zyga> nice idea
<mup> PR snapd#6146 opened: ifacestate/helpers: added SystemSnapName mapper helper method <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6146>
<pedronis> pstolowski: I seems we really need a helper for  CurrentInfo(systemSnapName), I see you need it also for hotplug-disconnect
<pstolowski> let me check and refresh my memory
<pedronis> pstolowski: I made a comment in the PR itself
<pedronis> clearer context
<pstolowski> pedronis: oh yes, right, i can see that, thanks
<pstolowski> will do
<zyga> re
<sparkiegeek> mi
<mborzecki> https://paste.ubuntu.com/p/h3xskwxJfg/ how does that look?
<pedronis> mborzecki: ?
<mborzecki> pedronis: check the pastebin
<pedronis> mborzecki: ?
<mborzecki> pedronis: revision publish date/time for each channel
<pedronis> we don't have the data
<pedronis> afaik
<pedronis> am I confused
<sparkiegeek> given two ?s in a row, I'd say you were :)
<mborzecki> pedronis: hm isn't created-at the date when given revision was created?
<pedronis> mborzecki: yes, that's not the info that is asked
<pedronis> the info is asked is when it was released into the channel
<pedronis> we might actual want both
<pedronis> mborzecki: that task need store work first
<pedronis> mborzecki: are you without a next task?
<mborzecki> pedronis: yeah, looking around currently, thinking about going back to centos to look into umount issues we saw, any suggestions are welcome
<pedronis> mborzecki: yes, CentOS is a good next task at this point
<mvo> mborzecki: if you are interessted in the umount I tried to reproduce it (in vain) with plain mount in http://paste.ubuntu.com/p/3yfgGjqXGY/
<pstolowski> added SystemSnapInfo helper to #6146
<pstolowski> pedronis: ^
<mup> PR #6146: ifacestate/helpers: added SystemSnapName mapper helper method <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6146>
<pedronis> pstolowski: do we have already code to deal with when a hotplug device shows up the first time?
<pedronis> I see PR for remove and update
<pedronis> or is that in the big PR marked as blocked atm
<pstolowski> pedronis: yes, it's in the big PR only, i haven't extracted it as it would need to be stacked on top of existing PRs
<pedronis> pstolowski: ok, does it do auto-connections as well? that was mentioned in the initial plan if I recall correctly
<pstolowski> pedronis: yes, although there are two issues, one of which we discussed earlier (there needs to be exactly 1 candidate slot for autoconnect, but with first hotplug interfaces you will always have 2), second which i mentioned yesterday on standup (you probably missed that since you joined late) - if you have no snaps at all and core is installed automatically for you as a prerequisite, hotplug will not kick in at all
<pstolowski> initially as udevmonitor init waits for system snap and will become active after a while
<pedronis> pstolowski: I don't understand the first one, why 2 slots ?
<pstolowski> pedronis: because the first hotplug interfaces simply extend existing interfaces - look a the camera PR for example. you still have the "old" camera interface, and hotplug slots of "camera" interface appearing as well. so when you plug a camera you get generic camera interface and a hotplug slot for this specific camera.
<pstolowski> pedronis: to solve this we should probably/maybe make candidate slots helper smarter and favor hotplug version of an interface?
<pstolowski> pedronis: makes sense?
<mup> PR snapd#6147 opened: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
<cachio> mvo, hey, 2.36.1 in candidate channel
<mvo> cachio: excellent news!
<mvo> cachio: lets aim for release Monday or Tuesday
<mvo> cachio: thank you!
<cachio> mvo, yes, I hope that
<cachio> yaw
<pedronis> pstolowski: is this specific to camera?  something sounds wrong?  is this because there is a generic camera device (that might or might not work)
<mup> PR snapd#6148 opened: cmd/snap-confine: remove unneeded unshare <Created by zyga> <https://github.com/snapcore/snapd/pull/6148>
<pedronis> pstolowski: anyway, something to think about/discuss
<mup> PR snapd#6149 opened: cmd/snap-confine: capture initialized per-user mount ns <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
<pedronis> pstolowski: the issue it that conceptuall camera is an interface to all cameras, so having two slots of it doesn't make sense
<mup> PR snapd#6150 opened: cmd/snap-discard-ns: add support for --from-snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/6150>
<pedronis> we need to think
<pstolowski> pedronis: it's a decision i think, i made camera hotplug for the existing interface instead of creating a new separate interface type (e.g "hotplug-camera")
<zyga> I'm creating a bunch of PRs, I'll garden them, some of those have dependencies but I'll try to get that under control
<pedronis> pstolowski: as, I said that plan sounds conceptually wrong
<pedronis> given the nature of camera at the moment
<pedronis> camera is all cameras, not one camera
<pedronis> there's even a comment about this in it
<pedronis> we need to see how to sort that out
<pedronis> without breaking things
<pedronis> pstolowski: there is this comment:  # Until we have proper device assignment, allow access to all cameras
<zyga> pedronis: one idea is as follows
<zyga> pedronis: keep the interface name as is
<zyga> pedronis: change the implicit slot on core to be called "all-cameras"
<pstolowski> pedronis: no, the hotplug variant of this interface gives access exactly to *one* camera
<pedronis> pstolowski: yes, you did that
<zyga> pedronis: hotplug interfaces will be named "camera-$foo" and will hold an attribute to specific camera
<pedronis> but it doesn't fit completely
<zyga> pedronis: teach auto-connect logic to prefer the all-cameras one unless a snap is marked as wanting the new behaviour via a plug attribute
<zyga> pedronis: the old logic is great for many snaps
<pstolowski> pedronis: but yes, the descriptions of interfaces are misleading and i was explaining this ~two weeks ago on a standup on an example of serial port ("allows access to all serial ports")
<pedronis> zyga: we probably cannot change the core slot name either
<pedronis> somebody is probably connecting to it in some script
<pstolowski> but yes we need to decide what to do to make new interfaces support hotplug without breaking compatiblity
<pstolowski> we might need to keep old interfaces for a while
<zyga> pstolowski: alternatively we do a flag day switch (camera is specific to camera) but teach auto-connect to connect *all* of them
<zyga> pstolowski: so "cheese" will now connect to all cameras automatically
<zyga> but the purpose of the camera interface is simple and specific
<zyga> this feels cleaner IMO
<zyga> but will have more complex "I want to revert snapd" semantics
<pedronis> flag day, complex revert snaps, all those things don't sounds appealing to me
<pedronis> it seems we have a complex problem on our hands, probably not something to discuss in irc right now
<pedronis> we have ideas
<zyga> +1
<pstolowski> +2
<mborzecki> funny situation with snapd in epel, it's there but it's not installable on centos because we're still waiting for 7.6 selinux-policy to be available in centos
<pedronis> pstolowski: it would be good to have a forum post that describes the problem, with a least of potential hardware interfaces that are affected, at least serial-port and i2c says thy all to access "a specific" device, camera and dvs says all
<pedronis> s/least/list/
<pstolowski> pedronis: right, will do
 * zyga goes to fix quirks PR
<zyga> please don't restart any user mount PRs
<mborzecki> zyga: pony icon? :)
<zyga> mborzecki: *mount* point
<mborzecki> hahah
<pstolowski> :D
 * pstolowski school run + lunch
<mup> PR snapd#6151 opened: snapd: allow snap-update-ns to read /proc/version <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6151>
<zyga> mborzecki: offtopic
<zyga> mborzecki: with connections API
<zyga> mborzecki: I'd like to have a debug command like
<zyga> snap debug is-connected
<zyga> snap debug is-autoconnected
<zyga> etc
<zyga> for tests mainly
<zyga> so that we can get away from the grepping snap interfaces
<mborzecki> mhm
<zyga> mborzecki: what do you think?
<mborzecki> zyga: and the output yes/no? or just exit code?
<zyga> exit code
<mup> PR snapd#6152 opened: spdx: update licenses to current data <Created by mvo5> <https://github.com/snapcore/snapd/pull/6152>
<zyga> could be more with --verbose or something like that
<zyga> if snap is-connected core:network; etc
<cachio> mvo, do we have an example to update the snap revision?
<cachio> to avoid it is refreshed?
<pedronis> pstolowski: mborzecki: do you remember what was the last set of decisions we made about re(starting) services from hooks? I think we decided to make it synchronous by default?
<mborzecki> pedronis: no, i don't recall, but iirc we're calling systemctl restart which waits
<pedronis> mborzecki: yes, but we postpone the tasks after the hook
<pedronis> there was some back and forth on that
<pedronis> and user confusion
<mborzecki> heh, i can imagine
<mborzecki> pedronis: so what you're saying, say install hook does restart (?), the task is injected and all other tasks automatically get WaitFor() ?
<pedronis> yes, we do something like that
<pedronis> but I vaguely remember discussions that is was confusing/was breaking some expectations
<pedronis> so should not be the default
<pedronis> seems we didn't write down this, it will need to surface again on its own
<zyga> red test day :/
<BlackDex> mvo, pstolowski and zyga thx for the info! :)
<cachio> zyga, we have new opensuse image
<zyga> cachio: which one?
<cachio> zyga, lets see if it fixes the errors
<cachio> zyga, 43.2
<zyga> 42.3?
<cachio> I updated it after the PRs with the fixes were merged
<zyga> there are no errors on 42.3 (well, non that fail tests that aren't disabled)
<zyga> but let's see yeah
<zyga> thanks!
<zyga> is it published and live?
<zyga> or do we need to opt into it?
<cachio> I retrigerred some of the PRs and builds which have failed
<cachio> you just need to rebuild if it errored
<cachio> zyga, well, if the build took 50 minutes and it was errored because of that
<zyga> ok
<mborzecki> zyga: cachio: saw some issues with snap downloads in the morning
<zyga> aha
<cachio> mborzecki, yes, I saw some 503
<cachio> mborzecki, did you see the same ?
<mborzecki> cachio: there were errors pointing to fastly, sorry didn't grab them at the time
<cachio> mborzecki, I also saw some errors downloading dependencies
<cachio> on xenial
<cachio> perhaps there are some network problems on gce
<cachio> mborzecki, I am following this
<pedronis> mborzecki: is this expected behavior, I suppose it is, but confusing:  https://bugs.launchpad.net/snapd/+bug/1803212 ?
<mup> Bug #1803212: snap restart starts disabled services <snapd:New> <https://launchpad.net/bugs/1803212>
<ijohnson> pedronis: I would say that is unexpected behavior (as the bug author :-) )
<mborzecki> pedronis: hm systemd allows you to do that too, imo it's probably a slight discrepancy between what users think enable/disable means and systemd's opinion
<mborzecki> ijohnson: maybe if you do snap restart <snapname> we should not restart serices that are disabled
<ijohnson> yeah to me, if a service in a snap is disabled, it shouldn't ever be started unless by `snap start SNAP_NAME.svc`
<mborzecki> ijohnson: but if you do snap restart <snapname>.<svcname> we should restart it as requested
<ijohnson> yes
<mborzecki> yup
<mborzecki> pedronis: what do you think?
<pedronis> I don't know
<pedronis> if need to step back a bit
<pedronis> s/if/we/
<pedronis> it feels we didn't finess the design of all of this enough
<pedronis> the first time around
<pedronis> mborzecki: we need to reach a consistent picture
<pedronis> even if we deem some behaviors bugs vs features or things we need to continue doing
<zyga> I bought two uSD cards to replace those that failed during weekend device fixup
<zyga> I'll send my test results in case anyone wants to buy similar cards
<pedronis> mborzecki: basically it's very easy to document that snap <service-command> <snap-name>  touches all services
<pedronis> otoh it might not be what ones wants
<pedronis> it also means enabled for services vs snaps have different nuances
<ijohnson> pedronis: speaking for the snap that I posted in the bug report (edgexfoundry) our snap has 16 services (soon to be 20) and if `snap restart` doesn't respect enable/disable then the feature will be effectively useless for us and to issue a restart of all services would be a giant pain because of the dependencies between the services
<mborzecki> pedronis: yeah, we're exposing systemd behavior this way
<pedronis> ijohnson: what do you expect snap stop <snap> to do?
<pedronis> anyway I'm writing something in the bug, I haven't made my mind up either way
<ijohnson> hmm going point not sure
<pedronis> ijohnson: I asked a couple of questions in the bug, please do write there what you expect if you have some time to think about it
<ijohnson> thanks I'll look at it now
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6097#pullrequestreview-174864176
<mup> PR #6097: interfaces/tests: MockHotplugSlot test helper <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6097>
<mborzecki> pedronis: i think there was also a quirk regarding restart related to refresh more, where we basically discourage from doing `systemctl restart snap...`
<mborzecki> s/more/mode/
<mup> PR snapd#6153 opened: tests: use mock-gpio.py in enable-disable-units-gpio test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6153>
<pstolowski> zyga: thanks, looking
 * zyga pstolowski: in https://github.com/snapcore/snapd/pull/6071/files is the interface argument to updateDevice the actual interface name (not plug or slot name)
<mup> PR #6071: ifacestate/hotplug: updateDevice helper <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6071>
<pstolowski> zyga: yes, it's the interface name
<zyga> thanks!
<mborzecki> cachio: i'm seeing no space left on device on amazon, something you were looking into earlier?
<cachio> mborzecki, yes, do you have any logs?
<cachio> mborzecki, it is really sporadic
<mborzecki> cachio: https://travis-ci.org/snapcore/snapd/jobs/454850118
<cachio> mborzecki, thanks
<ijohnson> pedronis: replied
<cachio> mborzecki, same error I saw last week
<ijohnson> mborzecki: apparently I misread that user on the forum, did your PR changing how services are started on install not also change how services are handled on `snap restart`? Regardless of whether disabled services should be started with `snap restart`, they should be started in topological sort order like on install
<cachio> mborzecki, I also see many errors on xenial 32 trying to install dependencies
<cachio> seems to be a network issue
<cachio> at least the opensuse issue seems to be fixed
<cachio> mborzecki, standup?
<mborzecki> off to school to the parents meeting
<mborzecki> zyga: added some tweaks for centos to call snap-discard-ns in snap-mgmt --purge, so far looking quite good
<zyga> mborzecki: purge may run only when snapd is installed, right?
<mborzecki> zyga: yes, that's how we do it on fedora, opensuse & arch
<zyga> good, sounds great
<zyga> lets do that instead of manual unmount
<mborzecki> zyga: there's still a case when we try to remove a snap that is using layouts or similar (eg. parallel installs)
<mborzecki> something to discuss tomorrow probably
<zyga> ok
<Chipaca> popey: let me know if I missed something from my call-for-testing topic
<popey> hm?
<popey> screenshots :D
<popey> also, i see broken unicode
<Chipaca> popey: where?
<popey> https://usercontent.irccloud-cdn.com/file/srgcfcQf/Screenshot%20from%202018-11-14%2015-13-14.png
<popey> works in a terminal, not in firefox (snap)
 * Chipaca wonders if he has any unicode nickels to give
<Chipaca> popey: does that improve?
<clobrano> hi o/, latest Yaru snap builds on Travis are broken with this error https://travis-ci.org/ubuntu/yaru/builds/454222505, which seems related to version-script. Looking at snapcraft forum, my understanding is that this is somehow deprecated, is there something I need to update on Yaru yaml?
<popey> your output needs to work on https://www.youtube.com/watch?v=9Qct8HWnXmY  :)
<popey> Chipaca: fixed first one, other three still broken
<Chipaca> good
<Chipaca> i'll change the rest then
<popey> good now
<Chipaca> also wtf why doesn't your browser know how to display a ð¸
<popey> thanks
<Chipaca> even your terminal does
<popey> nor does irccloud
<Chipaca> remind me, is that something that runs in a browser?
<popey> electron so kinda
<Chipaca> it's BMP unicode
<Chipaca> it should not not work
<Chipaca> no excuses at this point
<cachio> mborzecki, about this no space error
<Chipaca> anyhow
<Chipaca> popey: thanks
<cachio> mborzecki, the vm has free space
<cachio> mborzecki, it is like this mount point has not any space
<cachio> mborzecki, I'll leave a loop trying to reproduce it
<cachio> main.go:123: system does not fully support snapd: write /tmp/sanity-squashfs-702762208: no space left on device
 * cachio lunch
<zyga> tests absolutely suck today
<zyga> mvo: so about that bug fix
<zyga> mvo: everything is yellow
<zyga> unless you disagree I'd like to spend a moment on other tasks
<mvo> zyga: sure
<zyga> ok
<mvo> zyga: the gpio fix you mean? iirc there is nothing pending from you anyway, no? we just need tests to go green
<zyga> yes
<pedronis> mvo: I reviewed #6128
<mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
<mvo> pedronis: thank you
<zyga> pedronis: what do you mean by https://github.com/snapcore/snapd/pull/6128/files#r233513633
<mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
<pedronis> that we can do affectedNames = append(affectedNames, snapName) before the for loop
<zyga> oh, that's deliberate,
<zyga> we sort the _other_ names
<zyga> and then prepend the "principal snap"
<zyga> so the list of snaps is otherwise ordered except for the first item
<pedronis> ah
<zyga> this was done to ensure that the impact in how things are setup is minimal
<zyga> note that before we did setup on the principal snap
<zyga> and then on the rest
<pedronis> maybe the comment needs moving them
<pedronis> *then
<pedronis> given I was confused
<zyga> sure, will do, just wanted to clarify that
<pedronis> (otoh I might just be tired)
<pedronis> mvo: not urgent but #6070 can merged, right?
<mup> PR #6070: store,daemon: make UserInfo,LoginUser part of the store interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/6070>
<mup> PR snapd#6154 opened: snap: enforce minimal snap name len of 2 <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6154>
<mvo> pedronis: yes, 6070 can be merged if you are happy with it
<pedronis> mvo: I'm neutral on it :)
<pedronis> mvo: anything else urgent needed from me?
<mvo> pedronis: I think we are good for now :)
<pedronis> ok, thx
 * pedronis mostly eods
<mup> PR snapd#6070 closed: store,daemon: make UserInfo,LoginUser part of the store interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6070>
<mup> PR snapd#6097 closed: interfaces/tests: MockHotplugSlot test helper <Hotplug ð> <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6097>
<zyga> mvo: the gpio fix can go to just edge
<zyga> mvo: fire is over
<pedronis> let's post to the bug when we a have edge build
<pedronis> with the fix
<zyga> +1
<mvo> zyga: great, lets land it when its green and we can do the further bits in a followup (if it ever gets green :(
<zyga> yep, I'm working on unit tests as a follow up
<zyga> I just want gree
<zyga> it's autumn on travis, everything is yellow and red ;)
<zyga> will there be a winter pack with silver and blue colors next? :)
<ppisati> sergiusens: when trying to run a single unit test (python3 -m unittest tests.unit.plugins.test_kernel.KernelPluginDefaulTargetsTestCase.test_default), i get this: http://paste.ubuntu.com/p/zyYthtwgkG/
<ppisati> sergiusens: am i doing anything wrong or what?
<ppisati> kalikiana: ^
<sergiusens> ppisati: re-install pyyaml (the one listed in requirement.txt), but before that, install the yaml dev package
<ppisati> sergiusens: so, i remove the pip, install yaml-dev and reinstall the pip? me tries
<sergiusens> ppisati: yes
<mvo> zyga: does lp #1802332 ring any bells?
<mup> Bug #1802332: Apparmor complains in strict confinement with base: core18  <snapd:New> <https://launchpad.net/bugs/1802332>
<zyga> checking
<mvo> zyga: some denials in snap-update-ns
<zyga> boy, can we please do markdown on lauchpad!
<zyga> but back to the issue
<ppisati> sergiusens: \o/ <- it worked!
<sergiusens> glad it did, would of been bad if it hadn't ð
<zyga> mvo: it does
<zyga> at least it seems to
<zyga> though 2.36.x should fix it
<zyga> mvo: do you know if the reporter is on IRC?
<mvo> zyga: I don't but if its fixed thats fine, ask him to refresh to candidate :)
<zyga> mvo: no guartanee but I think this is a bug I fixed in 2.36 cycle
<zyga> *guarantee
 * zyga cannot spell
<roadmr> guartanee was an awesome typo :)
<mup> PR snapd#6144 closed: cmd: handle tumbleweed and leap in autogen.sh <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6144>
<zyga> mvo: https://github.com/snapcore/snapd/pull/6154#pullrequestreview-174974102
<mup> PR #6154: snap: enforce minimal snap name len of 2 <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6154>
<mvo> zyga: meh, thanks, will do
<zyga> if you can please add // NOTE: comments cross linking them
<zyga> I know of one in libsnap-confine-common
<zyga> and I think there's one more in boostrap.go in snap-update-ns (sorry)
<zyga> mvo: and triple check if snapcraft agrees
 * mvo weeps a bit
 * mvo is down to 64 "new" bugs in snapd not too bad
<zyga> mvo: checking that fedora29 snap-exec bug now
<zyga> mvo: you have N64 bugs :)
<mborzecki> zyga: https://paste.ubuntu.com/p/b7df9M5QpK/
<mborzecki> i'm leaving analyzing the log for tomorrow
<zyga> ouh
<zyga> ok
<zyga> I'm homeworking with Iza
<mborzecki> zyga: gl :)
<zyga> mvo: f29 bug triaged
<mup> PR snapcraft#2403 closed: project_loader: add git to build-packages for version: git <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2403>
<mup> PR snapcraft#2406 opened: project_loader: add git to build-packages for version: git (#2403) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2406>
<zyga> jdstrand: hey, could you please look at the apparmor part of https://github.com/snapcore/snapd/pull/6123 - that's just a bunch of removals with non-controversial additions that were previously handled by a more generic wildcard: https://github.com/snapcore/snapd/pull/6123/files#diff-798ce6f0668878eda67847b4ab492745
<mup> PR #6123: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <https://github.com/snapcore/snapd/pull/6123>
<zyga> ondra: which version of avahi is best for production use?
<zyga> they all have git-flavoured versions
<zyga> and candidate seems recent than edge or beta
<jdstrand> zyga: you probably saw I did that a little while ago
<mvo> zyga: fc29?
<mvo> zyga: what did you triage?
<mup> PR snapcraft#2392 closed: ci: update travis.yaml to use xenial <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2392>
<mup> PR snapcraft#2407 opened: build providers: preset the timezone <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2407>
<mup> PR snapcraft#2408 opened: multipass: avoid stdin where possible <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2408>
#snappy 2018-11-15
<mup> PR snapcraft#2406 closed: project_loader: add git to build-packages for version: git (#2403) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2406>
<mup> PR core18#91 opened: Make /etc/default/swapfile be writable <Created by musicguitar> <https://github.com/snapcore/core18/pull/91>
<mborzecki> morning
<zyga> good morning
<zyga> more red in tests
<zyga> oh well
<mborzecki> zyga: hey
<zyga> :-)
<mborzecki> zyga: looking into some opencl stuff from the forum, looks like none of the interfaces allows accessing /etc/OpenCL to read icd files, and then there's libnvidia-opencl which we do not pick up in s-c
<zyga> oh man
<zyga> another file to add
<mborzecki> i'll rebuild my debugging snap with clinfo and see how far i get there
<zyga> looking forward to removing that mess
<zyga> good luck!
<mborzecki> idk maybe we should have a 'compute' interace to cover cuda and opengl
<zyga> opencl?
<mborzecki> opencl right
<mborzecki> too many open suffixes :P
<mborzecki> prefixes
<mborzecki> damn
<zyga> open wtf :)
<mborzecki> should get coffee
<zyga> I'll take the dog out and focus on snap-update-ns and snapd feature flag for per user mouts
<zyga> i have plenty of PRs that depend on each other
<mborzecki> zyga: i'll have some questions about mount and MNT_DETACH that we do
<zyga> need to add some leafs :)
<zyga> yes?
<zyga> shoot, I'll answer
<mborzecki> zyga: we can do HO later
<zyga> ok
<zyga> mborzecki: can we aim for 9:00?
<zyga> for the talk
<mborzecki> sure
<zyga> otherwise I'll be in my pijamas ;)
<icey> where should I take a slightly comical snapcraft.io bug? doesn't hinder functionality but would probably be something we want to get fixed (we call French Guiana France in the map showing snap distribution)
<mborzecki> hmm 'Download snap "core" (5940) from channel "edge" (received an unexpected http response code (503) when trying to download https://fastly.cdn.snapcraft.io/download-origin/fastly/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_5940.snap?token=1542276000_dc14a149f1c3974949f187187a7bfd71ceacfad9)'
<mborzecki> snapcraft does not allow layouts?
<mvo> mborzecki: I saw the fastly 503 error in spread, probably something for the store team to look at (cc sparkiegeek maybe?)
<mvo> mborzecki: it looks like layout: was added to git Oct 10 in snapcraft but I doubt this is released yet
 * mvo checks
<mborzecki> mvo: found some info in https://forum.snapcraft.io/t/snap-layouts/7207
<mvo> mborzecki: I wish we had the "published-into-channel" metadata already :)
<zyga> It allows layouts since 3.x but you must also use a base
<mborzecki> so mesa OpenCL implementation is listed by clinfo now
<mborzecki> and no denials, that's probably because layouts opens up /etc/OpenCL/vendor
<pstolowski> morning
<mborzecki> pstolowski: hey
<Chipaca> moin moin
<mvo> hey Chipaca and pstolowski !
<pedronis> morning (me is up since a bit for a meeting)
<pedronis> zyga: mborzecki: hi, we should just close #6099 for now? right?
<mup> PR #6099: cmd/snap-confine: always put the snap process under a device cgroup <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6099>
<mborzecki> pedronis: yes, let me close it
<pedronis> thx
<mup> PR snapd#6099 closed: cmd/snap-confine: always put the snap process under a device cgroup <â Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6099>
<pedronis> Chipaca: hi, you are already working on the sanity check for epochs?
<pedronis> Chipaca: I reviewed the send epochs one
<Chipaca> pedronis: I am
<Chipaca> pedronis: saw the review, will circle back in a bit
<Chipaca> got distracted by the forum
<Chipaca> and reddit
<Chipaca> https://www.reddit.com/r/Ubuntu/comments/9x0b5r/and_this_is_one_reason_why_i_dislike_snaps/
<Chipaca> somebody asks why we don't use a private mount namespace to hide these
<Chipaca> I dunno if that'd work, but if it did, and it made people happy, maybe we should
<pedronis> Chipaca: what are these?  (me not sure I want to get lost in reddit right now)
<Chipaca> pedronis: nah, not worth your time, nothing actionable for us beyond the mount namespace question
<pedronis> Chipaca: could you convert the card for the sanity check to doing otherwise I'll do it
<Chipaca> uh, isn't it there already
<Chipaca> i thought i'd put it in doing yesterday during the meeting
<Chipaca> ah no 'send epoch' is doing
<Chipaca> done
<mborzecki> zyga: i got opencl & mesa to work, but there's some trouble with opencl and nvidia, i can get the libraries in, but the icd file is /etc/OpenCL/vendor/nvidia.icd in the host filesystem
<Chipaca> done moving it to doing
<Chipaca> not done done
<mborzecki> zyga: though tbh as a workaround a snap could generte the file itself and use layouts to put it under /etc/OpenCL/vendor
<pedronis> Chipaca: thank you
<pedronis> pstolowski: hi, thanks for the checklist, making some cards for hotplug
<pstolowski> pedronis: sure; i think we're stumbling on each other's feet right now, something unexpected just happend ;)
<pedronis> pstolowski: oops, sorry
<pstolowski> np
<zyga> re
<zyga> now to work :)
<pedronis> mborzecki: I added some info to the "snap connections" card, I will look at plan/review the PR when I have gone through some slightly higher prio stuff
<mborzecki> pedronis: thanks
<zyga> mborzecki:I like the idea of snapd generating config files for hardware and injecting them in /etc
<pstolowski> pedronis: can you explain "Doing" lane in the rules.. card? i'm abit unclear on that one (vs upcoming)
<Chipaca> pedronis: I'm not sure I understand your comment on 6142: isn't amend _already_ an "install"?
<pedronis> pstolowski: Doing means you are working on it,  upcoming for things you are planning to do but not working on yet
<pedronis> some things might go straight to doing
<Chipaca> pedronis: uh, now I see it
<Chipaca> will fix
<pedronis> Chipaca: :)
<mup> PR snapd#6151 closed: snapd: allow snap-update-ns to read /proc/version <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6151>
<pstolowski> pedronis: ok, thanks
<Chipaca> pedronis: so the amend check is wrong in store
<Chipaca> and maybe the amend test is also wrong
<Chipaca> hmm hmm
 * Chipaca stashes the checking work
<pedronis> Chipaca: store as in our store package?
<pedronis> or store store?
<pedronis> anyway I'm quite sure we want that change
<pedronis> and the rest should follow
<zyga> one small trello tip
<zyga> you can use the menu on the right to filter cards
<zyga> e.g. to show all the cards you are a member of
<zyga> very useful IMO
<pedronis> yup
<Chipaca> pedronis: the amend test i added in the store package
<Chipaca> pedronis: sends the snap id (d'oh)
<pstolowski> pedronis: ok, i created a couple of cards and left some in the checklist for hotplug for the time being
<pedronis> pstolowski: thanks
<pedronis> pstolowski: it looks reasonable, I think it matches what PR you have up etc, but indeed doesn't make sense having too much in doing or also in upcoming
<pedronis> Chipaca: I admit I didn't look super closely at tests in the first pass
<pedronis> also because I'm sure we were missing some or something (because of amend)
<mborzecki> heh rebuilt my snap with core18 clinfo stopped working :/
<mborzecki> anyone on 18.04?
<zyga> mmm, no, 18.10
<mborzecki> zyga: can you install clinfo package and run it?
<zyga> sure
<zyga> mvo: https://github.com/snapcore/snapd/pull/6153/files#diff-0eac7194db86098b8f1b2084fb732ec4
<mup> PR #6153: tests: use mock-gpio.py in enable-disable-units-gpio test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6153>
<mvo> zyga: oh, looks like there is a leftover [Install] - thanks for spotting
<zyga> mvo: I left a suggestion to apply
<mvo> zyga: yeah, like it
<mvo> zyga: https://github.com/snapcore/snapd/pull/6153/files#diff-0eac7194db86098b8f1b2084fb732ec4L5 is also wrong, I need to fix/revert this
<mup> PR #6153: tests: use mock-gpio.py in enable-disable-units-gpio test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6153>
<zyga> oh
<zyga> I didn't notice
<zyga> yeah
<zyga> mborzecki: clinfo has one line of output
<zyga> "Number of platforms"
<zyga> what did you want from that?
<mborzecki> hm so it must be one of the libs
<zyga> 	linux-vdso.so.1 (0x00007ffda4f1c000)
<zyga> 	libOpenCL.so.1 => /usr/lib/x86_64-linux-gnu/libOpenCL.so.1 (0x00007f45ae00e000)
<zyga> 	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f45ae008000)
<zyga> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f45ade1e000)
<zyga> 	/lib64/ld-linux-x86-64.so.2 (0x00007f45ae453000)
<zyga> ldd ^
<mborzecki> zyga: i've installed beignet and pocl opencl implementations in the snap and opencl exits with an error from llvm now :/ probably one of the libs is doing something wrong or loading both of them breaks things
<mvo> zyga: does lp 1786889 is something we fixed recently? I vaguely remember this error
<zyga> mvo: yes
<mvo> zyga: I will set to fix commited then
<zyga> 4.18.0-041800-generi
<zyga> this is a mainline kernel
<mvo> oh
<mvo> zyga: so this is just not supported?
<zyga> not exactly, it should work with 2.36.x
<zyga> we added some extra rules for that
<zyga> same thing was affecting TW
<mvo> zyga: ta
<mborzecki> zyga: btw. generating vulkan icd file for nvidia looks tricky, there is an api version listed in the file, need to check if it's required, but from the looks of it the drivers declare different versions (eg. nvidia 1.1.82, intel 1.1.80)
<zyga> it depends on how we generate  them
<zyga> I think this is something we should take from a driver snap
<mborzecki> sholud probably summarize the vulkan/opencl/glvnd craziness in a forum topic
<mborzecki> mvo: have you tried to run core18 base snap apps with --strace ?
<mvo> mborzecki: I don't know - does it fail?
<mvo> mborzecki: never conciously tried it
<mborzecki> mvo: it's getting stuck, can you try snap install test-snapd-tools-core18 and then snap run --strace test-snapd-tools-core18.echo foo ?
<mborzecki> mvo: maybe we need to update th list of skipped syscalls
<mvo> mborzecki: let me try that - I bet we need to blacklist one more systemcall :/
<mup> PR snapd#6082 closed: overlord/ifacestate: set hotplug-key of the connection when connecting hotplug slots <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6082>
<mup> PR snapd#6146 closed: ifacestate/helpers: added SystemSnapName mapper helper method <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6146>
<mvo> mborzecki: fun, when I try to run tests-napd-tools.echo I get "unexpected wait status 0x8b"
<mborzecki> mvo: adding -e !nanosleep unblocks it here
<mvo> mborzecki: cool! will you do a PR or shall I?
<pstolowski> Saviq: hey, it seems that installing/refreshing/removing multipass snap disconnect network for a short moment (or at least NM thinks it does); i suppose it's brige setup or something?
<mborzecki> mvo: zyga pasted me a log from his run, and teher's no nanosleep there, i'm probably running a newer kernel so maybe something new was added to vdso
<mborzecki> mvo: i'll open a PR
<mvo> mborzecki: ok
<Chipaca> mborzecki: pedronis: Thank you for your reviews of #6142! I believe I've addressed your concerns.
<mup> PR #6142: overlord/snapstate, store: always send epochs <Created by chipaca> <https://github.com/snapcore/snapd/pull/6142>
<Chipaca> let me know if I should pull out any of those commits into their own PR
<Chipaca> at least Epoch.Unset would stand alone if needed (but it's pretty trivial)
 * Chipaca -> more coffee
<pedronis> Chipaca: Unset is like Revision.Unset right? anyway the PR doesn't seem that big even after the changes
<mup> PR snapd#6155 opened: cmd/snap: add nanosleep to blacklisted syscalls when running with --strace <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6155>
<mborzecki> mvo: ^^
<mvo> mborzecki: ta
<pedronis> zyga: is there a easy way to use layouts to turn a read-only directory from the base into a writable directory into which things can get added?
<Chipaca> pedronis: yes, exactly like Revision.Unset semantically
<Chipaca> internal is different because different
<Chipaca> also we had two places already doing that check so it's really less code :-p
<zyga> pedronis: yes
<Chipaca> anyway. I'd said I was getting more coffee and didn't. I shall now.
<zyga> Thatâs available since improved content interface
<pedronis> zyga: do you need to actually add a file in the layout? or just need to specify the directory?
<mvo> hrm, it looks like our strace is not compatible with libnss-systemd, when I have this is installed the straced apps will segfault. oh well
<zyga> pedronis: a directory is sufficient
<zyga> We support both file and directory layout items
<pedronis> zyga: apparmor would still need to le us through right, though. I'm thinking something like /etc/foo
<pedronis> where foo exist in the base
<Saviq> pstolowski: yeah, if NM is dumb enough
<zyga> Yes, though the layout code does that too
<Saviq> pstolowski: I never noticed it though, care to file a bug please?
<pstolowski> Saviq: sure. could as well be a Mate NM indicator thing
<Saviq> yeah if it doesn't filter the interfaces
<Chipaca> hmmm. ssh -nNT -L ~/.snap/${remote}.snapd:/run/snapd.socket $remote
<Chipaca> hmm
<niemeyer> Guten Morgen
<sparkiegeek> moin moin
<pedronis> niemeyer: hi
<pedronis> Chipaca: niemeyer: given that you worked/discussed this initially I would be interested in your input on this:  https://bugs.launchpad.net/snapd/+bug/1803212
<mup> Bug #1803212: snap restart starts disabled services <snapd:New> <https://launchpad.net/bugs/1803212>
<ondra> zyga about avahi, stable is one to use. I made pull request to upstream, but it has not been accepted yet, that's why git commit in version
<Chipaca> pedronis: I think we fixed this recently
<pedronis> Chipaca: ?
<pedronis> Chipaca: fixed which way?
<Chipaca> ah sorry no
<ondra> zyga and once 2.36 lands, I current beta will go to stable to align it with classic, so clients can works same way on core and classic
<Chipaca> pedronis: we fixed the "snap refresh restarts disabled services" one :-)
<Chipaca> so close
<pedronis> heh
<pedronis> anyway
<pedronis> I can think about it, but input from original design sources could be useful
<niemeyer> pedronis: The way we cooked the commands gives a hint about what's reasonable there.. we can start something without it being enabled:
<niemeyer>       --enable       As well as starting the service now, arrange for it to be started on boot.
<Chipaca> why is launchpad so horrible at whitespace
<niemeyer> ... for so long
<sparkiegeek> Chipaca: because HTML, and backwards compatibility is hard?
<niemeyer> pedronis: So IMO restart should not touch disabled services either
<Chipaca> sparkiegeek: I've never not been frustrated by its handling of whitespace, so at least it's consistent
<niemeyer> sparkiegeek: Given how many systems get this right, I don't buy it
<pedronis> niemeyer: start should do though?
<niemeyer> pedronis: If you specifically name it, yes
 * Chipaca changes a <div> to a <pre> and is happier
<niemeyer> pedronis: Sorry, let's explore this better:
<pedronis> niemeyer: no, we are talking about <snap> here
<pedronis> not single services
<niemeyer> pedronis: If a service is running, it seems reasonable for it to be restarted
<niemeyer> pedronis: No matter hwat
<pedronis> I think the issue is what makes sense for restart <snap> vs overall consistency
<niemeyer> pedronis: Same is true for stop
<pedronis> niemeyer: what if something is not enabled but running, and one uses stop <snap>
<niemeyer> pedronis: There's only one option that sounds sane from a user perspective, right?
<pedronis> stopping it
<niemeyer> Yep
<pedronis> so we are left with snap start <snap>
<niemeyer> That's the slightly tricky one, as there are two potentially valid expectations
<pedronis> yes
<pedronis> start everything (mimic stop), start only enabled
<pedronis> (more like restart)
<niemeyer> Yeah, except restart clearly makes some sense even for disabled services,  as long as they are running
<pedronis> yes
<pedronis> so stop stops everything running
<pedronis> restart, restart everything running
<pedronis> but start is trickier
<niemeyer> I think there's way to define it
<pedronis> notice also that the user asked for different behavior that these
<niemeyer> There's one option which is more reasonable when running "snap stop" + "snap start"
<niemeyer> Which is a pretty reasonable pair
<niemeyer> I think we should make "snap start <snap>" only act on enabled services, and error out if all services are disabled
<pedronis> ok
<niemeyer> This way "snap stop <snap>" followed by "snap start <snap>" will tend to do the right thing
<niemeyer> But "snap start <snap>.<app>" should work always, since it's a more clear request
<pedronis> I can write something there, I also need to ask again if the user really meant what he wrote about restart disabled running doing nothing
<pedronis> yes
<niemeyer> snapctl should match
<niemeyer> Otherwise it's error prone
<pedronis> yea
<Chipaca> should we add flags for the complimentary option?
<Chipaca> ie snap start --all
<Chipaca> or sth
<Chipaca> snap restart --only-the-odd-numbered-ones
<Chipaca> :)
<Chipaca> complementary*
<pedronis> Chipaca: snap start --enable <snap>  will imply all I think
<pedronis> not sure it's enough
<niemeyer> pedronis: What the user is asking for has little bearing unless the argument comes with rationale similar to the discussion we had above
<pedronis> niemeyer: sorry, I'm not saying we should do what he says, but I just want to dig into the bit where il would diverge
<niemeyer> pedronis: For example, the very first case suggested in the bug is already breaking reasonable expectations
<niemeyer> pedronis: With a running service, having "snap restart <snap>" doing nothing is super awkward
<niemeyer> pedronis: Yeah, makes sense
<pedronis> Chipaca: given you worked on this how complicated would be restart only running ones?
<mvo> mborzecki: when you have a moment I would love to talk about LP: #1791182 - I started a PR but your input would be great as this is something that happend with parallel installs changes
<mup> Bug #1791182: Okular launcher present in Apps menu after removing Okular snap app <apps> <launcher> <menu> <okular> <snap> <snapd:In Progress> <https://launchpad.net/bugs/1791182>
<Chipaca> pedronis: not too hard
<Chipaca> pedronis: TOCTOU prone though
<pedronis> Chipaca: mmh, there's try-restart (oddly named)
<pedronis> which seems to do that
<Chipaca> pedronis: and try-reload-or-restart
<Chipaca> pedronis: this could work, for restart
<Chipaca> if that's what's wanted :)
<pedronis> Chipaca: just exploring
<pedronis> no immediate action
<pedronis> I need to answer/write a bit more in the bug
<niemeyer> Chipaca: Yeah, given the name, try-reload-or-restart sounds like the right thing
<niemeyer> Chipaca: It's the kind of command that likely made an appearance when people realized the default behavior was not the best one
<mup> PR snapd#6156 opened: [RFC] wrappers: remove all desktop files from a snap on removal <Created by mvo5> <https://github.com/snapcore/snapd/pull/6156>
<niemeyer> But it was too late to change get the default
<Chipaca> to be clear: we'd do try-restart or try-reload-or-restart depending on whether --reload was given
<Chipaca> on the other hand
<Chipaca> if a service failed
<Chipaca> 'snap restart' will stop starting it up again
<pedronis> mmh
<mvo> zyga: you mentioned you worked on a followup test in 6128 - is that in progress or shall I have a look at this?
<mup> PR snapd#6127 closed: overlord/ifacestate: setup systemd backend in separate pass <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6127>
<mup> PR snapd#6128 closed: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6128>
<zyga> mvo: I'm working on that
<zyga> mvo: just talking to maciej on HO now
<mvo> zyga: cool
<pedronis> Chipaca: restart if running, or enabled but failed doesn't roll on the tongue
<Chipaca> so it'd be try- only if not specifying services (ie if specifying snaps)
<Chipaca> i guess that's reasonable. We'd have to announce the behaviour change.
<pedronis> yes
<mup> PR snapd#6143 closed: cmd: install snap-discard-ns in "make hack" <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6143>
<Chipaca> pedronis: https://pastebin.ubuntu.com/p/tcgQXFcvmC/ <- is this something we'd want?
<Chipaca> pedronis: or should we consider adding a column?
<pedronis> Chipaca: I would put it only in info for now
<Chipaca> (adding a column sounds perilous)
<Chipaca> pedronis: I'd thought maybe add it in notes if != "0"
<pedronis> it can get complicated/long
<Chipaca> yes
<Chipaca> almost arbitrarily long
<pedronis> yea
<pedronis> epochs should be fairly transparent to the user in the normal case
<pedronis> unless one is debugging or it's a db snap or something
<pedronis> but then info seems ok
<pedronis> Chipaca: I mean we might end up doing something in list but I wouldn't start there before we have snaps using this around
<pedronis> to think about
<pedronis> showing the whole epoch doesn't seem an option there
<Chipaca> ok
<Chipaca> FWIW the max epoch currently would have len 240
<pedronis> Chipaca: you are not making your case, if you are making one to put it there :)
<Chipaca> pedronis: no i'm explaining that I understand the problems
<pedronis> ok
<Chipaca> pedronis: today epoch isn't seen by the client at all, fwiw
<pedronis> a saving grace actually
<pedronis> so far
<pedronis> I know
<pedronis> if we want to show in info we need to change that
<Chipaca> :)
<pstolowski> pedronis: described autoconnect difficulties https://forum.snapcraft.io/t/hotplug-autoconnect/8526 ; i only mentioned 3 interfaces as i'm not sure what else that we currently have makes sense for hotplug
<pedronis> pstolowski: thanks
<pedronis> pstolowski: I'll do a pass myself over the interface types and see if I find others relevant to this
<mup> PR snapd#6157 opened: userd: force zenity width if the text displayed is long <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6157>
<clobrano> Hi all :), could anybody tell me whether the "version-script" stage is still supported (even if deprecated)? I'm having a weird Yaru build failure on Travis
<mup> PR snapcraft#2402 closed: packaging: update requests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2402>
<clobrano> ^ here is the log https://travis-ci.org/ubuntu/yaru/builds/454222505
<cachio> zyga, hey
<zyga> hi
<cachio> after the images for bionic and cosmic were updated
<cachio> systemd was upgraded
<cachio> and now we can see the mount issue on those systems too
<cachio> :(
<cachio> zyga, most of the red builds are because of that issue
<zyga> oh fun
<zyga> I will be busy today
<zyga> thanks for letting me know
<mborzecki> yay
<zyga> I will prioritise this
<mborzecki> now we'll have to fix it :)
<mvo> degville: hi, I subscribed you to bug lp 1745037 - hope you don't mind, looks like a relatively straightforward docs fix
<cachio> mborzecki, sadly yes
<cachio> :)
<pstolowski> pedronis: in theory we could maybe have hotplug for e.g. removable media, but i'm not sure if it makes sense in practice
<mup> PR snapd#6069 closed: ifacestate/hotplug: removeDevice helper <Hotplug ð> <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6069>
<Chipaca> mvo: cachio: do any of our test-snapd- snaps have branches ?
<cachio> cachio, no
<cachio> at least mine
<cachio> Chipaca,
<Chipaca> cachio: ta
<Chipaca> cachio: is test-snapd-tools one of yours?
<cachio> Chipaca, no
<Chipaca> cachio: ok
<degville> mvo: thanks - I'll take a look!
<mup> PR snapcraft#2404 closed: cli: handle yaml errors for cleanbuild <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2404>
<mvo> 5845 is green! a second review would be great (maybe from jdstrand  ?)
<mvo> Chipaca: they are all(?) owned by the canonical account and shared
<mvo> Chipaca: aren't branches not long lived? or is that controlled easily server side?
<zyga> fun
<Chipaca> um
<zyga> two bugs
<Chipaca> mvo: i meant tracks
<zyga> well, two *new* bugs
<Chipaca> cachio: sorry i meant tracks :-)
<zyga> one in snap-confine and one in snap-update-ns
<mvo> Chipaca: not afaik - lets create one for test-snapd-tools?
<Chipaca> mvo: +1
<Chipaca> mvo: i'm wanting to have something to test epochs from the store with
<Chipaca> easiest, other than having a  snap just for that, is adding a track
<Chipaca> otherwise I could just make a test-snapd-epoch snap
 * mvo nods
<Chipaca> mvo: which would you rather?
<zyga> mborzecki: fixed
<zyga> mborzecki: the 2nd bug
<zyga> the 1st bug will be next shortly
<mborzecki> zyga: ok, ping me for reviews, i'm keen to try it out on centos
<sergiusens> icey: you might want to report an issue for the webteam
<mvo> Chipaca: ups, missed the quesiton - either way is fine, sorry. maybe test-snapd-epoch is simpler as we don't need to ask the store for creating of a track
<mvo> cachio: hey, so I would like to write a spread test for {personal,system}-files it needs a snap declaration to connect the interface, do we have test for similar interfaces already that I could use as a blueprint?
<zyga> mborzecki: spread test in flight
<mborzecki> are interface hooks supported by snapcraft?
<Chipaca> mvo: can you register test-snapd-epoch and invite me to collaborate on it?
<Chipaca> mvo: (in the Canonical account i mean)
<mvo> Chipaca: sure
<Chipaca> mvo: if you need to push a revision to collaborate, rename tests/lib/snaps/basic :-)
<Chipaca> I don't intend it to do anything (for now at least)
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6158
<zyga> 2nd bug
<zyga> now looking at 1st
<mup> PR #6158: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <https://github.com/snapcore/snapd/pull/6158>
<mup> PR snapd#6158 opened: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <https://github.com/snapcore/snapd/pull/6158>
<cachio> mvo, and what does it do?
<cachio> sh?
<mvo> Chipaca: you should have mail
<mvo> cachio: it allows access to files outside of the regular confinmement
<mvo> cachio: e.g. $HOME/.my-folder
<cachio> ok, so you can use the sh snap
<cachio> one sec
<cachio> mvo, test-snapd-sh
<cachio> just add the app there
<cachio> with the plug you want
<cachio> and that's it
<cachio> mvo, in the test then you can do test-snapd-sh.<your-app> "ls <path>"
<cachio> i.e. test-snapd-sh.with-broadcom-asic-control-plug -c "cat /dev/$device"
<cachio> mvo, does it work for you?
<mvo> cachio: I will look into it some more after lunch, thanks
<cachio> mvo, ok, I can create the test if you want
<cachio> mvo, so you can take other stuff
<cachio> I created many similar tests before
<zyga> mvo: can you please review https://github.com/snapcore/snapd/pull/6123
<mup> PR #6123: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <https://github.com/snapcore/snapd/pull/6123>
<zyga> -4029
<zyga> -402 +8 changes
<Chipaca> mvo: thanks
<mvo> cachio: that would be great, I'm not sure though if "deny-connection: true" will make things more complicated for the test
<mvo> cachio: but either way, help with the spread test would be great
<mvo> zyga: gladly
<mvo> zyga: whats not to like about this amount of "-"
<cachio> mvo, nice, I'll start with it today
<cachio> mvo, "deny-connection: true" shouldn't be a problem
<zyga> if anyone has review time, this is the only feature PR to review from my stuff: https://github.com/snapcore/snapd/pull/6145
<zyga> +87 -10 so not terrible
<zyga> mostly just tests
<mup> PR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
<zyga> actually not mostly just tests
<zyga> but not much anyway :)
<mborzecki> off to pick up the kids
<pstolowski> Chipaca: i'd be happy to approve #6107 when you add the missing test case, then it could land
<mup> PR #6107: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107>
<pedronis> pstolowski: I was a bit surprised that it really did show the column, not even name
<pedronis> I mean 6107
<pedronis> also the prereq doesn't have two reviews
<pedronis> Chipaca: I left a note in #6107, we should talk a sec on it
<mup> PR #6107: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107>
<mborzecki> re
<zyga> mborzecki: first bug also fixed, spread test took longer to write
<zyga> but I'm happy with the outcome
<mborzecki> pstolowski: question about interface hooks, is the hooks executed under the security profile that comes from the interface?
<zyga> much better than the original unit test
<zyga> fired it up now, should be ready by standup
<mborzecki> zyga: thanks for the fixes :)
<zyga> thank you for finding bugs :)
<mborzecki> heh
<pstolowski> mborzecki: depends, prepare-slot-*, prepare-plug-* - are not. connect-plug-*, connect-slot-* yes
<pstolowski> pedronis: hmm, i see what you mean
<mborzecki> pstolowski: i'm using connect-plug-opengl, hm maybe i need to look into that further
<pstolowski> mborzecki: let me know the details if you obseve anything suspicious. you might be the first one to make use of interface hooks..
<mborzecki> pstolowski: i don't need to declare plugs for interface hooks, do I? i mean it's it's a connect-plug-opengl hook then it runs with opengl plug implicitly, doesn't it?
<zyga> mborzecki: interesting but doubtful
<zyga> mborzecki: the hooks have the snap-level interfaces only
<sergiusens> zyga: I am getting this cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied when I try to run a snap try inside lxd
<zyga> anything scoped will *not* affect hooks
<zyga> sergiusens: what's the kernel version and snapd version?
<zyga> sergiusens: please report a bug, I will investigate
<pedronis> mborzecki: there is no code to make that implicit afaik, so either global plug, or the hook needs to list the plug
<zyga> sergiusens: (we're now using bugs for ... bugs) :-)
<sergiusens> https://www.irccloud.com/pastebin/SoCmFTkp/
<sergiusens> zyga: I do not believe you!
<sergiusens> I have been conned into reporting bugs before ;-)
<zyga> sergiusens: thank you, the host is ~~~ 18.04 or newer, I presume?
<zyga> sergiusens: and the host is xenial container, right?
<sergiusens> yes, xenial
<sergiusens> also, the snap uses bases
<mborzecki> pedronis: yup, adding plug explicitly made it work
<zyga> sergiusens: please report it, I'll check it out after writing tests for another fix
<pstolowski> zyga: one question re 6145, otherwise +1
<zyga> looking
<zyga> pstolowski: replied
<zyga> thank you for the review, this PR is the most important to move other mount stuff forward
<pedronis> Chipaca: standup ?
<pedronis> zyga: ^
<zyga> oh, joining
<sergiusens> zyga: got it to work by installing core...
<zyga> sergiusens: interesting
<mup> PR snapd#6159 opened: cmd/snap-confine: handle mounted shared /run/snapd/ns <Created by zyga> <https://github.com/snapcore/snapd/pull/6159>
<om26er> popey: ping
<popey> PONG!
<zyga> echo echo echo
<om26er> popey: the asciinema upstream wants to update its snap to latest version but the snap was uploaded by MarkS, so wanted to know what's the procedure to get that snap uploaded from their official account ?
<om26er> https://github.com/asciinema/asciinema/issues/296#issuecomment-438025083
<popey> Wimpress is about to be in the same physical location as sabdfl, maybe he could mention it :)
<om26er> so basically they are willing to move the packaging under their github org and I am committing to maintenance there.
<popey> (I think transferring the snap upstream is the best course of action)
<om26er> yep
<popey> i have let wimpy know, he's on a plane right now, but I'm sure he'll pass the message on when he gets there :)
<popey> thanks for letting us know om26er
<om26er> popey: sounds good to me, cheers!
<mup> PR snapd#6160 opened: nvidia, interfaces/builtin: OpenCL fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6160>
 * cachio lunch
<Wimpress> At the airport. I'll mention to Mark.
<zyga> quick break
 * pedronis mostly eods (will be back for some meeting later)
<mvo> mborzecki: heh, I was about to ask about 6160 and if we should pull it into 2.36 and then you added the milestone. thanks for this!
<mup> PR snapd#6160 closed: nvidia, interfaces/builtin: OpenCL fixes <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6160>
<mvo> mborzecki: could you please create a pr based on 2.36 for this? I tried to cherry-pick but the second commit does not apply cleanly
<mborzecki> mvo: sure
<mvo> ta
<mborzecki> mvo: i think we shoud also pick https://github.com/snapcore/snapd/pull/5696
<mup> PR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5696>
<mvo> mborzecki: ok, let me see if I can cherry pick this
<mborzecki> also that's what 6160 is conflicting with
<mvo> mborzecki: done, this is in 2.36 now
<mborzecki> mvo: ta
<mborzecki> mvo: 6160 will now apply cleanly on top of 2.36, do you want to me open a PR?
<mvo> mborzecki: no, thats fine then
<mborzecki> ok
<mvo> mborzecki: done, thanks again
<mborzecki> np
<zyga> re
<zyga> taht was a longer quick break but I did handle both lunch and the dog :)
<sparkiegeek> ate the dog and fed the lunch?
<zyga> unfortunately no hot-dogs :)
 * zyga sighs seeing a test fail on 14.04 
<zyga> "fun"
<zyga> they said crying ;)
<zyga> let's see
<pstolowski> zyga: #6158 can land?
<mup> PR #6158: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <https://github.com/snapcore/snapd/pull/6158>
<zyga> pstolowski: yes, please
<mup> PR snapd#6158 closed: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6158>
<zyga> mvo: can we have milestones on launchpad?
<zyga> now that we have bugs we could do that too :)
<mvo> zyga: yeah
 * zyga could use a 2nd review on https://github.com/snapcore/snapd/pull/6145
<mborzecki> zyga: 6158 for 2.36 too?
<zyga> mvo: I looked but I cannot add any
<mup> PR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
<zyga> mborzecki: so that's a good question, I can make a backport if mvo agrees
<zyga> it's fairly simple and significant
<mvo> zyga: I created one, how do you want to use it?
<zyga> one sec
<mvo> zyga: backport for what? sorry, miss context
<zyga> mvo: sorry, two topics
<zyga> mvo: one topic: the milestone, on lauchpad, I'd love to be able to set milestone for this bug: https://bugs.launchpad.net/snapd/+bug/1803535
<mup> Bug #1803535: Certain layouts cannot be constructed correctly <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1803535>
<mvo> zyga: added the milestone, go wild
<zyga> mvo: topic two, shall I create a backport for this issue and propose it for 2.36 release branch?
<zyga> mvo: I don't have the permission
<mvo> zyga: yes please, also no need for a backport if it can be cherry-picked cleanly
<zyga> mvo: so shall I just push into the release branch?
<mvo> zyga: I created the milestone in LP now, do you need more?
<zyga> it should be clean
<mvo> zyga: yeah, if its clean cherry picks thats fine
<zyga> mvo: yes, I cannot assign the milestone to the bug
<zyga> not sure which LP permission governs that
<mvo> zyga: I targed it to the series
<mvo> zyga: but you should also be able to do that
<zyga> milestone column was empty for me
<zyga> thanks for doing that
<zyga> I see "target to series"
<zyga> and I can target it for "trunk"
<mvo> zyga: that is confusing, let me check
<zyga> mvo: cherry picked and pushed to the 2.36 release branch
<zyga> mvo: I TG a screenshot of what I see
<mborzecki> zyga: findmnt in ubuntu 14.04 cannot do --output=PROPAGATION
<zyga> mborzecki: yeah, I just installed it to play
<zyga> blast from the past :)
<zyga> unity
<zyga> mborzecki: there's RHEL 8 beta!
<mborzecki> zyga: heh, which kernel version? 3.17? :)
<zyga> hold on :)
<zyga> mborzecki: downloading, I will let you know
<mborzecki> zyga: hm don't see it on developers.redhat.com
<zyga> you need to opt into the beta
<zyga> hold on
<mborzecki> aah there it is
<zyga> https://access.redhat.com/products/red-hat-enterprise-linux/beta?extIdCarryOver=true&sc_cid=70160000000dJVaAAM
<zyga> mborzecki: boot iso or binary dvd?
<zyga> I'll get both
<zyga> but weird...
<mborzecki> zyga: signed up just now
<thresh> at least 4 something cause it says bbr everywhere
<thresh> you need binary
<thresh> at least thats what they say in the mail
<mborzecki> zyga: hm ppc64le, aarch64 :)
<zyga> mborzecki: and there's a new raspberry pi!
<zyga> Pi 3 A+
<zyga> no eth, just wifi
<zyga> 119PLN
<mborzecki> no emmc?
<ogra> yeah ... as poorly designed as the b+
<zyga> 512MB ram
<zyga> WTF
<ogra> (high speed networking on a USB2 hub)
<zyga> no emmc
<ogra> indeed
<zyga> I'll pass
<ogra> only the cm3 has MMC
<mborzecki> so still nothing more than a curiosity ;)
<ogra> yeah
<mborzecki> wish i could do something useful with my CHIP though
<ogra> port core to it !
<mborzecki> iirc there was a gadget for it
<zyga> what's the HW inside the chip?
<ogra> there is a chip inside the chip ;)
<zyga> yes :D
<mborzecki> zyga: https://en.wikipedia.org/wiki/CHIP_(computer)
<mborzecki> the company went belly up :)
<zyga> making products for $9 tends to make that happen
<zyga> I think I know how to use findmnt and not cry a river over 14.04
 * zyga tweaks
<ogra> well, marketing it for $9 and producing it for $30 or so ...
<ogra> wasnt the cleverest strategy :)
<mup> PR snapcraft#2409 opened: python plugin: process deps before and separately from setup.py <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2409>
 * zyga -> school 
<zyga> ok, fixed 14.04 tests (hopefully)
<mup> PR snapd#6155 closed: cmd/snap: add nanosleep to blacklisted syscalls when running with --strace <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6155>
<cachio> mvo, sorry, is it .dot files interface already merged?
<mvo> cachio: it is still in review, one sec, let me find the pr number
<mvo> cachio: 5845
<cachio> mvo, I just discovered that
<cachio> thanks
<mvo> yw
<mvo> thanks for looking into it
<cachio> I could add the test to that PR, or create a new branch, what do you prefrer?
<mup> PR snapd#6123 closed: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6123>
<zyga> mvo: I didn't notice https://github.com/snapcore/snapd/pull/6128 is merged!
<mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6128>
<zyga> I'll push tests to a follow-up
<zyga> can we get an edge build
<zyga> and let the customer know
<zyga> anyone for a 2nd review of https://github.com/snapcore/snapd/pull/6145 ?
<mup> PR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
 * zyga considers wrapping up
<zyga> mvo: do you think you could look at https://github.com/snapcore/snapd/pull/6111 tomorrow, nothing binding, just tell me what you think
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> mainly at the makefile path
<zyga> as spec file is probably not terribly interesting
<popey> Is there some env var I need to set for classic snaps to 'find' GL drivers? Where do I point it?
<popey> (not using desktop helpers)
<mup> PR snapd#6161 opened: tests: new test suite to run snapd tests on a google remote instance <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6161>
<zyga> popey: dunno
 * zyga came to check on PRs
<mup> PR snapd#6162 opened: interfaces/greengrass_support: update accesses for GGC 1.6 <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6162>
#snappy 2018-11-16
<mup> PR snapcraft#2408 closed: multipass: avoid stdin where possible <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2408>
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> hey mborzecki - good morning
<zyga> Hey
<zyga> Oh boy, winter is coming
<zyga> mborzecki: RHEL 8 has very recent kernel
<mborzecki> zyga: and a very far relase date :)
<zyga> What is the release date?
<mborzecki> zyga: when it's ready
<mborzecki> zyga: i don't think they've annouced anything yet
<zyga> Mmm
<pstolowski> morning
<mborzecki> pstolowski: hey hey
<mborzecki> 2.36 branch is failing all the time
<mborzecki> the travis job
<mborzecki> google:opensuse-42.3-64:tests/main/interfaces-openvswitch-support is failing, i'd be surprised if it's https://bugzilla.opensuse.org/show_bug.cgi?id=1115168
<mup> PR snapd#6152 closed: spdx: update licenses to current data <â Blocked> <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6152>
<mborzecki> there's something messed up with our opensuse-42.3 images, they are not 43.2 but leap 15.0, https://paste.ubuntu.com/p/ZYFc8Rkjq4/
<mborzecki> i guess cachio is the only one who can fix it?
<mvo> mborzecki: yeah, I think so - we can set opensuse to manual though to unblock us
<pedronis> mvo: hi, I closed the spdx PR for now, it needs some more thoughts, we also need to check what we did about licenses in our oldest releases out (debian? 16.04 active images?)
<mup> PR snapd#6163 opened: interfaces: tweak deny-auto-connect policy tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/6163>
<mvo> pedronis: yeah, thats fine
<mvo> pedronis: I agree this needs more work
<pedronis> mvo: the personal/system-files PR needs a jdstrand re-review, right?  I haven't really done a review myself yet, just gone over some bits, also sorry, not sure if I put some comments at the wrong place, or the code changed under them
<mvo> pedronis: your comments were useful, I addressed them now
<mvo> pedronis: yeah, jdstrand should look at this again, I added the allow-install: false now
<pedronis> yes, saw that
<pedronis> thanks
<pedronis> zyga: mvo: I saw we put some bug cards (with landed PR) in the Done column, shouldn't they go in the cur release column?
<mvo> pedronis: I think so, this may require a 2.36 colum now that we have backported some of the bugfixes
<pedronis> or a backport label
<pedronis> but yes
<mvo> pedronis: yeah, or that :)
<pedronis> mvo: were they backported already?
<mvo> pedronis: yes, let me double check but yes, we pulled into 3 PRs into 2.36 yesterday
<pedronis> one doesn't have a card
<pedronis> (it's ok)
<pedronis> mvo: yet, another approach is indeed two columns, and copy the cards
<mvo> pedronis: or we put the card just in 2.36 and assume that whatever bugfix we did there automatically is also in all higher versions (which is generally true because we always cherry-pick from master)
<pedronis> yes, that's usually the case
<pedronis> let's try that
<mvo> great
<pedronis> mvo: does it look right now?
<mvo> pedronis: yeah - looks good, I would switch the order 2.36 and 2.37 (so that its from lower to higher) but thats a) nitpick b) personal preference
<zyga> pedronis: re, I think you may be right, let me re-read the trello rules post
<zyga> pedronis: thank you for moving them to the appropriate lanes
<pedronis> zyga: I'm not sure the rules explain the done lanes
<pedronis> I can add that
<zyga> tumblweed moved to 4.19
<pedronis> mvo: zyga: I added a para about the done lanes into the rules
<pedronis> hope it makes sense (I hope it makes a bit also without reading them tough)
<pstolowski> zyga: i've just did snap run --shell gnome-calculator and got this:
<pstolowski> https://www.irccloud.com/pastebin/TVwffLQo/
<pstolowski> zyga: expected?
<zyga> nope
<zyga> some of those are bugs in the theme
<zyga> that are quite unexpected since they were reported months ago
<zyga> but the last few are certainly unexpected
<zyga> is this on master?
<pstolowski> zyga: i'm on edge, 2.36.1+git1017.fdb9926~ubuntu16.04.1
<zyga> thank you, I will check this out
<zyga> "fun" (not)
<pstolowski> zyga: gnome stuff is from stable
<mborzecki> pstolowski: https://forum.snapcraft.io/t/gtk-common-themes-bind-mount-sources-are-symlinks-missing-sounds/8540/1
<zyga> pstolowski: can you file the bug about /snap/
<pstolowski> zyga: sure
<mborzecki> $SNAP/share/sounds is missing entirely, and Saru icon theme is a symlink
<zyga> rebooting and jumping into this
<mborzecki> pstolowski: there's a github issue as well https://github.com/snapcrafters/gtk-common-themes/issues/16 can you add it to the topic?
<zyga> oho
<zyga> 4.19 is not working too great with snaps
<mborzecki> zyga: 4.19.1-arch1-1-ARCH, didn't notice anything special, what does not work in your setup?
<zyga> type=AVC msg=audit(1542360228.183:306): apparmor="DENIED" operation="mkdir" profile="/usr/lib/snapd/snap-confine" name="/tmp/snapd.quirks_fAGbSk/" pid=4922 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<zyga> zyga@yantra:~> snap run gnome-calculator
<zyga> cannot create temporary directory for /var/lib/snapd mount point: Permission denied
<mborzecki> hm, profile update?
<pedronis> is that the kernel really? or selinux?
<pedronis> zyga: also if it's hairy can you take a note and look more later?
<zyga> pedronis: sure
<zyga> I wonder if this is because I have been hacking on this machine
<zyga> probably so, let me just reinstall the package
<zyga> pedronis: on suse there's just apparmor, no selinux
<pedronis> ok
<zyga> yes :)
<zyga> uff
<zyga> I didn't have the permission to do quirks because I was hacking on quirks removal here
<zyga> all is good
<zyga> looking at the theme issue
<Chipaca> pedronis: morning. Do I understand correctly that you think having the 0 epoch (or rather, anything that serialises back to "0") deserialise to unset is the best approach?
<Chipaca> pedronis: (I think I agree, but wanted to confirm before implementing it -- in the same pr?)
<pstolowski> zyga: not sure if i described it correctly, but here you go: https://bugs.launchpad.net/snapd/+bug/1803687
<mup> Bug #1803687: snap run --shell gnome-calculator gives a series of errors <snapd:New> <https://launchpad.net/bugs/1803687>
<pedronis> Chipaca: yes, if we basically say internal unset === "0", it seems saner to normalize
<pedronis> Chipaca: can be a follow up tough
<pedronis> that PR is around since a while
<pedronis> (relatively speaking, is not ancient in snapd PR terms)
<Chipaca> pedronis: 8 days old, if you count the original homonymous pr, yes
<Chipaca> pedronis: anything else I should do on this one and not the followup?
<pedronis> Chipaca: you are asking because it's green ? :)
<pedronis> Chipaca: there's the amend test revision to change, it's ok for a follow up if it doesn't get lost
<zyga> thank you pawel
<zyga> reproduced
<pstolowski> great!
<pedronis> mvo: do we have a edge build now for https://bugs.launchpad.net/tillamook/+bug/1802581 ?
<pedronis> to announce
<zyga> pedronis: I believe so, I can test on my device quicklyl
<Chipaca> pedronis: was asking because the tests were green, and it's got a 'changes requested' from you :-)
<zyga> refreshing to edge, i'll know in 3 minutes
<mvo> pedronis: yeah, build 5h ago and landed last night but if its not trouble for zyga to double check lets wait for that first
<pedronis> yes, that's fine
<zyga> rebooting pi3-1
<zyga> testing now
<zyga> confirmed
<zyga> edge allows to disable and enable the snap that previously reproduced the issue
<zyga> mvo, pedronis: +1
<pedronis> mvo: zyga: I'm writing something in the bug
<zyga> thank you
<pedronis> done
<pedronis> Chipaca: I wrote what we discussed yesterday about restart SNAP etc here: https://bugs.launchpad.net/snapd/+bug/1803212
<mup> Bug #1803212: snap restart starts disabled services <snapd:New> <https://launchpad.net/bugs/1803212>
<mborzecki> zyga: if you have a rhel instance, can you `yum --enablerepo=epel-testing install snapd` and report feedback here https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b240f3418f ?
<zyga> mborzecki: I don't have one handy now
<zyga> mborzecki: actually, maybe I'm wrong
<zyga> one sec
<zyga> nope
<zyga> I think I killed it
<mborzecki> ah ok, nvm, i've given +1, snapd installs and runs on 7.6
<pedronis> Chipaca: I have a remark, it seems all the store tests use either "0" or nil, no test with something a bit more interesting
<pedronis> in epoch
<pedronis> I also don't know if the change we plan affects that
<Chipaca> pedronis: there is one snap.E("1*") in the store tests (for the amend case)
<pedronis> Chipaca: yes, but nothing for context
<Chipaca> hmmm
<Chipaca> i'll see how things change with this
<pedronis> I made a remark
<zyga> pstolowski: ah
<zyga> pstolowski: I think it's not terrible
<zyga> I was worried this is a regression
<zyga> I improved logging of trespassing events
<pedronis> Chipaca: gave a +1 assuming you'll work through my wonderings :)
<pedronis> in the follow up
<Chipaca> mbuahaha
<Chipaca> i mean, "yes of course"
<Chipaca> :-p
<zyga> pstolowski: quick question, was it failing to start in your case?
<zyga> for me it starts ok
<zyga> (as in, runs)
<zyga> https://www.irccloud.com/pastebin/lBeg5CYb/
<pstolowski> zyga: no, no, it worked (i used --shell)
<zyga> look at line 1
<zyga> this is really telling us this
<zyga> the snap gnome-calculator
<zyga> was trying to write to /snap/gtk-common-themes/808/share/sounds/Yaru
<zyga> and that was refused
<zyga> it was trying to write there because of a content connection
<zyga> that's the "remote" end
<zyga> but it is absent (not really in the snap)
<zyga> so the code tried to make it
<zyga> but it wasn't allowed to
<zyga> that's all
<zyga> interesting
<zyga> I mean, we could allow writes to /snap/*/ except for /snap/bin
<zyga> but I really think this is a bug in the desktop themes snap
<zyga> I don't quite understand what is the thing going on there
<zyga> I mean
<zyga> it's totally bogus
<zyga> sound themes exposed by gtk-common-themes https://www.irccloud.com/pastebin/1T1cK5k0/
<zyga> the share/sounds directory is not even in the snap!
<mup> PR snapd#6142 closed: overlord/snapstate, store: always send epochs <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6142>
<zyga> kenvandine: ^ should we escalate that, it feels like stable version of gtk-common-themes is missing files
<mborzecki> zyga: https://forum.snapcraft.io/t/gtk-common-themes-bind-mount-sources-are-symlinks-missing-sounds/8540 heh
<zyga> heh, thank you for reporting this maciek
<mborzecki> pinged popey and kenvandine there ;)
<zyga> with enough eyeballs :)
<zyga> wat
<zyga> the snap is on gnome gitlab
<zyga> k, done
<zyga> good :)
<zyga> back to features
<pstolowski> zyga: i see, good :)
<pstolowski> zyga, mborzecki thanks for reporting it
<mborzecki> zyga: can we do a HO about mounts & rhel/centos? wanted to discuss something
<zyga> sure
<zyga> let me join
<zyga> can we "meet" instead?
<zyga> https://meet.google.com/sri-fdeu-yur?authuser=0
<zyga> just had this open now
<pstolowski> zyga: is there anything new re mount issue that's also reported here https://bugs.launchpad.net/snapd/+bug/1772016 ?
<mup> Bug #1772016: Mount snap "snapcraft" (1591) ([start snap-snapcraft-1591.mount] failed with exit status 1: <snapd:Triaged> <https://launchpad.net/bugs/1772016>
<zyga> pstolowski: I'll check after the call with mborzecki
<pstolowski> Chipaca: was https://bugs.launchpad.net/snapd/+bug/1767445 fixed already in snapd?
<mup> Bug #1767445: Uninstalled snaps show most recent channel version, not version to be installed by default <amd64> <apport-bug> <bionic> <verification-done> <verification-done-bionic> <verification-done-xenial> <snapd:New> <Snap Store:New> <gnome-software (Ubuntu):Fix Released> <gnome-software
<mup> (Ubuntu Xenial):Fix Released> <gnome-software (Ubuntu Bionic):Fix Released> <gnome-software (Ubuntu Cosmic):Fix Released> <https://launchpad.net/bugs/1767445>
 * Chipaca looks
<mup> PR snapd#6164 opened: wrappers: rename the desktop file to their apps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6164>
<Chipaca> pstolowski: no, there was nothing to fix in the current api
<Chipaca> bah
<Chipaca> pstolowski: yeah, that
<pstolowski> Chipaca: can be closed in snapd then? or it's for the future?
<Chipaca> pstolowski: I mean, as described in the attached forum post, snapd could workaround things, but it's mostly up to the store to return the most stablest revision or not, there
<Chipaca> pstolowski: i'd go with a "Won't fix" on snapd side though, with the rationale that (a) look in the channel map if you want to know what you'll get in stable, and (b) store can change what's returned outside the channel map, which we'd forward on
<pstolowski> Chipaca: allright, thanks, it wasn't clear where the things are since that topic is 5 months old
<zyga> pstolowski: looking
<zyga> ah
<zyga> this is the issue we know about
<zyga> it's bound to be fixed this cycle
<pstolowski> pedronis: what do you think about adding a pre-remove script? one of the bug reports request that we have a remove hook that runs before stop-snap-services, not after. we kina expected this when remove hook was introduced, but just wanted feedback and people actually starting to use hooks
<pstolowski> zyga: great, thanks for updating it
<zyga> kjackal: hello
<zyga> kjackal: do you have a moment to talk about microk8
<pedronis> pstolowski: can you point me to the actual bug?
<kjackal> hi zyga, yes go ahead
<kjackal> whats up?
<zyga> I'm looking at https://bugs.launchpad.net/snapd/+bug/1802332
<zyga> and I'd like to reproduce it locally
<mup> Bug #1802332: Apparmor complains in strict confinement with base: core18  <snapd:Incomplete by zyga> <https://launchpad.net/bugs/1802332>
<zyga> is the snap something you built locally or can I get it somewhere?
<pstolowski> pedronis: https://bugs.launchpad.net/snapd/+bug/1777121
<mup> Bug #1777121: Remove is called after snap services are stopped  <snapd:Triaged> <https://launchpad.net/bugs/1777121>
<pedronis> pstolowski: thanks, I'll put in my queue of things to look at
<kjackal> the snap is patched, let me find the branch
<zyga> kjackal: can you send me the snap please
<zyga> perhaps via wormhole :)
<pedronis> zyga: what's the status of per-user mounts?  wating o reviews?
<kjackal> Ah it is on the ticket https://github.com/ubuntu/microk8s/tree/feature/strict
<zyga> pedronis: yes, I really need to land the current set
<kjackal> zyga: ^
<zyga> pedronis: it's bound with several dependencies but it should all be landable
<zyga> kjackal: so I just need to take that snap, build it, and run it?
<kjackal> yes
<kjackal> zyga: for building the snap I went to snapcraft, version 3.0+git13.g04f18f5
<zyga> kjackal: let me try, I'll bug you if I cannot get it somehow
<kjackal> thank you
<pedronis> zyga: do nag people for reviews a bit :) , given I'm sprinting next week I will not dive into that
<zyga> pedronis: ay ay sir!
<zyga> mborzecki: could you do a 2nd review on https://github.com/snapcore/snapd/pull/6145
<zyga> that's the first one to go in
<mup> PR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
<zyga> mvo: or you perhaps? ^
<zyga> this unclogs the pipe :)
<mup> PR snapd#6165 opened: cmd/snap-update-ns: extra debugging of trespassing events <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6165>
<mup> PR snapd#6157 closed: userd: force zenity width if the text displayed is long <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6157>
 * Chipaca afk for a bit
<zyga> hmm
<zyga> where does snapcraft 3.0 drop built snaps?
<mborzecki> zyga: pwd?
<mborzecki> cwd
<zyga> nope :)
<zyga> not for me
<zyga> I forked microk8s and built it with snapcraft and multipass
<zyga> no snaps found
<zyga> I'll clean and try again
<zyga> but ... wtf
<zyga> no errors or anything
<zyga> sergiusens:
<zyga> sergiusens: halp
<zyga> snapcraft 3.0
<zyga> build works for a while
<zyga> then nothing
<zyga> error code 0
<zyga> last messages are:
<zyga> https://www.irccloud.com/pastebin/V8knVrdk/
<zyga> oh boy :)
<zyga> I need snapcraft, not snapcraft build
 * zyga facepalms
<cachio> mvo, hey
<cachio> https://paste.ubuntu.com/p/CwM7k7ntvW/
<sergiusens> zyga: help no longer required I assume?
<zyga> yes :)
<zyga> sergiusens: my only comment would be to auto-match the number of cores in qemu to the cores on the host
<zyga> 6 core machine had 4 cores idle
<zyga> it matters in the last step (compression)
<mborzecki> cachio: hey, we have a problem with opensuse-42.3 images, they are in fact leap 15.0 images
<mvo> cachio: hm, hm, is it connected? I assume so
<sergiusens> zyga: oh, you can do that manually, but we were killing the machines because you need to also assign around at least 1G of RAM per core
<mborzecki> cachio: that's why 2.36 branch is failing on travis
<cachio> mborzecki, checking
<sergiusens> zyga: it was the original design, moved away from it after some testing and agreements with Saviq
<zyga> 1G ram per core? why
<mborzecki> cachio: https://paste.ubuntu.com/p/ZYFc8Rkjq4/ this was on release/2.36 branch
<sergiusens> zyga: SNAPCRAFT_BUILD_ENVIRONMENT_CPU=8 SNAPCRAFT_BUILD_ENVIRONMENT_MEMORY=8G snapcraft (for a fresh project)
<sergiusens> given that 8 is the most common amount of RAM out there (I have one of those configurations) and that I usually barely manage to have 2G of free RAM I thought this conservative approach would be best for the wider audience
<cachio> mborzecki, it seems that the last automatic update did it
<mborzecki> cachio: can you fix it?
<cachio> mborzecki, yes
<cachio> I am on that
<mborzecki> cachio: thank you!
<cachio> mborzecki, np
<cachio> mvo, yes, it is connected
<zyga> simple review for https://github.com/snapcore/snapd/pull/6165
<mup> PR #6165: cmd/snap-update-ns: extra debugging of trespassing events <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6165>
<ogra> jdstrand, i see some very weird behaviour with the kvm interface ... when i switch qemu-virgil into --devmode i all of a sudden get "qemu-system-x86_64: failed to initialize KVM: Operation not permitted" ... switching back to --jailmode makes it work again
<cachio> mborzecki, I am creating the new image
<ogra> (nothing is printed in journalctl when that happens)
<mborzecki> cachio: did the automatic update tool pick the wrong name the last time?
<cachio> mborzecki, the change was caused because opoensuse project changed hte default image from 42.3 to 15
<cachio> and we build based on that
<cachio> mborzecki, I just changed to point to a specific 42.3 image
<mup> PR snapd#6165 closed: cmd/snap-update-ns: extra debugging of trespassing events <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6165>
<zyga> thank you :)
<pstolowski> #6100 needs 2nd review
<mup> PR #6100: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100>
<pstolowski> and has nice PR number ;)
<zyga>  haha, nice
<zyga> looking
<mup> PR snapcraft#2407 closed: build providers: preset the timezone <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2407>
<cachio> mvo, this is interesting https://paste.ubuntu.com/p/Fx48q9phRR/
<Saviq> zyga: https://bugs.launchpad.net/snapcraft/+bug/1795666
<Saviq> and https://github.com/CanonicalLtd/multipass/issues/420
<jdstrand> ogra: that is weird. when you go to --devmode, is that an remove/install --devmode or something else?
<jdstrand> s/an/a/
<zyga> Saviq: using 4 cores on a 2 core system is certainly wrong
<ogra> jdstrand, a refresh
<zyga> Saviq: not sure about using 6 cores on a 6 core system
<zyga> also not sure how ram relates
<zyga> is there really a kvm correlation between ram and cores?
<jdstrand> ogra: I suspect it would work right with a remove/install. I bet something isn't right with the device cgroup when refreshing to devmode. that probably deserves a forum topic
<ogra> jdstrand, with qemu-virgil normally installed i did "sudo snap refresh qemu-virgil --edge --devmode" and "sudo snap refresh qemu-virgil --stable --devmode"
<pedronis> jdstrand: hi, is re-reviewing #5845 in your queue?
<pedronis> pstolowski: I left some comments in the hotplug-disconnect PR, we probably need to be a bit more careful about conflicts there
<pstolowski> pedronis: yep, just noticed, thanks!
 * pstolowski lunch
<cachio> mborzecki, new opensuse image ready
<cachio> mvo, snapd[30158]: task.go:303: DEBUG: 2018-11-16T11:53:56Z INFO snap "test-snapd-sh" has bad plugs or slots: personal-files (cannot add personal-files plug: "$HOME" must start with "
<cachio> I see this error too
<mborzecki> cachio: thanks, let me restart the travis jobs and see if it's ok now
<zyga> hum hum
<zyga> I need to run an errand now
<zyga> I may miss the standup
<cachio> mborzecki, nice, sorry about that issue but this leap image is not under our control
<cachio> mborzecki, I'll see if I can create a copy to our project and then use it
<mborzecki> cachio: so you mean it's some other project that's changed the image?
<cachio> mborzecki, yes
<mborzecki> cachio: yeah, copy sounds like a good idea
<cachio> mborzecki, for some oss I get the images from other projects
<cachio> i.e. opensuse, debian, etc
<mvo> cachio: interessting error, I look at it
<cachio> INFO snap "test-snapd-sh" has bad plugs or slots: personal-files (cannot add personal-files plug: "$HOME" must start with "$HOME")
<cachio> this is the full message
<zyga> https://github.com/snapcore/snapd/pull/6150 is the next branch in the chain
<kenvandine> zyga: the Suru symlink issue is fixed in a Yaru PR by jamesh, I think
<kenvandine> zyga: indeed the sounds are missing
<mvo> zyga: standup?
<zyga> kenvandine: and the sound theme issue?
<kenvandine> zyga: working on it
<zyga> I cannot join
<zyga> mvo: sorry, cannot join
<mvo> zyga: ok
<zyga> My update is short, bug fixes and nagging for reviews
<zyga> Call with Maciej about mount issues
<zyga> No new bugs so happy
<zyga> Working on tests
<zyga> Master very flaky with testing
<zyga> On 1000 cuts of random stuff breaking
<zyga> mvo: ^
<zyga> Cannot wait for 2.36.1 to be released
<pstolowski> popey: hey, i asked you in some of your old bug reports to re-check if the problems can still be reproduced, hope you don't mind
<popey> I got the mails :)
<pstolowski> popey: good. i expected this :)
<ogra> jdstrand_, if you wouldnt mind ... https://dashboard.snapcraft.io/snaps/opencv-demo-ogra/revisions/19/
<Saviq> zyga: that's not really "cores" though - it's CPU threads, so with HT, that's what snapcraft was doing originally
<Saviq> it was matching the number of threads available on the host, but without a sane amount of memory for each core
<Saviq> so I recommended $threads * 1GB
<Saviq> still, with the cgroup approach we want to apply we might reduce that limit since it will be obvious what happened
<Saviq> without it things just get stuck, OOM never kicked in
<cachio> mvo, https://paste.ubuntu.com/p/cr2cbCtDHN/
<cachio> also failing with $HOME/
<cachio> both things are conflicting
<mvo> cachio: interessting
<mvo> mborzecki: http://paste.ubuntu.com/p/3yfgGjqXGY/
<mvo> mborzecki: that was my attempt to reproduce using plain mount
<mborzecki> mvo: thanks, i'll extend it with mount units and daemon-reload like we talked about
<mborzecki> mvo: i recall there were some concerns about daemon-reload in the context of packaging and post install tasks
<mborzecki> cachio: mvo: release/2.36 branch finally green
<mvo> mborzecki: awesome
<Son_Goku> mborzecki, can you please CC me on https://bugzilla.redhat.com/show_bug.cgi?id=1650582
<Son_Goku> I can't see the bug report otherwise
<mborzecki> Son_Goku: done
<Chipaca> pedronis: https://forum.snapcraft.io/t/snapctl-status/8313/7?u=chipaca fwiw
<Son_Goku> mborzecki, thanks
<cachio> mborzecki, :)
<mborzecki> Son_Goku: the good news is that rhel8 looks fine
<Son_Goku> I'm not surprised
<mborzecki> Son_Goku: as you said before, alt kernels on ppc64el and aarch64 are probably fine too
<Son_Goku> yeah
<Son_Goku> those on rhel7 are based on 4.14 kernel
 * Chipaca goes afk for a another bit
<cachio> mvo,  personal-files test working in case I don't specify $HOME
<cachio> it is the only scenario where it failed
<kenvandine> zyga: the sound theme issue is fixed in candidate
<kenvandine> sparkiegeek: i'd like to promote gtk-common-themes to stable today
<kenvandine> sparkiegeek: any concerns with the store?
<roadmr> kenvandine: the store seems happy, I think you could go ahead. However, the earlier the better for us; in case things get wobbly, it's easier for us to handle when some in the store team still have most of the day ahead
<roadmr> kenvandine: which revision(s) are you planning on promoting? the ones currently on candidate?
<kenvandine> 818
<kenvandine> currently on candidate
<kenvandine> just need to finish a round of testing
<roadmr> awesome
 * cachio lunch
<mvo> 6156 is ready for a review now
<roadmr> kenvandine: hey a question, gtk-common-themes is *not* baked/shipped preinstalled on Ubuntu images, is it? (I see it's not on 18.04, maybe it is on 18.10?)
<kenvandine> it is
<kenvandine> also in 18.04
<kenvandine> there are snaps that use it which pulls it in
<kenvandine> all the seeded snaps in 18.04 use it
<kenvandine> roadmr: i'm really close to being ready to release it to stable
<roadmr> kenvandine: hm, I don't see it on a fresh 18.04, but I'm using the live cd image
<roadmr> kenvandine: awesome
<kenvandine> ah, it wasn't on the actual iso
<kenvandine> but everyone that installed 18.04 has gotten it installed since
<kenvandine> as the seeded snaps now mount content from it
<roadmr> kenvandine: yes, that's the question; because if so, I need to generate the deltas from whichever version is shipped in the ISO to the one you're about to release
<roadmr> kenvandine: but if it was never shipped on an iso then I don't need to do anything special; just let me know when it gets released so I can keep an eye on our metrics
<roadmr> when you release the new version, one of two things can happen:
<kenvandine> it was on the 18.10 iso
<roadmr> people who had the previous stable will get a delta (the store auto-generates these, yay)
<roadmr> and people who didn't have it get a full download anyway
<roadmr> kenvandine: oh! 18.10, then I should totally generate the delta. Do you by chance know which revision shipped with 18.10? fine if not, I can find out but it'll take me a few mins
<kenvandine> actually it would have also been on the 18.04.1 iso
<kenvandine> i do not know which revision
<roadmr> kenvandine: ok, not a problem, I can find all that out
<kenvandine> roadmr: i'm release to release it to stable, should i wait a few?
<roadmr> kenvandine: and while it's better to pre-generate the deltas, I can also gen them post-facto which is not a huge setback
<roadmr> kenvandine: if you're ready to release let's go ahead with tht
<kenvandine> roadmr: cool, releasing now
<roadmr> woohooo!
<roadmr> kenvandine: btw many thanks for giving us a heads-up, it allows us to be on the lookout for issues and provide a better experience to end users
<kenvandine> roadmr: no problem
<kenvandine> roadmr: done
<roadmr> yay :)
<roadmr> kenvandine: we found the revisions that shipped with 18.04.1 (319) and 18.10 (701) and built deltas from those to the one you just released. This way, people booting from those images will get a nice small delta
<jdstrand_> ogra: sure
<kenvandine> roadmr: awesome
<mvo> cachio: could you please look at 5845? the new tests are failing it seems
<cachio> mvo, sure
<cachio> mvo, I fixed the issue for personal-files
<cachio> I am testing it
<cachio> the errors on system-files seem to be real
<cachio> I manually tested and the snap cannot see under the dir /tmp/.testdir1
<mvo> cachio: thanks, well, could be because of /tmp being special, can you test if its also an issue with non-tmp?
<cachio> mvo, sure
<AuroraAvenue> e-what is the cli-instrn to install (pop) prnce of persia?
#snappy 2018-11-17
<AuroraAvenue> thats over a whole hour to get a response!
<AuroraAvenue> nothing else mattrrs.
<AuroraAvenue> https://archive.org/search.php?query=sony%20vaio&and[]=mediatype%3A%22software%22
<thiras> vscode has new version
<thiras> the package is behind. it throw notification at the bottom left. FYI maintainers
<vidal72[m]> is there a way to find all snaps which are based on core18?
#snappy 2019-11-11
 * Chipaca brb
<cachio> zyga, hey
<cachio> I have the mount-ns test failing on bionic
<cachio> I have a debug session opened
<cachio> it fails with the latest changes on bionic
<cachio> after I update the image
<Chipaca> cachio: it's 4am in zyga-land
<Chipaca> cachio: (he's in gmt-8)
<cachio> Chipaca, ahhhh
<cachio> Chipaca, I forgot :)
<cachio> thanks for remember me that
<Chipaca> cachio: you're the early bird, for once :)
<cachio> heheheh
<cachio> yesssss
<Chipaca> popey: you around?
<popey> hello
<Chipaca> popey: I'm going to a conference in a couple of weeks and they just asked me if I could take swag. Do you know who I could ask?
<popey> clan
<Chipaca> popey: ok, thanks
<popey> np
<ijohnson> hey oSoMoN, is there any way you can provide me access to old chromium snap versions? If you have access to 78.0.3904.70 as a snap so I can compare with the deb directly that would be great. (the snap currently is at 78.0.3904.97)
<oSoMoN> ijohnson, what do you need to test?
<ijohnson> I'm looking at startup performance, and I want to rule out different chromium versions "acting differently"
<ijohnson> but if you can say confidently that there's no real difference between those two versions I'm ok with that too
<oSoMoN> ijohnson, well the .97 snap is smaller than .70 by ~5MB, I trimmed down unused files, but IÂ don't expect that would make a noticeable difference
<oSoMoN> (in startup time, that is)
<ijohnson> oSoMoN: ok, so the only difference is in missing files? were those files being executed at all by the launcher script in .70?
<oSoMoN> no, they were unused files from stage packages
<ijohnson> okay, great thanks for clarifying. I will continue with my tests just using the deb on disco vs the snap
<oSoMoN> ijohnson, cool, please share your results on bug #1847069
<mup> Bug #1847069: [snap] Chromium snap starts slowly <snap> <chromium-browser (Ubuntu):Confirmed> <https://launchpad.net/bugs/1847069>
<ijohnson> oSoMoN, sure I can provide info there too, I was firstly just going to post on the snapcraft forum though, as a followup to https://forum.snapcraft.io/t/squashfs-performance-effect-on-snap-startup-time/13920
<ijohnson> might be after vancouver though FYI
<oSoMoN> yeah, the forum is fine too
 * cachio lunch
<zyga> Chipaca: morning
<zyga> I prepared some machines for you in case you needed that arm system
<zyga> cachio: my laptop is not working (atta way to start a sprint) but open a bug with the logs please
<zyga> It would help to know which packages changed
<zyga> Chipaca: let me know if you still need hardware access and Iâll get you an account as soon as I can use my computer again
<Chipaca> zyga: I don't need hardware access, thank you
<Chipaca> zyga: not this month anyway
<Chipaca> zyga: good morning! how's the jetlag?
<zyga> Chipaca: terrible, I didnât sleep at all
<Chipaca> zyga: :-(
<cachio> zyga, I'll do it
<cachio> once I am back from the doctor
 * cachio afk - doctor
 * Chipaca afk
<mup> PR snapcraft#2796 opened: meta: ensure Snap's `assumes` is initialized as a set <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2796>
<mup> PR snapcraft#2678 closed: cli: introduce --provider <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2678>
<mup> PR snapd#7728 opened: cmd: implement snap run --explain <Created by zyga> <https://github.com/snapcore/snapd/pull/7728>
 * zyga solicits feedback for snap run --explain https://www.irccloud.com/pastebin/R9gNjltq/
<mup> PR snapd#7729 opened: cmd: fix a pair of typos <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7729>
#snappy 2019-11-12
<mup> PR core#110 opened: Disable dynamic motd <Created by vorlonofportland> <https://github.com/snapcore/core/pull/110>
<mborzecki> morning
<mborzecki> zyga: https://www.redhat.com/sysadmin/fedora-31-control-group-v2 in case you missed it
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: a trivial PR to start the day: https://github.com/snapcore/snapd/pull/7729
<mup> PR #7729: cmd: fix a pair of typos <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7729>
<pstolowski> mborzecki: hey, sure
<mup> PR snapd#7729 closed: cmd: fix a pair of typos <Simple ð> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7729>
<mborzecki> got an errand to run, back in 2h or so
<Chipaca> brb, need to take my laptop apart (???)
<mborzecki> re
<zyga> Good morning
<mborzecki> zyga: hey
<mborzecki> imo we should provide a `snap debug volume-layout` command for dumping what snapd thinks is the layout described by the gadget.yaml file
<Chipaca> mborzecki: nice
<Chipaca> zyga: it's not even 5am there?!?
<zyga> Chipaca: it's 4:59 now
<zyga> Chipaca: I woke up at 3:33 (no kidding!)
<zyga> Chipaca: but hey, guess what
<zyga> *no roommate* :)
<ogra>  zyga dude ... melatonin ...
<zyga> ogra: it's better, yesterday I slept for 0 hours
<zyga> ogra: I just could not ... it's the first time this happened to me
<zyga> is the standup in an hour?
<zyga> yep, ok
<mborzecki> degville: hi, i've created a docs page about the gadget assets update process, can you take a look? https://forum.snapcraft.io/t/gadget-assets-update/14117
<degville> mborzecki: yes, of course - thanks for the heads-up!
<mborzecki> degville: thanks!
 * zyga goes for breakfast
<mup> PR snapd#7693 closed: interfaces/gpg-keys: Enable access to system gpg_agent socket <Created by Kedstar99> <Closed by Kedstar99> <https://github.com/snapcore/snapd/pull/7693>
<mup> PR snapcraft#2797 opened: meson plugin: add support for core20 <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2797>
 * cachio lunch
<mup> PR snapd#7704 closed: snap: extract printInstallHint in cmd_download.go <Simple ð> <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7704>
<pstolowski> zyga: the snap run --explain output looks super nice! (i looked at your snippet pasted earlier)
<om26er> Hi! Does Travis CI support building snaps using multipass ?
<mup> PR snapcraft#2796 closed: meta: ensure Snap's `assumes` is initialized as a set <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2796>
<mup> PR snapcraft#2795 closed: manifest: track and annotate `primed-stage-packages` <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2795>
<om26er> hey cjwatson, launchpad is having a hard time uploading my snap to store https://launchpad.net/~build.snapcraft.io/+snap/c7f9e9a2d76707f5da7a8175b964b834/+build/731604
<om26er> its built but lp is trying to uploaded for quite a few minutes
<roadmr> sergiusens: hey there! snapcraft is taking about 7 seconds to run (even something simple like snapcraft register), and this appears to have happened/regressed recently. Does this ring a bell?
<sergiusens> roadmr: snapcraft from stable has not changed in the past two months
<sergiusens> roadmr: but I did see it run slow yesterday
<roadmr> (it's causing our store test run to fail because the "registers names too fast" behavior is not triggered with snapcraft taking this long for each name heheh
<sergiusens> roadmr: oh, our integration tests were running just fine
<roadmr> interesting.. do you run the store tests too?
<roadmr> -vvv -b -s tests/integration/store -t .
<sergiusens> roadmr: here's one from yesterday https://travis-ci.org/snapcore/snapcraft/jobs/610814226
<roadmr> yay!
<roadmr> right, test_registrations_in_a_row_fail_if_too_fast is what's failing for us but it passed here
<roadmr> "snapcraft list" (does nothing, just prints an error) takes a full 4 seconds to run
<om26er> all 4 jobs are "uploading build" https://launchpad.net/~build.snapcraft.io/+snap/c7f9e9a2d76707f5da7a8175b964b834 and I don't have admin permissions to force rebuild
<om26er> :-(
 * cachio afk
<roadmr> hey folks - inside an lxc container snaps mounted with snapfuse are significantly slower than those mounted using squashfuse; but the only way I found to make a snap be mounted with squashfuse is by snap downloading and installing it --dangerously, which is icky. Is there a way to make them use squashfuse always?
<zyga> roadmr: I think that was recently fixed
<zyga> roadmr: ask mvo about it please
 * cachio eod
<roadmr> zyga: will do! we sort of fixed it by installing squashfuse *before* installing any snaps in the container, then they use squashfuse which is 3x faster for some reason
<zyga> roadmr: there are two builds of squashfuse
<zyga> roadmr: one is fast other is slow
<zyga> roadmr: it's a build time option
<zyga> roadmr: we flipped the switch on one of the builds
<roadmr> zyga: ahh I see :)
<mup> PR snapd#7730 opened: Fix typo in spread suite summary <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/7730>
#snappy 2019-11-13
<mborzecki> morning
<mborzecki> re
<mborzecki> hate the morning traffic
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7702 ? maybe we could land it
<mup> PR #7702: tests: adding fedora 31 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7702>
<pstolowski> mborzecki: sure, will do
<mborzecki> pstolowski: thanks!
<mborzecki> quick errand, brb
<pstolowski> hmm something is not right with tumbleweed
<mborzecki> re
<mborzecki> pstolowski: got logs?
<pstolowski> mborzecki: https://paste.ubuntu.com/p/PkdyMvHYjT/
<pstolowski> home/gopath/src/github.com/snapcore/snapd/tests/lib/quiet.sh: line 30:   993 Segmentation fault      (core dumped) "$@" &> "$tf"
<mborzecki> duh, zypper segfaulted?
<pstolowski> mborzecki: happened on 2 independent PRs and now when run manually
<pstolowski> although i have no proof it was the same error; but they were definaltely tumbleweed prepare failures
<om26er> popey ping! re: building close-source project's snaps with launchpad, did you get a chance to make a video for that ?
<om26er> or popey_ ^
<mup> PR snapd#7731 opened: usersession/userd: add "apt" to the white list of URL schemes handled by xdg-open (LP: #1776873) <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/7731>
<zyga> o/
<zyga> good morning
<pstolowski> hey zyga!
<zyga> hey guys, how's the day going?
<zyga> mborzecki: can we chat here
<mborzecki> zyga: call would be quicker ;) unless you're in pyjamas or whatnot
<zyga> mborzecki: yes but yes :)
<zyga> ok, let's use meet
<zyga> https://meet.google.com/mym-ngpj-ynj
 * zyga goes for breakfast
<ijohnson> morning folks
<zyga> hey ijohnson
<ijohnson> morning zyga
<roadmr> zyga: no breakfast yet ð¢
<roadmr> (unless you go out?)
<zyga> roadmr: yeah, I had a call with my family; I think brekfast starts later
<zyga> oh
<zyga> shiny
<zyga> https://www.apple.com/macbook-pro-16/
<roadmr> zyga: yep need to wait 27 min :)
<roadmr> zyga: haha magic keyboard ?? I anticipate the "yes, magic - press a key, who knows what'll come out on screen ð¤£  " memes
 * zyga sells his 15" 
<roadmr> ð¤
<zyga> 64GB ram maximum, wow
<zyga> pstolowski: ^
<pstolowski> zyga: uhm, your predictions were right
<zyga> pstolowski: I will call it the vim macbook
<zyga> pstolowski: it has physical escape key :)
<zyga> pstolowski: but geez, if the keyboard is now "regular" this is a super shiny machine
<zyga> pstolowski: 8TB SSD max, 64GB RAM max
<pstolowski> zyga: wooot, esc? no way :D
<zyga> pstolowski: (obviously $$$$ but still)
<zyga> pstolowski: yep, physical escape key + rest of touchbar as before
<zyga> pstolowski: but the base model is not unlike other laptops from dell / lenovo
<zyga> pstolowski: 11-14K PLN for a really nice setup
<pstolowski> zyga: i see it replaced 15' in the store, only 13 & 16 now
<zyga> Yes, it seems so
<zyga> I wonder what the GPU is
<pstolowski> zyga: huh, going with 32GB and ssd >1TB makes the price skyrocket
<mborzecki> cachio: is there a more recent tumbleweed image that we could use by any chance?
<cachio> mborzecki, so, we are creating tumbleweed based on the leap 15.0
<pstolowski> cachio: re install slowness, please grab 'snap debug timings <change id>'
<cachio> mborzecki, and then we update it weekly
<cachio> pstolowski, sure
<cachio> mborzecki, which is the problem with the current one?
<cachio> perhaps we could create a new one
<mborzecki> cachio: this failed for instance https://api.travis-ci.org/v3/job/611337121/log.txt
<mborzecki> cachio: this is the relevant part https://paste.ubuntu.com/p/VGYvRc2wG4/
<mborzecki> cachio: looks like there's a segfault in zypper (?)
<mborzecki> cachio: although when i run a shell manually, i don't seem to be able to reproduce it with the same zypper command on a clean image
<cachio> mborzecki, mborzecki I could create a new one based on leap 15.1 latest image
<cachio> mborzecki, not sure if it is gonna help
<mborzecki> cachio: do you create a new image from scratch each time, or do you rather keep updating the same image?
 * ijohnson drools over the new macbook
<cachio> I initially created a tumbleweed image from leap 15.0
<cachio> this is called base image
<cachio> then every week I update that and install all the test dependencies
<cachio> in a new image
<cachio> the final image
<cachio> this is the image we use for snapd
<cachio> mborzecki, sometimes I create new base images or update the base image
<cachio> mborzecki, what I see is that opensuse-cloud added an image for leap 15.1 that we could use
<zyga> pstolowski: the important part is what the baseline has
<zyga> No more 256GB 8GB model
<zyga> It is a great upgrade!
<mborzecki> cachio: can you maybe try and update the current image to the latest TW snapshot?
<cachio> mborzecki, sure
<mborzecki> cachio: hmm looks like we're using 20191109 already
 * ijohnson stops drooling after looking at prices and gets back to work
<cachio> mborzecki, yes
<cachio> mborzecki, I updated 2 days ago
<pstolowski> zyga: for the gpu it apparently has AMD Radeon Pro 5300M and 5600M with 4GB DDR6
<mborzecki> zyga: looks like tehre's some updates, i think it's worth trying the latest snapshot anyway
<mborzecki> pstolowski: still i9 cpu booo
<mborzecki> pstolowski: zyga: wonder is i9 is vulnerable https://mdsattacks.com/#ridl-ng
<zyga> pstolowski: not sure how that GPU compares to consumer models
<mborzecki> zyga: i'm sure it's not as hot
<zyga> pstolowski: i9 -> no zen 2nd gen mobile yet, also very unlikely apple would move to amd on a laptop still
<zyga> mborzecki: well, apple store is 200 m away
<zyga> I'll check it out :)
<mborzecki> hahah
<pstolowski> zyga: :)
<pstolowski> i can sense zyga returning from the sprint with a new laptop ;)
<zyga> pstolowski: never, I want to get it back home as proper purchase with vat and stuff
<zyga> pstolowski: here it'd be just more complex
<mborzecki> zyga: for sure it's gonna hit the new split payment regulations :)
<zyga> mborzecki: mhm
<zyga> mborzecki: I really really wonder how that works now
<pstolowski> yeah it's confusing
<zyga> I cannot deny that it is tempting though
<zyga> it looks like great piece of hardware
<pstolowski> degville: hey, i think https://snapcraft.io/docs/hotplug-support needs a minor update, the feature is still behind experimental flag and not made widely available with 2.39 as indicated there
<cachio> pstolowski, https://paste.ubuntu.com/p/Y6TY4WMYXG/
<pstolowski> zyga: my santa is not reach enough ;). maybe next year..
<degville> pstolowski: thanks for letting me know -I'll update it now.
<pstolowski> *rich
<zyga> pstolowski: my santa is the same, it would depend on selling the 15" first
<cachio> pstolowski, id: 25
<cachio> and 24
<pstolowski> cachio: thanks, looking
<pstolowski> cachio: it takes 1.5s on my local VM. i'm not sure there is anything wrong there. great chunk of that is seccomp profiles compiler. note this snap has 9 apps in it
<pstolowski> cachio: not sure why copy-snap-data took 1.7s though. was there any old data?
<cachio> pstolowski, yes, but it takes more than 2 seconds
<cachio> seems to be so much compared with the other times
<pstolowski> cachio: what do you mean by other times?
<cachio> pstolowski, compared with the other steps and with apparmor
<pstolowski> cachio: ah, sure. yes, seccomp compiler got very slow a few months ago with a new version
<cachio> apparmor= 725ms seccomp=2201ms
<pstolowski> cachio: a few weeks ago i presented some tests on the standup, seccomp got a few times slower afair
<pstolowski> cachio: so yes, setup-profiles is one of the most expensive tasks, a few seconds is normal, unfortunately
<cachio> pstolowski, https://paste.ubuntu.com/p/yYnDCPpm7m/
<pstolowski> degville: thanks for updating hotplug doc!
<cachio> in this case I installed over
<degville> pstolowski: np!
<cachio> and didnt setup seccomp
<cachio> but did the setup for apparmor
<cachio> pstolowski, do you know why?
<pstolowski> cachio: seccomp backend computes new profiles and compares them with what's already on the disk, if there is no change then they are not reloaded. same logic applies to apparmor, i suppose they were reloaded because they have snap paths (specific to snap revision) in them
<cachio> pstolowski, still weird that if it computes the new profiles it makes that super fast
<cachio> and also it does not appear in the timings
<pstolowski> cachio: we don't save timings if something is faster than 5ms
<cachio> pstolowski, we have some stuff with 4ms
<pstolowski> cachio: computing profiles is fast, loading them with seccomp profiles is slow
<cachio> pstolowski, ahh
<pstolowski> cachio: sorry, i wasn't precise: we will still record times of individual tasks (like 4ms with post refresh hook), but we don't store detailed timing breakdown (nested timings) underneath
<cachio> pstolowski, ah, ok
<cachio> pstolowski, thanks for the explanation
<pstolowski> cachio: if we compute a profile and find it's the same, we don't invoke seccomp or apparmor parser at all
<cachio> pstolowski, perhaps we could see why we are calling apparmot
<cachio> it I am installing the same snap twice
<pstolowski> cachio: but it ends up with different revision, no?
<cachio> pstolowski, ye
<cachio> s
<pstolowski> cachio: so, paths are differnt in the aa profiles
<cachio> pstolowski, ah, ok
<cachio> makes sense
<cachio> pstolowski, so seccomp takes more time depending on the number of apps the snap has?
<cachio> pstolowski, for example the snap test-snapd-framebuffer with 2 apps and 1 interface takes 493ms on seccomp
<cachio> and 0ms to copy snap data
<cachio> pstolowski, and first time I saw: 1791ms            -  Copy snap "test-snapd-tools" data
<cachio> perhaps we could update the snap to make it faster to be installed
<cachio> because it is being used on many tests
<pstolowski> cachio: what is the data of this snap? it seems we're copying data over to the new revision in the test, maybe it makes no sense
<pstolowski> cachio: i mean, maybe we should simply rm -rf .. on snap data to avoid copying
<cachio> pstolowski, I think in the test there is something weird
<cachio> I ran the samein the pi3 and got 2212ms            -    setup security backend "seccomp" for snap "test-snapd-tools-core18"
<cachio> seccom takes same time on pi3 than in the vm
<cachio> hhehe
<cachio> pstolowski, take a look to this please https://paste.ubuntu.com/p/MKD5MCTtxn/
<cachio> pstolowski, do we use different seccomps for core than classic?
<pstolowski> cachio: is it a fast vm?
<cachio> pstolowski, it is same we use for tests on google
<cachio> pstolowski, but it should be faster then the pi3
<cachio> in fact in the pi3 apparmor takes more than 2 seoncds
<cachio> compared with 700ms on the vm
<cachio> but seccomp is the same time in both
<pstolowski> cachio: i see. i don't know why. this the time of seccomp compiler itself. maybe mborzecki or zyga know what is it doing that explains no difference on pi3 vs vm
<mborzecki> pstolowski:  hm? why it's so slow?
<cachio> mborzecki, well, in pi3 is slow as in a vm
<pstolowski> mborzecki: why it takes same time on pi3 vs vm
<cachio> mborzecki, https://paste.ubuntu.com/p/MKD5MCTtxn/
<pstolowski> mborzecki: where it should in theory be faster on vm
<cachio> pstolowski, but apparmor is much faster in the vm
<cachio> mborzecki, ~
<mborzecki> pstolowski: iirc it's cpu bound and single threaded
<pstolowski> mborzecki: aah, here you go
<cachio> mborzecki, ahh, that explains it
<cachio> mborzecki, pstolowski thanks for the explanations
<mborzecki> cachio: pstolowski: we could run the compiler in parallel, but you'd only benefit when there's more than 1 app
<mborzecki> setting up security backends in parallel would give more gains i believe
<cachio> mborzecki, for testing that should be really usefull
<pstolowski> yep.. test-snapd-tools has 9 apps ;)
<cachio> is it possible to so it by configuration?
<pstolowski> cachio: no, needs coding
<cachio> pstolowski, :(
<zyga> cachio, pstolowski: snap-seccomp needs a cache layer
<zyga> virtually all snaps use the same seccomp profile in the end
<mborzecki> pstolowski: cachio: i had the patches somewhere, iirc i pointed pawel to the commits at some point
<zyga> there is far less variability compared to apparmor
<mborzecki> cachio: if you feel like it i can try to revive the branch with paralell compilation of seccomp profiles and we can try to benchmark that
<mborzecki> brb
<cachio> mborzecki, that should be really nice
<cachio> on tests we have many snaps with more than 1 app and reviewing times I see most of the time it is installing snaps
<cachio> and most of that time it is creating seccomp profiles
<cachio> mborzecki, if you have a branch I could try it
<cachio> and see the time improvement
<mborzecki> ijohnson: hi, still around?
<ijohnson> hey mborzecki
<mup> PR snapd#7732 opened: [PoC] many: extracted snaps mode <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7732>
<mborzecki> ijohnson: opened a branch for you ^^
<ijohnson> thanks mborzecki, will give it a spin
<mborzecki> ijohnson: i think it should mostly work, but you may see some issues with layouts, iirc some logic depends on statfs()ing some paths and observing squashfs magic there
<mborzecki> ijohnson: and you'll need to set SNAPD_EXTRACT_SNAPS in your environment
<ijohnson> right I see that from the patch
<ijohnson> that's interesting about layouts needing to introspect the squashfs
<ijohnson> I'll see what I can find in any case
<mborzecki> ijohnson: if you see bugs or issues feel free to patch it ofc :P
<ijohnson> sounds good
<mborzecki> ijohnson: thanks! really looking forward to the numbers, i suppose next thing we could try afterwards is repacking the squashfs locally
<ijohnson> yeah I don't want to get too far into repacking without Samuele's blessing however :-)
<mborzecki> ijohnson: yup, agreed, this should give us some insight though
<ijohnson> indeed
<mborzecki> all right, wrapping it up, till tomorrow
<mup> PR snapd#7733 opened: tests: disable nova from install-snaps test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7733>
<mup> PR snapcraft#2786 closed: cli: add support for 'http-proxy' and 'https-proxy' parameters <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2786>
<mup> PR snapcraft#2769 closed: extensions: skip icon cache creation for theme and runtime snaps  <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2769>
#snappy 2019-11-14
<mborzecki> morning
<pstolowski> morning, hey mborzecki
<mborzecki> pstolowski:  hey
<pstolowski> mborzecki: should we disable opensuse tests for now?
<mborzecki> pstolowski: still failing?
<pstolowski> mborzecki: checkingm restarted one of the failing PRs
<pstolowski> *checking
<mborzecki> pstolowski: looks like it was timeouting a bit too
<mborzecki> anyways, restarted #7702 and if it fails again on tw, we can switch it to manual
<mup> PR #7702: tests: adding fedora 31 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7702>
<popey> https://forum.snapcraft.io/t/cant-install-snaps-in-clean-16-04-lxd-container/14140
<popey> this seems serious
<popey> probably due to snapd being super old in 16.04 and not supporting something new in latest core?
<mborzecki> ExecMount=/bin/mount /var/lib/snapd/snaps/core_8039.snap /snap/core/8039 -t squashfs -o nodev,ro (code=exited, status=32)
<mborzecki> the error is pretty generic, according to manpage it's  '32     mount failure'
<popey> it's very easy to reproduce
<mborzecki> if mount cannot mount then we're in deep trouble
<mborzecki> popey: what was the host os?
<ogra> IIRC there couldnt be a hard dependency on squashfuse in 16.04
<ogra> you need to install it manually
<popey> no ogra
<popey> this worked up until recently
<popey> it's a cron job I run every day
<popey> and today it failed
<ogra> oh, ok
<popey> mborzecki: 19.10
<mborzecki> popey: was lxd installed from snaps too?
<popey> on the host, yes, stable
<mborzecki> popey: ok, trying it out now
<ogra> can you try the mount command manually ? that pwerhaps gets you more output
<mborzecki> heh, can't start the container for some reason, and no logfile either
<ogra> https://paste.ubuntu.com/p/nNmgJf6Ndf/
<ogra> works for me
<ogra> (on a xenial host ... but not on recent kernel (havent rebooted for a while)
<ogra> )
<mborzecki> lxc launch ubuntu:16.04 complains that no image was found, but images:ubuntu/xenial seems to work
<mup> PR snapd#7734 opened: spread: do not explain errors <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7734>
<mborzecki> pstolowski: super trivial ^
<mup> PR snapd#7735 opened: spread: move openSUSE Tumbleweed to unstable systems <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7735>
<mup> PR snapd#7736 opened: tests/main/system-usernames: Amazon Linux 2 comes with libseccomp 2.4.1 now <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7736>
<mborzecki> so in my vm, once i launched the container, snapd doesn't even start
<mborzecki> pstolowski: hm looks like we'll need to merge 7736 and 7735 into one PR
<pstolowski> mborzecki: hah, right
<mup> PR snapd#7736 closed: tests/main/system-usernames: Amazon Linux 2 comes with libseccomp 2.4.1 now <Simple ð> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7736>
<mborzecki> popey: btw. eoan is on 5.3 kernel? not sure why it's showing 5.0 in snap version in the output you pasted
<mborzecki> and once i resized the vm image things work well now
<popey> mborzecki: that was inside the container
<popey> oh, you're right
<popey> my system has been upgraded from 18.04, maybe I am missing a package
<popey> something may have gone screwy in my upgrade, installing linux-image-generic now pulls in 5.3, gonna reboot and test again
<popey> that didn't help
<cachio> mborzecki, hey
<mborzecki> cachio: hey
<cachio> left a coment in the PR #7735
<mup> PR #7735: spread, tests: openSUSE Tumbleweed to unstable systems, update system-usernames on Amazon Linux 2 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7735>
<cachio> yesterday I updated the image
<cachio> but I think it is the same
<mborzecki> cachio: heh, that's unfortunate
<mborzecki> popey: is the 16.04 lxd image something you created in the past and keep updating? the one i pulled today had snapd 2.40 in it, rather than 2.27
<popey> i guess. I dunno how to update it
<mborzecki> cachio: the problem with system-usernames and opensuse 15.1 is differnt, looks like there's no daemon user at all
<mborzecki> popey: so snapfuse is not in the contained, but do you have squashfuse there at least?
<popey> no
<popey> i have removed lxd and am re-installing to see if i get a new image
<cachio> mborzecki, it could be because yesterday I imported the new opensuse leap 15.1 image
<cachio> from opensuse project
<cachio> mborzecki, I can revert that image if it is a problem
<mborzecki> cachio: is the daemon:daemon user/group added manually when you prepare the image?
<cachio> mborzecki, nottrobin
<cachio> no
<mborzecki> popey: still, makes me wonder how it worked before, since loopback isn't avaialbe inside the container and none of the fuse squashfs handlers are avaialble
<cachio> mborzecki, I have a debug session opened
<cachio> mborzecki, do you want to take a look?
<mborzecki> cachio: https://doc.opensuse.org/documentation/leap/startup/single-html/book.opensuse.startup/index.html#sec-yast-userman-defaultsystemusers lists bin, daemon as some default users added for legacy apps
<mborzecki> cachio: but i see neither in /etc/passwd
<cachio> mborzecki, I am checking that in the base image that I got from opensuse project
<cachio> mborzecki, in the mew image from opensuse cloud it is not included neither
<mborzecki> cachio: w8, so we had 15.1 image before, but the test broke only after the last update, is that what happened?
<cachio> mborzecki, yes
<cachio> I iincludede the new image provided by opensuse cloud
<mborzecki> cachio: then we should revert to the last good one and report a bug to whoever publishes the build
<mborzecki> s
<cachio> mborzecki, sure
<cachio> mborzecki, reverted
<cachio> and restarted tests
<cachio> mborzecki, that should fix the issue
<mborzecki> cachio: thanks
<mborzecki> cachio: downloaded the latest 15.1 kvm image from opensuse.org and there's no bin or daemon users either
<cachio> mborzecki, well, perhaps we should update our tests in that case
<mborzecki> cachio: i mean, if it's the case, then the system-users feature isn't universal anymore and probably needs extra tweaks to be documented
<cachio> mborzecki, agree
<cachio> I'll research a bit more about this
<pokk> Noob question, how do I actually add a group to my user? usermod -a -G isn't working since read-only system
<ogra> pokk, you dont ...
<ogra> (assuming you speak about ubuntu core)
<ogra> what do you try to do ?
<ogra> (why do you think you need the group=
<ogra> )
<gitesh> hi
<spinningcat> is it about snap? Ubuntu new toy
<ogra> this channel is for snap development, snapd development and ubuntu-core
<mup> PR snapd#7735 closed: spread, tests: openSUSE Tumbleweed to unstable systems, update system-usernames on Amazon Linux 2 <Simple ð> <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7735>
<ogra> (also ... not actually new, snap packages exist since 2014)
<gitesh> what is this channel about?
<ogra> (nor ubuntu ... snaps can be installed on a ton of different distros)
<gitesh> ok snap development ok, i thought you are a bot
<ogra> heh ... said the person that joins and leaves the channel between two lines
<ogra> looks like jean claude van damme is busy on freenode again ...
<ogra> ... doing net-splits ...
<zyga> yawn
<zyga> good morning
<zyga> how are things?
<ogra> how's the sleep situation ?
<zyga> ogra: I totally fall asleep around 9PM
<zyga> ogra: and then wake up 3-4AM
<zyga> so... okay I guess
<mborzecki> bug triage duty is great when LP keeps timing out ;)
<pstolowski> hey zyga!
<zyga> hey :)
<zyga> how are you doing?
<pstolowski> mvo can't sleep either i suppose, is active in the standup doc ;)
<zyga> it's 5:48, I wish I could sleep normally
<zyga> haha
<zyga> yeah
<zyga> it's the same for everyone here
<pstolowski> zyga: it's going fine here. i'm warming up for the new macbook.... ;)
<pstolowski> zyga: but not this year
<zyga> yeah
<zyga> I will first try to sell my 2018
<zyga> if that succeeds I'll go for it
<zyga> if not I'll stick around for longer
<pstolowski> zyga: just realized it gets much more attractive with VAT return :)
<zyga> pstolowski: yeah
<zyga> pstolowski: if you go to an apple reseller they almost always get you better price too
<zyga> pstolowski: just start talking to them
<pstolowski> i keep forgetting about that.. it's significant chunk in this case in particular
<zyga> pstolowski: it's not the stock price in the end
<zyga> pstolowski: vat, income tax, extra cut if you negotiate for a sec
<zyga> pstolowski: and that adds up
<zyga> pstolowski: I really just don't want two laptops at once :)
<zyga> pstolowski: I was thinking and the 6 core, 1TB, 32GB model is what I would look at most likely
<pstolowski> zyga: yeah that's my problem too... too much hardware already at home
<zyga> pstolowski: probably with the GPU upgrade since it's cheap but significant
<zyga> pstolowski: I want to play some music on it because apparently the speaker upgrade is incredible (starting from a already fantastic quality of 15")
<zyga> pstolowski: there are 6 speakers in that thing now
<zyga> I was out for a walk last night but went to the seaside instead
<pstolowski> zyga: yeah, 1TB + 32GB would be my setup too. i don't care about GPU too much
<zyga> pstolowski: the GPU is just $100 but it's not something you can ever upgrade
<pstolowski> zyga: yes, i watched a review, speakers are super good apparently
<zyga> I'd get it because it's useful to have vram for VMs as well as apps on the host
<zyga> I don't remember but I think the extra $100 gets you 8GB of vram
<pstolowski> zyga: ah, if you get more VRAM with that.. i though VRAM was fixed, just two chipsets to choose from
<zyga> I could be wrong, let's check
<pstolowski> then yes, by all means
<zyga> oh, there are 3 GPU tiers
<zyga> that's ... weird
<zyga> I checked on the website in the US
<zyga> and I saw two
<zyga> but on my phone with the apple store app I see three (tied to my eu account)
<zyga> 4GB 5300M, 4GB 5500M and 8GB 5500M
<zyga> anyway
<zyga> that's all theoretical
<mborzecki> zyga: you'll still end up carrying x240 :)
<zyga> mborzecki: yeah but that's different
<zyga> mborzecki: I would replace my 15" with the 16" because at home it's just awesome to use
<zyga> mborzecki: it's really my most loved device over the years
<zyga> mborzecki: despite the issues actually
<zyga> mborzecki: x240 is something I can comfortably throw on the xray scanner at the airport
<mborzecki> idk, i have no feelings for devices i own ;)
<pstolowski> haha
<zyga> mborzecki: and use for one week without missing things I like normally
<zyga> mborzecki: you say that because you are missing out ;-)
<zyga> haha
<zyga> ;D
<pstolowski> that!
 * zyga is totally silly now
<mborzecki> surprised they don't treat thinkpads as possible weapons
<zyga> pstolowski: did you notice the new github app for ios?
<zyga> it's invite only for now but it is coming
<pstolowski> zyga: nope, for ios?
<zyga> yep
<zyga> android later as well
<pstolowski> hmm what is it good for?
<zyga> everything normal github is good for but tailored for smaller screen
<pstolowski> code reviews?
<zyga> yes
<zyga> they announced it yesterday, hold on
<zyga> pstolowski: random google https://techcrunch.com/2019/11/13/github-launches-a-mobile-app-smarter-notifications-and-improved-code-search/
<zyga> but there are pics there I didn't see before
<pstolowski> standup
<zyga> enjoy
<zyga> I'll get breakfast now
<mborzecki> any idea if gnomne-contacts used to be a classic snap?
<zyga> mborzecki: is it about that bug that was reported recently?
<mborzecki> zyga: https://bugs.launchpad.net/snapd/+bug/1852355
<zyga> mborzecki: I'll try to find out, I encouraged the reporter to file it
<mup> Bug #1852355: Available snap not refreshed to ("cannot update "gnome-contacts": snap "gnome-contacts" is not a classic confined snap") <snapd:New> <https://launchpad.net/bugs/1852355>
<mborzecki> i recall we did some back and forth changes around that are
<zyga> yeah, perhaps something in the state was set so that we would never upgrade
<zyga> but
<zyga> but
<zyga> it was only during automatic refresh
<zyga> a manual refresh succeeded
<zyga> so it's a bug for sure
<mborzecki> duh, we're missing some mocking in gadget remodel unit tests, and spend time waiting for serial to be requested :/
<mborzecki> added mocking and for instance TestRemodelSwitchGadgetTrack execution time went from 1.3s down to 0.083s
<ijohnson> zyga that new github app looks really cool
<ijohnson> I'm excited for the new notifications stuff though
<ijohnson> that will be nice to filter it more
<ijohnson> mborzecki: re your comments on #7431, the reason I went with `st.Unlock(); defer st.Lock()`, etc. is because Samuele showed me that during a different PR, and actually I am starting to like that kind of code flow because it means when someone else goes to refactor this they don't need to be as careful about returning when st is unlocked because they can return and state is still ok
<mup> PR #7431: overlord/snapstate: don't re-enable and start disabled services on refresh, etc <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7431>
<ijohnson> but if you like I can still refactor to use your suggestion
<mborzecki> ijohnson: no, it's ok, don't like much that defers keep piling and we end up locking/unlocking (potentially a number of times) inside the function epilogue, but i suppose it's not a big deal
<ijohnson> mborzecki: yes I think it does lead to a bit of thrashing after the function returns but it reads cleanly
<mborzecki> ijohnson: right, let's got with easier to read code for now ;)
<ijohnson> mborzecki: https://xkcd.com/1691/
<mborzecki> hahah
 * ijohnson relocates back home
<pokk> ogra: sorry, other things came in between. I'd have prefered to be able to run docker without sudo, it's not a big thing.
 * cachio lunch
<ogra> pokk, well, you can use the --extrausers option to adduser and friends, that creates additional groups and users in a passwd db under /var/lib/extrausers ...
<pokk> ogra: but I take it you'd argue it's a very bad idea?
<ogra> (which is fine for development etc ... just not really something i'D encourage in a production system for an IoT device)
<ogra> it is fine if you use the install as build machine etc ... and typically use ssh logins and the like ...
<pokk> ogra: no no :) that I definitly can agree with. This is mainly me playing around with my hmoelab proxmox/ubuntu core
<ogra> most IoT gateways, routers, APs and digital signage kiosks wont actually need a user though
<pokk> seemed like core would be a good small vm to run docker in, so I'm trying that out
<ogra> while docker will surely work, i'd recommend lxd instead ... thats way better integrated (and you can run snaps inside the containers ... thats tricky with docker)
<pokk> lxd doesn't seem ideal for running many smaller things. I'll move things like dbs to lxd tho
<pstolowski> cachio: any idea what that means: Nov 14 13:35:11 arch google_clock_skew_daemon[615]: pkg_resources.DistributionNotFound: The 'google-compute-engine==20190801.0' distribution was not found and is required by the application ?
<pstolowski> cachio: just got such spread test failure
<pstolowski> cachio: full log: https://api.travis-ci.org/v3/job/611861148/log.txt
<cachio> pstolowski, checking
<cachio> pstolowski, seems to be a problem with the package google-compute-engine
<cachio> pstolowski, I think it was going to be updated
<cachio> pstolowski, I am running that to see if I can fix it
<cachio> I'll tell you once I have more info
<pstolowski> cachio: thanks!
<cachio> pstolowski, np
<pstolowski> not a happy week for spread tests...
<cachio> pstolowski, hehehee
<cachio> pstolowski is really weird the error, I'll try to update the image to see if that fix the issue
<cachio> pstolowski|afk, I tried to update arch
<cachio> but I am getting other problems with apparmor package
<cachio> pstolowski|afk, images are having a bad week too
<mup> PR snapcraft#2798 opened: cli: improve the remote-build upload messaging <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2798>
<mup> PR snapcraft#2791 closed: introduce bind-ssh support <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2791>
<mup> PR snapcraft#2798 closed: cli: improve the remote-build upload messaging <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2798>
<mup> PR snapcraft#2799 opened: Plainbox test updates <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2799>
#snappy 2019-11-15
<mup> PR snapcraft#2799 closed: Plainbox test updates <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2799>
<mborzecki> morning
<mup> PR snapd#7737 opened: overlord: mock device serial in gadget remodel unit tests <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7737>
<mborzecki> quick errand, back in 30
<mborzecki> and our arch images need an update, followed by a rebuild of google-compute-engine packages:/
<mborzecki> or, actually a longer errand, back in 1h or so
<pstolowski> morning
<mborzecki> turns out i need to take a day off, because it's so fucking complicated to sign a contract with a utility company
<mup> PR snapd#7738 opened: overlord/state: panic in MarkEdge() if task is nil <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7738>
<pstolowski> cachio: hey
<cachio> pstolowski, hey
<pstolowski> cachio: you probably know from maciej, but arch images need updating. everything fails still :(
<cachio> pstolowski, yes
<cachio> I am on that https://paste.ubuntu.com/p/BCFGw4hSVK/
<cachio> I am manually removing some dependencies to fix it
<cachio> but the problem is on the archive
<cachio> pstolowski, I0ll try to regenerate all the GPG keys
<popey> Anyone got a fedora 31 system handy? Do graphical desktop applications work fine there, or has the new cgroups stuff broken them?
<cachio> pstolowski, seens to work
<cachio> I'll create a new arch image in that case
<popey> I am sat with a developer who has a snap which works on ubuntu but breaks on fedora 31
<popey> WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
<popey> Fontconfig warning: FcPattern object weight does not accept value [0 210)
<popey> I am trying to reproduce it but don't have a fedora 31 image handy, so need to get the iso and setup. wondered if anyone had one handy.
<ogra> popey, really smells more like an issue with the fontconfig db (as we had it between xenial and bionic before)
<ogra> iirc the cache format has changed between two fontconfig versions
<ogra> ... in incompatible ways
<pstolowski> ogra: that's right but we now support both fontconfig versions, at least on ubuntu
<pstolowski> popey: i don't have but i can install later today, i was meaning to install fc31 anyway
<popey> I'm installing now too
<ogra> pstolowski, and we are indeed sure there are only two formats so this is sufficient :)
<pstolowski> ogra: heh, no... that fc major version change was the one we were aware of. the only problem with that was very slow startup because fc decided to regenerate its cache. anyway, i'll see if i can repro
<pstolowski> just finished fc31 installation
<popey> I have asked the developer to put a thread on the forum. We got the snap working - by running it under gdb once, then running again without gdb. running under gdb seemed to "unbreak" the snap, oddly
<popey> https://forum.snapcraft.io/t/toggldesktop-only-starts-in-fedora-31-after-running-snap-run-gdb/14165
<popey> very odd.
<pstolowski> popey: i'll try that snap in a sec. just got snapd on fc31
<pstolowski> popey: snap run --gdb ... runs things as root
<popey> yeah, but it seemed odd to add symlinks in the user home - I suspect that's being done by the desktop launchers
<popey> once you do that though, it is possible to run as the regular user, not root
<popey> thanks pstolowski
<popey> Also, another question. Why does "snap remove foo" not kill all processes of foo on the way to remove it? I removed the app while it was running and it was left broken on my desktop - since half was removed.
<popey> Is this partly due to the new feature of waiting for the application to close before updates happen.
<cachio> pstolowski, there is a new image
<pstolowski> cachio: great, ty!
<cachio> pstolowski, I am testing it
<cachio> give me 10 minutes to validate if it works
<pstolowski> popey: i think so (although zyga knows the details better). i think we need more awareness re app lifecycle
<pstolowski> popey: i have different problem with this snap: https://usercontent.irccloud-cdn.com/file/y8cHT2xM/Zrzut%20ekranu%202019-11-15%20o%2014.11.16.png
<pstolowski> popey: oh sorry, wrong screenshot
<pstolowski> https://usercontent.irccloud-cdn.com/file/B4SLxj5q/Zrzut%20ekranu%202019-11-15%20o%2014.18.12.png
<pstolowski> popey: this ^
<popey> can you try in an x session
<popey> or..
<popey> QT_QPA_PLATFORM=xcb toggldesktop
<cachio> pstolowski, is not working
<pstolowski> popey: i've just re-logged into X. works
<pstolowski> https://usercontent.irccloud-cdn.com/file/sf0HH8iF/Zrzut%20ekranu%202019-11-15%20o%2014.22.49.png
<popey> the application "just works"?
<pstolowski> popey: ^
<pstolowski> popey: could it be he has some cruft in fontconfig, e.g upgraded from old fedora?
<pstolowski> *fontconfig cache
<pstolowski> popey: i'm responding on the forum, let's carry it on there
<popey> ok
<ogra> ask him to create a fresh user temporary ...
<pstolowski> cachio: not good... what's happening?
<cachio> pstolowski, the gce package is not working properly
<cachio> and it is a hard dependency
<cachio> }I'll move arch to unstable untilo I can fix it
<mup> PR snapd#7739 opened: tests: moving arch linux to unstable <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7739>
<cachio> pstolowski, #7739
<mup> PR #7739: tests: moving arch linux to unstable <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7739>
<oSoMoN> jdstrand, hey, I'm at a workshop helping people snap their applications, and there's a new snap in the store that requires manual review because it declares a dbus slot (it's a Gtk application), can you ack that? the snap is "rust-workshop-example"
 * cachio lunnch
<mup> PR snapd#7740 opened: overlord/ifacestate: report bad plug/slots with warnings on snap install <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7740>
<pstolowski> cachio: #7739 exploded on spread shellcheck, wth
<mup> PR #7739: tests: moving arch linux to unstable <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7739>
<mup> PR snapcraft#2800 opened: introduce `--apt-mirror` build provider flag <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2800>
<cachio> pstolowski, do you understand the issue?
<pstolowski> cachio: no. it passed everywhere but on 18.04
<cachio> pstolowski, I removed the comment
<cachio> perhaps with that the error is removed too
<cachio> pstolowski, can you add the +1
<cachio> so if you leave I can merge it?
<cachio> thanks
<pstolowski> cachio: done. yes, please land when green
<zyga> hey guys
<zyga> starting Friday here
<zyga> how was your week?
<pstolowski> zyga: hey
<pstolowski> zyga: terrible. nothing can land. everything breaks.
<zyga> pstolowski: can you summarize what is broken now
<pstolowski> zyga: tumbleweed broke (zypper segfault, timeouts), moved to unstable. amazon linux change libseccomp and one of the tests needed disabling. arch broke yesterday and is now going to be moved to unstable
<zyga> pstolowski: what happened with libseccomp?
<zyga> update to the package?
<pstolowski> zyga: tests/main/system-usernames: Amazon Linux 2 comes with libseccomp 2.4.1 now (from the git commit)
<zyga> pstolowski: thanks,
<zyga> pstolowski: well, next week will be busy
<pstolowski> zyga: it's dark and grey outside, and red on travis. there is no green anywhere ;)
<zyga> pstolowski: time for tea with honey and long evenings to fix everything :)
<zyga> pstolowski: no need to despair, next week we'll be back and work on it together
<pstolowski> cachio has a PR for temporarily disabling arch so hopefully we can at last land some something
<zyga> that's good
<zyga> we should disable things to be able to move and make progress
<pstolowski> yeah.. it was unfortunate we were hitting these problems one after another (with some random failures as usual), so it felt like broken permanently since ~wednesday
<mup> PR snapcraft#2801 opened: travis: use `stable` channel for shellcheck snap <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2801>
<ogra> zyga, week was awful ... with everyone and his pet in vancouver i was forced to work on all my paperwork backlog !!!!
<cachio> pstolowski, zyga still running the Pr to move arch to unstable
<zyga> ogra: did you watch all the HR training videos?
<zyga> cachio: thank you, let's get this stuff stable
<ogra> lol, not yet :)
<zyga> ogra: it's like a day of work
<ogra> zyga, more like preparing contracts with future paying customers to pay all our salaries ;)
<cachio> zyga, yes, trying
<zyga> ogra: thank you for that :)
<ogra> id you do it already ?
<cachio> zyga, but we got some problems with gce dependencies
<ogra> *did
<zyga> ogra: no, I did two
<zyga> ogra: out of dozen maybe
<cachio> we need to wait until someone fix the google-compute-engine package on arch
<zyga> ogra: it's painful
<ogra> oh my !
<zyga> ogra: like really
<zyga> well, we will all see, I guess
<ogra> yeah, sounds like ...
<zyga> cachio: can we reach out to the maintainer
<zyga> cachio: talk to someone on IRC
<zyga> cachio: or at least report that it is broken
<cachio> I thnk maciek already did it
<cachio> zyga,  but he is out today
<zyga> good
<zyga> ok, there's always next week to fight :)
<mup> PR snapcraft#2802 opened: uprev devel python package requirements <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2802>
<mup> PR snapcraft#2803 opened: snap: add license to snapcraft.yaml <Created by sparkiegeek> <https://github.com/snapcore/snapcraft/pull/2803>
#snappy 2019-11-16
<mup> PR snapd#7741 opened: tests: fix spread shellcheck and degraded tests to unbreak master <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7741>
<mup> PR snapd#7741 closed: tests: fix spread shellcheck and degraded tests to unbreak master <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7741>
<mup> PR snapcraft#2801 closed: travis: use `stable` channel for shellcheck snap <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2801>
#snappy 2019-11-17
<mup> PR snapd#7734 closed: spread: do not explain errors <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7734>
<mup> PR snapd#7742 opened: tests: reset failing "fwupd-refresh.service" if needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/7742>
<mup> PR snapd#7743 opened: snap-bootstrap: force partition table operations <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743>
<mup> PR snapd#7744 opened: snap-bootstrap: set expected filesystem labels <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7744>
