#snappy 2016-03-21
<netphreak> hi, guys!
<shuduo> morning
<mvo> ogra_: if you have time at some point it would be great if we could update the arm64 kernel in xenial in the store
<zyga> Good morning
<mvo> ogra_: hm, the latest rpi2 kernel from the archive (canonical-pi2-linux.canonical_4.4.0-1004.5-1.snap) appears to not boot at all, hangs at "Uncompressing Linux... done, booting the kernel."
<mvo> ogra_: auto-rollback-broken-boot ftw :)
<dholbach> good morning
<didrocks> dholbach: good morning!
<dholbach> salut didrocks
<shuduo> hello, i am working on repack mopidy (http://github.com/mopidy/mopidy.git) into snap format. i'm referring py2-project of snapcraft-examples. after snapcraft build, i notice the execute file /usr/bin/mopidy as a python script file contain my work directory path in first line.
<shuduo> i wonder mopidy is pip compatible but spongeshaker don't has weird path. any idea how to solve or workaround it?
<ogra_> mvo, the cdimage snaps shoudl work ...
<ogra_> (for updating the store)
<asac> hmm. running snapcraft from within snapcraft tree isnt possible anymore? it cannot find the plugins for me :/
<asac> odd
<ogra_> mvo, for arm64 we now have the linux-snapdragon kernel, the cdimage snap is already built from it by default since friday, i need to create as new package in the store for the new name
<ogra_> s/as/a/
 * ogra_ is waiting for dd to finish to chekc the rpi image
<ogra_> mvo, hmm, i think we need a gadget update for the rpi side
<mvo> ogra_: is the kernel available as an artifact on cdimage?
<mvo> ogra_: do we need a new dtb ? or why is the gadget update needed?
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<ogra_> mvo, iirc the 4.4 support was added, the all-snaps gadget is still on older firmware
<ogra_> (i updated the 15.04 one but forgot about all-snaps back then)
<ogra_> above on the cdimage link are all all-snaps snap artefacts
<mvo> ogra_: I can upload the dragonboard snap thats fine, I will upload to edge and you can test on your board?
<Sin_> hi, all
<ogra_> mvo, sure ... but create a new package called canonical-linux-snapdragon then
<ogra_> and delete the old one
<mvo> ogra_: oh, its called differently? ok
<ogra_> yeah, and that kernel is supposed to support more snapdragons as i understood
<mvo> ogra_: I assume the dragonboard.device tar file is not available on cdimage? "just" the snap?
<mvo> ogra_: aha, interessting
<ogra_> the tarballs are still there too
<mvo> ogra_: in the past the tarball device stuff would not boot on the dragonboard
<mvo> ogra_: is that no longer the case, i.e. does it boot now?
<ogra_> i'm booting the cdimage snaps daily since a few weeks on the dragonboard
<mvo> ogra_: cool
<ogra_> i admittedly havent tries the rpi in a while ... nor the BBB
<ogra_> *tried
<Sin_> how to install apache on a rpi 2 ubuntu snappy core?
<ogra_> rpi should work after gadget update (will work on that now) ...
<ogra_> BBB still needs someone to test (but i can do that as well, just later)
<ogra_> Sin_, sure, you just need to snap it up using snapcraft
<Sin_> ogra, i'm trying to install snapcraft on rpi, but no luck
<ogra_> if you are on the 16.04 image: sudo snappy enable-classic; snappy shell classic
<ogra_> that gives you an apt environment in whicgh you can do work to create snaps
<ogra_> (you can just apt-get install snapcraft there)
<Sin_> "ubuntu core does not use apt-get"
<Sin_> 15.04 img
<ogra_> Sin_, http://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz take that one
<Sin_> thank you!
<asac> sergiusens: i cannot run the 96boards example from withing my snapcraft-master checkout
<asac> it tells me "kernel plugin ot found"
<asac> odd because its in the snapcraft/plugins directory
<asac> are we still supporting running from within tree?
<asac> i am running ../../bin/snapcraft --target arm64 from within that 96b dir
<asac> sergiusens: http://paste.ubuntu.com/15452970/
<sergiusens> asac, yeah, it is supposed to just work, I've been running in tree
<sergiusens> asac, kernel plugin is not in master
<sergiusens> asac, https://github.com/ubuntu-core/snapcraft/pull/366
<ogra_> ppisati, hmm, did you ever get around the FDT_ERR_BADMAGIC on the pi2 ?
 * ogra_ is just trying the -next branch of the firmware 
<ppisati> ogra_: yep, there's a way
<ppisati> ogra_: hold on
<ogra_> (or do you happen to have an up-to-date packaged version of the firmware)
<ppisati> ogra_: well, the newest formware relocate the dtb in memory
<ppisati> ogra_: so the answer is:
<ppisati> ogra_: https://github.com/piso77/ubuntu-embedded/blob/master/boards/raspi3/rootfs/boot/firmware/config.txt
<ppisati> ogra_: see at the end
<ppisati> ogra_: device_tree_address=0x02000000
<ppisati> ogra_: and uboot.env needs to be modified to look for the dtb there too
<ppisati> ogra_: here is some more info
<ppisati> https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=134018
<ppisati> ogra_: search for "The slot at 0x100 is limited to...|
<ppisati> that gives some more context
<ogra_> ppisati, thanks a lot !
<ppisati> ogra_: our kernel support teh rpi3 btw
<ogra_> yeah, but we have no fully working u-boot yet i think
<ppisati> ogra_: yes we do :)
<ogra_> (i havent checked swarrens branch on the weekend ... last i checked it still was WIP
<ogra_> )
<ogra_> ppisati, oh !
<ppisati> yeah, i was using that one
<ppisati> and it worked
<ogra_> for both pi's
<ppisati> no
<ogra_> ?
<ogra_> ah
<ppisati> it's not merged
<ogra_> right+
<ppisati> one for rpi2 and one for rpi3
<ogra_> preferably i'd like to use the same image on both ... for 32bit at least
<kyrofa> Good morning
<ogra_> hmpf ...
<ogra_> still not booting the new kernel
<ogra_> aha
<ogra_> eeek !
<ogra_> ppisati, i get a massive load of "cant mount device as F2FS filesystem" during boot
<ogra_> purely cosmetic, but looks really scary
<ogra_> mvo, so i got it booting ... but you wont like the solution ... our dtb from the kernel snap needs to end up in the toplevel of system-boot and overwrite the one from the firmware
<ogra_> ubuntu@localhost:~$ uname -a
<ogra_> Linux localhost.localdomain 4.4.0-1004-raspi2 #5-Ubuntu SMP Mon Mar 14 22:27:12 UTC 2016 armv7l armv7l armv7l GNU/Linux
<ogra_> (using the cdimage kernel snap)
<ogra_> hmm, and resizing worked just fine
<ogra_> ubuntu@localhost:~$ df -h |grep /writable
<ogra_> /dev/mmcblk0p2  118G  151M  111G   1% /writable
<ogra_> not sure what issue ali1234 had with his
<ogra_> kyrofa, didnt you also see the rpi not resize ?
<kyrofa> ogra_, indeed, yes
<ogra_> weird
<kyrofa> ogra_, ppisati I've been seeing garbled HDMI output and evbug errors whenever I press keys on the keyboard as well
<ogra_> kyrofa, well, lets see if todays update will get you going then
<kyrofa> ogra_, awesome :)
<ogra_> just need to discuss with mvo what we do with the dtb
<kyrofa> ogra_, so reading the scrollback, it seems you have a booting rpi3?
<ogra_> (as a quick hack i can indeed just copy it into the gadget, but thats no solution long term)
<ogra_> kyrofa, no, paolo has ... i'm working on the existing images today ... once we have a release i'll look at the pi3
<sergiusens> kyrofa, good morning! I could really use a review on the kernel plugin PR ;-)
<kyrofa> ogra_, ah, read too quickly then, but awesome :)
<kyrofa> sergiusens, yessir! Part way through now
<davidcalle> kyrofa: sergiusens: hi, is there a way to add an export to the launch wrapper created by snappy/snapcraft?
<sergiusens> davidcalle, no; the launch wrapper is an implementation detail
<sergiusens> davidcalle, it shouldn't be promoted to anyone ;-) People should write their own wrappers if they need that
<sergiusens> davidcalle, or create a plugin that exports env
<davidcalle> sergiusens: right, so, maybe the best course of action would be to create a wrapper part myself that exports what I want and launch the actual binary
<davidcalle> sergiusens: (first time I'm trying to snap something that's not a terminal game, some concepts and ways of doing things are still abit blurry to me :) )
<kyrofa> davidcalle, exactly
<davidcalle> kyrofa: sounds good, thanks
<kyrofa> davidcalle, you'll find little wrapper scripts here and there to be pretty central to how things are done
<sergiusens> darn, in an hour I have meetings for 5 hours :-/
<kyrofa> sergiusens, brutal
<kyrofa> enoch85, you around?
<asac> sergiusens: i am using your feature bran
<asac> ch
<asac> sergiusens: http://paste.ubuntu.com/15452970/
<davidcalle> dholbach: kyrofa: sergiusens: it worked, thanks a lot :)
<asac> ls -la ../../snapcraft/plugins/kernel.py
<asac> -rw-rw-r-- 1 asac asac 10623 Mar 21 09:55 ../../snapcraft/plugins/kernel.py
<asac> sergiusens: let me know if you need anything
<asac> i am on 559044dc02646a3b10f078bd1d74182a3efd9a8d
<ogra_> mvo, http://people.canonical.com/~ogra/snappy/canonical-pi2_3.1_all.snap built from https://code.launchpad.net/~ogra/+junk/snappy-systems (see revision 32-34) ... that one boots with the cdimage kernel
<ogra_> mvo, the dtb problem persistes though and i'm not sure it could boot with a 4.2 kernel at all
<ogra_> (without manually copying the 4.2 dtb in place)
<ogra_> mvo, bah, you didnt use any of the cdimage snaps for the store, thats not ok
<ogra_> (i want to auto-submit them starting this week)
<ogra_> oh, wait, i got tricked by the versioning
<ogra_> hmm, no, actually correct, not one of them
<sergiusens> asac, you need to be on f8fea60694c2f2540c9f7490bdd0376848179c1f
<sergiusens> asac, https://github.com/ubuntu-core/snapcraft/pull/366/commits/f8fea60694c2f2540c9f7490bdd0376848179c1f
<dholbach> davidcalle, is it running already?
<davidcalle> dholbach: yep, got it running :) Now, I'm trying to ship games in the snap and have them accessible to it
<dholbach> upload to the store! :)
<dholbach> snapcraft upload!
<ogra_> mvo, so i think we have to re-do all of this
<ogra_> we need to use the cdimage snaps here
<davidcalle> dholbach: still trying to figure out some runtime details :)
<dholbach> ok ok :)
<netphreak> Hello, guys!
<mvo> ogra_: sorry, I went for the safe route to ensure the cves are fixed, once they are in stable (i.e. now) I am more than happy to switch to the new artifacts
<mvo> ogra_: this was "upload-cve-fixes-first-without-any-risk" mode
<ogra_> ?
<ogra_> these snaps all come from the very latest xenial archive debs
<ogra_> i would not expect any open CVEs in them
<ogra_> (they are completely identical to the tarballs ... content wise)
<kyrofa> ogra_, the resize on boot thing, is that for the writable partition?
<ogra_> yes
<kyrofa> ogra_, should that continue to work if the writable partition is on a separate device?
<jdstrand> mvo: hey, fyi, there is a new xenial kernel that might land today. this is going to require updates to ubuntu-core-security and ubuntu-core-launcher. I'm not sure when you are planning new os and kernel snap updates, but you might want to ping me if you are doing them before wednesday
<elopio> mvo: related to that, if we are going with a two week cadence, we need to prepare today the 16.04 stable release to publish it tomorrow.
<elopio> do you think we should talk to the kernel team first about doing 3 weeks instead of 2?
<noizer> Hi jdstrand short question is it possible to use security-override and caps ( network-listener, ...) together?
<jdstrand> noizer: in 16.04, yes. in 15.04, no
<noizer> jdstrand: ok thx
<mvo> elopio: I think we can do that
<mvo> elopio: i.e. prepare update today
<mvo> elopio: I triggered a new image build
<elopio> mvo: ok. I also like the idea of trying a release tomorrow to get an idea of what will make it easier. We can decide on the # of weeks a little later.
<mvo> elopio: yeah, we did not have a stable release since 8. match, so +1 for a new update
<noizer> Will snappy be compatible with the Raspberry pi 3?
<ogra_> noizer, yes
<noizer> ogra_: ok that will be nicee
<kyrofa> ogra_, think the writable partition resize would continue to work if it was on another device (e.g. an external HD)?
<ogra_> kyrofa, thats what my "yes" above was for ... as long as the patition is properly named it should all work
<ogra_> (and as long as the old label from the old writablÃ¶e was removed ... i never tried what happens if you have two of them :) )
<kyrofa> ogra_, excellent thank you! And yeah, I imagine other problems would occur if that were the case!
<kyrofa> jospoortvliet, are you around?
<noizer> what does the caps exactly with a snap. Does it changes the apparmor profiles?
<asac> noizer: yes under the hoot it generates the profile for that specific app
<sergiusens> ogra_, out of the blue question; how do I build a 32 kernel ofrom an amd64 system?
<ogra_> sergiusens, hmm, better aks the kernel guys :)
<sergiusens> ppisati, ^ :-)
<asac> sergiusens: -m32?
<asac> :)
<ogra_> i guess with some clever ARCH= setup
<sergiusens> asac, is that all?
<noizer> asac Is that possible to get the changes for some caps? because i need to make my apparmor myself for my own snaps got special restrictions
<ogra_> passed to the toolchain
<asac> noizer: are you on 15.04?
<noizer> asac no im on 16.04 rolling
<sergiusens> asac, how about a 32 bit kernel from an armhf system?
<asac> sergiusens: i386_defconfig
<asac> dunno i will check this later and let you know if you havnet found :_)
<asac> you surely would want a cross compiler on armhf
<ogra_> you want to build an x86 kernel on an arm host ?
<ogra_> what did you guys smoke today ?
<asac> yeah or on amd64 :)
<asac> its important that you can read live the build process
<ysionneau> hi, does ubuntu-core support booting on a GPT disk?
<ogra_> ysionneau, indeed
<ysionneau> it seems the init scripts are searching for writable using findfs LABEL=writable, but in GPT you need to do findfs PARTLABEL=writable
<ogra_> the amd64 and arm64 images default to it
<ogra_> ysionneau, we set both ... partition label and filesystem label
<ysionneau> I'm on a Tegra X1 board and I'm using my own xml to describe the partitionning
<ysionneau> I guess my issue is in this xml
<ysionneau> I set name="writable" for the partition, but it does not seem to set the label, only the partlabel
<ogra_> http://paste.ubuntu.com/15463687/
<ogra_> ubuntu@localhost:~$ findfs LABEL=writable
<ogra_> /dev/mmcblk1p9
<ysionneau> ah, I guess it's my ext4 "file" which is missing its label then
<ogra_> (thats both on a dragonboard)
<ogra_> well, ubuntu.-device-flash creates the labels
<ogra_> before it unpacks the os snap in it
<ogra_> ("system-boot" and "writable" are the defaults)
<ysionneau> I'm creating the ext4 myself, maybe I should just use udf
<ogra_> yeah, you definitely should
<kyrofa> ogra_, ah, the pi2 gadget was updated?
<kyrofa> ogra_, means I need to update my fork
<kyrofa> ogra_, what changed?
<ogra_> kyrofa, last three commits https://code.launchpad.net/~ogra/+junk/snappy-systems
<ogra_> (i'm about to merge that into the main tree)
<kyrofa> ogra_, ah, very nice. Okay I'll keep an eye out
<sergiusens> kyrofa, meeting?
<kyrofa> sergiusens, sure! I figured you were booked
<sergiusens> kyrofa, join snapcraft
<ysionneau> yeah, I've got snappy booting on the drone board o/
<didrocks> nice ysionneau \o/
<joc_> elopio: ping
<popey> I just updated my snappy machine:-
<popey>  /var/lib/dpkg/info/tzdata.config: 379: /var/lib/dpkg/info/tzdata.config: cannot create /etc/timezone: Directory nonexistent
<popey> (sorry, classic dimension)
<popey> (classic)ubuntu@localhost:~$ ls -l /etc/timezone
<popey> lrwxrwxrwx 1 root root 17 Feb  3 09:22 /etc/timezone -> writable/timezone
<popey> that looks wrong (writable/timezone) is in red in my shell
<ogra_> popey, it exists outside of the classich container
<ogra_> (and we can only use relative links for that)
<ogra_> (though even absolute wouldnt help in this case)
<mvo> elopio: I think we have an updated ubuntu-core in 16.04/edge ready for tesing
<elopio> mvo: thanks. I will start.
<mvo> elopio: \o/
<elopio> mvo: what about the 15.04 update? is it still happening today?
<popey> ogra_: so what's the fix?
<ogra_> popey, dunno, copy that dir into classic ... (no idea how)
<ogra_> there are a bunch more files (three iirc)
<ogra_> in /etc/writable
<joc_> elopio: hey, the example tests appear to have errored on the plainbox snapcraft PR, would appreciate you having a quick look
<ogra_> elopio, please take into acocunt that we have a new name for the dragonoboard kernel and that you *need* the new pi2 gadget snap (3.1) to make the 4.4 kernel boot
<elopio> joc_: looking.
<elopio> mvo: the tests are failing on the rollback when comparing the versions: 16.04-20160321-05-01+fake1 <= 16.04-20160321-05-01
<elopio> that date 20160321-05-01 in the version is new. I suppose the function you wrote to compare is not ready to handle it.
<elopio> ogra_: noted.
<ogra_> elopio, use ~fake1 ?
<ogra_> (i would expect this to work the same as dpkg versions)
<mvo> elopio: can you point me to the actual test output please? the statement is correct, I don't think this is a version compare issue
<elopio> mvo: https://paste.ubuntu.com/15464432/
<mvo> ta
<elopio> mvo: fgimenez was saying that the version maybe shouldn't include the date, because we already have a date field.
<mvo> elopio: aha, I think I have an idea
<elopio> and we can easily change the +fake1 to ~fake1 as ogra says. That's probably better.
<mvo> elopio: that may indeed be a bug in the version compare code, iirc you normally can only have a single "-" but thats ok, should be easy to fix
<ogra_> elopio, thats a limitation if using cdimage to build the snaps now ...
<ogra_> (the date in the version string)
<mvo> elopio: I think ~fake1 is not what we want it will be a lower version this way but we want the fake version to be higher
<ogra_> i cant make cdimage aware of the latest version in the store so that i could bump it or some such ...
<ogra_> fgimenez, ^^
<elopio> lower, hum. This version rules are complex.
<elopio> ogra_: I think the output of snappy list will be a lot nicer if we don't have the dates twice. I didn't fully understand what you said about making cdimage aware of the latest version. Could you expand a little on that?
<jdstrand> mvo: hmmm, bug #1553040 seems to be happening on the hour
<ubottu> bug 1553040 in systemd (Ubuntu) "systemd-logind crashed with SIGSEGV" [Medium,Confirmed] https://launchpad.net/bugs/1553040
<mvo> ogra_: lets wait with that before we figure the actual issue out
<ogra_> elopio, cdimage doesnt know about the store ... by default it uses version numbers based on the date for everything it builds ... i can neither know what the last version was to bump it nor can i know whats in the store to bump it by 1
<mvo> jdstrand: meh, that sucks
<jdstrand> I guess I can uninstall ubuntu-core and reinstall
<jdstrand> as a workaround
<mvo> jdstrand: sorry for the language, I think we need to set the priority to high
<mvo> jdstrand: yes, that should work
<jdstrand> mvo: no need to be sorry. it does :)
<ogra_> elopio, the only safe way to generate a version on cdimage auto-builds is to actually use a version string (or parts of it)
<ogra_> err
<ogra_> is to actually use a date string
<ogra_> :P
<mvo> jdstrand: the real fix is to just ensure the bootloader detection magic is smater and will not attempt to reboot if its not a snappy system
<fgimenez> ogra_, could you use something like curl -s -H "X-Ubuntu-Architecture: amd64"  -H 'Accept: application/hal+json' 'https://search.apps.ubuntu.com/api/v1/package/ubuntu-core.canonical/edge' | jq '.version' to get the version?
<elopio> ogra_: could you take the version from the debian changelog?
 * jdstrand nods
<ogra_> fgimenez, no, i dont have any access to the outside world during builds
<ogra_> elopio, which debian changelog ?
<jdstrand> Removing ubuntu-core.canonical
<mvo> elopio, ogra_: lets keep the version for now until this is better understood, it smeels like a bug in the version compare code in snappy
<jdstrand> snappy package cannot be removed
<jdstrand> hmm
<mvo> jdstrand: lol, of course not, can't remove your os
<elopio> mvo: ogra_: sounds good.
<ogra_> mvo, well, i agree with fgimenez that we shouldnt have the date twice ... but i have no idea wht to do
<mvo> ogra_: oh, thats orthogonal I guess, thats fine
<elopio> what is that -05-01 appended to the date?
<ogra_> elopio, the os snap isnt bound to any debian/changelog ... and cant be
<ogra_> elopio, time
<jdstrand> mvo: yes, that obviously makes sense on a device, but sdoc now is interesting... I really should be able to remove that. I guess I can look at the cron job
<elopio> got it.
<jdstrand> not cron
<ogra_> systemd timer :)
<jdstrand> /lib/systemd/system/snappy-autopilot.timer
<jdstrand> yes, I was getting there :)
<mvo> jdstrand: yes you should
<mvo> jdstrand: I mean, yes you should be able to do that, this was written when we had no idea about this use-case
<jdstrand> mvo: oh sure, I was simply acknowledging that fact :)
<elopio> joc_: looks like an error connecting to the testbed. You can re-try them commenting: "retest this please"
<mvo> jdstrand: yeah :)
<popey> updating my snappy pi.. I get this...
<popey> 2016/03/21 16:19:37.029389 sort.go:162: Invalid version "16.04-20160321-14-25", using '0' instead. Expect wrong results
<popey> is that normal?
<ogra_> popey, most likely related to the issue that elopio and mvo are looking at above
<popey> oh, sorry
<mvo> popey: yes, thanks, what ogra_ said, but this error message is actually very useful
<popey> Oh good :)
<ogra_> yeah, that explins elopio's error :)
<ogra_> *explains
<popey> http://paste.ubuntu.com/15464724/ is the full output fwiw
<ogra_> popey, funny, i wonder what happens after reboot :)
<ogra_> seems it thinks it installed them
<mvo> ogra_: I finally looked at this and I think changing the version to only have a single "-" in it would be best if that is possible
<elopio> popey: thanks a lot. So it affects more than the integration tests, and you caught it early :)
<mvo> ogra_: i.e. 16.04+2016032114-25
<ogra_> mvo, hmm, yeah ... i can do that but need to re-build and re-upload
<ogra_> mvo, with a plus sign ?
<mvo> ogra_: yeah, plus is fine
<ogra_> ok
<mvo> ogra_: or give me a sec and I paste a new string, "-" and ":" are problematic
<mvo> ogra_: "+" and "." are fine
<ogra_> that takes quite some turnaround time though (livecd-rootfs upload ... waiting for publisher for 2h ... then rebuild and re-upload to the store)
<mvo> ogra_: and "-" is fine as long as there is only one
<popey> Do I dare reboot this?
<ogra_> do you ?
<jospoortvliet> kyrofa: I'm around now for a bit
<jospoortvliet> sadly, not feeling well today
<ogra_> mvo, http://paste.ubuntu.com/15464880/
<jospoortvliet> spend most of the day in bed and will be returning soon
<lool> sergiusens: hey
<kyrofa> jospoortvliet, ah I'm sorry! Nothing important here, go back to bed :)
<mvo> ogra_: maybe a "." in between? "date +20%y%m%d.-%M" ?
<mvo> ogra_: otherwise looks fine
<kyrofa> jospoortvliet, OC9 will be released as soon as it's built
<lool> sergiusens: did we have a nack on supporting patch files in snapcraft, or is this something that just needs work?
<mvo> ogra_: I think we can not avoid this delay, we could unpublish this particular version that is problematic though
<jospoortvliet> kyrofa: rocking
<jospoortvliet> kyrofa: we didn't figure out what PHP modules were missing though
<lool> sergiusens: other question, is there anything discussing extending CFLAGS/CPPFLAGS/LIBS etc. somewhere?
<ogra_> mvo, i'll upload to the PPA first ... that at least speeds up the publlisher
<kyrofa> jospoortvliet, the images require imagick
<kyrofa> jospoortvliet, that build process is complicated though, so it won't make it by tonight
<jospoortvliet> ok... got it
<kyrofa> jospoortvliet, it's dog slow on the rpi2 too, FYI
<jospoortvliet> kyrofa: yeah, of course... ;-)
<kyrofa> jospoortvliet, things are a bit snappier without it :P
<jospoortvliet> kyrofa: for ownCloud, we should add caching at least, that'll help with performance
<jospoortvliet> quite a bit ;-)
<jospoortvliet> was hoping somebody would help...
<kyrofa> jospoortvliet, yeah, that'll help
<jospoortvliet> btw see https://doc.owncloud.org/server/9.0/admin_manual/installation/source_installation.html for a list of deps that are useful/helpful
<jospoortvliet> add what you can ;-)
<kyrofa> jospoortvliet, yeah I'm familiar with it, the snap config is pretty bare-bones at the moment indeed
<sergiusens> lool, nack on patches
<sergiusens> lool, extend CFLAGS, CPPFLAGS and LIBS where?
 * sergiusens needs to leave for a bit
<lool> sergiusens: I want to pass an extra flag in CFLAGS to my build on top of the snapcraft ones
<lool> e.g. cmake build, autotools build etc.
<sergiusens> lool, can't you do that with the flags keywords those support?
<lool> I cant extend the current flags with this
<lool> if I say CFLAGS="foo", it will override
<lool> I could try CFLAGS="$CFLAGS foo", but dont think this works
<kyrofa> jospoortvliet, anyway, go back to bed. I'll send out an email
<sergiusens> lool, maybe CFLAGS="$CFLAGS foo"
<jospoortvliet> kyrofa: thanks!
<sergiusens> lool, why do you think it wouldn't ? :-)
<lool> sergiusens: I think I tried it, but I'll try again
<lool> it was before fixing the shell escaping issue, perhaps it works now
<sergiusens> lool, btw, what is your strategy with those PRs?
<ogra_> lool, stop scaring your shell, then it doesnt try to escape :P
<lool> sergiusens: what's the proposed approach for patches? point at a patched tree? I'm adapting this bb recipe https://github.com/open-switch/ops-build/blob/master/yocto/openswitch/meta-distro-openswitch/recipes-ops/openvswitch/ops-openvswitch.bb which is openswitch's openvswitch build (naming is confusing); it uses upstream's tree and adds openswitch patches; trying to do the same with snapcraft is hard
<lool> sergiusens: I'm about to update them
<sergiusens> lool, the policy is you will have your own tree
<sergiusens> lool, if you think about, that is what patches really are; git just makes patching obsolete
<sergiusens> just look at our ubuntu kernel :-)
<lool> sergiusens: sure, it's just that there is no merge support either, so how do you automatically take latest upstream git with your changes?
<lool> it means people need an automation point on their own
<lool> if we had something like Launchpad git recipes, then it would be fine though
<lool> e.g. I'd point at my branch with patches and merge it with upstream before building
<sergiusens> lool, sorry, I can't follow; but more so because I need to run; can we talk later or tomorrow?
<lool> sure
<lool> ttyl
<mvo> ogra_: thanks
<ogra_> new image build triggered
<elopio> thanks ogra_
<elopio> it's awesome when everything starts to be in place. Now jenkins will notice that a new edge was released, and run all the jobs itself.
<ogra_> neat !
<ogra_> well, the upload is still all me manual ...
<ogra_> (and a big PITA)
<elopio> oh, sure, it's ci, cyborg integration.
<elopio> I also will need to manually select the channel checkbox z.Z
<joc_> elopio: unfortunately my "retest this please" comment seems to have been ignored
<elopio> joc_: I think I need to whitelist you so you can retest.
<elopio> let me see. It's still a little confusing this plugin.
<joc_> elopio: thanks
<elopio> ogra_: can we change also the version of the latest edge snap?
<ogra_> elopio, which one ?
<ogra_> i cahnged all versions that are generated by the build to the schema tht mvo suggested above
<ogra_> $upstream+YYYYMMDD.HH-MM
<elopio> ogra_: in the store, revision #62 edge I see 16.04-20160321-14-13
<ogra_> no, tht comes from the snap.yaml
<ogra_> i dont think thats changeable
<ogra_> (and i learned today that we cant delte snaps ourselves either)
<elopio> we can upload a new one with the fixed version.
<ogra_> thats what i will do once this build finished
<elopio> so if I understand correctly, that would mean to go to that cdimage url where you are uploading the snaps, download it and upload it to the store selecting the edge channel.
<ogra_> exactly, thats what i'm doing all day aleready :)
<elopio> ogra_: ok, so nevermind I said anything. I thought that last part was on mvo's hands.
<ogra_> i was fiddling with the click-toolbelt stuff to have cdimage auto-upload from there ... but that will still take a few days
<elopio> ogra_: using snapcraft or calling the api directly?
<ogra_> mvo is the one who needs to approve the snaps to have them published :)
<ogra_> elopio, 12.04 server ... no snapcraft ...
<ogra_> thus: click-toolbelt
<elopio> got it, I will be slowly trying to understand all those parts this week. Let me know if I can give you a hand somewhere.
<mvo> ogra_: are they ready already :) ?
<ogra_> mvo, ready, yes, not uploaded yet
<mvo> ogra_: nice, keep me updated!
<mhall119> zyga: ping
<ogra_> mvo, https://myapps.developer.ubuntu.com/dev/click-apps/4142/ (ubuntu-core), https://myapps.developer.ubuntu.com/dev/click-apps/4283/ (canonical-pc-linux (dont forget i386 ;) )), https://myapps.developer.ubuntu.com/dev/click-apps/4284/ (canonical-pi2-linux)
<ogra_> mvo, https://myapps.developer.ubuntu.com/dev/click-apps/4316/ (canonical-bbb-linux), https://myapps.developer.ubuntu.com/dev/click-apps/4739/ (canonical-snapdragon-linux)
<ogra_> happy approving :)
<elopio> ogra_: mvo: is this a good version for the ubuntu-snappy deb we upload to the PPA? 1.7.3+20160310ubuntu1~ppa14-1
<elopio> 14 is the number of the build, so it's always increasing.
<ogra_> why -1 ?
<mvo> elopio: this looks good, you can skip the final "-1"
<ogra_> :)
<kgunn> ogra_: i haven't check on dragonboard in a while, is it getting any love? or is it roughly in same state as ~January
<ogra_> kgunn, totally
<ogra_> the store is full of shiny new packages and we'll do an alpha release this week
<kgunn> cool
<ogra_> (4.4 kernel is now canonical-snapdragon-linux ... and ubuntu-core for arm64 just got updated)
<ogra_> we still dont have any classic mode on arm64 though
<popey> ogra_: so will there be another update i can pull down on my edge pi which will replace the busted one?
<popey> (in some hours?)
<ogra_> popey, why hours ?
<popey> I assume it takes a while :)
<ogra_> just pour some extra fuel into elopio and it will be fast :)
<elopio> ogra_: mvo: dch adds a 1 at the end. I'm not sure how to remove that.
<elopio> dch --distribution xenial -m --local ~ppa$BUILD_NUMBER- Daily release to the PPA
<elopio> any tips to improve that ^ ?
<ogra_> hmm, i thought it only does that with explicit -i
<mvo> elopio: its fine, it won't hurt
<kyrofa> sergiusens, this should look familiar, but a bit easier to review: https://github.com/ubuntu-core/snapcraft/pull/384
<kyrofa> elopio, ^^
<sergiusens> kyrofa, my comments weren't exported though :-P
<kyrofa> sergiusens, unfortunately not :( . Darn intermediate branch. I wish I could change the PR partway through
<kyrofa> sergiusens, but the complicated bits (strip cleaning) aren't here anymore, so your comments wouldn't be relevant anyway
<sergiusens> kyrofa, heh :-) I search for the closed one and replicate
<sergiusens> kyrofa, oh they aren't? I don't want to blindly trust you though ;-)
<kyrofa> Haha, no don't trust me! I realized a lot of that other PR didn't have anything to do with strip cleaning-- there was a bit of setup to do it. This PR is that "bit of setup"
<kyrofa> So then subsequent PRs can just fill in their little bits
<kyrofa> sergiusens, smaller PRs=better
<sergiusens> kyrofa, oh, you removed the strip part
<kyrofa> sergiusens, right
<sergiusens> kyrofa, got it; I still managed to add MOAR comments ;-)
<kyrofa> Yeah I keep forgetting about !r
<sergiusens> kyrofa, btw, somethings failed here https://github.com/ubuntu-core/snapcraft/pull/383
<kyrofa> sergiusens, hmm...
<kyrofa> sergiusens, huh... I can't connect to the VPN at the moment. NM is telling me it doesn't have permission
<sergiusens> kyrofa, heh, I hate nm :-P
<kyrofa> *sigh*
<sergiusens> kyrofa, elopio btw, I am doing some manual traffic shaping on which PR gets tested next
<kyrofa> I'd totally reboot, but I have an emergency build of owncloud going that I can't stop
<kyrofa> sergiusens, no problem
<sergiusens> kyrofa, ssh and screen ;-)
<kyrofa> sergiusens, screen doesn't work in classic
<kyrofa> sergiusens, otherwise that's the obvious choice
<sergiusens> kyrofa, if it is a serial connection it would be fine
<kyrofa> sergiusens, :P
<sergiusens> to disconnect and reconnect
<kyrofa> sergiusens, SSH I'm afraid
<zyga> mhall119: hey
<sergiusens> kyrofa, testing is taking forever :-P
<kyrofa> sergiusens, yeah, killer
<mhall119> zyga: hey, I had a task to follow up with you about show to ship apps written for the phone/tablet on a the snappy desktop, do we have a plan for how we're going to approach that for 16.04?
<mhall119> last we spoke you were still workign that out
<kyrofa> jdstrand, I've got two owncloud.canonicals in the manual review queue for network-listener. Mind taking a look?
<jdstrand> kyrofa: approved
<kyrofa> jdstrand, thank you!
<zyga> mhall119: I think that hasn't changed since, we're still tying loose knots together to make the system work
<zyga> mhall119: I think we're still a bit behind there on what we aim to deliver
<mhall119> zyga: with it using the snappy space, will we be able to land that feature for users of 16.04 even after release? Or will it have to wait until 16.10?
<sergiusens> kyrofa, care to rebase https://github.com/ubuntu-core/snapcraft/pull/384 ?
<zyga> mhall119: I'm almost 100% sure that we'll land updates across all systems
<zyga> mhall119: we really need to land all the key things for 16.04 but we'll be making updates as the system evolves; AFAIR we're still trying to determine exactly how snappy updates in ubuntu will look like but that's the plan
<mhall119> zyga: ok, can you send an update to the email thread dholbach started, titled "Releasing the SDK libs as a snap" with the current state of things?
<zyga> mhall119: yes, I'll read updates since I replied initially and I'll do my best to reply
<mhall119> thanks, just to keep everybody in the loop updated
<popey> error: owncloud-pi2.kyrofa failed to install: gadget package installation not allowed
<popey> should I be able to install that?
<sergiusens> popey, no, gadgets are only allowed during image creation
<davidcalle> sergiusens: hi again, is there a way to put myself in the position of my snap, with the same constraints and path, and run commands (and maybe install packages)?
<davidcalle> paths*
<popey> sergiusens: shouldn't they be hidden from snapy find then?
<sergiusens> popey, oh they should; I made that statement or logged a bug about that or told stevebiscuit
<sergiusens> I forget which
<sergiusens> that and other kernels
<sergiusens> and also other uninstallables
<sergiusens> davidcalle, there's supposed to be a `snappy shell <snap>` ... but zyga
<sergiusens> lol, that came out wrong; I mean zyga can expand on if that is implemented or no
<sergiusens> t
<wililupy> Question: Whats the best documentation for building Kernel Snaps?
<sergiusens> elopio, care to look at https://github.com/ubuntu-core/snapcraft/pull/386/files
<sergiusens> wililupy, wait for snapcraft 2.5 to be announced later tonight or early in the morning
<wililupy> sergiusens: ack
<elopio> sergiusens: looks good. Are you going to include these two fixes I have in-progress?
<sergiusens> elopio, nah; we will get those in on Wednesday
<sergiusens> elopio, I have a bunch of small fixes to get in
<sergiusens> these can go there
<elopio> sergiusens: will you open a new milestone for the wednesday or should I target these bugs to 2.6?
<sergiusens> elopio, 2.6
<sergiusens> elopio, 2.6 is the wednesday milestone ;-)
<sergiusens> we are releasing 2.5 today :-)
#snappy 2016-03-22
<netphreak> Hi, guys :)
<netphreak> Any news on ubuntu snappy support on the RPI 3?
<zyga> jdstrand: hey
<zyga> jdstrand: could you have a quick look at https://github.com/ubuntu-core/snappy/pull/635
<zyga> jdstrand: the only new thing there since we last looked at that is https://github.com/ubuntu-core/snappy/pull/635/commits/939d1d5824c8ced1b7e994cf4f2f88ad289693ba
<zyga> jdstrand: I would *really* like to land this branch as it's been in a linbo for a week and I have some code that needs it
<zyga> jdstrand: if I lost track of the desired file name and other templates then please correct me but I think it is okay
<zyga> davidcalle: hey, sorry, lost IRC connection
<zyga> davidcalle: can you re-state your request please?
<dholbach> good morning
<noizer> Good morning
<noizer> jdstrand: Hi are you available?
<zyga> good morning
<ogra_> mvo, you didnt approve the kernels from the last build/upload ?
<noizer> Did you heard about the bomming in belgium dammed
<zyga> ogra_: hey, good morning
<mvo> ogra_: I see nothing in the unapproved queue
<netphreak> good morning ;)
<netphreak> Any news on ubuntu snappy support on the RPI 3?
<noizer> I heard it will be working on RPI 3 netphreak
<noizer> But i'm not a canonical developer
<ogra_> mvo, https://myapps.developer.ubuntu.com/dev/click-apps/4739/rev/2/ https://myapps.developer.ubuntu.com/dev/click-apps/4316/rev/3/ https://myapps.developer.ubuntu.com/dev/click-apps/4284/rev/8/ https://myapps.developer.ubuntu.com/dev/click-apps/4283/rev/16/ https://myapps.developer.ubuntu.com/dev/click-apps/4283/rev/17/
<ogra_> morning zyga
<mvo> ogra_: aha, please click on "request for manual review", then I can see them in the review queue, otherwise they are invisible for me
<mvo> ogra_: I can do that now myself
<mvo> ogra_: just for the next time, that click makes it easier for me to find them
<ogra_> ok
<ogra_> i wonder how to do that for the automated uploads then :P
<zyga> jdstrand: hey
<zyga> jdstrand: I didn't know you were around
<mvo> ogra_: I think we need to talk to jdstrand and see if we can drop the -all-root requirement
<mvo> ogra_: for the squashfs, I think that is causing the issues right now because the repack of the snap can not be done because of different parameters and this causes this manual review thing
<ogra_> mvo, well, at least special case os snaps
<zyga> jdstrand: I don't know if you saw the discussion on telegram; we were wondering about the apparmor cache, specifically what maintains the cache enabled by https://github.com/ubuntu-core/snappy/pull/635/files#diff-48ca5117699c941398b92fcd61caaed5R43
<mvo> ogra_: yes, or that
<ogra_> i think the --all-root was wanted (there was a bug)
<ogra_> Bug #1546821
<ubottu> bug 1546821 in Snappy "please add -all-root and -no-xattrs to mksquashfs options" [Undecided,New] https://launchpad.net/bugs/1546821
<sergiusens> ogra_, yes; the bug sequence was, make snapcraft support the os snap without all-root and remove the snappy build functionality
<sergiusens> wednesday's release will have that
<ogra_> sergiusens, ah, good to know
<ogra_> sergiusens, please leave me a few days with the removal from snappy though (even though i expect no issues with switching livecd-rootfs, if there are any we are screwed with the dailies)
<sergiusens> ogra_, I am not removing snappy build, that is on mvo and his merry friends :-)
<ogra_> ah, ok
<ysionneau> can ubuntu-device-flash generate separate .img files for each partition instead of a big img file?
<ogra_> ysionneau, nope, but kyrofa has a script to split it into two img files
<ogra_> (one for the boot stuff, one for writable
<ogra_> )
<ysionneau> I guess fdisk + losetup + dd should do the job?
<mvo> sergiusens: we still need that bit for various tests (and its ~5 lines) happy to hide it (and make it only available in the tests)
<ysionneau> but I'd like to have a look at the script anyway :)
<dholbach> davidcalle, want to have a chat about snappy/snapcraft docs in a bit? or shall we talk later?
<davidcalle> dholbach: can you do a quick one in ~20min?
<dholbach> yes, a quick one
<sergiusens> mvo, well I'm not the one pushing for it https://bugs.launchpad.net/snapcraft/+bug/1546821 look at comment #8
<ubottu> Launchpad bug 1546821 in Snappy "please add -all-root and -no-xattrs to mksquashfs options" [Undecided,New]
<sergiusens> mvo, you can hide it; but personally I think our QA would be a lot better if you use snapcraft's snap instead
<sergiusens> mvo, if it is just 5 lines it could also just be moved to the test runner code
<mvo> sergiusens: fair enough, yes, I think a separate package would be good
<mvo> sergiusens: anyway, let me look at this
<sergiusens> mvo, but of most importance; people like you and me need to stop using `snappy build`
<mvo> sergiusens: thats fine, can we make "snapcraft snap" not look for snapcraft.yaml maybe? this would allow us to keep using our tests
<sergiusens> mvo, have you used snapcraft snap? ;-)
<mvo> sergiusens: http://paste.ubuntu.com/15471199/
<sergiusens> mvo, `snapcraft snap DIR` :-)
<mvo> sergiusens: thanks! http://paste.ubuntu.com/15471206/ :P I guess it wants to tell me that the architectures field is mandatory
<popey> I spy new update coming down the pipe!
<popey> Updating canonical-pi2-linux (4.4.0-1004-raspi2+20160321.17-52)
<popey> \o/
<mvo> sergiusens: I will prepare a branch that replaces snappy build with snapcraft snap
<mvo> sergiusens: will snapcraft snap also run the click-reviewers-tools automatically?
<oparoz> Hello guys, I didn't RTFM, but I was just wondering. Can we have several snaps installed and communicte with one another? Redis snap, Libreoffice snap, all usable from a webapp snap?
<dholbach> davidcalle, let me know when you have time
<popey> is this expected when i update http://paste.ubuntu.com/15471238/ - to 4.4.0-1004-raspi2+20160321.17-52 ?
<davidcalle> dholbach: I do now :)
<dholbach> yes!
<kyrofa> Good morning
<kyrofa> ysionneau, those scripts are currently specific to the rpi2 image (they need to be generalized), but they're here: https://github.com/owncloud/pi-image/tree/master/image-creation-tools
<sergiusens> mvo, I need to make it run it; but I'm waiting for stabilization of the whole infra for that (wrt click review)
<sergiusens> as it might just end up confusing with all the churn
 * ogra_ tickles pitti with bug 1547033 ... would be nice to have that fixed before final release ;)
<ubottu> bug 1547033 in systemd (Ubuntu) "please allow /etc/mtab to be a pre-existing link on readonly filesystems" [Medium,New] https://launchpad.net/bugs/1547033
<ogra_> sergiusens, https://github.ubuntu.com/96boards/linux ??
<ogra_> (from your blogpost)
<ogra_> sergiusens, i assume there sneaked some wishful thinking in to take over github with ubuntu ?
<sergiusens> ogra_, lolz
<sergiusens> ogra_, let me fix that :-P
<kyrofa> sergiusens, elopio whew, so those examples were failing for everyone?
<sergiusens> kyrofa, yes, I dug into it last night; it is related to the snappy changes that landed yesterday
<kyrofa> sergiusens, ah, okay
<sergiusens> kyrofa, first -> binary_name = appname if appname == snapname else "snapname.appname"
<sergiusens> second, PWD for apps changed again
<sergiusens> to be PWD
<sergiusens> kyrofa, now the testing infra is broken ;-)
<kyrofa> sergiusens, yeah, and a number of environment variables were removed, too
<kyrofa> sergiusens, I see an opencv failure as well... trying to track that down
<ogra_> mvo, do you think we can do anything about the umount error messages on shutdown (i see a lot red on reboot)
<mvo> ogra_: what is that? do you have some more details?
<ogra_> mvo, /writable and some bind mounts cant be unmounted
<mvo> ogra_: hm, I check
<ogra_> i think we should just skip unmounting altogether, call sync and remouont ro
<ogra_> and not spit out an error :)
<pitti> ogra_: followed up to the bug, mind having a look?
<ogra_> pitti, i'll adjust that and we'll see :)
<pitti> ogra_: cheers
<ysionneau> kyrofa: thx !
<kyrofa> sergiusens, does the opencv example work for you on xenial? I'm getting libmvec errors
<kyrofa> ysionneau, no problem
<sergiusens> kyrofa, well the examples tests runs them, so I hope they do
<kyrofa> sergiusens, yeah mine failed... and it fails locally as well. I'll rerun them just to be safe
<noizer> What interfaces are there available for network?
<kyrofa> jdstrand, haha, using indent in the launcher now?
<sergiusens> kyrofa, don't run retest this as it will fail :-)
<jdstrand> kyrofa: yeah, I am spending some time in there :)
<kyrofa> sergiusens, :(
<jdstrand> mvo, ogra_: where do you want to drop -all-root?
<ogra_> jdstrand, for os snap builds
<ogra_> (we need the system-user-owned files and dirs there)
<jdstrand> background: -all-root is required to verify snaps from untrusted sources
<jdstrand> otherwise I can't resquash
<jdstrand> an os snap is of course trusted
<jdstrand> I'm pretty sure if I remove -all-root from the resquash we are going to get different users at some point, if not today
<jdstrand> but I can try
<jdstrand> ogra_: what about the kernel snap?
<ogra_> jdstrand, there it doesnt matter .. nor for the gadget
<kyrofa> sergiusens, ah, I was able to get rid of my local failure by upgrading gcc, g++ and libc6-dev
<jdstrand> ok
<sergiusens> jdstrand, I've been doing kernel snaps with all-root just fine
<jdstrand> ok good
<sergiusens> kyrofa, weird situation, abi breakage again?
<ogra_> it is only important for the system daemons to have their users around
<jdstrand> hopefully I can just remove -all-root if it is an os snap and it will work. but I might have to disable the resquash for them
<kyrofa> sergiusens, yeah not sure. Everything is broken!
<sergiusens> kyrofa, tests seem to be running fine now for your stuff ;-)
<jdstrand> mvo, ogra_: I added a card for -all-root and os snaps
<ogra_> thanks !
<ysionneau> will the ubuntu-device-flash available at http://people.canonical.com/~mvo/all-snaps/ubuntu-device-flash be packaged for ubuntu desktop 16.04 ?
<ogra_> ysionneau, there is a replacement in the works called ubuntu-image, though i was hoping mvo pushes the changes for bridging the time til thats ready if it takes longer
<kyrofa> mvo, yeah still worth landing I say
 * ogra_ isnt sure what the actual ETA for ubuntu-image is ... sergiusens knows though
<sergiusens> ogra_, you didn't join the meeting yesterday; so you didn't figure it out
<kyrofa> popey, I just noticed you tried to install the owncloud-pi gadget. Are you just looking for the owncloud snap?
<sergiusens> ogra_, now you might
<ysionneau> ogra_: ah ok
<ogra_> sergiusens, yeah, i totally missed while being busy releasing snaps to the store
<ogra_> ppisati, do you happen to have auboot binary for the rpi3 ?
 * ogra_ is to lazy to compile one :P
<ysionneau> hmmmm, so when snapcraft says 'architectures' when trying to build a gadget snap, it means?
<popey> kyrofa: yeah, i just thought I'd try installing that
<kyrofa> popey, oh okay, so not really looking for anything in particular?
<popey> well, owncloud in particular, yeah :)
<sergiusens> ysionneau, it means we have a bug :-)
<sergiusens> ysionneau, can you log one?
<kyrofa> popey, oh, just try `snappy install owncloud`
<ysionneau> you mean can I file a bug report ?
<sergiusens> ysionneau, yes please https://bugs.launchpad.net/snapcraft/+filebug
<sergiusens> ysionneau, I will add it to the 2.6 work due tomorrow
<popey> kyrofa: on 16.04?
<kyrofa> popey, indeed
<ysionneau> I'm really not used to your bugtracker and I don't even have an account
<ysionneau> but I guess it's the occasion
<popey> kyrofa: ok
<ysionneau> let me try that...
<kyrofa> popey, the gadget snap only exists for creating an image with the owncloud snap preinstalled
<kyrofa> sergiusens, I swear every time I run the example tests I get one more failure. I'm up to 4 now
<sergiusens> kyrofa, yeah I see the same
<sergiusens> fgimenez, any help ^
<sergiusens> ?
<kyrofa> The opencv failure is the same one I just got rid of locally by updating
<kyrofa> I wonder if the others are similar
<ysionneau> https://bugs.launchpad.net/snapcraft/+bug/1560481
<ubottu> Launchpad bug 1560481 in Snapcraft "snapcraft prints 'architectures' when trying to build a gadget snap" [Undecided,New]
<popey> kyrofa: does it start automatically once installed?
<kyrofa> popey, yes, though it takes a moment to generate mysql creds and stuff. Check the syslog
<kyrofa> popey, you'll see apache waiting for creds, and mysql initializing
<kyrofa> popey, on the rpi2, maybe a few moments ;)
<popey> it's been a while.
<sergiusens> kyrofa, ogra_ jdstrand https://github.com/ubuntu-core/snapcraft/pull/391
<popey> kyrofa: no apache or mysql processes running
<ogra_> sergiusens, looks good
<kyrofa> popey, hmm, see errors in the syslog then?
<popey> [340124.599445] audit: type=1400 audit(1458651897.178:59): apparmor="DENIED" operation="capable" profile="owncloud.canonical_mysql_9.0.0ubuntu1" pid=10400 comm="mysqld" capability=24  capname="sys_resource"
<popey> kyrofa: ah, works on my edge pi2, but not my stable pi2
<popey> guess this is expected?
<kyrofa> popey, uh oh, no it's not
<popey> heh
<kyrofa> popey, but I just released in an attempt to fix that
<kyrofa> popey, I apparently failed
<popey> no worries
<kyrofa> popey, can you give me the errors on the stable?
<popey> any particular logs?
<popey> http://paste.ubuntu.com/15471936/
<popey> that's dmesg last bunch of lines
<kyrofa> popey, just the syslog where they fired up. Those denials are normal
<ysionneau> hope my bug ticket is clear enough sergiusens
<popey> ricmm: fyi, the youtube-streamer demo (I think it's yours?) spams the syslog every 5 seconds after install http://paste.ubuntu.com/15471942/
<sergiusens> ysionneau, no worries; I know what you are after :-)
<sergiusens> ysionneau, in any case, gadget snaps in they future will be arch specific
<sergiusens> so this is rather a remporary thing
<ppisati> ogra_: yep
<ogra_> i cant even get a purp out of mine (i finally built an aarch64 one)
<ppisati> ogra_: https://github.com/piso77/ubuntu-embedded/blob/master/boards/raspi3/rootfs/boot/firmware/uboot.bin
<ppisati> ogra_: and here is an ubuntu img, if you want to do some debug etc
<ppisati> ogra_: http://people.canonical.com/~ppisati/ubuntu_embedded/ubuntu-embedded-16.04-raspi3.img.xz
<ogra_> well, i hopefully only need a gadget snap :)
<ppisati> ogra_: +1
<ogra_> bah+
<ogra_> reading uboot.env
<ogra_> *** Warning - bad CRC, using default environment
<ogra_> missing our patch
<ogra_> ppisati, how exactly did you build it ?
<ppisati> ogra_: you mean the steps?
<ppisati> export ARCH=arm; export $(dpkg-architecture -aarmhf); export CROSS_COMPILE=arm-linux-gnueabihf-
<ppisati> make rpi_3_32b_defconfig
<ogra_> ppisati, oh, 32bit ?
<ppisati> make ...
<ppisati> ogra_: yep
<ogra_> ah, there is a special config ... thats my error
<ppisati> ogra_: my uboot binary is of some days ago
<ppisati> ogra_: i think back then there was no 64b option
<ogra_> rpi_3_defconfig defaults to 64 in swarrens branch
<ppisati> i just noticed that
<ogra_> grmpf
<ogra_> still doesnt boot
<ogra_> i suspect my trusty gcc is to old or something
<ppisati> ogra_: i'm on wily FWIW
<didrocks> popey: it's mine, and yeah, it will spam you until you configure it!
<popey> :(
<didrocks> popey: which is better than failing IMHO
<didrocks> we can maybe just make it print once
<popey> my poor sd card
<popey> it's been spamming for days
<didrocks> why did you install something without having it running?
<popey> to look at it
<didrocks> (hem, look at the logs, you have way more spammer ;))
<popey> I can't believe you asked that question
<didrocks> but didn't configure it, so didn't look at it? :p
<popey> i wanted to see what was in the package, I didn't expect my syslog to be spammed for days as a result. "I'll configure that later"
<popey> "NO, YOU MUST CONFIGURE IT NOW!"
<popey> And I'll keep reminding you until your SD card wears out :)
<didrocks> popey: the issue is that if we didn't spam regularly, how would you know days after what to put in it?
<popey> Documentation
<popey> a README perhaps is the standard way
<didrocks> no way to expose the README in snappy
<popey> I can find it in the directory it's installed in
<didrocks> (forget people looking at the source git branch)
<didrocks> hum, I'm unsure
<didrocks> at least, it should print it once, ok
<popey> Thunderbird doesn't spam my syslog if I don't configure a mail account.
<didrocks> yeah, but configuring it is easier than snappy
<popey> Debateable :)
<didrocks> and you have a walkthrough
<popey> I don't believe that spamming the syslog is ever a right answer to "How should we tell the user that the app isn't configured"
<ogra_> ppisati, no go :( not sure why
 * ogra_ just built on a wily machine 
<didrocks> popey: remember you are not in the regular case, you are in the one installing something but not using it. However, I do agree, I can spam you once
<didrocks> popey: then, you go to answer people asking how to configure it :)
<didrocks> popey: mind opening a bug on the demo branch?
<didrocks> I'll do that on Friday
<popey> link?
<didrocks> http://github.com/ubuntu-core/demos
<popey> (I strongly disagree that people don't install and not configure stuff)
<didrocks> popey: I guess the real SD card issue is something else though, look at the logs you have, and yeah, we need ubuntu core to care about this
<popey> didrocks: done.
<didrocks> popey: link?
<popey> https://github.com/ubuntu-core/demos/issues/2
<ogra_> ppisati, was there any script i need to run ?
<ppisati> ogra_: oh yeah, after yui build the uboot binary
<ppisati> ogra_: you need to run...
<jdstrand> sergiusens: ack, thanks
<ogra_> i thought i remembered mkknlimage ... but cant find it
<ppisati> ogra_: mkknlimg
<ppisati> ogra_: https://github.com/raspberrypi/tools/blob/master/mkimage/mkknlimg
<ysionneau> sergiusens: is there something I can do in my snap.yaml to temporary work around the issue to keep working?
<sergiusens> ysionneau, use `snappy build` for now
<ysionneau> ah, works, thanks!
<kyrofa> ysionneau, note that will be going away soon, so move back to snapcraft once the bug is fixed
<ysionneau> allright, noted, thanks!
<ogra_> sigh .. no go
<fgimenez> sergiusens, no idea, it seems that 3 of the failures are consistent in each execution. we have a new test image fwiw, iirc that caused problems previously
<ysionneau> how can I make a kernel snap? any example?
<kyrofa> ysionneau, did you see the new Snapcraft release announcement? And sergiusens blog post?
<ysionneau> kyrofa: was it on snappy-devel ?
<ysionneau> I subscribed to this ML on the 10th of feb
<kyrofa> ysionneau, snappy-app-devel
<ysionneau> ah, I should subscribe to this one then
<kyrofa> ysionneau, indeed!
<kyrofa> Check the archives, sent out about 10 hours ago
<ysionneau> done.
<ysionneau> thx
<ysionneau> https://lists.ubuntu.com/archives/snappy-app-devel/2016-March/000645.html o/
<ysionneau> awesome!!
<sergiusens> ysionneau, bug reports welcome :-)
<ysionneau> ah, you need to have snapcraft build your kernel, maybe I can hack something by creating a squashfs out of my already built kernel+modules+initrd
<ysionneau> $ snapcraft --target-arch arm64 < !!!!!
<ysionneau> --target-arch ? :)
<ysionneau> so snapcraft is beginning to have some cross compilation notions ?
<ogra_> ppisati, i dont really get it ... do you do anything special ?
<ogra_> ppisati, i cant even get a burp out of the board with any uboot binary i build
<ppisati> ogra_: raspi3, right?
<ogra_> ppisati, yeah ... which compiler do you use ? just the gcc-5 eabihaf ?
<ogra_> *hf
<sergiusens> ysionneau, only for kernels
<ysionneau> but can any other plugin get the --target-arch value?
<ysionneau> I'll have a look anyway
<ysionneau> it would be cool if I can make my Alchemy plugin use that
<ysionneau> so that I don't need to set the TARGET_CPU via environmnent variable
<ppisati> ogra_: don't you get to the uboot console?
<ppisati> ogra_: i mean, nothing
<ppisati> ogra_: zero output on the serial?
<ogra_> nothing
<ogra_> rightr
<ppisati> ogra_: oh wait
<ppisati> ogra_: is it the first time you use it?
<ogra_> if i copy yours in place it gets me the console but obviously the snappy patches are missing
<ogra_> yes
<ogra_> copying mine back in place gets me total silence on the serial
<ppisati> ok
<ppisati> let me try to rebuild one
<ogra_> mind throwing http://paste.ubuntu.com/15472180/ in ?
<ogra_> ppisati, you are using the swarren rpi_dev branch ?
<ppisati> yes
<ogra_> and only --dtok as option to mkknlimg ?
<ogra_> (ro also --283x=
<ogra_> --283x)
<ogra_> *or
<ogra_> (though it doesnt seem to make any difference here )
<ogra_> my only idea is that we use different compilers or so
<sergiusens> kyrofa, fwiw, I see opencv failing now too (on the builders)
<kyrofa> sergiusens, urgh. Do the builders update first?
<sergiusens> ysionneau, implement set_target_machine in your plugin
<sergiusens> kyrofa, we can ask elopio like live now :-)
<kyrofa> sergiusens, good idea
<kyrofa> elopio, standup?
<ppisati> ogra_: i just compiled the tip of rpi-dev and uboot doesn't work here either
<ogra_> aha
<ogra_> do you knwo which commit you used ?
<ppisati> ogra_: ok
<ppisati> ogra_: git checkout -b rpi_dev_32bok f135e8f
<ppisati> ogra_: make rpi_3_32b_defconfig
<ppisati> ogra_: make ...
<ppisati> ./mkknlimg --dtok --ddtk --283x u-boot/u-boot.bin myuboot.bin
<ppisati> and it will work
<ppisati> just tested
<ppisati> either he broke 32bits or we are doing something wrong with the latest
<ppisati> but this will work
<ogra_> hmm git acts up
<ogra_> ogra@styx:~/all-snaps/rpi3/u-boot$ LC_ALL=C git checkout -b rpi_dev_32bok f135e8f
<ogra_> fatal: Cannot update paths and switch to branch 'rpi_dev_32bok' at the same time.
<ogra_> Did you intend to checkout 'f135e8f' which can not be resolved as commit?
<ogra_> ppisati, thats after a fresh: git clone git://github.com/swarren/u-boot.git
<ppisati> ogra_: i wonder if he deleted that commit, and the corresponding object is not present in the upstream repo anymore
<ogra_> :(
<ppisati> ogra_: i can give you a copy of my uboot tree
<ppisati> ogra_: until we find what's going on
<ogra_> yes please ... just tar it up or so
<ppisati> it's tarring...
<ogra_> swamped under hot tar ?
<ppisati> ogra_: http://people.canonical.com/~ppisati/u-boot.tgz
<ogra_> thx !!!
<ppisati> ogra_: today i got a new internet connection and a new router
<ogra_> cool ... how fast ?
<ppisati> ogra_: my firewall&c is a bit fucked up ATM
<ppisati> 100Mbit / 50Mbit
 * ogra_ just switcvhed to 50/10 
<ppisati> d / u
<ogra_> the best i could get here
<ogra_> (after 10 years with 2/2 ...)
<ppisati> i guess you live far from a city
<ogra_> i live in the middle of a city :P
<ppisati> doh!
<ppisati> :)
<ogra_> germany is a third world country wrt internet speed
<ppisati> you must something really bad to your isp then
<ppisati> neeee
<ppisati> italy is worst
<ppisati> i justgot lucky
<ppisati> i have FTTH
<ogra_> we dont even have 2% fiber coverage afaik
<ogra_> and DSL max speed is around 100MBit ... but you have to be lucky
<ppisati> here vodafone is selling 300 / 30 fiber
<ppisati> but i didn't want to switch isp
<ogra_> (my wire could go up to 70 but then it would get shaky ... old cables ... )
<Trevinho> ppisati: I told you to do that... :-)
<ppisati> (now i'm on fastweb / swisscom)
<ppisati> Trevinho: you have fweb too? or vodafone?
<Trevinho> ppisati: vodafone, but using telecom actually.
<Trevinho> ppisati: I mean, they've not their fiber network here yet (building atm)
<ppisati> Trevinho: yeah, i was scared about downtime, etc
<ppisati> Trevinho: so i got an upgrade from my existing isp
<Trevinho> ppisati: i've to say it's reaaaaally good in that terms. I was worreid, but it's not like their bad adsl
<ogra_> in most of germany the copper is still from the 70s ... i think thats the main prob
<ppisati> ogra_: i think pretty much everywhere copper sucks
<ppisati> ogra_: i must admit, having real fiber popping out of your wall is very nice :)
<ogra_> yeah
<ogra_> ppisati, ok, now i end up with FTD errors
<ogra_> *FDT
<ogra_> Hit any key to stop autoboot:  0
<ogra_> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
<ogra_> No FDT memory address configured. Please configure
<ogra_> the FDT address via "fdt addr <address>" command.
<ogra_> i got device_tree_address=0x02000000 in config.txt and also have my env set up to use fdt addr 0x02000000
<ogra_> ppisati, do you have your uboot.env.in somewhere ?
<ysionneau> sergiusens: it seems I need a snapcraft.cfg or something to use the kernel plugin?
<ysionneau> or else the load_config will return {} and the  storeapi.download() will fail
<sergiusens> ysionneau, oh, maybe a bug is in order; but you need to `snapcraft login` first
<ysionneau> ah!
<ppisati> ogra_: https://github.com/piso77/ubuntu-embedded/blob/master/boards/raspi3/rootfs/boot/firmware/uboot.env
<ogra_> ppisati, i'm looking for the content, not the blob :)
<ppisati> ogra_: heh :)
<sergiusens> ysionneau, it's necessary to obtain the generic initrd found in the os snap
<kyrofa> elopio, examples tests are still failing it seems
<ysionneau> sergiusens: works after snapcraft login :) bear in mind I'm a snapcraft noob ! thx !
<ppisati> ogra_: http://pastebin.ubuntu.com/15472788/
<sergiusens> ysionneau, no worries; your bug reports will be welcomed as we want to provide the easiest experience possible
<ppisati> ogra_: i'm out for a bit
<ogra_> ppisati, ok, i cant seem to load any devicetree at all
<ogra_> looks like you dont do anything different in your env
<ppisati> ogra_: which firmware version are you using?
<ogra_> ppisati, the one from your package in the "embedded" PPA
<ppisati> ogra_: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+sourcepub/6187265/+listing-archive-extra
<ogra_> right, exactly that
<ppisati> ogra_: and the dtb is called...
<ppisati> bcm2710-rpi-3-b.dtb?
<ogra_> and the dtb from the latest 4.4. kernel
<ysionneau> sergiusens: cool :) done! https://bugs.launchpad.net/snapcraft/+bug/1560553
<ogra_> (though by now i tried all of them upstream, our kernel, and from your test img)
<ubottu> Launchpad bug 1560553 in Snapcraft "snapcraft error message is not very helpful when using storeapi without being logged in" [Undecided,New]
<ogra_> ppisati, right
<ppisati> if you skip the dtb in memory, you load it from uyboot and pass it to the kernel
<ppisati> ogra_: does it work?
<ogra_> ah, we dont have a concept of that in snappy ... i'll try
<ogra_> (we always use what the blob gives us in ram since we need overlay support)
<ogra_> U-Boot> fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
<ogra_> reading bcm2710-rpi-3-dtb
<ogra_> ** Unable to read file bcm2710-rpi-3-dtb **
<ogra_> hmm
<ogra_> oh, copy paste messes up the uboot shell
<ogra_> fun
<ppisati> ah
<ppisati> fuck me
<ppisati> sudo ./mkknlimg --dtok ../../u-boot/u-boot.bin myuboot.bin
<ppisati> fixed the uboot in memory problem for me
<ppisati> try it out
 * ppisati really rushes out now, biab
<ppisati> ogra_: ^
<ogra_> ok
<sergiusens> elopio, fantastic :-/ http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/317/testReport/junit/test_busybox/BusyBoxTestCase/test_busybox/
<kyrofa> sergiusens, that's the opencv error
<kyrofa> sergiusens, so something isn't updated
<elopio> cannot find /lib/x86_64-linux-gnu/libmvec.so.1
<kyrofa> elopio, yeah, I fixed that by updating gcc g++ and libc6-dev
<kyrofa> I assume it was actually libc though
<elopio> kyrofa: sergio added apt-get upgrade.
<elopio> ah E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
<kyrofa> elopio, ah, so it didn't actually happen
<elopio> fgimenez: do you have a good solution in mind to make sure that the slaves are always up-to-date before jobs run?
<elopio> maybe a nightly redeploy?
<elopio> sergiusens: that solution might not be too good, because it forces us to have one single execution at a time.
<elopio> that means that if we have three PRs that want to run tests, the last one will have to wait like 2 or 3 hours.
<sergiusens> elopio, what solution? the hackish thing I did?
<elopio> yes, apt-get in the test script.
<sergiusens> where should it go?
<elopio> on the other hand, we are ok with only one apt-get upgrade per day-ish, so it's fine to let the other jobs fail when they can't get the lock.
<elopio> sergiusens: I don't know, that was my question for fgimenez.
<fgimenez> elopio, nightly redeploy sounds very good, that way we can make sure we have the versioned code up to date
<elopio> fgimenez: we would have to trigger also the regeneration of the dockers, right?
<fgimenez> we can begin with the current (and weak) validation and improve it as we find holes
<sergiusens> elopio, fgimenez can we force a redeploy now?
<elopio> sergiusens: I'm forcing an upgrade now.
<sergiusens> ok, whatever gets the job done
<fgimenez> elopio, the engine can stay, only the containers should be updated
<elopio> redeploying when there's a queue of pending executions is not that good.
<ogra_> crap
<ogra_> bah, no mvo
<fgimenez> elopio, but before any new redeploy we need to fix the extraction of the config.xml files of the jobs
<elopio> fgimenez: you mean, removing the old and keeping just the new ones?
<fgimenez> elopio, yep, keeping the ones that come with the container
<elopio> ogra_: heads up that I'm enabling now the dput job from master. Could you do your thing after the new deb is in place so we get the new version in edge?
<ogra_> elopio, what deb is that ?
<ogra_> ubuntu-snappy(-cli) ?
<elopio> ogra_: yes. take a look: http://162.213.35.179:8080/job/github-snappy-daily-ppa/
<elopio> it's currently dputing to a test ppa. I've just changed it to do it from now on on the image ppa.
<ogra_> elopio, hmm,. that shoudl go to the archive, no ?
<ogra_> we are not supposed to use PPAs in 16.04
<elopio> ogra_: for edge, I think we must use PPAs. I wouldn't want to put to the archive directly from master.
<elopio> once we are ready to promote to stable it's when we should update the archive, I think.
<ogra_> elopio, well, the ubuntui-core snap doesnt make a difference between edge/stable ... it is just building from the archive (which you can override from the PPA but we are supposed not to)
<ogra_> we dont have any separate ubuntu-core snap build
<elopio> ogra_: the edge you published yesterday was build from the image ppa, right?
<ogra_> elopio, it has the PPA enabled but we removed all xenial packages from there
<ogra_> (apart from the dragonboard kernel which will be moved ot the archive this week)
<ogra_> elopio, the point is that we cant have PPA snappy in ubuntu-core when we release it ... this is the official snap
<ogra_> we would need some ubuntu-core-edge snap for that ... that would mean to introduce a completely new product on cdimage
<ogra_> (not really trivial)
<elopio> ogra_: but, don't you agree that we shouldn't update the archive until we know that this snappy package is stable?
<ogra_> elopio, we should, but we cant do the testing in the production snap
<elopio> so, yes, we have a circular mess here.
<ogra_> right
<ogra_> we can indeed do it like you want until release
<ogra_> after all the 16.04 ubuntu-core snap isnt officially released yet
<ogra_> but the problem needs solving
<elopio> ogra_: what if the PPA has only this ubuntu-snappy deb?
<elopio> Then, we use the PPA only as a staging place for this deb, but is built using all the dependencies from the archive. Every day, we dput a new ubuntu-snappy to this ppa. Every day, you take this new ppa and build a snap. Every day, we publish this snap to edge.
<elopio> Once we are ready to go to stable, we both promote the snap and push the deb into the archive?
<ogra_> elopio, you would have to delete the deb from the PPA before we build the official snap
<ogra_> each time
<elopio> ok, there's a step missing. What I don't like is to have to generate a new snap. I want just to promote the same snap we put earlier into edge.
<elopio> but that breaks your requirement of not using the ppa for the official snap.
<sergiusens> elopio, there is no problem with putting a new snappy-cli in the archive
<sergiusens> few will directly consume it
<sergiusens> unless you really don't trust it; then automating this step is not really good
<elopio> sergiusens: isn't it the same package that will be used for snappy-dimension on classic ?
<sergiusens> they will in the end consume the snap
<sergiusens> elopio, yes they will btw
<elopio> I still don't like updating the archive once a day.
<sergiusens> elopio, what shall we do with https://github.com/ubuntu-core/snapcraft/pull/388 ?
<sergiusens> are we waiting on something?
<elopio> ogra_: where does this no-ppa requirement come from? If the PPA only has the exactly same deb that will go to the archive, the result is the same when we use the ppa or the archive.
<ogra_> elopio, sabdfl
<ogra_> elopio, in 16.04 only the archive should be used
<ogra_> updates only via SRU
<sergiusens> elopio, the no PPA requirement makes perfect sense; it should have never been a PPA
<elopio> sergiusens: we are waiting on the slaves to dist-upgrade
<sergiusens> elopio, ah, ok, thanks :-)
<elopio> but if we want a daily edge, then we would have to SRU every day.
<ogra_> elopio, which wont fly with the SRU rules :)
<ogra_> SRUs need to stay 2 weeks in quarantaine
 * ysionneau flooding bugs
<elopio> so that makes it even bad if we don't want a daily edge.
<sergiusens> ysionneau, what else did you find?
<ysionneau> https://bugs.launchpad.net/snapcraft/+bug/1560570
<ubottu> Launchpad bug 1560570 in Snapcraft "snapcraft needs to export CROSS32CC var when building arm64 kernel" [Undecided,New]
<elopio> let's say we have a two week cycle. At the end of the second week we want to release, but we will have to put the version for two weeks in quarantine
<ogra_> elopio, well, we would need to have a whole cdimage setup for an ubuntu-core-edge
<ysionneau> https://bugs.launchpad.net/snapcraft/+bug/1560569
<ubottu> Launchpad bug 1560569 in Snapcraft "snapcraft kernel plugin misses the bc dependency" [Undecided,New]
<ogra_> elopio, which is possible but quite some work, nothing i can "just do"
<elopio> ogra_: but I also don't want an ubuntu-core-edge. I just want the same package to be promoted from edge -> stable
<ogra_> elopio, well, then your daily builds need to go to the archive
<elopio> ogra_: I think that for me, the least bad option of what you told me is to generate the edge snap from the ppa. Once we are ready to move to stable, put the deb into the archive and generate the stable snap from the archive.
<elopio> it kind of invalidates part of the testing we do during the week, but it's not terrible.
<elopio> all the other options look worse to me. ogra_: what's your prefered option?
<ogra_> well, not using the PPA :)
<ogra_> or getting permission to use it all the time ...
<elopio> ogra_: so with not using the PPA do you mean, daily pushes to the archive, or no daily edge?
<ogra_> daily to the archive
<ogra_> but that wont fly witgh the SRU policy
<elopio> ok, I'll send an email. sergiusens: does what I said make sense to you? Or am I missing another requirement here?
<sergiusens> ogra_ and ppisati, can you comment on https://bugs.launchpad.net/snapcraft/+bug/1560570 please. I feel estranged
<ubottu> Launchpad bug 1560570 in Snapcraft "snapcraft needs to export CROSS32CC var when building arm64 kernel" [Undecided,New]
<ysionneau> or maybe it's just a need for tegra (x1?) kernels ?
<ysionneau> but by looking at the file path, it seems arm64 generic
<ogra_> sergiusens, i'll leave that to ppisati
<sergiusens> ysionneau, it confuses me since I'm not a kernel guy and I see 64bit and 32bit mixups in there
<ysionneau> yep
<ysionneau> but I can confirm that in our build system we also set CROSS32CC
<ogra_> ysionneau, any reason to not use an aarch64 gcc ?
<ysionneau> it's consistent with the web link I've put
<sergiusens> ysionneau, seems hackish tbh
<sergiusens> ogra_, https://devtalk.nvidia.com/default/topic/894945/jetson-tx1/jetson-tx1/post/4742474/#4742474
<ysionneau> ogra_: no idea, it's what we use here and it's also what's on the web link
<ysionneau> the kernel is compiled using aarch64 toolchain, but a few parts are compiled using "VDSO32C" makefile variable
<ysionneau> which is set from CROSS32CC
<ogra_> oh my
 * ogra_ agress with sergiusens ... seems hackish
<ysionneau> or maybe ... https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/arch/powerpc/Makefile
<ysionneau> do something like CROSS32CC = $(CC) -m32
<sergiusens> ysionneau, yeah, powerpc is 32bit :-)
<ogra_> ppc32tegra ?
<ogra_> :)
<ysionneau> o/
<ysionneau> only source I find for this hack is https://devtalk.nvidia.com/default/topic/917802/issue-with-building-nvidia-kernel-for-tx1/ and https://devtalk.nvidia.com/default/topic/923810/jetson-tx1/rebuilding-the-tegra-tx1-kernel-from-source/
<sergiusens> ysionneau, fwiw I marked this invalid as you can solve it in your snapcraft.yaml https://bugs.launchpad.net/snapcraft/+bug/1560569
<ubottu> Launchpad bug 1560569 in Snapcraft "snapcraft kernel plugin misses the bc dependency" [Undecided,Invalid]
<kyrofa> sergiusens, elopio still waiting on the upgrade? How are you guys seeing that, anyway?
<sergiusens> kyrofa, I can't see anything; I'm shooting blanks ;-)
<sergiusens> err, shooting in the dark :-)
<kyrofa> sergiusens, well, where did you put the dist-upgrade in the first place?
<ysionneau> sergiusens: arg sorry!
<kyrofa> sergiusens, or was that in that one git repo?
<elopio> kyrofa: I'm dealing with the last slave.
<sergiusens> kyrofa, inside the jenkins instance; but they removed that in favor of something else
<elopio> I found the problem: libc-dev-bin : Depends: libc6 (> 2.23) but 2.21-0ubuntu6 is installed
<sergiusens> elopio, dist-upgrade?
<sergiusens> ysionneau, no worries
<ogra_> ppisati, http://paste.ubuntu.com/15473201/ ... but sadly it hangs there (with blinking cursor though)
<elopio> sergiusens: yes, solved with install -f and dist-upgraded again.
<elopio> should be done soon.
<sergiusens> ysionneau, I still have to think about that CC thing; you can do it from the outside (as in `CCXXXX=xxxx snapcraft --target arm64`) if you want
<ysionneau> yes for now I do export it from my shell before running snapcraft
<ysionneau> it's not a blocker for me
<ysionneau> I have to confess I'm not a Tegra kernel export either ... so I don't know if it's a good thing for you to integrate that
<sergiusens> ysionneau, k; I'll leave the bug open in case more people run into it; this one I guess will go in if the population seeing it is huge
<ysionneau> but I need it to compile
<ysionneau> btw I've tried -m32 from aarch64 toolchain, does not seem OK :o
<sergiusens> ysionneau, from the bc thing and others it seems it is an android kernel this is based out of
<ysionneau> let me ask but it's highy probable
<ysionneau> at least I see some android merges in the git history
<sergiusens> ysionneau, thought so :-)
<sergiusens> elopio, so are we good?
 * sergiusens is getting anxious ;-)
<sergiusens> I bet kyrofa is too
 * kyrofa is indeed, he has all sorts of stuff queued up
<elopio> sergiusens: good, but the slave is still unpacking debs.
<elopio> they are slow. Maybe we should use the slaves only to direct scripts to scalingstack instances.
<elopio> ok, done. I'm retesting my branch.
<kyrofa> Thanks elopio! Hopefully that fixes things
<ysionneau> allright, kernel snap is done o/
<ysionneau> sergiusens: your kernel plugin works well o/ thanks!
<ysionneau> any idea what this could be? http://paste.ubuntu.com/15473724/
<ogra_> ysionneau, you dont need --developer-mode with the all-snaps u-d-f
<ogra_> tough the issue looks like something with your gadget
<Laney> snappy friends
<Laney> I was looking at doing the seed change for xenial that you are asking for
<Laney> but... https://paste.ubuntu.com/15473751/
<ogra_> Chipaca, ^^
<ogra_> i assume they would rather seed ubuntu-snappy-cli to not get the systemd services installed
<ogra_> s/would/should/
<sergiusens_> elopio, kyrofa we are back in business
<kyrofa> sergiusens_, YES!
<ogra_> you business people you
<elopio> \o/
<Laney> ogra_: I'm off in 5 minutes - maybe you can execute the seed/meta change when someone waks up?
<Laney> https://bugs.launchpad.net/ubuntu/+source/ubuntu-snappy/+bug/1548887
<ubottu> Launchpad bug 1548887 in ubuntu-snappy (Ubuntu) "[FFe][MIR] ubuntu-snappy and install it by default" [Undecided,Fix committed]
<ogra_> Laney, well, *if* someone wakes up
<Laney> sure
<ogra_> not sure if mvo planned to come back today ... and Chipaca's IRC client is a zombie since the telegram group exists
<Laney> It's really weird
<ogra_> (would really be nice if he could just shut it down)
<Laney> sometimes this seems urgent
<Laney> but nobody is actually pushing the change
<Laney> so I don't really understand what's going on tbh
<ogra_> well, i think it is just the wrong package ... i suggested -cli before but smoser said he'd like ubuntu-snappy instaed
<ogra_> i think the systemd units come from the ubuntu-snappy package and -cli will omit them ...
<Laney> mvo re-confirmed on the bug after I asked
<ogra_> you definitely do not want them
<Laney> was assuming that having it on the beta is a good thing
<Laney> but hey ho
<ogra_> yeah, it would be
<ogra_> but if you cant reach anyone who can make that decision ...
<Laney> nobody is chasing though
<Laney> and they're apparently asking for the wrong thing
<Laney> so ?!?!?!
<ogra_> *shrug*
<Laney> you see what I mean :P
<ysionneau> btw where can I fetch the os snap? (or do I need to generate it? how?)
<ysionneau> I used the os.snap which appeared in my kernel snap parts dir
<ogra_> ysionneau, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<ogra_> just grab the one for your arch
<ysionneau> should it be the arch of the kernel or user space?
<ogra_> or simply use: -os ubuntu-core.canonical
<ogra_> that will pull the last released one from the store
<sergiusens_> ogra_, no need for .canonical iirc
<ogra_> oh ?
<ogra_> when was that dropped ?
<jdstrand> kgunn: is it possible to test the mir snap in a qemu vm?
<sergiusens_> ogra_, not dropped; it is optional
<ogra_> well, it used to be mandatory for a while :)
<ysionneau> not sure what's wrong with my gadget snap
<sergiusens_> jdstrand, using virt-manager it is easier; you need a different display
<sergiusens_> ogra_, we setup an alias :-
<sergiusens_> :-)
<ogra_> ah
<Chipaca> looking...
<ogra_> Chipaca, !
<ogra_> alive !
<Chipaca> ogra_, not a zombie! just even more lagged
<ogra_> :D
<ysionneau> http://paste.ubuntu.com/15473862/ here is my meta.yaml
<jdstrand> sergiusens_: you're saying it will work in virt-manager?
<Chipaca> people always ping me at 6pm :-(
<ysionneau> 19:01 < ogra_> or simply use: -os ubuntu-core.canonical < ok!
<Chipaca> um
<ogra_> ysionneau, that will just produce an empty gadget
<ogra_> you dont define any files
<Chipaca> i don't think you should install those services on a system with apt-get
<kgunn> jdstrand: right, that's my understanding is that other vm's don't have nicely configured display/gfx stacks
<jdstrand> I can use virt-manager all day :)
<jdstrand> ok, thanks
<ogra_> Chipaca, thats why i suggested to seed -cli instead
<ogra_> (assuming that doesnt ship the units)
<kgunn> jdstrand: curious, you just getting around to display-server policy stuff?
<Chipaca> this is mvo territory i'm afraid
<ogra_> then we have to wait i guess
<jdstrand> kgunn: sadly no. still blocked, but hopefully soon
<jdstrand> I wanted to test a launcher change
<kgunn> ok, lemme know if you have any probs
<Chipaca> ogra_, i've not looked in to what's needed; it might be ubuntu-snappy itself, with the services adhoc-disabled somehow
<Chipaca> i've just never had to look :-)
<ogra_> heh, same here
<Chipaca> i'd love to *know*, of course, but my bandwidth is only so much
<ysionneau> ogra_: I think I'm fine with an empty gadget for now
<ogra_> ysionneau, but ubuntu-devicel-flash isnt :)
<ysionneau> ok =)
<ogra_> you use the ubuntu-device-flash binary from mvo's all-snaps dir ?
<ysionneau> yes
<Chipaca> ok, back to making dinner for me
<ogra_> Chipaca, enjoy
<ysionneau> ah indeed I've put a dummy file and now it goes forward to the next error
<ogra_> good
<ysionneau> ../paros_gadget/paros_1.0_all.snap failed to install: exit status 2
<ysionneau> o/
<ysionneau> maybe it should be absolute path
<ysionneau> nop, same
<ogra_> no, its the content
<ogra_> so you have a dtb file thats called tegra-x1 ?
<ysionneau> no
<ysionneau> stat("/tmp/diskimage828293005/tegra-x1.dtb", 0xc8202e0448) = -1 ENOENT (No such file or directory) <= indeed
<ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi2/meta/snap.yaml
<ogra_> have a look at that file
<ysionneau> yes I based my snap from this and from the gadget documentation
<ogra_> you need the boot-assets ... and your platform entry should be the same as your dtb
<ysionneau> allright, let's do this
<ysionneau> maybe this field should be renamed "dtb" instead of platform :o
<ysionneau> so that it's more clear what you are supposed to put
<ogra_> well, the gadget is supposed to becompletely re-worked (i learned today) ...
<ysionneau> ahah, ok
<ogra_> elopio, so whatever we'll do with the PPA stuff, lets for now just do it as you said ... (and perhaps start a mail discussion about how we want to finally fix this process) ... and let me know when i should hit the button for a build
<ogra_> we are still in pre-release after all
<elopio> ogra_: I sent the mail. Let me dput...
 * ogra_ doesnt want to be the blocker
<elopio> ogra_: oh, you are not at all. We just need to finish the details of how to connect everything.
<elopio> ogra_: in his update from yesterday, mvo added a changelog entry for the upload. Should I do that?
<elopio> with my current dch, I get a version that's lower than his.
<ogra_> then it wont be pulled in
<ogra_> you need a higher version
<ogra_> (livecd-rootfs is dumb ... it just pulls the latest available versions)
<jdstrand> kgunn: so, I installed it and rebooted and see this in the logs: http://paste.ubuntu.com/15474097/
<jdstrand> kgunn: I'm using 'vmvga': http://paste.ubuntu.com/15474110/
<jdstrand> this is the same setup I would use to run unity7
<elopio> ogra_: no, that makes sense. But what's the trick to get a version number like 1.7.3+20160322ubuntu1~ppa3 automatically?
<elopio> I'm not sure how to increase the date of the previous entry.
<kgunn> jdstrand: hmmm....fails on the vt arg
<jdstrand> kgunn: this is on 16.04. is there a mir snap in the store for 15.04?
<jdstrand> I can try there too
<kgunn> jdstrand: i took down the 15.04 one i think
<jdstrand> that would explain why I couldn't snappy search it
<jdstrand> is https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ up to date?
<kgunn> jdstrand: yes
<kgunn> jdstrand: and i just now tested against snapcraft2.5
<kgunn> and it worked fine
<jdstrand> kgunn: do you have a vm where this works? if so, can you paste 'virsh dumpxml <vmname>'
<jdstrand> kgunn: I downloaded the mir from the store. should I be using snapcraft like in the instructions?
<kgunn> jdstrand: nah, that snap should work fine
<kgunn> jdstrand: i'm using Virtual Machine Manager
<kgunn> which
<jdstrand> yeah that's fine
<jdstrand> what is the name of the vm?
<jdstrand> in a terminal you should be able to do 'virsh list --all'
<jdstrand> to see the names
<ogra_> elopio, you dont want to increase the date but turn ubuntu1 to ubuntu2
<jdstrand> then if you could paste 'virsh dumpxml <your vm name>' that would be great
<ogra_> (that is what will effectively land in the archive)
<elopio> ogra_: that's easy, with -i. But that would still be less than the one mvo uploaded. Should I delete that deb?
<jdstrand> kgunn: ^
<kgunn> jdstrand: https://pastebin.canonical.com/152534/
<jdstrand> ah qxl
<jdstrand> kgunn: thanks!
<elopio> ogra_: also I can't combine -i, with the --local to add the prefix ppa# that mvo told me to use.
<elopio> these tools...
<jdstrand> kgunn: ok, progress. a black screen :)
 * jdstrand builds the mir client snap
<kgunn> ;)
<jdstrand> I have clocks :)
<jdstrand> kgunn: ^
<kgunn> i assumed you ooo'd and awww'd
<jdstrand> kgunn: curious if it makes sense to upload mir-client-demo or soemthing
<ogra_> elopio, well, you could assemble the version externally and just pass it to dch
<jdstrand> kgunn: it is very cool-- I did! :)
<elopio> ogra_: yes, I went that way. Failed to build on armhf, I'm reporting a bug.
<ogra_> elopio, fun
 * ogra_ calls it a day
<elopio> have a good night ogra_!
<ogra_> and you a good rest of the day :)
<kyrofa> elopio, is sergio off for a bit?
<elopio> kyrofa: I didn't notice when he left. Maybe lunch?
<kyrofa> elopio, he pinged out a bit ago. Yeah, maybe
<elopio> kyrofa: I'm about to take a lunch break too. I quickly saw your clean branch, which looks awesome
<elopio> I'll look at it all when I'm back.
<kyrofa> elopio, oh good! Excellent, thank you :) . I've got some more ready when that one lands
<elopio> kyrofa: this state, partial clean and resume look nice. What do you think about putting some integration tests in there?
<kyrofa> elopio, yeah I'll do that when things are actually cleaned (that PR is just preliminary stuff)
<elopio> great. To be clear, I'm not asking for this branch :)
<elopio> we can define some important use cases, and make sure that the binaries work for them with tests. Maybe leave that for next week, and I'll help you writing some.
<kyrofa> Sounds good
<ezraholm50_TAM> hey guys, could anyone help me get webmin running on snappy?
<genii> !webmin
<ubottu> webmin is no longer supported in Debian and Ubuntu. It is not compatible with the way that Ubuntu packages handle configuration files, and is likely to cause unexpected issues with your system.
<genii> ...so probably not
<ezraholm50_TAM> ah great... thnx for the heads up
<ezraholm50_TAM> anyway, aside from snap, it works great on my 5 ubuntu 14 to 16 systems
<ezraholm50_TAM> i just need to easily figure out some stuff that i would rather do with some kind of a UI then on cmd line
<ezraholm50_TAM> checking out deb2snap right now
<roadmr> is there a way to get "snapcraft snap" to rebuild if files changed? Right now I have to rm -rf parts stage which feels super kludgy
<kyrofa> roadmr, indeed, it's yucky. Unfortunately not just yet, but it's in progress
<roadmr> kyrofa: thanks :) I can do it that way in the meanwhile, no problem
<roadmr> is there a way to run a command at snap installation time? use case is e.g. a custom ssh server for which I'd like to generate keys when the snap is installed (rather than shipping the same set of keys to every user :)
<kyrofa> roadmr, no, but you can check to see if keys already exist, and if not, generate them
<roadmr> kyrofa: that works! thanks :)
#snappy 2016-03-23
<ccfiel> hello
<ccfiel> silence :)
<kyrofa> ccfiel, hey there :)
<ccfiel> hello kyrofa! :)
<ccfiel> kyrofa, have you used snappy? :)
<kyrofa> ccfiel, indeed I have
<ccfiel> kyrofa, in what application? if you dont mind :)
<kyrofa> ccfiel, of course not. Well, first of all, I work on it. Snapcraft in particular. I've also packaged a few different things, such as a PiGlow service for the raspberry pi 2 and ownCloud
<ccfiel> kyrofa, I am still a newbe here still teting the example. I just wondering is ubuntu core read only OS and you snap application on it?
<kyrofa> ccfiel, not really, things are just really confined. Parts of it are read-only since snaps are packaged with squashfs
<kyrofa> ccfiel, each snap has a few different directories where they can write
<kyrofa> Those directories are specific to that snap and no other snap can write to/read from them
<ccfiel> kyrofa, oh i see because for now I have a raspberry pi with raspbian on it and monitoring some sensors. Its running great but one issue I encounter is if there is a power outage sometime the system corrupt I have to get a monitor and keyboard to fix it.
<ccfiel> kyrofa, would it solve this in ubuntu core? :)
<ccfiel> kyrofa, am i in the right track?
<kyrofa> ccfiel, I guess that depends on what exactly the problem is. What is getting corrupted? How do you go about fixing it?
<ccfiel> kyrofa, just a simple fsck and done
<kyrofa> ccfiel, ah, so the filesystem itself. Honestly I'm not sure if that's a problem you'd run into with ubuntu core
<kyrofa> ccfiel, I know the guy I'd ask, but he's in germany and is thus likely asleep
<ccfiel> kyrofa, I was reading the site and documents it claims ubuntu core/snappy is for loT so if you have a device that is loT it should be like an appliance and should behave like one :)
<kyrofa> ccfiel, indeed. Such checks may be run on boot, but I'm not sure
<ccfiel> kyrofa, if ubuntu core is like our phone that the main OS core is readonly and the application is sandbox then this will be my solution :)
<ccfiel> kyrofa, I tried the sample snapcraft i tried "snapcraft stage" it works successfully but there no .snap file. I tried "snapcraft assemble" it always says FileExistsError: [Errno 17] File exists: '/home/ccfiel/snappy/snapcraft/examples/mosquitto/snap/meta/'
<ccfiel> any ideas?
<kyrofa> ccfiel, try `snapcraft clean` and then simply run `snapcraft`
<ccfiel> kyrofa, still the same error :(
<kyrofa> ccfiel, so when you run `snapcraft clean` that entire `snap` folder should be gone, yes?
<ccfiel> kyrofa, yes it has
<kyrofa> ccfiel, pastebin the log for me
<ccfiel> kyrofa, http://pastebin.com/hqMxhiUX
<stgraber> jdstrand: can you review the lxd I uploaded in the store this morning when you have a moment? thanks
<ccfiel> kyrofa, what version snapcraft are you using?
<kyrofa> ccfiel, 2.5 here, the example works for me. How about you?
<ccfiel> kyrofa, my version 1 I think this is the problem
<ccfiel> kyrofa, what ppa did you used? :)
<ccfiel> and version of your ubuntu?
<kyrofa> ccfiel, perhaps you're running on too new of an example. Make sure you're using the ones from here: https://github.com/ubuntu-core/snapcraft/tree/1.x/examples
<kyrofa> Or apt-get install snapcraft-examples and use those
<kyrofa> ccfiel, xenial, no PPA necessary
<ccfiel> kyrofa, is xenial stable to used?
<kyrofa> ccfiel, I actually run trusty. My xenial stuff is all lxc
<ccfiel> kyrofa, thanks for tips :)
<kyrofa> ccfiel, sure thing :)
<kyrofa> ccfiel, bed time for me, so good luck!
<ccfiel> kyrofa, thanks!
<dholbach> good morning
<asac> ogra_: did you ever snapcraftify a simple ftp server?
<asac> ogra_: or even better a postfix/procmail/fetchmail/some-imap solution :)
<noizer> Good morning
<ogra_> asac, nothing that needs user management yet, since that needs special setup (a db or something)
<ogra_> (also snappy is changing way to much still, i cant re-do my mailserver every two weeks because the scurity model changed)
<asac> ogra_: i would be happy with unconfined for my personal vendor pi2 :P
<asac> for now
<asac> anyway, let me put my webserver and ftp server in one snap for now
<ogra_> even unconfined you have the issue that you need user mgmt
<asac> so i can use my scanner again :)
<asac> whats a good ftpd that is easy to run?
<ogra_> vsftpd ?
<asac> saw most use xinetd
<asac> is that a simple daemon?
<ogra_> nah, most of them *can* use inetd :)
<asac> hmm. dont think my scanner can do sftp
<asac> ok so guess i have to put inetd in and put special config up
<ogra_> (doesnt mean you need to)
<asac> well, they dont have daemon commands... at least the ones i tried just exited
<ogra_> feel free to grab some ideas from http://bazaar.launchpad.net/~ogra/+junk/upnp-server/files
<asac> guess if there is non i can just get the most simplest i can find
<ogra_> (not up to date wrt interfaces)
<asac> non that can run daemon itself
 * asac checks
<asac> lighthttp is surely in the mix for my goal
<ogra_> see the readme
<asac> wow, serious copy plugin usage
<ogra_> sqlite needs some special treatment ... either you patch it (like i do there) or you allow all of fchown in the security settings
<asac> thats the fchown pathc?
<asac> yeah. can we land that in archive?
<asac> at least the one gave to a partner back then felt just right (TM)
<ogra_> well, jamie wanted that upstream fixes it
<ogra_> (there was a ML discussion)
<asac> so we rather keep sqlite not working for snaps from archive?
<asac> well, he didnt see the patch
<asac> do you have yours?
<ogra_> well, i thinnk the long term plan was to simply allow fchown
<asac> want to see if its the same
<asac> sure, long term is not 16
<kyrofa> Good morning
<asac> and sqlite definitely should just work from archvie imo
<ogra_> it in the tree ;)
<asac> too many folks use it
<ogra_> http://bazaar.launchpad.net/~ogra/+junk/upnp-server/view/head:/sqlite.patch
<asac> ah ok
<asac> yours is ugly
<asac> let me find mine :)
<asac> that is safe
<ogra_> heh, i really didnt care :)
<ogra_> it works :)
<asac> right. i am sure noone will resist from landing my just in archive
<ogra_> yeah, i never wanted to do something archive worthy :)
<asac> right my patch is not in patch form, but its:
<asac>   return osGeteuid() ? 0 : osFchown(fd,uid,gid); -> return osGeteuid() || osGeteuid() == uid ? 0 : osFchown(fd,uid,gid);
<asac> which is simply correct
<asac> e.g. if you are already root, no need to try to become root
 * asac creates a real patch
<ogra_> right, yu kill the function, i kill the executions
<asac> well, i fix the logic to avoid a no-op call
<asac> which triggers our confinement barrier
<asac> and all is clean and fine
<asac> for everyeone with this
<ogra_> sumbit it then :)
<asac> yet producing it now
<ogra_> (though we are in hard freeze atm, might take a while to land)
 * asac installs quilt
<asac> yeah, better late than never
<ogra_> ppisati, sooo ... thats where i ended yesterday ... http://paste.ubuntu.com/15473201/
<asac> ogra_: do we have a bug?
<asac> that i can ref in the patchname
<ppisati> ogra_: that doesn't look good :)
<ogra_> ppisati, it stops there, heartbeat stops after a while, but funnily my cursor keeps blinking ...
<ppisati> ogra_: uhm
<ogra_> (usually the cursor freezes along with the board)
<ppisati> ogra_: yep
<ppisati> ogra_: i'm thinkg about the serial changes they made on the raspi3
<ogra_> i have some suspicion that the initrd overwrites the dtb at 0x02000000
<ogra_> hmm
<ogra_> wouldnt it keep booting if it was just the serial ?
<ppisati> ogra_: yes, indeed you say heartbeat goes on for a bit
<ppisati> ogra_: maybe it hangs later on
<ppisati> ogra_: i would try first without initrd
<ogra_> while uboot runs
<ogra_> how would i do that ... its snappy :P
<ogra_> ah, well, i could see some kernel output indeed
<ppisati> ogra_: manually, stop uboot and try to load manually kernel and point the dtb
<ppisati> just to see if serial is ok
<ppisati> right
<ogra_> there is something not right with serial in general ... uboot copy/paste ends up with garbage
<ogra_> whilch makes editing long lines really hard (and indeed the snappy scripts are all long lines :P)
<ppisati> ogra_: are you aware of the changes they made to the serial in the raspi3?
<ogra_> i only saw the changelog entry
<ppisati> ogra_: they connected the only real serial to the blueooth dongle
<ogra_> ouch
<ppisati> ogra_: ok, let me give you some background info
<ppisati> ogra_: by defaukt the serial is a sw serial that is affected by the frequency of core
<ogra_> ah, thats why you force the 250 in your config.txt ?
<ppisati> ogra_: yep
<ogra_> btw ... no change without inittrd, so my theory doesnt fly
<ppisati> ogra_: and i did some other changes
<ppisati> ogra_: let me check my board
<ogra_> ppisati, just to make sure, i'm using the latest raspi2 4.4 kernel from the archive here
<ppisati> ogra_: i'm doing an upgrade on my raspi3 as we speak
<ogra_> oh, you had an older kernel in use ?
<kyrofa> ogra_, is there any way to generate an image with swap enabled?
<FJKong>   /join #ubuntu-sdk
<ppisati> ogra_: no, actually i had a newer :)
<ogra_> kyrofa, nope, that would need some hackery (at least in the initrd when we generate the fstab) ... file a bug, we can make it a cmdline option ;)
<ogra_> (thought perhaps we should have a mail discussion first ... if we want to allow swap at all)
<ogra_> ppisati, hah !
<kyrofa> ogra_, alright I'll shoot one out, thanks! To be clear, when you say cmdline option, which component are you referring to?
<ogra_> kernel cmdline
<kyrofa> Ah okay
<ogra_> swapdevice=/dev/foobar0p1
<kyrofa> Gotcha
<ogra_> and perhaps "swapfile=/path/to/file"
<ogra_> that would get you a long first boot though
<ogra_> (cant create swapfiles fast)
<kyrofa> Does it create the swapfile?
<kyrofa> Ah, no fallocate eh?
<ogra_> well, it needs to be filled with actual zeros ... you cant create a sparse file
<ogra_> if we have swapfile we also need swapfilesize
<kyrofa> ogra_, I've used that successfully in the past for a swapfile. Did I just get lucky?
<ogra_> oh ?
<ogra_> perhaps mkswap got clever ... usually you cant create a file with holes
<kyrofa> ogra_, yeah, fallocate, mkswap, swapon. Works for me
<kyrofa> Now I'm curious about that
<ogra_> oh
<ogra_> i didnt know about fallocate !
<ogra_> how could i not !
 * kyrofa taught ogra_ something. I'm calling it a day
 * ogra_ is hardcore dd user if it comes to img files :P
<asac> ogra_: how do i go about propsing https://bugs.launchpad.net/ubuntu/+source/sqlite3/+bug/1560899 aws something considerable for landing after beta freeze?
<ubottu> Launchpad bug 1560899 in sqlite3 (Ubuntu) "sqlite triggers syscall error if run as root in snappy default confinement (fchown not allowed)" [Undecided,New]
 * asac forgot the process, who to subscribe etc.
<asac> :(
 * asac old guy
<ogra_> https://wiki.ubuntu.com/FreezeExceptionProcess
<ppisati> ogra_: nope, it works...
<ppisati> ogra_: do you have an image that i can dd and debug here?
<ogra_> ppisati, what exactlÃ¶y ?
<ppisati> ppisati: the latest raspi2 kernel
<ogra_> hmpf ... my SD is 128GB ... and already resized (and i'm working on the SD)
<ogra_> but technically you shoudl be fine with the boot partition ... one sec
<ppisati> ogra_: so, the difference might be in cmdline.txt / bootargs
<ppisati> or what else? /me thinking...
<asac> ogra_: subscribed release... lets see if someone will pick it up
<asac> i will assign it to you for now :P
<asac> j.k.
<ogra_> ppisati, http://people.canonical.com/~ogra/snappy/snappy-boot.img.xz and http://paste.ubuntu.com/15478441/
 * zyga looks at apparmor again
<ogra_> ppisati, woah ...
<ppisati> ogra_: ???
<ogra_> it boots (totally broken, but i have output )
<ogra_> i swear i have copied the same dtb ten times in place and it didnt work
<ogra_> ubuntu@localhost:~$ uname -a
<ogra_> Linux localhost.localdomain 4.4.0-1004-raspi2 #5-Ubuntu SMP Mon Mar 14 22:27:12 UTC 2016 armv7l armv7l armv7l GNU/Linux
<ppisati> ogra_: your image indeed doesn't boot here
<ppisati> ogra_: weird
<ppisati> ogra_: bad sd maybe?
<ogra_> ppisati, copy the dtb from system-boot/canonical-pi2-linux.sideload_IPOcSSWBccOI.snap/dtbs/bcm2710-rpi-3-b.dtb to system-boot/
<ogra_> then try again
<ogra_> but i have honestly done that ten times before and it didnt work
<ppisati> md5 are indeed different
<ogra_> yes, i was switching between the upstream one and ours
<ogra_> hmm, reboot doesnt work
<ogra_> lets see if it boots again :)
<ppisati> ahaha
<ogra_> it does !
<ogra_> looks like we have an rpi3 image ;)
<ppisati> cool
<ogra_> no wifi though :/
<ppisati> that something to investigate
<ogra_> i see the brcmfmac, cfg80211 and bcm2835_wdt modules loaded though
<ogra_> butu no device in /proc/net/dev
<ogra_> ppisati, we really need to quieten that FS2F driver ... that looks so scary
<ogra_> wo
<ogra_> w
<ogra_> ubuntu@localhost:~$ dmesg
<ogra_> dmesg: read kernel buffer failed: Operation not permitted
<ppisati> nope, no wifi even on a normal ubuntu image
<ppisati> i need to check upstream
<ogra_> brcmfmac_sdio mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.bin failed with error -2
<ogra_> there you go
<ogra_> https://github.com/RPi-Distro/firmware-nonfree/blob/master/brcm80211/defines
<ppisati> uri: http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git
<ppisati> sounds like it should be part of linux-firmware
<ogra_> yeah ... but /lib/firmware/brcm/ actually doesnt have that file
<ogra_> heh
<ogra_> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/brcm doesnt either :P
<ogra_> lies !
<ogra_> ah, well https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm80211/brcm has it ... says "added 27 days ago"
<ogra_> so its actually pretty new
<ogra_> wired network works well btw
 * ogra_ installs webdm
 * ogra_ wonders what "shadowsocks" is 
<ogra_> oh, now reboot works too (from ssh this time ... seems the serial connection held it back last time)
<ogra_> pitti, :(
<ogra_> Mar 23 11:56:08 localhost systemd[1]: Starting Create Volatile Files and Directories...
<ogra_> Mar 23 11:56:08 localhost systemd[1]: Failed to start Create Volatile Files and Directories.
<ogra_> ubuntu@localhost:~$ ls -lh /etc/mtab
<ogra_> lrwxrwxrwx 1 root root 17 Mar 23 05:11 /etc/mtab -> /proc/self/mounts
<ogra_> so that didnt help
<ogra_> ppisati, yay ... and it boots fine on the pi2 too !
<ogra_> i get no serial login prompt on the pi2 though ... thats a bit weird
<ogra_> mvo, please approve https://myapps.developer.ubuntu.com/dev/click-apps/4194/rev/5/ ... (gets us rpi3 support)
<kyrofa> ogra_, are you going to merge rpi3 support into the rpi2 gadget in snappy-systems?
<ogra_> kyrofa, yes
<ogra_> (it just a newer uboot and firmware)
<kyrofa> Awesome :) . Do you anticipate that landing soonish, or is there more work to be done on it?
<ogra_> i want to find out why i dont get a serial tty on the pi2 currently
<ogra_> once i have that fixed we'Re good to go i think
<kyrofa> ogra_, ppisati great work you two! :)
<ogra_> kyrofa, http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/gadget-snap.tgz for the imaptient ;)
<ogra_> *impatient
<kyrofa> ogra_, nah, I'm not impatient. Just curious ;)
<ogra_> ah, i thougth you wanted to update the owncloud thingie
<mvo> ogra_: approved
 * ogra_ hugs mvo 
 * mvo hugs ogra_
<ogra_> hmm, no serial console even if i completely drop console=tty1
<ogra_> this is weird
<ogra_> really strange
<kyrofa> ogra_, I do, but I don't want to jump the gun. It needs to work well on the rpi2 as well
<kyrofa> ogra_, although as soon as the u-d-f --install thing works again, I'll probably stop using the owncloud gadget fork anyway
<kyrofa> Which I guess is just waiting on the new ubuntu-core to make it to stable
<ogra_> yeah
<ogra_> ppisati, any idea abotu that serial thing ?
<ogra_> (i dont think it is critical, but a nice to have)
<ppisati> ogra_: is the serial console the only missing piece? i mean, do you see the system booting?
<ogra_> ppisati, system boots fine i just dont get anything after "Starting kernel ..." ,,, if i set console=tty1 i get proper output on the monitor ... just nothing at all on serial (no login prompt)
<ppisati> ogra_: ok, then no output when kernel start
<ogra_> right
 * ppisati thinks
<ogra_> argh
<ogra_> now i accidentially dropped all console= args :P
<ogra_> heh
<ogra_> and it defaults to tty1
<ppisati> ogra_: might be uboot that is tailored for the raspi3, or (but i don't think so) the "core_freq=250" in config.txt
<ogra_> [    0.103026] Serial: AMBA PL011 UART driver
<ogra_> [    0.103379] 3f201000.uart: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2
<ogra_> the driver is fine at least
<ppisati> first try to remove the core_freq option from config.txt
<ppisati> if that doesn't fix it, i would try with a uboot.bin + uboot.env from the rpi2 image
<ogra_> well, but thats not what i'm after :)
<ogra_> same uboot for both boards :)
<ppisati> ogra_: yeah, i know
<ppisati> ogra_: but at least we find where the problem is
<ppisati> ogra_: remebr that we are using a version of uboot that is not published by upstream anymore
<ogra_> well, it is clear that the difference is in uboot.bin
<ogra_> i dont get why systemd doesnt start a console ...
<ogra_> i think we can live without boot log output on serial
<ogra_> but a login console needs to work
<ppisati> i think we should get both working
<ogra_> yes, but login is more important
<ogra_> err
<ogra_> Mar 23 13:21:18 localhost systemd[1]: Started Serial Getty on ttyAMA0.
<ogra_> Mar 23 13:21:18 localhost systemd[1]: Started Getty on tty1.
<ogra_> Mar 23 13:21:18 localhost systemd[1]: Reached target Login Prompts.
<ogra_> ubuntu@localhost:~$ ps ax|grep getty
<ogra_>   963 ?        Ss+    0:00 /sbin/agetty --keep-baud 115200 38400 9600 ttyAMA0 vt220
<ogra_>   964 tty1     Ss+    0:00 /sbin/agetty --noclear tty1 linux
<ogra_> ...
<ogra_> ubuntu@localhost:~$ ls -l /dev/ttyAMA0
<ogra_> crw--w---- 1 root tty 204, 64 Mar 23 13:21 /dev/ttyAMA0
<ogra_> btw, dropping the the option from config.txt doesnt change anything
<ogra_> hmm
<ogra_> <ogra_> [    0.103026] Serial: AMBA PL011 UART driver
<ogra_> err
<ogra_> ppisati, did you try booting your image on a pi2 yet ?
<ppisati> ogra_: i think i tried but i hit some problems
<ppisati> ogra_: don't remember exctly
<ppisati> let me try
 * ogra_ sees init_uart_clock and init_uart_baud as config.txt options
<qengho> Have any of you had trouble with the dynamic linker inside a snap? I'm getting this. If I run the same code in the same place without the launcher wrapping it, it runs as expected.
<qengho> """Inconsistency detected by ld.so: dl-open.c: 691: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!"""
<jdstrand> zyga: hey, note while you are looking at apparmor again, can you pull in the latest updates to ubuntu-core-security from trunk?
<jdstrand> zyga: r209 for the default policy, but also the others if you already pulled them in somewhere (home, unity7, x, etc)
<jdstrand> zyga: r209 is critical for landing
<zyga> jdstrand: yep, can you file a bug on snappy and assign it to me so that we don't lose thise
<jdstrand> zyga: is the default template change landed already? do you have the other interfaces landed?
<zyga> what do you mean by default template change?
<jdstrand> the apparmor generator that produces the default policy
<jdstrand> did that land?
<zyga> the answer is no, I guess, I will propose apparmor (and everything else) as soon as 702 lands
<zyga> partially
<zyga> I evolved that to the point where it's different ;)
<jdstrand> does the partially part involve the actual policy?
<jdstrand> I reviewed a PR for that, I don't know if it landed
<zyga> jdstrand: yes but that has changed since
<zyga> jdstrand: well, not the actual content there
<zyga> jdstrand: so in any case, we'll have to sync that
<jdstrand> zyga: what I'm getting at is if you just add me to a PR that touches that file, I'll remember. or I could do a PR, or a bug
<jdstrand> tell me what is easiest for you and I'll do it
<zyga> jdstrand: wait then
<zyga> jdstrand: I'd love if you work on a PR instead but please wait for something else to land to do it, ok?
<jdstrand> zyga: sure that's fine. note that if policy generation starts happening on the image without r209, apps won't start
<zyga> jdstrand: (we're talking today)
<zyga> jdstrand: with all the changes today I would be surprised if they did
<jdstrand> heh
<zyga> jdstrand: chipaca is landing snap revisions and snap IDs
<zyga> jdstrand: we're aiming at end of the week/after long weekend for everything working again
<zyga> jdstrand: (including interfaces)
<jdstrand> well, I'd prefer my little corner wasn't the reason for that :)
<jdstrand> just ping me and I'll do a PR
<zyga> jdstrand: thanks, understood
<ppisati> ogra_: same here
<ppisati> ogra_: boots fine, but no output after uboot
<ogra_> k
<ogra_> ohm crap
<ogra_> i see it
<ogra_>  99 #ifdef CONFIG_BCM2837
<ogra_> 100 #define CONFIG_BCM283X_MU_SERIAL
<ogra_> 101 #else
<ogra_> 102 #define CONFIG_PL01X_SERIAL
<ogra_> 103 #endif
<ogra_> pi2 uses the latter
<ogra_> i wonder if it explodes if i enable both
<ppisati> uboot
<ppisati> yeah, saw that
<ogra_> doesnt explode on the pi2 ... still boots
<ogra_> but no login prompt
<ogra_> bug 1556241
<ubottu> bug 1556241 in debian-installer (Ubuntu) "installer sets "iface encf5f0 inet dhcp" although a static IP address was preseeded" [High,Confirmed] https://launchpad.net/bugs/1556241
<AnInstanceOfMe> Hello all ... I've followed instructions here https://developer.ubuntu.com/en/snappy/build-apps/get-started/ to the letter (I'm running 16.04), but just get "Unable to locate package snappy-tools". I added the ppa as per that page - it complained about a weak digest. Any pointers?
<kyrofa> AnInstanceOfMe, I'm afraid those docs are still a bit of a mix regarding 15.04/16.04
<kyrofa> AnInstanceOfMe, you don't need the PPA for xenial, and you should just install, say, snapcraft directory (e.g. sudo apt-get install snapcraft)
<kyrofa> directly rather. Too many directories today
<elopio> kyrofa: ping, meeting.
<kyrofa> elopio, on my way, sorry
<ogra_> ppisati, no matter what i do or try i cant get the kernel spit out anything on serial (and i heavily mangled the uboot build config by now ... funnily i also dont seem to be abe to break it either :)
<ogra_> ppisati, i have a slight suspicion it is the dtb or kernel itself
<AnInstanceOfMe> Right, thanks for that, no probs.
<ppisati> ogra_: actually if i swap out the raspi2 uboot, it works
<ogra_> swap in you mean :)
<ppisati> ogra_: yeah
<ppisati> ogra_: seems like the serial is left in a incosistent state, and the kernel doesn't recover it
<ppisati> let's dig some more
<ogra_> yeah
<lool> jdstrand: heya
<lool> jdstrand: we're trying to run /bin/ip from a snap and get a permission denied; I tried with security-template: unconfined and that didn't help, now I'm trying with read-paths: [/bin/ip], but surprizingly it didn't help either
<lool> [Wed Mar 23 14:54:36 2016] audit: type=1400 audit(1458744876.069:79): apparmor="
<lool> STATUS" operation="profile_load" profile="unconfined" name="openswitch.sideload_
<lool> start-openswitch_IPUAXRQSfQNe" pid=1810 comm="apparmor_parser"
<lool> [Wed Mar 23 14:54:40 2016] audit: type=1400 audit(1458744880.129:80): apparmor="
<lool> DENIED" operation="open" profile="openswitch.sideload_start-openswitch_IPUAXRQSf
<lool> QNe" name="/bin/ip" pid=1826 comm="ops-init" requested_mask="r" denied_mask="r"
<lool> fsuid=0 ouid=0
<lool> jdstrand: https://github.com/ops-snappy/ops-snappy/blob/master/snapcraft.yaml is the snapcraft def and I tried adding caps: [] and replacing security-template with read-paths, to no luck
<joc_> elopio: good morning leo, all the tests passed at last :) https://github.com/ubuntu-core/snapcraft/pull/364
<ogra_> ppisati, http://paste.ubuntu.com/15480016/ (pi3)  ... vs http://paste.ubuntu.com/15479995/ (pi2)
<ogra_> and in fact there is actually a ttyS0 device on the pi3
 * ogra_ wonders about "base_baud = 0" on the pi2
<ppisati> ogra_: i've something different
<ppisati> http://pastebin.ubuntu.com/15479739/
<ogra_> well but you compare two different images
<ppisati> ogra_: the difference is just in uboot at this point
<ogra_> i use the same image and compare it on both boards
<ppisati> same bcm-bootloader and same kernel
<ogra_> right
<ogra_> nontheless, the pi3 expects a ttyS0
<ogra_> http://paste.ubuntu.com/15480016/
<ogra_> about 6 seconds into the boot it also enables the ttyAMA0 one
<ogra_> [    6.967253] 3f201000.uart: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2
<ogra_> well, 7 rather
<ogra_> but the actual serial console seems to be on ttyS0 ... initialized around 4 sec
<ppisati> iirc the console was being rewritten by the firmware
 * ogra_ does a fresh clone ... lets see 
<elopio> joc_: awesome!
<elopio>  sergiusens_, kyrofa: joc_'s pr is ready for a review.
<ogra_> iirc our issue with the upstream uboot was that we forgot sudo for mkknlimg
<ogra_> bah ... and the missing defconfig
<kyrofa> elopio, this has happened twice now: http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/244/console
<kyrofa> (quota)
<kyrofa> elopio, should I just keep trying, or is there a problem?
<elopio> kyrofa: no, I need to delete the instances manually.
<elopio> when scalingstack is having a hard day, it takes a long time to build the instances. So we send the delete command while they are still building, and they are kept around.
<kyrofa> Oh, okay
<jdstrand> lool: is openvswitch using a fs namespace?
<lool> jdstrand: netns
<jdstrand> lool: a perhaps better first question is-- what are the contents of your /var/lib/snappy/apparmor/profiles/openswitch_start-openswitch_... file
<lool> jdstrand: dont know about fs namespace
<zyga> jdstrand: so the prerequisite lanted, I'll iterate for a sec but I can now propose apparmor configurator (terrible name) and you can target policy changes there
<lool> jdstrand: http://paste.ubuntu.com/15480149/
<zyga> jdstrand: I'll keep you posted
<zyga> *landed*
<lool> jdstrand: oh sorry
<jdstrand> yeah, I don't think that is what you meant to paste :)
<jdstrand> zyga: ack
<lool> jdstrand: http://paste.ubuntu.com/15480172/
<lool> no bin/ip there
<jdstrand> lool: more importantly, that isn't unconfied
<jdstrand> unconfined
<lool> no
<lool> well I had removed it in the last attempt
<lool> to not mix both
<lool> but unconfined doesn't work either
<elopio> kyrofa: you can try now.
<kyrofa> Thanks elopio
<lool> jdstrand: trying with unconfined again
<jdstrand> lool: the caps you want is network-management btw
<jdstrand> lool: but yes, let's see what happens with unconfined
<jdstrand> lool: please remove and purge the snap and then install
<lool> jdstrand: ah! I did remove but not purge
<lool> http://paste.ubuntu.com/15480195/
<lool> no unconfined again
<asac> sergiusens_: FAQ i guess... how do i use a ppa?
<lool> jdstrand: still no luck, http://paste.ubuntu.com/15480203/
<lool> despite a snappy purge openswitch
<jdstrand> lool: I don't know how new your snappy is. I wonder if security-template is no longer being honored
<lool> the apparmor stuff is regenerated
<code1o6> lool, Hey, I'm new is that a snapcraft.yaml?
<lool> jdstrand: ah it's the mvo image, but updates might not be applied
<lool> let's see with latest snappy
<jdstrand> lool: well, another thing to try is:
<jdstrand> plugs:
<jdstrand>   networking:
<jdstrand>     interface: old-security
<jdstrand>       caps: [network-client, network-management]
<jdstrand> err, caps shouldn't be indented that far
<jospoortvliet> kyrofa: any chance you could join some Pi drive ppl in #techandme ??
<code1o6> lool, jdstrand, I'm making a very simple snappy package that uses nmap and a bash script. Kinda like the one from getting started however I'm having issues is the getting started tutorial I believe is for snappy 16.04. Any help would be highly appreciated
<code1o6> *not getting started. build your first snap tutorial
<asac> sergiusens_: FAQ i guess... how do i use a ppa for stage-packages?
<code1o6> here is my yaml http://paste.ubuntu.com/15480263/
<sergiusens_> asac, that's only for plugins; why do you need this?
<lool> jdstrand: of course after updating snappy, things work
<asac> because i have a patch to apply to a package
<lool> jdstrand: sorry
<asac> that i want to use
<code1o6> Here is my bash script http://paste.ubuntu.com/15480269/
<asac> sergiusens_: why wouldnt we allow to add-repositories for apt?
<asac> globally
<sergiusens_> asac, or if added to your host system and using this variable that is about to go away LOCAL_SOURCES
<lool> code1o6: I'd suggest starting from a snapcraft checkout
<lool> code1o6: and reading through the examples
<code1o6> I did
<sergiusens_> asac, you don't have the master plan in your head; trust me :-)
<asac> sergiusens_: hmm. doesnt sound good
<code1o6> I did exactly from the tutorial
<asac> sergiusens_: is there a trick coming to make what i want to do easy?
<asac> without ppa?
<sergiusens_> asac, create a bug about stage-package's and ppa's I guess; but the original idea was that stage packages would come from the archive
<asac> like deb-source plugin that builds something from a debsource?
<code1o6> The only difference is that I changed "$SNAP_DATA" to "$SNAP_APP_DATA_PATH" because it was for 16.04
<asac> they come fromt he archive, but there might be need to do stuff different :)
<asac> i actually think the dpkg-buildpackage plugin might be neat :P
<jdstrand> zyga: erf, how to you unrequest a PR?
<zyga> jdstrand: close it!
<asac> i could apt-get source, hack away and jkust use that
<sergiusens_> asac, that will be horrible ;-)
<jdstrand> how do I close it? :)
<zyga> jdstrand: there's a button at the bottom of the page
<asac> sergiusens_: maybe from how it would need doing with pbuilder and friends?
<jdstrand> ah there it is
<asac> but from the feel it woudl be nice
<asac> have a bug in an archive package
<jdstrand> thanks
<asac> just take the source, patch it and build it nicely
<sergiusens_> asac, if there's a bug in an archive package it should ideally be fixed
<code1o6> lool, when i try to run the bash script in /apps/unisys-test/whatever I believe it fails to run since it doesn't have the right folder permissions.
<asac> i have never been a fan of such idealistic statements when something doesnt work
<asac> yes, the world should all be clean and upstream
<asac> but realitity is i need to get something done now :P
<lool> code1o6: which folder are you trying to open?
<asac> and we have beta freeze even
<asac> and i dont even know if my patch is great and want to first test it by using it :)
<asac> in snapcraft
<asac> anyway, i will figure
<code1o6> http://paste.ubuntu.com/15480269/
<code1o6> lool, it just pipes the output of nmap to test.out
<sergiusens> asac, well bottom line is it is not supported today
<code1o6> then golang static websever should display that folder
<ogra_> ppisati, hmm https://github.com/swarren/u-boot/commit/97e783304448f240b33ab308cd9e18df5d8f69ca
<code1o6> just like the tutorial does it for the webcam
<asac> right. i can file a bug and then wait till that feature is there :)
<asac> guess i cant setup my home ftp server on snappy then :)
<code1o6> instead of creating pictures from fswebcam i use nmap
<code1o6> lool, I'm still quite understand how filesets work. This is how I did it http://paste.ubuntu.com/15480263/
<code1o6> I'm guessing that the issue in my snapcraft.yaml
<asac> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1561068
<ubottu> Launchpad bug 1561068 in Snapcraft "cannot use ppa or deb source packages conveniently" [Undecided,New]
<code1o6> brb, going to get coffee
<asac> hmm. vsftpd doesnt even have a git tree from what i see
<jdstrand> zyga: https://github.com/ubuntu-core/snappy/pull/718
<asac> lets go for tarball mess then :/
<ogra_> asac, its probably so small that the maintainer just types it in from memory before building ;)
<code1o6> back
<lool> code1o6: sorry I need to focus on something else for a while, if you dont get help here I'll be back with you reading the backlog
<zyga> jdstrand: thanks
<asac> haha ... /me joins #vsftpd
<zyga> jdstrand: I've chaged the patch summary, we just indicated the package, not a particular file
<zyga> jdstrand: if you have more I'll gladly take them :)
<zyga> jdstrand: I'm working on some final bits that put all security stuff on disk and in memory
<jdstrand> zyga: what does 'whitelist this please' mean?
<zyga> jdstrand: just iterating to make it pretty and robust
<ogra_> ppisati, any idea what the dtb names are in that commit ? they dont seem to match any rpi dtb i have ever seen
<ogra_> (like: none of them)
<zyga> jdstrand: it's a command to one of the bots that says that this pull request is trusted, it triggers tests to run when a non-member of the ubuntu-core organization proposes a pull request
<asac> ogra_: so in your example you have the sqlite hacked binary in the source tree
<asac> because its not easy to just use ppas?
<ogra_> asac, yeah, and have a copy line
<asac> or do you build sqlite completely?
<asac> right
<jdstrand> zyga: I see
<asac> awful
<ogra_> sure :)
<asac> i feel super resistant against such things
<ogra_> its a demo snap ...
<ogra_> feel free to make it better ;)
 * ogra_ only cares about having working binaries 
<asac> i am ... files a bug
<asac> https://bugs.launchpad.net/snapcraft/+bug/1561068
<ubottu> Launchpad bug 1561068 in Snapcraft "cannot use ppa or deb source packages conveniently" [Undecided,New]
<jdstrand> zyga: so, the next step from my perspective is adding all the existing ubuntu-core-security (from trunk!) caps as interfaces
<asac> ppa is good, deb-soure plugin woudl be even more awesome
<zyga> jdstrand: I think we are ready-ish for that now
<jdstrand> zyga: so I'll wait for you to do that before I make other policy change PRs
 * ogra_ would just like to have patches auto-applied :)
<zyga> jdstrand: if you can, just add them
<asac> ogra_: not sure why i need snapcraft if i have to build the binaries elsewhere
<zyga> jdstrand: one pull request per interface
<asac> and then copy them in my tree :P
<asac> could just do the old way of doing it somehow then
<jdstrand> zyga: I'm not sure how...
<zyga> jdstrand: look at interfaces/builtin/network.go
<zyga> jdstrand: just copy-paste
<ogra_> asac, to r9oll the snap ... this snap is from early 15.04 days and was always just carriesd along
<zyga> jdstrand: 99% of the file is the security content or generic boilerplate
<ogra_> back then there was no such thing as snapcraft
<jdstrand> oh, I didn't know you did one already
<asac> ogra_: but it is snapcraft :)
<zyga> jdstrand: just paste the right security content and the right profile name
<ogra_> asac, now it is
<asac> soyou could have just kept it manual
<ogra_> no
<ogra_> snappy build will be gone soon
<asac> well just mksquashfs
<asac> :)
<zyga> jdstrand: I can help you out with this but it would be much faster and might align with having interfaces really work by the end of the week
<ogra_> and i still use the copy plugin
<asac> i did that a few times
<roadmr> hey snappers! my snap is having trouble accessing the network (it's a server thingy): http://paste.ubuntu.com/15479495/ I have the old-security plug stuff from the gopaste example but still I see this. What am I missing?
<asac> roadmr: how does your snapy.yaml look?
<zyga> roadmr: hey
<roadmr> asac: like crap :) let me paste it
<roadmr> zyga: hello!
<asac> roadmr: thsoe are not really network ones
<asac> at least they dont look like it
<asac> but who am i :) ... maybe seeing you have a syntax error in you snap.yaml will explain it
<zyga> with everything that happens this week I'd imagine it could be broken, not sure how away latest devel images are from git master
<roadmr> asac: http://paste.ubuntu.com/15480423/ this is just the apps and plugs
<roadmr> asac: blatantly copied from the gopaste example really :/
<zyga> jdstrand: merged
<zyga> roadmr: it looks good, I'd wait for after easter though
<zyga> roadmr: 90% of snappy is upside down this week
<zyga> roadmr: with major changes landing
<ogra_> just do a handstand
<zyga> roadmr: and next week I'd use network interface
<zyga> roadmr: not old security
<roadmr> zyga: yay!!
<ogra_> though typing is hard in that position
<zyga> (I suspect that next week old-security is the only interface that will not work)
<zyga> (while everything else will)
<roadmr> ogra_: haha :) a handstand sounds like a skill, rather than an interface :)
<ogra_> heh
<zyga> I'll get o-s to work too but after
<elopio> fgimenez: git push --set-upstream origin bug/mkdir_gnupg
<elopio> sorry
<elopio> fgimenez: https://github.com/ubuntu-core/snappy-jenkins/pull/114
<asac> roadmr: dunno... i never had problems, but didnt use override
<jdstrand> zyga: fyi, we need old-security/seccurity-override and old-security/security-policy to work at least (the other two can go away afaic)
<jdstrand> zyga: next week is fine, just saying, we should plan on those working. we can chat at some point when it makes sense about what those should be doing and how the interact with interfaces
<asac> roadmr: so its different for me
<asac> interface: old-security
<zyga> jdstrand: wooot
<zyga> jdstrand: wait, what about system calls?
<zyga> jdstrand: security-policy -- that's the "different template" support, right?
<asac> roadmr: http://paste.ubuntu.com/15480453/
<asac> thats what i would try
<zyga> jdstrand: and security-override is like a custom snippet, right?
<fgimenez> elopio, ok thx!
<jdstrand> zyga: regarding the other caps, I'm on it. I didn't realize network was already there
<jdstrand> zyga: security-policy is 'use my custom raw policy and don't use interfaces/apparmor.go and interfaces/seccomp.go"
<zyga> jdstrand: thanks, I'm sure we can land them quickly
<zyga> jdstrand: I see, that's okay, this should be supported with what I'm hacking on now
<jdstrand> zyga: security-override is 'use interfaces like normal, but add these few extra things I specified'
<zyga> jdstrand: perfect
<zyga> jdstrand: I'm 100% confident we'll get all of this to work now
<jdstrand> nice
<roadmr> asac: thanks! I'll try that right now...
<zyga> jdstrand: (it works now but I need to rebase on top of what mvo did first)
<zyga> jdstrand: and there's a looong review ahead :)
<asac> roadmr: but as said not sure about -override part
<roadmr> asac: ok, we'll know soon enough :)
<jdstrand> zyga: why doesn't git reset --hard origin/master pull in the change you just merged?
<zyga> jdstrand: git is offline except for "pull" and "fetch"
<zyga> jdstrand: git fetch --all
<jdstrand> zyga: that didn't do it either
<asac> git fetch origin
<jdstrand> I already trid git pull
<asac> then do the checkout / reset
<zyga> jdstrand: I'd normally pull instead
<zyga> jdstrand: git pull origin master
<jdstrand> I tried a pull before I asked the question
<zyga> jdstrand: safer than reset --hard
<zyga> ^^ like that
<roadmr> asac: so it didn't work :/ I still see the same apparmor DENIED stuff :/ I'm OK to wait until next week if things are wobbly right now
<jdstrand> zyga: it says I am up to date, but I am clearly not. I don't have 718
<asac> guess so
 * jdstrand sighs
<asac> jdstrand: git branch
<asac> git log -l1
<asac> i think you might be on different head\
<jdstrand> that's what I'm saying
<asac> then you think
<jdstrand> I have Merge pull request #717
<jdstrand> I do not have 718 which github says is committed
<asac> do you see it in the fetched branches?
<asac> e.g. git log origin/master ?
<asac> if not its a caching prob
<asac> of course only after doign git fetch origin first
<jdstrand> git log origin/master doesn't show it either
<jdstrand> I did git fetch origin
<asac> and git remote show origin
<jdstrand> maybe I'm confused by what github is saying
<asac> shows the right origin?
<asac> on master on github there is 718
<asac> no confusion on that front
<jdstrand> maybe I cloned it wrong?
<asac> yes, check git remote show origin
<asac> maybe that points to your own tree
<jdstrand> http://paste.ubuntu.com/15480553/
<jdstrand> it seems to
<jdstrand> I don't know why
<asac> you probably jus started with that
<asac> its not problem
<asac> just add the upstream origin
<asac> like git remote add upstream https://github.com/ubuntu-core/snappy
<asac> git fetch upstream
<asac> and then you can checkout upstream/master
<jdstrand> is that the normal way or is it a workaround because I cloned wrong?
<asac> well. its certainly not abnormal to have your own repo as origin and the upstream repo as something else
<asac> depends on the perspective
<asac> :)
<jdstrand> my perspective is I just want to have something that I trip on *every* time
<jdstrand> :P
<asac> lol
<asac> you have to learn this then
<zyga> jdstrand: yeah, I have origin as myself and upstream as upstream :)
<asac> no way around it :)
<zyga> jdstrand: it's all personal
<asac> git is not bzr
<jdstrand> I git that (see what I did there! :)
<zyga> ...
<zyga> ...
<jdstrand> but I'm trying to figure out what the git flow is
<zyga> we see (see what I did here)
<zyga> (except it took a while)
<asac> jdstrand: git flow is really very freeform... do what you want :)
<zyga> jdstrand: I typically git fetch once a day or when something I care about lands
<asac> you add the repos you care about with some name (origin, upstream, doesnt matter)
<jdstrand> assamaybe that is the issue
<asac> and then make local working branches for whatever youw eant to work on
<asac> :)
<asac> and push to wherever you want to push
<zyga> yep
<zyga> it's the hippygit workflow
<asac> i try to avoid magic stuff... becuase i dont understand what it doesn :)
<asac> so just do it old way :)
<asac> jdstrand: so if you do git branch -a you see all the branches you ahve fetched from remote repos
<jdstrand> I know what happened
<asac> that you ahve configured in snappy remote
<asac> and all that doesnt have ORIGIN./ is just local
<jdstrand> it is the combination of github and git
<asac> you can always just delete all that if you are confused
<jdstrand> ie, I forked ubuntu-core/snappy.git
<asac> and checkout whhatever you want as master from all those things available from upstream repo
<jdstrand> that gave me jdstrand/snappy.git
<jdstrand> I cloned jdstrand/snappy.git
<asac> yes
<jdstrand> I was thinking that github would do something magic there
<jdstrand> but now the upstream bit makes sense
<jdstrand> ok
<jdstrand> thanks!
<asac> thats how you usually end up with your own repo on github :)
<asac> hehe
<asac> so the security-override in the plug thing is not really the way to do that right?
<asac> e.g. to allow syscalls
<asac> for me the network caps work, but not the syscall whitelist
<asac> http://paste.ubuntu.com/15480672/
<sergiusens> elopio, help here would be nice http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/243/console
<asac> jdstrand: do you know?
<zyga> jdstrand: related to asac's question, do you think we need to support "syscalls" as thing in old-security
<zyga> (I know the custom snippet think is sufficient for that)
<elopio> sergiusens: I think I already solved that. We had a lot of slow scalingstack instances hanging around.
<asac> hmm. i think it actually worked
<asac> i get now a complain about missing cap setgid
<asac>     security-override:
<asac>       syscalls: [setgroups]
<asac>       caps: [setgid]
<asac> that doesnt feel right :)
<asac> let me add that to the other caps
<asac> where i have network-listener
<asac> ok that was clearly wrong :)
 * ogra_ takes a break
<asac> jdstrand: its odd... i now have http://paste.ubuntu.com/15480726/ and i managed to get rid of setgid capabilityt complain and setgroups syscalls complain, but this doesnt fix the sys_admin complains
<asac> zyga: ^
<zyga> no idea :-(
<zyga> I haven't tried using old-security much and I don't really follow the magic behind it
<asac> http://paste.ubuntu.com/15480738/
<zyga> asac: but I can promise you to support this next week
<asac> thats the complains i got before
<asac> now i only get the sys_admin one
<zyga> asac: when I know what happens inside
<sergiusens> elopio, hm
<asac> jdstrand: nevermind i got rid of all complains.... was just confused by scanlog
<sergiusens> morphis, btw https://github.com/ubuntu-core/snapcraft/pull/397
<asac> still have troubles
<sergiusens> and lool ^
<morphis> sergiusens: yeah!
<mvip> asac is most of the Snappy team in Paris now?
<asac> mvip: no most are distributed
 * asac does the ogra now :)
<asac> copies hacked binaries into snapcraft sourc etree
<asac> and i must admit once you have done it once it doesnt feel that bad anymore :)
<ogra_> haha
<mvip> asac yeah i know, but i thought Didier, Rircardo and Maarten were there so i just thought you had an event or something.
<mvip> *Ricardo
<ogra_> thats the tie and suit guys :)
<mvip> ogra_ ;)
<mvip> While i have seen Maarten in suit, i haven't seen Ricardo or Didier in one ;)
<ogra_> they have a party budget to take out customers, so they can have in-person meetings ... us poor developers have to stay at home ;)
<mvip> ogra_ hahaha
<asac> ricardo and didier did an important one day thing there :)
<mvip> ah ok
<asac> mectors wanst there afaik, but you newver know :_)
<mvip> asac i've been chasing Ricardo by email but he appears to be MIA
<asac> he is vac
<ogra_> back next week
<asac> back mon
<mvip> ah ok.
<asac> if you need urgent help let me know :)
<mvip> asac nah we talked at MWC about doing a pre-16.04 Hangout for my devs to avoid common pitfalls
<mvip> but now we're halfway there already
<mvip> but thanks for the offer
<asac> mvip: half way where?
<mvip> asac: yeah we've ported most of the code from 15.04, but there were a few changes that they're still working on
<asac> ic
<asac> ok sounds good. just remember there are still changes happening on trunk
<mvip> yeah i know
<asac> team will probably improve stuff till very shortly before release
<asac> goodie
<mvip> yeah but we want to open up the beta with some beta customers asap, and since there is no migration plan from 15.04 (w/out re-flashing), we kinda have to bite the bullet with 16.04
<asac> zyga: where is the old-secureity code?
<asac> i cannot find it
<asac> need to know if the field is called capabilities
<zyga> asac: snappy/*
<zyga> asac: mostly security.go
<zyga> asac: but it's not easy to follow IMHO
<zyga> (e.g. compare to interfaces/builtin/$iface_name.go
<zyga> asac: :-(
<asac> indeed
<asac> jdstrand: really would love to know where i can put stuff like sys_chroot
<asac> i tried putting it in old-security -> caps
<asac> doesnt work
<asac> then in override -> capabilities, but the code doesnt seem to suggest such field exists
<ogra_> even if it did you'd most likely have to change it again next week :P
<asac> its odd
 * ogra_ waits til someone actually calls the stuff stable ... i gave up forward porting my snaps every week
<asac> i get complain that syscall chroot is missing
<asac> then i add that and then it complains about missing cap sys_chroot
<asac> wonder why we always have both
<ogra_> i doubt you will be able to implement that sanely at all
<asac> ogra_: how can i make it unconfined?
<ogra_> turn off chrooting in your daemon
<asac> my machien crashed s i have to get this working today
<asac> no matter what
<zyga> asac: unconfined is going away, developer mode is replacing that
<ogra_> zyga, on a pre-snap basis ?
<asac> yes, but i need it working today
<zyga> yep
<ogra_> *per-snap
<asac> doesnt matter what goes away
<zyga> asac: sure, just FYI
<stgraber> jdstrand: hey, any chance you can look at that lxd upload?
<asac> soo how to do unconfined these days?
<asac> :)
<ogra_> asac, http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/files that worked two weeks ago
<ogra_> (obsolete again though)
<asac> yep great
 * asac tries the equiv
<sergiusens> mvo, hey, how is meta/gui defined?
<sergiusens> mvo, or what lives in it?
<mvo> sergiusens: I'm off for dinner now, lets talk later or tomorrow. its just icon in there and desktop files for now
<jdstrand> stgraber: done
<stgraber> jdstrand: thanks
<elopio> ogra_: the package on the ppa build successfully today. If you can trigger a snap build, that would be nice.
<code1o6> Hey guys, can someone take a look at my snapcraft.yaml to see if there is anything wrong with it. I'm not sure if I'm doing the filesets part right http://paste.ubuntu.com/15480263/
<sxj> installed snappy on VirtualBox-4.3.36-105129, have tried ubuntu/ubuntu for username/password
<sxj> get "login incorrect"
<sxj> have typed them carefully but still the same error
<jdstrand> zyga: not sure if you are still around, but how do I list available interfaces? I'm on trunk and wanted to se how that part workeed
<zyga> ther'es no way to do that
<zyga> jdstrand: just add a test in all_test.go
<jdstrand> today or ever?
<zyga> today, we haven't designed anything that needs it yet
<zyga> jdstrand: one thing I'd envison was the developer mode debug checker
<zyga> jdstrand: but it's not implemented in any way
<jdstrand> zyga: ok, so, the debugging tool I need to write will need some of this
<jdstrand> but let's not worry about that now
<zyga> jdstrand: it should be trivial to expose this on CLI
<zyga> jdstrand: one day
<sxj> downloaded the ova image from http://cloud-images.ubuntu.com/ubuntu-core/15.04/core/stable/current/core-stable-amd64-cloud.ova
<ogra_> elopio, building
<elopio> thank you!
<jdstrand> zyga: sorry to keep bothering you: ./run-tests
<jdstrand> can't load package: package _/home/jamie/bzr-pulls/snappy.jdstrand/arch: cannot find package "_/home/jamie/bzr-pulls/snappy.jdstrand/arch" in any of:
<jdstrand> 	/usr/lib/go/src/_/home/jamie/bzr-pulls/snappy.jdstrand/arch (from $GOROOT)
<jdstrand> 	/home/jamie/src/gopath/src/_/home/jamie/bzr-pulls/snappy.jdstrand/arch (from $GOPATH)
<zyga> jdstrand: don't be sorry
<zyga> jdstrand: first of all, forget about run tests for a sec
<jdstrand> I did ./get-deps.sh
<zyga> jdstrand: go to interfaces/builtin
<zyga> jdstrand: and run "go test"
<zyga> jdstrand: that's 99% of what matters
<jdstrand> ./bool_file_test.go:126: undefined: builtin.MockEvalSymlinks
<zyga> hmmm
<zyga> ok
<zyga> quick sanity check
<zyga> your code should be in $GOPATH/src/ubuntu-core/snappy
<zyga> that is
<zyga> after get-deps
<zyga> your snappy fork should be exactly there
<zyga> otherwise nothing works
<jdstrand> zyga: that worked
<jdstrand> zyga: I use a symlink from $GOPATH/src/ubuntu-core/snappy to somewhere else
<jdstrand> 13:49 < jdstrand> zyga: that worked
<jdstrand> 13:49 < jdstrand> zyga: I use a symlink from $GOPATH/src/ubuntu-core/snappy to somewhere else
<jdstrand> zyga: I was 'somewhere else'
<zyga> mmm
<jdstrand> doi
<jdstrand> I'm doing too much at once :)
<zyga> I'd suggest the other way around (have real stuff in $GOPATH and a symlink to reach faster but I'm glad that this works as well
<zyga> jdstrand: thanks for asking :)
<zyga> jdstrand: quick tip from my back of commands:
<zyga> go test . -cover -coverprofile $GOPATH/src/github.com/ubuntu-core/snappy/cover.out && go tool cover -html $GOPATH/src/github.com/ubuntu-core/snappy/cover.out -o $GOPATH/src/github.com/ubuntu-core/snappy/coverage.html
<zyga> xdg-open $GOPATH/src/github.com/ubuntu-core/snappy/coverage.html
<sergiusens> mvo, kyrofa https://github.com/ubuntu-core/snapcraft/pull/399
<code1o6> sjx, I recommend using kvm, aka virtual machine manager
<code1o6> works great
<code1o6> Can anyone take a look at my snapcraft.yaml
<code1o6> Is anyone running snappy core 16.04
<zyga> code1o6: I'd suggest just asking the question
<zyga> code1o6: aka, don't ask to ask, just ask
<zyga> code1o6: "I have a problem $DESCRIPTION_OF_PROBLEM with my snapcraft.yaml -- $PASTEBIN_OF_SNAPCRAFT_YAML"
<code1o6> Zyga, I have several time on multiple days
<code1o6> ey guys, can someone take a look at my snapcraft.yaml to see if there is anything wrong with it. I'm not sure if I'm doing the filesets part right http://paste.ubuntu.com/15480263/
<code1o6> So, it builds but my bash script doesn't create test.out file. When I try running nmap binary it fails /apps/unisys-test/blah/nmap
<code1o6> http://paste.ubuntu.com/15480269/
<code1o6> that's the bash scripts the should run using glue from snapcraft.yaml
<code1o6> The webserver gets started but I believe that the permission in the directory are not correct since the test.out file does not get created
<code1o6> I tested my bash script in ubuntu and works perfectly. So, the problem is that the Build your first snap tutorial from canonical is outdated. The example source they provide is for 16.04
<code1o6> So there is something I must be missing or that I have extra
<code1o6> zyga, ^^
<zyga> code1o6: unfortunately I cannot help you out, I'm not familiar with filesets, perhaps sergiusens can answer; if not I'd suggest sending that same question to snappy-app-devel mailing list
<code1o6> I'm just following the tutorial from here https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/. Look at the last two sections. It doesn't make any sense
<code1o6> filesets, and extending metadata
<code1o6> at the end they says edit snapcraft.yaml one more time and then it says again but if you look at the code for both of them they are completely different
<zyga> code1o6: developer docs are somewhat out of date between what's in 15.04 and 16.04
<zyga> code1o6: I haven't used filesets at all so I cannot say if that's affected
<code1o6> I understand that zyga, I even have friends at canonical but unfortunately they don't work in snappy core project. So I'd appreciate any help from the developers.
<zyga> I'd suggest looking for dholbah, he should be able to help with the docs and perhaps point you at the right person
<sergiusens> zyga, code1o6 there have been no changes for filesets though
<sergiusens> where does this project live? and I hope you are on xenial
<code1o6> sergiusens, its 15.04
<code1o6> The project where I build the snap package its 15.10
<sergiusens> code1o6, why are you doing stuff on 15.04?
<sergiusens> all the great stuff is in 16.04
<code1o6> I wish I could upgrade but its part of Dell IOT device and it's shipping with 15.04
<code1o6> sergiusens, ^^
<sergiusens> code1o6, ah, valid reason :-)
<sergiusens> code1o6, is you project anywhere to look at?
<sergiusens> code1o6, I'm almost sure you call to ip -4 addr show eth0 fails
<sergiusens> code1o6, can you install snappy-debug
<sergiusens> and run sudo snappy-debug scanlogs
<code1o6> sergiusens, it's not in github but here are all the files that are in my project folder. Snapcraft.yaml http://paste.ubuntu.com/15480263/ my webui http://paste.ubuntu.com/15480269/ and webui.go http://paste.ubuntu.com/15482363/
<code1o6> I can post it in github if you'd like
<code1o6> Why are you sure sergiusens ?
<code1o6> It works in ubuntu and I thought ip should be built into snappy
<code1o6> let me try  it right now
<sergiusens> code1o6, because if the `ip` comes from the system you are probably missing some security allowances
<sergiusens> snappy-debug will confirm
<code1o6> snappy-debug is not found
<code1o6> Is it a snap?
<code1o6> sergiusens, do you run that in snappy or my project folder?
<jdstrand> network-management is the cap you would use on 16.04, network-admin on 15.04
<jdstrand> zyga: sorry, another question: https://travis-ci.org/ubuntu-core/snappy/jobs/118065075
<jdstrand> zyga: you said go test was enough, but travis says otherwise
<code1o6> guys how do you run snappy-debug
<jdstrand> sudo snappy install snappy-debug
<jdstrand> sudo snappy-debug.security scanlog
<code1o6> nvm
<code1o6> thanks
<code1o6> serguisens, was right http://i.imgur.com/q9W5hKT.png
<code1o6> can someone take a look at it?
<code1o6> it says to add 'capability net_admin'
<jdstrand> did you see what I said above?
<jdstrand> network-management is the cap you would use on 16.04, network-admin on 15.04
<code1o6> oic
<code1o6> so just change that
<code1o6> what is cap? capability?
<jdstrand> or add it, yes
<code1o6> jdstrand, thank you so much.
<code1o6> plugs:
<code1o6>   listener:
<code1o6>     interface: old-security
<code1o6>     caps: [network-listener]
<code1o6>  [network-admin]
<code1o6> like this?
<jdstrand> caps: [network-listener, network-management]
<code1o6> I thought you said network-admin
<jdstrand> since you specified network-listener, this is 16.04, so use network-management, plus, I'm assuming you still want network-listener
<jdstrand> it is currently network-management on 16.04, changed from network-admin
<code1o6> jdstrand, [network-admin, network-listener]
<jdstrand> no
<jdstrand> [network-listener, network-management]
<code1o6> <jdstrand> network-management is the cap you would use on 16.04, network-admin on 15.04????
<jdstrand> yes
<jdstrand> you are on 16.04, use network-management
<code1o6> no i'm in 15.04
<jdstrand> not if you are using 'plus'
<jdstrand> plugs*
<code1o6> Well I have to use 15.04. How would I make it compatible then
<jdstrand> if you are on 15.04, drop all the 'plugs' stuff and simply use: caps: [network-client, network-admin]
<jdstrand> code1o6: eg:
<jdstrand> services:
<jdstrand>   foo:
<jdstrand>     caps: [network-client, network-admin]
<jdstrand> code1o6: fyi, you need to make sure you are using the right snapcraft for 15.04
<code1o6> jdstrand, does it look okay? http://paste.ubuntu.com/15482558/
<jdstrand> code1o6: the services bit does, yes. I am not a snapcraft expert though
<jdstrand> so I can't comment on the other parts
<jdstrand> I mean, it looks ok otoh
 * ogra_ is still curious if you will in the end be able to make nmap work within the confinement boundaries
<ogra_> i mean ... it needs quite some system access to collect the info (switching the NIC into promiscous mode for example)
<jdstrand> it will cause apparmor doesn't have fine-grained network mediation yet
<code1o6> it doesn't need to be in promscous mode
<jdstrand> CAP_NET_ADMIN is essentially all that is needed
<code1o6> jdstrand, I guess it progress http://paste.ubuntu.com/15482674/
<zyga> jdstrand: looking
<jdstrand> zyga: ./run-tests passed here locally
<zyga> jdstrand: hmm, travis merges AFAIR
<jdstrand> code1o6: yes, notice the timestamp, your network-admin worked
<zyga> jdstrand: can you rebase / merge master
<zyga> jdstrand: and see if that fixes it
<zyga> jdstrand: looks like pre native plug/slot info branch
<jdstrand> code1o6: File: /apps/unisys-test.sideload/IPUTNKTTWKUK/test.out. use $SNAP_DATA_PATH/test.out instead
<jdstrand> zyga: erf, I forked from https://github.com/ubuntu-core/snappy.git and am up to date
<zyga> jdstrand: ok, let me have another look
<zyga> jdstrand: you are not
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/720/files#diff-aa51e80575985c01c3fa42dabdd454ddR40
<zyga> jdstrand: this is before 702 landed
<jdstrand> it said I had 718 though
<zyga> jdstrand: 702 changed Plug/Slot API
<ogra_> code1o6, ah, you would only do higher level stuff ?
 * jdstrand shakes fist at git
<zyga> jdstrand: (landing order != proposal order)
<ogra_> yeah, i guess that works
<zyga> jdstrand: fetch / rebase
<zyga> jdstrand: and see what happens
<jdstrand> meh, I just did several of these
<zyga> jdstrand: tests will fail for you locally then, I suggest doing a quick vimdiff on your new _test file and other interface _test file to see how to change that
<zyga> jdstrand: the change is totally automatic
<zyga> jdstrand: git fetch upstream
<zyga> jdstrand: git rebase upstream/master
<jdstrand> I don't see how git clone gave me the wrong thing
<zyga> jdstrand: assuming upstream remote is github.com/ubuntu-core/snappy
<zyga> jdstrand: what is wrong?
<code1o6> jdstrand, like this http://paste.ubuntu.com/15482722/?
 * jdstrand has been struggling getting a git workflow going only to find he had the wrong branch
<code1o6> ogra_, what are you talking about?
<ogra_> nmap
<jdstrand> code1o6: seems fine
<ogra_> doesnt that usually also do arp scans and such ?
<code1o6> well I wanted to do -sS but that requires sudo
<jdstrand> zyga: git fetch upstream is up to date
<zyga> k
<code1o6> for now I'll try getting it working first
<ogra_> code1o6, right, thats what i mean ...
<zyga> jdstrand: do you see ea2f84a3362ba4b7757f178a6da82f5938181f1b
<zyga> jdstrand: you have to have it in your branch
<jdstrand> commit ea2f84a3362ba4b7757f178a6da82f5938181f1b
<jdstrand> Merge: c887a47 813c112
<jdstrand> Author: Zygmunt Krynicki <me@zygoon.pl>
<jdstrand> Date:   Wed Mar 23 18:00:44 2016 +0100
<jdstrand>     Merge pull request #702 from zyga/use-std-plugs-and-slots
<jdstrand>     
<jdstrand>     interfaces, daemon, overlord: use snap.{Plug,Slot}Info natively
<zyga> jdstrand: is that in the branch you are on?
<jdstrand> yes
<zyga> jdstrand: can you check that your firewall test looks the same to network test (for example)
<zyga> jdstrand: and that it looks like this:
<zyga> https://github.com/ubuntu-core/snappy/blob/master/interfaces/builtin/network_test.go#L38
<zyga> jdstrand: ^^
<zyga> jdstrand: git status
<zyga> jdstrand: git branch
<zyga> jdstrand: maybe your are in some weird place
<zyga> jdstrand: or you are pushing to some weird location so tests locally pass but you pushed something else earlier
<jdstrand> zyga: it is in everything except my firewall-controll branch
<zyga> jdstrand: there you go
<zyga> jdstrand: git rebase upstream/master
<jdstrand> zyga: apparently I forked and started working before that was merged
<zyga> :-)
 * jdstrand wonders why zyga said to work on these with that change not landed :)
<zyga> jdstrand: AFAIR at that time it *has* landed :D
<zyga> jdstrand: you just didn't fetch
<zyga> jdstrand: look at the timestamps
<jdstrand> so, https://github.com/ubuntu-core/snappy/pull/721 passed travis
<jdstrand> and the other two I started will have had that
<jdstrand> I'll update firewall-control
<code1o6> jdstrand, I'm still getting adjust program to not write to SNAP_APP_PATH
<jdstrand> it isn't SNAP_APP_PATH
<jdstrand> it is SNAP_DATA_PATH
<code1o6> http://i.imgur.com/GxJrEA6.png
<jdstrand> code1o6: I suggest: sudo snappy install hello-world ; hello-world.env | grep SNAP
<jdstrand> code1o6: whoops
<jdstrand> code1o6: SNAP_DATA, not SNAP_DATA_PATH
<code1o6> jdstrand, yes that what I did SNAP_DATA_PATH
<jdstrand> I know, I said it wrong
<jdstrand> SNAP_DAT
<jdstrand> erf
<jdstrand> SNAP_DATA
<code1o6> jdstrand, testing
<code1o6> jdstrand, Same error message
<code1o6> I though SNAP_DATA was for 16.04
<jdstrand> oh sigh
<jdstrand> SNAP_APP_DATA_PATH
<jdstrand> sorry, that should work
<code1o6> https://github.com/ubuntu-core/snapcraft/commit/04b1a13bc03305bc3180e71ede2f39b3183482d9
<jdstrand> note, hello-world.env is awfully handy
<code1o6> jdstrand, I get the same result
<code1o6> jdstrand, wait
<code1o6> jdstrand, it works so where is $SNAP_DATA_PATH ?
<zyga> code1o6: look at launcher (in $PATH) to see
<zyga> ls /snaps/bin
<code1o6> you mean /apps/bin?
<zyga> yes, sorry :)
<zyga> (I didn't know it changed already, I know it was supposed to change)
<code1o6> I found the bash script but it not in the same directory
<code1o6> zyga, I'm having now luck
<zyga> code1o6: cool :)
<code1o6> zyga, oops *no
<zyga> code1o6: well, all I wanted to say is that you can look at the scripts
<code1o6> Found it but it's empty
<zyga> code1o6: and see what variables are set
<zyga> code1o6: then something is wrong, it should not be empty
<jdstrand> SNAP_DATA_PATH isn't a thing (I said it was, I was wrong). SNAP_DATA is 16.04 and SNAP_APP_DATA_PATH is 15.04. both are in /var/lib/snaps/...
<code1o6> it was /var/lib/apps/
<jdstrand> erf
<jdstrand> 15.04 is /var/lib/apps/...
<jdstrand> ETOOMANYCHANGES :)
<code1o6> yes
<code1o6> jdstrand, I know :(
<code1o6> jdstrand, can I try to run nmap from /apps/blah/bin/nmap
<jdstrand> code1o6: not easily. I suggest adding something to 'binaries' like so:
<jdstrand> binaries:
<jdstrand>   - name: sh
<jdstrand>      caps: [network-client, network-admin]
<jdstrand> let's change that
<jdstrand> binaries:
<jdstrand>   - name: bin/myshell
<jdstrand>     caps: [network-client, network-admin]
<jdstrand> then create bin/myshell to be:
<jdstrand> #!/bin/sh
<jdstrand> sh
<jdstrand> then you can do: appname.myshell
<jdstrand> and get a shell where you can play around with equivalent confinement, run nmap, etc
<jdstrand> code1o6: I'm going to have to step away. good luck!
<code1o6> okay, just add binaries section to snapcraft.yaml
<code1o6> jdstrand, thanks for all help :D
<jdstrand> yeah
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/733/
<zyga> jdstrand: just FYI, you don't have to review it yet
<zyga> jdstrand: this *makes it happen* :-)
<zyga> ogra_: ^^ :-)
#snappy 2016-03-24
<zyga> good morning
<zyga> https://github.com/ubuntu-core/snappy/pull/734
<dholbach> good morning
<zyga> dholbach: morning :)
<dholbach> czeÅÄ zyga
<dholbach> davidcalle, dpm, popey: https://bugs.launchpad.net/snapcraft/+bug/1537786 :)
<ubottu> Launchpad bug 1537786 in Snapcraft "lifecycle: allow do clean rebuild of all/parts without having to pull all again" [Wishlist,Fix released]
<zyga> tschus :-)
<zyga> (if I recall correctly)
<dholbach> tschÃ¼ss :)
<dholbach> but that's goodbye
<dpm> morning dholbach, nice!
<dholbach> 'hallo' should work though :)
<zyga> oohhh
<zyga> then I remember poorly :)
<zyga> thanks for correcting me
<zyga> (that was over a decade ago when I last learned german)
<popey> dholbach: ooh
<dpm> dholbach, do you happen to know which are the clean steps you can use? It seems the info is missing from 'snapcraft clean --help'
<dholbach> dpm, I don't - but I assumed that the bug fix would allow snapcraft to figure out itself what needs updating and what doesn't
<dholbach> dpm, ah now...
<dholbach>     - pull
<dholbach>     - build
<dholbach>     - stage
<dholbach>     - strip
<dholbach>     - snap
<dholbach> ^ that's the steps (from: snapcraft help plugins)
<dpm> dholbach, thanks. https://github.com/ubuntu-core/snapcraft/pull/403
<dholbach> nice one
<davidcalle> dholbach: excellent!
<Ram_> hi
<Ram_> have anyone here ported snappy for an arm device?
<ogra_> hey Ram_, yes, i have (multiple times)
<Ram_> i'm facing a lot of trouble to do so
<ogra_> well, lets go through them and fix them one by one then :)
<Ram_> hi ogra! it's ur blog i'm following to achieve that ;)
<ogra_> oh, thats very old
<ogra_> i will write an up to date entry for 16.04 once it is out
<Ram_> that is nice!
<ogra_> (there have been very massive changes and 15.04 will be EOL soon)
<Ram_> first of all I'm a beginner..
<ogra_> we all were once ;)
<Ram_> i do things by following the blog to port ubuntu core
<ogra_> right, the new setup is not very well documented yet
<ogra_> but i would actually recommend to go for 16.04, despite that
<Ram_> okay!
<Ram_> now i'm using an arm based device, which is having support for kernel v3.14
<ogra_> in the new setup everything is a snap package (no more tarballs, even rootfs, kernel and the bootloader some as a snap)
<ogra_> to do a port you need a gadget snap (bootloader) and a kernel snap for your device
<ogra_> for an arm board you need a working uboot bootloader
<ogra_> (we are preparing for boards that use grub too, but are not there yet)
<Ram_> i got the u-boot.bin, and uImage
<ogra_> did you build the uboot from source ? you will need some patches
<ogra_> here is an example of a gadget snap (for the raspberry pi2 in this case) http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/pi2
<ogra_> here is the patch that we use (it is just a few config options) http://paste.ubuntu.com/15472180/
<ogra_> so first of all, build your uboot with these options enabled
<asac> is there a best practice how to add a user needed for a snap on install?
<ogra_> i doubt you can
<ogra_> (and it would be nonsense, your services run as root and all files are chowned to root when building the snap)
<ogra_> (we use the --all-root option to mksquashfs)
<asac> hmm. so now i am wondering if this is a prob with my vm setup
<asac> i am binding 8021 to 21
<asac> and ftp into it then causes stuff like
<asac> http://paste.ubuntu.com/15486216/
 * asac tries running on same port as the bound port on host
<ogra_> "Remote system type is UNIX."
<ogra_> just use Linux then it will work
<ogra_> *g*
<ogra_> how are the file permissions of the dirs you access there ?
<asac> those should be fine
<asac> i think its because ftp opens new ports
<asac> that then have no forward to the vm
<asac> but thought passive on would fix that
<ogra_> (seems also a bit odd that you end up in the toplevel dir of your snap ....)
<asac> seems passive also creates new ports?
<asac> !ls
<ubottu> The linux terminal or command-line interface is very powerful. Open a terminal via Applications -> Accessories -> Terminal (Gnome), K-menu -> System -> Konsole (KDE), or Menu -> Accessories -> LXTerminal (LXDE). Guide: https://help.ubuntu.com/community/UsingTheTerminal
<ogra_> hmm, no idea
<asac>  !ls shows the local host dir
<ubottu> asac: I am only a bot, please don't think I'm intelligent :)
<asac> so thats fine
<asac> ok guess i should go for the pi2 then next :)
<asac> where i have proper network
<asac> and see
<ogra_> In passive mode FTP the client initiates both connections to the server, solving the problem of firewalls filtering the incoming data port connection to the client from the server. When opening an FTP connection, the client opens two random unprivileged ports locally (N > 1023 and N+1).
<ogra_> http://www.slacksite.com/other/ftp.html
<ogra_>     FTP server's port 21 from anywhere (Client initiates connection)
<ogra_>     FTP server's port 21 to ports > 1023 (Server responds to client's control port)
<ogra_>     FTP server's ports > 1023 from anywhere (Client initiates data connection to random port specified by server)
<ogra_>     FTP server's ports > 1023 to remote ports > 1023 (Server sends ACKs (and data) to client's data port)
<ogra_> so you need more ports :)
<asac> ok i could force fix this by specifying max abnd min pasv port
<asac> saw those entries
<asac> well... guess iits time to go beagle or pi2 now anyway
<asac> just would love to not use ubuntu user for anonymous :)
<asac> but cant create one automatically on install
<ogra_> you cant see the ubuntu user from your snap
<asac> maybe we should have one user per snap that you can then use for services etc.
<ogra_> (i think)
<asac> it can
<asac> well it cant see the home
<asac> buut it can see that that user exists in /etc/passwd
<asac> it seems
<asac> and tahts all that is needed for this
<ogra_> i think jdstrand has a plan for system users in snaps ... but thats likely not 16.04 material
<asac> also i ended up unconfined now :)
<ogra_> you cant see the user in /etc/passwd, bhecause the user isnt in /etc/passwd ;)
<ogra_> nss-extrausers ...
<ogra_> i'm not sure how well getent() works ... might be possibel to use that
<asac> odd
<asac> but it works :)
<asac> think its using libc
<ogra_> *possible
<asac> and that figures it
<asac> i cant use a user that isnt avail
<asac> but i can use ubuntu :)
<asac> as my anon user
<ogra_> yeah, then getent likely works
<asac> which is good news... just would love to have my own user for that snap as i am using a dir somewhere in /var/lib anyway for the anon uploads
<asac> nobody didnt work
<asac> because /nonexistent doesnt exist
<asac> wodner if i should just hack vsftpd more so it doesnt refuse to use nobody
<asac> but *shrug*
 * asac goes and turns the pi2 into a box that will go to living room
<asac> the orange box one
<ogra_> http://paste.ubuntu.com/15486252/
<ogra_> thast my old server setup script ... there is also user creation in it
<ogra_> (ignore the chfn messages btw)
<asac> i must be that folks are stealing usb cables from me at events
<asac> i never forsaw that i had troulbes finding one
<asac> bought like 20 2-3 years back in a bundle ...
<ogra_> heh, thats SD cards for me :)
<asac> now i had to use a 20cm long one and the pi2 is hanging in the air
<asac> yeah sd cards i accept
<asac> but usb cables? wtf
 * asac goes to amazon and orders more :)
<asac> hmm. my pi2 doesnt see new updates
<asac> guess i have to reflash
<asac> ubuntu-core         2016-02-03 16.04.0-7.armhf
<asac> ubuntu@localhost:~$
<asac> that one
<asac> getting https://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz
<asac> and a coffee
<popey> ogra_: downloaded your pi3 image and put on card, Booted up and the last thing I see on the console is "Started OpenBSD Secure Shell server" and if I ssh in, it asks for my password then hangs
<popey> (I had raspbian on this before, so I know the pi itself is fine)
<ogra_> popey, hmm, you should get a login prompt
<ogra_> i definitely do here
<popey> when does it do the partition resize?
<popey> it's a 32GB card
<ogra_> (i dont if i use the same image on a pi2 ... but thats a different issue)
<ogra_> from the initrd
<popey> ok
<popey> so earlier than this
<ogra_> takes about 15sec here for a 128G card
<ogra_> so i'd imagine 32G to be really fast
<popey> yeah, not that
<ogra_> there is definitely a shell on HDMI
<popey> yup
<ogra_> if you ahve a cable around
<popey> i am looking at the output from hdmi
<ogra_> oh, i thought you look at serial, sorry :)
<ysionneau> any idea on how to "debug" this? http://paste.ubuntu.com/15486342/
<ysionneau> how can I understand what's going wrong?
<popey> http://i.imgur.com/g5a63oZ.jpg ogra_
<ogra_> and ssh with ubuntu:ubuntu doesnt work ?
<popey> alan@homeserver:~$ ssh ubuntu@192.168.1.69
<popey> ubuntu@192.168.1.69's password:
<popey> been sat there for minutes
<ogra_> yery weird
 * popey reboots
 * ogra_ does a fresh flash of his image
<popey> i just grabbed the pi xz image you linked to in your mail
<ogra_> ysionneau, where is your gadget source tree ?
<ogra_> popey, yeah, thats what i'm flashing now
<popey> hah, worked this time ð
<popey> i see a login prompt now, but didn't on first boot
 * ogra_ will check that 
<ysionneau> ogra_: it's not published but here is the content : http://paste.ubuntu.com/15486365/
<ogra_> note that cloud-init can take quite long on first boot
<ogra_> ysionneau, i guess it looks for a uboot binary somewhere
<ogra_> or for a uEnv.txt ...
<asac> mvo: is ubuntu-core         2016-02-03 16.04.0-7.armhf canonical
<asac> really the latest?
<popey> hm. trying to install a snap fails - just did "snap find owncloud" and it sees two results (one from kyrofa) and then if I "snap install owncloud" it just returns immediately and doesn't say anything
 * asac apparently cleaned his previous SD for no reason
<asac> mvo: nevermind... found and update
<asac> mvo: are we doing diff downloads yet?
<mvo> asac: if you use rolling/edge you get something newer, its been a while since we did a stable promotion
<asac> mvo: so one thing i noticed: http://paste.ubuntu.com/15486382/
<mvo> asac: no deltas yet will probably take a couple of weeks still
<asac> you guys spit out "reboot" before stuff is synced to disk
<asac> would have caused troubles i guess if i hard rebooted at that point
<asac> had to wait in sync for 20 secs
<mvo> asac: oh, that is interessting. it did not occour to me that people would do hard reboots
<asac> could be its fixed in latest of course... thats the feb image in your peopl
<mvo> asac: but of course this is a different world
<asac> people do everything :)
<mvo> it is not fixed, thanks for bringing it up
<popey> no power switch on a pi :)
<asac> also who knows if they get impatient if reboot command hags for a bit
<asac> would be interesting to see how our tx update behaves
<asac> if its not fully synched
<asac> might try it sometimes when i want to have fun :)
<ogra_> popey, so first boot works fine here ... it properly clears the screen and offers me a ligon prompt
<ogra_> *login
<asac> mvo: i need to update classic by myself right?
<popey> hm, odd
<asac> or is that now done in backgrounrd?
<popey> ogra_: now I can't install any snaps on it
<ogra_> ogra@anubis:~/datengrab/rpi3$ md5sum rpi3-all-snap.img.xz
<ogra_> 07abd31a72f54cfa0c1ae8241073e3d0  rpi3-all-snap.img.xz
<ogra_> popey, yeah, thats normal :P
<popey> hah, ooookay
<popey> why?
<ogra_> snaps are only installable until the next security model renaming :P
<popey> 07abd31a72f54cfa0c1ae8241073e3d0  rpi3-all-snap.img.xz
 * popey blinks
<ogra_> read: kyrofa neesd to update his owncloud snap again
<ogra_> interfaces landed yesterday
<ogra_> (the new security model)
<ogra_> also the rootfs snap is from yesterday morning ... i shoudl probably re-build it with todays rootfs (there might again be more changes)
<popey> ahhh
<dholbach> davidcalle, I created a branch with the examples for the doc
<dholbach> davidcalle, that might make it easier to keep them up to date and allow readers to get them all at once
<kyrofa> Good morning
<kyrofa> ogra_, ah, thanks for the heads up
<kyrofa> ogra_, is that in edge? Or has it gone to stable?
<ogra_> not yet in stable
<ogra_> stable is weeks old
<davidcalle> dholbach: yes of course, thanks :)
<davidcalle> dholbach: how do I run a command on a source before starting eg. a cmake building?
<dholbach> davidcalle, can you elaborate?
<dholbach> or explain what you're trying to do?
<davidcalle> dholbach: the source I'm trying should apparently use the autotools plugin, but before it runs ./configure (which is the first thing the autotools plugin does after getting the source), I need to run another command.
<dholbach> mh... no idea
<dholbach> kyrofa, ^ do you have a solution for such a case?
<kyrofa> davidcalle, dholbach perhaps the simplest thing to do would be to ship a custom in-tree plugin that inherits from autotools and does what you want?
<dholbach> of course... :)
<dholbach> https://developer.ubuntu.com/en/snappy/build-apps/plugins/
<dholbach> davidcalle, ^
<davidcalle> kyrofa, dholbach: alright, looking into this, thanks :)
<kyrofa> davidcalle, are you hitting this? https://bugs.launchpad.net/snapcraft/+bug/1551716
<ubottu> Launchpad bug 1551716 in Snapcraft "snapcraft does not allow vendor/platform patching of upstream sources (aka: add patch phase to lifecycle)" [Undecided,New]
<davidcalle> kyrofa: nope, it's just an extra build command that is required by the source
<kyrofa> davidcalle, ah, okay interesting. Yeah, the custom plugin is probably the way to go, but that doc sorely needs to be updated. Maybe I'll do that this morning
<davidcalle> kyrofa: alright, nothing urgent, I can move on to snapping something else for now, thanks!
<davidcalle> (unless I manage to find my way with the doc of course ;) )
<kyrofa> davidcalle, just don't worry about the `handle_source_options()` call
<kyrofa> davidcalle, and the x-crafty.yaml is now done via the schema function
<kyrofa> davidcalle, honestly you can mostly rip this off: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/autotools.py
<davidcalle> kyrofa: that's what I'm doing and adding the command I need
<kyrofa> davidcalle, perfect
<davidcalle> kyrofa: I'll probably look later into doing proper inheritance, though, but I want the build part out of the way for now
<ogra_> mvo, should "snappy install --allow-unauthenticated ..." work for os and kernel snaps (doesnt here, i got exclamation marks in snappy list after a reboot)
<mvo> ogra_: hm, that should work, what does grub-editenv list output?
<davidcalle> kyrofa: how do I define the name of my plugin, with the schema function? Do I still need to keep the plugin yaml file?
<ogra_> mvo, no grub on my rpi3 :P
<kyrofa> davidcalle, it's determined from the file name
<ogra_> looking at serial i see it loading the right kernel on reboot though
<davidcalle> kyrofa: alright :)
<ogra_> mvo, aha, after a second reboot it is fine
<ogra_> so there seems to be something wrong with the sequence
<mvo> ogra_: fw_printenv iirc it is then :)
<mvo> ogra_: but ok, if you rebooted the output will no longer be interessting
<ogra_> http://paste.ubuntu.com/15486754/
<ogra_> right ... i'll try tomorrow again :P
<ogra_> oh, webdm works again (didnt yesterday)
<ogra_> hmm, the store UI changed
<kyrofa> Does ubuntu core use ntp?
<ogra_> timedated iirc
<kyrofa> Ah, I'm not familiar with that
<zyga> kyrofa: part of systemd AFAIR
<kyrofa> zyga, yeah seems so. Thanks guys!
<kyrofa> zyga, ogra_ verified, and network time is on. Perfect
<dholbach> dpm, if you rebuild the clock app snap, can you still launch it?
<dholbach> I get: aa_change_onexec failed with -1. errmsg: Permission denied
<davidcalle> kyrofa: one more question, pulling stage-packages is failing because of a silly "E:Unable to correct problems, you have held broken packages.", is there a container somewhere I can log into to fix this?
<kyrofa> davidcalle, huh, no that stuff is way simpler than a container-- the packages are simply downloaded and unpacked. So there must be a dependency issue in the debs you're pulling?
<dpm> dholbach, I don't know, I'll have to try next week. Preparing to leave now
<dholbach> dpm, ok, sounds good
<dholbach> dpm, have a great time!
<davidcalle> kyrofa: oh ok, I was assuming it was somehwere special, sounds good
<dholbach> davidcalle, is it libubuntutoolkit5 vs libubuntutoolkit5-gles or something?
<davidcalle> dholbach: nope, the list being awfully long, I haven't found which one exactly yet :)
<jdstrand> ogra_, asac: "i think jdstrand has a plan for system users in snaps" - I don't. the only thought I had was that if we did optional uids for a snap, we'd need seccomp arg filtering
<dholbach> davidcalle, ok
<ogra_> jdstrand, ah, i thought you wanted to add them inside the snap somehow
<jdstrand> I might've mentioned I could imagine yaml to opt-in
<kyrofa> davidcalle, maybe fire up an lxc and try to install them all?
<jdstrand> but I'm not driving it and there is no design
<jdstrand> I did suggest it would be a nice feature
<ogra_> i surely dont think snap users should be added to the system passwd db though ... it would have to be some pre-snap overlay thing
<ogra_> *per-snap
<ogra_> thanks for clearifying though
<kyrofa> So jdstrand sounds like interfaces finally landed in edge? If I'm using old-interface's network-listener, what does that become?
<jdstrand> plugs: [network]
<kyrofa> jdstrand, ah that simplifies things. And network-bind is the service side of it?
<jdstrand> indeed
<jdstrand> kyrofa: note, those are the only two right now. there are MPs for the other 12
<jdstrand> err, PRs
<kyrofa> jdstrand, awesome
<kyrofa> ogra_, say I want to ship a Snappy-powered device that will be on the open internet. Obviously I don't want to ship with the default ubuntu/ubuntu creds. What is the recommended way of dealing with this?
<qengho> kyrofa: There shouldn't be a network listener, right?
<ogra_> kyrofa,  we dont have any recommended way yet ...
<kyrofa> qengho, well that's a little in flux right now. If running 16.04 edge, it's just the listener interface. If 16.04 stable, it's the network-listener thing
<ogra_> technically you shouldnt have ssh running ... practically all 16.04 images currently have it
<ogra_> so for now, change the password
<kyrofa> ogra_, what if I actually DO want SSH running, but want to lock it down a little more?
<qengho> kyrofa: I mean there should be no way for someone to use the default password One Day.
<kyrofa> qengho, oh man I totally misunderstood you :P
<ogra_> kyrofa, copy a key in place and disable password auth completely in /etc/ssh/ssh_config
<kyrofa> ogra_, is that something I can do in the image?
<ogra_> manually, yeah
<kyrofa> ogra_, kpartx, modify, dd again?
<ogra_> nah, after first boot
<ogra_> i mean you could kapratx/dd it and all, but it would be the same key everywehere ... so thats a rather useless attempt
<ogra_> *kpartx
<kyrofa> ogra_, right, duh. Hmm...
<dholbach> davidcalle, we should talk on tuesday and figure out how we finish this guide
<dholbach> first thing :)
<davidcalle> dholbach: +1, I'm interested into reshaping - at least - the intended layout for examples, taking into account evan's email.
<dholbach> yep
<davidcalle> dholbach: first thing coming to mind is a list of "I want to ... " bullet points and one example for each need we recognize.
<dholbach> +1
<renat> Hi guys! It's Renat from Screenly=)
<renat> I'm trying to run our programs on the new built image and getting "seccomp_load failed with -22" error
<beuno> jdstrand, ^
<qengho> renat: do your programs uses seccomp filters, inside?
<jdstrand> I know the problem
<jdstrand> renat: does it work if you uninstall the snap and then reinstall?
<renat> beuno, qengho, jdstrand, hello=)
<jdstrand> hi :)
<renat> let me try to reinstall it
<renat> jdstrand, no. didn't help
<rajen> Hi, Is there any 16.04 Snappy documentation available. All the documentation on https://developer.ubuntu.com/en/snappy/guides/ points to 15.04 model
<jdstrand> renat: can you paste the output of 'cat /var/lib/snappy/seccomp/profiles/<snapname>...' into paste.ubuntu.com?
<renat> qengho, yes. I set up it for other app using plugs system
<renat> jdstrand, sure. 3 min
<renat> jdstrand, https://paste.ubuntu.com/15488307/
<jdstrand> interesting, that isn't what I expected to see
<jdstrand> renat: can you paste the output of 'grep audit /var/log/syslog'
<renat> It used to work with older image I built
<renat> jdstrand, https://paste.ubuntu.com/15488327/
<qengho> renat: those parts are stirred often, in development.
<qengho> "brk" is a dangerous syscall? So, malloc doesn't work?
<jdstrand> qengho: I think you misread that
<jdstrand> # end dangerous syscalls
<jdstrand> ...
<jdstrand> brk
<jdstrand> we allow brk
<renat> Yes, brk is allowed.
<jdstrand> renat: if you do 'cat /var/lib/snappy/seccomp/profiles/<snapname>...' is there a final newline?
<renat> jdstrand, 2 newlines=)
<jdstrand> ok
<jdstrand> let me try to reproduce locally
<jdstrand> renat: can you paste the output of 'snappy info'
<qengho> Oh!
<renat> jdstrand ubuntu@localhost:~$ sudo snappy info
<renat> release: core/rolling
<renat> architecture: armhf
<renat> frameworks:
<renat> apps: screenly-client.sideload
<renat> ubuntu@localhost:~$ sudo snappy info
<renat> release: core/rolling
<renat> architecture: armhf
<renat> frameworks:
<renat> apps: screenly-client.sideload
<renat> https://paste.ubuntu.com/15488370/
<renat> Oh.... Sorry
<jdstrand> no worries
<jdstrand> what about snappy list?
<renat> https://paste.ubuntu.com/15488375/
<ogra_> i think i saw such an error from the core launcher these days ... havent seen it again with newer images though
<renat> screenly-oem-pi2 is an image bult from canonical-pi2.canonical version 3.2
<renat> Hello, ogra_!
<ogra_> hey
<ysionneau> I added the uboot.env but it's still failing :x
<ysionneau> I tried to read the strace results ... I could not get the reason clearly
<renat> I'm trying with older image. 10 min.
<ogra_> renat, canonical-pi2.canonical is a gadget snap ... i was talking about later ubuntu-core
<jdstrand> renat: what is the output of sha256sum /usr/bin/ubuntu-core-launcher
<renat> ogra_, understood. I use ubuntu-core snap automatically downloaded during the build process.
<ogra_> right, thats a rather old one
<ogra_> (somewhere around feb.)
<jdstrand> ogra_: hey, I have a core/rolling image, but it is using the os snap from monday. is there a newer os snap somewhere? how would I generate an image to use it?
<jdstrand> renat: 11:57 < jdstrand> renat: what is the output of sha256sum /usr/bin/ubuntu-core-launcher
<jdstrand> renat: (on the broken image)
<jdstrand> ogra_: this is for qemu amd64
<renat> jdstrand, 5 min please. I'm re-flashing an image=(
<ogra_> jdstrand, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ :)
<ogra_> (indeed onyl for sideloading ... )
<jdstrand> ogra_: is xenial-preinstalled-core-amd64.tar.gz a qemu raw image?
<ogra_> jdstrand, no, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-amd64.os.snap is an ubuntu-core os snap :)
<jdstrand> ogra_: I'm able to sideload that in a running image?
<ogra_> not sure if that works on one where it was initially not sideloaded ...
<ogra_> it works on my locally built one with a simple "sudo snappy install --allow-unatuthenticated ..."
<jdstrand> ok
<jdstrand> and same with the kernel?
<ogra_> yep
<jdstrand> ok, let me try that
<jdstrand> shoot it does't work
<jdstrand> /tmp/xenial-preinstalled-core-amd64.os.snap failed to install: package "ubuntu-core" is already installed with developer "canonical" your developer is "sideload"
<jdstrand> ogra_: how do I generate an image from those snaps?
<jdstrand> sorry, I've not had to do this before
<ogra_> use mvo's u-d-f
<renat> jdstrand, aa74d0040f626c2d090ae99d1534924cf6d4e905f5939fbadf179eff3950f12a  /usr/bin/ubuntu-core-launcher
<jdstrand> renat: this is on an image that is busted?
<ogra_> with --gadget pointing to canonical-pc ... --os ponting to the os snap and --kernel pointing to canonical-pc-linux or a downloaded kernel snap
<renat> jdstrand, yes. That image doesn't work
<jdstrand> renat: ok, I'm going to try to reproduce locally
<renat> I tried with older image, and it worked successfully. So it's not related to screenly-client snap.
<jdstrand> ogra_: thanks, where is canonical-pc?
<ogra_> in the store
<renat> jdstrand, thanks. I built that image today. Less than 4 hours ago.
<ogra_> just use --gadget canonical-pc
<jdstrand> oh and it'll fetch it
<jdstrand> ok
<ogra_> it shoudl download it
<jdstrand> ogra_: http://people.canonical.com/~mvo/all-snaps/ubuntu-device-flash ?
<ogra_> yep
<ogra_> ysionneau, could be that u-d-f checks for an existing boot-assets dir in the gadget snap ... try moving your uboot.env file in such a subdir (and adjust the snap.yaml)
<ysionneau> ah ok, will try thanks
<ysionneau> those stuff really should be documented (but I know it's in the pipe :p)
<ogra_> itsd not onyl in the pipe, it is also supposed to change (again)
<ogra_> EEEK !
<ogra_> CPP     xbmc/ApplicationPlayer.o
<ogra_> g++: internal compiler error: Killed (program cc1plus)
<ogra_> Please submit a full bug report,
<ogra_> with preprocessed source if appropriate.
<ogra_> *sniff*
<ogra_> that was after 4h compiling kodi on the rpi3 :(
<ysionneau> 18:17 < ogra_> ysionneau, could be that u-d-f checks for an existing boot-assets dir in the gadget snap ... try moving your uboot.env file in such a subdir  < I've just tried, same error
<jdstrand> hrmm
<jdstrand> ogra_: --gadget canonical-pc
<jdstrand> Determining gadget configuration
<jdstrand> expected 1 gadget snaps, found 0
<ogra_> jdstrand, try appending .canonical
<ogra_> i thought that was aliased
<ysionneau> ogra_: that's where cross compilation is convenient :p
<ogra_> ysionneau, nah
<jdstrand> that did it
<jdstrand> thanks!
<ogra_> it would be the same toolchain ... wouldnt help
<ogra_> (not with an ICE at least)
<ysionneau> it would help for the "after 4h compiling" :p
<ogra_> yeah, its not like i am in a hurry :)
<renat> Guys, could you tell, please, where can I find snap download uris for os and kernel snaps?
<ogra_> the build just runs on the side on an unused pi3 ;)
<renat> I found couple by "guessing". https://public.apps.ubuntu.com/anon/download/canonical/ubuntu-core.canonical/ubuntu-core.canonical_16.04+20160321.17-37_armhf.snap
<ogra_> renat, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ has the dailies
<ogra_> for an rpi you want xenial-preinstalled-core-armhf.raspi2.kernel.snap  and xenial-preinstalled-core-armhf.os.snap
<renat> Ahh... Really? They used to work before=)
<renat> ogra_, let me try. Thanks!
<ogra_> the others you posted work too
<ogra_> (they are the same, just uploaded to the store by hand ... so they are usually a few days older )
<jdstrand> renat: ok, using the kernel and os snaps in http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ I cannot reproduce on amd64
<renat> jdstrand, thanks. I will try re-create snaps. Let me see if that snaps will fix the issue.
<jdstrand> renat: I think what happened is you grabbed a new kernel snap and an old os snap. the ubuntu-core-launcher needs to be 1.0.20 to work with the latest Ubuntu kernels. we'll see what your snaps say
<jdstrand> s/snaps/new flash/
<renat> jdstrand, how can I know ubuntu-core-launcher version?
<renat> Unfortunately - it still doesn't work with the same error.
<jdstrand> renat: that is why I asked for the sha256sum
<jdstrand> renat: actually, there is a manifest file
<jdstrand> renat: is this what you used: http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-armhf.manifest
<jdstrand> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-armhf.os.snap
<renat> Yes. This is the file I used to build image.
<renat> The 2nd one.
<jdstrand> can you do sha256sum /usr/bin/ubuntu-core-launcher again?
<renat> https://paste.ubuntu.com/15489051/
<renat> 837ab5d35b9d2f757ef85ce51a10bd6084c5b122af829e3fe12ebef35af7cee3  /usr/bin/ubuntu-core-launcher
<jdstrand> ok, that is what is in 1.0.20
<jdstrand> renat: since this is a whole new image, can you paste the output of 'cat /var/lib/snappy/seccomp/<snap>...
<renat> Sire
<renat> Sure
<renat> jdstrand, https://paste.ubuntu.com/15489090/
<jdstrand> ok
<jdstrand> renat: can you paste the output of 'grep audit /var/log/syslog'?
<renat> jdstrand, which kernel version should I use to work with previous versions of ubuntu-device-flash tool?
<renat> https://paste.ubuntu.com/15489095/
<jdstrand> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-armhf.raspi2.kernel.snap should be fine
<jdstrand> renat: can you file a bug?
<renat> jdstrand, yes. I will investigate the issue a little first.
<renat> Thanks for help.
<renat> Disconnecting.
<jdstrand> renat: one other thing
<jdstrand> renat: can you install the hello-world app, then run hello-world.env?
<renat> Doing
<renat> The same error, jdstrand
<jdstrand> ok, then it isn't your app
<jdstrand> renat: actually, I can lead you through a rather complicated process to see if it is the launcher
<jdstrand> renat: do you have time?
<rootx_> hello
#snappy 2016-03-25
<ccfiel> hello guys
<ccfiel> hello
<ccfiel> hello anybody here? :)
<renat> Hi all! It's Renat from Screenly.
<renat> Hello, jdstrand. I created a bug report with the issue I get: https://bugs.launchpad.net/snappy/+bug/1561920
<ubottu> Launchpad bug 1561920 in Snappy "Seccomp error on recent builds of snappy" [Undecided,New]
<kyrofa> Good morning
<didrocks> hey kyrofa!
<didrocks> how are you?
<kyrofa> Hey didrocks! Doing well, and yourself? Keeping busy?
<didrocks> kyrofa: yeah, just back from Paris (stayed a couple of days for some event and meetup)
<kyrofa> Sounds like fun! I plan on trying to go there next time I'm in london
<didrocks> sweet! :)
<didrocks> I demoed there the ascii as a service that I teased you about: https://twitter.com/didrocks/status/712916851186143232
<jdstrand> renat: ok, thanks
<ccfiel> hello guys!
<kyrofa> didrocks, haha, that's awesome :)
<jdstrand> renat: before you said that this worked on a previous image. what did you mean by that?
<jdstrand> renat: what kernel, what os, etc
<ccfiel> hello
<ccfiel> anybody here? :)
<kyrofa> jdstrand, so I'm snapping a codebase that makes a call to setpriority(). That's denied under seccomp and the execution is aborted
<kyrofa> jdstrand, my current patch is to just comment out the setpriority(), but I'd like to suggest an upstream patch. Is there any way to check and see if setpriority() can be called before calling it?
<kyrofa> ccfiel, people are always here :) . If you have a question, just ask!
<ccfiel> kyrofa: hello! i know snappy has a copy plugin thats copy single file. how about multi files?
<kyrofa> ccfiel, the copy plugin can copy many files
<jdstrand> kyrofa: not otoh. if you use it you get killed. if you could introspect your seccomp policy, perhaps, but you can't
<kyrofa> jdstrand, hmm...
<kyrofa> jdstrand, so in the case of seccomp-restricted calls, there's no upstream patch we can suggest huh?
<kyrofa> That's a bummer
<jdstrand> a compile time option or a runtime option to not use it could work
<ccfiel> kyrofa, where can I find a format in copy plugin? any tips?
<kyrofa> jdstrand, ah, yeah compile-time flag, good idea. Not sure why I didn't think of it, thanks!
<kyrofa> ccfiel, yeah that plugin doesn't have documentation, huh!? Please log a bug on that. Until we fix that, have a look at this example: https://github.com/ubuntu-core/snapcraft/blob/master/examples/webcam-webui/snapcraft.yaml
<kyrofa> ccfiel, note the `files` key. Just add more items to it
<josepht> I filed bug #1562000 against snapcraft.  I was starting to worry when I got an email yesterday about a snap I uploaded to the store but didn't upload a snap to the store.
<ubottu> bug 1562000 in Snapcraft "when running runtest.sh while logged in uploads a snap to the store" [Undecided,New] https://launchpad.net/bugs/1562000
<jdstrand> olli: hey, mentioning this to you because mvo is offline. bug #1561920 seems to be a problem with the raspi2 kernel
<ubottu> bug 1561920 in Snappy "Seccomp error on recent builds of snappy" [Critical,Confirmed] https://launchpad.net/bugs/1561920
<jdstrand> olli: see my comment #2
<ccfiel> kyrofa, ok. I have already tested it. So we need to do for now specify each of the files. There is no option for wild cards *.py  :) is that correct?
<jdstrand> olli: summary-- rpi2 cannot launch confined apps
<jdstrand> olli: I'm not sure who this would be assigned to, so coming to you
<olli> jdstrand, looking
<olli> trying to assign to ogra_
<ogra_> boo
<ogra_> :P
<olli> I hear you do things with dem RPis
<ogra_> yeah ... assign to me ... most likely a kernel issue though
<jdstrand> I'm going to try the previous kernel now
<ogra_> (thought i'm not sure what the --enable-ssh and --developer-mode options do to the all-snaps image ... afaik they are obsolete and might break stuff)
<kyrofa> ccfiel, that should work
<ogra_> there is a new kernel in -proposed ... but we need to wait til it migrated
<kyrofa> ccfiel, the copy plugin does globbing
 * ogra_ notes that he isnt officially here :)
<kyrofa> Right, ogra_ out today and Monday, yeah?
<ogra_> yep
<ogra_> (finally some time to play with kodi on the rpi ;) )
<kyrofa> ogra_, snapping? Or that custom distro?
<jdstrand> ogra_: where is canonical-pi2-linux?
<jdstrand> I don't see it in the shared account
<jdstrand> oh, I might have a way to find it
<ogra_> jdstrand, pick the right package type at the top
 * ogra_ *always* runs into that 
<jdstrand> oh there it is
<ogra_> :)
<kyrofa> josepht, yeesh, sorry about that
<ogra_> daily is at http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-armhf.raspi2.kernel.snap
<jdstrand> that's weird, the shared account looks like it is showing snappy stuff, and then you click on core apps and you get different snappy stuff
<ogra_> yeah
 * ogra_ would appreciate a cookie that just saves your last view
<ogra_> after login it defaults to click ...
<jdstrand> ogra_: I guess your on holiday (sorry). I'm going to run down those kernels and see which one last worked
<ogra_> LD      kodi.bin
<ogra_> -----------------------
<ogra_> Kodi built successfully
<ogra_> -----------------------
<ogra_> (classic)ubuntu@localhost:~/xbmc$
<ogra_> :D
<olli> whut?
<olli> seriously?
<kyrofa> ogra_, good luck _running_ it
<ogra_> only built the git tree yet and running it under xorg in classic ...
<kyrofa> Ah!
<ogra_> cleaning that up for snappification comes later :)
<ccfiel> kyrofa, i tried *.py: bin/*.py
<olli> ogra_, mind grabbing that bug from Jamie, apparently I am not smart enough to assign you
<ccfiel> but error " expected alphabetic or numeric character, but found '.' on line 22 of snapcraft.yaml"
<olli> https://bugs.launchpad.net/snappy/+bug/1561920
<ubottu> Launchpad bug 1561920 in Snappy "Seccomp error on recent builds of snappy" [Critical,Confirmed]
<ogra_> olli, done
<olli> thx
<kyrofa> ccfiel, try *.py: bin/
<kyrofa> Hmm... that still may not work
<jdstrand> hrmm, installing canonical-pi2-linux.canonical_4.3.0-1006-6_armhf.snap hosed my install
<jdstrand> ogra_: is there a minimum kernel snap version I need to use with latest os/udf/etc?
<ogra_> nope, shouldnt
<ogra_> thats indeed 4.3
<ogra_> 4.4 waits for elopio to approve
<jdstrand> ogra_: in the bug you can see that 4.4 is in the store
<ccfiel> kyrofa, when I add in files. in copy it does not executed. do I need to do snappy clean always if I change something?
<ogra_> (though i think we should simply release the whole set untested as alpha for now ... so we finally have something usable )
<jdstrand> oh, it is starting to come up
<ogra_> jdstrand, 4.4 is on cdimage and uploaded to the store into edge
<kyrofa> ccfiel, indeed, Snapcraft doesn't currently notice changes in the yaml. It's something we're working on
<ogra_> but not moved to stable
<jdstrand> I see what you mean
<jdstrand> oh, I think rollback may have worked
<jdstrand> I'm back into the 4.4 kernel
 * jdstrand regenerates with udf
<jdstrand> kyrofa: fyi, I found myself doing this a lot lately with dirs in different locations and not wanting to overlay '/': http://paste.ubuntu.com/15496227/
<jdstrand> kyrofa: I imagine you probably already scripted that, but if not, there you go
<jdstrand> ./overlay-dir /lib
<jdstrand> ./overlay-dir /usr
<jdstrand> etc
<kyrofa> jdstrand, awesome, thanks! I hadn't actually-- haven't had to use it recently, but I'll keep this in my back pocket
<kyrofa> Super useful
<jdstrand> it is quite handy
<ccfiel> kyrofa, clean and doing staging again takes long to finish :(
<kyrofa> ccfiel, try just `snapcraft clean -s build` to only clean back to the build step
<kyrofa> So you don't need to pull again etc.
<kyrofa> Although I guess that depends on what version of snapcraft you're on
<jdstrand> hmm, that 4.3 kernel will not boot
<ccfiel> kyrofa, I will try that next time I do a clean
 * jdstrand move to next one
<renat> jdstrand, hello!
<renat> If you want to boot previous version of the kernel you need to use canonical-pi2.canonical version 3.0
<jdstrand> renat: this one: https://myapps.developer.ubuntu.com/dev/click-apps/4284/rev/3/
<renat> jdstrand, access denied=(
<jdstrand> renat: canonical-pi2-linux.canonical_4.3.0-1006-2_armhf.snap
<jdstrand> ?
<renat> canonical-pi2-linux.canonical_4.3.0-1006-6_armhf.snap
<jdstrand> I tried that one. it wouldn't boot
<renat> This gadget snap will boot canonical-pi2.canonical_3.0_all.snap
<jdstrand> renat: what udf invocation are you using with that kernel?
<renat> Yes, you need appropriate gadget snap.
<renat> I don't know=(
<jdstrand> oh, which gadget snap?
<jdstrand> oh I see
<jdstrand> man, these packages names are quite similar
<renat> Previous version. 3.0: https://public.apps.ubuntu.com/anon/download/canonical/canonical-pi2.canonical/canonical-pi2.canonical_3.0_all.snap
<renat> This may work. I create our gadget snap from it.
 * jdstrand is trying
<ogra_> you can use any gadget btw ... but need to manually copy the dtb from system-boot/canonical..../dtbs to system-boot/
<ogra_> (by default 3.0 uses the dtb from kernel 4.3 and 3.1+ uses 4.4)
<jdstrand> ah
<jdstrand> that explains that them
<jdstrand> then*
<jdstrand> ogra_: I can confirm that 4.3.0-1006-6 works. would it help if I went farther?
<ogra_> jdstrand, nah ... i'll talk to ppisati
<jdstrand> ok
<ogra_> and we should also wait for the kernel from -proposed
<ogra_> jdstrand, can you run dmesg without sudo on 4.3 ?
<ogra_> i noticed i cant on 4.4
<ogra_> might be related
<ogra_> ppisati, could you take a look at bug 1561920 ... seems kernel related
<ubottu> bug 1561920 in Snappy "Seccomp error on recent builds of snappy" [Critical,Confirmed] https://launchpad.net/bugs/1561920
<ppisati> ogra_: added it to the pile, i'm finishing one thing with the dboard ATM
<ogra_> no hurry ftrom my side :)
<josepht> I'm trying to build a armhf version of my snap on my rpi2 but I'm getting a checksum mismatch when it's reviewed in the store.  https://myapps.developer.ubuntu.com/dev/click-apps/4710/rev/7/
<ccfiel> kyrofa, it works just need to put qoute '*.py': bin/
<ysionneau> http://paste.ubuntu.com/15498365/ < where can I find the "AppArmor 2.4 compatibility patches"?
<ysionneau> ah seems to be there http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/apparmor/vivid/files/head:/kernel-patches/3.10/
<josepht> kyrofa: do you have any idea why I'd see that? ^
<stgraber> jdstrand: new LXD rc uploaded to the store
<jdstrand> approved
<stgraber> thanks
#snappy 2016-03-27
<popey> just updated my edge pi 2 and now it doesn't boot.
<popey> http://imgur.com/RNyqX2C
<popey> ubuntu@localhost:~$ snap find
<popey> error: no snaps found
<popey> :(
<popey> oh, canonical datacentre issue probably I imagine
#snappy 2017-03-20
<mup> PR snapd#3061 opened: Renamed thumbnailer interface to thumbnailer-service interface <Created by michihenning> <https://github.com/snapcore/snapd/pull/3061>
<mwhudson> hm
<mwhudson> hello
<mwhudson> so on debian, if you install snapd then install (say) hello, the install of the core snap fails
<mwhudson> (hangs at "run configure hook")
<mwhudson> the configure hook has a defunct snapctl subprocess
<mwhudson> running snap install core by itself works
<mwhudson> ah well off to lp for this i think
<mup> Bug #1674193 opened: core snap's configuration hangs on debian <Snappy:New> <https://launchpad.net/bugs/1674193>
<zyga> o/
<mup> PR snapd#3046 closed: many: merge release/2.23 into master <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3046>
<mup> PR snapd#3062 opened: many: merge release/2.23 branch back to master <Created by zyga> <https://github.com/snapcore/snapd/pull/3062>
<mup> PR snapd#3063 opened: tests: re-enable tests for /dev/pts on core <Created by zyga> <https://github.com/snapcore/snapd/pull/3063>
<lool> jdstrand: hey!
<lool> jdstrand: one partner snap was using sysctl -w net.ipv4.ip_forward=1
<lool> jdstrand: oh actually sorry, I read wrong
<lool> jdstrand: I was about to ask that sysctl be allowed to run
<lool> but I see that's correctly already part of network-control
<lool> jdstrand: (I thought writes to proc/sys were allowed but not running sysctl, but it is allowed - sorry for the bother)
<lool> it's just that the snap was lacking network-control
<lool> actually this might miss rw on forwarding
<jdstrand> lool: use firewall-control for ip_forward. I agree this should also be in network-control and have added a todo for that
<lool> jdstrand: I think it's actually in network-control
<jdstrand> it isn't (I just checked)
<lool> @{PROC}/sys/net/ipv{4,6}/** rw,
<nothal> lool: No such command!
<jdstrand> oh, yes, ok, good
<jdstrand> I only grepped for ip_forward
 * jdstrand removes todo
<ogra_> jdstrand, do you remember if apparmor had issues with all overlay filesystem variants, or was that overlayfs specific
<jdstrand> JamieBennett: hey, fyi, I drove the store reviews down such that the only things that are left are classic confinement snaps from non-Canonical employees
<ogra_> (i remember that was discussed at some sprint)
<lool> I had initially thought sysctl was missing because the ordering of the files wasn't the same (sysctl mentioned just before proc entries in https://github.com/snapcore/snapd/blob/master/interfaces/builtin/firewall_control.go but in separate listing in https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_control.go)
<jdstrand> ogra_: it's mostly overlay and overlayfs. iirc, aufs is mediatable to a large extent (but our policy isn't written for it). I'm going to defer to tyhicks and jjohansen on the details
<JamieBennett> jdstrand: OK, let me take a look, thanks
<renat> Hi guys!
<renat> I have two pull requests https://github.com/snapcore/snapd/pull/3045 and https://github.com/snapcore/snapd/pull/3051
<mup> PR snapd#3045: interfaces: add random interface <Created by femdom> <https://github.com/snapcore/snapd/pull/3045>
<mup> PR snapd#3051: interfaces: add consoles interface <Created by femdom> <https://github.com/snapcore/snapd/pull/3051>
<renat> Unit tests pass for them, but other tests fail=(
<renat> Could you, please, take a look?
<ogra_> niemeyer, see above ... seems aufs could be made working for your ideas
<niemeyer> ogra_: Problem is it's not in mainline, which means cross-distro headaches
<ogra_> yeah, indeed
<ogra_> same for ubuntu-core kernels etc ...
<renat> niemeyer, hi=)
<niemeyer> renat: Heya
<renat> niemeyer, could you please look at my pull requests related to consoles an random interface. Test failed because of the timeout
<ogra_> renat, uhm ... tty0 isnt always the system console ... you should better read it from /proc/cmdline
<ogra_> (in fact tty0 is very rarely the system console on actual ubuntu-core images)
<niemeyer> renat: Will do!  We've been rotating over the open PRs two or three times a week
<renat> niemetyer, thanks!
<renat> niemeyer, sorry
<niemeyer> renat: np, pinging is fine as well
<renat> ogra_, we need an interface to access that file)
<ogra_> renat, even if it isnt your console device at all ?
<ogra_> renat, i'd keep /dev/console and dynamically allow whatever is defined in console= from 7proc/cmdline
<ogra_> */proc
<tyhicks> ogra_: re overlay variants> I think aufs has an issue similar to ecryptfs (they're both stacked filesystems) where the policy has to grant permissions to two different filesystem paths
<tyhicks> ogra_: that's something that can be worked around in policy
<renat> ogra_ thanks. I need to read more about it)
<mup> PR snapd#3056 closed: overlord: when shutting down assume errors might be due to cancellation so retry <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3056>
<mup> PR snapd#3062 closed: many: merge release/2.23 branch back to master <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3062>
<mup> PR snapd#3057 closed: systemd: mount the squashfs with nodev <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3057>
<kyrofa> mcphail, you asked me about the nextcloud snap notifying you. I'm not sure when you pinged me, but I was out last week
<kyrofa> mcphail, from talking with oparoz, it sounds like there's an app I might be able to tie into for notifications (we have a bug for it), but I haven't had a chance to look into it yet
<elopio> ogra_: ping, are you around? Could you please review https://github.com/snapcore/snapcraft/pull/1198/files ?
<mup> PR snapcraft#1198: tests: add manual tests for the kernel snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1198>
<ogra_> elopio, i looked yesterday already buit there wasnt much there ... checking againg
<ogra_> -g
<ogra_> elopio, i think sergiusens' comment still applies, i'm not sure where they maintain the Makefile tree nowadays, most likely not under lp:pc-kernel-snap anymore ... bjf would knwo
<elopio> ogra_: I thought you maintained the make. This makes a lot of sense, because it's not booting :)
<elopio> bjf: ping, where do you have the snapcraft.yaml for the pc kernel?
<ogra_> elopio, i used to and then handed over to the kernel team ... since it is their realm after all
<ogra_> elopio, the instructions look fine to me
<ogra_> elopio, you dont need the --image-size 3G, that way you also test the auto-resize on first boot alongside ;)
<ogra_> -image-size 3G is really only needed for kvm
<elopio> I'll remove it. Thanks.
<bjf> elopio, https://launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial
<ogra_> oh, interesting, so master only has the makefile and the snapcraft.yaml's are in branches ... such a setup had never struck me
 * ogra_ now knows why he handed it over ;)
<elopio> bjf: thank you! If you have some minutes, it would be nice to also get a review from you: https://github.com/snapcore/snapcraft/pull/1198
<mup> PR snapcraft#1198: tests: add manual tests for the kernel snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1198>
<ogra_> i wonder if you cant actually force-sideload a kernel on an existing image to test ...
<ogra_> (surely breaks the auth stuff in the end but probably a lot less work for a one-shot test to see if it still boots)
<elopio> ogra_: this is not a lot of work, as we do it only if we change the kernel plugin, a couple of time before the release.
<ogra_> elopio, hmm, so you test the kernel plugin by building a kernel that doesnt use the kernel plugin ?
<elopio> ogra_: the 96boards example uses the kernel plugin. That's the test we wanted.
<ogra_> elopio, right, then you dont want bjf's branch
<elopio> I added pc only for completeness. I'm not yet sure what we win by running it, as we almost never change the make plugin these days, so I'm not yet sure when we should run it.
<ogra_> since that uses binaries from the archive
<ogra_> like all our offical kernel snaps do
<ogra_> (to get the signing key for potential secure boot solutions)
<elopio> yup. Ideally as we discussed some days ago, the signing could be done with scriptlets and we could use the kernel plugin for all our plugins.
<elopio> but that's not something we are in a hurry to do, I think.
<ogra_> elopio, i think ppisati has trees for all kernels that can use the kernel plugin directly
<ogra_> the signing cant be done with scriplets ... because you dont have the secret key
<elopio> ogra_: I'm trying to add those to our nightlies. https://github.com/elopio/snapcraft-de-noche/pull/21/files
<mup> PR elopio/snapcraft-de-noche#21: Add the kernels <Created by elopio> <https://github.com/elopio/snapcraft-de-noche/pull/21>
<elopio> with some errors there still to investigate.
<ogra_> afaik the secret part of the archive key is spread across multiple people and split ... and parts of that live in a safe somewhere
<ogra_> so signing something with it manually will be quite a challenge
<ogra_> elopio, yeah, that one looks more correct for testing the plugin
<ogra_> elopio, just ignore the Makefile stuff then and use https://github.com/elopio/snapcraft-de-noche/pull/21/files ... that will definitely test the right thing
<mup> PR elopio/snapcraft-de-noche#21: Add the kernels <Created by elopio> <https://github.com/elopio/snapcraft-de-noche/pull/21>
<ogra_> testing the Makefile side should simply be done by installing the latest official snap from edge ...
<ogra_> (or beta ... or wherever brad lands this by default)
<elopio> right, and that shouldn't be part of snapcraft's release process, that sounds good to me.
<ogra_> yeah
<ogra_> i'm not sure how well or how often the snapcraft.yaml based builds get tested at all though ... i knwo paolo recently tested dragoboard due to a mailing luist discussion ... but since we dont use these kernels by default i wouldnt count on regular testing
<ogra_> so your results might vary
<ogra_> (i.e. the kernel plugin might DTRT but the resulting kernel might not boot etc)
<mcphail> kyrofa: cool! Was wondering if there was something built into snpad which can send notifications on updates? Would be a nice feature to have
<kyrofa> mcphail, not that I know of anyway
<kyrofa> mcphail, probably a better question for niemeyer
<mcphail> kyrofa: ta. I'll maybe file a bug/feature request
<pmcgowan> ogra_, its still not working right for me, date reports the correct time and zone, but timedatectl does not
<ogra_> ogra@dragonboard:~$ date
<ogra_> Sat Feb 18 13:09:41 UTC 2017
<ogra_> ogra@dragonboard:~$ sudo timedatectl set-timezone Europe/Berlin
<ogra_> ogra@dragonboard:~$ timedatectl
<ogra_>       Local time: Sat 2017-02-18 14:10:08 CET
<ogra_>   Universal time: Sat 2017-02-18 13:10:08 UTC
<ogra_>         RTC time: Fri 1970-01-09 07:49:18
<ogra_>        Time zone: Europe/Berlin (CET, +0100)
<ogra_>  Network time on: no
<ogra_> NTP synchronized: no
<ogra_>  RTC in local TZ: no
<ogra_> ogra@dragonboard:~$ date
<ogra_> Sat Feb 18 14:10:12 CET 2017
<ogra_> pmcgowan, works fine here
<pmcgowan> ogra_, wait 5 mins
<pmcgowan> or watch journalctl for when the daemon runs
<pmcgowan> actually 2 mins should do
<ogra_> pmcgowan, well, iu see the log warning, but thats just a warning ...
<pmcgowan> ogra_, run timedatectl now
<pmcgowan> to see whats set
<ogra_> oh, you are right
<ogra_> funny
<pmcgowan> the problem I started with is snapweb calls that over dbus
<pmcgowan> well its becuase of the logic I mentioed int he bug
<pmcgowan> the daemon resolves the link and gets the wrong file
<ogra_> why doers snapweb not use date
<pmcgowan> it displays the tz
<ogra_> there is no guarasntee we will even keep timedatectl around
<ogra_> so does date
<pmcgowan> date must get it from somewhere else
<pmcgowan> we can change snapweb, now that we understand
<ogra_> it just asks libc
<ogra_> yeah, we migth decide to drop timedatectl and ship ntp or whatnot ... dont rely on any tools being here
<pmcgowan> hmm ok
<pmcgowan> let me repurpose the bug
<ogra_> shell and libc (and recently a basic python interpreter) is the only stuff we guarantee
<ogra_> everything else can always change
<pmcgowan> understood
<pmcgowan> ogra_, oh we also set time with that api
<pmcgowan> will open a new bug
<pmcgowan> the old one I guess can be marked fixed
<mup> Bug #1650688 changed: timedatectl set-timezone fails on UC16 <Snappy:Fix Released by ogra> <https://launchpad.net/bugs/1650688>
<bdmurray> If I have a simple daemon in a snap that sets some files in /proc, how I would unset those on removal?
<bdmurray> stop-command doesn't seem right since its not a long running service
<sergiusens> coreycb: from what I am seeing, the latest versions of pip and setuptools ignore entry_points in setup.cfg
<sergiusens> we use 9 in our plugin, xenial in the distro has 8.1 and zesty has 9
<coreycb> sergiusens, that's not very nice of them
<sergiusens> coreycb: python distribution is a mess
<sergiusens> coreycb: but I already ranted about this
<coreycb> sergiusens, is that a bug upstream then with pip or setuptools?
<sergiusens> still need to look into it a bit, but I might workaround the problem with a flag you can probably use
<sergiusens> coreycb: haven't pin pointed it yet; elopio asked barry for some guidance
<coreycb> sergiusens, ok cool
<sergiusens> an attribute I mean, to seup the version of pip you need
<coreycb> sergiusens, thanks
<coreycb> sergiusens, that'd be a nice work around
<mup> PR snapd#3064 opened: packaging: rename the file shipping snap-confine AA profile <Created by zyga> <https://github.com/snapcore/snapd/pull/3064>
<zyga> jdstrand: hello
<zyga> jdstrand: can you please review 3064
<zyga> jdstrand: if possible we'd like to use that as the fix for all the issues (including those that block the kernel)
<zyga> jdstrand: I just made it, didn't run any tests yet
<zyga> jdstrand: thank!
<zyga> thanks!
<jdstrand> np
<zyga> jdstrand: I'm considering _not_ removing the old conffile in this release
<zyga> jdstrand: so that we can just relase it with minial risk
<zyga> jdstrand: and unblock the kernel and snapd
<zyga> jdstrand: and if this works we can remove it in 2.24
<zyga> (the stale conffile)
<jdstrand> zyga: there isn't really any more risk with removing it, and I'm pretty sure the sru team is going to require it (you don't ship the old one any more after all)
<jdstrand> zyga: perhaps discuss it with them before you prepare an upload
<zyga> jdstrand: are you sure? I don't have a way to test this (to see if this explodes dpkg)
<jdstrand> ?
<zyga> yes, that's very smart
<zyga> gosh I hate dpkg
<zyga> conf-file handling is just so annoying and hard to get right
<zyga> jdstrand: is this sufficient?
<zyga> http://paste.ubuntu.com/24216924/
<Pharaoh_Atem> zyga: :P
<zyga> Pharaoh_Atem: hey
<Pharaoh_Atem> dpkg is kind of braindead with conffiles :)
<Pharaoh_Atem> zyga: you know what I'm going to bug you about :)
<zyga> Pharaoh_Atem: yes, I know
<zyga> Pharaoh_Atem: I have some good news
<zyga> Pharaoh_Atem: looks like I finally managed to reserve some time for !ubuntu work
<Pharaoh_Atem> thank god
<zyga> Pharaoh_Atem: details when I can release that :)
<zyga> Pharaoh_Atem: but not tonight
<Pharaoh_Atem> people are getting bitchy at me about it :(
<zyga> I really undestand, I'm sorry about it
<zyga> Pharaoh_Atem: I really wish we had less fires and less other things
<Pharaoh_Atem> just get a fireman :)
<zyga> well, don't look, here I come
<Pharaoh_Atem> zyga: you can't be the only fireman...?
<jdstrand> zyga: I've not done this for a while, but it should be, yes. you can perform an upgrade to 2.23.4 or higher and verify the removal. you should also run lintian on the deb
<zyga> jdstrand: sounds like a plan, thank you
<zyga> Pharaoh_Atem: the main fireman is on sick leave so I'm taking the honors
<Pharaoh_Atem> ah
 * davmor2 pictures zyga like this now https://en.wikipedia.org/wiki/Fireman_(steam_engine)#/media/File:Baureihe52Heizer.jpg what do you mean wrong fireman
<zyga> davidcalle: wow, that guy is dressed better than me for the 99.9% of my life ;)
<zyga> gee
<zyga> I should have become a train driver
<davmor2> zyga: wrong da<tab> ;)
<zyga> ah, always
<zyga> is there a way to tell irssi to do longest comon prefix and then stop?
<zyga> like in vim
<zyga> set wim=longest,list
<davmor2> zyga: I think there is a way to set last replied or something like that can't remember how though
<zyga> nah, I don't want last replied
<zyga> I want consistency among differenet programs :/
<davmor2> zyga: no idea then
<zyga> jdstrand: I see /etc/apparmor.d/usr.lib.snapd.snap-confine.dpkg-old
<zyga> ah but that file is ancient
<zyga> ok, all good otherwise
<zyga> I'm going to upload to the PPA now
<mup> Bug #1674468 opened: More than 36% overhead running tests for dbus interface in snap <Snappy:New> <https://launchpad.net/bugs/1674468>
<mwhudson> zyga: hi
<mwhudson> zyga: did you see https://bugs.launchpad.net/snappy/+bug/1674193 ?
<mup> Bug #1674193: core snap's configuration hangs on debian <Snappy:New> <https://launchpad.net/bugs/1674193>
<dpb1_> hi guys -- what am I doing wrong?  http://paste.ubuntu.com/24217290/
<kyrofa> dpb1_, what is the output of `snap --version`?
<dpb1_> http://paste.ubuntu.com/24217297/
<dpb1_> kernel update?
<kyrofa> dpb1_, can we also see the output of `snap interfaces`, please?
<dpb1_> error: no interfaces found
<kyrofa> dpb1_, huh, that doesn't sound good. How about `snap list`?
<dpb1_> No snaps are installed yet. Try "snap install hello-world".
<dpb1_> I just cleared out all my snaps trying to get the 'ubuntu-core' snap upgraded to 'core'
<kyrofa> dpb1_, ah, okay. Does the same thing happen if you just try to `snap install core`?
<dpb1_> kyrofa: yes, both with and without sudo
<kyrofa> dpb1_, not sure what's happening there. I'll refer you to zyga
<dpb1_> kyrofa: I'm running apt-get dist-upgrade now just to remove uncertainty.
<dpb1_> will reboot as well
<mup> PR snapd#3065 opened: Allow seeding a snap with classic confinement <Created by cyphermox> <https://github.com/snapcore/snapd/pull/3065>
<NicolinoCuralli> hi all i exchange some words with @pedronis and @mvo about a future feature for autoconnecting snap plug to core slot from gadget: is there some information more specific about the feature, the roadmap and chances to collaborate?
<niemeyer> NicolinoCuralli: We don't have the feature in place yet, but it does make sense for it to exist
<niemeyer> NicolinoCuralli: Gut feeling is that this should live in the model assertion, and be restricted to snaps present in the assertion as well
<niemeyer> NicolinoCuralli: I need to catch up with pedronis to brainstorm on this, but I can see us extending the snap-declaration logic we have today to consider entries specified in the model
<niemeyer> NicolinoCuralli: We have existing language today which is very flexible and defines when exactly to connect certain things automatically
<popey> ogra_: gentle reminder that packageproxy still breaks if your pc reboots and leaves a stale lock around :)
<NicolinoCuralli> So it is a one-shot enabling mechanism: is it possibile to extend during the lifetime of device this trust for other interface or snaps?
<NicolinoCuralli> @niemeyer So it is a one-shot enabling mechanism: is it possibile to extend during the lifetime of device this trust for other interface or snaps?
<nothal> NicolinoCuralli: No such command!
<niemeyer> NicolinoCuralli: It's not one-shot.. declarations can be updated over time
<niemeyer> NicolinoCuralli: Including the model one
<niemeyer> NicolinoCuralli: As a first idea, we should probably restrict these declarations to snaps that are shipped with the model itself
<niemeyer> NicolinoCuralli: Having them in one of the two ends (either as plug or slot)
<niemeyer> We may lift that resitriction, but then we need to think about social consequences more broadly, and it's good to buy time before we take that sort of decision
<niemeyer> NicolinoCuralli: e.g. developers would be pretty unhappy to find out that their snaps are broken because of custom declarations on particular devices
<niemeyer> I need to step out for a moment.. back soon
<zyga> mwhudson: hey
<zyga> mwhudson: I saw that
<mwhudson> zyga: that's a start :)
<mwhudson> zyga: any ideas what's going on, or how to start debugging?
<zyga> mwhudson: with so many things not working lately I don't have any ideas
<zyga> mwhudson: I heard that mvo reproduced it by just installing anything
<NicolinoCuralli> @niemeyer: I understand the danger for other snaps but in a contest where installed snap are from only one developer sounds very useful to have the changes to enabling trust between core and other snap in a more relaxed way
<nothal> NicolinoCuralli: No such command!
<zyga> mwhudson: I'm too tired with the constant fires to help with this tonight
<mwhudson> zyga: eh, that's not very reassuring :/
<mwhudson> zyga: fair enough
<mwhudson> zyga: mvo reproduced it on debian? or on ubuntu?
<NicolinoCuralli> niemeyer : the picture with the autoconnection built by model assertion seems good to me
<zyga> mwhudson: on debian
<mwhudson> ok
<mwhudson> yes, that's my impression too
<zyga> mwhudson: looks like snapctl or something like it explodes and doesn't die
<zyga> (maybe one thread dies)
<mwhudson> zyga: yeah, does it log anywhere?
<zyga> never tried it though
<zyga> nope, not that I know of
<mwhudson> or i can hack it so it does i guess
<mwhudson> i found a bug saying "the output of running hooks is not shown anywhere"
<zyga> mwhudson: it's tricky as snapd consumes the output
<zyga> mwhudson: but I think snapctl just explodes
<zyga> no need for the hook logic
<zyga> (maybe)
<zyga> but also, I should shut this down and go to sleep
<mwhudson> zyga: can i fake up the environment the hook runs in somehow?
<mwhudson> zyga: tell me on the bug report tomorrow, sleep now :-)
<zyga> mwhudson: maybe but I don't know how
<zyga> mwhudson: I mean snapd verifies it
<zyga> mwhudson: maybe some full system thing can look
<zyga> mwhudson: or if you reproduce it just look at what's left of snapctl
<zyga> mwhudson: this is especially odd if debian has no confinement
<mwhudson> hm i wonder if i had confinement enabled
<mwhudson> some of my debian vms do
<zyga> check if it happens on vanilla
<zyga> actually
<zyga> my debian 9 system is ok
<zyga> so perhaps confinement
<zyga> if confinement we never probably expect that to work
<mwhudson> so yeah this vm did have security=apparmor apparmor=1 on kernel command line
<mwhudson> booting without that now
<zyga> mwhudson: it's not worth debugging that case IMHO, it's not even meant to work, snap-confine doesn't work on debian-9 with apparmor
<zyga> mwhudson: and the generated profile probably doesn't work really
<zyga> mwhudson: all in all, good luck :)
<mwhudson> oh ffs why is the vm fscking
<mwhudson> zyga: thanks :)
<mwhudson> er i have a godd running and i can't kill it with SIGKILL
<mwhudson> maybe i should just give up on computers for today
<zyga> haha, nice
<kyrofa> mwhudson, haha, I hate days like that
<zyga> mwhudson: probably it's apparmor preventing the signal to arrive
<zyga> s/probably/maybe/
<mwhudson> Mar 21 10:24:21 aeglos kernel: [ 1310.730799] Buffer I/O error on dev sdd, logical block 139859, lost async page write
<mup> PR snapcraft#1201 opened: demos: make ROS demos support exiting after success <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1201>
<mwhudson> unplugging the card reader made godd die
<mwhudson> maybe i just hate sd cards
<mwhudson> yeah different sd card worked fine
<mwhudson> and now libvirt has stopped working?
<mwhudson> definitely a computers day
<dpb1_> kyrofa: what appears to be failing on that sudo snap install core:  http://paste.ubuntu.com/24217781/
<dpb1_> I'm not sure what those are signaling to me
<kyrofa> dpb1_, indeed. Me neither
<kyrofa> dpb1_, would you mind logging a bug?
<kyrofa> (against snapd)
<dpb1_> doing
<pachulo> I'm having a problem with the keepassXC snap (but I think that it's not related to the application): I installed the snap with --classic confinment, but even then I can't access NFS mounted directories from the app, does anybody know why?
<dpb1_> kyrofa: thx: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1674484
<mup> Bug #1674484: snap install core failure: permission denied (apparmor) <amd64> <apport-bug> <third-party-packages> <xenial> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1674484>
<mup> Bug #1674505 opened: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build <Snappy:New> <https://launchpad.net/bugs/1674505>
#snappy 2017-03-21
<mup> Bug #1674509 opened: unable to find bluetooth device on rp3 ubuntu core <Snappy:New> <https://launchpad.net/bugs/1674509>
<mwhudson> haha console-conf shouldn't let you use a wifi password < 8 characters long
<mup> PR snapcraft#1202 opened: python plugin: support pbr/setup.cfg projects <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1202>
<Rumple> Snap core has an old version of libstdc++, supporting only up to GLIBCXX_3.4.21 where as Ubuntu 16.10 provides GLIBCXX_3.4.22
<zyga> o/
<NicolinoCuralli> niemeyer:what is the flow that it permit interface autoconnection by gadget plus model assertion? what about update flow for model assertion?
<mup> Bug #1674634 opened: After initial 'refresh', snapd doesn't work <Snappy:New> <https://launchpad.net/bugs/1674634>
<mup> PR snapd#3054 closed: many: rename "snap-confine" to "snap-wrap" to workaround LP:1673247 <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3054>
<niemeyer> Nicolino_: The model assertion must be updated together with the other assertions.. I don't think we're doing that today, but it's easy to fix
<niemeyer> Nicolino_: Looking through the code for flows with the snap-declaration should give a good picture
<niemeyer> This is also the assertion that allows auto connections in general
<mup> PR snapd#3066 opened: asserts: remove some unused things <Created by emgee> <https://github.com/snapcore/snapd/pull/3066>
<mup> PR snapcraft#1201 closed: demos: make ROS demos support exiting after success <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1201>
<mup> PR snapcraft#1203 opened: Add some initial checks to intelligently build the initial snapcraft.yaml <Created by mhall119> <https://github.com/snapcore/snapcraft/pull/1203>
<mup> PR snapd#3067 opened: tests: move docker test to new nightly suite <Created by zyga> <https://github.com/snapcore/snapd/pull/3067>
<mup> PR snapd#3066 closed: asserts: remove some unused things <Created by emgee> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3066>
<mup> PR snapd#3068 opened: boot: log error in KernelOrOsRebootRequired <Created by zyga> <https://github.com/snapcore/snapd/pull/3068>
<lool> kyrofa: hey! around?
<lool> kyrofa: sent you an email with details
<liuxg> For qt project, does anyone know how to set CONFIG in snapcraft.yaml? I do not want to change the original .pro file in the upstream. thanks
<kyrofa> liuxg, just use the `options` param in the qmake plugin
<kyrofa> lool, I'm around now, I'll take a look at the email :)
<liuxg> kyrofa, thanks. I am now trying ...
<mup> PR snapcraft#1161 closed: channels: Add track support to commands <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1161>
<mup> PR snapcraft#1197 closed: tests: increase the timeout in the shared ros test <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1197>
<jdstrand> roadmr: hey, sorry, can you pull r850 at your convenience (not critical)
<roadmr> jdstrand: sure!
<roadmr> jdstrand: the pipeline is a bit clogged right now, may be a couple of days until I get this deployed, but do let me know if I should try to push it a bit
<jdstrand> roadmr: that is totally fine, thanks
<zyga> Pharaoh_Atem: hey
<zyga> Pharaoh_Atem: morphis here will be looking after distributions, he's not going to be stolen for more upstream work like I was
<Pharaoh_Atem> morphis?
<zyga> Pharaoh_Atem: yes
<zyga> Pharaoh_Atem: I'll show him the tooling tomorrow
<zyga> Pharaoh_Atem: and we'll get started with the missing dependencies
<zyga> Pharaoh_Atem: I just wanted to introuduce you guys
<morphis> Pharaoh_Atem: hey :-)
<Pharaoh_Atem> hello?
<kyrofa> Ah, Pharaoh_Atem you're in good hands
<kyrofa> morphis, nice to have you on board
<Pharaoh_Atem> am I?
<morphis> Pharaoh_Atem: I think we were sitting at the same table back in november talking about airlines other stuff in the late evening :-)
<mup> Bug #1668891 changed: Can install non classic snap with --classic, but classic flag isn't set <amd64> <apport-bug> <xenial> <snapd:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1668891>
<morphis> kyrofa: thanks!
<zyga> Pharaoh_Atem: btw, about those packages, no reply from gofed upstream, I think we should just hand-roll packages from copy-pasted gopkg.in examples in other places
<zyga> Pharaoh_Atem: replace names, hashes and stuff
<Pharaoh_Atem> go for it
<zyga> Pharaoh_Atem: we'll also do a build in COPR that has vendorized dependencies as a sanity check (if that thing works and main package doesn't it's the deps)
<zyga> Pharaoh_Atem: and we'll see what it would take to pass the unit tests on fedora
<Pharaoh_Atem> well, it currently doesn't build with vendorized stuff
<zyga> Pharaoh_Atem: then some look at CI (but not all tomorrow ;)
<Pharaoh_Atem> it fails to link
<zyga> Pharaoh_Atem: right
<zyga> Pharaoh_Atem: but the COPR package could, just to see where we are
<zyga> Pharaoh_Atem: so sorry for the extremely long wait (and endless fires) but hopefully with the extra pair of hands we'll get it to work :-)
<Pharaoh_Atem> maybe
<morphis> Pharaoh_Atem, zyga: I am sure we will
<morphis> need some time to get started with this but we should get good results along the way :-)
<mup> PR snapcraft#1204 opened: target-arch: decouple target arch from deb, and use a separate field â¦ <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1204>
<Pharaoh_Atem> morphis: we're going to need to get you up to speed in Fedora-land
<morphis> Pharaoh_Atem: yeah, just registered my account and waiting for approval now
<morphis> Pharaoh_Atem: zyga will give me some more in depth introduction tomorrow and then we will get this going
<morphis> then I should have a better overview of what we need to do and how we can get this forward
<NicolinoCuralli> hi all is it possible set the log level for snapd?
<ogra_> NicolinoCuralli, theer is a way to enable debug messages ... but i forgot the exact runes
<ogra_> Chipaca, might know
<Chipaca> i know nuthin'
<Chipaca> NicolinoCuralliâ yes
<ogra_> hah, lies!
<NicolinoCuralli> :D
<Chipaca> NicolinoCuralliâ not particularly granular, except for http requests
<Chipaca> NicolinoCuralliâ what are you needing?
<Chipaca> NicolinoCuralliâ journalctl already has DEBUG logs in it; you can add HTTP debug logs via the SNAPD_DEBUG_HTTP environ
<Chipaca> it's a bitmask, because we're lazy like that. Set it to 7 for it to log everything except for the actual snap download content
<NicolinoCuralli> perhaps i don't need to set the log level but understand if log of snapd are persistent and how much i/o can generate for a daemon that make network scan each 30 seconds
<NicolinoCuralli> if the daemon run in devmode
<Chipaca> ah. ogra_ back to you :-D
<ogra_> if anything runs in devmode, every execution will spill a lÃ¶ot of "ALLOWED" apparmor messages
<ogra_> and there is no way to avoid that since the assumption is that devmode is only used during development and debugging
 * jdstrand notes that if you connect your interfaces in devmode, you can get rid of a lot of ALLOWED messages
<NicolinoCuralli> ogra_: yes i see it :D
<ogra_> thats crazy talk ... who would connect interfaces in devmode :P
<mup> PR snapd#2877 closed: interfaces: add chroot to base templates <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2877>
<ogra_> (wow, i didnt knwo you could do that)
<jdstrand> devmode logs violations against policy so if you don't connect your interfaces, there are a lot of policy violations :)
<jdstrand> you might be thinking of classic confinement-- you may not plugs/slots with classic confinement, but devmode you are meant to
<jdstrand> the idea is you have an access or two or 10 that are not in snapd yet, but you connect them and only those violations are ignored
<jdstrand> as opposed to everything not in the default policy
<renat> Hi =) It's Renat from Screenly=)
<renat> I have a new question for you=)
<ogra_> and you always have the most interesting ones !
<ogra_> :)
<renat> https://paste.ubuntu.com/24222873/
<renat> We' re trying to install our custom gadget snap from the store.
<ogra_> renat, that is during ubuntu-image ?
<renat> No. Image is created successfully
<ogra_> (you cant install a custom gadget on an installed image afaik)
<renat> It's during the first boot.
<ogra_> ah
<NicolinoCuralli> jdstrand: can you repeat your explanation?
<mup> PR snapd#3069 opened: snapstate:Â restart as needed if we undid unlinking aka relinked core or kernel snap <Created by pedronis> <https://github.com/snapcore/snapd/pull/3069>
<renat> So, there is one more thing - snapd tries to mount it (as I can see from logs) and starts to use all the CPU
<renat> Official pi3 gadget snap works fine.
<ogra_> renat, did you use your own model assertion as well ?
<ogra_> afaik the signature needs to match
<renat> Yes.
<renat> When we provide our gadget snap to the ubuntu-image using the --extra-snaps option - everything works fine.
<ogra_> and it doesnt if you get the same snap from the store
<ogra_> ?
<renat> Yes.
<renat> As far as I can understand - if I install the snap using the extra-snaps cmd option - it doesn't try to mount the gadget snap.
<ogra_> now thats weird
<ogra_> theoretically the process should be exactly the same in both cases
<ogra_> just one more download step
<elopio> coreycb: can you give me the links to your snaps? We'll put them in the nightly test suite to make sure that snapcraft master can always build the snap.
<renat> Could you, please, see the logs I posted above? Maybe it would be good to show an error message to make debugging easier?
<coreycb> elopio, that'd be great, would links to the github repos work?
<elopio> coreycb: yes, please.
<coreycb> elopio, this is what we have so far: http://paste.ubuntu.com/24222988/
<elopio> coreycb: thanks!
<coreycb> elopio, thank you!
<ogra_> renat, can you file a bug ?
<ogra_> renat, i'll gather some poeople to look at it tomorrow
<niemeyer> renat: Yeah, sorry for the trouble there.. today was a bit busy due to issues with the stable release, but fire is all under control now.. we'll dig into your issue tomorrow
<renat> orga_, okay, I will do, thanks!
<renat> niemeyer, thanks!
<renat> ogra_, sorry.
<ogra_> no worries :)
<mup> PR snapcraft#1199 closed: cleanbuild: packaging independent detection <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1199>
<om26er> I see this error: - Download snap "core" (35) from channel "stable" (Please buy core before installing it.) -- Note: I have snapd pointing to staging.
<ogra_> i can give you my account data to transfer your money to ...
<ogra_> (though 35 is a rather old revision ... not sure i'd pay for that ... we're in the 1500s nowadays)
<om26er> ogra_: http://paste.ubuntu.com/24223144/
<om26er> ogra_: could it be that the 'core' in staging is different than production.
<mup> Bug #1674778 opened: snapd hangs with 100% CPU usage when image has a custom gadget snap <gadget> <snapd> <Snappy:New> <https://launchpad.net/bugs/1674778>
<renat> ogra_, again me=) I have another question. I want to supply a custom journald.conf in my gadget snap. But just adding it to the gadget snap (in the etc/systemd/ directory) doesn't help. Is there a preferred way to change journald.conf in Ubuntu-core?
<ogra_> om26er, could be, i never used staging and dont know how it ends up there
<ogra_> renat, i fear that would have to happen through an option in the core config hook ...
<ogra_> renat, i just have disabling syslog in the works, nothing for journald yet though
<cachio> ogra_, hey, any idea about this problem? My machine with yakkety is not detecting the sdcard when I flashed that with a ubuntu core image, but if I insert any other sdcard, it detects the card
<renat> ogra_, what I need is changing journald storage from auto to volatile
<ogra_> cachio, what image did you flash ?
<cachio> ogra_, the dragonboard one
<renat> ogra_, okay, thanks for the answer, have a good day=)
<cachio> ogra_, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-dragonboard-410c.img.xz
<ogra_> cachio, there is only one partition your PC could see ... system-boot
<ogra_> the writable partition is invalid until the first boot of the SD on a board happened (then it will be properly resized to the whole of the SD)
<ogra_> so you could really only see the vfat called system-boot when plugging it in to a PC if you never booted from that SD
<ogra_> renat, file a bug about that as well please, else i forget :)
<cachio> ogra_, I laready boot this SD card in the board, and it is working properly
<ogra_> cachio, well, then your PC should mount system-boot and writable ...
<cachio> ogra_, it is not mounting nothing
<ogra_> it surely does here on my xenial machines
<ogra_> anything in dmesg right after you plug it ?
<cachio> ogra_, let me check again, I was trying to find something useful
<cachio> [  380.505317] mmc0: error -110 whilst initialising SD card
<cachio> [  382.879924] mmc0: card never left busy state
<cachio> ogra_, this is the only interesting thing I saw
<ogra_> that sounds more like a controller issue on your laptop to be honest
<cachio> ogra_, it is happening with 2 sd cards
<ogra_> i'd blame the yakkety kernel/mmc driver there
<ogra_> is that any special type of SD ?
<ogra_> sdxc or plain sd or sdhc
<cachio> ogra_, sdhc
<ogra_> compared to the cards that are recognized
<cachio> ogra_, all of them are the same type
<ogra_> weird
<ogra_> well, there is nothing special about the GPT partition table used on the dragonboard SD cards
<ogra_> your PC should just read it and mount the partitions ... as i said, this works for me
<ogra_> but i use an USB card reader
<cachio> ogra_, perhaps the last update has wroken something in my yakkety
<ogra_> i dont have any builtin MMC slot here
<ogra_> and with that it usually works for all my SD cards
<cachio> ogra_, it was working for me too, but from yesterday I could not make it work it again
<ogra_> well, i'd blame yakkety then :)
<cachio> ogra_, :), thanks
<ogra_> if the SD worked and you didnt re-flash or anything ... we dont change anything on a booted SD regarding partitions r formatting after you did your first boot
<mup> Bug #1674794 opened: journald.conf storage=volatile config support <Snappy:New> <https://launchpad.net/bugs/1674794>
<ryebot> When I try to build a classic snap without snapd installed, I get this message: "classic confinement requires the core snap to be installed. Install it by running `snap install core`."
<ryebot> Non-classic snaps build just fine.
<ryebot> Is there a way around that?
<kyrofa> ryebot, yeah, set the SNAPCRAFT_SETUP_CORE environment variable to 1
<ryebot> magic!
<kyrofa> ryebot, instead of assuming you have the core snap, it'll download it itself and unpack it locally
<ryebot> thanks :D
<ryebot> does that require snapd to be running?
<kyrofa> ryebot, nope
<ryebot> excellent, thanks
<kyrofa> ryebot, it just unsquashes the snap itself, no mounting/running or anything
<ryebot> kyrofa: perfect, thanks
<kyrofa> ryebot, any time!
<mup> PR snapcraft#1205 opened: asset-tracking: track source VCS details <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1205>
<mup> PR snapcraft#1188 closed: store: set User-Agent header in store requests <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1188>
<ryebot> kyrofa: that doesn't seem to work if I use --target-arch=<not-my-arch>
<ryebot> kyrofa: any workaround there?
<kyrofa> ryebot, hmm, is it pulling the core snap for the wrong arch?
<ryebot> hmm I'm not sure
<ryebot> says:
<ryebot> Setting target machine to 'arm64'
<kyrofa> ryebot, what doesn't work?
<ryebot> Preparing to pull kubectl
<ryebot> classic confinement requires the core snap to be installed. Install it by running `snap install core`.
<kyrofa> Oh interesting
<kyrofa> And you have that env var still set?
<ryebot> yeah
<ryebot> SNAPCRAFT_SETUP_CORE=1 snapcraft --target-arch=arm64
<kyrofa> ryebot, I will say that support for --target-arch is a little shaky. It's typically only used for kernels
<kyrofa> ryebot, but please do log a bug so we can discuss and investigate
<ryebot> alright
<ryebot> thanks kyrofa!
<ryebot> kyrofa: https://bugs.launchpad.net/snapcraft/+bug/1674828
<mup> Bug #1674828: SNAPCRAFT_SETUP_CORE=1 doesn't work for foreign architectures <Snapcraft:New> <https://launchpad.net/bugs/1674828>
<ryebot> let me know if you need more details
<kyrofa> Thanks ryebot
<ryebot> thank you!
<Saviq> anyone with an idea why I can't install a snap on a xenial box? http://pastebin.ubuntu.com/24224369/
<kyrofa> Saviq, you're sure the kernel you're on supports apparmor?
<Saviq> 4.4.0-65-generic, I'd have hoped...
<Saviq> standard xenial kernel
<kyrofa> Saviq, that's nasty. Can you pastebin /var/lib/snapd/apparmor/profiles/snap.core.hook.configure?
<Saviq> kyrofa, http://paste.ubuntu.com/24224381/
<kyrofa> Saviq, huh, I was expecting it to be corrupted or something with that error, but that looks fine
<Saviq> kyrofa, any idea where the abstractions/openssl file should come from?
<kyrofa> jdstrand, are you around? Not sure what that error entails ^^
<jdstrand> /etc/apparmor.d
<jdstrand> I just downloaded the paste and it parses fine
<jdstrand> what is possibly happening is that the /var/lib/snapd/apparmor/profiles/snap.core.hook.configure was pasted failed to parse, then snapd reverted
<kyrofa> Ah
<jdstrand> note that ondra and I couldn't update to r1441 with snap refresh. it would spin over and over again phase 2 security profile generation (or something)
<Saviq> jdstrand, FWIW there is no /etc/apparmor.d/abstractions/openssl ...
<Saviq> I suppose my apparmor installation got broken, /me reinstalls
<jdstrand> Saviq: oh, that is not good
<Saviq> jdstrand, I had some filesystem issues on this box, that's probably what happened
<jdstrand> yes, that file is presumed to exist
<jdstrand> $ dpkg -S /etc/apparmor.d/abstractions/openssl
<jdstrand> apparmor: /etc/apparmor.d/abstractions/openssl
<Saviq> I wonder what can I do to recover those, --reinstall doesn't do
<Saviq> ok a bit of purge and install got them back
<Saviq> back in business
<sergiusens> ryebot: kyrofa --target-arch and classic will not work at all
<kyrofa> sergiusens, since we would need to run the other arch's linker?
<kyrofa> sergiusens, a decent error message will probably solve that bug, then
<sergiusens> kyrofa: yeah
<ryebot> sergiusens: what if the build target is a static binary, like some golang artifact?
<ryebot> sergiusens: maybe a better question is, what is getting linked with what?
<mup> Bug #1674847 opened: produce package lists for Ubuntu Core versions on the web <Snappy:New> <https://launchpad.net/bugs/1674847>
<mup> Bug #1674505 changed: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build <Snappy:Invalid> <https://launchpad.net/bugs/1674505>
#snappy 2017-03-22
<mup> PR snapcraft#1198 closed: tests: add manual tests for the kernel snaps <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1198>
<mup> PR snapcraft#1200 closed: tests: allow to run individual autopkgtest suites <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1200>
<mup> Bug #1629423 changed: Ordering of command line arguments matters <eco-team> <Snappy:Expired> <https://launchpad.net/bugs/1629423>
<mup> PR snapcraft#1206 opened: Arm64 witness <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1206>
<shuduo> zyga: hi, i upgrade snapd  to 2.23.1 on opensuse. now i'm installing hello-world and it stuck at "Run configure hook of core snap if present". anything I miss?
<zyga> shuduo: hi
<zyga> shuduo: hey, known issue in the core snap, I think it was resolved last night but let me check
<zyga> shuduo: thank you for reporting this
<shuduo> zyga: welcome. just want everything perfect when i show off it to customer in future. :)
<shuduo> zyga: one more question, i follow your blog https://new.zygoon.pl/post/case-study-snapd-on-centos/ to build snapd on centos 7. and i got error "cannot find -lcap" when making in cmd directory. but actually libcap-devel 2.22 is installed by default. i'm curious how you make it. thanks.
<zyga> shuduo: when I wrote the blog the build system had different requirements, there's a PR waiting now that once landed will make it build easily anywhere
<zyga> shuduo: the problem is that we need static libcap in certain case
<zyga> shuduo: I have a PR ...
<zyga> one sec
<zyga> this one: https://github.com/snapcore/snapd/pull/3039
<mup> PR snapd#3039: many: add support for partially static builds <Created by zyga> <https://github.com/snapcore/snapd/pull/3039>
<zyga> if you merge that in you should just get a clean build
<shuduo> zyga: got it. let me try it. thanks!
<zyga> shuduo: one more question, what does snap list say for you on suse?
<zyga> shuduo: I'm refreshing core on my 42.2 leap system now
<shuduo> zyga: only core 16-2 1441
<zyga> I had 1512 but we reverted that to 14xx last night
<zyga> shuduo: ok, reproduced
<zyga> man....
<zyga> those issues :-(
<shuduo> zyga: i'm using tumbleweed.
<zyga> right, I think this bug is in snapd
<zyga> I'll get right to it and investigate
<zyga> I'll release an update that puts a timeout on the configure hook at least so that people are not stuck forever
<shuduo> zyga: good to know. :)
<zyga> or even disable the configure hook on classic, it's not useful anyway yet
<zyga> shuduo: did you report this anywhere?
<shuduo> zyga: not yet. if you want I am happy to do that.
<zyga> shuduo: I think there is a report of this on debian
<zyga> let me find it
<zyga> shuduo: https://bugs.launchpad.net/snappy/+bug/1674193
<mup> Bug #1674193: core snap's configuration hangs on debian <Snappy:New> <https://launchpad.net/bugs/1674193>
<zyga> can you please add to this bug that it also happens on tumbleweed and leap 42.2
<zyga> add snap --version to the bug report too
<shuduo> zyga: okay
<mup> PR snapd#3070 opened: overlord: maintain per-revision snapshots of snap configuration <Created by stolowski> <https://github.com/snapcore/snapd/pull/3070>
<mup> PR snapd#3061 closed: interfaces: rename thumbnailer to thumbnailer-service <Created by michihenning> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3061>
<mup> PR snapd#3011 closed: tests: remove core_name variable <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3011>
<davmor2> hey guys question. Is there a way I can tell snapcraft to get the build parts it needs from a deb file so I can then pull from github?  Kinda like apt build-deps
<ogra_> davmor2, you mean the build-packages option in snapcraft.yaml ?
<davmor2> ogra_: could be I was just asking if there was one
<ogra_> indeed there is :)
<davmor2> ogra_: awesome I might try a edge build of pronterface and slic3r
<morphis_> zyga_: so build on fedora is running, as you said, pretty easy to get that up and running :-)
<mup> PR snapd#2987 closed: store: download from authenticated URL if there is a device session set <Created by matiasb> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2987>
<Son_Goku> morphis_ , zyga_
<morphis_> Son_Goku: you have two different nicks? :-)
<Son_Goku> I have three, actually
<Son_Goku> King_InuYasha is the third
<morphis_> ah :-)
<morphis_> good to know, each for a differnt machine?
<Son_Goku> yep
<morphis_> so fedpkg is actually quite nice
<Son_Goku> yes, it's full of win
<morphis_> but looks like we have to combine the packaging for snap-confine and snapd now that boht are build from the same source tree
<Son_Goku> where's this hangout thing so I can pop in
<Son_Goku> yeah, I already started doing that... :/
<morphis_> there isn't one right now
<morphis_> Son_Goku: ah great, how far did you come?
<Son_Goku> snap-confine stuff builds, but snapd doesn't :(
<morphis_> Son_Goku: is that work available somewhere?
<Son_Goku> yep
<Son_Goku> one sec
<zyga> Son_Goku: we finished as morphis_ didn't have his fedora account yet
<morphis_> zyga: I do now
<Son_Goku> morphis_: what's your FAS?
<morphis_> Son_Goku: mrmorph
<Son_Goku> [06:38:30 AM]  <Son_Goku>	.fasinfo mrmorph
<Son_Goku> [06:38:31 AM]  <zodbot>	Son_Goku: User: mrmorph, Name: Simon Fels, email: morphis@gravedo.de, Creation: 2017-03-22, IRC Nick: morphis, Timezone: UTC, Locale: en, GPG key ID: 1412DB3B, Status: active
<Son_Goku> [06:38:34 AM]  <zodbot>	Son_Goku: Approved Groups: cla_done cla_fpca
<Son_Goku> morphis_, so that's you, morphis_ ^
<morphis_> Son_Goku: yes
<Son_Goku> morphis_: so you now need to go through the first-time packager process
<Son_Goku> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
<morphis_> yeah, already working through that
<Son_Goku> and don't forget to also be in #fedora-devel IRC
<Son_Goku> lots of people hang out there and when real-time communications are supposed to happen, people like poking there
<morphis_> thanks for that pointer!
<morphis_> aye
<morphis_> good to know
<lool> jdstrand: hey, https://bugs.launchpad.net/snappy/+bug/1674505 might be of interest to you; one part of it is about apparmor home permissions when running under sudo
<mup> Bug #1674505: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build <Snappy:Invalid> <https://launchpad.net/bugs/1674505>
<morphis> Son_Goku: so you started work on combining the snapd/snap-confine packaging, did you also start work on updating the packaging to a more recent snapd version?
<Son_Goku> yes
<morphis> Son_Goku: is that work somewhere too?
<Son_Goku> yes
<Son_Goku> morphis: https://github.com/Conan-Kudo/snapd/commit/4c71ef5a9e6e89cf8aa2d31eef12be7e2e66d1bd
<morphis> Son_Goku: ah nice!
<morphis> Son_Goku: I guess there is a reason why you had to copy the systemd unit files, right?
<Son_Goku> the original systemd units use /snap and /usr/lib/snapd
<morphis> ah right
<Son_Goku> Fedora uses the saner paths /var/lib/snapd/snap and /usr/libexec/snapd
<morphis> Son_Goku: wondering if we can't change that via unit mixin's
<morphis> Son_Goku: that way we could keep the original files and just change what we need to
<Son_Goku> mixin's?
<zyga> Son_Goku: we can use sed later
<zyga> Son_Goku: or add this to packaging/fedora
<zyga> Son_Goku: for sanity
<morphis> /lib/systemd/systemd/snapd.service.d/fedora.conf
<zyga> Son_Goku: then we can just maintain it in one spot
<morphis> everything in fedora.conf gets applied to the original unit file
<Son_Goku> morphis: ideally, the unit file would actually be a template and debubuntu and fedora packaging would convert them properly
<morphis> possible
<morphis> but using sed in the spec file would be another way
<Son_Goku> yes, using sed would be required in this case, actually
<morphis> Son_Goku: so what is left to do in that branch you shared above?
<Son_Goku> as we'd most likely have service.in files with @libexecdir@ and @snapmountdir@ and those would be sedded in the spec
<Son_Goku> morphis: not much actually, the problem is that build deps can't be satisfied
<Son_Goku> and the vendorized build (for EPEL) doesn't work
<Son_Goku> it fails on the link stage due to choking on hardening flags
<Son_Goku> I've already finished the other adaptations, and one thing you can really do now is start working on the missing golang build deps
<Son_Goku> that's "golang(github.com/ojii/gettext.go)" and "golang(gopkg.in/retry.v1)"
<morphis> those do not exist in fedora at all in the moment?
<Son_Goku> nope
<morphis> ok
<Son_Goku> packaging is mostly automated, through the gofed tool
<Son_Goku> you should be able to generate packaging using it
<morphis> yeah heard that, can't wait to see that in action :-)
<Son_Goku> https://github.com/gofed/gofed
<Son_Goku> on your Fedora system, do "sudo dnf install gofed*" to install all the gofed packages
<Son_Goku> since they broke up the functionality into lots of subpackages :/
<Son_Goku> gofed is quite powerful, as it is also capable of doing something close to API/ABI checking of golang things
<morphis> Son_Goku: nice
<morphis> Son_Goku: ok, on my list
<Son_Goku> let me know when you've made the review requests
<morphis> will do
<mup> PR snapcraft#1207 opened: kernel plugin: stop duplicating initrd and image file, use symlinks fâ¦ <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1207>
<mup> Bug #1674505 opened: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build <Snappy:New> <https://launchpad.net/bugs/1674505>
<mup> PR snapcraft#1202 closed: python plugin: support pbr/setup.cfg projects <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1202>
<mup> Bug #1674505 changed: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build <Snappy:Invalid> <https://launchpad.net/bugs/1674505>
<morphis> Son_Goku: to build the package from the packaging/ directory, I can't use fedpkg, right?
<Son_Goku> no, you can't
<Son_Goku> you need to set up the tree correctly for it
<morphis> rpmbuild then?
<Son_Goku> yes
<Son_Goku> set the tree up correctly, then rpmbuild -bs <spec>
<Son_Goku> then mock </path/to/package.src.rpm>
<Son_Goku> that way you don't need all builddeps installed on your system
<morphis> sounds good, the source package snapd-2.23.1.tar.gz is what I need to provide, right? it doesn't generate it from the source tree
<Son_Goku> well, since snapd-2.23.1 actually has all the things
<Son_Goku> you can use spectool to download the sources :)
<morphis> ah
<Son_Goku> spectool -C ~/rpmbuild/SOURCES -g snapd.spec
<morphis> that was the point I was missing
<Son_Goku> you'll want to apply the patch adding fedora packaging stuff as a patch in the spec
<Son_Goku> that way, things like the systemd unit are available in the right place
<mup> PR snapcraft#1206 closed: Arm64 witness <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1206>
<jdstrand> pedronis: hey, am I crazy or is there an auto-connect bug: http://paste.ubuntu.com/24228316/
<pedronis> jdstrand: maybe
<jdstrand> pedronis: so, I tried quite a few things. I tried in the wpa slot side 'allow-auto-connection: true' and on the nm side 'allow-auto-connection: true', and various alternations. I didn't try to change the wpa connection contraint alternation though
<pedronis> jdstrand: that's not relevant if there is something in the plug
<jdstrand> well, unless there is a bug of course
<pedronis> plug should be the only interesting one
<pedronis> well, that logic is quite clear cut
<pedronis> there might be a bug
<pedronis> but it might not be about assertions
<pedronis> fwiw
<jdstrand> but yes, on the nm plugs I did simple "allow-auto-connection: true" and that didn't work
<jdstrand> pedronis: shall I file a bug then?
<jdstrand> pedronis: I just wanted to ping you here to double check my expectation that the snap decl should allow it
<jdstrand> s/just/mostly/
<pedronis> I think it should but as I said  I suspect either we are missing something obvious or the bug might not be in the assertion level
<pedronis> because we have exercized that for other things quite a bit
<pedronis> and it's rather clear cut
<jdstrand> I'll file a bug then
<jdstrand> pedronis: thanks
<lool> jdstrand: hey, is there an existing bug/spec for tun/tap devices in snaps? the snap I'm looking after calls mknod directly to create a tun device; tun/tap are probably common for VPN/VNF use cases
<jdstrand> lool: tun and tap devices are allowed by the network-control interface. mknod is not allowed anywhere, but there is a pr to allow it to create non-devices. I suspect you are asking for mknod of these devices. the application should instead use ioctl on /dev/net/tun and then the devices will be created without needing mknod. see https://www.kernel.org/doc/Documentation/networking/tuntap.txt
<lool> jdstrand: awesome, that's exactly what I was looking for; do you know if tunctl implements the right ioctl dance?
<jdstrand> lool: I'm not familiar with that tool. let me check
<lool> Hmm I'm kind of suspicious that this is still relevant given it was in uml-utilities
<lool> my god I'm old
<lool> I suspect iproute can do it
<lool> right, ip is the right tool, let's check if it does the ioctl
<lool>         if (ioctl(fd, TUNSETIFF, ifr)) {
<lool> it does!
<jdstrand> lool: ethertap.c unconditionally does a mknod
<jdstrand> ok, good, use that instead :)
<roadmr> jdstrand: hola. Hey I wanted to mention: last week we deployed some tweaks to the upload queue for a snap. The first upload that's "blocking" the queue due to needing manual review is now shown. Also, the snap's developer can now self-reject uploads pending review so they can self-unclog their snap's queue
<lool> jdstrand: I'm kind of ashamed of mentioning user-mode linux on a public channel in 2017
<jdstrand> lool: now, if /dev/net/tun doesn't exist then the tuntap.txt I referenced says to mknod that. if you encoutner this situation, I think snapd should do that for you, and that would be a bug against snapd
<jdstrand> roadmr: I saw! I've taken advantage of both already. thanks!! :)
<lool> ah
<jdstrand> lool: hehe
<roadmr> whee :) glad to hear jdstrand.
<jdstrand> lool: I think udev is going to create /dev/net/tun automatically. I see it on bbb and other places where I'm not using tun/tap devices
<lool> jdstrand: ok; I'll try to get more info; it's closed source, but I can ask to run it unconfined and see what it actually does
<jdstrand> olive: I was on holiday last week. did someone else answer your question? if not, I'm here now
<olive> jdstrand: thank you, stgraber answered me at #lxcontainers ;)
<jdstrand> olive: great :)
<pedronis> jdstrand: reading your bug, remember auto-connection works only if there is only one possibility, not sure it's relevant
<pedronis> jdstrand: and IÂ don't remember if assertions are used or not to prune down options anyway your assertion doesn't have extra info for that
<ogra_> jdstrand, do you happen to know why https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_setup_control.go has no execution rights for "netplan generate" ?
<pedronis> jdstrand: you need some rule that name needs to be same
<ogra_> i assume just copying the file into the dir wont be enough
<mup> PR snapcraft#878 closed: Added a fix for cases where modpbrobe append options to the line, ie.â¦ <Created by croepha> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/878>
<mup> PR snapcraft#1208 opened: kernel plugin: fix modprobe output parsing <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1208>
<pedronis> jdstrand: there should be only one possibility,  and assertions are used for pruning, and also the interface AutoConnect() method but I don't see anything that would pick only one in your example
<jdstrand> pedronis: I did try to use constraint alternations for allow-auto-connection using plug-attributes: { name: ... }
<pedronis> jdstrand: ?
<pedronis> jdstrand: but the plug rule has nothing
<pedronis> nor the interface
<pedronis> it seems like we need a rule either in code or assertions that compare name?
<jdstrand> pedronis: the plug side does have something. it specifies the interface, the name and the bus
<pedronis> jdstrand: in the assertion?
<pedronis> the code afaict doesn't do anything
<pedronis> with name atm
<jdstrand> pedronis: I'm saying I attempted an assertion that did that
<pedronis> IÂ mean dbus interface code
<kyleN> hey ogra_: can you please check out this bug a client filed? I'm not sure what the next step is, but it's critical for them: https://bugs.launchpad.net/snappy/+bug/1674778
<mup> Bug #1674778: snapd hangs with 100% CPU usage when image has a custom gadget snap <gadget> <snapd> <Snappy:New> <https://launchpad.net/bugs/1674778>
<pedronis> that's not what is in the bug though
<jdstrand> pedronis: no it isn't. I did say towards the end that I tried other things
<ogra_> kyleN, niemeyer wanted to look into that one he just said in our team meeting ;)
<pedronis> anyway given there are two slots what is in the bug cannot work for sure Â I think
<jdstrand> pedronis: I can give the example that I tried
<pedronis> the auto connect logic finds two cands and says nope
<ogra_> kyleN, we were actively talking to renat yesterday night and asked him to file that bug
<kyleN> ogra_, ok thanks. just wanted to be sure it was noted
<ogra_> it surely is
<jdstrand> ogra_: cause the person who wrote the interface didn't ask for it :)
<jdstrand> pedronis: ok, let me try something else then
<ogra_> jdstrand, haha ... well unless netplan has a clever inotify implem,entation i suspect the interface is pointless without being able to run "netplan generate" and "netplan apply"
<pedronis> jdstrand: another option would be to change dbus AutoConnect method, usually atm it's always just true because we do things with decls though
<cachio> jdstrand, hey
<cachio> jdstrand, I have build a dbus snap which is adding a dbus slot and plugs the same one
<cachio> I am getting a apparmor DENIED when I try to run in strict mode
<cachio> jdstrand, any idea?
<jdstrand> cachio: is the interface connected?
<jdstrand> cachio: snap interfaces
<cachio> yes
<cachio> jdstrand, I connected the slot and the interface manually
<jdstrand> cachio: can you paste the output of 'snap interfaces'?
<cachio> jdstrand, http://paste.ubuntu.com/24228789/
<jdstrand> cachio: can you paste /snap/kpi-dbus-tests/current/meta/snap.yaml
<cachio> jdstrand, that http://paste.ubuntu.com/24228795/
<cachio> jdstrand, http://paste.ubuntu.com/24228800/
<jdstrand> cachio: oh, that is a noisy denial that has nothing to do with the dbus interface. to get rid of it you can plugs: mount-observe
<jdstrand> that is a libc thing
<cachio> jdstrand, ah, ok
<cachio> jdstrand, I'll try that
<cachio> jdstrand, should I connect against mount-observe?
<cachio> jdstrand, I am getting that denied
<jdstrand> cachio: mount-observe needs a manual connection
<cachio> jdstrand, which slot should I use?
<jdstrand> cachio: you 'plugs: [ mount-observe ]'
<cachio> yes
<jdstrand> sudo snap connect kpi-dbus-tests:mount-observe
<cachio> jdstrand, ok
<jdstrand> (you can use that instead of 'sudo snap connect kpi-dbus-tests:mount-observe :mount-observe' since it is an implicit slot
<cachio> jdstrand, I see that now [ 4068.867293] wcn36xx: ERROR hal_remove_bsskey response failed err=6
<jdstrand> cachio: are there denials in the log?
<cachio> jdstrand, yes, from dmesg
<mup> PR snapcraft#1150 closed: kernel plugin: rework MAKEFLAGS from the environment <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1150>
<jdstrand> can you paste the denials that happen after you connected the mount-observe interface?
<cachio> jdstrand, I don't see any denial, just that error
<cachio> jdstrand, is it related to the snap?
<jdstrand> cachio: it is probably a snap issue then. you should try again after doing this though: sudo sysctl -w kernel.printk_ratelimit=0
<jdstrand> cachio: that will disable kernel rate limiting (sometimes denials are rate limited). you should also look in syslog, not dmesg since dmesg won't show dbus denials
<cachio> jdstrand, ok, I'll try that, tx
<mup> PR core#29 opened: drop sync from hooks/configure, it isnt in the interface <Created by ogra1> <https://github.com/snapcore/core/pull/29>
<mup> Bug #1675054 opened: "snap info" should provide detailed track/channel release information. <Snappy:New> <https://launchpad.net/bugs/1675054>
<zyga> morphis: have a look at https://github.com/gofed/gofed/issues/131
<zyga> Pharaoh_Atem: thanks for reporting that and wow, that's one quick fix :)
<zyga> morphis: this should help you out a lot
<zyga> morphis: you can use that technique to just quickly patch gofed locally and package the last bit
<plars> ogra_: I'm seeing a problem with dragonboard images that seems to have started recently. We generate our own for automated tests with ubuntu-image so that we can apply a user assertion, and pretty soon after booting it, it wants to transition from ubuntu-core to core
<plars> ogra_: so if I try to install a snap in that window, before it reboots after, it says: "ubuntu-core to core transition in progress, no other changes allowed until this is done"
<ogra_> err
<plars> but if we are building the image right then, shouldn't it already have core instead of ubuntu-core? why does it need to upgrade right away?
<ogra_> ubuntu-core is long dead for images
<plars> yeah I thought so
<ogra_> so i wonder what gives it the idea there would be any ubuntu-core to upgrade from
<plars> ogra_: that's not something that came from the model is it?
<ogra_> no, iirc the model doesnt define core, only kernel and gadgetz
<ogra_> do you actually see any ubuntu-core under /snap ??
<mup> PR snapd#3025 closed: cmd/snap-update-ns: compute the actions required to transform mount environment <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3025>
<morphis> zyga: yeah I saw some crashes too but got those two missing deps for snapd now building
<morphis> zyga, Pharaoh_Atem: also it looks like the gofed tool generates invalid spec files as the changelog at the bottom is somehow messed up in my cases
<morphis> but as long as it works and gives me something I can tune I am happy for now
<plars> ogra_: yes
<ogra_> plars, how did that get there ? :)
<plars> ubuntu-core         16-2           1889
<ogra_> plars, do you use an ancient ubuntu-image ?
<plars> ubuntu-image     0.12+real1  37
<ogra_> nothing should install ubuntu-core anymore ... sincwe 6 weeks or even longer
<ogra_> thats pretty old
<plars> oh, it looks like there's a newer version... I guess it didn't refresh because it's devmode
<ogra_> yeah
<plars> ah, ok
<plars> 0.15+snap3 now
<plars> let me try that, hopefully that's all it was :)
<ogra_> right, try again weith that
<zyga> morphis: what is the changelog you are getting?
<plars> thanks!
<ogra_> at least it should use core now and not try to upgrade ... no guarantees for anything else  :)
<plars> heh, ok
<om26er> Hi! Can I know which ppa generally contains snapd release candidate ? also, is there a "edge" aka daily ppa as well ?
<ogra_> om26er, https://launchpad.net/~snappy-dev/+archive/ubuntu/edge?field.series_filter=xenial
<om26er> ogra_: is there one for RC ?
<ogra_> om26er, well, thats usually xenial-proposed ... but sometimes it gets uploaded in parallel to https://launchpad.net/~snappy-dev/+archive/ubuntu/image?field.series_filter=xenial
<om26er> hmm, so I guess -proposed is more reliable than a ppa for release candidates.
<ogra_> yes
<jibel> om26er, release candidates are in -proposed
<jibel> om26er, /image is used before uploading to proposed
<jibel> it's a bit an equivalent of a beta
<om26er> jibel: so shall we track xenial-proposed and for dailies, the edge ppa ?
<jibel> om26er, yes
<morphis> zyga: %changelog* Wed Mar 22 2017 Simon Fels <morphis@gravedo.de> - 0-0.1.gitb6dae1d
<morphis> so both things are in the same line which the tools don't like
<morphis> but its just another bug in gofed
<mup> PR core#29 closed: drop sync from hooks/configure <Created by ogra1> <Merged by niemeyer> <https://github.com/snapcore/core/pull/29>
<om26er> ogra_: can you tell the version scheme for snapd used here includes the time of upload https://launchpad.net/~snappy-dev/+archive/ubuntu/edge?field.series_filter=xenial ?
<om26er> 201703221024 aka YYYYMMDDHHMM ?
<om26er> or if you could point me to the right person.
<ogra_> om26er, i think thats correct ...
<ogra_> the right person would be mvo, but he is off sick this week
<Pharaoh_Atem> morphis: I dunno why it always generates bad changelog sections
<Pharaoh_Atem> it's easy enough to fix thankfully :)
<pedronis> jdstrand: I put a comment in the bug
<plars> ogra_: ok, that didn't seem to help, but I think I  may have it resolved now. I upgraded snapd on the host that built the image, and then it updated to core from ubuntu-core, and now the new images seem to have core in them
<ogra_> cool
<ogra_> i thought ubuntu-image does it ... but indeed, ubuntu-image only acts as frontend for "snap prepare-image"
<zyga> morphis: weird, I never saw that
<morphis> zyga: yeah
<mup> PR snapcraft#1145 closed: tests: expect failures for the tests that can't be run in arm64 <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1145>
<sergiusens> ppisati: ^ because I added this https://github.com/snapcore/snapcraft/pull/1209/commits/e1e0dbb56564bdc532479e1a8066ca89e866ff05
<mup> PR snapcraft#1209: kernel plugin: use default per arch targets <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1209>
<mup> PR snapcraft#1149 closed: kernel plugin: if kernel's target == NULL, use per-arch default target <Created by piso77> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1149>
<mup> PR snapcraft#1209 opened: kernel plugin: use default per arch targets <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1209>
<ppisati> sergiusens: is that good or bad? do i need to do anything?
 * ppisati curls in a corner and cries
 * ogra_ notes it is that time of day ... 
<ogra_> ... and hands ppisati a beer
<sergiusens> ppisati: fixed a typo in your dict and added tests
<ppisati> sergiusens: k
<sergiusens> ppisati: just wanted to know if you were ok with it
<ppisati> sergiusens: +1
 * zyga EODs
<jdstrand> pedronis: thanks-- I'm going to try something else and report back
<mup> PR snapcraft#1210 opened: Add platforms for the nightly tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1210>
<jdstrand> pedronis: thanks for your help-- see https://bugs.launchpad.net/snapd/+bug/1675019/comments/5
<mup> Bug #1675019: wpa-supplicant's dbus interfaces are not auto-connecting to network-manager snap <snapd:Invalid> <https://launchpad.net/bugs/1675019>
<jdstrand> pedronis: snap decls can sure get tricky :)
<pedronis> :)
<Timmay> In latest Ubuntu-Core, how do I load kernel module at boot, seeing that most of the file system is read only? Assume it is in some "writable" folder?
<zyga> jdstrand: FYI https://bugs.launchpad.net/snappy/+bug/1674193/comments/3
<mup> Bug #1674193: core snap's configuration hangs on debian|openSUSE <Snappy:In Progress by morphis> <openSUSE:New for morphis> <https://launchpad.net/bugs/1674193>
<zyga> jdstrand: do we have any fixes in seccomp that may be causing this?
<zyga> jdstrand: (please reply in the bug report)
<zyga> jdstrand: I'm EOD, just wanted to put this on your radar
<roger__> Hi! I've gotten stuck on 'Run configure hook of "core" snap if present', and the only hit I get when searching for it suggests talking to people on IRC about it.
<roger__> (see https://www.mail-archive.com/snapcraft@lists.snapcraft.io/msg02739.html)
<mup> PR snapcraft#1211 opened: asset-tracking: add git source tracking <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1211>
<roadmr> jdstrand: tools r850 now in production! enjoy!
<jdstrand> roadmr: that was fast. thanks!
<roadmr> only if you discount the fact that r849 languished there for days ;)
<jdstrand> heh
<jdstrand> no complaints here
<roadmr> :D
<coreycb> sergiusens, thanks for the fix. :)  seems to work fine although I'm running into a few more issues post-install.  i updated the bug if you could take a look when you get a chance.
<mup> PR snapd#3043 closed: interfaces: use spec in the dbus backend <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3043>
<mup> Bug #1650688 opened: timedatectl set-timezone fails on UC16 <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
<mup> PR snapcraft#1212 opened: store: better retry strategy for GETs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1212>
<mup> PR snapcraft#1208 closed: kernel plugin: fix modprobe output parsing <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1208>
<mup> PR snapcraft#1209 closed: kernel plugin: use default per arch targets <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1209>
<mup> PR snapcraft#1185 closed: repo: add version support for build-packages <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1185>
<mup> PR snapcraft#1213 opened: asset-tracking: add bazaar source tracking <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1213>
#snappy 2017-03-23
<mup> PR snapcraft#1214 opened: asset-tracking: add subversion source tracking <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1214>
<mup> PR snapcraft#1215 opened: asset-tracking: add mercurial source tracking <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1215>
<zyga> Pharaoh_Atem: you may be interested in joining https://plus.google.com/communities/103356268060178755068
<Son_Goku> zyga: I'm in it now
<mup> PR snapd#3071 opened: many: Ignore configure hook failures on core refresh <Created by mvo5> <https://github.com/snapcore/snapd/pull/3071>
<zyga> Son_Goku: great, thanks
<zyga> Son_Goku: I set moderation for 1st post of new members
<zyga> Son_Goku: but after that you should be good
<Son_Goku> well, I don't have anything to say...
<zyga> Son_Goku: aww, I'm sure you will have something to say one day :)
 * Son_Goku shrugs
<mup> PR snapd#3071 closed: many: Ignore configure hook failures on core refresh <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3071>
 * zyga does school run
<mup> PR snapd#3071 opened: many: Ignore configure hook failures on core refresh <Created by mvo5> <https://github.com/snapcore/snapd/pull/3071>
<Son_Goku> morphis, golang deps packaging?
<morphis> Son_Goku: I've started and coming along
<mup> PR snapd#3072 opened: interfaces: use udev spec <Created by stolowski> <https://github.com/snapcore/snapd/pull/3072>
<mup> PR snapcraft#1216 opened: cleanbuild: don't copy cache into container <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1216>
<morphis> Son_Goku: can you have a look at https://github.com/CanonicalLtd/snappy-docs/pull/47 and check the Fedora part of you see something wrong?
<mup> PR CanonicalLtd/snappy-docs#47: Extend snapd installation instructions <Created by morphis> <https://github.com/CanonicalLtd/snappy-docs/pull/47>
<Son_Goku> morphis: yeah, there are no working snappy packages
<morphis> Son_Goku: the 2.16 ones from zyga's repo worked to some degree .. however this is more for the near future where we have working packages again
<Son_Goku> when we have working packages, they'll just be in the Fedora repos
<morphis> Son_Goku: sure, but keeping what is written there doesn't make sense so this just takes it and rewrites it
<Son_Goku> yes
<Son_Goku> I guess
<Son_Goku> by that token, I could have just built and released 2.16 now
<morphis> and if we can provide something in a repo until its in the main distribution we should do that to have something people can test
<morphis> Son_Goku: hm, lets not do that, it has too many unknowns for me right now
<Son_Goku> I held off on releasing 2.16 because zyga said we'd have 2.23 done in a week, several weeks ago :(
<morphis> there were quite some problems recently with getting people upgraded and if we release to main it should use the core instead of ubuntu-core snap from the beginning
<morphis> Son_Goku: yeah 2.23 is there now and I am here to put speed on this :-)
<Son_Goku> yeah, except 2.23 and 2.23.1 don't build
<morphis> we can fix this and I am working on the golang packages
<Son_Goku> well, I'm tired of receiving the errors from the buildsystem about snapd-glib needing snapd and it's unresolvable, so I hope you have the golang packages today for me to review :)
<morphis> Son_Goku: lets see
<Son_Goku> I also am able to sponsor new packagers into the packager group, so we can get it done very quickly
<morphis> Son_Goku: awesome!
<morphis> Son_Goku: can I enter the chroot mock builds somehow?
<Son_Goku> yes
<Son_Goku> mock [-r <name-of-root>] --shell
<morphis> ok
<morphis> Son_Goku: I love this .. the guy named the repo gettext.go and if you call go test github.com/ojii/gettext.go go can't deal with it as it things its a .go file
<Son_Goku> :/
<morphis> you need to put / behind it to make sure its a dir
<zyga> morphis: you may use go test github.com/ojii/gettext.go/....
<zyga> (one less dot)
<pmcgowan> zyga, is snapd checking the content: name in a newer version? does not seem to on 2.23.1
<pmcgowan> also what is the advantage of having a content: value specified
<mup> Bug #1675413 opened: snap disconnect doesn't support tab completion <Snappy:New> <https://launchpad.net/bugs/1675413>
<Son_Goku> morphis: it used to be called gogettext :/
<Son_Goku> then they broke it
<zyga> pmcgowan: I think it does
<zyga> pmcgowan: there was a regression at one revision but it was fixed AFAIR
<pmcgowan> zyga, I have 2.23.1 and it doesnt seem to get checked
<pmcgowan> zyga, but I am wondering, what is it good for?
<pmcgowan> since I cant really rev interface versions using it aiui
<zyga> pmcgowan: it's a "protocol" handshake
<zyga> pmcgowan: you cannot connect if plug and slot don't agree
<pmcgowan> zyga, but I already need to have the names agree, how is this different
<zyga> pmcgowan: the regression was in one place where we didn't return the default one based on interface name
<zyga> pmcgowan: which names?
<pmcgowan> the plug and slot
<zyga> pmcgowan: those are irrelevant
<zyga> pmcgowan: you cna name them any way you want
<pmcgowan> so they dont need to match
<pmcgowan> ok
<zyga> pmcgowan: the content attirbute matters
<pmcgowan> so its just broken in this version
<zyga> I think so
<pmcgowan> ok
<zyga> pmcgowan: but if you define content explictly it should work in any version
<pmcgowan> yeah its not
<pmcgowan> zyga, I just connected foo to bar basically and it worked
<pmcgowan> zyga I also filed a bug about connecting to the wrong snap entirely
<pmcgowan> zyga, unless the checking is not happening with locally installed snaps with dangerous
<zyga> pmcgowan: I think that's possible
<zyga> pmcgowan: this is based on assertions
<zyga> pmcgowan: so without assertions that will happen
<pmcgowan> zyga, ok thanks
<morphis> Son_Goku: hah! INFO: Done(/home/simon/rpmbuild/SRPMS/golang-github-ojii-gettext.go-0-0.1.gitb6dae1d.fc25.src.rpm) Config(default) 0 minutes 36 seconds
<Son_Goku> yay
<morphis> Son_Goku: ok, this is pretty rough, where can I submit for review?
<Son_Goku> process is mentioned in https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_Your_Review_Request
<morphis> ok
<zyga> morphis: note that first review is a bit different
<zyga> morphis: you need a space to put your spec file and srpm
<morphis> yeah
<zyga> morphis: after the first review you get assigned space (though not sure since fedorahosted was shut down)
<Son_Goku> fedorahosted != fedorapeople
<Son_Goku> fedorahosted was like Debian Alioth
<Son_Goku> except using Trac instead of FusionForge
<Son_Goku> fedorapeople is just a space for people to use :)
<mup> PR snapcraft#1216 closed: cleanbuild: don't copy cache into container <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1216>
<zyga> aaah
<zyga> so that's fine
 * zyga wonders why this doesn't work
<zyga> http://paste.ubuntu.com/24235103/
<mup> PR snapcraft#1217 opened: tour: make it work when its a snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1217>
<jdstrand> zyga: fyi https://github.com/snapcore/snapd/pull/2624#issuecomment-288732682
<mup> PR snapd#2624: cmd/snap-confine: re-associate with pid-1 mount namespace if required <Critical> <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2624>
<zyga> jdstrand: checking
<zyga> jdstrand: noted
<morphis> Pharaoh_Atem: https://bugzilla.redhat.com/show_bug.cgi?id=1435327
<morphis> Pharaoh_Atem: this is mostly what gofed gave me + some small additions to get the tests running
<morphis> zyga: ^^
<Pharaoh_Atem> morphis: left comments on review
<morphis> Pharaoh_Atem: great
<morphis> Pharaoh_Atem: fine for you if I update the spec and srpm at the same location?
<Pharaoh_Atem> yes, just make sure you note it as a comment
<Pharaoh_Atem> it's not significant enough to require anything else...
<morphis> aye
<morphis> Pharaoh_Atem: done
<mup> PR snapcraft#1218 opened: asset-tracking: use a more likely to be found global build-package <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1218>
<NicolinoCuralli> hi all which test ran on a snap as soon as published on a channel?
<morphis> Pharaoh_Atem: for the other package I need to see why gofed crashes on it
<mup> PR snapd#3073 opened: overlord: make sure all managers packages have *state.go with the main state manipulation/query APIs <Created by pedronis> <https://github.com/snapcore/snapd/pull/3073>
<Pharaoh_Atem> morphis: ERROR: 'Error [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661) downloading https://mm.gravedo.de/files/golang-github-ojii-gettext.go-0-0.1.gitb6dae1d.fc25.src.rpm' (logs in /home/makerpm/.cache/fedora-review.log)
<morphis> what?
<morphis> Pharaoh_Atem: it's singed by LetsEncrypt
<morphis> maybe that is the issue here for your build host
<mup> PR snapcraft#1219 opened: kernel plugin: learn how to assemble the ubuntu config using kconfigflavour <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1219>
<mup> PR snapd#3074 opened: configstate,hookstate: limit runtime of the configure hook to 1 minute <Created by mvo5> <https://github.com/snapcore/snapd/pull/3074>
<Pharaoh_Atem> morphis: something isn't set up right with your cert, since the only thing that lets me access it is Chrome
<mup> PR snapd#3073 closed: overlord: make sure all managers packages have *state.go with the main state manipulation/query APIs <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3073>
<stokachu> anyone seen returns: "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid
<stokachu>                  permission escalation attacks"
<stokachu> before?
<stokachu> ThiagoCMC: can you post `snap version` as well?
<ThiagoCMC> sure
<ThiagoCMC> 1 sec
<ThiagoCMC> "dpkg -l | grep snapd" = snapd 2.22.6
<ThiagoCMC> It is a fresh installed Ubuntu 16.04.2
<ogra_> better use "snap version"
<ThiagoCMC> Oh...
<ogra_> and also make sure to have all updates before trying to use snap
<ThiagoCMC> "apt full-upgrade" was executed a few minutes ago...
<ogra_> snapd is on a pretty frequent SRU cadence
<ThiagoCMC> sandvine@juju-1:~$ snap version
<ThiagoCMC> snap    2.23.1
<ThiagoCMC> snapd   2.23.1
<ThiagoCMC> series  16
<ThiagoCMC> ubuntu  16.04
<ThiagoCMC> kernel  4.8.0-41-generic
<ogra_> that looks better :)
<ThiagoCMC> damn... pasted my private login... lol
<stokachu> dont worry we're all saints here
<ThiagoCMC> So, how to fix: "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks" ?
<ogra_> we wont tell anyone (only the IRc logs and google will though)
<ThiagoCMC> I know....  ^_^
<ThiagoCMC> that's ok.. haha
<ogra_> looks like zyga is already off ... snap-confine is his area :/
<stokachu> found this http://askubuntu.com/questions/888497/snap-confine-refuses-to-launch-application-to-avoid-permission-attack
<stokachu> no answers but..
<ThiagoCMC> I found that too...  =/
<ThiagoCMC> So, http://conjure-up.io/ instructions are basically, broken.   :-(
<stokachu> ThiagoCMC: you aren't on mint are you?
<ThiagoCMC> Nop!
<ThiagoCMC> Ubuntu 16.04.2, fresh installed.
<ThiagoCMC> from Ubuntu Server ISO...
<stokachu> hmm
<stokachu> so where was "dpkg -l | grep snapd" = snapd 2.22.6 run from?
<zyga> hello
<stokachu> b/c your snap version shows 2.23.1
<stokachu> ah
<zyga> stokachu: hey
<stokachu> zyga: hey!
<zyga> so I wrote that part
<stokachu> zyga: have a user running into snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<zyga> stokachu: I'm curious where are you running this
<mup> PR snapcraft#1218 closed: asset-tracking: use a more likely to be found global build-package <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1218>
<stokachu> ThiagoCMC: ^
<stokachu> zyga: ThiagoCMC is the user with the issue
<ogra_> <ThiagoCMC> snap    2.23.1
<ogra_> <ThiagoCMC> snapd   2.23.1
<ogra_> <ThiagoCMC> series  16
<ogra_> <ThiagoCMC> ubuntu  16.04
<zyga> stokachu: is this on Ubuntu or is this somewhere else?
<ogra_> <ThiagoCMC> kernel  4.8.0-41-generic
<stokachu> zyga: yea ubuntu 16.04.2
<zyga> ThiagoCMC: hey
<ThiagoCMC> Hey!
<zyga> very interesting
<zyga> ok, can you please look at ...
<ogra_> seems up to date and all
<zyga> sudo cat /sys/kernel/security/apparmor/profiles
<zyga> ThiagoCMC: can you please run that and pastebin
<ThiagoCMC> 1 sec
<ogra_> oh, that looks like a hwe kernel btw
<ThiagoCMC> zyga, https://paste.ubuntu.com/24236144/
<ThiagoCMC> yeah, Linux 4.8
<zyga> ThiagoCMC: thanks, so lines 12 and 13 are what we needed to see
<zyga> ThiagoCMC: can you please set SNAP_CONFINE_DEBUG=yes and run something that is a snap
<ThiagoCMC> Let me try
<ThiagoCMC> zyga, you mean, something like "conjure-up openstack" ?
<zyga> ThiagoCMC: or even hello-world if you have that snap installed
<zyga> (the smaller the better)
<ThiagoCMC> right, 1 min...
<ThiagoCMC> zyga, https://paste.ubuntu.com/24236164/ look good
<zyga> ThiagoCMC: now run it
<ThiagoCMC> zyga, https://paste.ubuntu.com/24236179/
<zyga> hmmm
<zyga> so hello-world worked
<ThiagoCMC> yep
<zyga> now run what you tried earlier
<ThiagoCMC> maybe I need "$ sudo conjure-up openstack", with "sudo" ?
<ThiagoCMC> instructions on conjure-up.io doesn't tell to use sudo...
<zyga> ThiagoCMC: that error you saw should never show up
<ThiagoCMC> =(
<zyga> ThiagoCMC: maybe conjure-up runs some snap commands itself
<ThiagoCMC> easy to reproduce...
<zyga> ThiagoCMC: can you run conjure up again?
<ThiagoCMC> sure
<ThiagoCMC> LOL Worked after a reboot!
<ThiagoCMC> WTF!   =P
<zyga> ThiagoCMC: curious
<ThiagoCMC> Windows!
<ThiagoCMC> aheuHAEuae
<zyga> ThiagoCMC: what did you do before reboot?
<zyga> ThiagoCMC: what that error message said essentially
<zyga> ThiagoCMC: is that snap-confine didn't have its apparmor profile loade
<zyga> *loaded
<ThiagoCMC> zyga, "sudo snap install conjure-up --classic" then reboot
<ThiagoCMC> otherwise, "conjure-up openstack" doesn't work...
<zyga> aha
<ThiagoCMC> hehehe
<zyga> hmmm
<zyga> well
<zyga> no idea really :/
<zyga> ThiagoCMC: thanks, if this happens again please report it
<ThiagoCMC> Looks like that conjure-up.io needs a review!
<ThiagoCMC> It happens all the time!
<zyga> oh?
<ThiagoCMC> I tried it 3 times...
<zyga> can you report a bug with instructions on how to cause it?
<zyga> I never saw that myself
<ThiagoCMC> yes
<stokachu> ThiagoCMC: you are the only one to hit this issue
<zyga> aaah
<zyga> I think I know
<ThiagoCMC> I'm the Master of Bugs!   ;-)
<zyga> well, maybe suspect
<zyga> suspect this is related to classic confinement which does not reset PATH
<zyga> so you run with your own path
<zyga> but ...
<zyga> nah
<zyga> that doesn't explain anything
<ThiagoCMC> Right, I'll even record my screen and upload to youtube, then, fill a "video bug report" on launchpad
<stokachu> thanks
<stokachu> i'd like to reproduce it
<zyga> ThiagoCMC: if you can report that I would appreciate the details
<zyga> ThiagoCMC: then we can get to the bottom of it
<ThiagoCMC> Sounds cool! I'll be happy to help!
<Bizon> hey there. i'm packaging an app and while it runs completely fine if i start it through /snap/app/current/usr/bin/app, it just prints "F" and quits if i start it from /snap/bin
<Bizon> does anybody have a clue what could be wrong please?
<nacc> Bizon: iirc, /snap/bin apps are just wrapper scripts? you might be able (as root) to use bash -x or so (maybe, check what the script is first, i guess) to see what command is failing?
<kyrofa> nacc, they aren't wrapper scripts anymore, they're symlinks
<Bizon> nacc: /snap/bin apps are symlinks to snap run <app>
<kyrofa> nacc, snapd uses those symlinks to determine the environment programatically, so it's a little opaque
<nacc> kyrofa: ah! sorry, i dont' follow it actively, was going off what i recalled
<nacc> Bizon: sorry for the misinformation!
<Bizon> nacc: np
<kyrofa> nacc, oh no criticism meant on my part. You were absolutely correct until a few releases ago
<Bizon> hmm, now i see with snap run i can do --shell and try run it manually right?
<zyga> Bizon: if you run it via /snap/bin it gets confined
<kyrofa> Bizon, `snap run --shell` will put you into a shell confined with the same environment as the app, so yeah, try that
<kyrofa> Bizon, I assume it'll fail the same way as when you run the app in /snap/bin/
<zyga> Bizon: if you run it from /snap/$SNAP_NAME/current/... you just run whatever is there unconfined
<morphis> Pharaoh_Atem: that is lets-encrypt I guess
<Bizon> kyrofa: it doesn't, i get a ldd error
<niemeyer> Bizon: Note you need to provide any command line arguments yourself
<kyrofa> Bizon, ah, you're missing the snapcraft wrapper that's probably setting LD_LIBRARY_PATH for you, then
<niemeyer> kyrofa: It'd be nice to get rid of those wrappers at some point
<niemeyer> kyrofa: We have the environment settings support now
<Bizon> kyrofa: oh, i have that
<kyrofa> niemeyer, I doubt it'll ever happen. Some plugins actually inject real shell script
<Bizon> kyrofa: running the wrapper i get just F again
<kyrofa> niemeyer, i.e. not just exports
<niemeyer> kyrofa: It'd be nice to find an alternative to that
<niemeyer> kyrofa: Also, this is not a reason to not move the env itself into snap.yaml
<kyrofa> niemeyer, I agree that they're an annoying level of redirection. What sort of alternative to you envision?
<niemeyer> kyrofa: FIrst step would be to kill the wrapper altogether unless necessary
<niemeyer> kyrofa: In the conversation above, note how the shell ends up in a completely different environment from the one the application will actually run on
<niemeyer> kyrofa: More complexity, more confusion, ...
<kyrofa> niemeyer, yes, like I said, I agree
<niemeyer> kyrofa: So let's do it :)
<Bizon> but yeah, if i run the app, i just get "F" printed to stderr, not even a line break
<Bizon> and it quits immediately
<kyrofa> niemeyer, but the environment keyword only supports state variable definitions, which doesn't cover all use-cases. The catkin plugin for example actually has real shell scripting in there
<kyrofa> s/state/static/
<kyrofa> niemeyer, I'm not clear on a viable alternative
<ThiagoCMC> zyga, "conjure-up openstack", after staring the OpenStack deployment, failed again: https://paste.ubuntu.com/24236284/
<ThiagoCMC> I'll give it up for now...   :-(
<zyga> ThiagoCMC: hmmm
<ThiagoCMC> ;-(
<zyga> ThiagoCMC: is that because of snap-confine?
<morphis> Pharaoh_Atem: ok, retry, should work now
<ThiagoCMC> no idea...
<ThiagoCMC> I'll try juju only, conjure-up is not working.
<kyrofa> niemeyer, snapcraft could start placing all of its static environment in the snap.yaml and only generate those wrappers as a more special case for the plugins that need them, but that switches the order around so the plugin's environment doesn't come first which may have unintended side effects
<niemeyer> kyrofa: In which sense would it not come first?
<mup> PR snapcraft#1217 closed: tour: make it work when its a snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1217>
<kyrofa> niemeyer, right now snapcraft evaluates the plugin environment and then sets the stuff it knows it needs (LD_LIBRARY_PATH, PATH, etc.). If that was moved into the snap.yaml, snapd would evaluate it before the plugin's environment was evaluated
<kyrofa> niemeyer, changing the LD_LIBRARY_PATH ordering, etc.
<pmcgowan> kyrofa, where do I read about the environment keywword
<niemeyer> kyrofa: This sounds like the more natural choice?
<niemeyer> kyrofa: Defaults usually come first
<ogra_> ThiagoCMC, that pyhon stacktrace is probably something stokachu would like to see too
<kyrofa> niemeyer, perhaps, I'm simply stating that it's a change that could have unintended side effects. We should be careful
<ThiagoCMC> ogra_, right... I posted on #juju as well... I'll ping him... In the end of the day, conjure-up.io instructions does not work.
<kyrofa> pmcgowan, haha, I'm having a heck of a time finding docs for you, that's bad
<niemeyer> kyrofa: Indeed, but note that this only affects new builds
<pmcgowan> kyrofa, yeah I did look myself
<jrwren> is there a way to run https://snapcraft.io/docs locally? the 3-4s page loads are slow enough to be annoying.
<kyrofa> niemeyer, new or not, if the builds I publish via daily CI started breaking because of snapcraft changes I'd be unhappy
<kyrofa> Regardless, I agree that it's something to move toward. Those wrappers drive me nuts
<niemeyer> \o/
<kyrofa> Just don't want to put more work on the shoulders of snap developers
<kyrofa> pmcgowan, mind logging a bug about the environment keyword?
<kyrofa> pmcgowan, you can see a demo of it here if you're curious, though: https://github.com/snapcore/snapcraft/blob/master/demos/git/snap/snapcraft.yaml
<pmcgowan> kyrofa, what do I log against
<kyrofa> pmcgowan, definitely snapcraft, though I couldn't find anything in snapd either
<pmcgowan> ok
<pmcgowan> kyrofa, as long as the wrapper needs to do things conditionally, this only helps a bit
<kyrofa> pmcgowan, yeah that's what niemeyer and I were talking about. As soon as something other than static variables are required, we require wrappers
<pmcgowan> kyrofa, or most of the time to even set them you test something
<mup> PR snapd#3075 opened: overlord: split out handlers.go in devicestate and snapstate, other small order/naming tweaks <Created by pedronis> <https://github.com/snapcore/snapd/pull/3075>
<pmcgowan> like to make the arch specific path
<pmcgowan> or find the right socket location
<kyrofa> pmcgowan, indeed. Check out what the catkin plugin has to do: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/catkin.py#L381
<pmcgowan> oy vay
<kyrofa> Soo many faces on keyboards
<ogra_> there is a backslash missing ...
<ogra_> ... i'm sure ...
<ogra_> :P
<pmcgowan> kyrofa, michi reported one already at bug #1666745
<mup> Bug #1666745: environment appears to be undocumented <Snapcraft:New> <https://launchpad.net/bugs/1666745>
<Pharaoh_Atem> morphis: package approved
<kyrofa> Oh good!
<kyrofa> Shush ogra_
<ogra_> pmcgowan, https://github.com/myriadrf/snapcraft-sandbox/blob/master/limesdr-grc/snapcraft.yaml a good example for environment btw
<Pharaoh_Atem> morphis: however, you're not quite done yet :)
<kyrofa> niemeyer, would it be downright dreadful to support more verbose shell in snapd instead of just static variables?
<kyrofa> niemeyer, the point pmcgowan makes is a good one
<morphis> Pharaoh_Atem: you mean with submitting that package?
<kyrofa> niemeyer, but I can see that resulting in really gross YAMLs
<kyrofa> But as far as snapcraft is concerned, we already have the scriptlets
<Pharaoh_Atem> morphis: well, since you're a first time packager and you're quite literally new to RPM packaging, I want you to do a couple of (non-binding) package reviews in the package review queue
<niemeyer> kyrofa: Yes, that'd probably not end up well, but we might introduce the idea of a setup script
<niemeyer> Which ends up in the same place
<niemeyer> But not dreadful
<kyrofa> niemeyer, yeah, something like that would help a lot
<morphis> Pharaoh_Atem: sounds good, should I just pick some from https://fedoraproject.org/PackageReviewStatus/NEW.html ?
<Pharaoh_Atem> Yep
<Pharaoh_Atem> some from the newest ones, rather than the oldest ones
<morphis> yeah, will take a few golang ones
<Pharaoh_Atem> you'll want to familiarize yourself with https://fedoraproject.org/wiki/Packaging:Guidelines and https://fedoraproject.org/wiki/PackagingDrafts/Go
<mup> PR snapcraft#1220 opened: Release changelog for 2.28 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1220>
<Pharaoh_Atem> morphis: also, you should announce yourself on the fedora-devel mailing list
<morphis> Pharaoh_Atem: yeah was planing to do that tomorrow
<jrwren> is there a way I can run strace in a snap environment to see what is going on?
<zyga> jrwren: yes
<zyga> jrwren: you need to do a few things but it is possible
<zyga> jrwren: the trick is to use "snap run --shell" to run a shell with confinement the same as a given app
<zyga> jrwren: then run a copy of strace (you need to put it somewhere reachable)
<zyga> jrwren: you may need to adjust confinement (not sure, I do this without thinking sometimes)
<zyga> jrwren: you can copy strace from your host
<zyga> jrwren: and e.g. stick it in /run where you can copy it from
<zyga> jrwren: note that you will not be able to run it from /run (apparmor) so you will have to copy it somewhere else (try /tmp but again not sure because whenever I do it I do it automatically and think too little to remember)
<jrwren> ok, i'll play around with that. the snap in question is not confined anyway, so maybe it will be easier?
<zyga> jrwren: yes, it will be easier
<zyga> jrwren: you can then run it directly from /var/lib/snapd/hostfs/usr/bin/strace
<zyga> jrwren: (that is, use snap run --shell and then run strace like I said)
<jrwren> strace helped. thanks zyga
<jrwren> I filed a bug, but I'm snappy new enough that I wonder if it is a bug. https://bugs.launchpad.net/snapcraft/+bug/1675545
<mup> Bug #1675545: undefined symbol: _Py_RefTotal <Snapcraft:New> <https://launchpad.net/bugs/1675545>
<jrwren> Does the python plugin support C modules with python-version set to python2?
<jrwren> I get ImportError: ... undefined symbol: _Py_RefTotal
<jdstrand> roadmr: can you add a pull of r851 to your queue? like the last one, not urgent at all
<jdstrand> roadmr: and hi! :)
<roadmr> jdstrand: hello! sure thing, I'll prepare the merge
<jdstrand> thanks
<zyga> jdstrand: upstream kernel has something that fails our seccomp code
<zyga> jdstrand: https://bugs.launchpad.net/snappy/+bug/1674193
<mup> Bug #1674193: core snap's configuration hangs on debian|openSUSE <Snappy:In Progress by morphis> <snapd (Debian):New> <openSUSE:Fix Released by morphis> <https://launchpad.net/bugs/1674193>
<zyga> jdstrand: we should run our seccomp test suite on one
<zyga> jdstrand: (I'm EOD, just wanted to let you know)
<zyga> jdstrand: and perhaps extend it to test bind specifically
<zyga> jdstrand: (it gets killed on bind)
<zyga> jdstrand: this was tested on xenial with both xenial kernel (-41) and mainline kernel (linux-image-4.10.2-041002-generic)
<zyga> jdstrand: the mainline kernel fails reliably each time
<jdstrand> zyga: it is possible it is not the kernel but their seccomp
<jdstrand> zyga: see this changelog for trusty's https://launchpad.net/ubuntu/+source/libseccomp/2.1.1-1ubuntu1~trusty3
<zyga> jdstrand: no, it was tested on a machine with just rebooting to stock kernel
<zyga> no other updates were installed
<jdstrand> zyga: if they have 2.1.x, then they should use those patches or upgrade to 2.2.3 (what is in xenial)
<jdstrand> what version of seccomp do they have?
<zyga> jdstrand: asking
<zyga> jdstrand: apt-cache policy libseccomp is sufficient?
<zyga> (libseccomp2)
<jdstrand> cause the issues that bug showed with 2.1 were weird
<jdstrand> zyga: I thought this was opensuse?
<jdstrand> but however you can give me the version, that's fine
<zyga> jdstrand: no, I'm telling you this happens on *xenial* using a mainline (non ubuntu sauce) kernel
<zyga> jdstrand: it happens on debian, opensuse and now xenial with !patched kernel
<jdstrand> oh, that was not clear
<zyga> ah, sorry, about that
<jdstrand> I don't know of any seccomp patches to our kernel to fix bind
<zyga> yeah, it's pretty odd
<jdstrand> I'll see if I can trigger it locally, but may not be today-- I have several other people who asked for help from me this afternoon
<zyga> OK
<zyga> jdstrand: just wanted to let you know that the plot thickens :)
<zyga> I think it may be related to apparmor in the end, if we boot a mainline kernel we may run without apparmor so snapctl may end up doing things it normally doesn't because it gets EPERM from apparmor
<zyga> jdstrand: this was on libseccomp2 at version 2.2.3-3ubuntu3
<jdstrand> zyga: ok 2.2.3 is fine
<roadmr> zyga: are you still using git-lp sometimes?
<zyga> roadmr: no, just native git
<roadmr> zyga even better :)
<mwhudson> jdstrand: is there anything i can help with re: bug 1674193 ?
<mup> Bug #1674193: core snap's configuration hangs on debian|openSUSE <Snappy:In Progress by morphis> <snapd (Debian):New> <openSUSE:Fix Released by morphis> <https://launchpad.net/bugs/1674193>
<mwhudson> it seems mostly like people who know more about the innards than me are onto it, but i thought i'd ask
<mwhudson> hm not the best timing there, i need to disappear for a while
<mwhudson> but anyway, offer stands :)
<jdstrand> mwhudson: I'm not looking at it yet, I'm helping pmcgowan with something. I've added it to my list to look at. what I plan to do is boil it down to a simple reproducer so I can hand off to someone
<mup> PR snapd#3075 closed: overlord: clean up organization under state packages <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3075>
<mwhudson> uh can someone name a trivial confined snap that isn't hello?
<sbeattie> mwhudson: pwgen-tyhicks ?
<mwhudson> sbeattie: ta
 * tyhicks lets out a mwahahaha
<roadmr> evil laughter \o/
<mwhudson> uh well this is with apparmor off so i guess confined wasn't necessary
<mwhudson> wait no it isn't
<Pharaoh_Atem> morphis: where are we on merging in the fixes that zyga created for the openSUSE snapd package?
<mwhudson> heh debugging things that only happen confined is impressively impossible
<mwhudson> how do you make snapcraft actually use your python package when the snapcraft.yaml is in the same tree as your python?
<mwhudson> oh apparently i still want the source-type git
#snappy 2017-03-24
<mup> Bug #1650091 changed: console-conf and getty hang if password is not set and press many enters <Snappy:Fix Released> <https://launchpad.net/bugs/1650091>
<mup> PR snapcraft#1220 closed: Release changelog for 2.28 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1220>
<zyga> good morning
<mup> PR snapd#3076 opened: cmd: disable the re-associate fix as requested by jdstrand <Created by zyga> <https://github.com/snapcore/snapd/pull/3076>
<morphis> Son_Goku: I have the C part of snapd now building
<mup> PR snapd#3077 opened: interfaces: convert systemd backend to new APIs <Created by zyga> <https://github.com/snapcore/snapd/pull/3077>
<abeato> ogra_, where can I find the latest stable rpi3 image? I've flashed the daily one but not sure if it is working
<morphis> abeato: http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz
<abeato> morphis, thanks, seems more modern than last time I took a lookf
<morphis> Son_Goku: and a few builds later: INFO: Done(/home/simon/rpmbuild/SRPMS/snapd-2.23.1-1.fc25.src.rpm) Config(default) 0 minutes 57 seconds
<Son_Goku> unvendored?
<morphis> yes!
<Son_Goku> so you mockchain'd a build and it worked?
<morphis> I installed a few local packages into the mock env, but yeah
<Son_Goku> what changes did you need to make to snapd.spec?
<morphis> a few
<morphis> I also had to update the tomb package as it was quite outdated
<morphis> I will push in a bit
<morphis> things are still very rought
<Son_Goku> push to where?
<morphis> github.com/morphis/snapd
<morphis> Son_Goku: btw. https://bugzilla.redhat.com/show_bug.cgi?id=1435572
<morphis> Son_Goku: and zyga will be happy that we now see https://bugs.launchpad.net/snappy/+bug/1674193 on fedora too :-)
<mup> Bug #1674193: core snap's configuration hangs on debian|openSUSE <Snappy:In Progress by morphis> <snapd (Debian):New> <openSUSE:Fix Released by morphis> <https://launchpad.net/bugs/1674193>
<Son_Goku> what I'm concerned about is that I currently need nine patches to make snapd build
<Son_Goku> the rate of churn in snapd git makes it impossible to keep up with out of tree patches easily, unless they are very minor
<morphis> Son_Goku: yes I agree, but we can do this for now and I will work with zyga to get us drop all these
<morphis> or just keep one or two
<Son_Goku> I've already got modified packaging pulling in all the openSUSE patches
<morphis> ah great
<morphis> Son_Goku: so you have snapd building with the vendorized tree?
<Son_Goku> no
<Son_Goku> it fails to link vendorized
<morphis> with a error that the linker doesn't know about relro?
<Son_Goku> yes
<morphis> ok, I've switched from %gobuild to a simple go build for this
<morphis> looks like LDFLAGS carrys something which the go linker doesn't like
<Son_Goku> yeah, we enforce hardening
<morphis> yeah
<morphis> Son_Goku: https://github.com/morphis/snapd/tree/f/fedora-packaging
<Son_Goku> errm
<Son_Goku> your systemd units don't work
<morphis> I know :-)
<morphis> I said its kind of rough
<morphis> it also puts things into /snap ..
<morphis> doesn't run any tests ..
<Son_Goku> well, I did have a working build, but it wasn't something worth releasing into Fedora
<morphis> sure, but that are the next steps
<morphis> Son_Goku: so in general, getting something in f25 is possible or only with an exception?
<Son_Goku> I *could* technically get something released now, with a whole lot of FIXMEs
<morphis> even with my two packages not included?
<Son_Goku> well, no
<Son_Goku> not without those
<Son_Goku> well
<Son_Goku> I could, because it's pending their inclusion
<morphis> ok
<morphis> Son_Goku: then lets do a plan of what next things we take to get those remaining bits fixed so we can submit with a clean and working package
<Son_Goku> no hardening flags is a problem, though
<Son_Goku> hardened builds should be working
<Son_Goku> and I'd be even more concerned with snapd than normal go packages
<morphis> sure, lets collect those bits and get them fixed
<morphis> Son_Goku: shared a doc with you
<morphis> Son_Goku: feel free to add things I am missing
<Son_Goku> morphis: file a bug in rhbz to request an update for golang-github-go-tomb-tomb
<morphis> Son_Goku: who has to do the update? we or the maintainer?
<Son_Goku> well, the maintainer usually
<Son_Goku> you should also request comaintainership: https://admin.fedoraproject.org/pkgdb/package/rpms/golang-github-go-tomb-tomb/
<Son_Goku> in fact, you should do that for all packages that are snapd deps
<Son_Goku> you and zyga might also want to join the golang sig
<Son_Goku> though apparently no page describing it exists :/
<Son_Goku> anyway,  jchaloup is the maintainer of the package, so you could also email him
<zyga> Son_Goku: +1 good idea
 * zyga looks outside at the soaking rain 
<zyga> not a great way to start spring
<Son_Goku> it's cold and rainy here, so spring already sucks
<Son_Goku> morphis: you really need to do your introduction in devel@
<morphis> Son_Goku: yeah, I have that prepared here
<morphis> Son_Goku, zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1435616
<mup> PR snapd#3078 opened: tests: remove stale apt proxy leftover from cloud-init <Created by zyga> <https://github.com/snapcore/snapd/pull/3078>
<morphis> Son_Goku: how much time do you have to work on those remaining things?
<Son_Goku> morphis: I can try to make as much time as I can, but unlike you guys, I'm doing this in my spare time
<Son_Goku> and I juggle a lot of other things too
<morphis> Son_Goku: yeah, really appreciate this!
<Son_Goku> anyway, I approved your two golang package review requests
<morphis> Son_Goku: so I can take us through all of these next week
<Son_Goku> and you're now sponsored into packagers group
<morphis> awesome!
<Son_Goku> limb will approve them later today, most likely
<morphis> limb?
<Son_Goku> Jon Ciesla
<Son_Goku> well, apparently it's Gwyn now
<Son_Goku> but his FAS account name is limb and Gwyn often shows up on IRC as limb, too
<morphis> ah I see
<Son_Goku> oh boy, this is going to be rough :/
<Son_Goku> remembering to use the right pronouns
<mup> PR snapd#3079 opened: osutil: add GetBootID <Created by zyga> <https://github.com/snapcore/snapd/pull/3079>
<morphis> Son_Goku: so any particular item you want to work on or should I take them all for now?
<Son_Goku> you take them all for now
<Son_Goku> I'm about to push my pending changes to a git repo, one sec
<Son_Goku> morphis: would it be possible to release an "overlay tarball" that overlays the vendored stuff on top of the regular snappy sources?
<morphis> Son_Goku: maybe, need to talk with mvogt about that
<morphis> he currently generates the release tarballs by hand
<Son_Goku> if the "vendorizing" was a separate overlay tarball, that would make this easier for me
<morphis> Son_Goku: which way?
<Son_Goku> because then I can upload both sources and only use the vendorized code for EL7
<Son_Goku> and I don't have to condition which tarball to use
<Son_Goku> things like spectool cannot process conditional sources
<morphis> I see, let me see if that is something we can do
<Son_Goku> Debian packaging should also be able to leverage such a configuration easily, too
<mup> PR snapd#3080 opened: interfaces: remove old API <Created by stolowski> <https://github.com/snapcore/snapd/pull/3080>
<Son_Goku> morphis: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/commit/d2cd7591b6f362f4828ed7bbf29fb3cf335b541d
<Son_Goku> I exported fedora-dist-git and applied my in-progress packaging work there
<morphis> Son_Goku: great
<Son_Goku> morphis: and here's the "pristine" one: https://github.com/Conan-Kudo/snapd/commit/494f96fa458d6c71d07d2520555e5fabf61a8445
<zyga> Son_Goku: wrt vendor tarball, yes, I'm sure
<morphis> Son_Goku: thanks, will integrate those bits
<Son_Goku> zyga: overlay tarballs would be much better for me, since I can just conditionally install the second set of sources
<Son_Goku> but I can always pull them both and upload them in tandem
<zyga> Son_Goku: we could also split the upstream release to two tarballs, pristine snapd and pristine vendor tree
<zyga> Son_Goku: it's just a directory after all
<Son_Goku> zyga: that's what I meant
<Son_Goku> the vendor tree would be an overlay tarball
<zyga> Son_Goku: and then packaging for vendor/devendrized becomes easier
<zyga> yes, definitely, when michael is back (he's off resting today) we should propose that
<Son_Goku> because right now, it's a pain to switch back and forth
<Son_Goku> especially when debugging golang issues
<Son_Goku> zyga: but I have "building" sources now: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/blob/snapd-pkg-dev/snapd.spec
<Son_Goku> but only when building in vendorized mode
<zyga> Son_Goku: that's great, I would like to see a vendorized build in CORP
<zyga> COPR
<zyga> Son_Goku: in parallel with the devendorized build in the repository
<Son_Goku> well, I can build vendorized builds now in copr if I wanted to
<morphis> Son_Goku: lets put a vendorized build into copr now, then we have something people can play with if they want
<Son_Goku> morphis, maybe later today
<Son_Goku> as it is, I haven't even attempted to use the packages yet :/
<zyga> morphis: does the package you have built work?
<zyga> morphis: did you try it with some snaps?
<morphis> zyga: yes, it works fully
<morphis> nextcloud etc. comes up without problems
<morphis> zyga: however its a bit rough, need to fix the systemd packages etc.
<morphis> Son_Goku, zyga: but we could atleast push these things to https://copr.fedorainfracloud.org/coprs/zyga/snapcore/
<morphis> zyga: my plan is to merge with Son_Goku's changes next and then we can have something testable and do any further cleanup from there
<Son_Goku> my version should also be using /var/lib/snapd/snap correctly, among other things
<morphis> right
<morphis> that is why I need to merge :-)
<zyga> morphis: rought in which way?
<renatu> jdstrand, could you approve this package? https://myapps.developer.ubuntu.com/dev/click-apps/6453/rev/8/
<zyga> morphis: we have the presets now so snapd.socket should start ok
<zyga> morphis: yes, I think we should push something to COPR
<jdstrand> renatu: I literally just did :)
<renatu> jdstrand, thanks :D
<morphis> zyga: yes but the other jobs need patching which Son_Goku did
<zyga> morphis, Son_Goku: if you guys have a package (vendorized, using /var/lib/snapd/snap) I would like to upload it there
<renatu> jdstrand, can we white list it ?
<jdstrand> renatu: I already did
<zyga> aha, sounds good
<morphis> zyga: lets target that for monday
<renatu> jdstrand, thanks again :D
<zyga> very good idea
<jdstrand> renatu: check your email :)
<jdstrand> np
<zyga> releases on Friday bring back luck
<morphis> yeah
<Son_Goku> read-only friday!
<morphis> :-D
<Son_Goku> anyway, that also gives us the weekend to get snappy deps updated in Fedora
<Son_Goku> which allows us to no longer vendorize
<morphis> +1
<morphis> Son_Goku: but we wont get those into f25, right?
<Son_Goku> why wouldn't we?
<zyga> morphis: why not, this is not debian
<morphis> hah!
<Son_Goku> we're not debian or ubuntu
<Son_Goku> we don't make life hard for people ;)
<morphis> I am starting to like Fedora :-)
<Son_Goku> Fedora master race :)
<Son_Goku> new packages can enter all stable repos
<zyga> :-)
<zyga> let's try that hangout next week guys
<zyga> once this is released we could plan some next steps (CI)
<zyga> and just enabling unit tests
<morphis> zyga: +1
<Son_Goku> we really need to get this done asap
<Son_Goku> preferably before the F26 Alpha goes out
<morphis> Son_Goku: is there a target date for the alpha?
<Son_Goku> I'm getting tired of the buildsystem bitching at me about snapd-glib
<Son_Goku> morphis: week after next Tuesday
<zyga> Son_Goku: oh, yes
<zyga> Son_Goku: btw, I wonder if that is integrated to gnome-software
<Son_Goku> right now, no
<zyga> Son_Goku: once you have snapd installed
<Son_Goku> because gnome-software will FTBFS
<zyga> aaaha
<zyga> maybe there's a pkg-config test?
<zyga> I think this was upstreamed some time ago
<Son_Goku> gnome software < 3.24 doesn't use snapd-glib, so it works
<zyga> ok
<zyga> well, litte by little :)
<Son_Goku> err, < 3.22
<Son_Goku> so Fedora 25 won't get it
<Son_Goku> but we can get it for F26
<Son_Goku> I just have to ask hughsie very nicely to turn it on once we update everything
<morphis> Son_Goku: nice!
<morphis> Son_Goku: I am fully on getting this done and having a target date is even better :-)
<Son_Goku> the GNOME 3.24 megaupdate has landed in Fedora 26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d1ab69a395
<Son_Goku> well, will land
<Son_Goku> it's pending
<Son_Goku> it's already in Rawhide
<zyga> Son_Goku: I'm actually curious, I will try F26, I wanted to see how the new gnome feels like
<zyga> did you try it?
<zyga> morphis: how do you feel working with all the distros? :)
<Son_Goku> zyga: I actually planned on updating my secondary machine to F26 today
<morphis> zyga: I am using them all through ssh so I don't see much of the user interface, but yeah, interesting :-)
<Son_Goku> I always do it around alpha time
<zyga> morphis: headless VMs?
<morphis> zyga: not really headless yet but I ignore the vbox windows and have them minized all the time :-)
<morphis> ssh + sshfs integrates much more into my workflo
<jdstrand> morphis: hey, can you clarify this comment: "With snapd 2.23 now building on Fedora 25 I can reproduce the same problem without specifying --disable-seccomp for the snap-confine build." - you are saying that when seccomp is enabled on F25, you see the problem but when it isn't, you don't?
<morphis> jdstrand: correct
<jdstrand> ok, so that is consistent with all other evidence pointing to mainline
<morphis> jdstrand: so your idea is that something in the kernel part is broken?
<jdstrand> I don't have any ideas. that is a reflection of Zygmunt's idea
<jdstrand> I'm going to poke at this and try to provide some extra info for triage
 * jdstrand is only just now starting to look at it
<morphis> jdstrand: ok, I wanted to look into this too but if you do than I can concentrate on getting the packaging stuff done
<jdstrand> morphis: yeah, let me poke at it for a bit
<zyga> morphis: we should have a simple small smoke test
<zyga> morphis: C program
<zyga> morphis: using libseccomp
<zyga> morphis: allowing bind
<zyga> morphis: doing bind
<morphis> zyga: +1
<Son_Goku> zyga: ahh yep, I have some fixing to do
<Son_Goku> new snapd is still broken
<Son_Goku> the selinux policy needs to account for the new binaries
<zyga> Son_Goku: ah, thank you for fixing that
<Son_Goku> I mean, I haven't done it yet...
<zyga> fixing is a continouous thing ;)
<Son_Goku> zyga: https://github.com/snapcore/snapd/pull/3081
<mup> PR snapd#3081: data/selinux: Add contexts for snapctl and ubuntu-core-launcher <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3081>
<mup> PR snapd#3081 opened: data/selinux: Add contexts for snapctl and ubuntu-core-launcher <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3081>
<Son_Goku> zyga, morphis: that should fix issues related to snapctl, since it will have the access rights to snapd
<zyga> Son_Goku: commented
<Son_Goku> zyga: removed ubuntu-core-launcher
<zyga> Son_Goku: great, I'll merge it when CI goes green (I cannot earlier)
<Son_Goku> anyway, now I really need to get to work
<pshod> other than using node-snapper
<pshod> can some1 tell me how do i make a snap application from a script written in node js
<pshod> ?
<pshod> URGENT! HELP! HELP! HELP!
<zyga> pshod: hey
<zyga> pshod: try snapcraft :-)
<zyga> pshod: snapcraft.io
<pshod> hey zyga :D
<pshod> i really do not understand where my .js script goes with the nodejs plugin
<pshod> so i switched to node-snapper
<zyga> pshod: I'm not a node developer but if you look at snapcraft you may find some examples of how to do stuff
<pshod> but would still want to do without it
<pshod> looked around a bit
<zyga> pshod: otherwise perhaps ask in https://rocket.ubuntu.com/channel/snapcraft
<pshod> people happily use the node-snapper instead
<ogra_> people shlouldnt :P
<ogra_> node-snapper was for 15.04 snaps
<ogra_> before snapcraft existed at all
<ogra_> with the creation of snapcraft node-snapper became obsolete ... so i stopped maintaining it
<pshod> ogra :D
<pshod> where do i put my .js script which should run on node
<pshod> i can put the packages I need with node-packages tag
<pshod> or do i need to write a package.json
<pshod> ?
<ogra_> see snapcraft.io there should be examples
<pshod> if i do
<pshod> where do i put it
<pshod> there are not
<ogra_> i havent packaged a node app since we have the new stuff
<pshod> "new stuff" ?
<zyga> pshod: quick google: http://blog.bhdouglass.com/nodejs/snap/2016/08/06/packaging-nodejs-projects-as-snaps.html
<ogra_> https://snapcraft.io/docs/reference/plugins/nodejs ... also has pointers to examples
<pshod> zyga: saw this one
<zyga> pshod: what's wrong with it?
<pshod> it has
<pshod> but the link doesnt actually have anything
<pshod> give me a min
<pshod> zyga: so in the apps section, if i put my script path in the command tag, it will be automatically executed with node?
<zyga> no, but look at the first line of the script in the hello world example
<zyga> https://github.com/bhdouglass/hello-node-snap/blob/master/bin/hello-node-snap#L1
<pshod> hey thanks
<pshod> doing tat now
<mup> PR snapd#3081 closed: data/selinux: add context definition for snapctl <Created by Conan-Kudo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3081>
<pshod> he has listed the snap in the node-packages
<pshod> and exposes the app in the command
<pshod> I have 2 .js scripts, one is 'required" in another for using api's
<pshod> the .js file acting as an api provider requires other packages which i plan to put in the node-packages tag
<pshod> sorry if all this sounds pretty noob
<pshod> I AM :p
<pshod> node-packages: -hello-node-snap
<pshod> does this translate to npm install hello-node-snap
<pshod> ?
<jdstrand> morphis, zyga, mwhudson: fyi https://bugs.launchpad.net/snappy/+bug/1674193/comments/16
<mup> Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <Snappy:In Progress by morphis> <snapd (Debian):New> <snapd (Fedora):In Progress> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193>
<morphis> jdstrand: what wonders me is that I saw the bind syscall in the seccomp policy for the configure hook, see comment #3
<jdstrand> morphis: I can try a vanilla kernel too
<morphis> jdstrand: but do you saw bind in the policy for the configure hook too by default?
<jdstrand> morphis: no
<morphis> hm
<jdstrand> only mbind
<morphis> I saw this with 2.23.1
<jdstrand> this is 2.22.6
<morphis> maybe my fgrep was misleading, let me check
<morphis> hm, checked on fedora with 2.23.1 and no bind there
<morphis> so looks like you're right
<jdstrand> morphis: there was a moment when the core snap plugged network-bind
<jdstrand> but it was reverted
<jdstrand> well, it isn't in r1441 anyway
<jdstrand> idk why you saw it
<morphis> jdstrand: hm, maybe that was what I was seeing yesterday
<morphis> Pharaoh_Atem: can I somehow avoid that I need to do something like this:
<morphis> [simon@localhost fedorapkgs-snapd]$ cp *.patch ~/rpmbuild/SOURCES/
<morphis> before I can run rpmbuild -bs snapd.spec?
<Pharaoh_Atem> morphis: yes, you can --define "_sourcedir </path/to/sources>" on the rpmbuild command line
<morphis> ah great
<morphis> Pharaoh_Atem: also where is this %gobuild macro defined?
<Pharaoh_Atem> it's defined in /usr/lib/rpm/macros.d/macros.golang-go-compiler
<Pharaoh_Atem> err  /usr/lib/rpm/macros.d/macros.golang-compiler
<mup> PR snapd#3082 opened: many: break the /aliases mutation API with a clean 400 <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3082>
<morphis> Pharaoh_Atem: ah, thanks!
<Pharaoh_Atem> if you don't have it, do "dnf install 'compiler(go-compiler)'"
<morphis> Pharaoh_Atem: ok, looks like I've fixed the linker/relro issue
<mup> PR snapd#3050 closed: interfaces/mount: compute mount changes required to transition mount profiles <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3050>
<morphis> Pharaoh_Atem: yeah I did
<Pharaoh_Atem> what was the fix?
<mup> PR snapd#3067 closed: tests: move docker test to new nightly suite <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3067>
<morphis> Pharaoh_Atem: switching the order of C and Go build in the spec file
<morphis> the C build of snap-confine somehow leaves LDFLAGS set which the go linker can't work with, if you build Go stuff first with %gobuild it isn't set and things build as they should
<morphis> Pharaoh_Atem: https://paste.ubuntu.com/24241472/
<Pharaoh_Atem> that's so retarded
<morphis> :-)
<morphis> Pharaoh_Atem: I will prepare templating for the systemd units then we don't have to carry copies of them
<Pharaoh_Atem> my suggestion, use @libexecdir@ and @snapmountdir@ in place of /usr/libexec and /var/lib/snapd/snap, respectively
<morphis> yeah
<morphis> Pharaoh_Atem: what do you mean with "Retire separate snap-confine package"?
<Pharaoh_Atem> snap-confine has been in Fedora since F23
<Pharaoh_Atem> it's 1.0.43 I think
<pshod> i am packaging a node js script into a snap app
<pshod> some of the packages listed under the node-packages tag cannot be downloaded proly cos of company's proxy
<Pharaoh_Atem> morphis: once we have a new snapd ready, then snap-confine needs to be retired
<morphis> Pharaoh_Atem: so the "Obsoletes:" in the spec file isn't enough?
<pshod> so i first pull the part
<morphis> Pharaoh_Atem: ah there is a separate step we need to do for that
<Pharaoh_Atem> morphis: well, it is for users, but we need to get rid of it in the SCM :)
<morphis> Pharaoh_Atem: I see :-)
<Pharaoh_Atem> so that the build system stops building the old snap-confine package
<pshod> then in /parts/part-name/install/lib/node-modules
<pshod> i copy the packages i needed
<morphis> Pharaoh_Atem: I've reinstalled my package and got https://paste.ubuntu.com/24241487/ during the install
<morphis> looks like its trying to adjust the existing squashfs mounts
<pshod> they also reflect in the prime folder
<pshod> but are not being found by the binary inside prime
<pshod> which is exposed as an app
<morphis> pshod: really sounds like necessary env variables or so are not set up properly
<pshod> ummm
<pshod> in the binary
<pshod> which i have used as a .js script
<pshod> i removed the extn of .js
<Pharaoh_Atem> morphis: that's normal
<pshod> instead added #!/usr/bin/env node
<pshod> is that supposed to work?
<morphis> Pharaoh_Atem: so no way to teach the macros to skip those mounts
<Pharaoh_Atem> morphis: it's not the macros
<Pharaoh_Atem> it's restorecon -Rv
<morphis> pshod: sadly I am not an expert in nodejs things .. if you don't find anyone else here the best is to drop a mail to the snapcraft mailinglist
<Pharaoh_Atem> morphis: ideally, it wouldn't matter as snapd would mount them all with that label
<pshod> hey thank you!
<Pharaoh_Atem> right now, it does not
<pshod> moreover i think if i get the proxy issue resolved this thing also might work
<pshod> its just too late here for me to call someone at IT to resolve the proxy thing
<pshod> :(
<pshod> fuck corporate proxy
<morphis> Pharaoh_Atem: ok
<jdstrand> morphis: fyi, https://bugs.launchpad.net/snappy/+bug/1674193/comments/18
<mup> Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <Snappy:In Progress by morphis> <snapd (Debian):New> <snapd (Fedora):In Progress> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193>
<morphis> jdstrand: ok, so things are clear and we need bind for every hook or the snapctl implementation fixed
<jdstrand> morphis: yes
<jdstrand> I would like to be a part of any PR that addresses this
<jdstrand> morphis: ^
<morphis> jdstrand: +1
<zyga> pshod: hey, did you check out snapcraft chat room on rocket chat?
<pshod> zyga: no
<pshod> will do
<pshod> thanks for the info
<zyga> pshod: I think that will work better, there are losts of people making snaps there
<Pharaoh_Atem> morphis: pushed revised specs to my git repos
 * zyga loves to see morphis and Pharaoh_Atem do everything he wanted to get done :)
 * kyrofa too
<mup> PR snapd#3083 opened: tests: move unity test to nightly suite <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3083>
<zyga> first fedora then the world ;D
<zyga> I'd love to see snapd on osx and windows
<zyga> I bought the original DOOM on GOG
<zyga> I'll snap it this weekend
<zyga> I wonder if GOG folks could offer snaps for linux
<zyga> or even put them in the store somehow
<morphis> zyga: :-D
<morphis> Pharaoh_Atem: awesome!
<morphis> one step closer to a release
<morphis> Pharaoh_Atem: there will be one more patch for us to integrate to get the templating for the systemd units
<zyga> morphis: we could actually release over weekend, people can check bodhi and try it and vote
<zyga> it's not like it's going live in seconds
<zyga> Pharaoh_Atem: what do you think?
<zyga> morphis: if you think it is ready
<zyga> (for wider testing)
<morphis> zyga: https://docs.google.com/document/d/1l9xS8RqSSjASNEIcHAOanlURNrpmfodf4Fd79QXdLG4/edit
<zyga> even if it ends with -2 in the end
<zyga> morphis: can you share that to make it public
<morphis> done
<zyga> Pharaoh_Atem: packaging question, can we recommend/depend on snapd-xdg-open from snapd on a workstation variant but not on a server variant?
<zyga> thanks!
<morphis> Pharaoh_Atem: https://github.com/snapcore/snapd/pull/3084
<mup> PR snapd#3084: packaging: use templates for relevant systemd units <Created by morphis> <https://github.com/snapcore/snapd/pull/3084>
<mup> PR snapd#3084 opened: packaging: use templates for relevant systemd units <Created by morphis> <https://github.com/snapcore/snapd/pull/3084>
<kyrofa> jdstrand, is there an interface that will cover /dev/input/js0 ?
<ogra_> kyrofa, most likely the joystick interface ;)
<ogra_> (no, doesnt exist yet i think)
<kyrofa> ogra_, :P
<kyrofa> jdstrand, assuming it's not covered, think that'd be a pretty easy addition?
<Pharaoh_Atem> morphis: see my comments https://github.com/snapcore/snapd/pull/3084#pullrequestreview-28972607
<mup> PR snapd#3084: packaging: use templates for relevant systemd units <Created by morphis> <https://github.com/snapcore/snapd/pull/3084>
<morphis> Pharaoh_Atem: aye
<morphis> Pharaoh_Atem: I have those bits also included in the rpm packaging now
<morphis> but will change to those suggested names
<morphis> Pharaoh_Atem: ok, a problem seems to be still there: $ krita
<morphis> dropping privs did not work: No such file or directory
<morphis> but that is something for next week :-)
<jdstrand> kyrofa: there isn't, no. I suspect that the interface would need more than just /dev/input/js* (eg, probably /dev/input/event*) and that is where things might get dicey, but, I'd be happy to review a PR
<kyrofa> jdstrand, I assume /dev/input/js* would be safe, but /dev/input/event* sounds a little more general-purpose
<jdstrand> kyrofa: event* is where you can start doing nasty things
<jdstrand> kyrofa: I guess you are snapping something that needs it. did you add '/dev/input/js0 rw,' and did it resolve all your denials?
<mup> PR snapcraft#1221 opened: state: factor state bits out of meta <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1221>
<kyrofa> jdstrand, I haven't tried yet, still putting the snap together
<kyrofa> jdstrand, but I'll try that. If that works, I assume that interface would be a slam dunk?
<jdstrand> kyrofa: it would, yes
<kyrofa> jdstrand, alright, I'll be in touch
<jdstrand> kyrofa: if you are writing it, model it after framebuffer (as opposed to say, camera)
<kyrofa> jdstrand, thanks for the hint! I'll make sure I touch bases before I write anything
<jdstrand> kyrofa: and be aware of https://bugs.launchpad.net/snapd/+bug/1675738. I believe jhodapp's team will be fixing all the historical interfaces that aren't doing the right thing
<mup> Bug #1675738: OpenGL interface should udev tag all /dev/* files <snapd-interface> <snapd:New> <https://launchpad.net/bugs/1675738>
<jdstrand> kyrofa: cool, np
<jhodapp> jdstrand, yeah, we'll be doing a 2 pass approach to it...first is to do a quick fix so we can get the fix in in time for snapd 2.24
<jhodapp> then we'll do the comprehensive fix
<jdstrand> jhodapp: great!
<kyrofa> Huh, very interesting!
<mup> PR snapd#3079 closed: osutil: add BootID <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3079>
<NicolinoCuralli> hi all just a doubt: it seem that a gadget can't be upgraded during the lifetime of a supported board? I don't find anything for making it in a transational manner: do I think wrong?
<kyrofa> NicolinoCuralli, I'd refer you to ogra_, but I suspect he's off for the day
<NicolinoCuralli> kyrofa: is it better to ask on the mailinglist?
<kyrofa> NicolinoCuralli, yeah I suspect so
<kyrofa> NicolinoCuralli, he's very responsive there
<NicolinoCuralli> kyrofa : thanks a lot :D
<kyrofa> Any time!
<kyrofa> Hey niemeyer, can I not use a relative path for the gadget snap in a model assertion? Does it need to be in the store?
<kyrofa> It seems so. jdstrand can I get a review on a gadget snap?
<kyrofa> I can't even upload a gadget to beta or edge, it seems
<kyrofa> It's really hard to make/test a gadget snap!
<jdstrand> kyrofa: it was uploaded
<kyrofa> jdstrand, heh, release then
<kyrofa> Thanks jdstrand!
<jdstrand> kyrofa: approved. I'll let you review
<jdstrand> err
<jdstrand> release
<kyrofa> jdstrand, I'll probably need to iterate on this-- will I need a manual review each time?
<jdstrand> kyrofa: since we don't have model assertions, I need to add something to the review tools to override this. I'm doing that now, but it won't be in production for a while. until then, yes
<kyrofa> jdstrand, sounds good :)
<kyrofa> This might just work!
<jdstrand> kyrofa: in what capacity is this being supported?
<jdstrand> kyrofa: you have -kyrofa in the name, so guessing this isn't Canonical supported?
<kyrofa> jdstrand, nah, for a blog post series about the Turtlebot. I need the gadget due to bug #1645445
<mup> Bug #1645445: Turtlebot needs /dev/kobuki <snapd-interface> <snapd:Confirmed> <https://launchpad.net/bugs/1645445>
 * jdstrand nods
<kyrofa> jdstrand, I'm a little sad no one will be able to follow it though. I was under the impression ubuntu-image would accept file paths
<jdstrand> hotplugging will be nice
<kyrofa> jdstrand, yes that would be better :)
<jdstrand> kyrofa: I suggest raising with stakeholders :)
 * jdstrand knows this comes up from time to time. squeaky wheel...
<kyrofa> Yeah, I was told to leave it alone and just write the series with a gadget snap
<jdstrand> roadmr: totally not urgent, but can you please pull r852 whenever is convenient?
<jdstrand> kyrofa: that is for you ^
<roadmr> jdstrand: sure thing
<kyrofa> jdstrand, haha, quick work!
<kyrofa> jdstrand, thank you :)
<roadmr> jdstrand: I should have that deployed early next week, but I'm starting by committing the change
<pedronis> kyrofa: the model assertion take just a name, you can override it with a local snap using --extra-snaps
<kyrofa> pedronis, ah ha! I tried that, but I still used a path in the assertion
<kyrofa> pedronis, let me give that a shot, thanks for jumping in
<pedronis> (that option name is very confusing, adding extra-snap is actually the thing we wantt the least, and might remove, but overriding with locall will stay supported)
<jdstrand> roadmr: thanks :)
<kyrofa> Indeed
<pedronis> kyrofa: remember that local snaps will not refresh though , just like snap install .snap
<kyrofa> pedronis, indeed. Although I seem to remember that gadget snaps being refreshed isn't really a thing anyway?
<pedronis> it gets refreshed
<pedronis> we don't do much with the refreshed content though
<pedronis> that's a bug, to fix
<kyrofa> Ah, right
<kyrofa> pedronis, there's a mailing list question for you to answer, then
<kyrofa> Sent about an hour ago
<pedronis> mostly that if it's a tutorial you might want to note on the side (I'm using a local snap because it's quick but for the full experience with refresh need a store one or something)
<kyrofa> pedronis, agreed, thanks for the tip
<kyrofa> pedronis, verified: leaving the assertion with just the name and using --extra-snaps works
<pedronis> IÂ wonder if our page about model assertion/ubuntu-image needs improvement, because IÂ have been explaining this a couple of times
<pedronis> I think
<kyrofa> pedronis, which page? All I know about is the tutorial
<kyrofa> I mean on tutorials.ubuntu.com
<pedronis> yes, it says this:  gadget: name of the gadget snap as published on the store. Note that this snap can be a file on disk.
<kyrofa> pedronis, yeah I read that as "this can be a file path on disk"
<pedronis> yea, not super clear
<pedronis> but it really means what it says literally
<pedronis> here goes the name (in snap.yaml/store) sense of the snap and the snap can be  a file
<pedronis> but then it doesn't says anywhere something about --extra-snaps
<kyrofa> Yeah I would say "name of the gadget snap as published on the store. If you want to use a snap from your disk, you'll need to supply its path via --extra-snaps" or something similar
<kyrofa> Although "as published on the store" begs the question "what if my snap isn't in the store"
<pedronis> well name of the snap, is the name of the snap, what you put snapcraft.yaml and goes into snap.yaml
<pedronis> but not sure how ingrained is that in general
<kyrofa> pedronis, note that you can edit the snap name in the store though
<kyrofa> pedronis, so there's a few levels of confusion that can happen there
<pedronis> IÂ don't remember that
<pedronis> it can be renamed
<kyrofa> pedronis, it doesn't rename it as far as snapd is concerned
<pedronis> given that snap name need to be registered
<kyrofa> pedronis, it's just a presentation layer thing
<pedronis> might be a left over from clicks
<pedronis> or something
<kyrofa> But the option is "edit name"
<pedronis> sounds strange for snaps
<kyrofa> Yeah maybe
<jrwren> Is there any docs on how snaps actually run. I see a snap which runs on xenial, but fails on trusty, but I thought this would be impossible given the ubuntu-core is the same. How does this actually work?
<kyrofa> Hey jdstrand this serial port interface doesn't seem to be doing anything
<kyrofa> jdstrand, this specifically: https://github.com/kyrofa/pc-amd64-turtlebot-gadget/blob/master/snapcraft.yaml
<kyrofa> jdstrand, should the vendor and product actually be strings?
<totallyhuman> hi
<totallyhuman> i have searched around for this error
<totallyhuman> and there are several bugs filed
<totallyhuman> with no success
<totallyhuman> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/find?q=e: dial unix /run/snapd-snap.socket: connect: no such file or directory
#snappy 2017-03-25
<anuragh> can someone suggest me  best tutorials for snapcraft ?
<mup> PR snapd#3077 closed: interfaces: convert systemd backend to new APIs <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3077>
<Son_Goku> zyga: who do we talk to for getting Launchpad's Red Hat bug tracker integration fixed? https://bugs.launchpad.net/bugs/bugtrackers/redhat-bugs
<mup> PR snapd#3072 closed: interfaces: use udev spec <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3072>
<zyga> Son_Goku: hey
<zyga> Son_Goku: cjwatson I think
<zyga> Son_Goku: those are pretty tiny and probably just neglected
<zyga> Son_Goku: but should be easy to fix
<Son_Goku> the bug tracking has been broken for a couple of years, and I think disabled for nearly as long
<zyga> Son_Goku: yeah, niche feature
<zyga> Son_Goku: I think we need to report a bug / talk to cjwatson
<Son_Goku> well, I personally like being able to tie upstream and downstream bugs together and have them tracked and injected into the bug report
<Son_Goku> it helps keep everyone in the loop, so to speak
<zyga> Son_Goku: yeah, that's why this feature exists here but it doesn't work perfectly everywhere
<zyga> Son_Goku: we had some issues and the github tracker was fixed
<zyga> offtopic, I got some set of nylon screws and standoffs so that my boards don't just lay flat on the desk
<zyga> but ... obviously... wrong size for everyone
<Son_Goku> O.o
<zyga> pi2, pi3, dragon, ci20
<zyga> eh
<zyga> why doesn't anyone think about consistency
<zyga> especially for casual folks like us here, not mechanical engineers that love the 10s of marginally different screws they can use
<zyga> or have easy and well-understood supply chain
<zyga> dragon has smaller screws holes than anyone else, ci20 has huge holes :/
<Son_Goku> it's super annoying
<Son_Goku> had the same problem with the Pine vs the Pi3 vs Pi2
<zyga> and no sata :D
<zyga> oh, I have one more board
<zyga> I forgot about it
<zyga> I mean plenty of others but this runs linux
<zyga> orange pi
<zyga> one of the gazillion variants
<Son_Goku> the ARM ecosystem just depresses me
<Son_Goku> so much potential, but so bloody screwy
<zyga> but we're stuck with it
<zyga> wow
<zyga> actually, this last board has sane screw holders
<zyga> go figure...
<Son_Goku> at least Red Hat and Linaro made the server ARM boards not stupid
<Son_Goku> but goddamn
<zyga> yes
<zyga> no matter how I hate firmware
<zyga> this is a good thing
<zyga> (acpi and all that stuff)
<zyga> btw, snapd for mageia?
<Son_Goku> in 2017, over 85% (and I'm being generous here) of all ARM boards requires special snowflake firmware
<zyga> sync from fedora or do we need a new package?
<Son_Goku> zyga: mostly sync from Fedora
<zyga> well, it's like a micro controller world really :)
<Son_Goku> just need to disable mandatory installation of the selinux subpackage
<Son_Goku> and since we still need AppArmor fixes upstreamed, still no confinement goodness
<Son_Goku> technically, Mageia currently uses TOMOYO
<Son_Goku> but nobody really supports it, so *shrugs*
<zyga> isn't it a thing in some vertical market?
<zyga> automotive/
<Son_Goku> yes
<zyga> or something like htat
<zyga> it's a japanese invention
<Son_Goku> yep
<zyga> like ruby
<zyga> :D
<zyga> speaking of which
<zyga> I want to do my own thing today
<zyga> no work :)
<zyga> so after I'm done with the boards
<Son_Goku> well, the gratuitous use of capital letters is indicative of Japaneseness :)
<zyga> I'll blog some more
<zyga> and work on rob
<Son_Goku> rob?
<zyga> rob is my sandbox for creativity and just sheer NIH :D
<zyga> rob = make
<Son_Goku> ah right
<zyga> rÃ³b :-)
<zyga> (Ã³ is pronounced exactly like u)
<Son_Goku> so... like rub or rube?
<zyga> not like US "r" (a-r) more like plain rrrr
<zyga> rrrr-u-b (short u)
<zyga> heh
<zyga> I wanted to add a feature
<zyga> rob --pronounce (or something)
<zyga> that has a wave table inside
<zyga> and just plays it
<Son_Goku> haha
<zyga> I was thinking about a new license as well
<zyga> SSL (sustainable software license)
<zyga> the name sucks :)
<Son_Goku> :/
<zyga> the idea is that it is proprietary with escrow so it turns to a pre-determined FOSS license if abandoned
<zyga> so you'd be able to sell new copies
<Son_Goku> please don't make custom licenses for the fucks
<Son_Goku> you know what happens when you do
<zyga> but would not die if I stop caring
<zyga> well, I think it's a real problem for today FOSS software
<zyga> it's hard to fund
<zyga> it's just an idea
<zyga> I don't need to put everything into one box
<zyga> and rob is just a toy for now
<zyga> but if one could really sell FOSS software (practically, not like today but not really) at low price in high volume I think world would be better
<zyga> would you buy a program for $5 knowing that it becomes GPL if you don't get an update in 12 months?
<zyga> Son_Goku: ah, sorry got disconnected
<zyga> all the boards have stand offs now :)
<Son_Goku> heh
<Son_Goku> today is going to be the day where I spend most of my time playing Legend of Zelda: Breath of the Wild
<Son_Goku> I have a Nintendo Switch and my god, it's amazing
<zyga> Son_Goku: ooooooooh
<zyga> Son_Goku: tell me
<zyga> Son_Goku: I love zelda
<zyga> Son_Goku: did you get the switch?
<zyga> Son_Goku: or the wii u version?
<Son_Goku> yes
<Son_Goku> Switch version, ofc
<zyga> Son_Goku: ohhh!
<zyga> Son_Goku: tell me! how do you like it?
<Son_Goku> it's awesome
<zyga> Son_Goku: bot the console and the game
<Son_Goku> the Joy-Cons are a literal joy to use
<zyga> Son_Goku: ooooh :-( I don't have it yet
<Son_Goku> 1-2-Switch game made it easy to really pick it up and get familiar
<zyga> Son_Goku: I was thinking about buying horizon zero dawn as it's not as $$$ as a new game *and* a new device
<Son_Goku> and they really did a good job emulating real-world feel with the haptics
<zyga> Son_Goku: did you play on the go?
<Son_Goku> I've done a bit of that, yes
<zyga> Son_Goku: does it play equally well?
<zyga> Son_Goku: is the framerate the same?
<zyga> Son_Goku: and is the screen good?
<Son_Goku> the screen is very nice, and the framerate is good, most of the time
<Son_Goku> there's some moments where it slows down a bit, particularly when there's lots of actively moving things
<Son_Goku> but it doesn't happen often enough to be concerning
<zyga> Son_Goku: but does that happen only while on the go? I'm trying to understand if it's slower when on batter
<zyga> battery
<Son_Goku> when not connected to the TV, it's actually better
<Son_Goku> less pixels to push
<zyga> oh, curious :)
<zyga> Son_Goku: and the actual game
<Son_Goku> battery life is about 3.5~4 hours with Zelda
<Son_Goku> supposedly the battery capacity lends itself well for 8 hours, but who knows?
<zyga> Son_Goku: how far did you get into the game?
<Son_Goku> I'm not too far in yet, I've only gotten to two shrines, and I have to get to two more before I get a paraglider to get further along
<Son_Goku> but damn, the world is HUGE and somewhat challenging to navigate
<zyga> Son_Goku: bring it to the next snappy sprint :)
<Son_Goku> if there is one, I will :)
<zyga> Son_Goku: my kids have nintendo 3DSes but they rarely game
<zyga> Son_Goku: nowadays it's just the PS4
<zyga> Son_Goku: star wars battlefront for my son and lots of gentle games for my daughter (she adores flower)
<zyga> Son_Goku: they played zeldas but still too challenging for my son (he hates reading)
<Son_Goku> I usually bring my 3DS with me wherever I go
<Son_Goku> but this time around, I'll be able to bring a real console too :D
<zyga> ha, indeed :)
<zyga> Son_Goku: what do you plan to do after you finish zelda
<zyga> Son_Goku: with each new console lack of games is a risk
<Son_Goku> well, I have another game on the way, it just isn't here yet :)
<zyga> Son_Goku: and nintendo and shun-3rd-party approach is an extra factor
<Son_Goku> they've done the opposite this time
<Son_Goku> even freaking Skyrim is going to be on the Switch
<zyga> Son_Goku: well but skyrim is ooold
<Son_Goku> that's not the point
<zyga> Son_Goku: and I played it years ago after getting it for 10 euro
<Son_Goku> it's a third party vendor who historically doesn't do Nintendo
<zyga> Son_Goku: my point is that unless they bring *new* stuff 3rd party is not that fun (spend 60 to play skyrim)
<zyga> Son_Goku: I hope you are right :)
<Son_Goku> but regardless, there's still a huge catalog of Nintendo games to release too
<zyga> Son_Goku: well, but for adults most are nooooot that fun
<zyga> Son_Goku: I love mario
<zyga> Son_Goku: but what else is there
<Son_Goku> I'd like to consider myself an "Adult(TM)"
<zyga> AFON
<zyga> adult fan of nintendo
<zyga> ;D
<Son_Goku> I find the Donkey Kong stuff fun, the Sonic games coming are also looking to be quite good
<Son_Goku> though Sonic is SEGA, not Nintendo
<zyga> isn't sega done and a part of EA now?
<Son_Goku> they're still owned by Sega-Sammy Holdings
<Son_Goku> they acquired Technosoft last year
<zyga> Son_Goku: I'd love to see some new IP show up, something fres
<zyga> fresh*
<zyga> not another mario/zelda/metroid spin
<Son_Goku> oh, Splatoon is very fun
<zyga> or open switch to indie games
<Son_Goku> oh you didn't hear?
<Son_Goku> Switch is actually going to be opening to indie games
<Son_Goku> http://indieobscura.com/article/817/confirmed-nintendo-switch-indie-game-lineup
<Son_Goku> I actually ordered Has-Been Heroes
<zyga> mmm, interesting
<Son_Goku> more details on the "Switch": http://www.theverge.com/2017/3/1/14777672/nintendo-switch-indie-games-releases
<zyga> so back to licenses
<Son_Goku> hm?
<zyga> Son_Goku: would you pay for a game on Linux?
<zyga> Son_Goku: (say inside a snap as that's the only format that is open for any publisher and has a payment system)
<Son_Goku> I pay for Linux games quite often, actually
<Son_Goku> but portability is a huge problem
<Son_Goku> frankly, I would not today with snap
<Son_Goku> and as a game dev, I don't even like snapping my game right now
<Son_Goku> admittedly, my game is freely available and open source
<Son_Goku> but still
<zyga> Son_Goku: what risks or issues do you see?
<Son_Goku> well, the main issue is that custom hardware and GL issues still plague it
<Son_Goku> custom game pads are a pain to make work normally anyway
<Son_Goku> but this adds another level of pain
<zyga> Son_Goku: I think we know what the solution is
<zyga> Son_Goku: but needs some focus to get there
<zyga> Son_Goku: stuff like proprietary 3D stacks need to become snaps so there's no ABI issue
<Son_Goku> one of my friends who works on a game engine project was approached about snapping it, and he didn't feel like it was worth it
<Son_Goku> he had two big problems with it:
<Son_Goku> 1. He despises developing on the Ubuntu platform
<Son_Goku> 2. Most of the things he needs to work don't currently in snaps
<zyga> Son_Goku: what are the 2. things that don't work?
<Son_Goku> well, there didn't seem to be an easy or obvious way to link game content to the engine runtime snap
<zyga> Son_Goku: (even in devmode?)
<zyga> Son_Goku: ah so he wants a two-snap solution?
<Son_Goku> and of course, custom hardware support is basically nil
<Son_Goku> for developing games, that's absolutely critical to have
<zyga> Son_Goku: any reason to pursue that today? one snap approach is far better for now
<zyga> what custom hardware?
<zyga> controllers?
<zyga> or GPUs?
<Son_Goku> controllers, GPUs, midi devices, etc.
<zyga> Son_Goku: I'm surprised because I suspect that most things that people play would run in snaps without issues
<Son_Goku> if you need a midi device, you're SOL
<zyga> Son_Goku: controllers = USB interface and it's all solved (probably 5 controllers covers 99% of the planet)
<zyga> Son_Goku: midi = dead (for gaming)
<zyga> Son_Goku: and GPU is well known and solvable
<Son_Goku> for music composition, it's not
<zyga> Son_Goku: we're not talking about niche music making stuff but games
<Son_Goku> game composers do it too
<Son_Goku> especially for those "retro" games
<Son_Goku> you know what I'm talking about
<zyga> but those don't use midi to play it in the end
<Son_Goku> no they don't
<zyga> nobody has midi hardware in their device
<zyga> so for game making
<zyga> fine use whatever
<zyga> after that there's no midi issue
<zyga> so?
<Son_Goku> the engine is a game development toolkit too
<Son_Goku> engine includes runtime plus editor and manipulator
<zyga> Son_Goku: fine, that can be shipped in whatever form
<zyga> Son_Goku: after the game is done
<Son_Goku> yes, yes
<Son_Goku> but he was approached on making the engine tools snapped too
 * Son_Goku shrugs
<zyga> Son_Goku: is there an actual issue?
<zyga> Son_Goku: what is the actual issue then?
<zyga> Son_Goku: it's not midi
<zyga> Son_Goku: ah, well, that's another story
<zyga> Son_Goku: I think that's really phase 2
<zyga> Son_Goku: phase one is a format for games to sell and play anywhere
<Son_Goku> of course, when the engine tooling renders the output game, it's not using midi
<Son_Goku> that would be stupid
<zyga> Son_Goku: one thing gaming sucks about is cross-buy
<zyga> Son_Goku: I got stardew valley on gog
<zyga> Son_Goku: I dont want to re-buy on other platforms
<Son_Goku> yeah
<zyga> Son_Goku: gog<->steam connect is the step in that direction
<zyga> Son_Goku: I'd love to see gog<->snap as well if they can do it
<zyga> Son_Goku: I think it could be a boom for snaps
<zyga> Son_Goku: seed your snap library with your gog games
<zyga> Son_Goku: show that it works
<Son_Goku> that'd be hard though
<zyga> Son_Goku: show that it is convenient
<zyga> Son_Goku: why?
<Son_Goku> because the snap store API is unstable
<zyga> Son_Goku: and who would be affected by that?
<Son_Goku> gogs mainly
<Son_Goku> no one wants to deal with that shit
<zyga> Son_Goku: there's no api for something like connect, if there was anything like this happening that API would be stable
<zyga> Son_Goku: besides, it is a specialized api that only two people would use
<zyga> Son_Goku: (gog, humble bundle, maybe steam)
<zyga> Son_Goku: as snap developer or user nobody would see that
<zyga> Son_Goku: I think it's compelling
<Son_Goku> it is compelling
<Son_Goku> as long no one breaks it :)
<zyga> Son_Goku: I think after you "own" it it's not going to be broken even if the connection part is disabled for some reason
<zyga> Son_Goku: I should try to snap that doom game
<zyga> Son_Goku: doom == dosbox + data
<Son_Goku> that game would be relatively easy to do
<zyga> but first...
<zyga> spring cleaning
<mup> PR snapd#3080 closed: interfaces: remove old API <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3080>
<mup> PR snapd#3068 closed: boot: log error in KernelOrOsRebootRequired <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3068>
#snappy 2017-03-26
<riccardo> Hello
<riccardo> I keep getting this Run configure hook of "core" snap if present
<riccardo> It is an infinite wating
<qengho> riccardo: I think that bug is known and should be fixed, already or soon.
<chani> hello guys i am having trouble figuring out how to add my custom script to a snap
<chani> can anyone help please?
<chani> basically i want to build a webserver snap which will update the website at regular intervals by pulling the website source code from github
<chani> so i have added git and apache2 to my part with plugin as nil
<chani> now i want to write a shell script which does the git pull and some other sub routins at regular intervals
<chani> so where do i write the script and include it
<ogra_> just put it somewhere next to the snapcraft.yaml and use the dump plugin to put it in place
<ogra_> chani, https://github.com/snapcore/snapcraft/blob/master/demos/webcam-webui/snap/snapcraft.yaml ... look at the glue part at the bottom (and indeed the apps section)
<ogra_> that copies the webcam-webui script from the toplevel source tree dir to bin/webcam-webui inside the snap package
<ogra_> (and runs it as a daemon script as defined in the apps section)
<chani> thanks a lot guys
<chani> *ogra
<ogra_> :)
#snappy 2018-03-19
 * Son_Goku waves at sabdfl 
<Son_Goku> hey sabdfl
<Son_Goku> how are you doing this evening?
<mborzecki> morning
<zyga> good morning!
<zyga> I found a silly reason for the symlink issue, there were two checks and I only patched one last week
<mborzecki> zyga: hey
<zyga> I noticed late on Friday and started fixing it but stopped because it has huge diff on unit tests
<zyga> I will finish that now quickly
<mborzecki> zyga: that's good news
<zyga> yeah, it's from and older part of the code that existed before we had any creation code
<zyga> it just checked if things exist and are of the right type
<mborzecki> zyga: mhm, ping me if you need a review
<mborzecki> zyga: in other news, there's another user reporting issues with nvidia on arch with new drivers, i've ordered gt1030 card just now, so i'll probably take a look tomorrow or on wednesday
<zyga> yeah, I saw that
<zyga> excellent!
<zyga> I didn't knew 1030s existed, how much was it?
<mborzecki> ~340pln/80eur
<mborzecki> and it's a 30W card
<zyga> that's pretty neat!
<zyga> and it will be on modern drivers
<zyga> thank you for doing that, it will definitely help the team
<kalikiana> good morning, snaooy
<pstolowski|afk> morning!
<mborzecki> kalikiana: pstolowski: morning guys
<mborzecki> zyga: what's the plan with #4509?
<mup> PR #4509: interfaces/builtin: add support for software-watchdog interface <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4509>
<mborzecki> damn, not that one
<zyga> oh?
<mborzecki> zyga: #4781
<mup> PR #4781: wrappers: refactor desktop file sanitizer to support autostart files <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4781>
<mborzecki> zyga: must by my unlycky day, not that one obviously :P
<mborzecki> zyga: #4571
<mup> PR #4571: data, cmd, packaging: use autotools to generate artifacts under data <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4571>
<zyga> haha
<zyga> looking again :)
<zyga> I _think_ the desire is to drop autotools
<zyga> so for now this can stay as refrence but we probably won't land it
<mborzecki> ok
<mborzecki> hm so hand written makefiles then?
<mborzecki> zyga: i can look into it, i'm not super busy with anything atm anyway
<zyga> yeah, go for it!
<zyga> I'm a big fan of pure make
<zyga> so I'll gladly review
<zyga> ok, I will do two patches
<zyga> one that is tiny and can land quickly
<zyga> and one that removes obsolete code that can land later without rushes
<zyga> just running tests now
<zyga> a few lines changed, vs what I got last Fridat
<zyga> (100s, probably close to 1K)
<mup> PR snapd#4866 opened: tests: make autopkgtest tests more targeted <Created by mvo5> <https://github.com/snapcore/snapd/pull/4866>
<zyga> mborzecki, mvo: https://github.com/snapcore/snapd/pull/4867
<mup> PR #4867: cmd/snap-update-ns: don't fail on existing symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4867>
<zyga> that's the symlink part of the bug
<zyga> fingers crossed
<mup> PR snapd#4867 opened: cmd/snap-update-ns: don't fail on existing symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4867>
<zyga> now refocusing on not writing to places  that leak to host filesystems
<mup> PR snapd#4861 closed: store: reorg auth refresh  (2.32) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4861>
<mup> PR snapd#4862 closed: store: cleanup test naming, dropping remoteRepo and UbuntuStore(Repository)? references (2.32) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4862>
<mup> PR snapd#4865 closed: many: propagate contexts enough to be able to mark store operations done from the Ensure loop (2.32) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4865>
<Chipaca> good morning, all!
<mvo> hey Chipaca ! good morning
<Chipaca> that ! feels like a gnarly binop
<Chipaca> mvo: hiya :-) how was your friday?
<pstolowski> morning Chipaca !
<Chipaca> pstolowski: :-)
<mvo> Chipaca: mostly good, about 1h of small panic because of something that looked like a serious snapd bug but turned out to be a glich in the data
<mvo> hey pstolowski
<Chipaca> mvo: no, no, how was your _friday_
<pstolowski> mvo: o/
<Chipaca> mvo: that thing where you _weren't_ working
<mvo> Chipaca: *cough*
<mborzecki> Chipaca: hey, thanks for benchmarking the text wrapper thing, must have been a lot of fun :)
<Chipaca> mborzecki: I learned some stuff :-)
<mborzecki> Chipaca: out of curiosity, have you tried the profiler? :P
<Chipaca> mborzecki: the web clicky thing? not on this code
<Chipaca> mborzecki: on other code yes
<mborzecki> Chipaca: ah, ok, it's neat though, like how it always amazes non-go guys during presentations
<Chipaca> mborzecki: for this I used the profile flags on go test, and got to a version that was doing over 100MB/s with 0 allocs
<Chipaca> all rather academic but fun
<Chipaca> (academic because in real use it's terminal i/o so unless you're on a non-xft xterm, it's got no way of hitting 100MB/s :-) )
<Chipaca> also academic because most descriptions shouldn't hit a megabyte :-)
<mborzecki> haha nice :)
<mborzecki> zyga: mvo: systemCoreSnapUnalias?
<zyga> mmm
<zyga> well, +1 because bikeshed :)
<mborzecki> hahah
<mborzecki> well, renamed & pushed, too late now
<mvo> mborzecki: yeah, fine with me
<Chipaca> zyga: FYI snapped things don't work with nvidia prime in intel mode
<mvo> (also +1 for zyga )
<mborzecki> zyga: mvo: thank you for the reviews :)
<mvo> yw
<zyga> Chipaca: can you please tell me and mborzecki more?
<mborzecki> Chipaca: that PRIME?
<Chipaca> mborzecki: zyga: have laptop with nvidia prime, which is not a condom nor a subscription service for quicker delivery
<Chipaca> mborzecki: zyga: non-snapped 3d apps work fine in both modes, although of course faster in nvidia mode
<Chipaca> mborzecki: zyga: snapped 3d apps fail to work in intel mode
<mvo> Chipaca: what is the error message?
<Chipaca> minecraft: https://pastebin.ubuntu.com/p/7pxkxkVVTK/
<Chipaca> although, hold on, ohmygiraffe works
<Chipaca> is that 3d?
<mborzecki> Chipaca: it has a plug for opengl
<Chipaca> hmm, hmm. so maybe the minecraft snap is buggy, and not our 3d support
<mborzecki> Chipaca: can you `MESA_DEBUG=1 snap run ohmygiraffe` and see what's in the logs?
<Chipaca> mborzecki: in which logs? on the terminal I just get âMesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailableâ
<mborzecki> Chipaca: and how about LIBGL_DEBUG=verbose ?
<Chipaca> mborzecki: https://pastebin.ubuntu.com/p/WDT3TDpNcj/
<mborzecki> Chipaca: looks like it's using intel/mesa now
<Chipaca> mborzecki: yes, it's in intel mode
<Chipaca> the snapped minecraft crashes in this mode (regular minecraft doesn't)
<mborzecki> Chipaca: can you also try some other snap, say supertuxkart
<Chipaca> yes
<zyga> Chipaca: it would be interesting to compare an app that crashes inside and outside the snap
<zyga> is this on xenial btw?
<Chipaca> zyga: it doesn't crash outside the snap :-)
<zyga> right
<zyga> so the debug log of that
<zyga> and where it differs is a hint
<Chipaca> zyga: yes, xenial, but xenial as factory-installed
<mborzecki> btw. is glxinfo included in any snap?
<Chipaca> glxinfo in nvidia mode here isn't happy, fwiw
<Chipaca> something about  bad libGL version
<Chipaca> supertuxkart crashes
<zyga> I think we need to support glvnd natively and remove bundled libraries from snaps
<mborzecki> Chipaca: woo, badly? backtrace?
<Chipaca> hmmm, somehow supertuxkart loaded the nvrm module
<Chipaca> weird
<Chipaca> mborzecki: https://pastebin.ubuntu.com/p/6x45s6RNnH/
<Chipaca> mborzecki: no backtrace
<mborzecki> Chipaca: `[warn   ] [IrrDriver Temp Logger]: Level 2: Could not create GLX rendering context`. same as minecraft
<mup> PR snapd#4866 closed: tests: make autopkgtest tests more targeted <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4866>
<vidal72[m]> hi, I'm trying to run snap on Archlinux with apparmor but I get denial when trying to start an app AVC apparmor="DENIED" operation="open" profile="snap.qownnotes.qownnotes" name="/var/lib/snapd/snap/qownnotes/906/meta/snap.yaml" pid=32283 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<zyga> https://www.irccloud.com/pastebin/14klzXuE/
<zyga> vidal72[m]: did you build apparmor enabled kernel?
<zyga> mborzecki: ^
<vidal72[m]> yes, I use apparmor for a long time, this denial comes from apparmor
<vidal72[m]> here is appamror profile for this app https://paste.ubuntu.com/p/zwB4Yb57nB/
<zyga> which kernel are you on now?
<vidal72[m]> 4.16-rc6
<zyga> interesting
<pstolowski> zyga: where do you see this error you pasted with https://www.irccloud.com/pastebin/14klzXuE/ ?
<zyga> so there are permissions to m snap-exec
<zyga> but not to x it
<zyga> pstolowski: in my bionic box when running run-checks.sh
<zyga> pstolowski: run-checks.sh --unit, to be precise
<zyga> vidal72[m]: if you edit the profile and replace line 194 with
<zyga>  /usr/lib/snapd/snap-exec mr,
<zyga> and reload the profile with apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.qownnotes.qownnotes
<zyga> does it fix the issue?
<pstolowski> that error looks like a copycat of a problem with tests that I fixed a few weeks ago; we were trying to lunch zenity/kdialog for real in unit tests
<vidal72[m]> zyga: no, same message
<zyga> vidal72[m]: could you please publish your kernel config and tree somewhere?
<zyga> I cannot answer why this happens instantly
<mup> PR snapd#4868 opened: [WIP] secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868>
<jjohansen> zyga: did you get a chance to try the patch. So far it seems to be working good for me, if its good for you throw a comment on the bug and I'll get it sent into the the kt
<vidal72[m]> zyga: here's my config https://paste.ubuntu.com/p/5rw2Fxxsps/
<zyga> I read the patch and built it but I didn't do any testing yet, I will have the results for my tomorrow, sorry I had a busy weekend
<zyga> I'll update the bug today
<zyga> vidal72[m]: thank you, can you please open a thread on forum.snapcraft.io with the basic information and your kernel config and git tree reference
<zyga> and I will explore that this week
<jjohansen> zyga: np, and no hurry I just don't want to let it get dropped in the tsunami of other issues, so if you don't get to it this week I will poke you again next
<vidal72[m]> zyga: ok
<zyga> jjohansen: understood, thank you very much for the patch
<zyga> I was looking for some kind of race condition but now I understand how it works better
<zyga> do'h
<zyga> I found a very embarrasing bug
<jjohansen> zyga: yeah, well it seems that when I did the convertion the racy update of i_link got dropped. My first few attempts at fixing this involved locking and an rcu callback to free the i_link value, needless to say I wasn't happy with those
<zyga> the bug exsits because I'm not using something I wrote for this specific purpose
<zyga> (different bug, something I realized on friday and debugged just now)
<mborzecki> i've uplaoded a snap for debugging issues with graphics, using this snapcraft.yaml https://github.com/bboozzoo/graphics-debug-tools-snap/blob/master/snapcraft.yaml once I requested x11 and opengl it got stuck in manual review, the reason being lack of *.desktop file :/ (there'll hardly be any for cli tools)
<Chipaca> zyga: when is the fix for the DENIED on actions_avail happening?
<zyga> I didn't discuss this with jdstrand yet, I'm not sure what is the right way
<zyga> since jamie is back this week it will be on my plate to ask
<mvo> mborzecki: I can help
<mvo> mborzecki: its in
<mborzecki> mvo: thank you
<mvo> xnox, mwhudson the autopkgtests run on s390x shows some unusal errors and panics (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/s/snapd/20180319_102843_5bafc@/log.gz) - are there known issues with golang1.10 on s390x ?
<zyga> mvo: https://github.com/snapcore/snapd/pull/4867 updated with unit tests and green
<mup> PR #4867: cmd/snap-update-ns: don't fail on existing symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4867>
<zyga> +1 to merge?
<mvo> zyga: yes
<mvo> zyga: thanks for adding the test
<cachio> zyga, hey, could yo uplease take a look to #4835?
<mup> PR #4835: tests: add bionic system to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4835>
<cachio> zyga, it is almost ready
<zyga> hmmm
<zyga> the extra code for stoppping the stopping of the mount unit is worrying, why do we need it?
<cachio> zyga, this is mvo
<cachio> zyga, it is to deal with a problem that comes from 2.31
<zyga> Should that be done by snapd instead so that is not just in test code
<cachio> zyga, we were researching but the only way to fix that was mounting again the units after install
<zyga> mvo: can you explain the problem please?
<mvo> zyga: sure, so 2.31.X has the snap.mount unit. but 2.32 does not have it anymore. this means that on upgrade dpkg will run the "prerm" of the *old* 2.31.X deb. The default is to stop mount units there. this leads to all childs being unmounted
<mvo> zyga: because it is the old prerm we cannot prevent this umount
<mvo> zyga: I mean, that would be the ideal solution, do something to prevent this and just leave it running
<mvo> zyga: the alternative is to undo what it was doing
<zyga> right, I understand the prerm issue
<zyga> so the question is this; is this a real issue that needs to be dealt in more than just test code
<zyga> ah
<zyga> sorry
<zyga> I'm blind, this is in .postinst
<zyga> so it's all fine
<zyga> I read this as somthing in prepare-restore.sh
<zyga> +1 :-)
<mvo> zyga: ok
<mvo> zyga: fwiw, I'm *not* happy with this code
<mvo> zyga: and it only affects bionic and -proposed users
<mvo> zyga: so the alternative might be to just ask them to reboot. but at the same time, the fixup will also only run for these users so even if the code is buggy for some its not worse than before (I think)
 * zyga whispers "it will be there forever" to mvo's ear 
 * mvo drops into a coma
<mvo> cachio: 2.31.2 got accepted into -proposed - if you have time (not super urgent) please do the sru validation
<cachio> mvo, sure
<cachio> zyga, so, is it ok to merge bionic?
<zyga> doing some comments there
<zyga> hold on please
<cachio> mvo, beta validation is ready
<cachio> OI am waiting for confirmation from qa team
<zyga> cachio, mvo: 4835 reviewed
<cachio> zyga, thanks
<mvo> cachio: cool, I will prepare 2.32(-final) then and focus on test fixes etc
<mvo> zyga: anything that needs to land from your side in 2.32 still?
<zyga> yes
<zyga> two PRs I'm afraid
<zyga> and everything that is tagged
<zyga> note that I did _not_ cherry pick anything yet
<zyga> so I'm afraid still a few PRs to go
<zyga> mvo: https://github.com/snapcore/snapd/pull/4867 is one that's ready to land
<mup> PR #4867: cmd/snap-update-ns: don't fail on existing symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4867>
<zyga> mvo: https://github.com/snapcore/snapd/pull/4765 is a bigger one from the sprint
<mup> PR #4765: interfaces: harden snap-update-ns profile <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4765>
<zyga> mvo: and two more (small) that I'm brewing
<mup> PR snapd#4867 closed: cmd/snap-update-ns: don't fail on existing symlinks <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4867>
<zyga> mvo: I will try to prepare them both by 14:00 today
<zyga> and after all the fixes are in master I will look at backport PRs
<zyga> mvo: does that sound acceptable?
<mvo> zyga: sounds good, lets talk during the standup.
<zyga> ok
 * cachio afk
<xnox> mvo, looks, i have no clue.
<mvo> xnox: I think I asked before, but is there a porter box for s390x?
<xnox> mvo, yes
<vidal72[m]> zyga: I managed to fix it by changing @{INSTALL_DIR}="/snap" to @{INSTALL_DIR}="/{,var/lib/snapd/}snap" but now I have
<vidal72[m]> ANOM_ABEND auid=1000 uid=1000 gid=100 ses=1 pid=2319 comm="QOwnNotes" exe="/snap/qownnotes/906/usr/bin/QOwnNotes" sig=6 res=1
<zyga> vidal72[m]: I have never seen such a message (ANOM_ABEND)
<pbek> vidal72[m]: if nothing helps you can use one of the many other install methods of QOwnNotes. ;) http://www.qownnotes.org/installation
<vidal72[m]> zyga: "Triggered when a processes ends abnormally (with a signal that could cause a core dump, if enabled)."
<zyga> I see
<zyga> did you get any other denial?
<zyga> perhaps it was killed by seccomp
<zyga> those would be logged by the audit logger
<zyga> vidal72[m]: I think the install dir is a clear omission on our end,
<zyga> do other snaps work?
<vidal72[m]> zyga: no, only this single message
<vidal72[m]> zyga: I didn't tried other as I'm strugling to make this one work (first which I tried), I have some other small fixes to usr.lib.snapd.snap-confine
<zyga> vidal72[m]: please send a PR if you can
<zyga> try the hello snap
<zyga> it's very basic
<Son_Goku> mvo, btw, zyga has access to the Fedora test/porter boxes if you want to work on quirky things with ppc and arm: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
<vidal72[m]> pbek: thx, I can succesfully use qownotes, just not as snap
<Son_Goku> mvo, and zyga can probably get access to Fedora s390x boxes by requesting them in #fedora-s390x
<zyga> thank you Son_Goku
<zyga> I _hope_ we won't have to use them :)
<zyga> but it's good that we have them if we have to
<zyga> ok, one more bug fixed, now looking at the last one
<zyga> actually, let's break for 5
<zyga> back.hurt()
<mup> PR snapcraft#2005 closed: pluginhandler: special case go patchelf failures for classic confinement <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2005>
<mup> PR snapd#4869 opened: cmd/snap-update-ns: use x-snapd.{synthetic,needed-by} in practice <Created by zyga> <https://github.com/snapcore/snapd/pull/4869>
 * Chipaca -> lunch
<Chipaca> zyga: :-((((
<zyga> what's wrong John?
<Chipaca> zyga: take more care of your back
<zyga> yeah, I should take a walk
<mup> PR snapcraft#2006 closed: many: use packaging logic to get patchelf <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2006>
<mup> PR snapd#4870 opened: tests: drop old debug code <Created by zyga> <https://github.com/snapcore/snapd/pull/4870>
 * Chipaca -> lunch-making
<mup> PR snapcraft#2008 opened: Release changelog for 2.40 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2008>
<vidal72[m]> zyga: hello-world works, in qownnotes the error is: snap run qownnotes
<vidal72[m]> Fatal: QXcbConnection: Could not connect to display :0 ((null):0, (null))
<vidal72[m]> [1]    5648 abort (core dumped)  snap run qownnotes
<vidal72[m]> I use xorg
<mup> PR snapd#4850 closed: many: fix shellcheck warnings in bionic <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4850>
<zyga> interesting, that may hint at a different issue now
<zyga> mborzecki: can you run qownnotes on your arch system?
<mborzecki> tseliot: installing
<mborzecki> damn, wrong person :P
<mborzecki> zyga: installing
<zyga> pstolowski, cachio: standup time :)
<mup> PR snapd#4835 closed: tests: add bionic system to google backend <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4835>
<mup> PR snapd#4871 opened: cmd/snap-confine: fix Archlinux compatibility <Created by Erick555> <https://github.com/snapcore/snapd/pull/4871>
<vidal72[m]> zyga: I created PR with fixes for usr.lib.snapd.snap-confine on Arch ^^
<zyga> vidal72[m]: thank you, I will look at them in a moment
<zyga> vidal72[m]: added one comment
<vidal72[m]> zyga: I answered
<vidal72[m]> zyga: I'm talking about this: https://github.com/torvalds/linux/commit/2a4c22426955d4fc04069811997b7390c0fb858e
<zyga> ah, that's very interesting
<zyga> yeah, I think your change looks good
<zyga> I asked a colleague for a 2nd review
<zyga> vidal72[m]: can you please sign the CLA https://www.ubuntu.com/legal/contributors
<vidal72[m]> zyga: I tried but it wants me to put something in "Please add the Canonical Project Manager or contact" field
 * kalikiana lunch
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/4832
<mup> PR #4832: tests: move fedora 27 to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832>
<zyga> mvo: I'll take a dog+lunch break now and will be back to fix bugs after that
<mborzecki> off to pick up the kids from school and the dog from a vet
<jdstrand> abeato: added to the list. note, just got back from holiday so going through backlog
<mup> PR snapd#4870 closed: tests: drop old debug code <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4870>
<zyga> jdstrand: good morning, welcome back
<jdstrand> hey zyga, thanks :)
<jamesh> jdstrand, zyga: I'm heading to bed, but I pushed up https://github.com/snapcore/snapd/pull/4868 based on the discussions at the sprint
<mup> PR #4868: [WIP] secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868>
<jamesh> it'
<jamesh> s got good test coverage, but the question is whether it satisfies the security concerns
<zyga> jamesh: I saw, thank you for starting and pushing that work!
<zyga> jamesh: I _suspect_ so, I'll discuss this with jdstrand
<mvo> mwhudson: just fyi - https://github.com/golang/go/issues/24449 - there is a s390x issue with go1.10
<xnox> mvo, so 1.9 is still in bionic, and in main. can you revert to build-depend on 1.9 and/or use 1.9?
<mvo> xnox: I will just disable coverage on s390x for now and then see what upstream is doing
<xnox> mvo, ok.
<mvo> xnox: but yeah, going to 1.9 might be an option if there is no upstream reaction
<mup> PR snapd#4872 opened: tests: add workaround for s390x failure <Created by mvo5> <https://github.com/snapcore/snapd/pull/4872>
<pedronis> mvo: when you have a moment could you look at #4829 again,  as I said in my comment to your comment IÂ have to generalize a bit
<mup> PR #4829: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store <Created by pedronis> <https://github.com/snapcore/snapd/pull/4829>
<zyga> sigh,
<zyga> this last error is just annoying
<zyga> it's not hard but not easy either
<cyphermox> ogra_: can I haz help to validate https://bugs.launchpad.net/netplan/+bug/1741910 ?
<mup> Bug #1741910: ath6kl_sdio does not support unbinding <verification-needed-xenial> <netplan:Fix Committed by cyphermox> <nplan (Ubuntu):Fix Released> <nplan (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1741910>
<cyphermox> (I don't have any ath6kl_sdio here)
<ogra_> how dare you !
<ogra_> :)
<ogra_> szre, will test :)
<ogra_> *sure even
<cyphermox> ta
<ogra_> cyphermox, hmm, i can only test xenial, we do not have non-core images for any of the devices (and core is 16.04 only atm)
<mvo> pedronis: I saw this, do you mean you want to keep the name and (maybe) consider changing it later?
<pedronis> mvo: no, I changed things more, see PR
<mvo> pedronis: aha, nevermind, just saw it, sorry
<vidal72[m]> zyga: should I make PR which changes default @{INSTALL_DIR}="/snap" to  @{INSTALL_DIR}="/{,var/lib/snapd/}snap" ? (not sure where it's set)
<mvo> pedronis: nice, I like the diff
<cyphermox> ogra_: only needed on xenial
<ogra_> ok
<zyga> vidal72[m]: yes, feel free to push that to this PR or open a new one
<zyga> vidal72[m]: and thank you for contributing! I'm super happy you are an arch user that cares about apparmor
<cyphermox> zyga: vidal72[m]: nice, someone mentioned that to me as well yesterday for Fedora
<vidal72[m]> Probably the only one who uses apparmor with snap...
<zyga> vidal72[m]: I'm curious if there's any movement inside arch to enable apparmor in the distribution
<zyga> did you have to package apparmor userspace tools or are those available already?
<vidal72[m]> zyga: don't think so, userspace tools are avalaible in AUR (unofficial user repository)
<zyga> vidal72[m]: I see
<Pharaoh_Atem> zyga: generally speaking, Arch doesn't want audit enabled in the main kernel
<zyga> well, it's good to have you, welcome :)
<Pharaoh_Atem> the originally had SELinux enabled (with no policy), but the arch devs disliked audit being enabled
<Pharaoh_Atem> the official hardened project prefers SELinux as well
<vidal72[m]> zyga: I see it's defined in https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/template_vars.go#L38 and https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/backend_test.go#L387 but I don't know how
<vidal72[m]> "/{,var/lib/snapd/}snap" should be expressed in go
<mup> PR # closed: snapd#3963, snapd#4349, snapd#4358, snapd#4369, snapd#4387, snapd#4399, snapd#4416, snapd#4443, snapd#4497, snapd#4504, snapd#4509, snapd#4510, snapd#4538, snapd#4545, snapd#4551, snapd#4562, snapd#4571, snapd#4578, snapd#4588, snapd#4600, snapd#4672, snapd#4682, snapd#4700,
<mup> snapd#4721, snapd#4750, snapd#4765, snapd#4767, snapd#4771, snapd#4772, snapd#4778, snapd#4781, snapd#4790, snapd#4805, snapd#4816, snapd#4819, snapd#4829, snapd#4832, snapd#4833,
<mup> snapd#4840, snapd#4841, snapd#4842, snapd#4843, snapd#4844, snapd#4845, snapd#4854, snapd#4858, snapd#4863, snapd#4864, snapd#4868, snapd#4869, snapd#4871, snapd#4872
<zyga> hmmm
<zyga> this is actually a bit more interesting now, that I think of it
<zyga> when starting a snap application we do a bind mount from /var/lib/snapd/snap to /snap
<mup> PR # opened: snapd#3963, snapd#4349, snapd#4358, snapd#4369, snapd#4387, snapd#4399, snapd#4416, snapd#4443, snapd#4497, snapd#4504, snapd#4509, snapd#4510, snapd#4538, snapd#4545, snapd#4551, snapd#4562, snapd#4571, snapd#4578, snapd#4588, snapd#4600, snapd#4672, snapd#4682, snapd#4700,
<mup> snapd#4721, snapd#4750, snapd#4765, snapd#4767, snapd#4771, snapd#4772, snapd#4778, snapd#4781, snapd#4790, snapd#4805, snapd#4816, snapd#4819, snapd#4829, snapd#4832, snapd#4833,
<mup> snapd#4840, snapd#4841, snapd#4842, snapd#4843, snapd#4844, snapd#4845, snapd#4854, snapd#4858, snapd#4863, snapd#4864, snapd#4868, snapd#4869, snapd#4871, snapd#4872
<zyga> and apparmor should really be conifing /snap/whatever and never care about that other path
<zyga> so whatever is going on here, makes things break elsewhere so that this happens
<zyga> vidal72[m]: please don't make this change yet
<Pharaoh_Atem> whoa
<Pharaoh_Atem> wtf
<zyga> Pharaoh_Atem: mup restarted / github broke
<vidal72[m]> zyga: ok
<cyphermox> zyga: I think the point was that the bind mount could be elsewhere than /snap, such as /var/lib/snapd/snap-mount (for example)
<cyphermox> zyga: just so that other distros who really insist on FHS can be happy.
<cyphermox> (but yeah, it needs a bit of thought)
<Pharaoh_Atem> right, for example /var/lib/snapd/snap is where stuff is in Fedora, Arch, etc.
<zyga> cyphermox: yes it can but before the application starts and before the application apparmor profile takes over we relocate that to /snap
<zyga> so it's not supposed to happen this way
<Pharaoh_Atem> yeah, but that doesn't happen for classically confined stuff
<Pharaoh_Atem> you don't do internal relocation
<zyga> yes, but is that snap classically confined?
<zyga> vidal72[m]: is that snap classically confined (snap info will know)
<zyga> I strongly doubt that becasue classic template doesn't care about INSTALL PATH
<zyga> or INSTALL_DIR (sorry)
<vidal72[m]> zyga: I found that it needs at first /var/lib/snapd/snap/qownnotes/906/meta/snap.yaml and then /snap/qownnotes/906/bin/desktop-launch so both /snap snd /var/lib/snapd/snap are needed
<vidal72[m]> it uses strict sandbox
<vidal72[m]> I don't have /snap top direcory on my system
<zyga> vidal72[m]: I know but that directory exists later at runitme
<zyga> vidal72[m]: if it ever sees /var/lib/snapd/snap then the bug is elsewhere
<zyga> vidal72[m]: please try this: snap run --shell hello
<zyga> then inside that shell run ls /snap
<zyga> it's there at runtime even if your host system doesn't have it
<cyphermox> zyga: isn't /snap only created at package install time?
<zyga> cyphermox: no, it's never created
<zyga> it's not in the host at any time
<cyphermox> I disagree.
<zyga> that /snap is really /var/lib/snapd/snap/core/current/snap
<cyphermox> it was clearly in the snapd debian/dirs file, and /snap exists on my system :)
<cyphermox> zyga: are you talking about an ubuntu-core system?
<zyga> no
<zyga> this is true in any system
<zyga> cyphermox: ah, the confusion is that we are talking about the arch package
<zyga> and things are different there because a while ago some arch maintainers decided to opt out of /snap in the package
<cyphermox> right
<cyphermox> Pharaoh_Atem: ^^ maybe you and vidal72[m] should talk
<zyga> vidal72[m]: so to recap, I don't know what happens yet
<zyga> vidal72[m]: but that snap should never need that permission so please don't change that part in template_vars.go
<zyga> cyphermox: I suspect it's either something custom to vidal72[m]'s system or to the new 4.16 kernel
<cyphermox> zyga: I don't need to know, I'm not at all familiar with Arch
<vidal72[m]> zyga: with @{INSTALL_DIR}="/snap" snap run hello-world
<vidal72[m]>  fails as always; with @{INSTALL_DIR}="/{,var/lib/snapd/}snap"  ls /snap fails with: ls: cannot open directory '/snap': Permission denied (blocked by apparmor)
<vidal72[m]> *snap run --shell hello-world
<mvo> hm, is there a way to see when "snap info go" channel edge devel-b61b1d2 was uploaded?
<vidal72[m]> zyga: but /snap dir exist inside shell
<zyga> vidal72[m]: right, that just shows what I meant
<zyga> please open a forum thread to dicuss this so that it's not lost in this IRC chat
 * mvo hugs mwhudson for having up-to-date edge snaps for golang, so helpful 
<pedronis> mvo: ~ on the 19th
<mvo> pedronis: ha! great, so super up-to-date
<mvo> pedronis: thank you
<vidal72[m]> zyga: I do, do you know what's going on with travis faild in https://github.com/snapcore/snapd/pull/4871
<mup> PR #4871: cmd/snap-confine: fix Archlinux compatibility <Created by Erick555> <https://github.com/snapcore/snapd/pull/4871>
<zyga> not yet, let me look
<mvo> pedronis: 4829 is good to go I think, feel free to merge/squash
<mvo> pedronis: same for 4854
<pedronis> mvo: thanks, running some tests for something else and then I'll clicking on things
<mvo> pedronis: ta
<mvo> pedronis: no rush, just wanted to mention it :)
<zyga> vidal72[m]: that's not related to your PR
<zyga> hmm
<mup> PR snapd#4829 closed: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4829>
<mup> PR snapd#4854 closed: devicestate: add DeviceManager.Registered returning a channel closed when the device is known to be registered <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4854>
<zyga> vidal72[m]: restarted tests in your PR, I have never seen that failure, maybe some issue in the recent changes to the testing system
<mup> PR snapd#4873 opened: many: delay classic registration until first store interaction <Created by pedronis> <https://github.com/snapcore/snapd/pull/4873>
<mup> PR snapcraft#2007 closed: catkin plugin: replace python calls in all profile.d scripts <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2007>
<vidal72[m]> zyga: it failed again with similiar error :)
<niemeyer> cachio: spread#53 looks pretty reasonable.. added some comments
<mup> PR spread#53: Check uptime on system to determine if reboot was done <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/53>
<cachio> niemeyer, nice, I'll take a look
<cachio> thanks
<vidal72[m]> is it normal that gnome app (gnome-mines) hasn't x11 slot?
<vidal72[m]> zyga: wow I found what was breaking snap apps - I had disabled Xorg abstract socket!!!
<zyga> vidal72[m]: where did you disable that?
<vidal72[m]> I run xorg from sddm with "-nolisten local" config option
<zyga> ah
<zyga> :-)
<vidal72[m]> zyga: i opened topic about @{INSTALL_DIR} issue: https://forum.snapcraft.io/t/apparmor-issues-with-default-install-dir/4568
<zyga> thank you vidal72[m], looking
<mup> PR snapcraft#2009 opened: Base check for classic <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2009>
<Lin-Buo-Ren> https://forum.snapcraft.io/t/documentation-issue-regarding-the-setup-lxd-section-part-of-get-started-with-snapcraft/4467
<ahasenack> hi,
<ahasenack> somehow I got a snap with no version number
<ahasenack> and snapd seems to not like it
<ahasenack> Mar 19 17:09:12 nsnx snapd[8171]: 2018/03/19 17:09:12.233531 helpers.go:110: invalid snap version: cannot be empty
<ahasenack> root@nsnx:~# snap list --all
<ahasenack> error: cannot list local snaps! cannot find installed snap "core" at revision 4110
<ahasenack> are these two things relateD?
<ahasenack> just "snap list" works, and shows the unversioned snap
<jnamldk> when i run keepassx snappy, i get this error "cannot create lock directory /run/snapd/lock: Permission denied";  seems AppArmor fails to create the desired paths, any workaroud?
<nacc> niemeyer: snapd in bionic just broke all my snaps :(
<nacc> $ git-ubuntu --help
<nacc> internal error, please report: running "git-ubuntu" failed: cannot find installed snap "git-ubuntu" at revision 402
<ahasenack> just what I got above
<nacc> it worked immediately before the snapd update to snapd:amd64 (2.31.1+18.04, 2.32+18.04~pre5)
<Odd_Bloke> I was having (differently presenting) problems and refreshing to the beta core snap fixed them.
<Odd_Bloke> nacc: ahasenack: ^
<nacc> Odd_Bloke: interesting
<niemeyer> nacc, ahasenack: There was a known bug due to the interaction of a prerm script and a baf behavior of systemd on mount units.. This is supposed to be fixed, I believe.. Easiest workaround is to just reboot
<niemeyer> The cause is a snap.mount unit that is stopped by the prerm, when it shouldn't be since it's specific to containers.. systemd doesn't start, but stops the unit, and that chains into stopping every snap mount under it
<nacc> niemeyer: will try it
<nacc> niemeyer: confirmed, reboot fixed the issue
<niemeyer> nacc: Phew
<niemeyer> nacc: Sorry for the trouble.. we're on top of that one already.. I'll confirm with Michael tomorrow the versions affected
<nacc> niemeyer: thanks!
<niemeyer> nacc: In theory the fix should be going out, or be out already
<nacc> niemeyer: ok; yeah i didn't see anything in bionic-proposed to test (when i looked earlier)
<ahasenack> I'll reboot... at eod :)
<Chipaca> ahasenack: if you need anything earlier, systemctl start snap.<stuff>.mount should fix it
<Chipaca> ahasenack: (tab completion will help figure out the <stuff> bit)
<ahasenack> thx
<vidal72[m]> are snaps supposed to create apparmor denials during normal usage?
<Chipaca> vidal72[m]: they're not supposed to, but some might
<Chipaca> vidal72[m]: why?
<vidal72[m]> Chipaca: cluttering logs will make managing them harder for me. Is sandbox defined by mantainer or is it created automatically?
<Chipaca> vidal72[m]: if it's bad enough to affect the logs it should be fixable
<Chipaca> vidal72[m]: the ones we don't mind too much are things like java apps that try all sorts of crazy things on startup (but gracefully degrade to things that work and then are happy)
<Chipaca> vidal72[m]: typically there'll be more chatter in the log about profile loads than denials, at least in my use
<vidal72[m]> Chipaca: chatter are no problem, denials are - especially if you set notification about them :) I have qt app which try access /sys/devices/* at startup.
<zyga> vidal72[m]: hey, about your system, normally snaps don't generate many denials but you are working with apparmor enabled and unpatched kernel, I think we are still missing one feature patch in mainline and this may switch all of confinment into big compain but don't deny mode
<zyga> vidal72[m]: can you paste find /sys/kernel/security/apparmor
<Chipaca> vidal72[m]: there might be an appropriate interface to let the app access /sys/devices (but probably not *, if that was literal)
<Chipaca> vidal72[m]: OTOH if it's really doing that, you could detect you're in a snap and not do it :-)
<vidal72[m]> zyga: my kernel is patched :) https://paste.ubuntu.com/p/JMJ9VGQZjS/
<Chipaca> vidal72[m]: do you also have the seccomp patches for complain mode?
<vidal72[m]> Chipaca: I have only those https://gitlab.com/apparmor/apparmor/tree/master/kernel-patches/v4.15
<vidal72[m]> Chipaca: this app tries to acces my gpu under /sys/devices/
 * vidal72[m] sent a long message: vidal72[m]_2018-03-19_21:45:32.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/ndxqEpzSbAFVWSaHTjifuQKZ>
<Chipaca> niemeyer: not sure if my explanation of the <runes> prefix makes sense, or if I should just drop it; please advise
<Chipaca> vidal72[m]: ooh, i think mborzecki might want to have a look at that
<Chipaca> vidal72[m]: (he'll be around in 9h or so)
<zyga> vidal72[m]: yes it looks like it
<zyga> Chipaca: the patches are in the upstream kernel (for seccomp)
<zyga> userspace just needs upstream release
<zyga> vidal72[m]: I'm puzzled but not to confuse issues please report each issue separately on the forum
 * zyga gets back to being AFK
 * Chipaca also is mostly afk, reading scifi and wondering whether to brave the cold to get some tea, or just stay put
<vidal72[m]> I guess it's caused by lack of opengl slot for this app. Is it possible to grant slot access manually?
<zyga> vidal72[m]: you'd have to repackage the app
<zyga> vidal72[m]: you can only connect and disconnect to existing slots
<vidal72[m]> zyga: ok, I try to contact the developer
<sdfsdf> ay
<niemeyer> Chipaca: The current state and the actual implementation both look nice, actually.. I'm just not sure we need those functions, but for a different reason. I've sent a more detailed review. Let me know what you think
<Chipaca> niemeyer: ok
<Chipaca> niemeyer: where did you send it?
<niemeyer> Chipaca: I thought it was in the PR itself
<niemeyer> If not, please let me know
<Chipaca> niemeyer: is it the one starting "Looking through this function"?
<niemeyer> Chipaca: Yeah
<Chipaca> niemeyer: ah, answered that before answering the others
<niemeyer> Chipaca: Not sure I get what you mean there
<sdfsdf> can I put a full lamp stack in snaps
<niemeyer> Chipaca: strings has a LastIndexFunc whose func argument is a rune
<Chipaca> niemeyer: yes
<niemeyer> Chipaca: Do you mean it's broken?
<kyrofa> sdfsdf, yep
<Chipaca> niemeyer: no, it's not broken
<sdfsdf> kyrofa: any guides?
<kyrofa> sdfsdf, take a look at the Nextcloud snap, for example
<sdfsdf> Snaps are a new idea to me
<Chipaca> niemeyer: what do you do LastIndexFunc of?
<kyrofa> sdfsdf, it's a little old, but yeah: https://kyrofa.com/posts/installing-nextcloud-can-be-a-snap
<Chipaca> niemeyer: that is: you want the last unicode.IsSpace before the end of the terminal
<niemeyer> Chipaca: I'm probably missing the trick of the logic
<niemeyer> Chipaca: The logic there is doing:
<niemeyer> idx = runesLastIndexSpace(text[:width+1])
<Chipaca> yes
<niemeyer> How's that different from
<niemeyer> strings.LastIndexFunc(text[:width+1], unicode.IsSpace)
<niemeyer> or similar
<sdfsdf> kyrofa: Can snaps access the full fat filesystem
<kyrofa> sdfsdf, by default, no they're pretty locked down. You can get more access by using various interfaces, though
<Chipaca> niemeyer: say text is "Â â¢Â Ã¡rbol", and width is 5
<sdfsdf> I'm thinking about doing development with Ubuntu Core but I guess I'll use 16.04 LTS
<sdfsdf> Then make a snap
<Chipaca> niemeyer: or 10 even :-) i'm generous
<kyrofa> sdfsdf, yeah development on classic Ubuntu is a little easier, but you can use the `classic` snap in Ubuntu Core to get access to a more "classic" environment, e.g. apt etc., which helps with development
<niemeyer> Chipaca: Ok
<niemeyer> ?
<Chipaca> niemeyer: text[:width+1], if text is a string, is "Â â¢Â Ã¡rb"
<Chipaca> niemeyer: whereas there are less than width runes in text
<Chipaca> so you could just print it
<Chipaca> niemeyer: if width is 5, text[:width+1] with text as a string gives you "Â â¢ï¿½"
<niemeyer> Chipaca: This is assuming a brok?en prior implementation of width
<niemeyer> Chipaca: I think?
<Chipaca> niemeyer: the width is the number of columns of the terminal
<Chipaca> niemeyer: the terminal doesn't know how many bytes you are going to need in your variable-width encoding to encode the characters you want to show :-)
<niemeyer> Chipaca: It sounds like you are referring to the behavior which is explicitly listed in the current implementation as being a bug still.. let me play that in a different way:
<niemeyer> Chipaca: If width was 80, and the current text was defined to exceed 80, we'd want to cut it to less than 80 at the space..
<Chipaca> niemeyer: yes
<niemeyer> Chipaca: That's what the logic there does.. it was determined to be in excess when we reach that line already
<Chipaca> niemeyer: yes
<niemeyer> Chipaca: at len(text) > width {
<niemeyer> Chipaca: This is the same as runeCount(text) > width
<Chipaca> but that comparison is only possible if text is a []rune
<Chipaca> yes
<niemeyer> Chipaca: Which is what is being done for the padding already..
<Chipaca> yes
<Chipaca> niemeyer: the comment about it being broken might be confusing you, so let me explain that one first
<Chipaca> niemeyer: what's broken is that the current implementation counts each rune as having widht 1
<niemeyer> Chipaca: Yeah, so that's where I was coming from.. it sounds like the logic might be easily implemented with logic similar to the one already in use there, without any type conversions or even allocations, since the logic is essentially slicing an existing string
<Chipaca> niemeyer: but that's not true: some runes have widht zero (composing characters), some have width 2 (a lot of east asian things), some have ambiguous width that nobody knows
<niemeyer> :)
<Chipaca> niemeyer: no seriously :-)
<Chipaca> niemeyer: but that's the map from a rune to the width on the terminal
<niemeyer> Chipaca: I haven't looked, but from your comment the slightly depressing part is having no means to simply ask for the width
<niemeyer> Chipaca: But that's an aside
<Chipaca> niemeyer: and this is the map from the length of the utf8-encoded runes
<Chipaca> niemeyer: there's a first approximation that's fairly good, if you ignore bugs
<Chipaca> (but then there are bugs :-) )
<niemeyer> Yeah, +1
<Chipaca> niemeyer: the first approximation is to have two big unicode tables (like the ones in ctrl16.go and ctrl17.go in puritan)
<Chipaca> (oh also these tables depend on the unicode version...)
<Chipaca> (... which depends on the go version... )
<Chipaca> (everything is terrible)
<Chipaca> anyway, that's getting ahead of this
<Chipaca> this one is simply accounting for the fact that, for example, len("â¢") is 3
<Chipaca> (also that's the most-used non-ascii character in current stable amd64 descriptions)
<niemeyer> Chipaca: Right, it sounded like the problem was simple enough to be handled with plain strings, similar to what we already have there for padding, but this isn't really a blocker
<mup> PR snapcraft#2009 closed: Base check for classic <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2009>
#snappy 2018-03-20
<mup> PR snapd#4869 closed: cmd/snap-update-ns: use x-snapd.{synthetic,needed-by} in practice <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4869>
<mup> PR snapcraft#2010 opened: Release/2.40+18.04 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2010>
<mborzecki> morning
<phoenix_firebrd> morning
<mup> PR snapd#4864 closed: daemon: support 'system' as nickname of the core snap <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4864>
<mup> PR snapd#4841 closed: snap/pack, cmd/snap: add `snap pack --check-skeleton` <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4841>
<zyga> good morning
<zyga> quick breakfast and brb
<phoenix_firebrd> any of you fellows use a intel gpu?
<zyga> phoenix_firebrd: probably most of us
<phoenix_firebrd> zyga: When you find time can you check If you are able to play a VP9 encoded file(ex: videos from youtube) using the vlc snap with hardware acceleration enable and using vaapi for hardware acceleration?
<zyga> yes, sure
<zyga> can you give me an example URL?
<phoenix_firebrd> zyga: any youtube video is fine
<zyga> any?
<zyga> aren't they encoded in different formats
<phoenix_firebrd> zyga: as far as i know all the youtube videos are displayed using vp9/webm format in the latest browsers by default
<zyga> I mean, I'd love to help but I want to make the test meaningful
<mvo> hey zyga ! good morning
<zyga> hey :-)
<phoenix_firebrd> zyga: do you have youtube-dl
<zyga> no, I don't believe I do
<phoenix_firebrd> zyga: try this as an example https://www.youtube.com/watch?v=D6tC1pyrsTM
<zyga> let me try to get a video and play it
<phoenix_firebrd> zyga: takecare, youtube-dl by default downloads the highest quality video and the above video is a 4k video and take a lot of size
<zyga> phoenix_firebrd: which channel of vlc do you want to tets
<zyga> *test
<phoenix_firebrd> zyga: normal
<zyga> stable? ok
<phoenix_firebrd> zyga: I think it contains vlc verion 3.0.1
<phoenix_firebrd> zyga: ok
<zyga> phoenix_firebrd: I'll let you know once the download finishes
<phoenix_firebrd> zyga: ok
<zyga> mvo: what shall we do with 4765
<mup> PR snapd#4874 opened: tests: a bunch of test fixes for s390x from looking at the autopkgtest logs <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4874>
<mup> PR snapd#4872 closed: tests: add workaround for s390x failure <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4872>
<mborzecki> zyga: is this line correct? https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/snap-confine.apparmor.in#L367 the current autotools setup configured with --libexecdir=/usr/lib/snapd
<zyga> looking
<zyga> oh
<zyga> no, looks like a bug
<zyga> nice catch!
<zyga> please tag the fix with 2.32 as well
<mborzecki> ok
<mup> PR snapd#4863 closed: snap: don't create empty Change with "Hold" state on disconnect (2.32) <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4863>
<zyga> jjohansen: I'm running your kernel today, so far no issues, I will periodically run the script that finds dangling symlinks and report back
<mborzecki> zyga: #4875
<mup> PR #4875: cmd/snap-confine: fix ptrace rule with snap-confine peer <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4875>
<mup> PR snapd#4875 opened: cmd/snap-confine: fix ptrace rule with snap-confine peer <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4875>
<zyga> thank you
<zyga> mborzecki: approved
<zyga> man, we will have a lot of back ports to do
<mborzecki> hopefully those are single patch fixes :)
<zyga> mvo: I failed to fix the last bug yesterday, it's not that I don't know what to do it is just _how_ to do it
<zyga> phoenix_firebrd_: hey
<zyga> so I think it doesn't work
<zyga> [00007f7608001ca0] glconv_vaapi_x11 gl error: vaInitialize: unknown libva error
<zyga> libva info: VA-API version 0.39.0
<zyga> libva info: va_getDriverName() returns 1
<zyga> libva error: va_getDriverName() failed with operation failed,driver_name=i965
<zyga> [00007f7608001ca0] glconv_vaapi_drm gl error: vaInitialize: operation failed
<zyga> this is on a i5 skylake chip
<phoenix_firebrd> zyga: hi
<zyga> the video plays but using significant amount of CPU
<phoenix_firebrd> zyga: I think skylake supports hybrid decoding of vp9
<phoenix_firebrd> zyga: can you paste the profiles list?
<zyga> what profiles?
<phoenix_firebrd> zyga: the rest of the livainfo
<phoenix_firebrd> zyga: vainfo i mean
<zyga> one sec
<zyga> https://www.irccloud.com/pastebin/ZuZnIbE4/
<zyga> note that this is vainfo outside of the snap
<phoenix_firebrd> zyga: are you on 18.04?
<zyga> yes
<phoenix_firebrd> zyga: ah
<phoenix_firebrd> zyga: https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1756380
<mup> Bug #1756380: vaapi VP9 hardware decoding not working anymore in bionic <intel-vaapi-driver (Ubuntu):Confirmed> <libva (Ubuntu):Invalid> <https://launchpad.net/bugs/1756380>
<phoenix_firebrd> zyga: vp9 profiles are absent for supported hardware in 18.04
<zyga> phoenix_firebrd: but shouldn't this matter in snaps
<zyga> is this a kernel side issue or a userspace issue
<phoenix_firebrd> zyga: i mean just in case of the vainfo you gave from outside of snap
<zyga> right
<zyga> did you see the erros from libva I posted earlier
<zyga> when starting up vlc
<phoenix_firebrd> zyga: ya
<phoenix_firebrd> zyga: is there a way to update the i965-va-driver package in snap to 2.1.0?
<zyga> only by rebuilding the snap
<zyga> mborzecki: ^ FYI, one of the things we could eventually support is pluggable va drivers
<pstolowski> Mornings!
<phoenix_firebrd> zyga: what are the steps that has to be done to fix this driver bug issue so that it does not show up in the vlc snap
<zyga> I don't understand the issue so I cannot say
<phoenix_firebrd> zyga: by driver i mean the one used in the snap core i guess
<zyga> phoenix_firebrd: are you asking what is needed to stop shipping libva in a particular snap, like vlc?
<Mirv> I think it would be nice to consider whether the version in bionic archives could be upgraded or cherry pick fixed, but that's outside of snappy realm
<phoenix_firebrd> zyga: If you know that the intel vaapi driver is buggy  and that causes vlc snap to display corrupted frames while playback, how do you fix that
<zyga> phoenix_firebrd: I don't know anything about libva, I cannot help with that
<zyga> phoenix_firebrd: perhaps vlc folks who make the snap can say more
<zyga> I can help with snapd side of the problem
<phoenix_firebrd> zyga: if you want to update the display drivers what snap will you update? core or vlc or both?
<zyga> phoenix_firebrd: vlc
<zyga> phoenix_firebrd: the core doesn't ship any
<phoenix_firebrd> zyga: so you mean different media player snaps can ship with different version of drivers ?
<zyga> not really drivers, drivers are in the kernel
<zyga> of userspace libraries, yes
<phoenix_firebrd> zyga: This list of packages used to compile a snap is called manifest right?
<mup> PR snapd#4876 opened: packaging: recommend "gnupg" instead of "gnupg1 | gnupg" <Created by mvo5> <https://github.com/snapcore/snapd/pull/4876>
<zyga> phoenix_firebrd: snap may be built entirely from source (except from the toolchain perhaps) so the word package is perhaps misleading
<zyga> I don't know how vlc snap is built, for example, I didn't look at it that closely
<zyga> phoenix_firebrd: so it's possible to both reuse binary builds from a distribution and to build latest and greates of everything from source
<Mirv> a quick look at vlc snap tells me they're building a lot from scratch at least, as they have Qt 5.10
<phoenix_firebrd> zyga: how I see what are the contents of the core snap
<zyga> phoenix_firebrd: just look at it? it's usually mounted in /snap/core/current/
<Mirv> but the intel driver they have is from 2016
<kalikiana> good morning
<kalikiana> o/ Mirv
<Mirv> right, they are basically using unmodified 16.04 LTS version of i965-va-driver, not building it themselves. since they're already building the whole Qt, it sounds to me they could be interested in building some of this too
<Mirv> kalikiana: o/ :)
<mborzecki> zyga: by the looks of it, plain makefile stuff (even though I'm doing some templates inside) is way faster than autotools
<mborzecki> the actual build part is comparable, the largest win is not running configure
<zyga> mborzecki: yeah, that is very typical
<phoenix_firebrd> zyga: I just found that the intel vaapi driver is shipped with the vlc snap and not with core snap. Where to file a bug on a vlc snap ?
<zyga> phoenix_firebrd: well, I told you that
<zyga> phoenix_firebrd: run "snap info vlc"
<zyga> and see the contact URL
<phoenix_firebrd> zyga: ok, let me check
<phoenix_firebrd> zyga: thank you so much for the support
<zyga> thank you for using snaps :-)
<zyga> Ok, I think I have a nice way to fix the bug with layouts leaking thing to the host
<mborzecki> `ERROR: Conflicting profiles for /snap/core/4278/usr/lib/snapd/snap-confine^mount-namespace-capture-helper defined in two files:` this something new?
<mborzecki> full log https://paste.ubuntu.com/p/xCzYR4Ztpv/
<oSoMoN> is snapd 2.32+18.04~pre5 known to be broken?
<oSoMoN> after dist-upgrading today, all my snaps are marked broken
<oSoMoN> rebooting seems to "fix" them, but then they won't start
<zyga> mborzecki: I saw that once yesterday
<zyga> mborzecki: looks like atomic file write left some stuff behind
<zyga> oSoMoN: yes
<oSoMoN> zyga, want me to file a bug report or start a thread on the forum to gather information on the issue?
<mborzecki> zyga: just saw it in 4875, restarted the build to see if it's something random
<mwhudson> pedronis: hi did you see this? https://forum.snapcraft.io/t/avoiding-snap-refresh-in-live-sessions-i-e-installers/4468/4
 * mwhudson is not really here
<mup> PR snapcraft#2011 opened: tests: run tests on Trusty on Travis <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2011>
<pedronis> mwhudson: yes, IÂ don't have particular opinions, is this something snapd needs to do or the installer could do?
<mwhudson> pedronis: how could the installer do it?
<mwhudson> i'm all for not changing snapd at this point of the cycle
<pedronis> mwhudson: move refresh.hold from 2h to 60 days ?
<mwhudson> pedronis: oh just execute snap set core refresh.hold 60d?
<pedronis> well now+60d
<pedronis> but yes
<pedronis> would that be enough?
<mwhudson> oh ok then that sounds easy :)
<mwhudson> i think if people boot the installer and then don't do anything for 60 days, i think i'm ok with things breaking
<pedronis> to be precise you can set anywhere in the future
<pedronis> but after 60 days is not respecte
<pedronis> d
<mwhudson> haha
<mwhudson> pedronis: i had another awful hack in mind, which was to install core and subiquity unasserted
<mwhudson> but this sounds better than that
<mwhudson> pedronis: which version of snapd has refresh.hold support?
<pedronis> 2.32
<mwhudson> ok
<mwhudson> and that's not in bionic because i uploaded go 1.10 but well
<pedronis> well our plan is to have in bionic in the images
<mwhudson> oh no it is in bionic now
<mwhudson> awesome
<pedronis> it has issues it seems though (but unrelated to this)
<mwhudson> pedronis: thanks
 * mwhudson goes to bed
<mvo> mwhudson: it is in bionic now
<mvo> mwhudson: I mean 2.32 is in bionic, we asked to ingore the s390x failures for now as this only affects the covermode=atomic right now
<Chipaca> hmm, why is connecting to interfaces so slow all of a sudden
<mvo> Chipaca: I noticed this as well
<Chipaca> ok, I'll dig
<Chipaca> mvo: do we still not have auto-prereqs?
<mvo> Chipaca: 2.32 should have them
<mvo> Chipaca: is that not working for you? iirc we do not pull in new prereq on refresh, that is a missing feature/bug
<Chipaca> mvo: 2.32~pre4+git612.2003af8~ubuntu16.04.1 isn't working for me
<Chipaca> that is, "snap install evince" resulted in no gnome platform snap
<mvo> in related news: does someone know why master is broken? it seems ~200 tasks are aborted
<mvo> Chipaca: I look once the current fire is out
<mvo> Chipaca: but I see the same here, slightly sad
<Chipaca> mvo: k
<abeato> kalikiana, hey, have you ever seen this snapcraft error when cross-compiling: https://paste.ubuntu.com/p/z4BW75yhXB/ ? (edge channel)
<kalikiana> abeato: Hmm no I think that's new to me
<kalikiana> abeato: Did this break recently?
<abeato> kalikiana, well, it used to work last week
<kalikiana> Also on edge?
<abeato> yes
<abeato> artful fyi
<abeato> kalikiana, stable works
<abeato> a regression in edge then
<kalikiana> Yeah, looks like it :-/
<kalikiana> abeato: Can you file a bug, please?
<abeato> kalikiana, yup
<mup> PR snapd#4877 opened: snap-confine: fallback to /lib/udev/snappy-app-dev if the core is older <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4877>
<zyga> mvo: looking
<abeato> kalikiana, https://bugs.launchpad.net/snapcraft/+bug/1757094
<mup> Bug #1757094: snapcraft in edge channel (2.39.2+git46.c22d7e2) fails to cross-compile kernel <Snapcraft:New> <https://launchpad.net/bugs/1757094>
<zyga> +1 :)
<mvo> zyga: yay, thank you
<mvo> zyga: now we just need to unbreak master
<mvo> zyga: and *hopefully* the world is a happy place again
<zyga> is master broken?
<mvo> zyga: yeah, next PR comming that tests my theory on the why
<zyga> oh, ok
<mup> PR snapd#4878 opened: tests: disable 18.04 spread tests in google for now <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4878>
<mvo> zyga: it looks like its a test problem with the google 18.04
<zyga> I didn't see any issues
<zyga> but I'm still on an older branch from yesterday
<mvo> zyga: no worries, only spread not our code
<mvo> zyga: also - "make fmt" on bionic produces some different output than "make fmt" on older releases it seems
<mvo> zyga: not a great morning so far, too many fires
<zyga> yes
<zyga> I noticed
<zyga> this is why it's no longer enforced
<zyga> when things quited down I will reindent with something saner
<zyga> or see if I can coerce newer indent
<kalikiana> abeato: Thanks!
<kalikiana> abeato: Can you link the snap you're building there?
<ogra_> that might be tricky
<ogra_> (customer kernel)
<abeato> kalikiana, that ^
<kalikiana> Hmm okay.
<mvo> Chipaca: turns out the problem with evince is that there is on `content: <tag>` line in the interface, I'm looking if we should use default here
<pedronis> mvo: we have code that sets defaults
<pedronis> but probably is not called for this case
<pedronis> bit fragile to duplicate it though
<mvo> pedronis: yeah, I'm poking a bit to see if there is a nice way
<Chipaca> mvo: i think oSoMoN and/or kalikiana could land a fix meanwhiles :-)
<mvo> Chipaca: yeah, fix is trivial, just adding "content: <some-string>" on both the evince plug and the gnome-3-26-1604 slot
<Chipaca> mvo: âcontent: like a riverâ
<Chipaca> (http://www.azquotes.com/quote/1262712)
<pedronis> mvo: mmh, it's it not done much earlier, I suppose the issue is that we read the snap yaml but don't validate it
<pedronis> (which would set the defaults)
<pedronis> I was remembering the old code, but in the new world this should happen somewhere in snap/
<zyga> mvo: I finally have good progress on the (I named it) trespassing bug
<zyga> I'll get a coffee and finish it soon
<mvo> Chipaca: nice and poetic
<mvo> pedronis: hm, that might be it
<mvo> pedronis: it looks like nowday "interfaces.BeforePrpareSlot" must have been called
<pedronis> mmh
<mvo> pedronis: interfaces.SanitizePlugsSlots calls this, so you are right I think, somewhere there is a sanitation missing
<pedronis> mvo: it's called by the ReadInfo*  but not by just parsing
<pedronis> mvo: I think you added code to details.go in store that calls parsing of yaml but not that
<mvo> pedronis: indeed, that sounds like the culprit
<pedronis> mvo: otoh it seems to be called only for installed snaps
<pedronis> atm
<pedronis> mvo: Chipaca: it's all a bit confusing:  ReadInfoFromSnapFiles calls Validate bot not SanitizePlugsSlots  and ReadInfo calls SanitizePlugsSlots but not Validate
<pedronis> pstolowski: ^
<pedronis> what was the thinking there?
<pstolowski> pedronis: yes just looking. seems to be my oversight in the refactoring :(
<mvo> pedronis: I'm still looking but afaict store/details.go calls InfoFromSnapYaml() which does not sanitzze, I wonder if we can/should do it there because that is used by the various bits afaict
<pedronis> IÂ know why we don't validate already installed snaps
<pedronis> the assumption is that is done once
<pedronis> before
<pedronis> but SanitizePlugsSlots has side effects we always need
<pedronis> for values of always
<mvo> pedronis: yeah, I wonder if nowdays it should be "annotatePlugsSlots" or something, its doing much more than to sanitize
<mup> PR snapcraft#2011 closed: tests: run tests on Trusty on Travis <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/2011>
<pstolowski> mvo: what do you mean with more? afair the only difference with old implementation is the fact that it collects invalid ones in BadInterfaces
<mvo> pstolowski: it calls BeforePrepareSlot for each interface
<mvo> pstolowski: for the content interface this adds some defaults (like when content: is missing it adds an implicit "content: <slot-name>")
<mvo> kenvandine: could you please update evince so that default-provider is just a snap name? right now it is "gnome-3-..:gnome-3-..."
<pstolowski> mvo: I see. BeforePepare* is the old Sanitize*, we were doing that before, it's just that we don't call SanitizePlugSlots now when we should after the code was moved around
<mvo> pedronis: http://paste.ubuntu.com/p/2NjMYChFzR/ <- this might be what we need, i.e. run this always
<mvo> pstolowski: yeah, it was just a idle though that the name is not fully conveying what is happening (but I guess one could argue that part of the sanitize is that missing fields are updated with sensible defaults)
<pedronis> it's reasonable, IÂ don't know if there is some assumption that that code does that would explode if we don't Validate first though
<mvo> pedronis: ReadInfo() would still get sanitization via infoFromSnapYamlWithSideInfo
<mvo> pedronis: all tests explode because we are not prepared for this in the tests, so there is some work here :) and of course I need to double check with pstolowski that this is sensible
<pedronis> seems orthogonal right now
<mvo> pedronis: orthogonal to what?
<pedronis> sorry, I was answering my question:  IÂ mean the jobs Validate does and SanitizePlugsSlots do
<pedronis> they don't seem to depend on each other
<pedronis> (atm)
<mvo> pedronis: yeah, validate is doing something else right now indeed
<mvo> Chipaca, pedronis fwiw, I tested the evince with the updated location for the SanitizePlug and the content is installed (well, would be installed if default-provider was a snap name ;) but that is a problem of the snap and easy to fix there)
<mvo> pedronis I think I will prepare a PR with the change and test updates and let pstolowski and you double check, sounds reasonable?
<pstolowski> mvo: the original invariant was (and still is) that every snap.Info that we create and return has all the plugs and slots sanitized and we don't expose broken ones via this struct
<pedronis> mvo: ok
<mvo> pstolowski: yeah, I think this invariant is currently not honored
<pstolowski> mvo: right, my bad :(
<mvo> pstolowski: when you create a snap.Info via InfoFromSnapYaml()
<mvo> pstolowski: no worries
<pstolowski> mvo: I can take this bug
<mvo> pstolowski: http://paste.ubuntu.com/p/2NjMYChFzR/ is probably what we want plus test updates, if you can take it that would be great
<mvo> pstolowski: the real world test is to snap install evince, it should pull in the gnome-3-... content snap but it does not right now because the defaults are not set
<mvo> pstolowski: (john discovered this bug). if you have any question, just let me know
 * mvo goes back to unbreaking bionic
<pstolowski> mvo: yes, that fix looks sensible as long as this is indeed the central (or only) place that needs this
<pstolowski> mvo: ok, i'll work on this right away; is this some kind of a blocker atm?
<mvo> pstolowski: its not terrible but nice to have
<mvo> pstolowski: 2.32 will have the install of content providers so if we can unbug it, that would be great
<mvo> pstolowski: I mean, its not terrible urgent (no need to skip lunch over it) but ideally we should fix it today if we can
<pstolowski> ack, will be aiming at that
<mvo> thanks pstolowski !
<pstolowski> pedronis: one question re your comment "what happens on update with old tasks that had the previous thing?" to the interface hooks; that's a valid concern and I think we need to make sure update conflicts with these hooks (there is already some code for connect/disconnect conflict on update, but I need to check if it would do that). does that sound sensible?
<pstolowski> mvo: sure, thanks for catching & sorry for the trouble /o\
<mvo> pstolowski: no worries
<mup> PR snapd#4878 closed: tests: disable 18.04 spread tests in google for now <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4878>
<mup> PR snapd#4879 opened: tests: revert "tests: disable 18.04 spread tests in google for now" <Created by mvo5> <https://github.com/snapcore/snapd/pull/4879>
<cachio> sergiusens, hey, I've seen some errors on autopkgtests https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/s/snapcraft/20180319_163043_7404b@/log.gz
<sergiusens> cachio: feel free to ignore armhf until the new autopkgtest roll out comes into place
<cachio> sergiusens, nice, thanks
<mup> PR snapd#4880 opened: [RFC] cmd, data: plain make  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4880>
<mborzecki> zyga: plain make ^^
<zyga> oh,cool
<zyga> mborzecki: queued for after standup
<mvo> mborzecki: nice speedup
<mvo> mborzecki: hard to grasp how auto* is so inefficient, speed 6x
<mborzecki> all the perl/sed/coreutils invocations add up
<mborzecki> i'm looking into why #4875 fails, also #4871 failed in a way that's sort of similar
<mup> PR #4875: cmd/snap-confine: fix ptrace rule with snap-confine peer <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4875>
<mup> PR #4871: cmd/snap-confine: fix Archlinux compatibility <Created by Erick555> <https://github.com/snapcore/snapd/pull/4871>
<mborzecki> it looks as if when updating snap-confine apparmor profile, some temp files are left behind
<mborzecki> mvo: zyga: any ideas how that could be possible?
<zyga> no,
<zyga> we just write it using atomic thing
<phoenix_firebrd> zyga: I checked the vlc snap info, it shows a url to a general support page. I checked the vlc support page, I shows a general bug reporting page, not anything specific to snaps, also on searching for existing bugs, there was not a single snap related bug report. So is there a specific place dedicated for vlc snap bugs?
<zyga> phoenix_firebrd: no, it's their snap and their bug reports
<mvo> mborzecki: looking
<mborzecki> zyga: hm it looks like a temp file made by us though, /etc/apparmor.d/snap.core.4278.usr.lib.snapd.snap-confine.gVv662JKQnGl the suffix is 12 chars, the same as we use
<mvo> mborzecki: do you have a link to the failure log or a pastebin of it?
<zyga> yes
<mborzecki> mvo: https://paste.ubuntu.com/p/xCzYR4Ztpv/
<mvo> ta
<zyga> mborzecki: but I don't know why it would stay behind now
<mvo> zyga: that is ensureDirState, right? that is used all over the place so should be well tested
<zyga> yes
<zyga> and the actual writing is done by atomic thing AFAIR
<zyga> so I doubt it's something newly broken there
<mvo> or its a race
<mvo> i.e. we write things at the same time when the profile is loaded?
<zyga> hmmmm
<zyga> perhaps
<zyga> but who would load it?
<mvo> (a long shoot)
<mvo> I have no idea :)
<zyga> apparmor loads that profile
<zyga> but we start after apparmor
<zyga> then snapd reloads that profile
<zyga> but _exactly_ that profile (not everything else)
<zyga> the error is weird btw,
<zyga> ah
<zyga> + aa-enforce /etc/apparmor.d/usr.lib.snapd.snap-confine.real
<zyga> this is aa-enforce doing things
<zyga> it's just a test thing, we never touch that from snapd
<zyga> so something goes wrong
<zyga> and then much later we run aa-enfroce
<zyga> *aa-enforce
<zyga> and  that looks for system-wide consistency for some reason
<phoenix_firebrd> zyga: so a bug in vlc snap has to be reported in the regular vlc bug reporting channel?
<zyga> phoenix_firebrd: yes, snaps don't have packagers in the same sense as other linux packages, typically upstreams package and ship the snap
<mborzecki> zyga: mvo: just ran this test through spread and it was all good
<zyga> yeah, I saw this once yesterday
<mvo> zyga: maybe we need to run aa-enforce checks in each restore to catch the offender?
<mborzecki> do we touch those profiles while installing the package?
<zyga> and it's first time I ever saw it
<phoenix_firebrd> ok
<zyga> mvo: I think that's what happened here
<zyga> or maybe I'm wrong
<mvo> zyga: I think this makes sense - but what is calling aa-enforce?
<zyga> I think it's one of the tests actually
<mborzecki> mvo: the test does
<zyga> mvo: main/snap-confine
<zyga> mvo: one idea
<zyga> mvo: somehow we stop snapd at the wrong time
<zyga> and we have this in the state tarball
<zyga> it would be good if someone managed to reproduce this with -debug
<mborzecki> zyga: running it now with the same seed as the tests
<zyga> NB: I doubt it's deterministic anyway
<zyga> but let's see
<phoenix_firebrd> zyga: can you point me to a place, where there is a complete documentation about snaps and the related process
<zyga> phoenix_firebrd: ha, I wish we had one, we are doing most of the work on forum.snapcraft.io and on a new (test URL) site at https://snapdocs.labix.org/
<phoenix_firebrd> zyga: If i am doing "sudo snap install vlc " in ubuntu, from where does the vlc snap gets fetched?
<zyga> phoenix_firebrd: from the snap store
<phoenix_firebrd> zyga: snapstore.com?
<zyga> no
<zyga> it's a service at...
<zyga> https://api.snapcraft.io/ AFAIR
<zyga> the actual package download is from a CDN
<phoenix_firebrd> zyga: so in case of vlc, Vlc snap gets created and uploaded to the snap store by the vlc maintainers and then we fetch from it during install?
<zyga> yes
<zyga> exactly that
<phoenix_firebrd> zyga: cdn of course
<zyga> mvo: I'm testing the fix for trespassing bug now, looks good for 2.32 from layout POV today
<phoenix_firebrd> zyga: I guess I have to create a vlc account and file a bug with them. I think I will windup today with this. Thank you.
<zyga> I will need to backport all the things that were labelled as 2.32 and only merged to master
<zyga> phoenix_firebrd: thank you! I think you can also shoot them an email somewhere but I have never tried reporting VLC bugs directly
<phoenix_firebrd> zyga: I am thinking of collection preliminary information by directly talking to some devs in vlc irc channel, if one exists and then will email and/or file a bug report
<zyga> yeah, that's a good idea
<cachio> niemeyer, change in spread already updated
<zyga> aww, drat
 * zyga tinks
<zyga> thinks
<pedronis> pstolowski|lunch: my question was more about   the older version of the same hooks? did we partially support hook already in stable?
<cachio> mvo, hey
<cachio> I am pushing a fix for bionic
<mup> PR snapd#4881 opened: tests: make tests run with specific bionic release avoiding take the last one <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4881>
<zyga> jdstrand: man, fixing the "trespassing" bug (where we write to real /etc is really hard)
<zyga> it requires some fair amount of changes
<Chipaca> mvo: fwiw, https://forum.snapcraft.io/t/auto-connection-for-gnome-3-24-content-interface/1379/79
<zyga> jdstrand: my approach was to interact with the secureMk* family of functions
<zyga> and before calling open(..., O_CREAT,...) or mkdirat() or symlinkat() check that fstatfs reports that we are on a tmpfs
<zyga> this is not perfect but it is a close approximation to "is this a mimic"
<zyga> if something is a tmpfs we just carry on
<zyga> if it's not a tmpfs we check if the path we are attempting to make looks legitemately
<mborzecki> zyga: https://paste.ubuntu.com/p/tQg4GVfMK5/
<zyga> brb
<zyga> mvo: I will be a moment late to the standup
<phoenix_firebrd> zyga: I spoke to a vlc dev, they say that the one-line-patch to fix the driver bug, has to be backported to 16.04 by ubuntu, they will then re-release an update vlc snap with the updated driver.
<phoenix_firebrd> zyga: how likely ubuntu will backport a patch to 16.04?
<zyga> phoenix_firebrd: not sure but they don't have to wait for that, they can just build the right version of the driver from source and put that in the snap
<phoenix_firebrd> zyga: I guess their policy stops them.
<phoenix_firebrd> zyga: they say they use the stuff from 16.04 to target the 16.04 core i guess
<phoenix_firebrd> zyga: like for example the va-api version 2 uses libva2 which cannot be installed in 17.10, because of the dependency issue
<phoenix_firebrd> zyga: do you know how long it will take for the ubuntu core snap to migrate to 18.04?
<ogra_> it wont, the design will change
<ogra_> (you wuill be able to simply declare 16 or 18 in your snaps snapcraft.yaml and it will work on either of them, pulling in what it needs)
<ogra_> but thats probably a thing that will still take til ... well.. october ?
<phoenix_firebrd> ogra_: this October ?
<ogra_> no, october in 7 years
<ogra_> :P
<ogra_> (indeed this october :) )
<zyga> phoenix_firebrd: ubuntu core16 and core18 will exist in parallel
<zyga> phoenix_firebrd: so vlc snap maintainers can hop onto the 18 one when they feel like it and when it is ready
<zyga> it won't be a "hard" change
<zyga> snaps will use base they want and will switch whenever they want
<kenvandine> mvo, oh, all of our snaps do that
<kenvandine> mvo, so it should just be the snap name?
<phoenix_firebrd> ogra_:  :)
<phoenix_firebrd> zyga: ok
<kenvandine> mvo, the documentation says to use the name and slot
<kenvandine> default-provider (plug): name and slot of preferred providing snap (<SNAP>:<SLOT>)
<mborzecki> zyga: temp files do not seem to come from snapd-state.tar.gz https://paste.ubuntu.com/p/D8qf6j6CwY/
<mvo> kenvandine: thank you, I'm in a meeting right now, I will review the docs
<mvo> kenvandine: please do nothing for now, I will look in  a bit
<kenvandine> mvo, ok, thx!
<jdstrand> mvo, zyga: looking at backscroll from last week, https://github.com/snapcore/snapd/pull/4822 would kill boot speed, especially on armhf. I'm glad you figured out another way
<mup> PR #4822: interfaces/apparmor: skip apparmor cache <Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4822>
<oSoMoN> mvo, zyga:Â how is that bionic fix coming along?
<mvo> oSoMoN: fix is reviewed we are waiting for tests
<oSoMoN> mvo, excellent, thanks!
<mvo> jdstrand: thanks, yes, we never wanted to do this for real :)
<oSoMoN> mvo, do the autopkgtests for snapd exercise installing and running real-world snaps?
<zyga> jdstrand: yes, that was a RFC really, to see what the problem is
<zyga> oSoMoN: mvo is handling that
 * jdstrand hugs mvo and zyga 
<mvo> oSoMoN: yes
<mvo> oSoMoN: well, depends on what you mean by real-world :) it does run lxd and a bunch of small snaps, it does not run chromium or firefox
<zyga> jdstrand: btw, did you see my apparmor parser wrapper
<zyga> with more control over caching?
<jdstrand> zyga: not yet. is it a PR?
<oSoMoN> mvo, ack, thanks
<zyga> jdstrand: it was but got closed (it was another RFC, let me show that to you quickly)
<mvo> oSoMoN: this particular problem is caused by bionic being ahead of core
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/4827/files
<mup> PR #4827: cmd/snap-apparmor-parser: add a prototype apparmor parser <Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4827>
<mvo> oSoMoN: if you switch your core to "beta" (snap refresh --beta core) you are good again too
<zyga> I grew it slightly to handle removing later but this version shows the general idea
<zyga> (I was also saving both the source file and the binary file)
<zyga> (source after preprocessing)
<jdstrand> mvo: you mentioned in backscroll that https://bugs.launchpad.net/snappy/+bug/1460152 needed love. that (and a regression fix for it) was committed to upstream apparmor in 2015
<mup> Bug #1460152: apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates) <patch> <Snappy:Fix Released by mvo> <Snappy 15.04:Fix Released by mvo> <apparmor (Ubuntu):Fix Released> <https://launchpad.net/bugs/1460152>
<jdstrand> mvo: if it is continuing to not do what we want, then I think a new bug is in order
<zyga> cachio: you want apparmor-profiles package
<mborzecki> zyga: cachio: fwiw. apparmor is disabled in snap-confine for opensuse https://github.com/snapcore/snapd/blob/master/packaging/opensuse-42.2/snapd.spec#L126
<zyga> mborzecki: yes, but it could be enabled now
<mborzecki> let's try it :)
<jdstrand> zyga: before committing https://github.com/snapcore/snapd/pull/4827, we should talk to jjohansen
<mup> PR #4827: cmd/snap-apparmor-parser: add a prototype apparmor parser <Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4827>
<zyga> jdstrand: it's closed, we're not going to commit that AFAIK
<mvo> mborzecki: I'm with you in the hunt for the snap-confine.XXXX leftover profiles now
<mvo> mborzecki: as this blocks my PR too
<jdstrand> mvo, zyga: is the cache drama from last week resolved due to removing the system key OR?
<jdstrand> PR?
<zyga> jdstrand: yes, it's the system key
 * jdstrand is trying to wade through the discussion and the various PRs
<zyga> we change things that end up in system key behind snapd's back
<zyga> (we repackage core)
<zyga> so revision was not sufficient
<jdstrand> right
<zyga> and we simply remove the system key as a workaround (this only affects test)
<jdstrand> https://github.com/snapcore/snapd/pull/4842 is still open btw (and out of date)
<mup> PR #4842: interfaces: make hash of apparmor profile for snap-confine in core part of the system-key <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4842>
<zyga> jdstrand: I think that was another RFC
<mvo> jdstrand: it is resolved in the sense that things work now and we also have an idea how we could make it more robust (by adding a hash of the current snap-confine profile from core into the system-key). but I think there is a bug lurking there somewhere in the apparmor cache handling still :/
<zyga> the one that we decided on was merged
<mvo> jdstrand: unfortunately I don't have much better feedback than: "it does not work" :/ sorry for that
<jdstrand> mvo: if you figure it when 'it does not work', please file a bug and me or jjohansen can take a look at it
<jdstrand> mvo: there is a lot going on between apparmor cache, system key, ensure dir, reexec, etc
<pedronis> #4873 is the delay classic reg PR
<mup> PR #4873: many: delay classic registration until first store interaction <Created by pedronis> <https://github.com/snapcore/snapd/pull/4873>
<mborzecki> mvo: any idea where this could be coming from? the code in intefaces/apparmor does not seem to be doing anything wrong
<mup> PR snapd#4842 closed: interfaces: make hash of apparmor profile for snap-confine in core part of the system-key <Blocked> <Created by mvo5> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/4842>
<mup> PR snapd#4781 closed: wrappers: refactor desktop file sanitizer to support autostart files <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4781>
<mup> PR snapd#4882 opened: snap: make `snap run` look at the system-key for security profiles <Created by mvo5> <https://github.com/snapcore/snapd/pull/4882>
<mvo> mborzecki: yeah, its confusing. it just uses EnsureDirState() and that uses AtomicWrite and defer .Cancel()
<zyga> mvo: ha, interesting
<mborzecki> mvo: when core is refreshed, when does snapd restart to reexec into the new one?
<mvo> mborzecki: thats slightly complicated, iirc in overlord/snapstate and in the link-snap handler there
<zyga> mvo: I need to take a break
<mup> PR snapd#4883 opened: debian: undo snap.mount system unit removal <Created by mvo5> <https://github.com/snapcore/snapd/pull/4883>
<mup> PR snapd#4884 opened: debian: run snap.mount upgrade fixup *before* debhelper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4884>
<niemeyer> zyga: Didn't we have a snap for gcloud or something?
<niemeyer> cachio: ^
<cachio> zyga, mmm, I think zyga created it
<popey> We're working on that.
<cachio> niemeyer, I have the google clud sdk snap that zyga created
<niemeyer> cachio: What's the snap name?
<cachio> niemeyer, it is not in the store
<niemeyer> I see
<cachio> niemeyer, he copied the snap in a usb
<niemeyer> Is it super secret? :)
<popey> No, but don't put it in the store please.
<cachio> niemeyer, I don't think so
<cachio> niemeyer, should we upload it to the store?
<cachio> niemeyer, zyga is it ok if we move the tests execution from opensuse 42.2 to 42.3 for each PR?
<morphis> mvo: I am currently seeing problems with snap removal in LXD containers, is that a thing which was meant to work?
<zyga> Yes, i think so
<morphis> mvo: it smells like snapd tries to unmount the snap via mount where `fusermount -u` would be right
<zyga> It is s point update
<zyga> Morphis: we donât unmount
<zyga> It is done by systemd
<morphis> zyga: someone does it, however a `snap remove ..` hangs forever
<zyga> I think the fix was not released yet
<zyga> You need 2.32 den
<morphis> zyga: ++ snap remove lxd
<morphis> 2018-03-20T14:41:12Z ERROR cannot remove snap file "lxd", will retry in 3 mins: [stop snap-lxd-6162.mount] failed with exit status 1: Job for snap-lxd-6162.mount failed. See "systemctl status snap-lxd-6162.mount" and "journalctl -xe" for details.
<morphis> that is what I get
<morphis> zyga: is this https://bugs.launchpad.net/snapd/+bug/1712930 ?
<mup> Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1712930>
<zyga> Yes
<morphis> so 2.31 should have the fix, right?
<mvo> kenvandine: https://forum.snapcraft.io/t/the-content-interface/1074 has the correct description for the content interface. where did you see the incorrect description? asking so that we can get this fixed :)
<morphis> zyga: so is there already a timeline for when 2.31 gets SRUed into xenial or should this be fixed (without a reboot) with just a new core snap?
<kenvandine> mvo, https://docs.snapcraft.io/reference/interfaces
<kenvandine> mvo,  it says "default-provider (plug): name and slot of preferred providing snap (<SNAP>:<SLOT>)"
<mvo> thanks kenvandine
<kenvandine> mvo, so that means all of our GNOME snaps are wrong :(
<mvo> kenvandine: well, I need to talk to niemeyer but we could simply support you by adding coding to split on the ":" and just throw that part away
<kenvandine> mvo, which are the official docs?  the forum or docs.snapcraft.io?
<zyga> morphis: for this bug we need 3.32 and I donât know about timelines
<mborzecki> off to prep lunch for the kids
<morphis> zyga: you mean a new deb or a new core snap with 2.32?
<zyga> New deb
<zyga> Then the container inside can work
<zyga> I mean then snapd inside the container can work
<mvo> kenvandine: well, there is a bit of a debate about this but the forum docs tend to be more up-to-date and more accurate
<morphis> zyga: ok, sounds like this is long away with the deb of snapd being still at 2.29 in xenial
<zyga> Oh
<kenvandine> mvo, hmmm... ok, we need to kill docs.snapcraft.io then
<zyga> Good point
 * zyga needs to stop sitting for back pain to go away
<mvo> kenvandine: this is a ongoing discussion how to best deal with the docs, niemeyer is leading this discussion
<mvo> davidcalle: what is the best way to ask for a small fix onhttps://docs.snapcraft.io/reference/interfaces ? we need to tweak the "default-provider" line so that it says that the default provider is just a snap name
<mvo> mborzecki: when I tried to reproduce the snap-confine "ERROR: Conflicting profiles for /snap/core/4278/usr/lib/snapd/snap-confine^mount-namespace-capture-helper defined in two files:" in qemu (run in isolation) this did not work - did you managed to reproduce it?
<davidcalle> mvo, hey, I'm not handling this anymore, but I'd say a PR on https://github.com/canonical-docs/snappy-docs/blob/master/reference/interfaces.md
<mup> PR snapd#4885 opened: Specify charset in po/snappy.pot <Created by gunnarhj> <https://github.com/snapcore/snapd/pull/4885>
<mborzecki> mvo: yes, i reproduced it twice using #4875
<mup> PR #4875: cmd/snap-confine: fix ptrace rule with snap-confine peer <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4875>
<mborzecki> but didn't happen on the 3rd run when i had more ideas what to check :/
<nacc> niemeyer: there's some mention of the core snap and vlc in LP: #1756380 about the vaapi driver used by vlc
<mup> Bug #1756380: vaapi VP9 hardware decoding not working anymore in bionic <intel-vaapi-driver (Ubuntu):Fix Released> <libva (Ubuntu):Invalid> <https://launchpad.net/bugs/1756380>
<nacc> niemeyer: dunno if you can help confirm it, that user was a bit problematic on irc
<niemeyer> mvo, kenvandine: We have a agreement to go ahead and replace docs.snapcraft.io to documentation based on the forum, resembling snapdocs.labix.org
<niemeyer> nacc: I don't know details about that one, but I see a message in the bug itself saying it has been fixed elsewhere
<nacc> niemeyer: yeah, i just wasn't sure if the user was full of it :)
<niemeyer> davidcalle,mvo,kenvandine: We need to finish moving (and polishing on the way) this content over to the forum.. I'm hoping to come back to it once 18.04 and the review queue is a bit more under control
<kenvandine> niemeyer, thx
<kenvandine> snapdocs looks nice
<niemeyer> mvo: About the splitting of default-provider, I think we had agreed to do that before in conversations.. we just forgot to come back into it
<niemeyer> mvo: The issue was precisely one of practical consequences of people using it already more than it being technically important
<niemeyer> I didn't realize it was in docs
<niemeyer> That explains why people use it.. I thought it was just a copy & paste from terminal
<niemeyer> kenvandine: There's a lot to do still, but it's slowly getting into shape
<zyga> jdstrand: hey, this is the bugfix for the case when snapd would write to /etc  directly (without a mimic) https://github.com/snapcore/snapd/compare/master...zyga:fix/trespassing?expand=1
<zyga> I'll propose a merge soon but I want to do a clean run first
<cyphermox> ogra_: did you have a chance to verify https://bugs.launchpad.net/netplan/+bug/1741910 ?
<mup> Bug #1741910: ath6kl_sdio does not support unbinding <verification-needed-xenial> <netplan:Fix Committed by cyphermox> <nplan (Ubuntu):Fix Released> <nplan (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1741910>
<zyga> I need to lay down for now
<zyga> mvo: ^ that is (fingers crossed) my last thing for 2.32
<zyga> mvo: https://github.com/snapcore/snapd/pull/4882#pullrequestreview-105420120
<mup> PR #4882: snap: make `snap run` look at the system-key for security profiles <Created by mvo5> <https://github.com/snapcore/snapd/pull/4882>
<mvo> niemeyer: thanks, I will work on the splitting for content provider (cc kenvandine)
<kenvandine> mvo, thx
<mvo> zyga: I think its not only for reboot, on classic if snapd got updated and you restart the daemon its the same problem, no?
<niemeyer> mvo: Thank you!
<mvo> zyga: I mean, system-key may change even without a reboot
<zyga> mvo: no because in such case snapd will regenerate the profile on core snap refresh
<zyga> mvo: so before we are in the new core the profiles will be ready
<zyga> mvo:  this IMO strictly for core
<zyga> mvo: on classic restarting snapd will complete without system reboot and the phase 2 profile generation handles that part
<zyga> mvo: and then the profiles are ready and we proceed to activating the core snap revision
<mvo> zyga: there is still a race here on phase 2, no? I mean, snapd gets refreshed, for some reason network-manager is restarted during that time, won't that be the same as in the reboot scenario?
<zyga> mvo: that depends on one thing: if the new core is active and has the updated current symlink
<zyga> if we do that after security (and AFAIR we do)
<zyga> then it's not racy
<zyga> jdstrand: hey, not urgent as we have thick smoke and some fires now but please enqueue this: https://github.com/snapcore/snapd/pull/4868
<mup> PR #4868: [WIP] secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868>
<zyga> jdstrand: jamesh wrote an interation of the secure mount idea
<mup> PR snapd#4886 opened: tests: adding opensuse-42.3 to google <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4886>
<pedronis> zyga: mvo: phase2 security setup is after link-snap (it cannot be before by necessity)
<zyga> pedronis: hmm, could we do that after we mount but before we rewrite current?
<pedronis> we can do a lot of stuff
<mborzecki> wow, snap apps really core dump on arch with nvidia drivers
<pedronis> but is not trivial with the current task definition
<pedronis> s
<pedronis> it does phase1: setup-profiles link-snap   restarts  phase2: setup-profiles again
<Chipaca> niemeyer: given my comment about the things doing print via io.Writer in cmd/snap, ok to merge #4858?
<mup> PR #4858: strutil, cmd/snap: drop strutil.WordWrap, first pass at replacement <Created by chipaca> <https://github.com/snapcore/snapd/pull/4858>
<niemeyer> Chipaca: Looking
<mvo> cachio: is there anything atypical about the google machines? any strange mount options or filesystem layouts? I ask because we see strange failures in the snap-confine test
<niemeyer> Chipaca: If we have other bad patterns, we should change them indeed, but let's please not add more of them
<zyga> mvo: do you have an example?
<niemeyer> Chipaca: Your PR doesn't need to fix all, though
<niemeyer> Chipaca: It's trivial to do that by just making the type concrete
<niemeyer> Chipaca: If it's memory, that is
 * Chipaca changes it all to *os.File
<Chipaca> :-D
<niemeyer> Chipaca: Yeah, that's the point ;)
<mvo> zyga, cachio these errors http://paste.ubuntu.com/p/DNWCbQRDqs/
<zyga> ah, those
<Chipaca> niemeyer: do you also expect the code to check the returned error?
 * zyga keeps trying to reproduce those
<niemeyer> Chipaca: Not if it's bytes.Buffer
<Chipaca> niemeyer: when it's an io.Writer
<niemeyer> Chipaca: Passing those around with no error checking is fine
<cachio> mvo, where did you see that?
<niemeyer> Chipaca: If it's io.Writer, something is necessarily broken.. the single point of io.Writer is to allow any io.Writer, but we cannot do that and ignore errors without it being a bug
<Chipaca> niemeyer: we fmt.Fprintf all over the place without checking error returns
<Chipaca> niemeyer: are you saying we need to check every error returned from fmt.Fprint?
<niemeyer> Chipaca: That's okay when you are the call site, and you know that it's okay to ignore the error
<Chipaca> ah
<niemeyer> Chipaca: It's not okay when that's inside a function that has no context about what the io.Writer is
<Chipaca> niemeyer: ok, i think i understood
<Chipaca> I guess I'll get to do the fix sometime later this week then
<niemeyer> Chipaca: The cheapest fix for this particular case would be simply to make the type concrete
<niemeyer> Chipaca: Since it's really all in memory AFAICS
<mup> PR snapcraft#2012 opened: pluginhandler: only do elf checking and patching for type app <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2012>
<Chipaca> niemeyer: you mean because it's going into a tabwriter?
<niemeyer> Chipaca: Is that the io.Writer? If so, my point is moot..
<Chipaca> right now it is, but it could just be the terminal
<niemeyer> Chipaca: In that case the easiest would be to just return the error from these functions.. and let the call site decide to ignore it or not
<Chipaca> (the description cuts the tabbing anyway)
<Chipaca> niemeyer: k
<Chipaca> niemeyer: pedronis: also note i addressed the issues in #4790
<mup> PR #4790: jsonutil/puritan: introducing puritan.String & etc <Created by chipaca> <https://github.com/snapcore/snapd/pull/4790>
 * Chipaca goes back to snapshots
<mup> PR snapcraft#2013 opened: tests: run tests on Trusty on Travis <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2013>
<mup> PR snapd#4887 opened: snapstate: add compat mode for default-provider <Created by mvo5> <https://github.com/snapcore/snapd/pull/4887>
<mvo> niemeyer: -^ (cc kenvandine )
<mvo> niemeyer: and thank you for your input on this!
<zyga> mvo: question about this pr
<zyga> will this be any problem on reverts?
<zyga> or is the :ifname part totally irrelevant and was never used
<niemeyer> Chipaca: Thanks, approved, with a note
<jdstrand> zyga: ack (i was already there)
<niemeyer> mvo: Thanks!
<niemeyer> mvo: LGTM
<niemeyer> zyga: Yes, it's irrelevant
<zyga> ack, +1 then
<niemeyer> We may actually use this some day, but not today
<jdstrand> s/i/it/
<niemeyer> zyga: The only reasonable thing to have there is the actual slot of the default provider.. if people put random content it may eventually stop working indeed
<niemeyer> but not a problem we need to worry about today
<mborzecki> hm glxinfo from inside the snap segfaults too
<Chipaca> zyga: did you say we had an implenetation of OpenAt already?
<zyga> Chipaca: we have something that's very similar in secureMkPrefix
<Chipaca> zyga: ah, ok, then I'll leave it for later
<mborzecki> anyone intimately familiar with glvnd?
<zyga> not intimately
<zyga> but I read the source of it once
<zyga> but ask in #ubuntu-desktop maybe
<zyga> and ask around upstream
<mborzecki> zyga: i'm looking into why snaps segfault on arch with nvidia, apparently even glxinfo segfaults, bt points to glvnd: https://forum.snapcraft.io/t/nvidia-proprietary-driver-no-h-w-acceleration-in-chromium-and-firefox-stack-mashing-problem-also/4532/8
<mvo> a review for 4874 would be great, should be easy
<mup> PR snapd#4843 closed: interfaces/builtin: let MM change qmi device attributes <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4843>
<zyga> mborzecki: did you manage to get a backtrace?
<zyga> mvo: doing that now
<mup> PR snapd#4876 closed: packaging: recommend "gnupg" instead of "gnupg1 | gnupg" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4876>
<zyga> mvo: I tweaked spread.yaml to break if there's a snap-confine profile with some garbage in the filename
<zyga> and I'm running this in a main/ loop
<mup> PR snapd#4883 closed: debian: undo snap.mount system unit removal <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4883>
<mvo> zyga: ta
<pstolowski> mvo: the sanitize changes are more annoying than I thought (due to the tests)... i'm almost there
<mvo> pstolowski: yeah, I feared it might be. thanks for pushing it through
<pstolowski> mvo: amazing for 1 line fix :D
<mup> PR snapd#4888 opened: snap-confine: fallback to /lib/udev/snappy-app-dev if the core is older <Created by mvo5> <https://github.com/snapcore/snapd/pull/4888>
 * kalikiana wrapping up for today
<zyga> mvo: let's keep (2.23) in the PR name if we can, some things will get confusing very quickly
<mborzecki> zyga: temporarily disabled aslr, bt https://paste.ubuntu.com/p/TwRRRVZHYs/ strace https://paste.ubuntu.com/p/QdsZHM2rnz/
<zyga> mborzecki: can you list all the files in the nvidia and libglvnd files
<zyga> er
<zyga> packages
<zyga> and compare that to what is visible in /var/lib/snapd/lib/gl
<zyga> (as symlinks)
<mup> PR snapd#4874 closed: tests: a bunch of test fixes for s390x from looking at the autopkgtest logs <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4874>
<zyga> mborzecki: is it possible that libglvnd is compiled with newer libc than the snap
<zyga> and that causes the incompatibility?
<zyga> I long suspect this will bite us
<zyga> and that we need to ship libglvnd and all the other userspace drivers in separate overlay/content snaps
<mborzecki> zyga: well, it's possible, it's symlinked from hostfs atm
<mvo> zyga: +1
<mvo> pstolowski: heh, indeed
<zyga> yes, I know it is :(
<zyga> mborzecki as a hack:
<zyga> mborzecki: grab xenial chroot
<zyga> compile libglvd
<zyga> and drop it into that namespace instead of those symlinks
<zyga> just libgldv
<zyga> the only parts of userspace from hostfs you can use are the binary driver from nvidia
<zyga> all the other parts compile on xenial chroot
<zyga> if that fixes the issue we will have our answer
<Pharaoh_Atem> zyga: you guys know glvnd hasn't been working correctly with snapd forever now, right?
<zyga> Pharaoh_Atem: ish, yes
<mborzecki> Pharaoh_Atem: i didn't :P
<Pharaoh_Atem> it's been an issue in Fedora for a while
<zyga> it has been working in the past to some extent
<Pharaoh_Atem> it only works with Mesa drivers
<zyga> but it's a perpetual todo
<Pharaoh_Atem> well, now that it's in Ubuntu 18.04, now hopefully it'll get fixed :P
<zyga> Pharaoh_Atem: this reminds me of the run towards 16.04
<zyga> I don't miss that
<Pharaoh_Atem> mborzecki: at one point or another, I've had reports on almost every single snapd update about it
<Pharaoh_Atem> but there's nothing I could do about it as I have zero nvidia hardware to debug with
<zyga> I suspect it may require non-trivial work
<Pharaoh_Atem> no kidding
<popey> zyga: can someone please triage bug 1756793 so it has the right assignment and priority? Otherwise it outwardly looks like we're not on top of it
<mup> Bug #1756793: Can't run snaps on Ubuntu 18.04 <amd64> <apport-bug> <bionic> <package-from-proposed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1756793>
<gQuigs> trying to snap sosreport - and stuck at it needing a file to exist: /etc/sos.conf.  It needs to be a classic snap.  Is there a way to have this file created?  - https://github.com/sosreport/sos
<zyga> popey: it's already fixed but we need new package out
<zyga> popey: we debugged this earlier today
<zyga> I'll update the bug report
<popey> (this should also be on the bug)
<zyga> done now, I was not aware of the bug report before
<popey> I just rebooted on advice of the bug - closing down all my currently running apps - and now I've rebooted I have an unusable workstation - none of the snaps I use launch
<zyga> popey: refresh to beta please
<zyga> that's sufficient AFAIK
<popey> zyga: that worked. might want to let people on the bug know that's a valid workaround until the package lands.
<zyga> done
<popey> Thanks
<zyga> and I'm sorry, I did see this bug before
<popey> I appreciate there's like 3 threads on the forum and a bug.
<popey> Our direction from the top is to file and update bugs. So that's why I'm poking :)
<mup> PR snapd#4889 opened: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
<zyga> mvo: I pushed and opened the trespassing PR
<zyga> and I need to leave now
<Chipaca> pedronis: do you know if there's an easy way (and if it's sane) to add an already-done task to a taskset, just to have a place to Logf() ?
<zyga> my laptop is looping through all of master
<zyga> er main
<zyga> hopefully something will come up
<pedronis> Chipaca: ?
<pedronis> I'm not sure IÂ even parse the question
<pedronis> Chipaca: what are you trying to do?
 * pedronis needs to go have dinner
<niemeyer> Need to step out for a while.. will be back later today
<mup> PR snapcraft#2014 opened: integration tests: snap tests shouldn't be arch-specific <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2014>
<Chipaca> pedronis: sorry, was preparing dinner myself =)
<Chipaca> pedronis: my issue is that I have a list of non-fatal errors produced at the start of any of the exported snapshotstate taskset-returning public functions
<Chipaca> and I thought I could log them
<Chipaca> there, against the task
<Chipaca> or I could return them all the way out to daemon and up
<Chipaca> the latter might be easier, as it's a rather unique case, hm
<pedronis> Chipaca: you can return both a taskset and a error
<pedronis> if the caller can deal
<Chipaca> yeah
<pedronis> logging them on the task is weird
<Chipaca> they're just informative so yeah
<Chipaca> pedronis: go have dinner :-) thanks
<pedronis> I'm back
<Chipaca> ah! ok
<Chipaca> it'll be a map[string]error, but, yeah
<Chipaca> it's not an error in doing the thing, it's an error in listing the snapshots
<Chipaca> which i was previously ignoring but at the sprint we decided to talk about
<Chipaca> i mean, to alert the user about
<mvo> zyga: thank oyu
<mvo> zyga: once bionic is happy again I will look
<mup> PR snapd#4887 closed: snapstate: add compat mode for default-provider <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4887>
<mup> PR snapd#4888 closed: snap-confine: fallback to /lib/udev/snappy-app-dev if the core is older (2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4888>
<mup> PR snapcraft#2015 opened: docs: add execstack to HACKING.md's list of deb deps <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2015>
<mup> PR snapcraft#2015 closed: docs: add execstack to HACKING.md's list of deb deps <docs> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2015>
<mup> PR snapcraft#2016 opened: demos: use realpath in command entry for java-hello-world <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2016>
<kyrofa> Hey stgraber, I'm kind of pushing the limits here, but I installed lxd on my rpi2 with Ubuntu Core on it, but can't get snaps to mount within a container, even with squashfuse installed. Any chance you've tried snaps in LXD on armhf?
<mup> PR snapcraft#2012 closed: pluginhandler: only do elf checking and patching for type app <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2012>
<stgraber> kyrofa: what kernel are you using?
<kyrofa> stgraber, 4.4.0-1030-raspi2
<stgraber> is that an official ubuntu kernel? if not, you won't have unpriv fuse as that's not upstream
<kyrofa> stgraber, I assume so, it's our reference Ubuntu Core image for the rpi
<stgraber> kyrofa: cat /sys/module/fuse/parameters/userns_mounts
<kyrofa> stgraber, N
<stgraber> try echo "Y" into it
<mvo> niemeyer: your opinion on 4882 would be great
<stgraber> should be Y by default on Ubuntu kernels though... it is on my 4.4.0-116-generic here (armhf)
<mup> PR snapcraft#2017 opened: many: optimize retrieval of the linker version <bug> <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2017>
<kyrofa> stgraber, ha! Works
<kyrofa> Think that's a bug, then?
<stgraber> well, I don't know, that setting was changed a while back
<stgraber> and you're running a super outdated kernel
<stgraber> current 4.4.0 for raspi2 is -1085
<stgraber> and you've got -1030 so you're months if not over a year out of date
<kyrofa> ppisati, any chance you're around?
<kyrofa> Probably not. stgraber I'll chase that one down, thanks for your help :)
<stgraber> kyrofa: your kernel dates back from Nov 2016 :)
<stgraber> kyrofa: so yeah, don't run that
<jdstrand> kyrofa: what is snapcraft-pr?
<jdstrand> kyrofa: and hi! :)
<kyrofa> jdstrand, hey! snapcraft-pr is essentially a set of shell scripts that sets up a venv for a given snapcraft pull request and then runs that snapcraft. Basically, it's me automating what I have to do several times a day
<jdstrand> kyrofa: is it useful for more than just you? you've requested classic confinement... perhaps request it formally?
<kyrofa> jdstrand, maybe, but it's pretty developer-focused. Ideally build.snapcraft.io would just build snaps of each PR, which would probably make this tool unnecessary
<jdstrand> kyrofa: I'm not sure how to proceed with that... I have a process I'm supposed to follow. I mean, technically I can add it, but based on this, it seems like a discussion in the forum might prompt improvements that make the snap unnecessary
<kyrofa> jdstrand, follow your process, you can reject it without incurring my wrath
<mup> PR snapd#4890 opened: snap: Call SanitizePlugsSlots from InfoFromSnapYaml <Created by stolowski> <https://github.com/snapcore/snapd/pull/4890>
<pstolowski|afk> mvo: ^
<zyga> re
<zyga> I got /usr/lib/go-1.6/pkg/tool/linux_amd64/link: running gcc failed: fork/exec /usr/bin/gcc: cannot allocate memory
<zyga> that's fun but unexpected
<zyga> restarted loop
<cwayne> mvo: hi, so should we be on the lookout for a new core in beta soonish then?
<Saviq> cachio: hey, did you guys do something to spread so that it started launching i686 images on google?
<Saviq> how can I request amd64 ones?
<Saviq> cachio: https://travis-ci.org/MirServer/mir/jobs/356038699
<vidal72[m]> on beta/edge core snap channel every app tries to read /proc/sys/kernel/seccomp/actions_avail on startup which is blocked by apparmor. Is it known issue?
<vidal72[m]> another thing: is it possible to permanently unplug snap form slot? After update everything is coming back to defaults
<zyga> vidal72[m]: hey, yes' that is a known issue
<zyga> vidal72[m]: I was planning on fixing it
<zyga> vidal72[m]: but if you want to take a bite at the code, look at release/seccomp.go
<zyga> vidal72[m]: and make the initialization there lazy (on first real use)
<zyga> vidal72[m]: that will fix the issue
<zyga> vidal72[m]: the auto-reconnect bug is fixed in edge now (and in master)
<zyga> vidal72[m]: I believe pstolowski|afk can tell you more about that tomorrow
<zyga> vidal72[m]: but if you build snapd from git you should no longer see that behavior
<zyga> cachio: some tests are leaking "snap userd" processes
<zyga> and those pile up in -reuse VMs
<zyga> also plenty of dbus-daemon
<zyga> specifically plenty of usr/bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
<vidal72[m]> so snapd-git and core --edge are both needed?
<mup> PR snapcraft#2014 closed: integration tests: snap tests shouldn't be arch-specific <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2014>
<zyga> vidal72[m]: technically no, it depends if reexec is enabled
<zyga> vidal72[m]: on some distributions, for instance on debian stable, snapd in the package re-exec itself from the core snap
<zyga> vidal72[m]: this is not yet avialable everywhere as some strings are attached
<zyga> vidal72[m]: and on arch for instance it is disabled
<zyga> vidal72[m]: (in general the snapd build in the core snap must be compatible with the distribution and we still have a few compile-time choices in the C code)
<zyga> vidal72[m]: if you take snapd from git you should be ok
 * zyga restarted his test loop and resumes being mostly AFK
<mup> PR snapd#4816 closed: tests: move xenial i386 to google backend <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4816>
<cachio> Saviq, you should call it like we do https://github.com/snapcore/snapd/blob/master/spread.yaml#L54
<cachio> Saviq, take a look to that file, we are configuring the machines for google there
<cachio> zygan which testS?
<cachio> zyga, which testS?
<Saviq> cachio: ack
<cachio> Saviq, fedora should be working now with the new spread
<Saviq> cachio: do I need to ask for a drive size or does it default to a bigger one?
<cachio> Saviq, the default is 10 gb
<cachio> as it was in linode
<Saviq> ack
 * cachio afk
<pedronis> zyga: do we have a list of directories that are prohibited in layouts?  IÂ thought we planned to have  one
<zyga> pedronis: one sec
<zyga> pedronis: https://github.com/snapcore/snapd/blob/master/snap/validate.go#L660
<zyga> pedronis: those places are off limits
<zyga> pedronis: are you thinking about store-side validation?
<pedronis> zyga: no, I'm thinking about your new branch and the tmpfs check
<zyga> cachio: I don't know which test, I observed this by running all of main in a -reuse loop in qemu all day
<pedronis> for example run is a tmpfs
<zyga> pedronis: ah
<pedronis> but is in the prohibited list
<zyga> pedronis: yes, that's safe because it's disallowed there
<zyga> pedronis: as I wrote in the comment it is not perfect, ideally we'd allow only mimics and well-known places (/tmp)
<zyga> oh, I see real failures in that PR
<zyga> drat, I need to look at that
<vidal72[m]> zyga: I have core --edge and curent snapd-git. I did snap revert <app>, disconnected slot, snap refresh <app> and slot is connected again
<zyga> hmmm
<zyga> revert does some things that can cause this to go back
<zyga> revert is really "I liked previs revision better"
<zyga> if you install a snap
<zyga> disconnect something
<zyga> and then refresh (not revet) to another revision
<zyga> it should not auto-connect
<zyga> s/previs/previous/
<pedronis> zyga: IÂ left a comment in the PR
<zyga> thank you
<vidal72[m]> zyga: I made changes after revert, not before and updated with refresh
<zyga> hmm, in that case you want to talk to pstolowski|afk tomorrow
<zyga> it smells like a bug
<vidal72[m]> zyga: ok, thx
<pedronis> zyga: the fix not to re-autoconnect is still up for review
<pedronis> is not landed even
<zyga> ohh
<zyga> I see, I must have read it and assumed it is merged
<zyga> vidal72[m]: ^
<zyga> vidal72[m]: you can perhaps review the code to learn more about how this works
<zyga> vidal72[m]: https://github.com/snapcore/snapd/pull/4551
<mup> PR #4551: ifacestate: do not auto-connect manually disconnected interfaces <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4551>
<vidal72[m]> zyga: pedronis ok, thx for info
<vidal72[m]> zyga: when we talk about PR...as PR my was approved what happens next?
<zyga> vidal72[m]: it will get merged
<zyga> vidal72[m]: it's just that now we have a bit of a fire to put out
<zyga> vidal72[m]: with bad bionic package and overdue release
<zyga> vidal72[m]: and important bugs surfacing
<zyga> all at the same time
<vidal72[m]> zyga: ok, no pressure from me :)
<pedronis> zyga: do we protect about trying to mount with layout  to /var/lib/snapd/hostfs
<pedronis> or below?
<zyga> those things are mounted as slave so none of those matter
<zyga> if you mount something there it won't show up in the host
<zyga> still, I think it's something we could forbit explicitly
<mup> PR snapcraft#2016 closed: demos: use realpath in command entry for java-hello-world <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2016>
<mvo> pstolowski|afk: woah, thank you! that was a long day for you, appreciated
<mvo> cwayne: new beta tomorrow, there is a bit of a discussion how to best fix this right now
<cwayne> mvo: ack, thanks. no rush just wanted to make sure we werent holding you guys up
<mvo> cwayne: heh, thank you!
<niemeyer> cachio: ping
<cachio> yes
<cachio> niemeyer, the change is pushed
<niemeyer> cachio: Thanks for that
<cachio> and i386 is merged
<niemeyer> cachio: The placeholder should remain as %q there
<niemeyer> cachio: It's just the variable that needed changing
<niemeyer> cachio: This is a parsing error.. %q tells us what exactly was being parsed
<niemeyer> %s won't.. at least not clearly
<cachio> niemeyer, ok, just 1 min
<cachio> niemeyer, done
<niemeyer> cachio: Thanks!
<cachio> niemeyer, with this change debian-9 should be ready to be merged
<niemeyer> cachio: I'm merging and releasing.. just a sec
<cachio> niemeyer, sure
<niemeyer> cachio: It's in, thank you!
<niemeyer> cachio: Let me release it..
<cachio> niemeyer, great!!!! thanks for reviewing that
<niemeyer> cachio: My pleasure, and thanks for the change. It's a nice tweak.
<niemeyer> cachio: Travis release is up
<cachio> niemeyer, great
<cachio> niemeyer, re triggering jobs
<niemeyer> cachio: Snap is up too, btw
<vidal72[m]> is snapd in debian stretch usable? (2.21 version is quite dated)
<mwhudson> jdstrand: ayt?
#snappy 2018-03-21
<mup> PR snapcraft#2017 closed: many: optimize retrieval of the linker version <bug> <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2017>
<mup> PR snapcraft#2018 opened: tests: minor fixes to autopkgtests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2018>
<mup> PR snapcraft#2018 closed: tests: minor fixes to autopkgtests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2018>
<mup> PR snapd#4578 closed: Expose payment and account URLs in /v2/system-info <Created by robert-ancell> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4578>
<mborzecki> morning
<zyga> good morning
<mborzecki> zyga: hey
<zyga> I lost my phone
<mborzecki> ayy
<zyga> I put it somewhere and now I cannot find it
<zyga> and it's on mute
<zyga> na
<zyga> man :)
<zyga> it's somewhere at home
<zyga> or the dog ate it very very politely ;-)
<mborzecki> well, that might still be a problem
<zyga> I need to fix https://github.com/snapcore/snapd/pull/4889
<mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
<zyga> and then I'm blissfully happy and can help mvo with the release
<mborzecki> jokes aside, i'll be looking into glvnd today, didn't manage to do anything yday, my son has flu-like thing again, so fever and the rest of the package
<zyga> mborzecki: uhh, not fun
<zyga> this winter is not going anywhere it seems
<zyga> but, it's spring time (officially)
<zyga> I need to wake kids up
<zyga> mborzecki: I was thinking about making sense of prepare restore
<zyga> mborzecki: and I came up with a very simple mechanism for making it modular and understandable
<zyga> mborzecki: so that we can put some code affecting a given concept in a single file
<zyga> mborzecki: and that file can affect any phase of the lifecycle (prepare project, suite, test, restore, etc)
<zyga> mborzecki: I will propose the mechanism first and then chop prepare-restore into parts and move it there piece-by-piece
<zyga> mborzecki: I did this while running tests all day, looking for the bug that was blocking master yesteday
<zyga> mborzecki: I did not reproduce the bug ever
<zyga> mborzecki: but I did find that we leave snap userd processes around
<zyga> mborzecki: and that leak dbus-daemon processes (probably in the same tests)
<zyga> mborzecki: and that my 1.5GB VM runs out of memory after a few hours just because there are so many of those
<zyga> mborzecki: anyway, I'll get some coffee and start proposing this
<mborzecki> zyga: hm yeah, we should kill whatever userd is left after the test completes
<zyga> yes, that's obvious
<zyga> just our way of doing prepare restore is making it hard to ensure and reason about
<mborzecki> zyga: that might be the reason for one of the failures that pstolowski saw
<mborzecki> although that was in unt tests
<zyga> the scripts are too large now
<zyga> and not maintainable much
<mborzecki> heh running into build problems with glvnd on xenial, i'm probably better of pulling the source package from bionic
<zyga> good luck with that!
<zyga> I need to manage kids a little bit
<zyga> then I'll be back
<mborzecki> hm given the problems, we should look into having at least one spread test that tries to run glxinfo on a host with nvidia/radeon/intel, perferrably also something with PRIME
<zyga> mborzecki: yeah, this is not supe easy due to infra
<zyga> mborzecki: I wanted to have a rule where each release is tested on a modern nvidia machine running 16.04 and now 18.04
<mborzecki> zyga: maybe at least during validation
<zyga> so that we have reasonable coverage of the most popular release
<zyga> yes
<mborzecki> zyga: and radeon would be intersting too, amdgpu probably works since it's mesa, but i'd guess the pro variant is broken
<mborzecki> zyga: you have r9 right? :)
<zyga> mborzecki: yes
<zyga> mborzecki: I can boot and test things periodically for release
<zyga> I was thinking about selling this t470 and getting some variant with the nvidia 150 GPU
<zyga> or was it MX150
<zyga> something like that
<zyga> low end modern core GPU
<zyga> oh, it's just 1030 relabelled
<zyga> wow, that's impressive then
<zyga> It seems I want T480s
<zyga> eh, expensive
 * zyga wonders when the next laptop refresh cycle is 
<mborzecki> extgpu?
<zyga> or that :)
<zyga> but I'd have to check that it 1) works 2) doesn't need external display
<zyga> I want only one display, the one in my laptop
<mborzecki> i still need to buy one of rx580/vegas, 1030 is to be only the backup card, the more powerful one will go for passthrough
<zyga> do you want one r9 280x?
<zyga> I have two
<mborzecki> vega :P but I need to wait for btc/xmr/eth to drop
<zyga> haha
<zyga> yes, that's sad :)
<mborzecki> the prices are dropping though, slowly but still, just enough to keep the hopes up
<zyga> I think at this rate we'll skip a gen or two
<mborzecki> zyga: i have libglvnd rebuilt for xenial, what would be the best way of getting that into the namespace of a snap?
<zyga> so, dragons ahead but let's try this
<mborzecki> mount bind it somewhere and nsenter?
<zyga> open a shell with nsenter -m/run/snapd/ns/foo.mnt
<mborzecki> haha that's what i thought :P
<zyga> then inside that shell go to /var/lib/snapd/lib/gl
<zyga> then it should be a swarm of symlinks, remove them (or move them aside) all
<zyga> the place should be a tmpfs, unpack your deb there
<zyga> use ldd to see if things resolve one by one
<zyga> and let's see what we have
<zyga> mvo is not around, I hope he's okay
<zyga> good morning mvo
<mvo> hey zyga
<mborzecki> mvo: morning
<mborzecki> zyga: bad news, still segfaulting, although i have a nicer backtrace now
<zyga> that's better now
<zyga> can you list all the files in that directory?
<zyga> as seen from inside the nsenter world
<mborzecki> zyga: https://paste.ubuntu.com/p/jBSVD8bG84/
<zyga> is lrwxrwxrwx 1 root   maciek     53 Mar 20 17:52 libEGL_nvidia.so.390.42 -> /var/lib/snapd/hostfs/usr/lib/libEGL_nvidia.so.390.42 this okay?
<zyga> can you triple check that we only ever open things that are in the nvidia download for linux
<zyga> nothing distros build
<mborzecki> zyga: yes, that's the glvnd part on nvidia's side
<mborzecki> zyga: bt https://paste.ubuntu.com/p/G9SdS24tTJ/
<zyga> actually, just download that an unpack it somewhere
<zyga> yes, this does look better
<mvo> hey mborzecki - good morning!
<zyga> mborzecki: another idea, move them out of hostfs
<zyga> in case some logic then looks at files in the same directory
<zyga> little by little well' get to the bottom of this :)
<kalikiana> moin moin
<mwhudson> pedronis: er how can i make a date string that snap set core refresh.hold= accepts?
<mwhudson> date --rfc-3339=seconds doesn't do it
<mwhudson> ahh --iso-8601=seconds
<pedronis> yes
 * pedronis breakfast
<zyga> mborzecki, mvo: https://github.com/snapcore/snapd/compare/master...zyga:feature/test-modules-and-phases?expand=1
<zyga> I will open it as soon as I get a pass on my machine
<Chipaca> moin moin
 * Chipaca not really here yet
<mvo> hey Chipaca
<Chipaca> zyga: did the themes thing land at any point?
<Chipaca> mvo: how's things on this lovely spring day?
<mvo> zyga: interessting idea
<mvo> Chipaca: things are in progress, we almost landed a fixed 2.32 in bionic, one autopkgtest issue though
<Chipaca> asking about themes because of this 'papirus theme crashes snapped evince' thing
<mvo> zyga: is all your 2.32 stuff in PRs now? threspass was the last one?
<Chipaca> mvo: nice
<mborzecki> zyga: hm this doesn't make sense, the segfault is in a mt_mutex_lock (a wrapper around pthread_mutex_lock), it is called a couple of times before the place where it segfaults and seems to work ok, i've confimed that it's trying to load "libGLX_nvidia.so.0", does that successfuly and then goes on to allocate new vendor id and this is where the crash happens
<mborzecki> zyga: the wrappers are initialized into a larger struct, and the symbols are picked up one by one using RTLD_DEFAULT at the very beginning
<mborzecki> zyga: unless loading libGLX_nvidia.so.0 break all this
<mvo> zyga: https://api.travis-ci.org/v3/job/355950075/log.txt is interessting, I added code to reset.sh that checks for the snap-confine profiles and it explodes in what looks like total random places
<zyga> mborzecki: it must be doint something when it loads libGLX_nvidia
<zyga> maybe some constructors fire and they clobber things
<zyga> mvo: I added the same thing I suspect
<mvo> zyga: same result?
<mborzecki> i have a trace with LD_DEBUG=all, gonna look at it now
<zyga> https://www.irccloud.com/pastebin/hyOQrz3C/
<zyga> mvo: ^ I never managed to reproduce it
<zyga> not once, it ran for 12 hours
<mborzecki> oh, or coffee first
<zyga> mvo: I ran into two bugs where my test VM ran out of memory though
<zyga> mvo: I will fix those separately
<mvo> zyga: interessting, it seems to happen in google everytime, I wonder if something strange is going on in the google vm
<mborzecki> it'd be really nice to have a 'debug' image of the core snap (tar.[gx]z), that you could just set your gdb sysroot to
<zyga> oh
<zyga> mvo: we reuse machines in google
<zyga> oh we don't sorry
<zyga> mvo: I need to take the dog out, I opened 4891 for the phase/module system
<zyga> mvo: and I'll porpose that anomaly detector I pasted above next
<mup> PR snapd#4891 opened: tests: add support for phased prepare-restore logic <Created by zyga> <https://github.com/snapcore/snapd/pull/4891>
<zyga> mvo: I'll be back in 20 minutes
<pstolowski> Morning!
<mborzecki> pstolowski: Chipaca: kalikiana: morning guys
<mvo> zyga: is all your 2.32 stuff in PRs now? threspass was the last one?
<zyga>  It is the last one
<mvo> zyga: I just looked at the threspass PR and the errors in the spread run look real (at least some)
<zyga> Yes
<zyga> See my comment there
<zyga> I will fix after the walk
<mvo> zyga: aha, sure, thank
<mvo> s
<mup> PR snapd#4884 closed: debian: run snap.mount upgrade fixup *before* debhelper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4884>
<mup> PR snapd#4879 closed: tests: revert "tests: disable 18.04 spread tests in google for now" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4879>
<mup> PR snapd#4881 closed: tests: make tests run with specific bionic release avoiding take the last one <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4881>
<zyga> re
<pedronis> mvo: Chipaca: have you seen this  https://forum.snapcraft.io/t/var-cache-snapd-commands-db-permission-denied/4590  seems CNF stuff breaks inside classic snap
<zyga> hmm, I just saw /etc error on google
<zyga> man, I need to run a google loop next
<mvo> pedronis: looking
<Chipaca> pedronis: nice
<pedronis> zyga: as I said my PRs atm get it all the time
<mvo> jdstrand: afaict #4509 is unblocked now, do you want to have a final look (the interface itself is trivial) ?
<mup> PR #4509: interfaces/builtin: add support for software-watchdog interface <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4509>
<zyga> pedronis: I'm testing this against google now
<mup> PR snapd#4885 closed: Specify charset in po/snappy.pot <Created by gunnarhj> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4885>
<mup> PR snapd#4892 opened: tests: update tests to deal with s390x quirks <Created by mvo5> <https://github.com/snapcore/snapd/pull/4892>
<mup> PR snapd#4893 opened: po: specify charset in po/snappy.pot <Created by mvo5> <https://github.com/snapcore/snapd/pull/4893>
<mvo> zyga: 4765 has a conflict, otherwise its good to go
<zyga> Thanks, resolving now
<jibel> hi, I'm on bionic and I cannot start spotify.
<jibel> it fails with
<jibel> $ /snap/bin/spotify
<jibel> execl failed: No such file or directory
<jibel> child exited with status 1
<jibel> anyone seeing this?
<zyga> jibel: hey this is a known issue
<zyga> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1756793
<mup> Bug #1756793: Can't run snaps on Ubuntu 18.04 <amd64> <apport-bug> <bionic> <package-from-proposed> <snapd (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1756793>
<jibel> zyga, ah it's the same. Thanks!
<mvo> jibel: the snapd in -proposed fixes it, also sudo snap refresh --beta core should work too
<jibel> mvo, yes, I saw the workaround but I'll stay on candidate and wait for the fix.
<jibel> is there a way to set configuration options when snapd starts like in a config file instead of running "snap set ..." ?
<mvo> jibel: thanks. autopkgtest is green now so the new snapd should make it to bionic soon (we need to override s390x, autopkgtest is a bit confused, it thinks there is a regression but in reality it was skipped because it was container virt until very recently)
<mvo> 4890 needs a second review
<zyga> mvo: doing that
<mvo> ta
<mup> PR snapd#4894 opened:  snap: Call SanitizePlugsSlots from InfoFromSnapYaml (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4894>
<mup> PR snapd#4895 opened: cmd/snap-confine: fix ptrace rule with snap-confine peer (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4895>
<cachio> hey zyga mvo could someone take a quick look to #4778, we already fixed spread and it it passing
<mup> PR #4778: tests: moving debian 9 from linode to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4778>
<cachio> mvo, about sru, did you reduce the amount of tests to run for autopkgtests?
<cachio> because I see that all of them were executed
<mborzecki> zyga: i suspect the problem may be TLS related
<zyga> tls?
<zyga> thread local storage?
<mborzecki> yes
<mborzecki> i've reordered some calls and got stack smashing detection to abort the binary
<mborzecki> though outside of libglvnd, so i rebuilt libglvnd with -fstack-protector -fstack-protector-all and went on debugging
<mborzecki> stepped through the prologue, pick up the canary, figure out an address and try cathing with watchpoints, nothing turns up
<mborzecki> and the thing is that the value at the address does not change
<mvo> cachio: for 2.32 the number of tests in autopkgtest will be reduced, I hope we can get 2.32-final today
<mvo> cachio: a bunch of the expensive ones (core transiton) are disabled
<cachio> mvo, ok
<mborzecki> but at the end of the function, the canary is calculated again, there's:
<mborzecki>    â0x7ffff721365e <__glXLookupVendorByName+7862>   mov    -0x18(%rbp),%rbx                                                                                                                                                                   â
<mborzecki>    â0x7ffff7213662 <__glXLookupVendorByName+7866>   xor    %fs:0x28,%rbx
<mvo> cachio: some stuff is still flaky
<mborzecki> zyga: and $fs is different this time
<mvo> cachio: like it looks like the upstream autopkgtest env is (somtimes) super slow
<cachio> mvo, is it gona be a new snapd for sru?
<mvo> cachio: and that kills tests
<mborzecki> zyga: thought this should not change
<cachio> mvo, or I should continue with 2.31.2
<mvo> cachio: I think so, I think we can go with 2.32
<zyga> mborzecki: does it happen if you run the same app outside?
<zyga> mborzecki: I wonder what is at fault now
<mborzecki> outside of snap stuff works
<mborzecki> i'd guess libc/pthread or something close by
<mborzecki> let me debug this a bit more
<xnox> mvo, you can propose "force-badtest snapd/s390x/<the right version>" into hints-ubuntu branch of britney..... documenting the override.....
<mborzecki> mvo: snap run --gdb is very nice, although `run` in gdb does not work :/
<cachio> mvo, ok
<mvo> xnox: I hope the next upload fixes the two remaiing tests
<mvo> mborzecki: indeed, just "continue"
<jibel> Laney, mvo (repeating from #u-desktop) On a live session, it seems that setting refresh.hold triggers a refresh https://paste.ubuntu.com/p/CKmgFZ8vHV/
<jibel> mwhudson, ^
<jibel> mvo, I repeated the experiment twice and there is a refresh event immediately after setting the config option.
<jibel> on a live session we don't want any update at all
<mvo> jibel: this is core                  16-2.31.2  4206  canonical  core
<mvo> jibel: we need 2.32 for this to work
<jibel> ah crap
<mvo> jibel: oh, hold on
<mvo> jibel: what does `snap version` print?
<mvo> jibel: the core snap is 2.31.2 but snapd on bionic may be newer
<jibel> 2.31.2
<mvo> jibel: ok, curious, why? is there a delay in the updates?
<mvo> jibel: could you try to manually install the new snapd in the live-cd?
<jibel> mvo, I'll try with a newer version
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/4890#pullrequestreview-105677607
<mup> PR #4890: snap: Call SanitizePlugsSlots from InfoFromSnapYaml <Created by stolowski> <https://github.com/snapcore/snapd/pull/4890>
<zyga> https://www.irccloud.com/pastebin/mD9VRH2i/
<mvo> jibel: thank you
<zyga> pedronis: ^ does this make sense?
<zyga> I have a debug shell now
<zyga> mborzecki: can you have a quick look at 4891 please
<mvo> zyga: thanks for the review!
<cachio> mvo, I' am going to the doctor now, perhaps I'll be few minutes late for standup
<mvo> cachio: ok
<mvo> cachio: good luck
<cachio> tx
 * cachio afk
<pstolowski> zyga: thanks
<mup> PR snapd#4892 closed: tests: update tests to deal with s390x quirks <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4892>
<mup> PR snapd#4890 closed: snap: Call SanitizePlugsSlots from InfoFromSnapYaml <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4890>
<Laney> jibel: I think you can `snap set' arbitrary keys before they're known, so this should work with After=snapd.service if you get that problem fixed
<mborzecki> zyga: https://forum.snapcraft.io/t/nvidia-proprietary-driver-no-h-w-acceleration-in-chromium-and-firefox-stack-mashing-problem-also/4532/12 would appreciate any advice
<zyga> ack
<zyga> mborzecki: quick question, can you link to the code of glXLookupVendorByName pelase
<zyga> *please
<mborzecki> zyga: it's there
<zyga> ah, I see now
<zyga> did you try playing with __GLX_VENDOR_LIBRARY_NAME
<zyga> or with __GLX_FORCE_VENDOR_LIBRARY_%d (%d is screen number)
<mborzecki> yeah, but I only have nvidia there
<mborzecki> and it seemed to ignore indirect
<pedronis> zyga: IÂ have a todo to improve on that
<pedronis> but it can happen
<pedronis> zyga: it's related to the fact that our retry mechanism and nonces don't go well together
<zyga> ok
<zyga> mborzecki: I think I'm lost
<mborzecki> zyga: that makes the two of us
<niemeyer> Morning all
<niemeyer> sergiusens: Can we have a quick snapcraft release supporting the new refresh-mode option?
<niemeyer> We really need a way to not be blocked by snapcraft on these new features
<niemeyer> Perhaps some sort of --force-passthrough option
<zyga> mvo: ack to merge https://github.com/snapcore/snapd/pull/4765/
<mup> PR #4765: interfaces: harden snap-update-ns profile <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4765>
<mup> PR snapd#4896 opened: store: support macaroon refreshes in store.InstallRefresh <Created by pedronis> <https://github.com/snapcore/snapd/pull/4896>
<zyga> I think you said so already but you didn't vote on it
<mvo> zyga: ack
 * zyga prepares for some backport time now
<mup> PR snapd#4765 closed: interfaces: harden snap-update-ns profile <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4765>
<sergiusens> niemeyer: I do not even know what that feature is about
<niemeyer> sergiusens: That's part of the issue :)
<niemeyer> sergiusens: https://forum.snapcraft.io/t/process-lifecycle-on-snap-refresh/140/21
<sergiusens> yeah, would be nice to be included in the conversations; I do not keep track of every single forum post (and these are easy to flag by your team as needing support from ours)
<niemeyer> sergiusens: Sergio, this is an extremely important part of that job
<niemeyer> sergiusens: If you are not reading the forum, something is not right
<niemeyer> sergiusens: Let's catch up elsewhere about this
<sergiusens> niemeyer: this is 10 days older than your post and not a single comment from the snapd team https://forum.snapcraft.io/t/architectures-keyword-for-build-snapcraft-io/4272 something is certainly wrong
<niemeyer> sergiusens: 1. I've just read it again, and still feel no need to respond; 2. That's completely irrelevant for the point I just made
<jdstrand> mvo: PR 4509 was already on my list. hope to get to it, 4868 and 4851 today (as you may have noticed, I had a lot of forum backlog to tend to)
<mup> PR #4509: interfaces/builtin: add support for software-watchdog interface <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4509>
<sergiusens> niemeyer: ok, you win, like always
 * sergiusens is not in the mood today
<niemeyer> sergiusens: I only win if we fix the problem, so not yet
<niemeyer> sergiusens: Getting back to the original point, I think we need a way to tell snapcraft to override unknown options and pass them through to snap.yaml on request
<zyga> mborzecki: By comparing the config.log between the build environments, the problem turns out to be "-fno-plt" in CFLAGS and "-z,now" in LDFLAGS, which Arch added recently. Wine built with these two flags enabled will have this issue.
<zyga> did you see that?
<zyga> also https://bugs.winehq.org/show_bug.cgi?id=43530#c35
<mborzecki> > Someone from NVIDIA confirmed it's a bug in the driver. Hopefully this will be resolved in future releases.
<mborzecki> pffff
<mborzecki> but yeah, i saw that before when it was posted in the forum
<mborzecki> anyways, not sure we would be affected, snaps are built against xenial, so we could have picked up something with libglvnd delivering libGLX*, but I've rebuilt libglvnd on xenial and replaced those pieces
<zyga> hmmm
<zyga> yes
<zyga> i think we are missing something
<Son_Goku> there's an ABI conflict that causes GL explosions
 * Son_Goku increasingly wishes he could spend time on making the Fedora core snap
<Son_Goku> kyrofa, you've not submitted https://bodhi.fedoraproject.org/updates/FEDORA-2018-81ef149b8b
<Son_Goku> it looks like you probably need to deal with this issue: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NZY3P352COQVUWMW6VRNN7CJR7TKKCAQ/
<Son_Goku> i.e.: https://fedoraproject.org/wiki/Package_update_HOWTO#Handling_feedback_from_automated_tests
<mup> PR snapd#4897 opened: Specify charset in po/snappy.pot <Created by gunnarhj> <https://github.com/snapcore/snapd/pull/4897>
<Son_Goku> err: https://fedoraproject.org/wiki/Package_update_HOWTO#Waive_the_absence_of_a_result
<Son_Goku> kyrofa ^
<sergiusens> niemeyer: ok
<zyga> Son_Goku: can you tell us more about the abi issue
<Son_Goku> zyga, what it comes down to is that the GL symbols don't bind well between Fedora GL and Ubuntu GL
<Son_Goku> the Ubuntu Core is so far in the past, things get broken when the underlying infra changes
<Son_Goku> to some extent, we're lucky that the Mesa stuff still works because of how glvnd works
<zyga> pstolowski: hey
<zyga> pstolowski: standup time
<niemeyer> Son_Goku, zyga: After we're done with the current changes, we should look into implementing a better mechanism to packing such libraries
<zyga> yes, yes yes
<Son_Goku> YES, please
<sparkiegeek> any further debugging advice for https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1757427 ?
<mup> Bug #1757427: Unable to find snap at revision, broken snaps <amd64> <apport-bug> <bionic> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1757427>
<sparkiegeek> my systemd/journald-fu is weak, so if anyone has tips on how I can figure out *why* the mount units are AWOL I'm all ears :)
<mup> PR snapd#4893 closed: po: specify charset in po/snappy.pot <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4893>
<Chipaca> #1757427 seems to be a dupe but I'm not sure of which one
<mup> Bug #1757427: Unable to find snap at revision, broken snaps <amd64> <apport-bug> <bionic> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1757427>
<sparkiegeek> Chipaca: hmm, I am aware of that bug, but it didn't seem to be the same? I didn't see the execl issue, and the workaround that zyga posted didn't work
<sparkiegeek> Chipaca: or am I missing that the underlying cause is the same?
<Chipaca> sparkiegeek: it's not the 'snap.mount makes everything broken' afaik
<Chipaca> sparkiegeek: but the other one that i don't know the bug# of
<Chipaca> sparkiegeek: the 'snap.mount makes everything broken' one is #1756793
<mup> Bug #1756793: Can't run snaps on Ubuntu 18.04 <amd64> <apport-bug> <bionic> <package-from-proposed> <snapd (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1756793>
<sparkiegeek> so right now my bug is duped to #1756793
<Chipaca> ah :-)
<Chipaca> afaik it's a separate issue, but has also been addressed if I understood zyga in the standup just now
<zyga> two bugs, yes
<zyga> to fix the other one just reboot
<zyga> (the mount is broken one)
<zyga> cachio: can you give me a reference to the failure you saw that you just mentioned
<zyga> I have some follow-up for that makes everything modular and easier to understand
<kyrofa> Son_Goku, yes, thank you, I meant to reach out to you yesterday about that
<Son_Goku> kyrofa, no problem
<kyrofa> Son_Goku, FEDORA-EPEL-2018-0c373ee2d6 has issues as well, but I can't figure out what they are :P
<Son_Goku> it has one more day left before you can push it
<Son_Goku> look at the "days to stable" on the bottom right ;)
<kyrofa> Oh! I thought they were all a week
<Son_Goku> the counter starts from when it makes it into the testing repo
<kyrofa> Ah
<Son_Goku> nope, EPEL is 14 days from when it hits testing
<Son_Goku> Fedora is 7 days from when it hits testing
<kyrofa> Okay, that makes sense then
<Son_Goku> ;)
<zyga> I will break for lunch/walk now
<mup> PR snapd#4895 closed: cmd/snap-confine: fix ptrace rule with snap-confine peer (2.32) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4895>
<mup> PR snapd#4894 closed:  snap: Call SanitizePlugsSlots from InfoFromSnapYaml (2.32) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4894>
<jdstrand> roadmr: hi! can you sync r1013 of the review tools? this will cut the review time by half
<roadmr> jdstrand: oh how does it do it? sounds magical! yes, I'll put it in the queue in a few mins (otp)
<jdstrand> roadmr: I noticed that the tools were running expensive python magic calls on files twice! now it is only once :)
<roadmr> oh hahah :) nice catch
<jdstrand> and the review time is dominated by python-magic. at some point I'll see if I can optimize further, but I thought this speed improvement quite nice
<sparkiegeek> roadmr: wait, when you said it sounds magical, did you know that it was python-magic that was fixed?!
<cachio> zyga, https://travis-ci.org/snapcore/snapd/builds/356291630#L6914
<cachio> zyga, this is quite new
<cachio> zyga, the branch should have the latest changes from master
<zyga> Ack
<mborzecki> off to pick u pthe kids
<sparkiegeek> zyga: thanks, reboot seems to have fixed that issue
<sparkiegeek> I suggest that the bug be de-duped though, since IIUC you ack'd that they are separate issues
<pedronis> zyga: I just got the snap-confine error running only google:ubuntu-16.04-64:tests/main/...
<pedronis> (using staging store but shouldn't be different)
<zyga> pedronis: the one with extra profile with garbage filename?
<pedronis> yes
 * zyga is almost back, will check stuff now
<pedronis> running from here
<pedronis> to google
<pedronis> not from travies
<pedronis> fwiw
 * cachio afk
<mvo> niemeyer: sorry for being a pain, your input on 4882 would be great, this and 4889 are the only things left for 2.32-final
<zyga> mvo: I'm about to backport things I did to 2.32
<zyga> mvo: did you do any of my branches by any chance?
<mvo> zyga: I didn't
<zyga> ok
<zyga> https://github.com/snapcore/snapd/pull/4889 is green!
<mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
<mvo> zyga: I'm fine with blacklisting the layouts test for now in autopkgtest
<zyga> ok
<mvo> zyga: unless the fixes for the test are easy and quick to backport, that is of course perferable
 * mvo needs to step out for some minutes first
<zyga> well, given that we still see odd things happening I suspect there's something broken still
<niemeyer> mvo: Will look right away
<niemeyer> zyga, mvo: Do we really want https://github.com/snapcore/snapd/pull/4765 now?  Similar changes have taken a while to stabilize.. unless this is fixing something, it doesn't seem like the right time to touch it
<mup> PR #4765: interfaces: harden snap-update-ns profile <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4765>
<niemeyer> Is that actually fixing something, or required by something else?  It doesn't look like that from the description
<zyga> niemeyer: this is fixing the open profiles per request from jdstrand
<zyga> niemeyer: when we did layouts we opened the profile for snap-confine/snap-update-ns significantly
<zyga> niemeyer: this is the last bit that undoes that
<zyga> niemeyer: jamie requested that it is present in the release
<niemeyer> zyga: Which again makes me quite concerned
<niemeyer> zyga: Previous times we played with that took a while to stabilize, and we don't have a lot of time anymore.
<zyga> right, I see
<zyga> if jdstrand acks this we can keep the open (permissive profiles)
<zyga> and land the hardening for 2.33
<niemeyer> We have plenty of other issues to worry about
<popey> https://forum.snapcraft.io/t/cant-launch-skype-snap-relocation-error/4536
<niemeyer> zyga, mvo: What's the plan for 2.32 to land in stable/
<niemeyer> ?
<popey> Any of you on 17.10 or 18.04 can reproduce this issue with skyp?
<zyga> niemeyer: I don't know more beyond prepare the release PRs and land them
<popey> Skype works on 16.04 for me, but not on 18.04. Did we break it or did they?
<zyga> gnome-shell just crashed, eh
<zyga> popey: actually, running skype on my bionic system crashes gnome shell
<zyga> I get a segvfault in xwayland
<popey> Maybe don't use wayland?
<mvo> niemeyer: I had hoped early next week, but that may be too ambitious, I want to get 2.32-final out today, two PRs left:  4889 and 4882
<zyga> popey: x11 corrputs my display
<zyga> popey: wayland doesn't
<niemeyer> mvo: Those testing periods are getting too short for the kind of change being merged I'm afraid
<zyga> (I get to pick my kind of pain, that's all)
<mvo> niemeyer: agreed, we need to be careful at this point
<mvo> niemeyer: we can extend the testing, we could add an extra week
<niemeyer> mvo: For example, we just merged that major change in the profile of snap-confine, which is fundamental for everything
<mvo> niemeyer: that might be a good idea in any case, lots of churn in 2.32
<mvo> niemeyer: that merge only hit master, no?
<niemeyer> mvo: Yeah, and not just that.. besides the timing between releases, there's the time from merge to stable
<niemeyer> mvo: IOW, merging now and branching off means pretty much only two days of testing
<niemeyer> mvo: Right
<zyga> mvo: note: I will have some backports still for 2.32
<mvo> niemeyer: release/2.32 is branched since some days alrerady, we only "cherry-pick". but we did some large cherry-picks, I guess this is your concern (and I agree)
<zyga> those that merged into master with 2.32 label
<mvo> zyga: for what exactly?
<zyga> 4898 is one
<zyga> this fixes layouts on refreshes
<zyga> (and content interface to some extent)
<mup> PR snapd#4898 opened: cmd/snap-update-ns: use x-snapd.{synthetic,needed-by} in practice <Created by zyga> <https://github.com/snapcore/snapd/pull/4898>
<mvo> zyga: hm, that is not even merged into master yet :/
<zyga> what?
<zyga> it is merged, I linked to the 2.32 PR
<mvo> zyga: oh, sorry
<mvo> zyga: this one is fine, is there more to come? (and if so, how much?)
<zyga> I think two more, one moment
<zyga> the rest is smaller
<zyga> and all are backports from master
<niemeyer> mvo: Sure, but as I understand it these changes are/were going into it?
<niemeyer> mvo: I mean, snap-confine changes, snap-update-ns, ...
<zyga> s-u-n
<niemeyer> zyga: 4889 reviewed.. I'm worried about progress in that corner
<niemeyer> zyga: Feels too loose
<mvo> niemeyer: yes, a lot of changes went into 2.32
<niemeyer> mvo: I get it, but I'm raising a more specific issue:
<niemeyer> mvo: There's a big difference between landing something in master early in the cycle, and committing something in master right before we bake the beta, even more if the idea is to have a fast release that goes to stable too quickly
<mvo> niemeyer: yes, agreed. if you want we can have a quick HO to discuss quicker (but here is fine as well of course)
<niemeyer> mvo: Yeah, let's get to the standup
<niemeyer> zyga: Can you come?
<zyga> yes
<niemeyer> jdstrand: And you too, if we're lucky enough to have you around
<abeato> tyhicks, do you know how the rng_core.default_quality kernel setting works?
<tyhicks> abeato: hey - I used to have all of those details in my head
<tyhicks> abeato: if you have specific questions, it might jog my memory
<abeato> tyhicks, if it is set to, say, 700, how is that related to /proc/sys/kernel/random/entropy_avail?
<tyhicks> abeato: give me a sec to scan the code
<tyhicks> abeato: it is starting to come back to me now... default_quality is a way to express the "Estimation of true entropy in RNG's bitstream (per mill)" for hardware random number generators that don't have a pre-defined quality value
<tyhicks> abeato: some hwrng devices have a pre-defined quality value and default_quality is ignored in those cases
<tyhicks> abeato: for devices that don't have a pre-defined quality value, default_quality is used when determining how much entropy is available after reading a certain number of bytes from the hwrng device
<tyhicks> abeato: that would then help determine the value of entropy_avail
<abeato> tyhicks, oh, ok, so it is a constant tied to the hw to help to estimate entropy
<abeato> (available entropy)
<tyhicks> abeato: that's correct
<abeato> tyhicks, got it then, thanks a lot
<tyhicks> abeato: the idea is that some hwrng devices have a known quality constant that's hard coded into the kernel sources
<tyhicks> abeato: other devices, for example, may not have enough public documentation published about them and it is impossible for the driver developer to place a pre-defined quality constant in the source code
<abeato> right, makes sense
<tyhicks> abeato: in those situations, the driver developer defines the hwrng quality as "0" and lets the system integrator/administrator define the quality constant that they are comfortable with
<tyhicks> abeato: one last tip - the range is from 0 (no quality at all) to 1024
<abeato> tyhicks, got it. Another question, is the randomness exposed through /dev/random or via /dev/hwrng only?
<mup> PR snapd#4899 opened: many: backported fixes for layouts and symlinks (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4899>
<zyga> mvo: ^ that's all of it
<tyhicks> abeato: it is injected into the /dev/random pool
<zyga> mvo: and this will also explain why some 2.32 branches were failing, the fixes are only in master
<zyga> I will take a short break and then look at adressing some feedback from the call
<abeato> tyhicks, ok, thanks
<mvo> zyga: thanks, I have a look in a little bit
<zyga> all of those were clean cherry picks
<zyga> no conflicts
<zyga> hmmm, I don't see travis running against 2.32
<mborzecki> zyga: got back just now and tried xenial chroot, glxinfo is segfaulting at exactly the same spot
<zyga> mborzecki: cool
<zyga> can you boot an unbuntu kernel
<zyga> ubuntu kernel
<zyga> and see if that makes it go away in your xenial chroot first
<zyga> and then in your snap env
<zyga> I smell a kernel option that breaks  this in arch, assuming all code is compiled with arch toolchain with some specific tweaking
<zyga> mvo: offtopic, on pre6 none of my classic snaps run
<zyga> oh, sorry, atom ran, it was just slow
<zyga> it was just skype that doesn't run
<mborzecki> ok, let's baseline, libglvnd built with xenial toolchain, nvidia 390 as it comes from arch packages, xenial chroot (from current cloud image)
<mborzecki> i'm leaving playing with ubuntu kernel (and getting the matching drivers) for tomorrow, need to prep dinner for the kids
<zyga> ok
<niemeyer> mvo: Quick thought: I think it's safer to compare the in-memory value of unmarshaling the json than the json blob itself
<niemeyer> mvo: With reflect.DeepEqual
<niemeyer> mvo: I'm considering ordering issues, etc
<jdstrand> niemeyer: sorry, I was out when I got pinged. I'll happily follow whatever outcome you, mvo and others came up with
<niemeyer> jdstrand: No worries, it's all good
<niemeyer> jdstrand: We'll just move forward, but work harder on testing this time
<niemeyer> jdstrand: So we get a similar benefit of having more resting time
<jdstrand> niemeyer: reading backscroll, it sounds like this is a 'general problem' rather than a 'specific incident' to avoid. it makes sense to be careful with what gets committed right before cutting a beta, sure
<niemeyer> jdstrand: Right, that's the key idea
<niemeyer> jdstrand: That's extra true if we need to fast track the release due to requirements
<jdstrand> it's always difficult to balance that with outside pressures, but I don't think there is anything wrong with saying "no, you need to wait" more often
 * jdstrand nods
<niemeyer> jdstrand: Yeah, definitely.. it's a careful balance
 * jdstrand nods
<mup> PR snapd#4897 closed: Specify charset in po/snappy.pot <Created by gunnarhj> <Closed by gunnarhj> <https://github.com/snapcore/snapd/pull/4897>
<mup> PR snapd#4898 closed: cmd/snap-update-ns: use x-snapd.{synthetic,needed-by} in practice (2.32) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4898>
<jdstrand> niemeyer: perhaps this is worth discussing: it sounds like this is prompted by zyga's snap-update-ns hardening branch. this is part of layouts and because everything was broken up in many PRs, the last major piece of layouts I acked some time ago, but I ack'd it conditional on (at the time) a future hardening PR such that 2.32 would have the hardening in place
<jdstrand> niemeyer: this was probably a mistake since other PRs built on top of the layouts feature and rework, and the hardening came quite a bit later and wanting to be jammed in at the last minute
<jdstrand> niemeyer: because of my conditional ack, it put zyga and everyone in a hard place since it made backing out the conditionally acked pr difficult. in the future I won't do that
 * zyga recalls the moment when we realised this was a * rw, permission
<jdstrand> niemeyer: if a similar situation comes up, I'll instead leave as 'Request changes' until the conditional followup PR is approved and ready, then they could both go at the same time
<Chipaca> hmm
<Chipaca> what's "grade" doing in snap.yaml in the wild?
<zyga> Chipaca: hiding
<jdstrand> Chipaca: personally, I use grade to make sure nothing ever goes to stable. I do this with my test snaps, for example
<Chipaca> jdstrand: but that's in snapcraft.yaml, right?
<jdstrand> I'm not sure if that was your question, but that's my answer
<jdstrand> Chipaca: grade was added to the review tools ages ago. I think it needs to be in the snap.yaml because the store looks at it to enforce things (it doesn't have snapcraft.yaml). I could be wrong. cprov should know since he added initial grade support to the review tools
<niemeyer> jdstrand: Thanks for the details, and I definitely don't blame you for that one. I think it was a reasonable decision in the context we had at the time.
<niemeyer> Chipaca: No, grade is for snap.yaml
<cprov> jdstrand, Chipaca: grade is used in the store to prevent release of `devel` revisions in stable risks (stable, candidate). What is the problem in the snap.yaml hierarchy you are referring to ?
<niemeyer> Chipaca: It's supposed to prevent people from releasing snaps into candidate and stable if they are marked as unstable
<Chipaca> I was just surprised because I didn't know all this, and snapd ignores its existence
<niemeyer> Chipaca: We should at least validate it, but we don't need to do anything with it I think
<niemeyer> Chipaca: It's a snap.yaml setting that is more critical for the store
<Chipaca> niemeyer: we don't even parse it, today :-)
<jdstrand> niemeyer: ok, thanks. I suspect attempting my suggested future workflow is a good idea. some PRs end up being quite special though.... let's hope we don't have too many more of those ;)
<niemeyer> Chipaca: I get it.. we should probably do it for validation, but it's not crticial.. it's okay for snapd to accept it. If it gets there it's too late for the setting to make sense. The store is the one that should reject it.
<jdstrand> cprov: no problem, Chipaca was wondering if it should be in snapcraft.yaml and I thought I remembered why it needed to be in snap.yaml, and mentioned you since you could back up my claim (which you did) or correct me
<niemeyer> No, it's really meant for snap.yaml.. none of snapcraft.yaml is defined in the output format
<Chipaca> jdstrand: cprov: niemeyer: it was just me being curious :-)
<cprov> :-)
<niemeyer> Chipaca: I knoooowww.. :)
<niemeyer> Chipaca: Was simply explaining it
<jdstrand> niemeyer: re snap.yaml> yep
<niemeyer> We also agreed to rename it to unstable instead of devel, but that never went through for lack of time
<jdstrand> mvo: is 'core18' the final name for the core 18 base snap? I'm adjusting the review tools for it and see it was base-18 before. core18, not core-18, right?
<Chipaca> niemeyer: I have a problem with an aspect of 'broken' snapshots
<Chipaca> niemeyer: basically one of the snapshots in a set could be broken, which means listing it in 'snap saved' is tricky
<niemeyer> Hmm
<Chipaca> niemeyer: I played with adding a '!' after the name of the snap snapshot that was broken, but (a) the information of _how_ it was broken is lost, and (b) if you have 200 snaps installed and the broken one is zzt, you won't see that '!'
<niemeyer> Chipaca: I wonder if we should expand it out
<niemeyer> Chipaca: I thought about this earlier for different reasons, but I think we never discussed it
<Chipaca> so one option would be to have a saved --long
<Chipaca> that would list more info about each set
<jdstrand> kalikiana: hi! I see the 'vendorize' snap is classic. what does it do?
<Chipaca> niemeyer: then the short listing could have a single marker to say "check engine"
<niemeyer> Chipaca: It's also pretty obscure to just have a !
<niemeyer> Chipaca: Too subtle, too rarely.. probably won't work
<Chipaca> niemeyer: you're right, I'll make it a â¼
<niemeyer> Chipaca: It worked for yaml.. :)
<Chipaca> FWIW it was: have ! in the list, and if you have any !, add a "! means broken, yadda yadda"
<niemeyer> Which probably means it's a counter example.. :P
<Chipaca> which with --long would be "! means broken, see --long"
<niemeyer> Chipaca: The current design, although not nearly as bad, reminds me a bit of snap interfaces in terms of the grouping
<Chipaca> niemeyer: the current design of snapshotses?
<niemeyer> Chipaca: No, the output format..
<niemeyer> Chipaca: I mean, we also have that sort of grouping per line on "snap interfaces"
<niemeyer> Chipaca: But we list it all, and it sucks for other unrelated reasons..
<niemeyer> Chipaca: Still, the grouping issue is similar.. we lose the ability to talk about the individual entries
<kyrofa> Son_Goku, this "waive absence of result" thing is soaring over my head. I seriously have to send a raw POST to greenwave to unblock things? What is an NVR?
<niemeyer> Chipaca: We can play with an analogy with "snap list", though
<niemeyer> Chipaca: e.g. snap list --all
<Son_Goku> kyrofa, name-version-release
<kyrofa> Ah ha
<Son_Goku> and yeah, there's a button coming to bodhi in the coming weeks
<Son_Goku> greenwave is... not fully integrated yet
<niemeyer> Chipaca: So, strawman for brainstorm: "snap saved" keeps the grouping, shows "broken" in notes similar to how it works in "snap list"  , and "snap saved --all" expands the listing to show a single snap per line (so repeated set ids, potentially), and identifies which specific snap is broken
<niemeyer> Chipaca: "snap list" can take an optional [<snap name>] as usual, in which case the output would be effectively the same as "snap list --all" filtered for that particular snap
<niemeyer> Chipaca: Waddathink?
<Chipaca> niemeyer: basic idea seems a'ight, although there's more info we could show than is conveyed by --all
<Chipaca> niemeyer: give me a minute or 5
<mup> PR snapd#4900 opened: many: use the new install/refresh API by switching snapstate to use store.InstallRefresh <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>
<Saviq> cachio: hey, we're still ENOSPC'ing on fedora... https://travis-ci.org/MirServer/mir/jobs/356462120 am I using the right images and such https://github.com/MirServer/mir/pull/267/files? (-64 suffix doesn't work yet)
<mup> PR MirServer/mir#267: [travis] move Fedora over to GCE, too <Created by Saviq> <https://github.com/MirServer/mir/pull/267>
<cachio> Saviq, try using this image --> image: fedora-cloud-base-27-1-6-x86-64
<cachio> Saviq, I'll update the name soon to make it match automatically
<Saviq> tx
<cachio> Saviq, which sprad are you using?
<cachio> are you downloading spread for each test execution?
<Saviq> cachio: Gustavo's https://github.com/Saviq/mir/blob/9df8e34b514608503f88a723ade8df4bf2446be6/.travis.yml#L57
<cachio> Saviq, this one should be updated, could you please debug the execution from your localhost and check if the host has 10GB of disk?
<kyrofa> Son_Goku, so I got the test failure from greenwave, but waiverdb-cli doesn't have the same interface as documented there, at least on f26
 * Son_Goku sighs
<cachio> just to make sure that spread is the correct one
<kyrofa> It requires an ID, and the curl command it's giving me gies me nothing :P
<Son_Goku> kyrofa, I suggest checking in #fedora-releng
<cachio> otherwise we can try adding more space
<Son_Goku> one of those folks can help
<Son_Goku> I have no clue :P
<kyrofa> Son_Goku, haha, okay glad I'm not the only one
<Son_Goku> I've been lucky enough that greenwave hasn't failed my updates yet
<Son_Goku> though I think that's going to happen when I make the Mir update for Fedora 28
<niemeyer> cachio, Saviq: Question might be how much free space that specific image has, instead of how much space was allocated for it
<niemeyer> cachio: How much space is the image itself taking out of the 10GB?
<Chipaca> niemeyer: https://pastebin.ubuntu.com/p/kH8Wj5vZsS/
<cachio> niemeyer, well, first I want to know is the image has 10GB, in that case, it they are going out of space they need to define the storage for that specific image
<niemeyer> Chipaca: That reminds me a *lot* of the output of snap interfaces
<niemeyer> Chipaca: That help message at the end also feels a bit awkward to have there all the time
<Chipaca> niemeyer: it'd only be there if a ! is shown
<cachio> niemeyer, sadly, the don't have any free space
<niemeyer> Chipaca: If the UX is right we shouldn't need it
<Chipaca> niemeyer: the output with --long should also remind you of the output of snap list :-)
<niemeyer> cachio: That doesn't make much sense
<niemeyer> cachio: The image wouldn't take 10GB for data by itself
<niemeyer> Chipaca: The second output looks so much better that it should really be the default one
<Chipaca> niemeyer: oh wait, the _first_ one is the one you were objecting to?
<Chipaca> heh
<niemeyer> Chipaca: Yeah, totally :)
<Chipaca> hmmmm
<Chipaca> niemeyer: it's not really suited to show more than one set at a time though
<Chipaca> but, let me play with it a little bit
<niemeyer> Chipaca: I'd take a long list in that format over a short list in the first one any day
<Chipaca> niemeyer: fair enough
<niemeyer> Chipaca: People can constrain by providing the snap name they are interested on
<Chipaca> niemeyer: which reminds me, what do you say to start paging by default?
<Chipaca> niemeyer: that is, snap feeding its output to less instead of straight to stdout
<niemeyer> Chipaca: The thing that second output is missing is a way to identify the particular snapshot
<niemeyer> So it can be restored, etc
<cachio> niemeyer, we are requesting by default diskSizeGb=10
<Chipaca> niemeyer: yep, but fixable with indentation (although that'd make grepping harder)
<niemeyer> Chipaca: I'm not a huge fan to be honest.. it feels like getting in the way of the terminal flow
<niemeyer> Chipaca: | less is so easy
<Chipaca> niemeyer: do you find git getting in the way?
<Chipaca> or journalctl
<niemeyer> Chipaca: Much of git doesn't go to a pager
<niemeyer> Chipaca: Things like git log etc, I pipe to vi instead of using the default pager
<niemeyer> Chipaca: It'd also be easy to make the same argument towards every other tool that does not go to a pager
<niemeyer> Chipaca: "Do you find ls broken?"
<Chipaca> niemeyer: yes :-)
<Chipaca> but that's another conversation
<niemeyer> :)
<Chipaca> niemeyer: changing subjects, I might be looking at working on an initial (warning-less) implementation of the "keep some space for refreshing core" thing; would you have any concerns over that?
<Chipaca> waiting for the customer to get back about whether it is snapd filling the disk, or if it's them :-)
<niemeyer> Chipaca: I just wonder if we should do warnings first
<Chipaca> that was the plan
<niemeyer> Chipaca: Every other day we stumble upon an issue that would benefit from having that mechanism we discussed in London.. would be a UX win to have that, and then do disk space/etc
<pedronis> Chipaca: niemeyer: for what is worth lots of recent work would have been improved UX wise by warnings
<niemeyer> Yea
<niemeyer> h
<Chipaca> awwww
<pedronis> I had to use logging and leave TODOs around
<niemeyer> It's one of those things that it's not a deal breaker and we keep pushing forward
<Chipaca> I've got half of warnings done since that sprint and look at it every so often
<niemeyer> Chipaca: Go go go :)
<Chipaca> but â¦ snapshots!
<Chipaca> augh
<Chipaca> anyway maybe it's syslog filling this customer's disc
<Chipaca> we'll see :-)
<niemeyer> Chipaca: Well, to be clear that's not a suggestion not to do the disk check, but rather to do it right after warns
<Chipaca> https://forum.snapcraft.io/t/out-of-disk-space-protection/1632/13 fwiw
<Chipaca> ooh look it's beer o'clock
<niemeyer> :)
<Chipaca> how are people monitoring big deploys with core? because warnings should tie into that as well :-)
<Chipaca> i wonder who i need to talk with about that
 * Chipaca has a sudden surge of compassion for the person on pagerduty for 100k toasters
 * Chipaca 's feeling passes
<mup> PR snapcraft#2019 opened: elf: avoid duplicating rpath entries <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2019>
<niemeyer> cachio: Going back to the image conversation, how much free space is left in the 10GB for Fedora?  That was the original question
<cachio> niemeyer, I don't know, let me check that
<niemeyer> cachio: Ideally we should try to keep those images low profile, and make sure to collect garbage as we did in Linode
<niemeyer> cachio: I won't be bothering you anymore about the individual images, so please make sure to account for those details
<cachio> niemeyer, sure
<Chipaca> niemeyer: https://pastebin.ubuntu.com/p/dM6wMqJc37/ ?
<niemeyer> Chipaca: <3
<niemeyer> I need to step out quickly or will miss the window in which I can exercise.. but will be back later
 * Chipaca won't :-)
<Chipaca> niemeyer: enjoy
<cachio> niemeyer, taking a look to fedora image
<cachio> niemeyer, https://paste.ubuntu.com/p/9m9p8pdCnD/
<cachio> the resize is not as useful as I thought
<cachio> just 2.5 GB free on /
 * zyga found https://packagecontrol.io/packages/Colorcoder interesting
<cachio> niemeyer, I'll resize the filesistems to get a better distribution once the image is resized
<mvo> jdstrand: yeah, its core18
<mvo> jdstrand: base-18 will be phased out
<jdstrand> roadmr: hey, can you queue up r1014? small change for core18 (see above). not urgent in the least
<roadmr> jdstrand: sure! I'd just QAd r1013 :) no problem, this'll make it in to the queue and I'll aim to roll out tomorrow
<cachio> Saviq, I am working to generate a new fedora image
<jdstrand> roadmr: thanks. sorry it was post QA
<cachio> Saviq, it won't be needed to specify the image anymore once it is uploaded
<roadmr> jdstrand: hehe no worries, QA is really fast: I just approve the merge, wait 2 hours or so, then push a snap and ensure it was processed by the correct tools version :)
<cachio> just to call the system "fedora-27-64"
<jdstrand> heh, cool :)
<jdstrand> I like that we have the black box functional tests for 50+ snaps
<jdstrand> (beyond the extensive unit tests)
<popey> When will we be able to build snaps against an 18 core?
<cachio> niemeyer, if you have time, could you please take a look to this one? #4778
<mup> PR #4778: tests: moving debian 9 from linode to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4778>
<cachio> niemeyer, it is passing after the last change we did to spread
<mup> PR snapcraft#2019 closed: elf: avoid duplicating rpath entries <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2019>
<Saviq> cachio: it's still just 4GB though: https://travis-ci.org/MirServer/mir/jobs/356561944#L3492
<mup> PR snapcraft#2020 opened: elf: set no-default-lib for all elf files if patching <bug> <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2020>
<cachio> Saviq, yes, working on that, I could reproduce the same with our machines
<Saviq> ack
<cachio> Saviq, it is failing just on fedora the resize
<cachio> I need to see what is wrong with that image
<Saviq> maybe missing resize2fs or something, /me grabs cloud-init log
<cachio> Saviq, apparently also missing growpart
<cachio> I'll create a new image with those deps
<cachio> Saviq, thanks for the info
 * cachio afk
<Chipaca> niemeyer: it just struck me that possibly the most important bit of info is missing from that 'saved' proposal, and adding it looks relaly nasty: https://pastebin.ubuntu.com/p/Kb8mc7nb3b/
<niemeyer> Chipaca: I think we can fix two problems at once there
<niemeyer> One issue in that output is it had spaces, breaking the column-based parsing
<niemeyer> Chipaca: We discussed before on another context the use of a shorter format.. If we use something like that we can remove the repetition and avoid the spaces
<niemeyer> E.g.:
<niemeyer> 18:20
<niemeyer> 3days
<niemeyer> 2018-01-15
<Chipaca> for parsing you'd use --abs-time which doesn't have spaces though
<niemeyer> Well, ideally we'd make both of them without spaces
<niemeyer> We've managed to do that in every other table so far, I think
<niemeyer> Or at least it's a nice property to preserve
<Chipaca> not sure it'll solve the thing i dislike about it being two columns all the same, but I'll take a look
<niemeyer> Two columns?
 * niemeyer looks again
<niemeyer> Chipaca: Yeah, still don't see the two columns
<Chipaca> niemeyer: https://pastebin.ubuntu.com/p/75BdH8g9rc/
<niemeyer> Chipaca: What I suggested above would be a single column, but ... Looking
<Chipaca> niemeyer: the repetition of the set id and the time (now age) column
<Chipaca> niemeyer: creates two columns that look nasty
<niemeyer> I quite like that output now
<Chipaca> ok
<niemeyer> Duplication is not by itself all bad
<niemeyer> It also makes us realize the associtation
<Chipaca> niemeyer: would you have the columns ordered like this, or age before snap?
<niemeyer> As long as it's not a lot of data duplicated, but the shorter values solve some of that
<Chipaca> I'd rename the column to Time when --abs-time was given
<Chipaca> i guess
<niemeyer> That 22.6h looks a bit strange, but the rest looks quite nice
<niemeyer> The 2h10m form in particular looks nicer
<Chipaca> heh, yes, decimal hours are strange -- quantity's thing is that it's fixed width, which might not be wanted here
<niemeyer> Yeah.. Just rounding to 22h would be fine
<Chipaca> niemeyer: while you're at it, any other that look weird? https://github.com/snapcore/snapd/blob/master/strutil/quantity/example_test.go#L92
<SuperJonotron> how do you find dhcp lease information in ubuntu core?
<Chipaca> FWIW i wanted to let it do things like "2Â¼h" but that's Hard, again
<Chipaca> (especially in the context of tabwriter)
 * niemeyer looks
 * Chipaca just realised that Âµs will suffer the same issue
 * Chipaca is sad now
<Chipaca> SuperJonotron: what is handling dhcp for you on core?
<SuperJonotron> NetworkManager/netplan
<niemeyer> Chipaca: Yeah, I'd drop all of these decimals
<niemeyer> Just accepting the rounded integer form, or presenting the fractional part with a proper unit if it's relevant
<niemeyer> Also E is weird :)
<niemeyer> Ah, and the leading zeros can probably be dropped for a nicer output too..
<niemeyer> That is 4h9m instead of 4h09m
<Chipaca> SuperJonotron: leading zeros?
<Chipaca> um
<Chipaca> niemeyer: leading zeros?
<Chipaca> niemeyer: ah
<niemeyer> Hmm.  Although that last  one is more  unclear
<niemeyer> (Now that I write it out)
<SuperJonotron> Chipaca: leading zeros?
<Chipaca> SuperJonotron: trying to carry two conversations at once when I should be carrying none
<SuperJonotron> gotchya
<Chipaca> SuperJonotron: there's nothing core-specific about dhcp leases, the info'll be where it is without core
<Chipaca> mostly
<Chipaca> :-)
<Chipaca> SuperJonotron: i mean, how would you get that info without core?
<SuperJonotron> Chipaca: according to forums, /var/lib/dhcp/dhcp.leases but that folder is empty
<SuperJonotron> Chipaca: that folder is empty though
<SuperJonotron> Chipaca: there's also mention to looking at /var/logNetworkManager* which also doesn't exist in core
<Chipaca> SuperJonotron: I don't think that's the location of the leases file in reasonably new ubuntus though
<SuperJonotron> Chipaca: where did they move to in core?
<Chipaca> SuperJonotron: as NetworkManager is a snap, I'd expect it to be under /var/snap/
<Chipaca> SuperJonotron: but you can figure it out with 'find':
<Chipaca> SuperJonotron: sudo find / -name \*.lease 2>/dev/null
<SuperJonotron> ls
<SuperJonotron> whoops, wrong window
<SuperJonotron> i did find the lease files starting in /var/snap
<SuperJonotron> but that find command will likely be needed since it is not a pretty file name
<Chipaca> heh
<Chipaca> SuperJonotron: if it's looking there like it looks here, the names have a reason
<Chipaca> SuperJonotron: (but that reason might not make sense to you :-) )
<SuperJonotron> Chipaca: looks like a naming pattern with a UUID as part of it both pointing to the same interface so that is a bit confusing about which one to read
<Chipaca> SuperJonotron: as i understand it it's a UUID which is the id of the network connection in network manager, then "-", then the device name, then ".lease"
<Chipaca> SuperJonotron: nmcli con
<Chipaca> SuperJonotron: ^ list the connections, including the uuids
<SuperJonotron> perfect
<SuperJonotron> now to figure out how to read this file...
<Chipaca> SuperJonotron: what are you trying to do?
<SuperJonotron> Chipaca: working with an application that needs to report DHCP Server, Lease Granted Time and Least Expiration time
<SuperJonotron> for all interfaces using dhcp that is
<Chipaca> hmmm
<Chipaca> SuperJonotron: so,  nmcli can give you that info
<Chipaca> SuperJonotron: if $CON is your connection name or uuid, then 'nmcli connection show $FOO' will give you all that, i think
<Chipaca> um
<Chipaca> CON and FOO got jumbled there
<Chipaca> see: me needing to go to bed
<Chipaca> ah, maybe not granted time
<Chipaca> dunno
<SuperJonotron> was inspecting that now
<Chipaca> SuperJonotron: good luck
<Chipaca> and good night
<SuperJonotron> thanks
#snappy 2018-03-22
<mborzecki> morning
<mup> PR snapd#4901 opened: cmd/snap-confine: nvidia: add tls/libnvidia-tls.so* glob <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4901>
<zyga> good morning
<mborzecki> zyga: hey
<mborzecki> zyga: take a look at 4901 please
<zyga> ohhh
<zyga> I see now
<zyga> man, is that it?
<mborzecki> yeah
<mborzecki> 'magic'
<zyga> man :)
<zyga> that's insane
<mborzecki> zyga: left a note here https://forum.snapcraft.io/t/nvidia-acceleration-on-chrome-and-firefox/4532/16 , there's 2 copies of these libraries
<zyga> but also brittle on our part, I wonder how can we make sure to pick the right set in general
<zyga> I think that should be a snap
<zyga> and that snapcraft should prevent people from shipping those
 * zyga reads
<mborzecki> we already pick up libnvidia-tls.so*, bu there's another one under tls/libnvidia-tls.so*, no clue how the second one gets loaded
<zyga> are they identical?
<mborzecki> yup
<mborzecki> aah w8,
<mborzecki> no, damn, looked wrong
<mborzecki> they're different
<mborzecki> need to correct the post
<zyga> Ah
<zyga> This makes more sense now
<zyga> Ok
<zyga> Still +1
<mborzecki> note to self, make sure to sort the inputs
<zyga> Are they coming out of nvidia private build?
<zyga> Or out of libglvnd
<mborzecki> zyga: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/nvidia-utils#n114 nvidia
<mborzecki> zyga: it even works the arch glvnd libs now
<zyga> Ok
<zyga> Can you please do a small experiment
<zyga> Take the nvidia build from their website
<zyga> Unpack it
<zyga> And correlate the files inside with our patterns
<zyga> Are we missing anything
<zyga> mborzecki: I'll review and perhaps land the makefile change today
<zyga> but can you please look at this: https://github.com/snapcore/snapd/pull/4891
<mup> PR #4891: tests: add support for phased prepare-restore logic <Created by zyga> <https://github.com/snapcore/snapd/pull/4891>
<zyga> I have some nice follow-ups
<zyga> and I wanted to get the foundation in place
<mborzecki> zyga: hm i think we might be doing something silly with those globs
<mborzecki> on the host I have both paths /usr/lib/libnvidia-tls.so.390.42 and /usr/lib/tls/libnvidia-tls.so.390.42, but in the mount ns only one appears
<mborzecki> then readme in the drivers states this: The nvidia-tls libraries (/usr/lib/libnvidia-tls.so.390.42 and /usr/lib/tls/libnvidia-tls.so.390.42); these files provide thread local storage support for the NVIDIA OpenGL libraries (libGL, libnvidia-glcore, and libglx). Each nvidia-tls library provides support for a particular thread local storage model (such as ELF TLS), and the one appropriate for your system will
<mborzecki> be loaded at run time.
<zyga> mborzecki: look at the snap-confine code there, we probably don't look at tls/* at all
<zyga> mborzecki: my idea is to convert the nvidia tarball into a snap
<zyga> and mount it
<zyga> ignore anything the host does
<mborzecki> you'd need a tarball for each version of the drivers
<zyga> we only need to support each family, not each version
<zyga> there are about 3 at most
<zyga> and yes, I agree
<zyga> although I don't know if all families support libglvnd
<zyga> what is the layout of the working setup at runtime, what is in /var/lib/snapd/lib/gl
<zyga> (can you ls -lR there please?)
<mborzecki> just a sec, got some changes in place
<zyga> kk
<zyga> great work btw! this is very promising
<mborzecki> zyga: https://paste.ubuntu.com/p/jHSFhjbjV9/
<mborzecki> zyga: we have this: libnvidia-tls.so.390.42 -> /var/lib/snapd/hostfs/usr/lib/tls/libnvidia-tls.so.390.42, but the symlink should be to var/lib/snapd/hostfs/usr/lib/libnvidia-tls.so.390.42 and we should have directory tls with symlink to respecive libs inside
<mborzecki> same for vdpau
<zyga> hmm
<zyga> this will require small changes there
<zyga> but yeah
<zyga> and can you pastebin the tree of files that is in the nvidia tarball?
<mborzecki> zyga: the correct layout https://paste.ubuntu.com/p/NHHHpNCrVY/, seems to work fine too
<zyga> hmm
<zyga> a bit magic
<zyga> since you said those libnvidia-tls.so files are not the same
<mborzecki> zyga: files in the driver package pulled from nvidia's site: https://paste.ubuntu.com/p/zDFygPwSQ2/
<mborzecki> yeah the readme says: 'the one appropriate for your system will be loaded at run time.'
<zyga> drwxr-xr-x 2 maciek maciek     4096 03-03 14:03 tls
<zyga> they have a tls dir
<zyga> I need to run
<zyga> my son forgot his homework (yeah)
<zyga> and just called me
<zyga> AFK
<zyga> and then I will work from a coffee shop because I planned to move anyway
<zyga> mvo: good morning, I'll be back soon, please ping me if urgent
<mvo> zyga: ok
<mup> PR snapd#4901 closed: cmd/snap-confine: nvidia: add tls/libnvidia-tls.so* glob <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4901>
<mborzecki> mvo: can you cherrypick it to 2.32?
<mvo> mborzecki: already done
<mvo> mborzecki: thank you
<mborzecki> mvo: thanks
<kalikiana> moin moin
<pstolowski> morning
<mup> PR snapd#4902 opened: cmd/snap-confine: nvidia: preserve globbed file prefix <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4902>
<mborzecki> zyga: ^^ https://paste.ubuntu.com/p/NSWPHDrNBd/
<zyga> Almost back
<zyga> re
<zyga> sorry for being late
<zyga> mvo: hey, I'm ready to assist in any way I can
<zyga> mvo: I was thinking about the trespassing bug
<zyga> mvo: and I think we can postpone that for 2.33
<zyga> mvo: since the impact is not serious and this is a beta feature
<zyga> mvo: I will work on cleaning it up to have proper data path from main all the way down
<zyga> mvo: and this will lessen the impact on the release
<zyga> mvo: I would only like to merge the symlink fixes
<zyga> mvo: and do more more more testing to see if we can reproduce the issue again
<mvo> zyga: that sounds great. I'm working right now on the snap run fixes we talked about yesterday
<zyga> mvo: I also have a tiny PR to add (I can add it to the symlink PR) to add something to debug: there
<zyga> mvo: thank you sounds good
<zyga> mvo: I moved downtown to meet with an old colleague
<zyga> super smart guy, I wonder if he would consider joining our team :)
<mvo> zyga: heh, ok
<zyga> he's an old lisp hacker, not sure if he'd want to use go ;-)
<mvo> zyga: ha! a sage
<zyga> I think he needs to upgrade his beard a few times for that ;D
<mvo> zyga: CE testing found that 2.32 would not work correct on caracalla because the security profile re-generation. I am curretnly trying to write up how this happens, do you remember in what way we modify the security profiles between 2.31->2.32 that would trigger this?
<zyga> yes
<mvo> zyga: please tell me then :)
<zyga> mvo: we now require a new profile snap-update-ns.$SNAP_NAME on startup
<zyga> in the past whenever we changed profiles and the changes were not huge we would just start with the old profile
<zyga> and replace the profile in place as soon as snapd woke up
<mvo> zyga: what requires this? snap-confine?
<mborzecki> zyga: please take a look at 4902 when you can
<zyga> now we cannot start apps because w ecannot complete the profile transition from snap-confine to snap-update-ns
<zyga> mborzecki: ack
<zyga> mvo:  in 2.31 we had one profile for snap-update-ns
<zyga> one that was very open because of layouts
<mvo> zyga: that is excellent, this also means that without system-key this would not even possible?
<mborzecki> i'll be looking at 4891 in a while and then will try nvidia & bionic
<mvo> zyga: is it snap-confine that loads these extra profiles?
<zyga> in 2.32 we have one profile per snap, that is tailored to construct the layout
<zyga> mvo: no, it's not snap-confine
<mvo> zyga: what is loading those?
<zyga> mvo: snap confine doesn't even check if they exist, it just requests transition on the next exec
<zyga> mvo: normally they are loaded by apparmor init script on early boot
<zyga> mvo: those are stored just like snap application profiles, in /var/lib/snapd/apparmor/profiles
<mvo> zyga: hm, I'm puzzled then, so part of the new profile (that require these extra things) are on disk already?
<zyga> mvo: no
<zyga> mvo: they will be created by snapd after core reboots to 2.32
<mvo> zyga: what am I missing :)
<zyga> mvo: in 2.31 they were not a thing
<pedronis> but in 2.31 -> 2.32 transition they will not be there until after reboot and start of snapd, no?
<zyga> mvo: so we hit a hard transition when a profile is missing
<zyga> yes pedronis, exactly right
<zyga> mvo: this will become less of an issue once we have snapd.snap
<zyga> and snapd can restart itself without rebooting the box
<mvo> zyga: what bit falls over? I mean, if the old profiles are there until we run snapd one would assume that network-manager would run happily with the old profiles?
<zyga> then the profiles will show up in phase 2
<zyga> mvo: you miss one fact
<zyga> mvo: it's a brand new profile
<zyga> not one that existed in 2.31 at all
<pedronis> mvo: well after reboot there's a profile that requires a profile that is not there
<pedronis> not quite sure how the profile transition work
<zyga> mvo: the name is snap-update-ns.network-manager
<zyga> mvo: we never had that profile in 2.31
<zyga> mvo: note that this can happen even if we take snap-update-ns out of the picture
<mvo> zyga,pedronis: why the mismatch, I mean, if there is a new profile after reboot then the other profile should also be written. and if its an old profile it does not reference the new profile. what am I missing :) ?
<mvo> zyga: sorry for being a bit slow today
<zyga> mvo: 2.31 doesn't write snap-update-ns.network-manager
<zyga> mvo: 2.32 does and requires it to start network-manager process
<mvo> zyga: but does 2.31 references this profile in any way?
<zyga> mvo: no
<zyga> mvo: do you want to HO to have me explain this in person?
<mvo> zyga: yes
<zyga> kk
<zyga> one sec
<mvo> sure, I'm sure there is some tiny details I'm missing, but I don't know yet what
 * zyga hopes background coffee shop music won't be an issue
<mvo> zyga: I'm in the stadnup HO
<zyga> mvo: one moment, I don't have chrome here
<zyga> normally I HO from my desktop
 * mvo nods
<zyga> 2 minutes to download
<zyga> uh, I should visit that telco store and get a modem for my sim :(
<mvo> zyga: we could also have a old-fashioned phone call if you want :)
<zyga> installing chrome now
<mvo> ok
<zyga> if this fails, yeah
<zyga> I'll call you
<mwhudson> pedronis: can you read Laney's comments on https://bugs.launchpad.net/snapd/+bug/1723094 and reply on the bug?
<mup> Bug #1723094: Live images should be able to turn off Snap updates <snapd:Confirmed> <casper (Ubuntu):Triaged by jibel> <casper (Ubuntu Bionic):Triaged by jibel> <https://launchpad.net/bugs/1723094>
<pedronis> mwhudson: I tried to answer, does it make sense?
<mwhudson> pedronis: it makes sense to me at least :)
<Laney> thanks!
<zyga> mborzecki: done
 * Chipaca afk for a bit
<zyga> mvo: can we merge https://github.com/snapcore/snapd/pull/4899
<mup> PR #4899: many: backported fixes for layouts and symlinks (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4899>
<mborzecki> when i'm running bionic from usb stick, are the changes preserver accross reboots?
<zyga> mborzecki: dunno
<zyga> it used to be (some)
<zyga> but not sure
 * Chipaca really afk now
<zyga> o/
<Chipaca> mborzecki: it depends on whether, when you created the thing, you told it to leave some rw space
<mborzecki> Chipaca: I dd'ed iso to usb stick
<Chipaca> hmm, i can't see where on usb-creator-gtk there was that option, but i'm sure it was there before
<zyga> I think it may have been removed now
<mborzecki> Chipaca: dd is the only usb-creator i ever use :)
<zyga> because that code evolved a lot
<mvo> zyga: let me look at it. in the meantime: 4882 is updated
<zyga> mborzecki: install ubuntu on some spare hdd
<zyga> mvo: thank you, looking
<Chipaca> usb-creator (0.3.0) xenial; urgency=medium
<Chipaca>   [ Marc Deslauriers ]
<Chipaca>   * Rework the whole imaging process for writing to devices:
<Chipaca>     - Use an equivalent of dd to make an exact copy of the image to the device
<Chipaca>     - This also breaks persistence.
<Chipaca> that last line there? boom. no more persistence.
<mborzecki> damn
<mvo> godd!
<mvo> just saying :)
<Chipaca> mvo: does that do persistence
<Chipaca> :-)
<mvo> its persistently nice, if that is what you mean ;)
<Chipaca> mborzecki: get your hands on usb-creator-gtk 0.2.68 :-)
<Chipaca> mvo: dunno, seems unmaintained, i proposed a pr ages ago and got no feedback
 * Chipaca runs
<mborzecki> Chipaca: i'll try installing to a usb stick (while running the installer from another usb stick)
<Chipaca> mborzecki: usb-creator-gtk from trusty should do it
<Chipaca> mborzecki: https://packages.ubuntu.com/trusty-updates/amd64/usb-creator-gtk/download
<zyga> Chipaca, mborzecki: I would not trust that :)
<Chipaca> zyga: 'course you can trust it, it's got 'trusty' in the name!
 * Chipaca really needs to afk for a bit now
<zyga> hahaah
<zyga> :-)
 * zyga bakes a few more patches in google
<zyga> while on the go, google is a nice place to test
<zyga> we should update the reference tag to get smaller deltas
<mvo> zyga: hm, one test missing, sorry for this, will push a new 4882 in some minutes
<zyga> ok
<pedronis> mvo: do we know if for some reasons network-manager needs to start before snapd on those machines? (IÂ suppose not, we write the all the relevant units and there's no such dep)
<zyga> pedronis: I think that on those machines n-m manages all networking
<zyga> pedronis: and it just starts as early as it can
<zyga> it's not strictly "before snapd" but not explicitly linked to through dependencies
<zyga> pedronis: and if we go and change the units now we'd have issues in the field as there's no easy way to change any systemd units
<pedronis> that's fine as long as snapd doesn't wait for that, and the timeout on starting that service is within the time it takes for snapd to do its job
<zyga> (we don't have equivalent of ensure there)
<pedronis> in terms of profile writing
<mborzecki> hm the installer does something funny, there's 'Erase disk and install Ubuntu' option, but I have 5 disks plugged in at the moment, so which one will it erase?
<zyga> pedronis: that's a good point
<zyga> mborzecki: choose manual partitioning
<zyga> mborzecki: 18.04 or 16.04?
<zyga> I'm used to 16.04 installer but I think that 18 changed a lot
<mborzecki> 18.04
<zyga> mborzecki: one more "hint" detach other disks :D
<zyga> it's surprisingly low tech robust solution for this problem
<zyga> also helps if you install windows or other OS with silly installer that just overwrites everything agressively
<mborzecki> i'm clicking, but franly i'm minutes away from debootstrapping the thing
<zyga> mborzecki: you can do it, just a bit more patience :)
<mborzecki> slightly worrying, wonder wher grub efi will get installed, i've made a partition for efi and set the bootloader to be installed to that disk
<mborzecki> aaannd it installed grub to the wrong drive
<mborzecki> inistaller finished, now i can start fixing the system :/
<zyga> mborzecki: is it booting?
<zyga> what's up?
<zyga> mborzecki: sorry :/
<mborzecki> zyga: the installer hijacked the ESP on the main nvme drive, heh so the system i got now is ubuntu/efi on nvme and rootfs on usb stick
<mborzecki> got to install ubuntu's grub in efi partition of usb stick and make arch boot again
<Chipaca> mborzecki: are you having fun yet
<mup> PR snapd#4899 closed: many: backported fixes for layouts and symlinks (2.32) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4899>
<zyga> woot
<zyga> thanks mvo
<zyga> mvo: I forgot to push that debug branch so I'll add a debug PR to 2.32 as well
<zyga> mvo: in 15 minutes, busy with some topics
<mvo> zyga: 4882 is ready to review. this and your debug pr are the last bits, right?
<zyga> yes
<zyga> well
<zyga> 4882 not sure
<zyga> I forgot which PR that was
<mvo> zyga: snap run --system-key
<zyga> ay
<zyga> +1
<zyga> yes
<zyga> I left the debug bits at home so I'll just make a new PR
<mborzecki> zyga: fwiw bionic boots now
<mborzecki> and from the right drive
<zyga> mborzecki: cool :)
<zyga> did you have to update bootloader layout?
<mborzecki> zyga: yes, mount proper partiion under /boot/efi, edit fstab to make it work after reboot, install grub x86_64-efi
<mborzecki> i'll deal with arch later, i have a slightly convoluted luks+lvm there
<mup> PR snapd#4903 opened: tests: split prepare-restore.sh into prepare-restore.d modules <Created by zyga> <https://github.com/snapcore/snapd/pull/4903>
<zyga> hey mborzecki-ubuntu :)
<ogra_> Chipaca, shouldn't whatever needs /var/cache/snapd/commands.db create it if it is none-existent ? (see https://forum.snapcraft.io/t/var-cache-snapd-commands-db-permission-denied/4590 )
<mborzecki-ubuntu> zyga: hey
<Chipaca> ogra_: if it doesn't exist there's nothing to do, so it should just move on
<ogra_> well, it doesn't
<Chipaca> ogra_: IKR
<Chipaca> ogra_: I think at least two things need fixing: one, which i think mvo is already on, is to make _command_not_found hide stderr from snap advise-snap (or maybe make snap advise-snap not error on no db)
<Chipaca> ogra_: the other is to make the classic snap grab the commands.db from host :-)
<ogra_> yeah, obviously
<ogra_> i only noticed after i wrote the first comment that it seems to be created on first boot
<Chipaca> ogra_: if you've got classic installed somewhere, could you see if you could just cp it from hostfs?
<ogra_> so we need a cp in the classic setup script
<ogra_> err, yes, see my last post there
<Chipaca> ogra_: no, from _inside_
<Chipaca> ogra_: maybe it's fixable inside :-)
<ogra_> ah, nop, that wont work
<Chipaca> aw
<ogra_> we're in a chroot
<Chipaca> ogra_: i thought the classic snap had crazy privs
<ogra_> and dont do fancy hostfs bind mounting or anything
<ogra_> its a simple chroot :)
<ogra_> but it is no prob to simply add it to the chroot setup script
<Chipaca> ogra_: given core can be size constrained, maybe ln || cp (or is there a better way to do that)
 * Chipaca knows nothing
<zyga> mvo: 2.32 debug PR https://github.com/snapcore/snapd/pull/4904
<mup> PR #4904: tests: change debug for layout test (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4904>
<mup> PR snapd#4904 opened: tests: change debug for layout test (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4904>
<mvo> zyga: ta
<ogra_> Chipaca, linking wont work (and bind mounting adds complexity i'd like to avoid) ... cp will do
<mborzecki-ubuntu> well, nvidia doesn't work in snaps on bionic
<mborzecki-ubuntu> i'll try my branch
<zyga> OMG!!!! git checkout -
<mborzecki-ubuntu> is tehre a command i can use to install all build deps listed in debian/control?
<zyga> my favourite command
<mborzecki-ubuntu> zyga: yeah, it's like cd - ;)
<mvo> mborzecki-ubuntu: sudo apt build-dep ./
<zyga> yes
<zyga> I just complained I wish there was something like that
<mvo> mborzecki-ubuntu: if you are inside the unpacked deb
<zyga> and suddenly my colleague shows me this
<mborzecki-ubuntu> mvo: ta
<zyga> oops, pushed to wrong PR
<zyga> PRs corrected
<zyga> mborzecki-ubuntu: https://github.com/snapcore/snapd/pull/4903
<mup> PR #4903: tests: [WIP] split prepare-restore.sh into prepare-restore.d modules <Created by zyga> <https://github.com/snapcore/snapd/pull/4903>
<zyga> no need to review yet before the other one lands
<zyga> but this is what I was thinking about
<zyga> there's lots of room to improve from this state
<zyga> but it's already much more approachable than the big one we have now
<zyga> is there a spread variable that holds the name of the current test?
<mvo> zyga: meh, the system-key stuff is actually more work because snap run needs to read the build-id of snapd not of snap
<zyga> oohh
<zyga> yeah
<zyga> and great catch :/
<zyga> mvo: and now it needs to know which snapd to read
<zyga> mvo: /o\
<mvo> zyga: make the whole thing more complicated. exactly, re-exec and all that :(
<zyga> mvo: maybe
<zyga> mvo: maybe we drop the tailored profiles
<zyga> mvo: use the old profile for 2.32
<mvo> zyga: that sounds wise
<zyga> mvo: and at least 2.32 ships with the new profile on disk
<zyga> mvo: and 2.33 won't have massive issues
<mvo> zyga: how much work is it?
<zyga> not a solution much but yeah
<zyga> mvo: drop a few lines of C from snap-confine
<mvo> zyga: \o/
<mvo> zyga: lets do that
<zyga> mvo: restore child profile for snap-confine.apparmor.in
<zyga> mvo: and it _should_ work
<mvo> zyga: much safer and we look at this problem again with more time and less presure
<zyga> mvo: we'll still make the snap-update-ns.$SNAP_NAME profiles and load them but they will be unused
<zyga> yes
<zyga> mvo: I'll prepare a PR
<zyga> mvo: and you can get fewer gray hair :)
<mvo> zyga: heh, indeed
<mvo> zyga: I have way too many of those already
<zyga> mvo: ok, let me do this quickly
<ogra_> mvo, https://github.com/snapcore/classic-snap/pull/16
<mup> PR classic-snap#16: fix breakage of command-not-found  <Created by ogra1> <https://github.com/snapcore/classic-snap/pull/16>
 * Chipaca switches tasks, from improving test coverage to improving lunch coverage
<zyga> hahaha
 * zyga hugs Chipaca 
<Chipaca> zyga: how're your breaks coming?
 * zyga looks the other way to avoid eye contact
<zyga> I'm not at home
<zyga> that's an improvement
<mvo> ogra_: thank you
<zyga> but relaease rush
<zyga> so ... you know
<zyga> *release even
<Chipaca> yeah
<zyga> mvo: ok, running locally now
<zyga> mvo: https://github.com/snapcore/snapd/pull/4905
<mup> PR #4905: cmd/snap-confine: don't use per-snap s-u-n profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4905>
<mup> PR snapd#4905 opened: cmd/snap-confine: don't use per-snap s-u-n profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4905>
<zyga> not tested yet
<mborzecki-ubuntu> zyga: failed to create prefix path: /tmp/snap.rootfs_jW5tpa/var/lib/snapd/lib/vulkan/icd.d: Permission denied
<diddledan> a bit of fun: "how to make package managers cry" https://www.youtube.com/watch?v=kguJ1ihOyV8
<zyga> mborzecki-ubuntu: dmesg | grep DENIED
<zyga> I suspect we need some apparmor love there
<mborzecki-ubuntu> zyga: switched it to aa-complain atm
<zyga> good, that will let you see all the access patterns
<zyga> please collect the denials though
<zyga> diddledan: good one!
<diddledan> :-)
<mborzecki-ubuntu> zyga: hmm multiarch is broken, we're trying to bind mount the wrong paths
<zyga> oh
<zyga> on 18.04?
<mborzecki-ubuntu> zyga: yes
<zyga> on 18.04 all of nvidia is broken for us
<zyga> :/
<mborzecki-ubuntu> we ought to do the same as for biarch, as the libs are under /usr/lib/<arch-tuple> now
<zyga> yes
<zyga> you can disable reexec and just build snapd with that option
<zyga> and see what breaks
<zyga> we can use this experience to later do this at runitme
<zyga> *runtime
<mborzecki-ubuntu> is there a command line tool that would return the arch tuple of current host?
<mborzecki-ubuntu> i mean the default one
<pedronis> mborzecki:Â I think mvo IÂ had a PR about the exposing full triplet at some point, but was closed
<zyga> mborzecki-ubuntu: gcc -dumpmachine
<zyga> mborzecki-ubuntu: everything else disagrees
<zyga> mborzecki-ubuntu: dpkg --print-architecture is one more but not the same
<zyga> mborzecki-ubuntu: can that be a compile-time constant?
<mvo> mborzecki-ubuntu: https://github.com/snapcore/snapd/pull/4477/files#diff-fb91c6071604836b89ba2de46c45a56fR56 is what I did
<mup> PR #4477: snapenv: add SNAP_ARCH_TRIPLET <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4477>
<mup> PR snapd#4906 opened: polkit: Pass caller uid to PolicyKit authority <Created by chrisccoulson> <https://github.com/snapcore/snapd/pull/4906>
<mup> PR snapd#4905 closed: cmd/snap-confine: don't use per-snap s-u-n profile (2.32 only) <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4905>
<mup> PR snapd#4903 closed: tests: [WIP] split prepare-restore.sh into prepare-restore.d modules <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4903>
<jdstrand> zyga (cc mvo): you're backing out the hardening? that is terribly unfortunate cause I only conditionally acked layouts on the promise that the hardening would be there
<jdstrand> zyga (cc mvo): for 2.32
<zyga> jdstrand: we're backing out of 2.32 split profile
<jdstrand> zyga: yes, the hardening that I said was required cause the child profile was way too open
<mvo> jdstrand: the split profiles cause deep issues
<zyga> jdstrand: yes, we may axe the feature for now so that we can do it properly
<mvo> jdstrand: happy to have a HO if you want maybe after the standup
<jdstrand> I'll not do a conditional ack like this again
<zyga> (that would break layouts entirely for 2.32)
<mvo> jdstrand: I think the alternative is to disabled this entirely
<jdstrand> of course, I said I wouldn't do it yesterday
<jdstrand> mvo: that was understood with the conditional ack
<zyga> I think we can axe it and do it for 2.33
<zyga> where it will be all done
<zyga> (both the hardening and the feature)
<jdstrand> allow it to be committed to test things out and if the hardening wasn't there, back out the feature
<mvo> jdstrand: ok, lets have a HO then, we are in the middle of the standup right now so not the best time to discuss. would you be able to make it to a hangout at the top of the hour (in 49min)?
<jdstrand> I'm not sure a hangout is needed-- my position is that with s-u-n profiles, we may as well not confine snap-confine
<jdstrand> but I think I can do a hangout then
<mvo> jdstrand: might be easiest just to ensure we are all on the same page. we won't do anything that you do not ACK
<jdstrand> zyga: are you in said hangout out? I'd like to understan the 'deep issues'
<jdstrand> hangout out?
<jdstrand> said standup?
<mvo> jdstrand: well, its not that deep. basic there is a race: when snapd refresehes and reboots on core then snapd start before the new snapd is run
<mvo> jdstrand: so these snaps will not find the needed profiles
<mvo> jdstrand: and fail to start
<mvo> jdstrand: and of course thats bad(tm) for things like network-manager
<jdstrand> isn't that what the system-key 'wait on me' stuff is for? we did that somewhere else recently
<mvo> jdstrand: https://github.com/snapcore/snapd/pull/4882 - correct, implementing this is tricky
<mup> PR #4882: snap: make `snap run` look at the system-key for security profiles <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4882>
<mvo> jdstrand: and we are under some pressure to release 2.32
<mvo> jdstrand: anyway, might be easiest in a HO, then we can discuss options and maybe come to different conclusions
<zyga> mvo, jdstrand: yeah, let's reuse the HO after standup
<zyga> and discuss the problem, our approach so far and the plans we had
<zyga> and what we actually want to do after discussing this
 * zyga would prefer to merge the hardening but it doesn't change the other problem we had
<zyga> mvo, jdstrand: if we need to back out layouts and undo the un-hardening so that we are back to 2.31 profile I can do that quickly
<zyga> though we have the experimental flag now and we need to remove that as well
<jdstrand> zyga, mvo: another idea: https://github.com/snapcore/snapd/pull/4905#issuecomment-375306343
<mup> PR #4905: cmd/snap-confine: don't use per-snap s-u-n profile (2.32 only) <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4905>
<zyga> ack
<zyga> jdstrand: that's an interesting idea
<zyga> jdstrand: so we keep a strict profile for s-u-n
<zyga> jdstrand: and if there's a good profile we transition
<zyga> and if not we use the strict profile
<zyga> jdstrand: how can we check if a profile with given name is loaded?
<jdstrand> there is probably libapparmor api for that, but a look in sysfs is sufficient (eg, /sys/kernel/security/apparmor/profiles or /sys/kernel/security/apparmor/policy/profiles/)
<jdstrand> zyga: ^
<zyga> yes, I was trying to avoid having to parse it now
<zyga> but sure
<jdstrand> zyga: so you can either parse /sys/kernel/security/apparmor/profiles or do a smart glob on a directory name existence in /sys/kernel/security/apparmor/policy/profiles/
<jdstrand> zyga: you could aa_query_label() for a file that is expected to be allowed and check for ENOENT
<jdstrand> zyga: could also adjust the logic a bit to look for ENOENT on the aa_change_onexec, and if it fails, aa_change_onexec to the child profile instead (thus removing the Cx rules, but adding a change_profile rule for the child)
<jdstrand> zyga: that last suggestion is probably clearest in terms of intent wrt fallback
<zyga> yes
<zyga> I think that's sensible
<zyga> let's discuss this soon
<jdstrand> then no parsing
<zyga> yes
<Trevinho> Hey.. question, if I close a channel (say candidate), the people will be moved to stable version... But, if a new revision is released to candidate, all the people who were tracking it will keep it or not? Do they manually to go back to track it?
<Trevinho> I mean when we say that people will be moved to the safest risk level, is that related to the snap revision or also to the track itself?
 * zyga relocates
<Chipaca> Trevinho: they're tracking candidate, if you reopen candidate and release something into it, they'll get it
<Trevinho> Chipaca: ok good.. That was what I was assuming, but just to double-check
<Chipaca> Trevinho: that's the "tracking" field in "snap info"
<Trevinho> as docs didn't mention it
<Chipaca> ogra_: ooh, ooh, could you copy _everything_ from cache to the inside?
<Chipaca> ogra_: another question: how do you update it
<Chipaca> ogra_: ie those cache files should get updated periodically...
<jdstrand> mvo: where is the hangout?
<mvo> jdstrand: https://hangouts.google.com/hangouts/_/canonical.com/snappy-devel?authuser=1 but zyga is looking for a quiet place to join right now
<mvo> jdstrand: so we may need to wait ~2 more minutes
<ogra_> Chipaca, we never update the chroot (any of it ...) it is really only to provide you apt/dpkg for development, not for any other use
<Chipaca> ogra_: hmmmm
<ogra_> so it is really only a snapshot of the moment you create the chroot
<Chipaca> ogra_: could we have a .bashrc saying "Your classic environ is now XYZ days old, time to nuke it"?
<ogra_> (it wont allow to run any services or inbteract with snapd on the host or anything  either)
<Chipaca> ogra_: somebody, somewhere is building an IoT device gateway on top of that :-)
<Chipaca> (that's not a fact, just statistics)
<ogra_> someone should stop him then ;)
<ogra_> it might be really hard to do that though ... given that you can not automatically run anything from classic after a reboot
<ogra_> if you need a real classic setup on top of core to run a product you'd hopefully use lxd or docker
<ogra_> and not some developer tool
<ogra_> (that is clearly marked as such)
<Chipaca> ogra_: I'm 93% joking
<ogra_> yeah, but there are these 7% !
<ogra_> :)
<Chipaca> 5% wry cynicism, 2% other
<Chipaca> :-)
<ogra_> (and there *is* at least one person trying to abuse it so you are not that far off ... https://github.com/snapcore/classic-snap/issues/15 )
<ogra_> (havent found the time to answer yet )
<Chipaca> oh man, just two sentences into the bug and i'm already noped out
<Chipaca> three sentences if you count 'hello there!'
<ogra_> heh
 * Chipaca replies with "you should install expect"
<Chipaca> or maybe ârun "/sbin/agetty -n --noclear -l /snap/bin/classic tty1" and then ...â
 * Chipaca shuts up
<ogra_> heh
<Chipaca> ogra_: I mean, I've used mplayer as a filter to lpd to have a networked music player
<Chipaca> ogra_: the above wouldn't frighten me in the least :-D
<ogra_> me neither ... but it isnt what classic is designed for ...
 * Chipaca goes for a walk
<ogra_> mplayer as filter to lpd ... to do what ? print song texts ?
<ogra_> (or is there some other lpd i dont know)
<sergiusens> ogra_: where is the snapcraft project definition for the current build of `core`?
<ogra_> sergiusens, "sapcraft project definition" ? you mean snapcraft.yaml ?
<sergiusens> yes
<ogra_> https://github.com/snapcore/core
<sergiusens> ogra_: do you know where that is mirrored to on launchpad? core is such a generic name
<ogra_> scroll down ;)
<ogra_> it's in the README
<sergiusens> thanks
<jdstrand> mvo: since you are going forward with hardened profiles, it sounds like I do not need to be present in the followup hangout (I've got a number of things I need to do today)
<cachio> Saviq, there?
<jdstrand> mvo: I can make myself available to be pulled in if that is useful though (I may have a conflict, someone is trying to schedule a meeting today with a partner that I've been asked to attend)
<mvo> jdstrand: corret
<mvo> jdstrand: I think its fine
<mvo> jdstrand: we needed your input on the security questions, thanks for providing it
<jdstrand> mvo: np. thanks to you, zyga and niemeyer on working through this
<mup> PR snapcraft#2021 opened: Only mangle elf app <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2021>
<mup> PR snapd#4907 opened: advisor: deal with missing commands.db file <Created by mvo5> <https://github.com/snapcore/snapd/pull/4907>
<mup> PR snapd#4904 closed: tests: change debug for layout test (2.32) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4904>
<Saviq> cachio: hey
<cachio> Saviq, 2 things
<cachio> first, the image for fedoras was renamed, so yo dont need to add the image anymore
<cachio> Saviq, 2nd I found the problem with resizing, but I need to agree how to fix it, if you need a temporal workaround, you can add these 2 lines to your tests (at the beginind)
<cachio> sudo growpart /dev/sda 1
<cachio> sudo resize2fs /dev/sda1
<cachio> that will force the partition resizing
<cachio> niemeyer, I have a fix for spread to force the resizing that be default is not being done in fedora or centos
<cachio> niemeyer, it is automatic on ubuntu/debian but you need to do it manually for other deistros
<cachio> I made a fix for spread, addthis these 2 lines to the googleStartupScript
<cachio> and it works
<cachio> niemeyer, this is the PR https://github.com/snapcore/spread/pull/54
<mup> PR spread#54: Add the resize of the partition on the googleStartupScript <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/54>
<Saviq> cachio: I'll wait, we're fine on linode for now
<niemeyer> cachio: What does it automatically in Debian and Ubuntu?
<cachio> niemeyer, resize the partition
<cachio> and the disk as well
<Saviq> cloud-init
<cachio> but, in centos or fedora it is not happening
<cachio> in the forums other people is facing the same problem
<niemeyer> cachio: Yes, *what* is doing it
<cachio> gogole compute init
<Saviq> cachio: you sure it's not cloud-init http://cloudinit.readthedocs.io/en/latest/topics/examples.html?#grow-partitions ?
<cachio> google-compute-engine-init
<niemeyer> cachio: If it's the same software, why does it do in one image and not the other?
<cachio> google-compute-init calls to cloud init
<cachio> niemeyer, I don't know
<cachio> can't find the code yet
<niemeyer> cachio: OK, so that's what we need to find out
<cachio> niemeyer, ok
<cachio> Saviq, is it running resize2fs as well?
<cachio> or just growpart?
<Saviq> cachio: both
<ogra_> iirc growpart is a python script that shells out to a ton of shell binaries ...
<ogra_> (resize2fs among them)
<cachio> Saviq, ok, tx
<mup> PR snapd#4908 opened: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4908>
<mborzecki-ubuntu> zyga: ^^ a little experiment, at least I see the 'nvidia segfault' now
<Chipaca> niemeyer: snapshots pr has all local changes other than tests (and even some of those, but i'm adding more right now)
<niemeyer> Chipaca: Super, thank you
<mborzecki-ubuntu> zyga: aaand got it working now :P
<mborzecki-ubuntu> zyga: and ohmygiraffe works now
<zyga> Sweet
<zyga> The way we discussed?
<mborzecki-ubuntu> adding a note in the forum topic
<mborzecki-ubuntu> zyga: take a look at the PR
<mborzecki-ubuntu> need to wrap it up for today, still have to make arch boot again :/
<zyga> I will back home
<zyga> Iâm on a bus now
<zyga> Thank you!
<pedronis> mvo: after discussion, what's the plan/timing about releasing 2.32 now ?
<mvo> pedronis: release to candidate asap (ideally today), keep in candidate for a week is the current plan
<pedronis> ok
<pedronis> thx for the update
<mvo> pedronis: yw - given the short time between that and the relase I think there will be a .1 and no .33 for 18.04-final. the .33 will then be a normal SRU
<mvo> pedronis: does that sounds reasonable? i.e. the delay registraion prs will need to be ported
<pedronis> mvo: ok, will need to discuss what goes into .1, ideally delay of registration
<mvo> pedronis: yeah, we can put everything important in there, it just feels risky to do full .33 before the bionic final release
<cachio> niemeyer, I fixed the problem
<cachio> it was a dependency missing
<niemeyer> cachio: Oh, tell me more
<cachio> niemeyer, for fedora we need to install gce-disk-expand
<cachio> which has conflicts with cloud-utils-growpart
<cachio> so we need to remove cloud-utils-growpart and then install gce-disk-expand
<cachio> this is in charged of making the resize
<cachio> cloud init is not used for that
<cachio> I am gonna upload a new image
<cachio> and deprecate the old one
<niemeyer> cachio: After you're done with this, can you please send a message to the forum with all the details of how to get the image in place and working?
<cachio> niemeyer, sure
<cachio> niemeyer, just for fedora or all the images that we use?
<niemeyer> cachio: In N months I'm sure we'll be creating an image for a different distro, or for a new release of an existing distro, and will try to remember these details
<niemeyer> cachio: It can even be something more high-level
<cachio> niemeyer, sure, I am going to add also those scripts to spread-cron soon
<niemeyer> cachio: For no particular distro.. just the process of how to cook the image and make sure it's working
<cachio> niemeyer, ahh, ok
<niemeyer> cachio: It may end up as a mix of the different images.. e.g. maybe there's a detail that is needed for Fedora, and another one for OpenSUSE.. we want both of these details, but no need to repeat what is the same for both
<cachio> niemeyer, ok
<niemeyer> cachio: Yeah, the script is important as we don't want to build those images by hand.. but since all of that is so fresh in your mind, it's good to put down in text so we can easily digest in several months
<cachio> niemeyer, yes, totally agree
<cachio> niemeyer, months or weeks :)
<niemeyer> cachio: Thanks!
<niemeyer> Yes :)
<zyga> re
<zyga> I'm back now
<zyga> I'll unpack and I can return to work in a few minutes
 * kalikiana pipes zyga into `tar -xJf`
<zyga> haha
<zyga> now I need to go on a diet, I'm so much bigger than before :D
<kalikiana> :-D
 * kalikiana wrapping up for the day and looking forward to getting a little bigger over dinner as well
<niemeyer> mvo, zyga: Ready when you are
<zyga> niemeyer: [m]vo went for dinner just now
<zyga> let's wait for him to be back
<niemeyer> zyga: Sounds good
 * Chipaca going offline for a while
<cachio> zyga, when you have a minute, could you plese take a look to #4778
<mup> PR #4778: tests: moving debian 9 from linode to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4778>
<cachio> ?
<cachio> mvo, today is comming new beta, right?
<zyga> +1
<zyga> cachio: yes, hopefully ;)
<cachio> zyga, tx
<mup> PR snapd#4778 closed: tests: moving debian 9 from linode to google backend <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4778>
<zyga> OHHH
<zyga> I just had a mini-heart-attack
<zyga> I checked out release/2.23 by accident
<zyga> and was looking at the set of patches to backport
<zyga> and OMG what's wrong
<cachio> zyga, heart-attack are delayed for 2.34
<cachio> :)
<zyga> man :)
<zyga> 2.23
<zyga> 2.32
<zyga> so silly
<zyga> :)
<cachio> zyga, similar happened to me last week
<cachio> :)
<mup> PR snapd#4909 opened: interfaces: harden snap-update-ns profile (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4909>
<mup> PR snapd#4910 opened: interfaces/apparmor: simplify UpdateNS internals <Created by zyga> <https://github.com/snapcore/snapd/pull/4910>
<zyga> jdstrand: stuff from the sprint ^
<zyga> I just recall this existed because I remembe writing it but coudn't see it in master
<zyga> comitted 16 days ago, I forgot to propose it
<jdstrand> zyga: I recall this being called out in a previous PR. thanks! approved, but please do the requested comment change
<zyga> ook
<jdstrand> it is so easy to forget to update the comments. I did it the other day...
<flexiondotorg> davdunc o/
<davdunc> thanks.
<zyga> niemeyer: I think we can have that call soon
<niemeyer> zyga: Still here
<niemeyer> Just waiting for you and mvo
<mvo> niemeyer: ready
<niemeyer> Ok, let's go
<mup> PR snapcraft#2021 closed: pluginhandler: only resort to elf mangling if the snap type is app  <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2021>
<mup> PR snapd#4819 closed: interfaces/serial: change pattern not to exclude valid devices <Created by bergotorino> <Closed by bergotorino> <https://github.com/snapcore/snapd/pull/4819>
<mup> PR snapd#4819 opened: interfaces/serial: change pattern not to exclude valid devices <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4819>
<mup> PR snapd#4911 opened: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>
<mup> PR snapd#4906 closed: polkit: Pass caller uid to PolicyKit authority <Critical> <Created by chrisccoulson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4906>
<mup> PR snapd#4910 closed: interfaces/apparmor: simplify UpdateNS internals <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4910>
<mwhudson> Laney: re testing casper changes i have this script that mounts an iso, creates an overlay over it, drops you into a shell the repacks a new iso when you exit the shell
<mwhudson> (and does some other stuff)
<mwhudson> would that be useful for this sort of thing?
<cachio> niemeyer, well, gce-disk-expand package does not work well in fedora
<cachio> it works well in CentOS, redhat, RHEL and cloudlinux
<cachio> but fails to start in fedora
<cachio> ubuntu and debian automatically resize the partition when the disk has been resized
<cachio> bet the other OSs are not doing that
<cachio> this project creates a service which makes the resize after reboot, so you can resize a disk for an instance which is already running
<cachio> Pharaoh_Atem, hey
<cachio> I am trying to make fedora resize the partition /dev/sda1 when the system starts in google
<cachio> most of the sytems are resizing the partition when the disk sda is resized
<cachio> but in fedora it is not happening
<cachio> any idea how to do it?
<cachio> the only way I could make it work was adding the resize command as part of the machine init script
<cachio> I am using the fedora cloud image + some google dependecies
<pedronis> mvo:   what's the plan   with #4911, will it mean we need snapd running (always) for snap run? feel free to answer tomorrow, just asking/wondering before IÂ forget
<mup> PR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>
<mvo> pedronis: we discussed this with zyga and niemeyer and the idea is that if snap run detects a system-key change it should talk to snapd to double check what is going on
<pedronis> I see, so a 2nd line of check
<mvo> pedronis: so this communication would only happen in the (rare) case when the system-key that snap run calculates and that is on disk mismatch
<mvo> pedronis: exactly
<pedronis> thanks for the answer
<mvo> pedronis: I think there are still some corners to think about, what if its a local build of snapd run for testing, how should snapd behave. but I think all the open questions are really the developer case, i.e. you run snapd or snap from a local build
<pedronis> mvo: I'm probably confused, are you off tomorrow? or starting monday?
<mvo> pedronis: technically tomorrow but the amount of fires make it unlikely
<mvo> pedronis: so I will swap that day with another day
<pedronis> ok, makes (sadly) sense
<mvo> pedronis: yes
<mvo> 4882 is a fun PR to review if someone feels inclined to do so :)
<Laney> mwhudson: that sounds nice, you should make it available
<Laney> mwhudson: for the casper scripts you have to update the initramfs and then make that available in casper/initrd.lz (iirc) too
<cachio> niemeyer, please tell me if this makes sense https://github.com/snapcore/spread/pull/55
<mup> PR spread#55: Make possible to add an initialization script for custom images <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/55>
<mup> PR snapd#4912 opened: overlord/configstate: change how ssh is stopped/started <Created by zyga> <https://github.com/snapcore/snapd/pull/4912>
<zyga> niemeyer: ^
<bashingboi> has anyone tried the firefox snap in debian/centos?
#snappy 2018-03-23
<bashingboi> and if so, how does it run performance wise?
<zyga> bashingboi: I haven't tried on debian yet
<zyga> I can try tomorrow
<zyga> today I should really hit the bed :)
<bashingboi> ha, np. I will try for myself and check how it runs
<mwhudson> Laney: yeah i guess unpacking repacking the initramfs is even more steps
<mwhudson> Laney: it's at https://github.com/CanonicalLtd/subiquity/blob/master/scripts/inject-subiquity-snap.sh although bits of that are hardcoded for subiquity, the general bits could be extracted i think
<mborzecki> morning
<zyga> o/
<zyga> mborzecki: can you please review https://github.com/snapcore/snapd/pull/4912
<mup> PR #4912: overlord/configstate: change how ssh is stopped/started (2.32) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4912>
<zyga> mborzecki: if you have a kvm or a pi at home it's best to try it for real too
<mborzecki> zyga: looking
<mborzecki> zyga: wasn't sshd.service -> ssh.service already addressed by a patch from mvo?
<mborzecki> zyga: or maybe it was the other way around
<zyga> it was
<zyga> but it broke badly
<zyga> once sshd is disabled
<zyga> it cannot be enabled
<zyga> because it is an alias
<mborzecki> zyga: snapd alias or some sort of system alias?
<zyga> systemd alias
<zyga> look at systemctl cat ssh.service
<zyga> sshd is an alias there
<zyga> if you disable ssh.service
<zyga> the alias goes away
<zyga> and cannot be enabled, started or stopped
<zyga> we used sshd instead of ssh because of the issue with writable paths
<zyga> if you just switch to ssh everything is fine
<zyga> but then you reboot
<zyga> and ssh is re-enabled
<zyga> because writable paths is terrible
<zyga> and ssh is enabled by default so it bring the file back
<zyga> this is why I used two things: sshd -> ssh so that enable/disable works
<zyga> and the conditional file to actually control being off or on
<mborzecki> i'm reading up the systemd.unit manpage
<zyga> ok
<mborzecki> nice, > aliases specified through Alias= are only effective when the unit is enabled.
<zyga> I may have missed something, hence the request for review
<zyga> it's an urgen issue affecting customer deployments
<mborzecki> zyga: wow that service file is interesting
<mborzecki> zyga: sshd_not_to_be_run is a debian thing right?
<zyga> Probably
<mborzecki> zyga: a similar attemp was there in configure hook in the core snap https://github.com/snapcore/core/commit/dc782a37a3aef3fb11f256260f5205f2ff256acd
<zyga> oh, that's interesting
<zyga> we we had this
<zyga> and lost this?
<mborzecki> yeah, i was looking for the actual contents of writable paths and found this instead :P
<mup> PR snapd#4903 opened: tests: [WIP] split prepare-restore.sh into prepare-restore.d modules <Created by zyga> <https://github.com/snapcore/snapd/pull/4903>
<mup> PR snapd#4913 opened: interfaces,release: probe seccomp features lazily <Created by zyga> <https://github.com/snapcore/snapd/pull/4913>
<zyga> hmmm, my PR just got a massive TLS handshake failure with everything (google, linode)
<zyga> all tasks aborted
<zyga> hope this is not a norm today
<mborzecki> zyga: ok, played a bit with core image, if i understand it right since we disable the service, the symlink is removed from etc, but then it's still restored from core snap because /etc/systemd/system is synced in writable-paths?
<zyga> yes
<zyga> that's the issue
<zyga> that's the reason we switched to sshd service
<zyga> but this had unintended consequences
<mborzecki> from what i see disabling/masking sshd does not work either
<zyga> yep
<zyga> I'm testing another mode now
<zyga> where sshd was disabled
<zyga> thus breaking people
<zyga> and chceking if the new core with my fix  heals that
<mborzecki> hah, now i'm locked out of the ssh, and serial console only shows the prompt with ssh login :P, how can i log in?
<zyga> mborzecki: ha
<zyga> yank the card
<zyga> set a password
<zyga> and put it back in
<zyga> mvo: so to recap
<zyga> mvo: I tested the scenario where sshd.service was disabled
<zyga> and that the new patched snapd can fix that state simply by rebooting (which happens on update) and starting ssh.service
<zyga> by setting the core config value
<zyga> so I think this is a fix for the issue in general and for the machines affected in particular
<mvo> zyga: we do more than just disable, we also mask, I think this will result in a different outcome
<mvo> my feeling is that we need to at least unmask (opportunisticly and ignore the error)
<zyga> I will test that now
<zyga> yes, perhaps
<zyga> mvo: I think masking doesn't work
<zyga> zyga@localhost:~$ sudo systemctl disable sshd.service
<zyga> zyga@localhost:~$ sudo systemctl mask sshd.service
<zyga> Failed to execute operation: File exists
<zyga> the initial state was that neither sshd nor ssh were masked
<mvo> zyga: let me check
<zyga> hmm
<zyga> maybe I'm wrong
<zyga> let me reset everything
<mvo> zyga: it used to be the case, we masked ssh.service and then sshd.service would reappear via the writable-magic. but let me double check :)
<zyga> ok
<zyga> tested that now
<mvo> my vm will take a moment to be ready, it has an older core
<zyga> initial state https://www.irccloud.com/pastebin/BMckHA77/
<zyga> so sshd is disabled and masked
<zyga> now I'm setting the core config
<zyga> and ssh starts and I can log in
<zyga> ah
<zyga> because I *start* it
<zyga> not enable it
<zyga> let's reboot now
<zyga> I mean, the hack just starts ssh directly
<zyga> so even if sshd is masked
<zyga> that's not an issue
<zyga> I think we should unmaks it though
<zyga> but it's not for corectness
<zyga> but more for purity
<zyga> mvo: it's also good after reboot
<zyga> even though sshd is masked
<mvo> zyga: even with the mask?
<zyga> lrwxrwxrwx 1 root root 9 Mar 23  2018 /etc/systemd/system/sshd.service -> /dev/null
<mvo> zyga: wuuut? crazy
<zyga> (this is after reboot)
<zyga> woah
<zyga> https://www.irccloud.com/pastebin/LHAlPevl/
<zyga> look at this
<zyga> sshd.service changed on disk
<zyga> this is after reboot, no touching at all
<zyga> how come?
<zyga> I'll reboot again just to be 100% sure
<mvo> zyga: I think its confusion from ssh.service vs sshd.service but let me double check
<zyga> so  +1 to unmask it
<mvo> zyga: I'm so happy we have the /etc/ssh_no_start thing, this unit aliases seem to be crazy
<zyga> yes, I have the same feeling
<zyga> testing the new build now
<zyga> I need to buy some more serial ports
<pstolowski> mornings
<zyga> this makes testing so much easier
<mborzecki> mvo: pstolowski: morning guys
<mvo> hey mborzecki
<mborzecki> zyga: mvo: could we straighten out the situation with ssh instead of using that ssh_no_run.. monstrosity?
<mvo> mborzecki: maybe
<mvo> mborzecki: so there are multiple issues
<zyga> mborzecki: do you have a proposal?
<zyga> I mean, yes, but not trivially
<kalikiana> good morning
<zyga> we'd have to remove writable-path sync on systemd services
<mvo> mborzecki: our ssh.service is using Alias=sshd.service
<mvo> mborzecki: our core snap has "/etc/systemd/system/sshd.service" which is in writable-paths marked as "sync". this means that when the file is missing it will be copied from the core snap
<mborzecki> as i understand we could fix it in the core snap, have just one ssh.service and no aliases
<mvo> mborzecki: so we need to unmask both ssh and sshd service
<mvo> mborzecki: yes, I think that is a good idea, fix the core snap to a) remove the alias b) not use /etc/ but /lib for the unit
<mvo> mborzecki: but its more risky than what zyga is doing
<mvo> mborzecki: what I really like about the zyga PR is that its dead-simple
<zyga> mvo: force pushed with the unmask
<zyga> tested that it works all the way
<mvo> ta
<mborzecki> mhm, it is :)
<mvo> mborzecki: but gustavo also wants to talk about this so maybe it will be solved differently :)
<zyga> mvo, mborzecki: one note, we need to tie this to core16
<zyga> with core18 the approach should be direct and without hacks
<mvo> zyga, mborzecki I think its fine to revisit this very soon and fix core16 directly, i.e. fix our ssh install and go back to straight systemctl stop/disable ssh
<mborzecki> as far as i'm considered, it's +1, but ideally we should fix this and use ssh.service (or sshd, just make sure that it's a single one, no aliases or whatnot)
<mvo> agreed
<zyga> (sshd cannot be used)
<zyga> we must use ssh.service
<zyga> and get rid of that sync stanza on that director
<zyga> *directory
<mvo> mborzecki: whats also annoying is that even if we do stop/disable/mask ssh and sshd it fails on enable because the operations are not symetric
<mvo> mborzecki: i.e. unmask/enable/start ssh sshd will fail during enable sshd because it says there is a symlink alsready
<mborzecki> mvo: yeah, i did this in the console :P
<mvo> mborzecki: which boggles my mind, but maybe I'm missing something
<mborzecki> and then locked out myself :P
<zyga> haha
<zyga> :D
<zyga> well
<mvo> mborzecki: like how can you sanely stop a service with aliases
<mvo> mborzecki: haha
<zyga> I'm happy with this patch
 * mvo hugs zyga 
<zyga> I won't touch it until we talk to gustavo
 * mvo hugs zyga harder
<mborzecki> mvo: 'Failed to execute operation: Too many levels of symbolic links' maybe it's something in system(d,ctl) too
<mvo> mborzecki: yeah
<mvo> mborzecki: like "wuuuuut"?
<mvo> mborzecki: what kind of error is that to begin with
<pedronis> mvo: hi, there's quite bit of PRs marked for 2.32,  anything in particular that IÂ could help with a review?
<mvo> mborzecki: anyway, sorry, I'm still perplexed how difficult it is to disable ssh via systemctl
<mborzecki> zyga: pushed an update to #4902
<mup> PR #4902: cmd/snap-confine: nvidia: preserve globbed file prefix <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4902>
<mvo> pedronis: let me unmark some
<mborzecki> mvo: disabling is simple, making sure that it never gets enabled is a bit harder :P
<mvo> pedronis: 4882 might be a good one, that is the most critical one right now
<mvo> mborzecki: heh, exactly
<zyga> I'll push a unmask of ssh.service now
<zyga> just testing that after reboot
<mvo> mborzecki: quick question about 4902 - that fixes nvidia issues on arch?
<pedronis> mvo: does 4882 need a follow up to use 4911 ?
<mborzecki> mvo: yes, there's another pr for ubuntu #4908 (though still RFC) that includes the patch from 4902
<mvo> pedronis: yes, I will talk to gustavo about it
<mup> PR #4908: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4908>
<mvo> pedronis: I think technically 4882 will solve the problems we are seeing but gustavo was keen to add the second layer of check (snap run talking to snapd on system-key mismatch)
<mvo> mborzecki: ta
<zyga> mvo: unmasking both now
<mvo> zyga: ta
<mup> PR snapd#4909 closed: interfaces: harden snap-update-ns profile (2.32) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4909>
<mup> PR snapd#4907 closed: advisor: deal with missing commands.db file <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4907>
<mup> PR snapd#4913 closed: interfaces,release: probe seccomp features lazily <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4913>
<mup> PR snapd#4914 opened: advisor: add comment why osutil.FileExists(dirs.SnapCommandsDB) is needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/4914>
<mup> PR snapd#4915 opened: interfaces,release: probe seccomp features lazily <Created by mvo5> <https://github.com/snapcore/snapd/pull/4915>
<pedronis> mvo: left some questions/comments
<mvo> pedronis: yay,thank you!
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/4902/files#r176670685
<mup> PR #4902: cmd/snap-confine: nvidia: preserve globbed file prefix <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4902>
<mborzecki> zyga: responded :)
<zyga> replied too
<mborzecki> zyga: ok, makes sense, btw. i was surprised by it too
<pedronis> mvo: not urgent but I'm confused/see some duplication of things in the roadmap page (for 2.32 and 2.33 and after)
<zyga> mvo: did you notice https://github.com/snapcore/core/commit/dc782a37a3aef3fb11f256260f5205f2ff256acd
<zyga> mborzecki pointed me to it
<mborzecki> zyga: force pushed
<zyga> thank you
<mborzecki> damn, i feel sick, finally caught something from the junior
<mvo> zyga: no, huh
<zyga> mborzecki take it easy
<zyga> mvo: fun, right?
<zyga> where is that, it's gone now?
<zyga> it was lost when we went to in-core config
<mvo> zyga: yeah :(
<mvo> zyga: sadly
<zyga> full circle
<Chipaca> 'sup?
<zyga> Chipaca: fire, smoke, screams and tears
<Chipaca> zyga: I didn't ask about your bedroom
<zyga> Chipaca: it's slowly getting better onw
<Chipaca> zyga: good to hear :-)
<Chipaca> what did we lose by moving to in-core config?
 * Chipaca curious
<zyga> Chipaca: ssh control
<zyga> https://github.com/snapcore/snapd/pull/4912
<mup> PR #4912: overlord/configstate: change how ssh is stopped/started (2.32) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4912>
<kalikiana> so, I have a question about the ssh-keys interface. I added it to my snap, did `snap connect` to enable it but when the snap runs I'm getting `Permissions 0644 for '/home/rumo/.ssh/id_local' are too open.`
<kalikiana> The permissions that ls reports within --shell as the same as on the real system, though. And of course the permissions are correct on the real system.
<mvo> zyga: quick question about reverts from 2.32 -> 2.31. the new/updated security profiles will break reverts, no? I mean, suppose 2.32 has the stricter profiles and it loads the per-snap update-ns profiles. now on revert the old snap run will start network-manager and that will use the new 2.32 profiles which are strict and won't let n-m run, is that correct?
<zyga> on revert snap-confine will load the old profile which is permissive for content and doesn't support layouts
<Chipaca> kalikiana: that's very weird
<Chipaca> kalikiana: is the snap in the store? i'd like to take a look
<zyga> mvo: the snap-confine profile is from core directly
<mvo> zyga: awsome
<zyga> mvo: and the issue didn't affect the regular profiles, just s-u-n profile
<mvo> zyga: so no problem here, just wanted to double check
<zyga> mvo: I think it should work
<zyga> but I did not check
<mvo> zyga: its part of our standard tests so we will know
<zyga> ok
<kalikiana> Chipaca: I haven't pushed that bit yet since it's not working, but I can push it
<Chipaca> kalikiana: is it an easy to build snap?
<Chipaca> i mean, just run snapcraft and wait sort of thing?
<Chipaca> in that case i could use just the snapcraft.yaml :-)
<Chipaca> to be clear, this is just me being lazy: i'd rather tinker with it to figure out what's going on, than think about it in the abstract
<mvo> zyga: hey, does https://paste.ubuntu.com/p/jxtYz7z9CD/ ring any bells?
<zyga> mmm
<mvo> zyga: happend on master
<zyga> is that on release
<zyga> aww
<zyga> I didn't push the debug thing to master
<zyga> mvo: can you please force-land that https://github.com/snapcore/snapd/pull/4916
<mup> PR #4916: tests: change debug for layout test <Created by zyga> <https://github.com/snapcore/snapd/pull/4916>
<mup> PR snapd#4916 opened: tests: change debug for layout test <Created by zyga> <https://github.com/snapcore/snapd/pull/4916>
<Chipaca> kalikiana: so, I can't reproduce your issue
<Chipaca> kalikiana: wondering what's different between here and there
<Chipaca> kalikiana: one thing though, i don't think your snap needs to include openssh-client, as that's part of core and ssh-keys gives you access to it (at least to /usr/bin/ssh)
<Chipaca> but here it works with both the ssh in the snap, and the one in core
<kalikiana> Ah, I didn't realize that. So I can drop the package.
<Chipaca> kalikiana: but that doesn't answer where the 0644 error is coming from :-)
<kalikiana> Chipaca: Could it be a bug in snap connect then? Vaguely thinking of content interface issues depending on the order of install/connect/snap executation
<Chipaca> kalikiana: wait, can you ssh from within --shell?
<Chipaca> that's what i am doing and it works, if it works for you as well the issue is even weirder
<kalikiana> Chipaca: No, same error, even on a simple "ssh helga" (helga being an arbitrary host that works outside confinement)
<Chipaca> phew
<kalikiana> Chipaca: Also getting a `Control socket connect(/home/rumo/.ssh/socket-root@***.***.***.***:22): Permission denied`with just ssh, before the other error
<Chipaca> kalikiana: just to make sure, can you âfind /home/rumo/.ssh -lsâ?
<kalikiana> Chipaca: That works and lists each key with -rw-r--r--
<Chipaca> kalikiana: inside, or outside?
<kalikiana> Chipaca: both are the same
<Chipaca> kalikiana: why are your private keys world-readable?
<Chipaca> kalikiana: (see also: how is your ssh 'outside' not complaining about it all the time?)
<kalikiana> Hmmm now that you mention it, they probably shouldn't be...
<kalikiana> Chipaca: Outside is fine
<Chipaca> kalikiana: fine how?
<kalikiana> As in, I get no errors
<Chipaca> right
<kalikiana> But lemme try and change them
<Chipaca> kalikiana: but you should :-)
<Chipaca> kalikiana: only thing I can think of is that you have seahorse auto-adding your ssh keys on session start, and it's less picky about permissions, and ssh never looks at your actual keys because by the time you run it they're in the agent
<Chipaca> kalikiana: if that's the case, it sounds like a bug in seahorse to me ;)
<Chipaca> kalikiana: but also, sounds like an easy thing to detect and warn about from your snap
<Chipaca> ie, can i access the keys? no: tell user about snap connect, yes: are they the right perms? no: tell user about it
<kalikiana> Dropping the group/world reads seems to fix it indeed.
<kalikiana> Now ssh just tells me `bind: Permission denied` and `unix_listener: cannot bind to path`
<mborzecki> zyga: i think i need to check for a specific library in autodetection, one thats' always there, libnvidia-glcore.so.<maj>.<min> looks like a good candidate
<kalikiana> But it unlocked the key/passphrase fine
 * kalikiana tests git push from the snap
<Chipaca> kalikiana: that socket might be a control master thing, which isn't supported from inside
<Chipaca> kalikiana: (the thing that lets you multiplex ssh sessions over a single connection)
<kalikiana> Chipaca: You were right, disabling it explictly works
<kalikiana> Chipaca: Thanks a lot for helping me track this down!
<cachio> Saviq, a new fedora image with the correct size is uploaded
<kalikiana> Now if it'd actually use the ssh agent, that'd be sweet, but it works perfectly
<Saviq> cachio: ack, me tries
<cachio> Saviq, great, tell me how if goes
<Saviq> cachio: -64 suffix, too?
<Chipaca> kalikiana: talk with jdstrand, but I suspect much laughter to be had :-)
<kalikiana> :-D
<cachio> Saviq, fedora-27-64
<cachio> this is the name you have to use
<cachio> Saviq, you don't need to specify the image
<mborzecki> zyga: can you take another look at #4902?
<mup> PR #4902: cmd/snap-confine: nvidia: preserve globbed file prefix <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4902>
<mborzecki> zyga: also i'm finishing with fixes for 4908 and will be switching back to ubuntu to check if things didn't break :)
<Chipaca> zyga: might #1757284 be an instance of the 'interface connections go away' bug?
<mup> Bug #1757284: Several snap apps fail to launch <amd64> <apport-bug> <bionic> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1757284>
<Chipaca> (now that i think about it, it probably is -- but don't know that bug #)
<zyga> mborzecki: looking
<mup> PR snapd#4916 closed: tests: change debug for layout test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4916>
 * Chipaca attempts to dad up and get out of bed
<zyga> Chipaca: updated the bug with a question
<Saviq> cachio: yeah, it's lookin' good https://travis-ci.org/MirServer/mir/builds/357325003
 * Chipaca AFK for a while (physio, etc)
<mvo> pedronis: hrm, hrm, my system-key pr has a bit of a problem on core. on firstboot on core snapd starts, generates the system-key and the core revision is empty (because things are not seeded yet). then stuff gets seeded but that means the systme-key changes because the core revision is part of the inputs
<mvo> zyga: (cc -^)
 * mvo will need to think about this while taking a short lunch break
<zyga> hmm hmm hmm
<zyga> mvo: if we drop core revision?
<zyga> we keep it because apparmor profiles are there (includes)
<zyga> hmm :/
<mvo> zyga: yeah, feels strange to just drop it, but maybe we can drop it on core?
<zyga> well, if apparmor gets updated
<mvo> zyga: let me try that
<zyga> and snapd doesn't
<zyga> it's not correct then
<mvo> zyga: hm, good point
<pedronis> will apparmor come from the snapd snap?
<pedronis> fun questions
<cachio> Saviq, nice
<cachio> good to hear that
<pedronis> don't we check the feature of apparmor becuase of that?
<mvo> pedronis: partly, the abstractions are also part of the mix and those come from the core snap
<mvo> pedronis: apparmor has two inputs: the kernel capabilities and the abstractions with pre-writen rules
<mvo> we could force a re-gen of the profiles after seeding but thats a bit ugly
<mvo> full of dragons this pr
<mborzecki-ubuntu> https://paste.ubuntu.com/p/77k9YJbVQK/
<mborzecki-ubuntu> humanSuite.TestHuman failed here, but was passing yesterday
<zyga> pedronis: yes, apparmor will come from core snap (on core)
<zyga> pedronis: I mean the include statements, we check for kernel features but each profile we make has include statements that reach to apparmor profiles from either native package or from the core snap on all-snap boxes
<mborzecki-ubuntu> Chipaca: DST change https://paste.ubuntu.com/p/77k9YJbVQK/
<zyga> LOL
<zyga> stuff will never stop to amaze me
<mborzecki-ubuntu> otoh, i had no clue that we're changing clocks on saturday ;)
<pedronis> mvo: also the issue with seeding exists also on classic
<pedronis> mvo: we support seeding there with snaps
<zyga> mvo: I have an idea
<pedronis> mvo: it's a bit unclear to me why are we writing a key before being seeded ?
<pedronis> mvo: we should wait/skip that, if there are not snaps, we are not seeded
<zyga> mvo: instead of revision we can inspect a single file in /meta/manifest
<zyga> (we don't have that file yet)
<zyga> but as long as it encodes the version of every package
<zyga> it caputres the essence of core
<zyga> pedronis: we need that on boot to setup profiles for core itself
<zyga> pedronis: on snapd daemon startup actually
<Chipaca> mborzecki: on the one hand, huzzah it works
<Chipaca> mborzecki: on the other, booo
<pedronis> zyga: ok, there's a recursion problem here
<Chipaca> mborzecki: on the last one, a test that works 350 days a year is fine, right?
<pedronis> the double build-id doesn't make sense then
 * Chipaca now really goes
<zyga> pedronis: can you explain?
<pedronis> zyga: we generate profile with a key id without build-id  for a thing that by definition has one
<Chipaca> mborzecki: actually that might be a real bug, need to look when i get back
<pedronis> then we regenerate just because
<zyga> pedronis: why without a build-id?
<pedronis> zyga: because there's no /snap/core/current
<pedronis> at that point
<pedronis> at least that's what I understood was the problem
<pedronis> mvo mentioned
<zyga> pedronis: on core we could just use /usr/lib/snapd/snapd
<zyga> no need for core's build-id
<pedronis> zyga: as I said the same issue exists with classic seeding
<pedronis> first boot is not a core only thing
<zyga> on classic we can use /proc/self/exe
<zyga> but we cannot capture apparmor changes in the distro
<zyga> but I think that is done by apparmor itself, it has a trick to detect that in the init script
<pedronis> zyga: did you look at the PR, the system-key has two build-ids in it
<pedronis> atm
<zyga> yes, we discussed that last night
<mup> PR snapd#4917 opened: repo: added repo ConnectionsInfo method (for the new snap connections API) <Created by stolowski> <https://github.com/snapcore/snapd/pull/4917>
<zyga> I think we can evolve that pattern
<pedronis> on core we need only one
<pedronis> but on classic
<pedronis> we have a problem
<zyga> on classic we also need only one but we did two because that's easier
<pedronis> but then seeding
<zyga> (because we don't know which)
<pedronis> it's not easy anymore
<zyga> mvo: what do you think?
<zyga> pedronis: I agree
<zyga> pedronis: no easy way out yetr
<zyga> *yet
<pedronis> one issue is also that we think reexec
<pedronis> is something you can turn on and off
<pedronis> easily
<pedronis> but is quite true
<pedronis> especial if you are outside snapd and the inside snapd
<pedronis> are far apart
<pedronis> *is not quite true
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/4908#issuecomment-375392384
<mup> PR #4908: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4908>
 * cachio afk
<mup> PR snapd#4903 closed: tests: [WIP] split prepare-restore.sh into prepare-restore.d modules <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4903>
<mborzecki> zyga: it's alredy fixed, i also improved detection and look for a specific nvidia lib (libnvidia-glcore.so), the packaging is also updated, now i'm cleaning up s-c apparmor profile
<mborzecki> zyga: https://github.com/bboozzoo/snapd/commits/bboozzoo/nvidia-glob-prefix-ubuntu-triplet-wip if you want to take a look
<pedronis> mvo: zyga: IÂ made a comment,  one idea  could be to simply delay writint the key when we are not yet seeded
<zyga> thanks,
<zyga> but this is going to change one important property
<zyga> (perhaps)
<zyga> that daemon doesn't respond to api requests before having stable security profiles
<pedronis> ?
<zyga> maybe if we are not seeded (rare) we should just always rewrite profiles on startup (mvo: opinion?)
<zyga> actually, I'm confused: writing the system key is not the same as computing it in memory
<zyga> so perhaps that's okay
<pedronis> if we are seeded there no snap profiles
<pedronis> sorry
<zyga> that's true
<pedronis> if we are not seeeded
<zyga> yes, that's a good point
<pedronis> I'm  saying,  if not seeded delay until we really need it
<pedronis> which is about when we generate profiles for core
<pedronis> (which is the first thing we seed)
<zyga> right, I understand that now, I forgot that not seeded == nothins is installed
<zyga> so I think this is okay
<pedronis> IÂ might be missing something
<zyga> mborzecki: interesting https://build.opensuse.org/request/show/590390
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/4917#pullrequestreview-106469715
<mup> PR #4917: repo: added repo ConnectionsInfo method (for the new snap connections API) <Created by stolowski> <https://github.com/snapcore/snapd/pull/4917>
<mborzecki-ubuntu> zyga: that opensuse review looks good, maybe advise him to update to 2.31.2 while at it
<zyga> I'll merge it and encourage him to iterate
<zyga> mborzecki-ubuntu: the package is not buildable on leap though
<zyga> actually, I didn't merge it but I added some comments
 * zyga lunch
<mborzecki-ubuntu> zyga: i'll force push to #4908
<mup> PR #4908: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4908>
<zyga> k
<mborzecki-ubuntu> and pushed
<mborzecki-ubuntu> ohmygiraffe works with nvidia and confinement now ;)
<mborzecki-ubuntu> let me try the the flare snap
<niemeyer> Glad for your giraffe :P
<niemeyer> Morning all
<mvo> pedronis: delaying sounds reasonable, let me have a look at this
<pedronis> Chipaca: is you that moved the waitMixin stuff to its own wait.go file?
<Chipaca> pedronis: that sounds like me
<Chipaca> pedronis: why
<pedronis> Chipaca: there's a function in cmd_snap_op.go  that probably should have moved too, given that is used only in the wait code, lastLogStr
<Chipaca> pedronis: ah, good call
<pedronis> Chipaca: I noticed because I'm solving conflicts in one of my old PRs
<mvo> pedronis, zyga yet another `snap run` system-key issue on core. when we install a new core we update "current". but we only reboot ~10min later. during that time the system-key on disk and the one that snap run calcualtes are different because /snap/core/current is part of the inputs
<pedronis> mvo: I'm fixed the 10 minutes things but that's part of the problem
<pedronis> *that's only
<mvo> pedronis:
<mvo> pedronis: yes
<pedronis> mvo: I suppose there the endpoint might help
<sergiusens> mvo: is there a way to `snap run --shell core18....`?
<Chipaca> sergiusens: no, snap run only runs apps*
<Chipaca> * and hooks but you don't want to do that
<mvo> sergiusens: a trivial snap that just has a /bin/sh and uses base: core18
<mvo> sergiusens: might be the solution
<sergiusens> mvo: yeah, I am doing just that; to verify core18 is in good shape (using the test job I created, but using yours should be fine as well, I couldn't find it from the store just yet though)
<sergiusens> python/asciinema base: core18 and install to test the story end2end
<sergiusens> mvo ok, everything is working now
<mvo> sergiusens: sys
<mvo> sergiusens: eh, I mean yay
<sergiusens> lol, I was trying to decipher that :-P
<pedronis> Chipaca: this bit of code seems nonsensical or am I confused?:   https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_snap_op.go#L543
<zyga> E: Type 'curity' is not known on line 50 in source list /etc/apt/sources.list
<zyga> E: The list of sources could not be read.
<zyga> how did we get 'curity' out of 'security'
<Chipaca> pedronis: that looks broken indeed
<zyga> https://api.travis-ci.org/v3/job/357284871/log.txt
<pedronis> Chipaca: I find it by chance, IÂ suppose not all the error paths are tested :/
<zyga> mborzecki-ubuntu: https://github.com/snapcore/snapd/pull/4908 broken
<mup> PR #4908: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4908>
<mborzecki-ubuntu> zyga: force pushed  just now
<mborzecki-ubuntu> zyga: `dpkg-architecture -a i386` doesn't work on 14.04, you need to do `dpkg-architecture -ai386` :/
<Chipaca> pedronis: the wait one is hard to test i guess
<Chipaca> seems to be the only one with that particular bug though :-)
<pedronis> yes
<pedronis> funnily enough my test used that one command
<niemeyer> Hangouts going crazy
<Chipaca> pedronis: do you want me to fix it, or will you?
<pedronis> Chipaca: IÂ can make a PR in a bit, also moving that other function
<pedronis> Chipaca: trying to finish the merge right now
<Chipaca> pedronis: k
<mvo> cachio: for the sru validation, could you pastebin the failures again for me please (or link)
<mborzecki> Chipaca: if you're willing to try the nvidia stuff, please grab https://github.com/snapcore/snapd/pull/4908
<mup> PR #4908: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4908>
<Chipaca> mborzecki: actual nvidia, right?
<Chipaca> I need to restart my session for that, give me a mo'
<mborzecki> Chipaca: yes
<ackk> mvo, hi, WRT the discussion at the sprint about having a "nobody" user snaps, has there been further discussion on whether that's acceptable?
<Chipaca> mborzecki: what do i need to build against this to test?
<mborzecki> Chipaca: just build and reinstall the package, add SNAP_REEXEC=0 to /etc/environment to make sure you're runing the right thing
<mborzecki> Chipaca: once snapd deb is installed, please snap install graphics-debug-tools-bboozzoo too
<Chipaca> mborzecki: â¦ i'm getting the DST change error also
<mborzecki> Chipaca: i've commented it out locally :) sorry
<Chipaca> mborzecki: is this your revenge for that code :-)
 * Chipaca runs it agian with DEB_BUILD_OPTIONS=nocheck
<mborzecki> Chipaca: can you also do `cat /sys/module/nvidia/version`?
<Chipaca> mborzecki: 384.111
<Chipaca> mborzecki: snapd build and running
<Chipaca> mborzecki: an' now?
<mborzecki> Chipaca: have you installed graphics-debug-tools-bboozzoo --edge?
 * mborzecki forgot to mention --edge before
<Chipaca> mborzecki: graphics-debug-tools-bboozzoo  1.0      3    edge      maciek-borzecki  -
<cachio> mvo, https://paste.ubuntu.com/p/KB7SyvgRn4/
<mborzecki> Chipaca: SNAP_CONFINE_DEBUG=1 SNAPD_DEBUG=1 snap run graphics-debug-tools-bboozzoo.glxinfo |& tee log and paste the log somewhere
<cachio> these are the spread tests
<mborzecki> oh, and SNAP_REEXEC=0
<cachio> mvo, give me 5 minutes
<mborzecki> Chipaca: SNAP_CONFINE_DEBUG=1 SNAPD_DEBUG=1 SNAP_REEXEC=0 snap run ..
<cachio> mvo, also many of the autopkgtets failed because of "package context: unrecognized import path "context" (import path does not begin with hostname)"
<cachio> seem to be a different go version installed there
<Chipaca> mborzecki: http://paste.ubuntu.com/p/94hmf6KcHN/
<Chipaca> mborzecki: do you also want me to test it with the intel board (ie with prime turned off)
<Chipaca> or turned to nvidia
<mborzecki> Chipaca: looking good, can you try some snap that does graphics? eg. ohmygiraffe
 * Chipaca doesn't know what these things are called
<Chipaca> mborzecki: ohmygiraffe, supertuxkart and minecraft worked
<pedronis> Chipaca: I managed to add tests, not super interesting tests but better than nothing
 * Chipaca hugs pedronis 
<Chipaca> pedronis: thank you
<Chipaca> mborzecki: so as far as i'm concerned there is no regression with this :-)
<mborzecki> Chipaca: one more thing, can you sudo nsenter -m/run/snap/ns/ohmygiraffe.mnt
<mborzecki> Chipaca: and then `cat /proc/self/mountinfo` and paste it
<Chipaca> mborzecki: snapd, but yes
<mborzecki> right /run/snapd/ns/..
<Chipaca> mborzecki: whoa, leaving the mountspace makes x unhappy for a bit
<mborzecki> hm? how so?
<mborzecki> Chipaca: if you could also check that intel works :)
<mborzecki> zyga: mvo: do we want the nvidia fixes for 2.32?
<Chipaca> mborzecki: http://paste.ubuntu.com/p/4GhMJmt22t/
<Chipaca> mborzecki: or http://paste.ubuntu.com/p/Rp7TQVjsDY/
<Chipaca> mborzecki: I can try nvidia in a bit
<mborzecki> Chipaca: great, so it doesn't regress and mounts the right thing :)
<Chipaca> mborzecki: wrt leaving the mount namespace, it's as if i'd gone to console and back
<Chipaca> even redshift gets reset
<mborzecki> Chipaca: that's weird, maybe it's because the env is still there
<Chipaca> mborzecki: you don't see that?
<mborzecki> nope
<Chipaca> ok, switching to nvidia
 * Chipaca in a rush
<Chipaca> mborzecki: http://paste.ubuntu.com/p/yKb7RhVffw/
<Chipaca> mborzecki: with intel
<Chipaca> mborzecki: but â¦ the ns are still there, i guess, maybe that's the problem?
<Chipaca> mborzecki: http://paste.ubuntu.com/p/8xhdRfjnZw/
<Chipaca> now 3d apps don't work
<mborzecki> Chipaca: is the driver loaded now? lsmod|grep nvidia?
<Chipaca> mborzecki: i've got to go, but i'll be back in ~45
<Chipaca> mborzecki: it is not
<mup> PR snapd#4918 opened: cmd/snap:  fix one issue with noWait error handling logic, add tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4918>
 * Chipaca runs
<mborzecki> Chipaca: sudo /usr/lib/snapd/snap-discard-ns graphics-debug-tools-bboozzoo
<mborzecki> ah ok :) i'll leave you some notes here
<mborzecki> Chipaca: thank you for testing this
<mup> PR snapcraft#2022 opened: Polish our landing page â¨ <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/2022>
<pedronis> mvo: zyga: on classic we use the apparmor abstractions from the host? or from core ?
<mvo> pedronis: host
<pedronis> mvo: that is not really part of the system key atm, no?
<pedronis> then
<mvo> pedronis: yes, we just discussed htis that we can drop
<mvo> pedronis: which makes the whole problem much easier
<mvo> pedronis: also on core we apparently don't need this input because one of the init scripts (apparmor init) will rebuild the profiles if the abstraction change
<mvo> pedronis: this makes the problem on core go away when the current symlink is missing
<mvo> pedronis: eh, missing or updated too early
<mvo> pedronis: which is really nice, I will update my PR now with this, I hope we finally have figured it out
<Chipaca> zyga: ping
<Chipaca> ah, maybe nothing
<pedronis> Chipaca: IÂ pushed #4918
<mup> PR #4918: cmd/snap: fix one issue with noWait error handling logic, add tests plus other cleanups <Created by pedronis> <https://github.com/snapcore/snapd/pull/4918>
<Chipaca> pedronis: ok
<zyga> Iâm on a walk
<cachio> mvo, there?
<pedronis> mvo: let me know when/if IÂ should look again
<mvo> cachio: yes, sorry
<mvo> pedronis: will do
<cachio> np
<cachio> so, about the sru
<mvo> yes
<cachio> mvo, did you see the expect error?
<mvo> cachio: what was the pastebin again, sorry, missed it was in a very long meeting
<cachio> np
<cachio> mvo, many execs failed because of this https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20180319_122711_e1003@/log.gz
<cachio> in autopkgtests
<mvo> cachio: uhhh, I don't know where this one comes from :(
<cachio> mvo, in xenial all the execs failed because of that
<cachio> seem to be a problem with the go version
<pedronis> mvo: cachio: seems like spread doesn't build with 1.6 anymore
<pedronis> that's the issue IÂ think
<cachio> pedronis, yes
<pedronis> it's using context directly
<cachio> I am builing with 1.9
<cachio> to avoid issues on spread
<pedronis> well but that test
<pedronis> is trying to build spread
<pedronis> on xenail
<pedronis> go get -u github.com/snapcore/spread/cmd/spread
<pedronis> boom
<cachio> but, why it is doing go get instead of downloading spread?
<pedronis> downloading from where?
<pedronis> this is autopkgtests
<cachio> from aws
<pedronis> not even sure they will let us download a random binary
<cachio> or the snap
<pedronis> the snap might be an option I suppose
<pedronis> or spread need to be made to build 1.6 again
<pedronis> with 1.6
<cachio> pedronis, well that's something for niemeyer
<pedronis> though I'm not quire sure if the autopackage test for snapd can use snap
<pedronis> mvo: we cannot build spread anymore on xenial
<mup> PR snapcraft#2008 closed: Release changelog for 2.40 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2008>
<mvo> Chipaca: what was the status of "human_tsest.go:67" ? it fails here with http://paste.ubuntu.com/p/nyxKqcQFqQ/
<Chipaca> :-(
<Chipaca> mvo: yeah, mborzecki alerted me of that, and indeed it's failing here as well
<Chipaca> so there's two bugs in it
<mborzecki> mvo: it will be fixed tomorrow, or a day after
<Chipaca> one in the test, which happily pretends it'll never get run on dst, and one in the code because there's a day missing
<mborzecki> until the next dst change
<Chipaca> need to look into that
<Chipaca> mborzecki: glxinfo is still not finding the intel driver, but the games work
<Chipaca> mborzecki: http://paste.ubuntu.com/p/XcmQZmvN5z/
<Chipaca> mborzecki: and http://paste.ubuntu.com/p/cZBYzXvX73/
<mborzecki> Chipaca: hmm interesting, can you check if it behaves the same with the regular snapd?
<Chipaca> mborzecki: it did
<mborzecki> Chipaca: ah ok, then there's no regression :)
<Chipaca> bah, i can double check just in case
<mvo> mborzecki: I can't wait that long â¦
<Chipaca> mborzecki: hmm, hold on, some of these tests were run without SNAP_REEXEC=0 :-(
<Chipaca> augh
<cachio> mvo, also there errors I saw in linode exec for sru https://paste.ubuntu.com/p/KB7SyvgRn4/
<cachio> mvo, many "Permission denied"
<mvo> cachio: I think these are the ones i'm concerned about
<Chipaca> mborzecki: yeah, same
<cachio> mvo, I am gonna debug those
<zyga> mvo: did we land https://github.com/snapcore/snapd/pull/4877 for 2.32?
<mup> PR #4877: snap-confine: fallback to /lib/udev/snappy-app-dev if the core is older <Created by mvo5> <https://github.com/snapcore/snapd/pull/4877>
<zyga> mvo: I think we need too
<zyga> to too
<mborzecki> Chipaca: that's sort of great :) thank you for checking
<Chipaca> mvo: I can fix that human time bug
<Chipaca> mvo: probably :-p
<mvo> Chipaca: please
<mvo> zyga: I think so
<mvo> zyga: but not for 2.31 .(
<mvo> zyga: that might be it
<zyga> all the failures there look crazy
<zyga> I restarted it now
<mvo> zyga: I suspect its the symlink for snappy-app-dev to snap-device-helper
<zyga> mvo: symlink => copy
<zyga> actually, symlink is fine
<zyga> I think
<mvo> zyga: I think we did not do that
<mup> PR snapd#4891 closed: tests: add support for phased prepare-restore logic <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4891>
<mup> PR snapd#4914 closed: advisor: add comment why osutil.FileExists(dirs.SnapCommandsDB) is needed <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4914>
<mup> PR snapd#4915 closed: interfaces,release: probe seccomp features lazily <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4915>
<pedronis> zyga: did you merge #4891 with one review?
<mup> PR #4891: tests: add support for phased prepare-restore logic <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4891>
<zyga> mvo: I will tweak the ssh fix now
<zyga> pedronis: yes, because it's tiny and I have useful fixes on top
<zyga> pedronis: (and doesn't do anything yet)
<pedronis> did you discuss this with niemeyer?
<pedronis> I remember we had long code org discussion around this
<zyga> I wasn't aware of that, what was the discussion about specifically?
<pedronis> how stuff should be organized
<pedronis> the usual contentious topic
<zyga> was the outcome captured somewhere?
<pedronis> no
<zyga> well, I can still back that out, I just want to do something because we have real issues and no solution in sight
<pedronis> I'm just saying that merging somethign that changes deeply how we structure spread bits
<zyga> well, it's not doing that yet
<pedronis> with one review and without niemeyer input
<pedronis> is perilious
<pedronis> zyga: also is the usual issue with do nothing code, it's hard to tell how it will be used in practice
<niemeyer> zyga: Yeah, please revert this..
<zyga> sure, in a moment, just working on ssh now
<niemeyer> zyga: This sounds like a recipe for shell sausage
<zyga> I explained how it will be used in the example file but I'm fine with reverting it
<niemeyer> zyga: Yes, it's an example of sausage
<zyga> I don't know what a sausage is
<niemeyer> zyga: It's also not the right way of doing these changes.. please hear pedronis
<niemeyer> zyga: I'll send you a picture later
<zyga> our code is a mess there, I want someone to own it and fix it; I may do it in a way some people don't agree with but my motivation was to fix this
<niemeyer> zyga: We have a forum here: https://forum.snapcraft.io
<zyga> I don't mind if someone fixes our test suite to run better, really
<niemeyer> zyga: Merging these changes, which sound controversial and unclear to begin with, with no actual discussion despite the fact we spent hours talking today, on a Friday, before a release, when people are leaving on holiday... man...
<niemeyer> With one review!
<zyga> niemeyer: none of that is in the release, none of that is contoversial or unclear, did you see what that code did? IMO that is an over reaction now
<niemeyer> zyga: Please step back and breath.. it's not the way we do things..
<niemeyer> zyga: If you want to reorganize that logic, please open a forum topic and let's talk
<niemeyer> zyga: As perdronis insightfully pointed out, we are very careful to not create a mess of shell on our tests.. we simplified things out of seemingly innocent practices several times..
<pablo_> Hi: I'm trying to use wifi-ap snap on ubuntu core in Raspberry Pi 3, but status keeps changing to active=false after a couple of seconds i activate it. Any hints?
<cachio> zyga, any news on https://travis-ci.org/snapcore/snapd/builds/357331248#L8138 ?
<zyga> cachio: ha, interesting
<mvo> cachio: can you look at the denial for the permission denied failures please?
<zyga> cachio: only that I still don't understand something there
<mvo> cachio: can you pastebin those?
<cachio> 1 sec
<cachio> [Fri Mar 23 11:08:29 2018] audit: type=1400 audit(1521803309.374:626): apparmor="DENIED" operation="open" profile="snap-update-ns.test-snapd-layout" name="/proc/sys/kernel/seccomp/actions_avail" pid=16648 comm="3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<cachio> [Fri Mar 23 11:08:29 2018] audit: type=1400 audit(1521803309.402:627): apparmor="DENIED" operation="mount" info="Failed name lookup - deleted entry" error=-2 profile="snap-update-ns.test-snapd-layout" name="/etc/group" pid=16648 comm="3" flags="rw, bind"
<zyga> cachio: the 1st one is fixed in another pr
<cachio> today at least 3 builds failed on master because of this :(
<zyga> cachio: the 2nd one says something removed /etc/group while we were looking and I don't understand it
<zyga> jdstrand: ^ do you know what could cause the denial above?
<zyga> (the second one)
<mup> PR snapd#4919 opened: Revert "tests: add support for phased prepare-restore logic" <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4919>
<zyga> niemeyer: I pushed the ssh changes
<niemeyer> cachio: After you're done with the current topic, what spread images are ready to merge?
<mup> PR snapd#4919 closed: Revert "tests: add support for phased prepare-restore logic" <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4919>
<zyga> is that what you had on your mind earlier?
<zyga> https://github.com/snapcore/snapd/pull/4912/files
<mup> PR #4912: overlord/configstate: change how ssh is stopped/started (2.32) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4912>
<niemeyer> cachio: Sorry.. I mean, what snapd PRs moving images to Google
<niemeyer> zyga: Looking
<cachio> niemeyer, opensuse is almost ready, I think today will be ready to be merged
<cachio> then, just fedora is missing, we need to see how to fix those deniails from selinux
<pedronis> zyga: I'm aware that we have issues with tests,  it's a bit unclear that they are organisation problem though,   the feeling in that prepare/restore do a lot, unclear if doing a lot differently is what we need, or just try to be more careful/streamline
<zyga> yes, I know
<niemeyer> zyga: One comment and LGTM
<zyga> anyway, we can discuss this later when there's more time to see what I wanted to do
<cachio> niemeyer, well then just missing debian sid which is currently set as manual
<zyga> I have a refactor of the original code, that does what it did before but is more readable, that I wanted to use a base for refactoring
<zyga> to restore the property that setup sets stuff up from pristine and restore undoes that to pristine
<zyga> with hard checks that ensure this is happening for real
<niemeyer> pedronis: Right, exactly.. the moment we allow ourselves to just throw files at a directory, which in fact *need* to be ordered because they depend on each other, is the day we lose complete control over the sanity of something that is already not as clean as it should be
<cachio> niemeyer, are we gonna try arch or centos ?
<zyga> niemeyer: they don't depend on each other much; I'd love to discuss this but I think you are jumping to conclusions now
<niemeyer> cachio: Yeah, mborzecki had arch working already.. I closed the PR because it was still on Linode, but you two should be able to quickly get it up again on Google once you have everything else sorted
<zyga> updating ssh again, just a sec
<cachio> niemeyer, ok
<niemeyer> zyga: I'm not jumping into conclusions.. I'm concluding from experience from many years looking at similar systems evolve
<niemeyer> zyga: What's the rationale for the change in the first place?
<cachio> niemeyer, then we need to discuss the changes needed to make fedora work on google with selinux
<cachio> niemeyer, that's missing to move fedora
<mborzecki> cachio: ping me when you'd want to give arch a try, IIRC there was just a couple of tests failing there (one of those was merged usr which got fixed in master not long ago)
<niemeyer> cachio: Ok.. but gback to the original question: what can I merge?
<zyga> niemeyer: pushed ssh,
<zyga> the rationale...
<zyga> " This patch will help to modularize the prepare/restore logic and hopefully make it more testable and easy to reason about."
<cachio> niemeyer, opensuse will be ready but later doday
<zyga> also that related prepare/restore code is in one file
<niemeyer> cachio: So nothing yet?
<cachio> niemeyer, #4886
<mup> PR #4886: tests: adding opensuse-42.3 to google <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4886>
<zyga> and not far away from each other
<niemeyer> zyga: Yep.. so exactly what I said..
<cachio> yesterday we merged debian
<zyga> niemeyer: I disagree but I dont' want to argue abut it this way now
<niemeyer> zyga: Me neither.. that was part of the point
<cachio> niemeyer, I pushed a fix for opensuse, tests are waiting to be executed
<zyga> niemeyer: is https://github.com/snapcore/snapd/pull/4912/commits/1213460ccc6b96baf28f478bde752d25b8212dbb ok? I think that's it for this fx
<mup> PR #4912: overlord/configstate: change how ssh is stopped/started (2.32) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4912>
<niemeyer> zyga: Yeah, that was all, thank you
<zyga> excellent, now what's left for the system key work
<zyga> mvo: how can I help?
<niemeyer> mvo, zyga: I had a quick question/comment.. can we hang out for a few (hopefully short) minutes?
<zyga> yeah
<mvo> zyga, niemeyer sure
<niemeyer> I'm there
<pablo_> ogra_: hi, i followed your wifi-ap tutorial, but i cannot make it work... could you help me pls?
<ogra_> pablo_, on what board is that ?
<ogra_> (did you check jrounalctl for errors ?)
<ogra_> *journalctl
<pablo_> ogra_: raspberrypi 3. I'll check right now
<ogra_> any other network related snaps installed ?
<pablo_> ogra_: nmcli
<ogra_> ah, i think that will take over the wlan device ... remove NM
<ogra_> (if youo need to configure ethernet, use the config in /etc/netplan/
<ogra_> =
<ogra_> )
<pablo_> ogra_:journalctl shows lots of messages i don't understand.. i'll pastebin them.
<pablo_> ogra_: i'm using raspberry through ssh
<ogra_> well, likely that wifi-ap cn not switch the interface to ap mode
<pablo_> if i remove nmcli would i be disconnecteD?
<ogra_> well, if you did the initial setup with console-conf (to get the user set up etc) you should have a working config for eth0 already ... but you can also double check in /etc/netplan/
<pablo_> ogra_: i'll check... if eth0 is configured there i can safely remove NM? then i install wifi-ap?
<ogra_> yes, that should work
<cachio> jdstrand, I see this denial https://paste.ubuntu.com/p/8ZQVRQjZvZ/ running the test security-device-cgroups
<cachio> it is happening when execute test-snapd-tools.env
<cachio> jdstrand, any idea about what could be causing that?
<pablo_> ogra_, i removed it, then executer wifi-ap.setup_wizard. Connection keeps geting ap.active=false
<ogra_> did you reboot ?
<pablo_> no :S sorry
<ogra_> the wlan driver might be in a weird state
<pablo_> ogra_: same thing... after a couple of seconds, ap.active changes to false
<ogra_> well, then lets check the log ...
<pablo_> ogra_: how do i check the logg? sorry i'm very noob with this
<pablo_> journalctl? https://pastebin.com/hcRmcvbq
<ogra_> Mar 23 17:10:07 ema systemd-networkd[577]: wlan0: DHCPv4 address 192.168.2.111/24 via 192.168.2.1
<ogra_> thats clearly in client mode
<ogra_> do you have an entry for wlan0 in your netplan config ?
<ogra_> (in /etc/netplan/00-snapd-config.yaml )
<pablo_> ogra_, yes i have... it was created when i flashed ubuntu core..
<pablo_> ogra_, how i change it?
<ogra_> well, if you use the wlan device in clinet mode it can not run as AP
<ogra_> *client
<pablo_> I cannot even use the wifi as client right now.. how can i change client mode?
<ogra_> you can re-run console-conf with "sudo console-conf" and make sure to only configure wired ... or you can edit /etc/netplan/00-snapd-config.yaml and remove the "wifis" block (but make sure you keep ethernet configured to still get into the system)
<pablo_> thanks! i'll try with console-conf
<Chipaca> mvo: 4920 fixes the human thing
<mup> PR snapd#4920 opened: timeutil: in Human, count days with fingers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4920>
<pablo_> ogra_, in console-conf, should i erase everything in wlan0? is that enough? or how should i config it to work as ap
<ogra_> just pick "do not use"
<pablo_> ogra_, i can select "do not use" in ipv4 and ipv5 settings, but it says "associated to mywifi"
<ogra_> well, then change the wifi settings too
<ogra_> not sure how the "dont use" option in there is named
<pablo_> there isn't... i try to erase configuration.
<mvo> pedronis: 4882 is ready for a second look I think
<pablo_> ogra_, excellent! now it works! thanks a lot..
<ogra_> :)
<ogra_> enjoy
<pedronis> mvo: ok,  almost dinner here
<pedronis> though
<mvo> pedronis: yeah, same here
<pablo_> ogra_, is it possible to connecto trhough ssh if i connecto to the ap also? i mainly want it to do a simple webhost, but connecting trhough ssh could be helpful
<ogra_> sure, as long as you use the same key on the client side it doesnt matter through which network device you connect
<pablo_> thanks a lot! i'll disconnect a little time to connect to the boards ap
<mup> PR snapcraft#2023 opened: repo: catch error due to broken build packages <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2023>
<Chipaca> the BBC is wondering about Ubuntu's future: https://www.bbc.co.uk/cbbc/quizzes/beyond-bionic-mega-quiz-1
 * kalikiana wrapping up for the day
<niemeyer> kalikiana: Heya.. didn't forget our conversation.. still need to write the notes into the forum.. let me do that now
<niemeyer> kalikiana: Enjoy the weekend
<niemeyer> cachio: Haha :)
<niemeyer> Oops.. that was Chipaca
<kalikiana> niemeyer: Grand! Looking forward to reading it.
<Chipaca> I think this is a mostly-EOD from me
<Chipaca> I'm off to do housework, might pop back in when the neighbours object to the hoovering
<mup> PR snapcraft#2022 closed: Polish our landing page â¨ <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2022>
<niemeyer> Chipaca: Sweet.. I'm might have a review done for you, but you shouldn't care anyway because it's your evening isn't it :)
<Chipaca> niemeyer: sorry i can't hear you over all the hoovering
<niemeyer> :)
<mup> PR snapcraft#1999 closed: tests: document the SRU testing process <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1999>
<cachio> mborzecki, hey I'll start preparing the image
<mborzecki> cachio: ok
<cachio> mborzecki, which version should I use?
<cachio> mborzecki, I think we can use this https://github.com/GoogleCloudPlatform/compute-archlinux-image-builder
<mborzecki> cachio: take the last one, 2018.03.01, it's a rolling release anyway, so we'll have to update the image (bi-)weekly
<cachio> the ones tht are prebuilt are pretty old
<mborzecki> cachio: you can start with those scripts, if they work then we'll have an image, if not we'll try another way :)
<cachio> mborzecki, ok, I'll try those scripts and see
<cachio> mborzecki, shnould we try first with some stable image?
<cachio> or it is ok with the last one?
<mborzecki> cachio: there's no stable image per se, it's just a snapshot of current repos, it's always updating
<cachio> mborzecki, ah, ok
<mborzecki> cachio: https://www.archlinux.org/download/ 2018.03.01 is a good starting point
<cachio> let's try with this last one
<cachio> mborzecki, nice thanks
<mborzecki> cachio: let me check one more thing though, there was some discussion in the mailing liast about a cloud/vagrant image of arch
<mborzecki> cachio: does google require cloud init?
<cachio> mborzecki, I don't think so
<cachio> it requires its own cloud dependencies
<cachio> mborzecki, why?
<mborzecki> cachio: do you know what these deps are?
<cachio> mborzecki, some of these ones https://github.com/GoogleCloudPlatform/compute-image-packages
<mborzecki> cachio: ok, let me know if you run into problems, mayble i'll need to package something
<mup> PR snapd#4902 closed: cmd/snap-confine: nvidia: preserve globbed file prefix <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4902>
<pedronis> mvo: back from dinner, IÂ will look at the PR now
<mvo> pedronis: great, thank you
<zyga> Thank you pedronis
<niemeyer> Here is a short teaser
<niemeyer> root@spread-cluster:/proc# cat cpuinfo | grep processor | wc -l
<niemeyer> 96
<niemeyer> root@spread-cluster:/proc# ls -ls kcore
<niemeyer> 0 -r-------- 1 root root 141905719468032 Mar 23 18:42 kcore
<mup> PR snapcraft#2024 opened: errors: improve the UX for sending error data <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2024>
<pedronis> mvo: left a few comments,   I'm wondering what the move from yaml to json means in terms of the behavior on 2.31->2.32 transition
<cachio> niemeyer, awesome
<cachio> 141905719468032 is bigggg
<niemeyer> cachio: Yeah, and wrong.. sorry.. :)  It's close to the real one, but kcore shows virtual memory.. the actual size is 128GB, which is close, but in GB not TB
<cachio> niemeyer, so, spread should be in charge of creating vms inside this server?
<cachio> niemeyer, is it possible to create vms with arm32 architecture too?
<mvo> pedronis: yeah, thats a critical point indeed
<niemeyer> cachio: Yeah.. I'll do a tiny daemon that basically allows a conversation like "give me a server" => "okay, server 142 has ssh at ...:8782" => "thanks, destroy 142"
<mvo> pedronis: I think we need to handle this as a mismatch without
<pedronis> mvo: bug we ingore mismatches
<pedronis> s/bug/but/
<mvo> pedronis: I mean, I think we need to return that we have a mismatch and no errror here which sucks a bit
<mvo> pedronis: or we could first try json and if that fails try nyaml it
<pedronis> but the content is different, no?
<mvo> pedronis: yes, the content is different so it would be a case of "there is a mismatch, try to talk to snapd before contiue"
<cachio> niemeyer, opensuse tests passed 100% but I had to retrigger because the layout test failed for ubuntu-sore
<niemeyer> cachio: Due a known issue or hiccup?
<mvo> pedronis: maybe that is actually the answer, on error we try to reach snapd instead of silently ignoring the issue?
<cachio> niemeyer, there are 2 issues related, for one there is a PR
<cachio> niemeyer, the second one is under research
<niemeyer> cachio: Ack
<cachio> niemeyer, zyga has more info for sure
<mup> PR snapd#4921 opened: skip test if no user "daemon" in build jail <Created by rkitover> <https://github.com/snapcore/snapd/pull/4921>
<pedronis> mvo: the issue is that there are various scenarios
<pedronis> the race described in the comment is only one of them
<pedronis> there's also switchin on or off  REEXEC
<pedronis> potentially
<pedronis> and this yaml to json transition
<zyga> mvo: I sent my review
<mvo> pedronis: indeed, at least for the race described in the comment and for the yaml -> json handling this by waiting for snapd should be ok. i.e. on error try to reach snapd and then continue
<mvo> zyga: cool, thanks
<zyga> sorry for taking so long, I took a break from this
<mvo> zyga: no problem, thanks for the review. will address things in a little bit
<mvo> pedronis: I'm not sure about the switching on/off of re-exec though
<pedronis> mvo: there is nothing we can do in general there
 * zyga EOWs
<pedronis> except for testing/development it shouldn't really be done
<pedronis> mvo: anyway hopfully people don't have things trying to run while they switch
<zyga> we just have to keep the packages up to date ;-)
<niemeyer> mvo: Just reviewed 4882 as well.. very nice, and looks super close
<mup> PR snapd#4918 closed: cmd/snap: fix one issue with noWait error handling logic, add tests plus other cleanups <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4918>
<mvo> niemeyer: yay, thank you all. fixing the comments now
<cachio> mborzecki, the images that that project is creating are about 100GB
<cachio> 107 GB
<cachio> I am aborting this, creating arch linux image from scratch
<pedronis> mvo: niemeyer: the comment about connection to old snapd means we really need #4911 too ?
<mup> PR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>
<cachio> niemeyer, #4886 in green
<mup> PR #4886: tests: adding opensuse-42.3 to google <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4886>
<niemeyer> cachio: Is it stable, or are there issues to sort out still?
<cachio> niemeyer, opensuse is stable
<cachio> I ran more than 10 times and I didn't see any error
<cachio> last 3 executions in travis 0 errors for opensuse
<niemeyer> cachio: LGTM then!
 * niemeyer needs to step out.. back later
<Syntist> As Snap is container based solution, does it effect the performance?
<mvo> niemeyer, pedronis updated the PR
<mup> PR snapd#4912 closed: overlord/configstate: change how ssh is stopped/started (2.32) <Critical> <Squash-merge> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4912>
<mvo> zyga: quick question - 4912 needs a port to master, right?
<mup> PR snapd#4922 opened: overlord/configstate: change how ssh is stopped/started (2.32) (#4912) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4922>
<zyga> Re
<mup> PR snapd#4886 closed: tests: adding opensuse-42.3 to google <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4886>
 * zyga checks 4912
<zyga> mvo: yes b
<mvo> zyga: I added it
<zyga> mvo: I assumed it would not be an issue if this lands with the beta release you plan on making today
<mvo> zyga: all except 4882 are now in
<mvo> zyga: its fine
<mvo> zyga: I was just asking to not duplicate work :)
<zyga> sorry I wasn't around, I didn't hear the pings
<zyga> I was on headphones watching a movie
<mvo> zyga: toally fine
<mvo> zyga: no worries
 * mvo hugs pedronis for his review
 * zyga makes tea and reads the reviews
<mvo> zyga: just 4882
<mvo> zyga: :)
<zyga> mvo: I added one nitpick and +1
<zyga> it's not important though
<zyga> not worth waiting another round of tests if they go green
 * mvo hugs zyga 
<mvo> zyga: the fearful kernel
<zyga> haha, did I write fearful?
<mvo> zyga: no but that is what I read at first
<zyga> Yeah they sound kind of similar
<zyga> So after this branch lands then what?
<zyga> Do you need a PPA build
<mvo> zyga: yeah, when it lands-> ppa build
<zyga> oooooh
<zyga> I reproduced the /etc issue!!!!!!
<zyga> for the first time, I have debug shell
<zyga> this is like candy
<zyga> but diet
<mvo> zyga: yay
 * mvo hugs zyga 
<pedronis> mvo: do we need #4877 ?
<mup> PR #4877: snap-confine: fallback to /lib/udev/snappy-app-dev if the core is older <Created by mvo5> <https://github.com/snapcore/snapd/pull/4877>
<zyga> and I have a strace
<mvo> pedronis: thats the master version of a pr that landed in 2.32 already
<zyga> [pid  2951] mount("/tmp/.snap/etc/group", "/etc/group", 0xc82010fb6b, MS_BIND, NULL) = -1 ENOENT (No such file or directory)
<zyga> this is what fails
<pedronis> mvo: ah, ok
<mvo> pedronis: its "funny" becasue the tests for this one in master fail all the time with snap-confine.dsajlkjfslda (tmpname) leftovers
<mvo> pedronis: and its not clear what is writing these leftover files
<pedronis> mvo: IÂ have a PR that gets layout problems most of the time, interestingly follow up PRs are all green
 * zyga has a feeling this is a kernel bug
<zyga> I'll paste the strace
<zyga> https://pastebin.ubuntu.com/p/qKyPqTnT3N/
<mvo> pedronis: hm,hm,I saw the layout ones too but not on recent test runs
 * cachio afk
<zyga> super interesting facts:
<zyga> 1) /dev/sda3 on /etc/group type ext4 (rw,relatime,data=ordered)
<zyga> : /etc/group is a bind-mount
<zyga> hmmm
<pedronis> is that the result of threspassing ?
<zyga> no
<zyga> this is just /etc/ on core
<zyga> I don't get this thing: [pid  2951] lstat("/etc/group", 0xc8201097c8) = -1 ENOENT (No such file or directory)
<zyga> [pid  2951] mount("/tmp/.snap/etc/group", "/etc/group", 0xc82010fb6b, MS_BIND, NULL) = -1 ENOENT (No such file or directory)
<zyga> this last error is the error we are seeing
<zyga> we carefully create /tmp/.snap/etc/group
<zyga> and it exits, we can see that on line 1478 in the pastebin
<zyga> but when we try to bind mount /tmp/.snap/etc/group over to /etc/group, something fails and we get ENOENT
<zyga> that pastebin is really weird,
<pedronis> we are bind mounting over a bind-mount?
<zyga> I will need to study it
<zyga> no, technically we are mount --rbind /etc /tmp/.snap/etc
<zyga> mounting tmpfs over /etc
<zyga> and bind-mounting things back. one by one
<zyga> at this stage /etc/group should be an empty file
<zyga> but I think the code gets confused
<pedronis> but you said it's a bind-mount?
<zyga> because we check if it's a file or directory
<zyga> on the host
<zyga> on core it seems to be
<zyga> let me look on my dragon
<zyga> hmm
<zyga> it's not
<zyga> it's squashfs there
 * zyga wonders what's the google core-16 image then
<pedronis> we build the image
<pedronis> in the tests
<zyga> mountinfo on google ubuntu-core-16 https://www.irccloud.com/pastebin/h9nNyYdf/
<pedronis> mmh
<zyga> ahhh
<zyga> I see what's wrong now
<zyga> 117 25 8:3 /system-data/var/lib/extrausers/group//deleted /etc/group rw,relatime shared:7 - ext4 /dev/sda3 rw,data=ordered
<zyga> !
<zyga> after booting
<zyga> something wiped /writable
<zyga> and all hell broke loose
<zyga> it's a very peculiar thing in mounts
<zyga> I need to add code to detect that
<zyga> and bail early
<zyga> maybe then we'll know more
<zyga> so.......
<zyga> I would say that some of our tests killed /writable
<zyga> this broke /etc in the real system
<zyga> and then my code doesn't cope with a file being there but not really being there because it's a //deleted mount
<zyga> I need to check the kernel what the semantics is then
<zyga> but I bet a beer that this is broken prepare/restore
<pedronis> zyga: notice that we do special things to the image to get the spread user in it
<pedronis> let me find a pointer
<pedronis> zyga: we add special units that bind mount  /var/lib/extrausers/x  to  /etc/x
<zyga> I don't understand why /etc/group is the extrausers/group in this image but not in my dragon
<zyga> ooooh
<zyga> where is this?
<zyga> man,
<zyga> I didn't know that
<pedronis> one sec
<zyga> sure, thank you!
<zyga> I bet it's suite-level restore
<zyga> as I only ran this test (layout) with -repeat
<pedronis> zyga:  no,  it's done with the image
<pedronis> is not a restore thing
<pedronis> zyga: https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L388
<zyga> but it doesn't always fail
<pedronis> that is a different question
<zyga> it must be the ordering or tests so that layout runs after something restored suite in the same system
<pedronis> but this operation is done with the image once
<zyga> when I ran layout (and just layout) with repeat
<pedronis> but the mounts will happen at boot each time
<zyga> yes, but it doesn't hurt normally
<zyga> what is wrong is that something removed them
<zyga> so reset_all_snap has this at the end
<zyga> https://www.irccloud.com/pastebin/SPpOyIr1/
<zyga> -rw-r--r-- 1 root root 453M Mar 23 21:22 /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz
<zyga> this doesn't feel right
<zyga> 450MB?
<zyga> ha
<zyga> it's not tar.gz
<zyga> it's tar
<zyga> what?
<zyga> some this is clearly wrong here
<pedronis> ?
<pedronis> it's probably mostly /var/lib/snapd/snaps that make up that size
<pedronis> zyga: I see a few tests that manipulate things in /var/lib/extrausers but nothing removes things totally
<pedronis> ah but
<zyga> re
<zyga> but?
<zyga> https://github.com/snapcore/snapd/pull/4923 may help us find the culprit
<mup> PR #4923: spread.yaml: look for signs of //deleted mounts <Created by zyga> <https://github.com/snapcore/snapd/pull/4923>
<mup> PR snapd#4923 opened: spread.yaml: look for signs of //deleted mounts <Created by zyga> <https://github.com/snapcore/snapd/pull/4923>
<zyga> I need to check what the kernel semantics is
<zyga> but I think we are much closer to understanding the issue
<zyga> where //deleted comes from https://www.irccloud.com/pastebin/jtTaEdO3/
 * pedronis -> rest
<zyga> pedronis: let's catch up with this next week, have a great weekend
#snappy 2018-03-24
<mup> Bug #1758465 opened: snapd doesn't upgrade on bionic when a local installed snap mount is failing <Snappy:New> <https://launchpad.net/bugs/1758465>
<mup> PR snapd#4858 closed: strutil, cmd/snap: drop strutil.WordWrap, first pass at replacement <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4858>
<mup> Bug #1741486 changed: failed snap try leaves snap symlink around <Snappy:Expired> <https://launchpad.net/bugs/1741486>
<mup> PR snapd#4882 closed: snap: make `snap run` look at the system-key for security profiles <Critical> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4882>
<mup> PR snapd#4924 opened: snap: make `snap run` look at the system-key for security profiles (#â¦ <Created by mvo5> <https://github.com/snapcore/snapd/pull/4924>
<mup> PR core#86 opened: hooks: create compat copy of /lib/udev/snappy-app-dev <Created by mvo5> <https://github.com/snapcore/core/pull/86>
<mup> PR core#86 closed: hooks: create compat copy of /lib/udev/snappy-app-dev <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/86>
<pedronis> mvo: zyga:Â I'm a bit confused, it seems  account-control expects files to be already present in /var/lib/extrausers  but in our tests they are just because of a hack
<mup> PR snapd#4924 closed: snap: make `snap run` look at the system-key for security profiles (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4924>
<pedronis> if I tweak the hack I get:    useradd: cannot open /var/lib/extrausers/passwd
<pedronis> it's not a confinement issue btw,     useradd --extrausers alice  as root also gives the same
<mup> PR snapd#4925 opened: tests: fix snap-run tests when snapd is not running <Created by mvo5> <https://github.com/snapcore/snapd/pull/4925>
<mup> PR snapd#4926 opened: tests: fix snap-run tests when snapd is not running <Created by mvo5> <https://github.com/snapcore/snapd/pull/4926>
<thresh> hello.  how do I debug why stage-packages: pulls in packages that I don't see installed when I do apt-get install for that list?
<thresh> I see some packages that should not be there
<thresh> found --debug, let me see if that helps...
<mborzecki> zyga: hi, you around?
<mborzecki> zyga: there's a hackathon at GOG office in May, want to show them how make snaps? https://www.gog.com/hackathon
<mup> PR snapd#4925 closed: tests: fix snap-run tests when snapd is not running (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4925>
<zyga> Hi mborzecki
<zyga> Ooohhh
<zyga> Thanks
<zyga> Wanna come?
<mborzecki> zyga: i'm interested for sure, don't know yet if i will be able to go, probably will know more mid-april, registration closes on may 7, so we still have some time
<bulld> hi
<zyga> We could snap gog games
<bulld> am building my app with qt5.7.1 and later am going to snap pack it, how can i use my local qt5.7.1 toolkit to build in snapcraft file
<zyga> Iâll register us back home
<zyga> bulld: hey, Iâm not sure but itâs possible for sure.
<zyga> Did you check on the forum? Maybe someone did this already
<bulld> i build qt5.7.1's webengine myself with codecs support so i need it to build/ship the binary am using in snap package
<thresh> so I've ran two snapcraft --debug prime runs, and it seems like the behaviour is inconsistent: https://thre.sh/stuff/snapcraft-different-packages-staged.diff.txt
<bulld> okay @zyga i will check
<thresh> any idea how to make sure snapcraft works the same between different runs?
 * zyga is a snapd hacker and builds snaps less frequently than others
<thresh> e.g. you can see it fetches libvlc5 in one case and not in the other
<zyga> And when I do I build weird snaps that use new features
<bulld> @zyga :)
<zyga> Speaking of which, I have some cool snap demo to publish
<zyga> But first family time with my daughter :-)
<bulld> hmm :)
<bulld> my snap installation is broken somehow cannot install any snap package local or from store. getting some apparmor errors
<bulld> am using ubuntu 16.04
<mup> PR snapcraft#2024 closed: errors: improve the UX for sending error data <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2024>
<bulld> i already posted details of errors am getting in snapcraft forums https://forum.snapcraft.io/t/unable-to-install-snap-from-store-or-loallay/4629
<zyga> bulld: can you give me more details
<zyga> Snap version
<zyga> And the errors you are seeing
<bulld> i provided everything in the forum link in my previous msg
<bulld> https://forum.snapcraft.io/t/unable-to-install-snap-from-store-or-loallay/4629
<zyga> Ok
<zyga> Thanks
<zyga> Iâll check that later today
<bulld> okay ty
<mup> PR snapd#4927 opened: release 2.32 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4927>
<pedronis> zyga: I think  IÂ know how to disentangle the etc mess,  was confused for a bit by writable-paths (surprise)
<zyga> Ha
<zyga> I sent a PR that looks for the damage
<zyga> There are some tests that need fixes
<pedronis> zyga: well, it's no the tests
<pedronis> is the prepare stuff that does very strange stuff
<pedronis> (in hindsight)
<pedronis> zyga: we basically run the tests with /etc/passwd  being a bind mount of /var/lib/extrausers/passwd
<pedronis> that makes little sense conceptually
<zyga> Why do we do thatâs
<zyga> Note that would not break the mimic code
<pedronis> zyga: well we do need to bind mount something on /etc/passwd
<zyga> It is this with combination of some unfortunate rm -rf
<pedronis> afair
<pedronis> sorry
<pedronis> afaiu
<pedronis> but making it /var/lib/extrausers/passwd
<pedronis> adds to the confusion
<pedronis> because then some other code will modify it
<pedronis> zyga: it doesn't seem to be a rm -rf , more some cases of sed -i
<pedronis> but IÂ bit unclear exactly how (I don't get that effect playing locally with sed -i)
<zyga> Interesting
<zyga> I think sed would not cause that
<zyga> Kernel code indicates that dentry must be removed
<zyga> So more like the parent directory
<pedronis> zyga: anyway  having etc/passwd === extrausers/passwd doesn't make sense
<pedronis> conceptually
<zyga> I agree
<pedronis> zyga: I think we need to bind mount /etc/passwd   because we need to put there the spread root user
<pedronis> afaiu
<zyga> Cannot we use extra users for that?
<pedronis> zyga: no, that's the problem
<pedronis> root cannot be in extrausers
<pedronis> because the one in /etc/passwed wins
<zyga> Ah, I see
<pedronis> so we need a bind mount
<pedronis> but no reason to do this bind mount
<pedronis> (is super confusing in various ways)
<pedronis> also it means that when we test extrausers stuff
<pedronis> (which is important)
<zyga> Well
<pedronis> we really test nonsense
<zyga> At the very least I know how to improve mimic code
<zyga> But our test environment is in a very broken state
<pedronis> zyga: anywy I can propose a change that doesn't have any /etc  //deleted mounts at least
<pedronis> anymore
<pedronis> and also untangle a bit that confusion
<pedronis> I don't know if it's enough to not confused layout
<pedronis> but is a step
<zyga> Because all those //deleted mount points are broken
<pedronis> yea
<zyga> I will check kernel code
<pedronis> no more of those
<pedronis> with my change
<pedronis> IÂ mean for etc
<zyga> But Iâm worried that such deleted mount points cannot be the target of a mount call
<pedronis> we have some for try snaps afaict
<zyga> Because they no longer exist conceptually
<pedronis> zyga: ?
<pedronis> zyga: so?
<zyga> Itâs a detached inode
<pedronis> zyga: as I said I fixed the //deleted bit
<zyga> So mount with that as a target will always fail
<zyga> So what can we
<zyga> Do?
<pedronis> is that a problem?
<zyga> Yes
<zyga> The mimic is broker
<zyga> Broker
<pedronis> IÂ mean do you think it will happen in practice?
<zyga> Broken
<zyga> No
<zyga> But we must handle that in tests
<pedronis> ?
<zyga> In reality it will not happen
<pedronis> if there are no  //deleted
<pedronis> anymore
<pedronis> there's nothing to handle
<pedronis> IÂ made changes such that there are no more //deleted
<pedronis> I think I said that a couple fo times
<zyga> But I donât want to fail tests 30% of the time because of that
<zyga> Oh
<pedronis> ?
<zyga> Cool
<zyga> Can you merge my patch from a later pr that detects dangling //deleted please?
<pedronis> zyga: I used your patch
<pedronis> as a baseline
<pedronis> otherwise how would IÂ know
<pedronis> that there no //deleted
<zyga> Ah perfect
<pedronis> to be clear I'm talking about /etc here
<pedronis> there are some tests using try
<pedronis> that live //deleted around
<pedronis> not sure it's an issue or not
<zyga> I see
<zyga> I can review that next week and try to eliminate them
 * zyga is very much afk
<mborzecki> updated snapd to 2.32 in AUR
<mup> PR snapd#4922 closed: overlord/configstate: change how ssh is stopped/started (#4912) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4922>
<pedronis> ok, my change seems to do what I wanted (there was a further subtle detail, but IÂ think I have a fix)
<mup> PR snapd#4928 opened: tests: disentangle etc vs extrausers <Created by pedronis> <https://github.com/snapcore/snapd/pull/4928>
<pedronis> zyga: ^
<zyga> Thank you. I will return home soon and review it
<zyga> Did you find this by reading the strace from last night?
<pedronis> zyga: no, IÂ just assumed  that /etc/group  being //deleted would be the source of the problem?
<pedronis> zyga: anyway I tried to run those account tets and layout together and layout passes
<pedronis> with this change
<zyga> Thank you so much!
<zyga> My question about the strace was motivated by wanting to see if there was anything else fishy there
<zyga> I will review it in the evening
<pedronis> zyga: anyway as I explain in the PR, this is a saner change because what we did would make our /var/lib//extrausers not very realistic
<pedronis> because /etc/passwd would also contain the stuff
<pedronis> etc
<pedronis> zyga: rechecked, on master if one runs ubuntu-core-create-user just before layout  the latter fails with the /etc issue
<zyga> Great find! But I also managed to fail it by running just layout with -repeat 2
<pedronis> that is stranger
<zyga> But that was against core 16
<zyga> So I thought the suite restore is buggy
<pedronis> this is a core only problem btw
<pedronis> we don't do this strange things on classic
<zyga> It would fail on 2nd try
<zyga> I hope so. I think we saw layout failures in classic too
<zyga> But perhaps older codebase
<pedronis> well it might be that layout breaks layout
<pedronis> in some cases
<pedronis> are the  threspassing fixes merged?
<zyga> No but they cannot affect this
<pedronis> also linode and google are different because reuse vs not
<zyga> Trespassing bug means we leave empty regular file, directory or symlink
<pedronis> that also changed
<zyga> Ah, good point
<pedronis> grumble
<mup> PR snapd#4926 closed: tests: fix snap-run tests when snapd is not running <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4926>
<pedronis> zyga: yes, that was my grumble, classic test is failing
<zyga> pedronis: I reviewed https://github.com/snapcore/snapd/pull/4928
<mup> PR #4928: tests: disentangle etc vs extrausers in core tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4928>
<zyga> ha
<pedronis> I think IÂ know what to do
<pedronis> just annoying
<pedronis> I still need to create extrausers
<zyga> what is your plan?
<pedronis> just not bind it somewhere
<zyga> aha
<pedronis> zyga: basically we need the "test" user there
<pedronis> I'm testing the fix right now locally
<zyga> if we need it for just one test, perhaps we could do it there
<zyga> we can bind mount over /etc/passwd
<zyga> and restore that correctly
<pedronis> it doesn't need to be in /etc/passwd
<pedronis> it really needs to be in extrausers
<pedronis> because classic knows that's were core puts users
<pedronis> so it's the thing it copies inside
<zyga> ah, I see
<pedronis> as I said, I think I have a fix that should keep the rest of the sanity
<pedronis> trying it now
<zyga> cool, thank you
<zyga> I will play with the kernel, I have an idea on how to improve the error reporting for my sanity, at least
<zyga> just add some logging in places where kernel returns error on mount
<pedronis> zyga: fwiw   is not sed -i that was ripping apart /var/extrausers/foo,  it's useradd itself
<pedronis> I think
<zyga> I wrote a similar patch for pivot_root which has half a dozen reasons for EINVAL
<pedronis> it does atomic writes with renames
<pedronis> of stuff there
<zyga> ah, that's sensible, it would get a new inode and the old one would become //deleted
<zyga> kernel is "fun"
<pedronis> zyga: I pushed the fix
<zyga> lookng
<zyga> let
<zyga> let's see if it passes now
<pedronis> zyga: passed, I'll need a 2nd review on monday
<zyga> sounds very good
<cachio> zyga, is it gonna be a new 2.32?
<cachio> I am running beta validation for the current one
<zyga> cachio: no, I don't think so
<cachio> zyga, ah, ok, good news
<pedronis> it's  a test only fix, we probably want it in 2.32.x  if likely we need to do that, but should affect current 2.32 testing
<pedronis> *but shouldn't
#snappy 2018-03-25
<mup> Bug #1693037 changed: Canât start a snap app <zesty> <Snappy:Expired> <https://launchpad.net/bugs/1693037>
<mup> Bug #1693664 changed: Snapd won't install anbox, Character error <auto> <connect> <info> <snap> <Snappy:Expired> <https://launchpad.net/bugs/1693664>
#snappy 2019-03-18
<zyga> Good morning
<mborzecki> morning
<mup> PR snapd#6611 closed: interfaces/builtin: add add exec "/" to docker-support (for 2.38) <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6611>
<zyga> Hey mborzecki
<mborzecki> zyga:  hey
<zyga> https://github.com/systemd/systemd/issues/12018
<mvo> hey zyga and mborzecki
<zyga> Hey mvo :-)
<mborzecki> zyga: interesting bug report
<zyga> Systemd ran into the same parsing issue
<zyga> In that bug report it would really clobber a tmp-foo.mount unit
<zyga> back in the office
 * zyga focuses on https://github.com/snapcore/snapd/pull/6575
<mup> PR #6575: cmd/snap-confine: pass sc_invocation instead of numerous args around <Created by zyga> <https://github.com/snapcore/snapd/pull/6575>
<mborzecki> mvo: when you have a break from backporting systemd patches, could you take a look at https://github.com/snapcore/snapd/pull/6609 ?
<mup> PR #6609: snap/gadget: introduce volume update info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6609>
<zyga> mborzecki: did you see my question about case sensitivity?
<mborzecki> zyga: yeah, we could probably warn when there's a volume which is case insensitive and more than one 'version' of file is listed in the path
<zyga> mborzecki: I think we should not warn, we should use case-insensitive matching
<zyga> do the right thing
<zyga> mborzecki: and it should be invalid to specifcy case-clashing entries
<pstolowski> morning
<mvo> hey pstolowski - good morning
<mborzecki> pstolowski: hey
<Chipaca> kjackal, zyga: I stopped using OVH over this "we'll call it ubuntu but use a random kernel we found down a ginnel" nonsense
<mborzecki> damn, that error with removing of snap data directory is annoying
<Chipaca> mborzecki: and i can't reproduce it on its own :-(
<mborzecki> Chipaca: since it's so well randomly reproducible, i'm actually thinging about adding a list of files in snap data dir in the error message
<Chipaca> mborzecki: sgtm
<Chipaca> mborzecki: find -ls in a debug section?
<mborzecki> hm or that
<mborzecki> let me open a PR
<mup> PR snapd#6615 opened: spread: some debug info to catch /var/snap/.. not being empty <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6615>
<mborzecki> Chipaca: it's not really reproducing locally either, 40+ loop iterations of install/remove of 2 snaps and still nothing
<Chipaca> mborzecki: what turns on SPREAD_DEBUG_EACH?
<mborzecki> -debug-each ?
<Chipaca> ah, found it
<Chipaca>     SPREAD_DEBUG_EACH: "$(HOST: echo ${SPREAD_DEBUG_EACH:-1})"
<Chipaca> you can't turn it on, but you can turn it off :-)
<mborzecki> heh
<zyga> Chipaca: you can turn it off
<zyga> I use it all the time
<zyga> SPREAD_DEBUG_EACH=0
<zyga> hello sir :)
<Chipaca> zyga: that's what i said innit?
<zyga> ah
<zyga> I read that backwards, sorry
<zyga> it's good I got my coffe :)
<zyga> Chipaca: can you please look at the commit message in https://github.com/snapcore/snapd/pull/6614
<mup> PR #6614: cmd/snap-confine: use fixed private tmp directory <Created by zyga> <https://github.com/snapcore/snapd/pull/6614>
<zyga> Chipaca: if this lands, I'd like to start removing per-snap /tmp data
<zyga> Chipaca: when we remove a snap
<zyga> Chipaca: just FYI
<Chipaca> zyga: i reviewed the whole thing, friday
<Chipaca> spent some time remembering the semantics of mkdir and mkdirat to make sure it was ok wrt symlink attack
<Chipaca> zyga: but i then got distracted and didn't +1 or anything
<Chipaca> zyga: but
<Chipaca> zyga: what happens if somebody mkdir's the expected directory, and then mkdir's tmp inside it to not be 01777?
<zyga> Chipaca: we fix it on startup
<Chipaca> ah, there
 * Chipaca found it
<zyga> Chipaca: we don't fix it if you break it after taht
<zyga> *that
<zyga> but that was  true before
<zyga> and it wasn't hidden, just obfuscated
<zyga> if you are root you can break it
<zyga> but this is also true now
<Chipaca> zyga: right, root can do w/e
<Chipaca> zyga: but i didn't want a random user to mkdir and then have fun deleting other user's stuff
<Chipaca> but that's fine
<zyga> yeah, that's prevented now
<zyga> I have one more aspect of that to fix but this is an unrelated bug related to /tmp
<mborzecki> Chipaca: https://api.travis-ci.org/v3/job/507758121/log.txt
<Chipaca> wait what
 * zyga looks at the same one
<Chipaca> that is very much unexpected
<Chipaca> I expected a random directory
<Chipaca> not the current symlink!
<Chipaca> wtf
<mborzecki> yup
<Chipaca> - Remove security profile for snap "test-snapd-tools_instance" (6) (cannot find installed snap "test-snapd-tools_instance" at revision 6: missing file /snap/test-snapd-tools_instance/6/meta/snap.yaml)
<Chipaca> mborzecki: ^ some fuckery going on
<zyga> Chipaca: I love our test suite
<zyga> perfect job security
<Chipaca> waaaaait
<Chipaca> mborzecki: quick check with you
<Chipaca> - Remove data for snap "test-snapd-tools_instance" (5) (failed to remove snap "test-snapd-tools" base directory: remove /var/snap/test-snapd-tools: directory not empty)
<Chipaca> mborzecki: why is test-snapd-tools_instance removal removing /var/snap/test-snapd-tools ?
<zyga> Chipaca: ooh
<zyga> feels like incorrect use of snap name vs instance name?
<Chipaca> zyga: or incorrect determination of hasOtherInstances
<mborzecki> Chipaca: seen it happen without any extra _instance entries too
<Chipaca> mborzecki: what does hasOtherInstances() return if you have two instances installed, and remove them both in the same change?
 * Chipaca ponders
 * zyga is in a ethernet cable bonanza
<zyga> I can finally fix my messy office wiring
<Chipaca> zyga: is this the part of bonanza where everything is on fire and you ride away into the sunset?
<zyga> Chipaca: that is after I plug them :)
<ogra> given the time it is probably rather the part where the cook comes out and calls for lunch
<mborzecki> Chipaca: so you're sayng a scenario where both snaps are removed, and at the time hasOtherInstances is run, it returns true for both, but then the directory is left behind?
 * zyga small break to install new network cables
<mborzecki> cables? :P
<zyga> mborzecki: wifi runs on cables :)"
<zyga> you don't want to see how it looks like now
<zyga> 1/3 there,
<zyga> now the longest one
<zyga> mborzecki: I'm mainly using ethernet because NAS over wifi is not as fast
<zyga> mborzecki: my NAS would be noticeably faster if I got the 10Gbit network update now
<zyga> mborzecki: wifi here is also very crowded and noisy
<zyga> pstolowski: https://www.apple.com/us/shop/ <- roll your 8ball what the updates are
<pstolowski> zyga: interesting
<zyga> pstolowski: that's apple talk for "new products today"
<pstolowski> uhm
<mvo> pedronis: any concerns if I chery-pick 6598 into 2.38? I think we talked about it and it was fine but I may misremember (the "set a header when auto-refreshing" change from john
<pedronis> mvo: it's fine
<Chipaca> mborzecki: or conversely, where it returns false to both
<Son_Goku> mborzecki, can we get all the selinux stuff to land for 2.38?
<mborzecki> Son_Goku: 2.39
<Son_Goku> arrrgh
<Son_Goku> you're killing me here :P
<mborzecki> Son_Goku: sorry :)
<Son_Goku> I was hoping to get this in with F30 devel so that the majority of people would be doing reboot upgrades no matter what
<zyga> mvo: possible spam edit on https://bugs.launchpad.net/arduino-debug/+bug/1791691
<mup> Bug #1791691: PATH broken in systemd units <Arduino Debugging Tool:Fix Released> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Bionic):In Progress> <snapd (Ubuntu Cosmic):Fix Released> <https://launchpad.net/bugs/1791691>
 * Chipaca disappears in a cloud of lunch
<MattJ> Yum
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502, snapd#6541, snapd#6559,
<mup> snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6594, snapd#6595, snapd#6597, snapd#6599, snapd#6602, snapd#6603, snapd#6604, snapd#6605, snapd#6606, snapd#6607, snapd#6608, snapd#6609, snapd#6610, snapd#6612, snapd#6613, snapd#6614, snapd#6615
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502, snapd#6541, snapd#6559,
<mup> snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6594, snapd#6595, snapd#6597, snapd#6599, snapd#6602, snapd#6603, snapd#6604, snapd#6605, snapd#6606, snapd#6607, snapd#6608, snapd#6609, snapd#6610, snapd#6612, snapd#6613, snapd#6614, snapd#6615
 * zyga breaks
<pstolowski> wow @mup
<mborzecki> finishing up with an update to the yocto layer
<mborzecki> hm things were a bit behind
<zyga> mborzecki: "a bit"
<zyga> mborzecki: any chance you can use snapd.mK/
<mborzecki> zyga: maybe, although the main problem was handling of go in poky, which is fine to 'just' go packages, but little funky when there's go and something else
<zyga> mmm
<zyga> re
<mborzecki> Chipaca: restarted the travis job in #6615, want to get another sample
<mup> PR #6615: spread: some debug info to catch /var/snap/.. not being empty <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6615>
<mborzecki> off to pick up the kids
<zyga> brb, daughter is hungry
<mvo> mborzecki, Chipaca we might be a bit late, meeting overrunning
<zyga> jdstrand: some low hanging fruit: https://github.com/snapcore/snapd/pull/6607
<mup> PR #6607: cmd: typedef mountinfo structures <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6607>
<jdstrand> zyga: yes it is on my list
<zyga> thanks!
<zyga> it's boring, there are some more interesting ones in the pipe :)
<mup> PR snapd#6616 opened: [RFC] boot: add flag file "force-kernel-extraction" <Created by mvo5> <https://github.com/snapcore/snapd/pull/6616>
<pedronis> pstolowski: I did a pass over the timings PR
<pstolowski> pedronis: k, thanks
<pstolowski> mvo, pedronis, Chipaca I think my fix for error handling of non-nummeric snapshot IDs in snap snapshots commands broke 'snap saved' (2.37.4 is ok) :(
<mvo> pstolowski: ok, so we need this for 2.38?
<pstolowski> mvo: when was 2.38 branched away?
<pstolowski> my change landed the week after the sprint. let me check
<mvo> pstolowski: ok
<mvo> pstolowski: about 2 weeks ago it was branched
<pstolowski> mvo: ok, confirmed, 2.38 requires a fix
<mvo> pstolowski: ta
<mvo> pstolowski: I will wait for 2.38-final then
<mvo> pstolowski: until that is available
<Saviq> cachio: hey, could you redo the rawhide image? it's cut to version 30 now so GPG is failing https://travis-ci.org/MirServer/mir/jobs/507765669#L1529
<cachio> Saviq, hi, sure
<Saviq> thanks :)
<cachio> I'll ping you when it is ready
<Saviq> alan_g: FYI â
<cachio> Saviq, np
<mup> PR snapd#6617 opened: cmd/snap: fix regression of snap saved command <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6617>
<pstolowski> mvo: ^ this fix for master
<cachio> niemeyer, hey, https://github.com/snapcore/spread/pull/75 readu
<mup> PR spread#75: Make spread tests for spread project run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75>
<cachio> ready
<mup> PR snapcraft#2504 opened: cli: validate plugin schema before provider <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2504>
<mup> PR snapcraft#2503 closed: cli: disable raven if not running from package <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2503>
<zyga> re
<cachio> Saviq, the image is ready
<cachio>  Saviq please tell me if it works for you
 * cachio afk
<mup> PR snapcraft#2505 opened: Test store <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2505>
#snappy 2019-03-19
<mup> PR snapd#6618 opened: tests: validates snapd from ppa <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6618>
<zyga> Good morning
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> mborzecki: hey, good morning
<zyga> hey mborzecki, mvo
<mborzecki> zyga: hey
<zyga> kids off to school, time to work
<zyga> I took sime time to clean my office yesterday
<zyga> I must say, it feels great to work in a tidy place
<zyga> I will try to preserve this condition better than last time
<zyga> I have a few small PRs that could land quickly, if anyone wants to see
<mborzecki> zyga: which ones?
<zyga> mborzecki: typedef struct mountinfo is trivial
<zyga> mborzecki: UMOUNT_NOFOLLOW is super trivial
<zyga> those two can just land
<zyga> mborzecki: there are some short but not trivial branches like fixed private /tmp
<zyga> or fixes to mountinfo parsing
<mvo> hey zyga
<zyga> good morning :)
<zyga> how is your daughter today?
<mvo> zyga: all well
<mvo> zyga: and yours :) ?
<zyga> she was very hungry today, eating a few times in a row
<zyga> the older one went to school recently :)
<zyga> (need to remember about both)
<pstolowski> mornings!
<mborzecki> pstolowski: hey
<mvo> good morning pstolowski
<mborzecki> zyga: do you need a review from pedronis on https://github.com/snapcore/snapd/pull/6608  and the mountinfo one?
<mup> PR #6608: cmd/snap-confine: umount scratch dir using UMOUNT_NOFOLLOW <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6608>
<zyga> I will wait for a pass, yes
<dot-tobias> good morning
<zyga> hey dot-tobias
<dot-tobias> zyga: Morning ð BTW, thank you again for the layouts feature, made both of my snaps possible in the first place! Huge improvement for snapping otherwise âunconfinableâ software IMHO
<pedronis> 6608 can land
<Chipaca> man i wish each log line said what machine it was from :-(
<Chipaca> morning all
<mborzecki> Chipaca: wouldn't be suprised everyone has a patch for spread to do just that :P i had one
<zyga> pedronis: hello
<zyga> pedronis: I updated https://github.com/snapcore/snapd/pull/6502
<mup> PR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502>
<zyga> dot-tobias: I'm very glad to hear that :-)
<zyga> thank you :)
<zyga> Chipaca: good morning
<zyga> pedronis: thank you, merged now
<mup> PR snapd#6608 closed: cmd/snap-confine: umount scratch dir using UMOUNT_NOFOLLOW <Reviewed> <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6608>
<mvo> zyga: hey, when you have a spare slot, could you please re-review 6491 - aiui it "just" needs a re-review at this point
<mvo> pstolowski: (or is anything missing in 6491)
<pstolowski> mvo: no, it needs 2nd review
<pstolowski> Chipaca: hey, can you cast your eye on https://github.com/snapcore/snapd/pull/6617 ?
<mup> PR #6617: cmd/snap: fix regression of snap saved command <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6617>
<zyga> mvo: sure, doing so now
<Chipaca> ah, yes
<mvo> zyga: thank you!
<Chipaca> kjackal: ping
<kjackal> hey Chipaca
<Chipaca> kjackal: hey
<Chipaca> kjackal: which 16.04 image from ovh doesn't support squashfs?
<kjackal> Let me see what that person said, give me a sec
<kjackal> Chipaca: unfortunately he did not came back to answer your questions: https://github.com/ubuntu/microk8s/issues/362
<kjackal> I did point him to the discourse topic
<Chipaca> kjackal: thanks
<Chipaca> kjackal: I've raised the issue internally as well
<Chipaca> if it doesn't support squashfs it's running some random kernel, meaning it's not Ubuntu
<kjackal> does the ovh get certified ubuntu images from us?
<Chipaca> they've been in trouble with canonical before for selling something as Ubuntu and it not being Ubuntu
<Chipaca> but I don't know how that got resolved
<Chipaca> if it did, even
<pstolowski> grrr the testing situation is really annoying
<zyga> can we all stop the line and fix tests
<zyga> including perhaps spending a moment to ensure that the situation is really better, not just not broken again
<Chipaca> zyga: what's broken now?
<zyga> Chipaca: is the situation with /var/snap fixed now?
<Chipaca> zyga: no
<zyga> so that's enough ;)
<Chipaca> i'm still working on it
<zyga> tests cannot be red for many days
<Chipaca> i'm still working on it
<zyga> I understand, I'm saying we should all jump at fixing the fundamental issue
<Chipaca> which is the fundamental issue?
<zyga> that is the one-to-all influence of every test
<zyga> any test can break any other test
<zyga> we do insufficinent work in making sure the environment is pristine
<zyga> and the definition of pristine is not strict
<zyga> it's all reactionary
<Chipaca> quick fix: set workers to the number of tests
<zyga> I'm partially not joking, it's just impractical to develop snapd for several years and constantly be in a situation where nearly every PR needs to be restarted
<zyga> github is down, fine, happens once a year
<zyga> tests don't clean up: *not* fine
<zyga> we should really fix this
<Chipaca> i'm not disagreeing, but
<Chipaca> this issue is something else
<Chipaca> 'snap changes' indicates that snapd _did_ remove the snap
<Chipaca> so there's an actual bug somewhere
<zyga> that's okay, but the first test that experiences this should stop and fail,
<zyga> and not influence something entirely different later
<zyga> once you fix the problem with current we will still have the very same unreliability problem with tests
<Chipaca> what do you mean by "experiences"
<zyga> a test that, by the end of the execution, due to the bug or otherwise leaves the test environment (system) in a state different from the state it was in at the beginning of the test
<zyga> my impression is that right now our tests feel like DOS software
<zyga> one program runs and corrupts something
<zyga> them sometime later another program dies because of that corruption
<zyga> it's very time-consuming to debug
<zyga> we should spend the time in a smarter way
<mborzecki> can i get some eyes on https://github.com/snapcore/snapd/pull/6609 ?
<mup> PR #6609: snap/gadget: introduce volume update info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6609>
<Chipaca> so, we have the snapd-state code
<zyga> mborzecki: enqueued
<mborzecki> zyga: thanks
<Chipaca> this problem would go away, i expect, if /var/snap were also part of the things that got nuked every iteration
<Chipaca> OTOH, maybe the restore code should fail if there's things that shouldn't be there
<Chipaca> so then the tests _need_ to clean up after themselves
<zyga> perhaps the assumption that there's a magic cleanup system was flawed
<Chipaca> so then we are testing that things are clean after cleaning up
<mborzecki> Chipaca: wonder if that may be the package post/pre rm cleanup code
<zyga> would tests be really that much longer if install_local enqueued a restore action that removes the test
<zyga> and the restore code would just check that nothing is left behind (and fail if there was)
<mborzecki> though it's only happening on ubuntu-core, hmm
<Chipaca> mborzecki: what's only happening on ubuntu-core? these failures you mean?
<zyga> mborzecki: interesting
<zyga> on core we get extra snaps for testing
<mborzecki> Chipaca: yeah, i recall seeing only ubuntu-core there
<zyga> anyway, I'm grumpy because I see us happily igoring the ephant in the room
<Chipaca> hmmm!
<zyga> our testing infrastructure needs love
<Chipaca> mborzecki: i hadn't noticed :-/
<zyga> it's not healthy
<Chipaca> if it's that, maybe it's silly
<Chipaca> because is_snapd_state_saved behaves differently on core
<mborzecki> heh
<Chipaca> save_snapd_state behaves differently on core too
<mborzecki> Chipaca: yup, looking at 3 logs atm, all ubuntu-core
<Chipaca> i thought i'd seen a non-core one, but can't find it now
<Chipaca> so it might've been unrelated
<Chipaca> the whole 'snap state file' thing does not exist on core
<mborzecki> and we dont uninstall the package on ubuntu-core, because how we'd do it?
<Chipaca> afaict
<Chipaca> mborzecki: we don't do that either, in the save state thing -- are you saying we do that each loop?
<mborzecki> Chipaca: my bad, we don't
<Chipaca> mborzecki: might just be coincidence tho
<Chipaca> hm
<Chipaca> mborzecki: in save_snapd_state, when it's core, we copy /var/lib/snapd
<Chipaca> ah and then restore_snapd_lib
<Chipaca> ok fair
<Chipaca> eep! finally got a shell in a failed one!
 * Chipaca runs
<mborzecki> hahah
<mborzecki> Chipaca: hm, but we dont restore snapd state for each test
<Chipaca> mborzecki: in core we do
<Chipaca> mborzecki: reset_all_snap does that
<Chipaca> and this might be the problem?
<Chipaca> or at least i think we do
<Chipaca> i mean, that's the code that fails
<Chipaca> reset.sh calls reset_all_snap on load
<Chipaca> so everything that sources it will do that
<Chipaca> (on core)
<Chipaca> (on classic, reset_classic)
<Chipaca> so prepare_suite_each and restore_suite both do that
<pedronis> we should restore the state for each test,  lots of things assume that
<mborzecki> Chipaca: ok, then reset_classic does rm -rvf /var/snap, reset_all_snap doesnot
<mborzecki> it calls snap remove which sould do the trick
<Chipaca> pedronis: the -each versions do run for each test
<Chipaca> mborzecki: indeed
<mborzecki> maybe we should have a check there to verify that /var/snap does not have any extra data?
<Chipaca> mborzecki: we kinda do :-)
 * zyga wonders if we will ever return to the spread measurements idea that he proposed about a year ago
<Chipaca> i mean, that's why it's dying
<zyga> well, more than a year now
<Chipaca> zyga: ?
<zyga> Chipaca: I proposed a spread extension where we can add a "measure: " section; anything printed there is stored compared with before/after for each level of nesting
<zyga> Chipaca: so if you print the set of installed packages
<zyga> you will notice leaked packages
<zyga> if you print the state of systemd services
<zyga> you will see systemd services changing state across tests
<zyga> we can easily measure anything we want
<zyga> I iterated on this idea
<zyga> and while doing so found a bunch of bugs in our test setup then
<Chipaca> zyga: and what happened?
<zyga> I think not enough eyes looking or agreeing with the gravity of the problem
<zyga> Chipaca: I think that we need something that would alert us of a test doing unexpected system change
<zyga> not just trying to fix them
<zyga> fixing is costly (we untar / remove all the time)
<zyga> checking is presumably cheaper
<zyga> so this might also speed up things in the end
<pedronis> it was also mixed with a change to spread which come with friction
<zyga> pedronis: we could replicate that without spread but arguably the issue is that spread is too open and doesn't give us the ability to tame that
<zyga> pedronis: perhaps that's the way forward?
<pedronis> anyway "flaky tests" and "test invariant" are still part of my open problems list
<zyga> I would argue we should solve that with priorty because it hinders any other development done by the team
<pedronis> let's look at this in the standup (cc mvo)
<zyga> gladly!
<zyga> brb
<mup> PR snapd#6619 opened: partition,bootloader: rename 'partition' package to 'bootloader' <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6619>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6491 reviewed
<mup> PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>
<zyga> mborzecki: looking at https://github.com/snapcore/snapd/pull/6609
<mup> PR #6609: snap/gadget: introduce volume update info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6609>
<pstolowski> zyga: thanks!
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6609 done
<mup> PR #6609: snap/gadget: introduce volume update info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6609>
<zyga> pstolowski: I think that some of my questions got answers by the time I read to the bottom but I chose not to remove them.
<zyga> pstolowski: it's safer and easier to ask and just get a quick answer
<pstolowski> zyga: sure, makes sense
 * zyga goes for a break
<mborzecki> Chipaca: have you found anything interesting in the debug shell?
<Chipaca> mborzecki: nothing as yet, but i'm retrying with more debug
<Chipaca> hm
<Chipaca> mvo: 'snap remodel' doesn't print a last \n
<Chipaca> HAH! found the bugger
 * Chipaca notes that is "the thing that causes the bug", not any other meaning of the word
<Chipaca> mborzecki: the 'snap remodel' spread test leaves things in a confused state
<mborzecki> 'confused'
<pedronis> well, it's a remodel
<pedronis> :/
<mborzecki> Chipaca: installed snap disappeared from the state?
<Chipaca> well, it's hard to call it 'disappear' when the restore of the test overwrites state.json
<Chipaca> pedronis: it isn't the remodel per se; the restore of the test just was untidy
<Chipaca> i now need to test the fix a few times
<Chipaca> pedronis: we can remove required-snaps. Are we supposed to be able to remove required-snaps?
<pedronis> Chipaca: no, it's a bug in remodel, I actually discussed that mvo this morning
<pedronis> *with mvo
<pedronis> Chipaca: it's not setting the flag properly
<Chipaca> grr
<Chipaca> then this fix gets a lot harder
<Chipaca> pedronis: can you remodel 'back'?
<mborzecki> do we have a helper to parse size information that has format like 100M ?
<pedronis> Chipaca: yes
<Chipaca> mborzecki: yes, strutil
<mborzecki> Chipaca: ta!
<pedronis> it doesn't remove things
<Chipaca> mborzecki: strutil.ParseByteSize
<pedronis> but under correct behavior
<Chipaca> mborzecki: it's ISO tho
<pedronis> it would unset the required flag
<sergiusens> Chipaca: hey, do you know in what snapd version will the """download""" local snaps feature show up in?
<Chipaca> pedronis: so I can remodel back, and snap remove, and it'd be happy
<pedronis> Chipaca: yes
<pedronis> assuming no bugs :)
<Chipaca> sergiusens: 2.38 afaik
<pedronis> but we are interesetd to know if we have some
<Chipaca> sergiusens: but let me confirm
<Chipaca> sergiusens: this reminds me we still need to talk about the commandline options (not this week tho)
<Chipaca> sergiusens: maybe 2.39 :-(
<sergiusens> Chipaca: also, can we consider having a `snap wait-for-ready` command for easier scripting, and until that is done, what is the most bullet proof way to write my own? (e.g.; for multipass we run `multipass version` and wait for the `multipassd` version to show up)
<Chipaca> sergiusens: what is wait-for-ready
<sergiusens> Chipaca: block until snapd is ready
<pedronis> ready in which sense?
<Chipaca> sergiusens: what pedronis said
<Chipaca> sergiusens: snap wait system seed.loaded <- that's one version of 'wait for ready'
<sergiusens> ready to be able to carry over "snap install" commands through the socket (no need to consider networking)
<pedronis> then what John showed is mostly that
<sergiusens> to the minimum, the socket existing and taking connections
<sergiusens> great
<Chipaca> sergiusens: I should probably ask mvo every time somebody asks me about versions-to-features
<Chipaca> sergiusens: 2.38 isn't cut yet, so 2.38 will have the download api
<sergiusens> thanks Chipaca, that will be a pleasure ð
<Chipaca> sergiusens: you saw what its final form was?
 * pstolowski lunch
<sergiusens> Chipaca: is that to counter my "pleasure" comment? Should I be afraid?
<Chipaca> sergiusens: GET ..../v2/snaps/<snapname>/file
<sergiusens> Chipaca: I did not get to see it though, no... did it change much from what we discussed
<sergiusens> ah, that sounds usable
<Chipaca> :-)
<Chipaca> sergiusens: when you saw it it was the same, but .../blob
 * Chipaca <- really good at bad names
<sergiusens> I remember the tusks and husks and all that ð
<Chipaca> it's all been downhill since candirÃº
<Chipaca> cerati/candirÃº/curucÃº
<Chipaca> popey: BTW, Feb 11 17:07:15 hal snapd[14673]: desktop.go:129: cannot use line "Exec=/usr/share/code-insiders/code-insiders --new-window %F" for desktop file "/var/lib/snapd/desktop/applications/code-insiders_code-insiders.desktop" (snap code-insiders)
<Chipaca> maybe something to raise with code-insiders
<Chipaca> popey: and, as feared, Mar 19 12:31:02 hal snapd[3271]: main.go:141: DEBUG: activation done in 21.615s
<Chipaca> that's one slow activation
<mup> PR snapcraft#2505 closed: Test store <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2505>
<zyga> Chipaca: question to you sir
<zyga> Chipaca: when is a refresh done
<Chipaca> zyga: it was like that when I got there!
<zyga> conceptually
<zyga> hah :)
<zyga> I would like to reset a new time stored in the state when a refresh is ready
<Chipaca> zyga: I did not understand that last statement
<Chipaca> zyga: but
<Chipaca> zyga: please explain
<zyga> Chipaca: when refresh is done, when a part of a change that refreshes a particular snap is deemed complete, I'd like to perfrom some operations
<zyga> Chipaca: to account for that in the state
<zyga> Chipaca: should that be link-snap/
<zyga> Chipaca: or start services?
<zyga> or a new task?
<zyga> this may also be relevant for health checks
<Chipaca> pedronis: you _can't_ set a revision 'back' :-/
<zyga> Chipaca: do you know CLOS?
<pedronis> Chipaca: no, you can make a new one though, that is like the first
<Chipaca> pedronis: but i don't have the key for that
<Chipaca> pedronis: dunno who does
<Chipaca> pedronis: do you?
<pedronis> Chipaca: it's the test key
<Chipaca> zyga: no i do not know clos
<pedronis> it's in the code
<pedronis> but let's talk at the standup about this at this point
<zyga> (defmethod refresh :after ((s snap)) (setf (postponed-refresh-time (state-of-snap s)) 0))
<Chipaca> :-( ok
<zyga> something along those lines
 * Chipaca kickbans zyga
<zyga> hehe
<Chipaca> zyga: CLOs are collateralized loan obligations, the internet tells me
<zyga> https://lispcookbook.github.io/cl-cookbook/clos.html#method-qualifiers-before-after-around
 * pedronis eyes his copy of "The Art of The Metaobject Protocol"
 * Chipaca writes back to the kind person from google
<Chipaca> well, recruiter, 'person' might be a stretch
<Chipaca> I think the answer to "thinks are rather complex and starting to fail in ways that escape us" is not "let's make it more complex"
<zyga> all things evolve till the contain an implementation of lisp, that sort of thing ;)
<Chipaca> things*
<Chipaca> pedronis: I mean, I could push a fix that just does 'snap remove', which will then fail when it gets fixed
<pedronis> Chipaca: that's fine I think
<zyga> Chipaca: so.... where would I put something like that?
<pedronis> it will fail in a clear way
<pedronis> (at least)
<Chipaca> zyga: nowhere
<pedronis> zyga: it depends what you need to know?  link-snap is the easiest place if it's good enough
<zyga> pedronis: yeah, I think link-snap is OK for now
<zyga> pedronis: conceptually where post-refresh hooks run probably
<zyga> s/where/when/
<pedronis> we have rerefresh now , so you have options if you need something else
<pedronis> but link-snap would be easier
<pedronis> if it's enough
<mborzecki> off to pick up the kids
<zyga> I think it's enough for now
<zyga> thanks!
<zyga> it will all be a PR soon
 * Chipaca honestly didn't understand
 * Chipaca will look at the pr
<mvo> Chipaca: reading backlog - verison-to-feature - for some we have this in the forum. for all the "important" ones. remodel test - I miss some details, how can it leave things in state when we restore state.json from a backup?
<Chipaca> mvo: remodel test, fixing it
<Chipaca> mvo: with comments about how to fix it again when you fix remodel and thus break the test fixer
<Chipaca> mvo: i'll push as soon as it's green here
<mvo> Chipaca: woah
<mvo> Chipaca: looking forward to that
<Chipaca> Â¯\_(ã)_/Â¯ it's not lisp
<mvo> Chipaca: really curious what I'm missing
<Chipaca> =)
<roadmr> lots of incredibly silly parentheses
<mvo> Chipaca: at least this part I understand
 * mvo is very proud about this 
 * zyga is unsure about the LISP comments
<Chipaca> mvo: vvv
<mup> PR snapd#6620 opened: tests/main/remodel: clean up before reverting the state <Created by chipaca> <https://github.com/snapcore/snapd/pull/6620>
<Chipaca> mvo: ^^^
<mup> PR snapd#6621 opened: overlord/snapstate: track time of postponed refreshes <Created by zyga> <https://github.com/snapcore/snapd/pull/6621>
<mvo> Chipaca: looking
<mvo> Chipaca: thanks! do we actually keep state.json between when we do a restroe for the next test?
<mvo> Chipaca: what I'm missing is why this makes the state untidy
<Chipaca> mvo: this test itself does
<Chipaca> this test is rather piggy
<Chipaca> on classic, where we restore the state by hand, it doesn't break (because that restoring cleans things up also)
<mvo> Chipaca: oh, so this restore runs *after* the full restore?
<Chipaca> on core we use snapd to remove stuff, and that fails because of this
<mvo> Chipaca: aha
<Chipaca> so
<Chipaca> it's like this:
<Chipaca> this test restores the state, but does not clean up /var/snap
<mvo> Chipaca: it seems on core we also want to restore the previous state.json. it sounds dangerous what we do right now
<Chipaca> the next test that installs test-snapd-tools, fails on cleanup
<mvo> Chipaca: ohhhhh
<mvo> Chipaca: now I get it
<Chipaca> so it might not be the immediate next test
<Chipaca> it would have to install test-snapd-tools first :-)
<Chipaca> anyway, that
<Chipaca> mvo: on the contrary i'd be happier if restoring state.json wasn't needed (unless we were snapshotting the whole machine)
<Chipaca> because we _should_ be able to clean back to a known-good state
<Chipaca> but, alas, sometimes we don't
<Chipaca> so i dunno
<mvo> Chipaca: right, except that some tests use "jq" to do things
<mvo> Chipaca: which might make a mess
<Chipaca> yeah
<mvo> Chipaca: but yeah, I guess even then we should write good "jq"
<Chipaca> mvo: those do restore it tho
<Chipaca> at least, i grepped and it looked like they did
<Chipaca> i wasn't too thorough because i'm tired of red tests
<Chipaca> and the jq-using tests are all old :)
<mvo> Chipaca: thanks for finding this one, you get a hero medal for this one (https://www.google.com/imgres?imgurl=https://vignette.wikia.nocookie.net/wreckitralph/images/1/1d/RalphHeroesDutyMedal.png/revision/latest?cb%3D20130516213303&imgrefurl=https://wreckitralph.fandom.com/wiki/Medal_of_Heroes&docid=OoNm4g5X82ygWM&tbnid=4S4dCW2qcULhzM:&vet=1&w=783&h=446&source=sh/x/im)
<zyga> mvo: quick trivial for your consideration https://github.com/snapcore/snapd/pull/6622
<mup> PR #6622: cmd/libsnap: rename C enum for feature flag <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6622>
<mvo> zyga: thanks
<mup> PR snapd#6622 opened: cmd/libsnap: rename C enum for feature flag <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6622>
<zyga> hmm, comparing time is apparently harder than I hoped
<zyga> brb, see you at standup
<popey> Chipaca: sorry, i don't know what that means, whether it's good or bad (the DEBUG thing)
<Chipaca> popey: I'll be getting you a snapd with moar debug, if you don't mind
<popey> hah
<Chipaca> popey: because your snapd is taking 21 seconds to do â¦ nothing? :-)
<popey> sweet
<Chipaca> not nothing, but all very quick things
<Chipaca> so we're missing something :-)
<Chipaca> popey: i've got a few things on my plate before that tho
<Chipaca> so maybe tomorrow
<popey> kk
<popey> np
<Chipaca> any more things on my plate and the carrots will start touching the fish
<popey> Create a breakwater with some potatoes
<Chipaca> the potatos are at gravy carrying capacity
<Chipaca> as is law
<pedronis> Chipaca: we initialize the interface manager, that might have slow bits
<zyga> pedronis: perhaps we should inject a change (even a fake one) that accumulates the time of the system-key regeneration cost
<zyga> pedronis: it would help with accountability
<pedronis> well, the new infra can measure
<pedronis> out of changes too
<zyga> does the new infra measure non-task cost like this? if so that's great
<sergiusens> Chipaca: if I do not wait by other means, I get `error: cannot communicate with server: Get http://localhost/v2/snaps/system/conf?keys=seed.loaded: dial unix /run/snapd.socket: connect: no such file or directory`
<sergiusens> should I just loop until that call works? I want to avoid using anything internal that is subject to change
<Chipaca> sergiusens: that's strange, because multi-user.target and cloud-final.target both wait for that
<Chipaca> sergiusens: how are you getting 'in'?
<sergiusens> Chipaca: lxc exec
<ogra> HRM
<Chipaca> sergiusens: does that ssh?
<ogra> shouldnt "apt remove snapd" also remove all installed snaps ??
<sergiusens> Chipaca: no, it just runs whatever I tell it to run in that container
<Chipaca> ogra: purge does
<ogra> bah
<Chipaca> ogra: dpkg -P snapd
<sergiusens> Chipaca: if you say that waiting for cloud-init is enough, then I will do that
<ogra> apt purge does it too ... thanks ... i thought a simple remove suffices
<Chipaca> sergiusens: how do you wait for cloud-init?
<sergiusens> `apt remove --purge snapd`
<sergiusens> Chipaca: I am not, but I can
<Chipaca> sergiusens: if you can wait for cloud-init, can't you wait for snapd?
<sergiusens> Chipaca: I think we just agreed on what to do
<Chipaca> sergiusens: wait for snapd :)
<zyga> pstolowski: there are new imacs today :) https://www.apple.com/pl/imac/
<pstolowski> zyga: i'm not looking. lalalla.
<pstolowski> zyga: ok i lied; i looked
<Chipaca> i'm going for a walk to wake up a bit, bbiab
 * zyga lunch & walk
<zyga> jdstrand: 3 second PR https://github.com/snapcore/snapd/pull/6607
 * zyga really gone now
<mup> PR #6607: cmd: typedef mountinfo structures <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6607>
 * cachio lunch
<jdstrand> zyga: I'm aware of the PR :) I glanced at it, it isn't 3 seconds, but it is fast. I have several things I'm trying to get to, and that is towards the top
<zyga> jdstrand: how can it not be 3 seconds, it's a typedef :)
<zyga> jdstrand: but I'm happy to see the final review
<zyga> jdstrand: don't forget it's the 360 day
<jdstrand> zyga: cause it is a bunch of them :)
<zyga> that's always a priority
<jdstrand> zyga: indeed, that is one of the things that was before it (I just completed that, fwiw)
<zyga> I'm doing that now
<zyga> just NaN people left :)
<jdstrand> heh, yeah
<Chipaca> brb need to reroute my booter
<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
<zyga> almost done with 360s
<zyga> (and then the walk I promised myself)
<zyga> 360 done, I'll go now because it's getting dark
<zyga> ttyl
<mup> PR snapd#6623 opened: interfaces/builtin/opengl: allow access to Tegra X1 <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/6623>
<pedronis> Chipaca: mborzecki: we can close 6615 at this point, right?
<Chipaca> pedronis: i'm still running that
<Chipaca> pedronis: to confirm my hypothesis
<Chipaca> (so far it's failed because opensuse is having a day)
<pedronis> ah
<ackk> hi, does snapd do something special with /snap and snap dirs if the underlying fs is btrfs?
<Chipaca> ackk: no
<Chipaca> ackk: any weirdness you see is entirely of btrfs's making :-)
<Chipaca> pedronis: â¦ and again opensuse :-(
<zyga> ackk: can you tell me more please?
<pedronis> Chipaca: push to make it manual if it's having a day
<pedronis> Chipaca: that's another area that we'll need to think about in our tests
<ackk> zyga, so it's a bit complicated dev setup I have here. basically my disk is all btrfs, and I'm using "snap try" in a lxd container (which uses btrfs backend as well)
<ackk> zyga, the issue I'm having which I suspect is related is that sometimes I rsync some files to the prime/ dir then "snap restart mysnap" and I get "no such file or directory" when trying to execute snap commands
<ackk> but the files are there
<zyga> Can you provide a small reproducer
<zyga> I wonder if rsync replaces the directory
<zyga> Making the bind mount die
<ackk> zyga, it doesn't happen all the times. what I noticed is that the /snap dir in the snap shows as a btrfs subvolume mounted, but that's not true
<zyga> Can you provide a copy of proc self moujtinfo please
<ackk> zyga, specifically: /dev/mapper/ubuntu-root on /snap type btrfs (rw,noatime,ssd,space_cache,subvolid=1337,subvol=/lxd/storage-pools/default/containers/maas/rootfs/snap)
<ackk> sure one sec
<zyga> Tying from phone sorry
<zyga> I will be home in 10 minutes
<ackk> zyga, http://paste.ubuntu.com/p/SXmVh3XYM9/
<ackk> zyga, if you're trying to reproduce in a lxd container on your phone, that's impressive :)
<zyga> It is an Ubuntu phone ;-)
<zyga> Kidding though
<zyga> I will try at home
<ackk> thanks
<zyga> Do you have the broken setup still
<zyga> Can you jump into lxd
<zyga> And mointinfo there
<zyga> Lastly jump into broken mount namespace (use nsenter -m/run/snapd/ns/snapname.mnt)
<zyga> And provide that third mountinfo please
<ackk> zyga, I don't have it anmore at the moment
<zyga> Please wrap that into a bug report
<zyga> Ok
<zyga> Once you do please :-)
<ackk> zyga, fwiw the snap-try'd dir also was showing as a btrfs mount
<ackk> with a subvol= pointing at the dir (which is not really a subvol)
<ackk> zyga, that paste is from within the lxd fwiw
<ackk> zyga, ok I will, thanks
<ackk> I've seen this happening a lot of times
<ackk> zyga, if it matters, the snap is --devmode
<zyga> Snap try is just a bind mount
<zyga> Snaps sets that up based on the path given
<zyga> So it would likely be whatever is powering the lxd container
<zyga> My personal setup is not using btrfs
<zyga> ETOOMUCHHASSLE
<zyga> but perhaps I should dog food more
<zyga> Is this on openSUSE?
<ackk> no, ubuntu
<ackk> I've been using btrfs since xenial here
<zyga> Aha
<ackk> zyga, ah yeah indeed if you bind-mount a dir it shows in subvol
<zyga> ackk: so the bind mount subvol thing is a non-issue?
<zyga> ackk: I wonder about the breakage
<zyga> ackk: I suspect rsync is replacing the prime directory
<zyga> ackk: if this happens, look if mountinfo says "deleted"
<zyga> ackk: that would be a good bug report
<mup> PR # closed: snapcraft#1649, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2493, snapcraft#2495, snapcraft#2500, snapcraft#2504
<ackk> zyga, yeah it seems the bind mount just shows the dir as subvol, so I guess it's not an issue
<zyga> ackk: but you said it was broken too
<ackk> zyga, yeah sorry I mean, it's not something different that snapd is doing wrt the mountpoint
<zyga> ok
<ackk> zyga, yeah it seems binaries are not found althoguh they're there
<zyga> can you run "snap run --strace=--raw snap.app"
<zyga> I wonder what really happens
<mup> PR # opened: snapcraft#1649, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2493, snapcraft#2495, snapcraft#2500, snapcraft#2504
 * zyga EODs
<zyga> tty
<zyga> ackk: please follow up tomorrow, I'd love to see that strace
<Chipaca> #6620 could use a second review
<mup> PR #6620: tests/main/remodel: clean up before reverting the state <Created by chipaca> <https://github.com/snapcore/snapd/pull/6620>
<mup> PR snapd#6624 opened: overlord/snapstate, store: retry less for auto-stuff <Created by chipaca> <https://github.com/snapcore/snapd/pull/6624>
<Chipaca> and, pedronis if you're around, 6624 ^ is nasty but nice
<Chipaca> my wifi goes AWOL in 8 minutes, so my EOD is then
 * Chipaca trying a new thing to see if he can get his sleep schedule sorted
 * Chipaca thinks better about it, and adds two minutes to the scheduled wifi shutoff
<Chipaca> ok, EOD, ttyl, hand, etc etc
<cachio> niemeyer, hey
<cachio> niemeyer, when you have a minute, could you pleas take a look to https://github.com/snapcore/spread/pull/75
<mup> PR spread#75: Make spread tests for spread project run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75>
<cachio> ?
<pedronis> mvo: I don't think the whole of 6624 is viable for 2.38
<cachio> pedronis, about the card to add tests for service.ssh.disable
<pedronis> cachio: yes?
<cachio> pedronis, how should be the gadget scenario?
<cachio> jdstrand, hey, is there any lp issue for the sru validation?
<pedronis> cachio: we need something like  main/ubuntu-core-gadget-config-defaults/task.yaml at least
<pedronis> cachio: then we should explore if we can do something where we boot for real (not just snapd restart) with something made with ubuntu-image
<jdstrand> cachio: see privmsg
<cachio> pedronis, ok
<cachio> pedronis, starting with this, thanks
<mvo> pedronis: looking at 6624
<mvo> pedronis: yeah, it looks risky, lets discuss tomorrow, my brain is a bit fried
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117
<mup> PR # closed: core18#43, core18#63, core18#72, core18#90, core18#98, core18#120
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117
<mup> PR # opened: core18#43, core18#63, core18#72, core18#90, core18#98, core18#120
#snappy 2019-03-20
<mup> PR snapd#6625 opened: tests: system disable ssh for config defaults in gadget <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6625>
<mwhudson> is there a way via the snapd api to see if refreshing to a particular risk (in particular: including a branch) will perform an upgrade?
<wgrant> mwhudson: "risk (in particular: including a branch)" is just a channel
<mwhudson> wgrant: well ok my question still stands
<wgrant> mwhudson: snap refresh --list SNAP --channel=CHANNEL should do it, but it's not supported
<wgrant> Not sure why
<wgrant> --list doesn't take the normal refresh args
<mwhudson> it's a very different path inside snapd for whatever reason
<mwhudson> you can say snap switch --channel=foo SNAP, snap refresh --list
<wgrant> Ah, --list uses find
<wgrant> That's weird
<mwhudson> but that seems to silently succeed if you use a bogus channel
<wgrant> Yeah, snap refresh --channel=foo SNAP checks that the target channel exists, but snap switch doesn't
<wgrant> It doesn't look like snapd provides a sufficient API :(
<mwhudson> heh switch to a missing channel and refresh --list does end up with a complaint in the logs
<mwhudson> but i don't think i should be that evil :)
<mwhudson> snap refresh --no-wait --channel=foo SNAP and assume i can abort the job in time? :)
<wgrant> Heh
<mborzecki> morning
<mborzecki> shall we land #6620?
<mup> PR #6620: tests/main/remodel: clean up before reverting the state <Created by chipaca> <https://github.com/snapcore/snapd/pull/6620>
<zyga> Good morning
<zyga> Hey Maciej
<zyga> mborzecki: I will likely have a slower day today
<zyga> Looking at 6620
<mborzecki> zyga: hey hey
<zyga> Yeah
<zyga> Letâs land it
<zyga> good morning mvo
<zyga> I just merged the fix from chipaca
<zyga> let's see some green today :-)
<mup> PR snapd#6620 closed: tests/main/remodel: clean up before reverting the state <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6620>
<mvo> hey zyga
<zyga> I, selfishly restarted https://github.com/snapcore/snapd/pull/6622 - let's see if it goes green now
<zyga> hey :)
<mvo> zyga: thank you
<mup> PR #6622: cmd/libsnap: rename C enum for feature flag <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6622>
<mvo> zyga: lets focus on the 2.38 tagged one(s) initially :)
<zyga> I'll wait and see if anything turns green
<zyga> mvo: https://github.com/snapcore/snapd/pull/6617 needs a review from You
<mup> PR #6617: cmd/snap: fix regression of snap saved command <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6617>
<mup> PR snapd#6607 closed: cmd: typedef mountinfo structures <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6607>
<pstolowski> mornings
<mvo> hey pstolowski
<zyga> hey pawel :)
<zyga> hmm
<zyga> tests still red?
<mup> PR snapd#6626 opened: strutil: make SplitUnit public, allow negative numbers <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6626>
<mborzecki> should be a simple one ^^
<mborzecki> pstolowski: mvo: hey
<mvo> mborzecki: good morning
<zyga> mvo: https://github.com/snapcore/snapd/pull/6613 needs a 2nd review
<mup> PR #6613: interfaces/builtin: add dev/pts/ptmx access to docker_support (for 2.38) <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6613>
<mvo> zyga: on it
<zyga> mborzecki: is there anything that unicode.IsDigit returns true to that is not in range '0'..'9'?
<zyga> like any funky numerals?
<mborzecki> zyga: iirc that's what IsNumber could do
<mborzecki> afaik IsDigit is 0-9
<zyga> mborzecki: https://golang.org/src/unicode/digit.go
<zyga> mborzecki: https://golang.org/src/unicode/letter.go line 170
<zyga> mborzecki: I think it does more than you think it does :)
<zyga> at least my naive understanding would suggest that there are more characters that match
<zyga> can you run a simple loop over 65K runes and see what matches?
<zyga> mborzecki: https://golang.org/src/unicode/tables.go line 2308
<zyga> there's a lot of digits
<mborzecki> pfff
<mborzecki> à§¬ hello there little digit
<zyga> whaat? what is that?
<zyga> google says that is 6
<zyga> well
<zyga> I think the branch needs some more changes
<mborzecki> 'bengali digit one'
<zyga> ä¸
<zyga> I wonder if that also matches
<mborzecki> zyga: but it doesn't parse as a number
<zyga> äº
<mborzecki> "ßkB" -> cannot parse \"ßkB\": \"\\xdf\" is not a number
<zyga> hmm
<zyga> that's not what I sent, perhaps IRC client mangles that
<zyga> anyway :)
<mup> PR snapd#6613 closed: interfaces/builtin: add dev/pts/ptmx access to docker_support (for 2.38) <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6613>
<zyga> tests are still ungreen
<zyga> fatal: unable to access 'https://github.com/snapcore/squashfuse/': gnutls_handshake() failed: Error in the pull function.
<zyga> eh
<zyga> hey chihchun
<zyga> hey Chipaca
<zyga> hey tab completion :/
<Chipaca> hey zygurat
<Chipaca> :-p
<Chipaca> zyga: 'sup?
<zyga> Chipaca: it's a sunny day
<zyga> that's always good
 * Chipaca looks outside
<Chipaca> lies
<Chipaca> zyga: mborzecki: i agree about the unicode.IsDigit, saw that the other day and added a todo to fix it
<Chipaca> zyga: mborzecki: but in my case i was going to change it to return uints everywhere
<Chipaca> (because we weren't using it from anywhere that needed negative sizes anyway)
<Chipaca> mborzecki: but
<Chipaca> mborzecki: we rely on the behaviour of never returning negative
<Chipaca> ah but it now checks for that explicitly
<Chipaca> ok :-)
<mborzecki> hm have to fix the slicing too, otherwise it'll split up the unicode chars incorrecty
<Chipaca> mborzecki: ?
<mborzecki> Chipaca: just antoher bug in the PR that i see now
<Chipaca> mborzecki: did you change the loop from a range over the string?
<Chipaca> mborzecki: ranging over a string yields full runes
<mup> PR snapd#6627 opened: devicestate: deal correctly with the "required" flag on Remodel <Created by mvo5> <https://github.com/snapcore/snapd/pull/6627>
<Chipaca> mborzecki: https://play.golang.org/p/SUc1sdPpeUd fwiw
<Chipaca> mborzecki: or https://play.jsgo.io/8e1f7704efa0f1ca794f16e88134281cf870fe93 :-p
 * Chipaca stops having fun and gets to work
<mup> PR snapd#6628 opened: overlord/snapshotstate: support auto flag (automatic snapshots 1/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/6628>
<mborzecki> jsgo.io
<mborzecki> that's quite fancy
<mborzecki> and 3rd party imports work too
<Chipaca> mborzecki: they even tweaked the limits so we could import snapd in there
<Chipaca> (i mentioned this when it happened)
<mborzecki> Chipaca: zyga: updated the PR, please take a look
<zyga> enqueued, doing another review now
<mborzecki> zyga: #6605 needs master merge
<mup> PR #6605: cmd/libsnap,osutil: fix parsing of mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/6605>
<pedronis> mvo: hi, could you re-review #6575 when you have some time
<mup> PR #6575: cmd/snap-confine: pass sc_invocation instead of numerous args around <Created by zyga> <https://github.com/snapcore/snapd/pull/6575>
<zyga> mborzecki: thank you, I will de-conflict that soon
<mborzecki> need to grab some coffee
<mborzecki> relative offsets in gadget.yaml are so fancy
<Chipaca> mborzecki: I'd expect you to make a ParseByteSize analogue, ParseNonISOByteSize (or something), instead of exporting the helper, fwiw
<Chipaca> mborzecki: but I don't mind (obviously)
 * Chipaca not that worried
 * zyga could use a coffee too but first a quick merge with master
<mborzecki> Chipaca: would like that, but gadget takes sizes in format 1/1M/1G, SplitUnit is all i need
<zyga> https://github.com/snapcore/snapd/pull/6614 needs a 2nd review now
<mup> PR #6614: cmd/snap-confine: use fixed private tmp directory <Created by zyga> <https://github.com/snapcore/snapd/pull/6614>
<zyga> mborzecki: conflict resolved, thanks
<mborzecki> wodner how did google come up with 'stadia' as the name
<zyga> mborzecki: https://www.dailymotion.com/video/x1afila
<zyga> mborzecki: (seek to the end unless you know this one ;)
<mborzecki> heh
 * zyga looks at https://forum.snapcraft.io/t/problems-installing-a-base-core18-snap-on-bionic/10084/2 
<zyga> but first coffee, it's so cold in the office still
<zyga> I need to print something again, it's always cozy when that thing is on
<pedronis> Chipaca: can we have a chat about 6624, everything is more complicated than we remembered
<Chipaca> pstolowski: #6628 includes #6617 ?
<mup> PR #6628: overlord/snapshotstate: support auto flag (automatic snapshots 1/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/6628>
<mup> PR #6617: cmd/snap: fix regression of snap saved command <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6617>
<Chipaca> pedronis: sure
<pstolowski> Chipaca: no, i'm waiting for 6617 to become green, will merge and deconflict
<Chipaca> pedronis: but if it really is, that means it isn't 2.38 material, so I vote we refactor now and fix it properly
<pedronis> Chipaca: well the issue is not so much the change to autorefresh, is the store changes
<pstolowski> and maybe i'm very optimistic hoping for green..
<Chipaca> pedronis: i'm listening
<Chipaca> pstolowski: what's red now?
<pedronis> Chipaca: can we do a quick HO?
<Chipaca> pedronis: sure, in 5?
<pedronis> Chipaca: works for me, thanks
<pstolowski> Chipaca: just saying, still a couple of red PRs from there, maybe just need restarting
<pstolowski> d/from/
 * Chipaca searches for his headset
<Chipaca> pedronis: ready when you are
<pedronis> Chipaca: omw
<mvo> pedronis: sure, will re-review. thank you
<pstolowski> oh noes
<pstolowski> Chipaca: you asked about what's red... #6617 went red
<mup> PR #6617: cmd/snap: fix regression of snap saved command <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6617>
<Chipaca> fatal: unable to access 'https://go.googlesource.com/net/': Failed to connect to go.googlesource.com port 443: Connection timed out
<Chipaca> pstolowski: ^
<Chipaca> lots of timeouts from there
<Chipaca> pstolowski: restarted
<Chipaca> pstolowski: thank you
<Chipaca> pedronis: maybe i should've split the the backoff test, but it exercises the bits we want it to now
<pedronis> Chipaca: if you think two tests make more sense, yes let's do that
<Chipaca> pedronis: i think one is fine, even though the name could use a tweak
<Chipaca> as it's not just about the backoff
<Chipaca> but the comments cover what's going on
<Chipaca> and they're all about backoff in one way or another, so maybe it's fine
<pedronis> Chipaca: maybe it should have Error in the name?
<pedronis> is is about errors after all
<pstolowski> Chipaca: ty!
<pedronis> zyga: I need to have lunch, we should probably have a chat about 6597, seems we are a bit talking across each other
<mup> PR snapd#6622 closed: cmd/libsnap: rename C enum for feature flag <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6622>
<zyga> pedronis: gladly, I would prefer to do it before the standup if you can because I need to break early today
<pedronis> zyga: 20 mins before the standup?
<mvo> zyga, pedronis quick question abut https://github.com/snapcore/snapd/pull/6575#discussion_r264631829 then I can continue with the review
<mup> PR #6575: cmd/snap-confine: pass sc_invocation instead of numerous args around <Created by zyga> <https://github.com/snapcore/snapd/pull/6575>
<mvo> zyga: but I'm puzzled by this one
 * mvo probably miss something obvious
<zyga> mvo: looking
<zyga> mvo: replied
<zyga> pedronis: sounds good
<pedronis> mvo: the move make the unit test linking fail, I suppose it's .h bit of the move
<pedronis> s/linking/compiling/
 * mvo nods
<zyga> pedronis: we could move it again but I would have to rework snap-confine.c to effectively move main somewhere else
<mup> PR snapd#6629 opened: overlord/snapshotstate: helpers for dealing with expiration times <Created by stolowski> <https://github.com/snapcore/snapd/pull/6629>
<cachio> pedronis, hey, I see this error on the new test to disable ssh
<cachio> https://paste.ubuntu.com/p/d9ckjJWMPk/
<pedronis> cachio: we don't mask ssh, we use a file instead
<pedronis> mvo: ^
<cachio> pedronis, mvo which file?
<pedronis> one sec
<pedronis> cachio: /etc/ssh/sshd_not_to_be_run
<cachio> pedronis, nice, thanks
<pedronis> cachio: code is here: https://github.com/snapcore/snapd/blob/master/overlord/configstate/configcore/services.go#L59
<pedronis> we do unmask in case when (re)enabling, but our own disabling logic is based on that file
<pedronis> there's a conditional in the unit
<cachio> pedronis, reading, thanks for the info
<mvo> pedronis, cachio its complicated, we used to "mask" but had bugs becaus of ssh/sshd aliases and the recommended way was to use this file
<pstolowski> pedronis: re your comment to measurements PR about capturing task status, that's a good idea; does "task-status" tag sound ok?
<mvo> zyga: reviewed, sorry for the delay, had some questions
<pedronis> pstolowski: yes
<cachio> mvo, it is ok, I with that code I can adjust the test case
<zyga> mvo: no worries
<pedronis> pstolowski: like task-kind
<mvo> cachio: thanks
<pstolowski> pedronis: ty
<pstolowski> and now google:fedora-29-64:tests/main/degraded failed. fun.
 * pstolowski lunch
<zyga> mvo: updated https://github.com/snapcore/snapd/pull/6575 - I left one thing out (cleanups memset 0) and I would prefer to do it in a separate branch
<mup> PR #6575: cmd/snap-confine: pass sc_invocation instead of numerous args around <Created by zyga> <https://github.com/snapcore/snapd/pull/6575>
<ddstreet> mvo what's your plans for lp #1819728?  i have a couple/few systemd patches i'm planning to sru soon, i can include your patches if you think they will be ready this or next week
<mup> Bug #1819728: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) <patch> <verification-failed-bionic> <verification-failed-xenial> <verification-needed> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):Triaged> <systemd (Ubuntu
<mup> Bionic):Fix Committed> <https://launchpad.net/bugs/1819728>
<ddstreet> also i assume the current systemd bionic upload will be rejected due to failed verification, so you'll need to include lp #1778936 patch in the next upload as well
<mup> Bug #1778936: please re-add Support-system-image-read-only-etc.patch <patch> <verification-needed> <verification-needed-bionic> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Bionic):Fix Committed> <systemd (Ubuntu Cosmic):Fix Released> <https://launchpad.net/bugs/1778936>
<mborzecki> off to pick up the kids, may be a bit late to the standup
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6626 is green
<mup> PR #6626: strutil: make SplitUnit public, allow negative numbers <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6626>
<mvo> ddstreet: that sounds reasonable, I should have things ready by then. its not at all straightforward unfortunately because its 239->229 and there are a bunch of changes which cause conflicts etc. plus its a delicate area of the code. but I think i have something ready
<mvo> ddstreet: do you have a link to your things? just to double check that we don't conflict?
<ddstreet> mvo so far we have lp #1812760 and lp #1818282 which we're getting patches ready for, but also 2 more issues without bugs yet that we're investigating
<mup> Bug #1812760: networkd: [Route] PreferredSource not working in *.network files <sts> <systemd:Unknown> <systemd (Ubuntu):Fix Released by xnox> <systemd (Ubuntu Bionic):In
<mup> Progress by ddstreet> <systemd (Ubuntu Cosmic):In Progress by ddstreet> <systemd (Ubuntu Disco):Fix Released by xnox> <https://launchpad.net/bugs/1812760>
<mup> Bug #1818282: systemd-networkd - RoutingPolicyRule does not apply correctly <patch> <patch-accepted-upstream> <patch-forwarded-debian> <sts> <sts-sponsor> <sts-sponsor-ddstreet> <systemd (Ubuntu):Fix Released by joalif> <systemd (Ubuntu Bionic):In Progress by joalif> <systemd (Ubuntu Cosmic):In
<mup> Progress by joalif> <systemd (Ubuntu Disco):Fix Released by joalif> <systemd (Debian):New> <https://launchpad.net/bugs/1818282>
<ddstreet> mvo also, there may be a systemd security release coming soon so we might be waiting until after that to upload
<mvo> ddstreet: thanks, that looks like a totally different area, so that should be fine
<mup> PR snapd#6617 closed: cmd/snap: fix regression of snap saved command <Squash-merge> <â  Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6617>
<Chipaca> cachio: spread -list google:[^u]...:tests/...  vs  spread -list google:[u]...:tests/...
<zyga> pedronis: updated https://github.com/snapcore/snapd/pull/6597
<mup> PR #6597: cmd/snap-update-ns: refactor of profile application (1/N) <Created by zyga> <https://github.com/snapcore/snapd/pull/6597>
<mup> Bug #1821023 opened: core18 base on core 16 missing firmware <Snappy:Triaged by zyga> <https://launchpad.net/bugs/1821023>
<tobikoch> Is there an API call to determine which base a snap has before installation?
<zyga> tobikoch: yes, see what happens when you `snap info --verbose jq-core18`
<tobikoch> zyga: I see, I have to explicitly request the field.
<cachio> Chipaca, nice, thanks
<zyga> yes, I believe so
 * zyga needs to break, need to study before classes
<Chipaca> tobikoch: request it where?
<tobikoch> Chipaca: refresh API endpoint
<Chipaca> tobikoch: on api.snapcraft.io?
<tobikoch> Chipaca: yes
<Chipaca> tobikoch: refresh endpoint, or info endpoint?
<tobikoch> Chipaca: refresh
<Chipaca> strange, but ok
<Chipaca> tobikoch: what're you doing?
<Chipaca> (out of pure unadulterated curiosity)
<tobikoch> Updating the snap download tool in livecd-rootfs
<Chipaca> tobikoch: 'snap download' not cutting it?
<tobikoch> Chipaca: snap download was fine, but it doesn't allow passing along a cohort key.
<tobikoch> So until it does, there is this script.
 * cachio lunch
<Chipaca> pedronis: ^ were you aware that livecd-rootfs was using cohorts already?
<Chipaca> tobikoch: fascinating :-)
<tobikoch> heh
<Chipaca> tobikoch: if you're doing bases like that, how're you doing other prerequisites (content providers, particularly)?
<pedronis> Chipaca: yes
<pedronis> I was aware
<tobikoch> Chipaca: not sure I understand, so far the script does what it needs, I may be missing out on the wider scope.
<Chipaca> tobikoch: if it's not a proble, it's not a problem :-)
<tobikoch> :)
<tobikoch> Chipaca: this is only for download, it does nothing else.
<tobikoch> It's used for snap-preseeding in our images.
<pedronis> Chipaca: they might need changes, but that's really a discussion to have with the store for them
<Chipaca> k
<tobikoch> pedronis: actually I had mentioned it here: https://forum.snapcraft.io/t/managing-cohorts/8995/2
<pedronis> zyga: could you re-review #6485  (it has two reviews but it had a complicated history so a 3rd will not hurt)
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<zyga> pedronis: certainly!
<pedronis> thx
<iTommix> Hi. maybe someone can help me: my apache user www-data should run a snap app (like /snap/bin/vlc) but gives me âcannot create user data directory: /var/www/snap/vlc/770: Read-only file systemâ - first: the directoy is created by this app (its there), but second: could it be that there are missing permissions (solved with snap connect) ?
<zyga> iTommix: hey, just a partial answer, read only file system means that you are on a read only file system, permissions cannot fix this
<zyga> iTommix: I will let others help you, I'm partially AFK / commutting
<iTommix> zyga: thats not rightâ¦ the FS is writable.
<zyga> is the path realy /var/www/snap/vlc/770?
<zyga> that's unusual
<iTommix> yes, because of the user www-data home-dir its /var/www
<iTommix> i have an own âsnapâ-folder in my homedir
<zyga> iTommix: please seek help on the forum, I'm sorry I cannot help you more now
<iTommix> will wait till others answer maybeâ¦ thanks anyway :)
<mup> PR snapd#6610 closed: interfaces/builtin: add add exec "/" to docker-support <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6610>
<mup> PR snapd#6630 opened: cmd/snap: make 'snap warnings' output yamlish <Created by chipaca> <https://github.com/snapcore/snapd/pull/6630>
<mvo> pedronis: do you want to squash merge 6624 and tweak the commit message or shall I do it? the current commit message does not match the reality of the PR anymore (or maybe Chipaca can do it when he is back?)
<pedronis> mvo: I'm about to go afk
<Chipaca> ah
<Chipaca> mvo: i'll do it now
<pedronis> so I think either you or John
<pedronis> Chipaca: thx
<mvo> Chipaca: thank you! later is fine if you are on the run
<Chipaca> mvo: done
<Chipaca> about to disappear but here still :-)
<mvo> Chipaca: \o/
<mup> PR snapd#6624 closed: overlord/snapstate: retry less for auto-stuff <Squash-merge> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6624>
<mup> PR snapd#6631 opened: tests: split travis spread execution in 2 jobs for ubuntu and non ubuntu systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6631>
<mvo> pedronis, Chipaca just FYI, I added a comment in https://bugs.launchpad.net/snapd/+bug/1768419/comments/4
<mup> Bug #1768419: Pass through snapd client User-Agent to store requests snapd <snapd:Triaged> <https://launchpad.net/bugs/1768419>
<mup> PR snapd#6615 closed: spread: some debug info to catch /var/snap/.. not being empty <â Blocked> <Created by bboozzoo> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6615>
<mup> PR snapd#6626 closed: strutil: make SplitUnit public, allow negative numbers <Simple ð> <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6626>
<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
<Wimpress> Snapcraft Live! starts in about 10 minutes - https://www.youtube.com/watch?v=X_U-pcvBFrU
<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
<mup> PR snapcraft#2506 opened: schema, tests: add more detail wrt numeric version errors <Created by adanhawth> <https://github.com/snapcore/snapcraft/pull/2506>
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117
<mup> PR # closed: core18#43, core18#63, core18#72, core18#90, core18#98, core18#120
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117
<mup> PR # opened: core18#43, core18#63, core18#72, core18#90, core18#98, core18#120
#snappy 2019-03-21
<mup> PR snapd#6632 opened: tests: restore sbuild test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6632>
<zyga> Good morning
<mborzecki> morning
<zyga> o/
<zyga> hey mborzecki :)
<mborzecki> zyga: hey
<mborzecki> love when the PRs are green
<zyga> like the smell of fresh coffee in the morning
<zyga> I restarted a few PRs last night
<mborzecki> all but one of mine are green :)
<zyga> https://pact.kadena.io/example/Accounts
<zyga> neat stuff
<mborzecki> btw. today is the first day of spring for those in the northern part of the globe
<zyga> must explain my back pain :/
<mborzecki> zyga: what's with the lispy thing you linked?
<zyga> it's a formal verification engine that works over the web
<zyga> splice an algorithm
<zyga> add constraints
<zyga> and it formally proves it (or provides a violating input set)
<zyga> https://twitter.com/_wjmartino_/status/1105496676754751494 <- example
 * zyga goes to the office
<zyga> ttys (talk to you soon :)
<pstolowski> heyas
<mborzecki> pstolowski:  hey
<mborzecki> coffee time
<zyga> hey pawel :)
 * zyga will work on some debugging today
<mborzecki> mvo: morning
<mvo> hey mborzecki
<mvo> mborzecki: did I miss anything ?
<mborzecki> mvo: nope
<mborzecki> hmm, google:ubuntu-18.04-64:tests/main/desktop-portal-filechooser strikes again?
<mvo> booo
<mvo> ok
<mup> PR snapd#6632 closed: tests: restore sbuild test <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6632>
 * zyga looks at https://github.com/snapcore/snapd/pull/6485
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<zyga> mborzecki: reviewed
<mborzecki> zyga: thanks
<pedronis> zyga: mborzecki: I added a comment there
<pedronis> zyga: also shouldn't the system-key mechanism in part prevent trying to use old .bin ?
<mborzecki> pedronis: isnt't that in snap?
<pedronis> mborzecki: ?
<pedronis> it's the wait in snap-confine that zyga mentioned
<mborzecki> so there's this mechanism, one in snap-confine that waits for the profile to appear, and then we can fix the PR and use EnsureFileState or similar
<mborzecki> pedronis: that's the wait for compiled bpf profile
<pedronis> mborzecki: yes, ok, then we agree, and yes, some form of atomic rename, EnsureFIleState would be better
<pedronis> for that case
<mborzecki> iirc there was another mechanism in snap (?) that checked system-key
<pedronis> mborzecki: there's a mechanism that also wait if there's a system-key mismatch I think
<pedronis> in snap run
<pedronis> yes
<pedronis> likely
<mborzecki> ok, will push an update, got to figure out the gadget structure overlap first
<mborzecki> there's also some weird assumption about offset-write that isn't really clear
<pedronis> mborzecki: thx
<mvo> mborzecki: I think ubuntu-image also has a readme or some design doc or something that also explains some of this (not sure if that is helpful for your specific case though)
<mborzecki> mvo: i think i got it, idk maybe i'm bit too much used to anaconda/mic/wic way of specifying paritions/offsets and have some prior assumptions that don't hold up with u-i and gadget.yaml
 * mvo nods
<zyga> mborzecki, pedronis: I added some comments there as well
<zyga> I think the behavior of snap-run and snap-seccomp is important context for the reader there
<Chipaca> watchdog timeout in https://api.travis-ci.org/v3/job/509326704/log.txt
<Chipaca> very interesting
<zyga> Chipaca: looks like a deadlock?
<Chipaca> snapd thinks it's waiting for reboot, system has no inkling of it
<Chipaca> but then, because again we don't store the 'needs reboot' flag, snapd rolls back the refresh
<pedronis> Chipaca: we should fix that, but if we are waiting for a reboot and there's no reboot something else is also going on
<Chipaca> pedronis: yeah, the reboot happens later due to the revert
<zyga> what kicks the watchdog timer?
<zyga> is that from ensure loops?
<zyga> or from a dedicated goroutine?
<Chipaca> dunno, things are weird in that log
<pedronis> zyga: we have a dedicated goroutine
<pedronis> in main
<zyga> so that would have to die
<zyga> that's odd
<Chipaca> dedicated goroutine in cmd/snapd/main.go
<Chipaca> well
<Chipaca> not too odd
<Chipaca> we stop poking the watchdog if the daemon is Dying()
<zyga> ahh
<Chipaca> and the first thing daemon.Stop does is tomb.Kill
<zyga> mvo: 2.38 is on releases
<zyga> is that the day we package?
<mvo> zyga: we can wait for the beta validation but it should be fine
<zyga> ok
<zyga> tomorrow then
<zyga> thank you :)
<zyga> mborzecki: I'll do debian, fedora and suse
<mvo> zyga: yeah - or later today, more automation makes it quicker
<mborzecki> heh, someone already flagged snapd out of date in aur
<Son_Goku> mvo, errm
<Son_Goku> I think your releasing automation is broken
<Son_Goku> this is the second release I've looked at with a corrupted changelog entry
<Son_Goku> https://github.com/snapcore/snapd/commit/7d3222250d98ff1baf8ad4e7df283b40a35d960c
<Chipaca> Son_Goku: corrupted how?
<Son_Goku> it's missing the parent level "- New upstream release <version>" in the changelog entry
<mvo> Son_Goku: uh, sorry :/
<Son_Goku> it's alright
<Son_Goku> I've been fixing it locally and couldn't get ahold of you to let you know, so that's my bad :(
<mvo> Son_Goku: thanks for letting me know now :)
<mvo> and sorry again
<Son_Goku> I'm looking at the fedora 2.38 update now
<mvo> Son_Goku: thank you!
<Son_Goku> did we ever deal with the global MongoDB removal thing?
<mup> PR snapd#6612 closed: interfaces/builtin: add dev/pts/ptmx access to docker_support <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6612>
<Son_Goku> mvo or am I still going to need this? https://src.fedoraproject.org/rpms/snapd/blob/master/f/1001-errtracker-neuter-error-tracker.patch
<Chipaca> Son_Goku: why is that needed?
<Son_Goku> the mgo golang package requires mongodb itself, and mongodb was removed
<Son_Goku> Chipaca: https://src.fedoraproject.org/rpms/snapd/c/e923663082f5ce01052fe6299bbb1e0b6780bfc5?branch=master
<Chipaca> ah, i didn't remember the first half of that
<Chipaca> that's a bit silly
<Chipaca> :-/
<Chipaca> maybe we should vendor bson itself, directly
 * Son_Goku shrugs
<Son_Goku> MongoDB has been removed, effective Fedora 30
<Chipaca> that makes me happy, for historical reasons :-)
<Chipaca> Son_Goku: how grumpy would fedora be if we vendored bson?
<Chipaca> vendored as in pulled it into our tree directly, not via fancy golang vendoring
<Son_Goku> actually, it looks like my problem might be solved anyway
<Chipaca> oh no
<Chipaca> :-)
<mup> PR snapd#6633 opened: release: merge 2.38 changelogs back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/6633>
<Son_Goku> it looks like they might have mutated the driver sources so that mongodb isn't pulled in as part of using the sources to build a thing
<Chipaca> sweet
<Son_Goku> I'll need to test to see if it chokes on itself during the build or not
<Son_Goku> if not, then I can drop that patch
<zyga> Son_Goku: thank you for looking at the 2.38 update, I was planning on doing that tomorrow but please go ahead :)
<Son_Goku> well, I saw the bug report filed by anitya
<Son_Goku> (aka release-monitoring.org)
<zyga> Son_Goku: I saw it too
<mup> PR snapd#6634 opened: snap: add validation of gadget.yaml <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6634>
<zyga> the title of the forum topic: https://forum.snapcraft.io/t/layout-magic-collection/10501
<zyga> :D
<zyga> (I love that people use layouts to do things they could not do before)
<Son_Goku> hoooh
<Son_Goku> we have some SELinux stuff in 2.38
<mborzecki> Son_Goku: some
<Son_Goku> none of it is enabled in the spec for 2.38
<Son_Goku> so I guess I should leave it be then
<mup> PR snapd#6619 closed: partition,bootloader: rename 'partition' package to 'bootloader' <Simple ð> <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6619>
<mup> PR snapd#6635 opened: client, daemon, store: search by common-id <Created by chipaca> <https://github.com/snapcore/snapd/pull/6635>
<Chipaca> cprov: ^ fwiw
<Chipaca> zyga: u standup today?
<zyga> oh
<zyga> sorry
<zyga> I muted all notifications
<mup> PR snapcraft#2507 opened: build providers: improve handling in snap logic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2507>
<pedronis> pstolowski: what's the status of #6491? is it close to landing?
<mup> PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>
<pstolowski> pedronis: zyga promised to take another look
<mborzecki> zyga: added a comment here https://github.com/snapcore/snapd/pull/6485#discussion_r267821309 and in the code
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
 * cachio lunch
<mup> PR snapcraft#2508 opened: Build provider errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2508>
<pedronis> zyga: 6575 can be landed
<abeato> jdstrand, hey, are you sure that the behaviour re: empty cgroup is not a bug? See my last comment: https://github.com/snapcore/snapd/pull/6623#discussion_r267811338
<mup> PR #6623: interfaces/builtin/opengl: allow access to Tegra X1 <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/6623>
<pedronis> Chipaca: could you look at #6591 when you have a bit of time
<mup> PR #6591: overlord/ifacemgr: basic measurements <Created by stolowski> <https://github.com/snapcore/snapd/pull/6591>
<Chipaca> pedronis: ye
<pedronis> thx
<pedronis> zyga: I did another pass on some of your PRs
<zyga> pedronis: thank you!
<mvo> 2.38 is in disco!
<mup> PR snapd#6609 closed: snap/gadget: introduce volume update info <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6609>
<mup> PR snapd#6636 opened: cmd: prevent umask from breaking snap-run chain <Created by zyga> <https://github.com/snapcore/snapd/pull/6636>
<zyga> pedronis: any objections to merge https://github.com/snapcore/snapd/pull/6575
<mup> PR #6575: cmd/snap-confine: pass sc_invocation instead of numerous args around <Created by zyga> <https://github.com/snapcore/snapd/pull/6575>
<pedronis> zyga: no, I actually mentioned in the channel a while ago
<zyga> great, sorry I must have missed that
<pedronis> mvo: I left an after the fact comment about 6609
<mup> PR snapd#6575 closed: cmd/snap-confine: pass sc_invocation instead of numerous args around <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6575>
<mvo> pedronis: thanks, looking
<mvo> pedronis: uh, thank you for the comment in 6609 - looks like I was too trigger happy
<pedronis> mvo: not the end of the world
<zyga> pedronis: I updated https://github.com/snapcore/snapd/pull/6597
<mup> PR #6597: cmd/snap-update-ns: refactor of profile application (1/N) <Created by zyga> <https://github.com/snapcore/snapd/pull/6597>
<zyga> I hope this part is ready now
<pedronis> zyga: I'll look in the morning at this point
<mup> PR core18#63 closed: [RFC] snapcraft.yaml: add current date to core18 rev <Created by mvo5> <Closed by sil2100> <https://github.com/snapcore/core18/pull/63>
<mup> PR core18#121 opened: Make the version number date-based <Created by sil2100> <https://github.com/snapcore/core18/pull/121>
<zyga> pedronis: sure, thank you
 * zyga EOEs
<zyga> have a nice evening everyone
 * zyga goes to study
<zyga> jdstrand: hello, can you please enqueue https://github.com/snapcore/snapd/pull/6502 -- it is the next feature work I need your review for
<mup> PR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502>
<jdstrand> zyga: it is already enqueued
<Chipaca> EOD from me
<mup> PR snapcraft#2507 closed: build providers: improve handling in snap logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2507>
<mup> PR snapcraft#2508 closed: Build provider errors <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2508>
<mup> PR snapcraft#2509 opened: build providers: initial support for LXD <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2509>
<mup> PR snapcraft#2510 opened: Release changelog for 3.3 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2510>
#snappy 2019-03-22
<amurray> would be good to get snaps listed on this page https://github.com/google/sandboxed-api/blob/master/sandboxed_api/docs/sandbox-overview.md
<mborzecki> morning
<zyga> Good morning
<mborzecki> just been outside, really feels like spring
<zyga> amurray: interesting
<zyga> mborzecki: Iâm just stepping out
<zyga> My back is killing me today, way too many hours coding yesterday
<zyga> I will need a longer walk today
<mborzecki> zyga: buy a standing desk
<zyga> Eventually :-)
<zyga> I need to buy new NAS disks next month
<mborzecki> zyga: every couple of months tehre are some nice discouts at ikea
<zyga> Does one go with mdraid or zfs nowadays?
<zyga> I plan to get 3x(~5) TB in raid-5 and a 10+ TB drive for weekly snapshot off-case in case the main nas melts
<mborzecki> looking at gadget validation again, obviously forgot to check that size must be set at the structure level :/
<zyga> back in the office
<zyga> mborzecki: could you please look at https://github.com/snapcore/snapd/pull/6636
<mup> PR #6636: cmd: prevent umask from breaking snap-run chain <Created by zyga> <https://github.com/snapcore/snapd/pull/6636>
<zyga> it's not big but I want a second pair of UNIXy eyes :)
<mborzecki> zyga: LOOKING
<mborzecki> damn caps
<mborzecki> mvo: morning
<mvo> hey mborzecki
<mvo> mborzecki: good morning
<mborzecki> zyga: lgtm, left a comment about trying out umask 000 in the spread test too
<mborzecki> after all if it's supposed to be restored fully
<zyga> mborzecki: thank you, I will add more tests
<zyga> linux is funny
<zyga> mborzecki: you can have a process that lives in a current working directory that doesn't exist in its own mount namespace at all
<zyga> funny things happen
<pstolowski> morning
<mborzecki> pstolowski: hey
<zyga> hey pawel :)
<zyga> hey mvo
<mvo> hey zyga and pstolowski
<ackk> zyga, hi, I just hit that issue with the snap (under try) reporting not found on executables inside the snap
<ackk> zyga, how do I cat mountinfo in the right ns again?
<zyga> hey! thank  you for asking: use sudo nsenter -m/run/snapd/ns/foo.mnt
<zyga> then inside the new shell run cat /proc/self/mountinfo
<zyga> this information will be very useful
<zyga> a bit of usabilty warning: there cannot be a space between -m and the path
<ackk> ah that's what was hitting me
<ackk> zyga, btw strace doesn't seem to give much info: https://paste.ubuntu.com/p/xf3WQRZWyw/
<ackk> zyga, what should I look for in the mountifo?
<zyga> deleted
<zyga> but I would love to see the whole listing
<ackk> zyga, http://paste.ubuntu.com/p/zBq4X3TMXb/
<ackk> (this is in the ns)
<ackk> no deleted
<zyga> interesting
<zyga> hmm hmm
<zyga> can you run snap run --shell maas?
<ackk> same errorr (execv failed)
<zyga> hmmm
<zyga> mborzecki: ^ any ideas
 * zyga reads the mountinfo data 
<ackk> zyga, ftr I've run the rsync like hundred times yesterday and no issue
<ackk> it's always like that, it randomly happens once in a while
<zyga> ackk: what I find curious is that you can clearly nsenter
<zyga> ackk: what's the base snap?
<ackk> zyga, core18
<zyga> ackk: what are you tracking (which channel of the base snap)
<zyga> ackk: did it refresh recently?
<ackk> oh, I'm on core18 edge
<mborzecki> hm that strace doesn't have much content
<ackk> ah yes esterday
<mborzecki> is that a classic snap?
<ackk> refresh-date: yesterday at 13:38 UTC
<zyga> ackk: did it break at around the same time it refreshed?
<zyga> ackk: ahhh
<zyga> I know :D
<zyga> man
<zyga> hold on please
 * ackk curious
<zyga> ah, no :/
<zyga> man, I thought this is it
<zyga> we don't support try mode base snaps
<zyga> but that's clearly not it
<mborzecki> zyga: looks like it faiedl executing snap-confine, unless i'm missing something
<zyga> ackk: when you rsync, what do you do exactly?
<zyga> Permission denied is curious
<ackk> zyga, https://github.com/maas/maas/blob/master/Makefile#L781
<zyga> ackk: do you have any apparmor denials?
<ackk> zyga, it doesn't seem so
<ackk> I mean I have stuff in dmesg but I don't see new errors if I try to run it
<mborzecki> ackk: can you run /snap/core/6531/usr/lib/snapd/snap-confine --base core18 snap.maas.maas /usr/lib/snapd/snap-exec maas at all?
<zyga> mborzecki: don't forget SNAP_INSTANCE_NAME=maas
<ackk> no, same error
<zyga> permission?
<zyga> check dmesg again please
<ackk> $ SNAP_INSTANCE_NAME=maas /snap/core/6531/usr/lib/snapd/snap-confine --base core18 snap.maas.maas /usr/lib/snapd/snap-exec maas
<ackk> execv failed: No such file or directory
<zyga> wait
<zyga> before it was a permission denied error
<ackk> no new error
<zyga> ackk: since this a  core18 snap
<zyga> snapd (and snap-exec) come from another snap
<zyga> can you check one more thing
<zyga> run that same SNAP_INSTANCE_NAME=... line but run /bin/sh at the end
<zyga> instead of snap-exec that is
<zyga> once on the inside
<zyga> run ls -ld /usr/lib/snapd/snap-exec
 * zyga looks at mountinfo list again
<zyga> er
<mborzecki> zyga: s-c does some work, if it ran i'd expect to see taht in strace log
<ackk> $ SNAP_INSTANCE_NAME=maas /snap/core/6531/usr/lib/snapd/snap-confine --base core18 snap.maas.maas /bin/ls -ld /usr/lib/snapd/snap-exec
<ackk> /bin/ls: cannot access '/usr/lib/snapd/snap-exec': No such file or directory
<zyga> there's no /usr/lib/snapd!
<ackk> there is but it's empty
<zyga>  SNAP_INSTANCE_NAME=maas /snap/core/6531/usr/lib/snapd/snap-confine --base core18 snap.maas.maas /bin/sh
<zyga> then cd /usr/lib
<zyga> ls -ld snapd
<zyga> ls -l snapd
 * zyga checks stuff
<ackk> $ ls -lad snapd
<ackk> drwxr-xr-x 2 root root 0 Mar 21 11:41 snapd
<ackk> $ ls -l snapd
<ackk> total 0
<ackk> the dir is there, but empty
<ackk> is that a mountpoint?
<ackk> I mean, does snapd bind-mount stuff on top?
<zyga> it should be a mountpoint
<ackk> zyga, so you think it could be related to the core refresh?
<zyga> that explainswhat you are seeing
<zyga> perhaps
<zyga> can you collect snap changes and add this to the bug report
<ackk> it might well be that's been broken since yesterday,but I haven't restarted the service (nor called the cli) since then, although I think I did
<zyga> ackk: do you have snapd.snap?
<ackk> zyga, where?
<zyga> is snapd the snap installed on your system
<ackk> no
<zyga> snap list | grep snapd :)
<zyga> ok
<zyga> thank you
<zyga> ackk: I think we have enough to explore this now
<zyga> the key question is what happens when core18 + core + app combo has a refresh of core18
<zyga> or a refresh of core
<zyga> when core refreshes it's different
<zyga> actually
<zyga> that's a separate bug
<zyga> we will never update the tooling
<zyga> mvo: core18/core bug
<ackk> are core18 apps still somewhat dependent on core?
<ackk> I think I had filed a bug a long time ago about it, and I've still seen the issue recently
<zyga> mvo: when /usr/lib/snapd comes from core on a core18 base snap app, the core refresh is not reflected in the mount namespace of the app
<zyga> that is
<mvo> zyga: they shouldn't be - hm, hm
<zyga> mvo: future snapd is using old snap-exec
<zyga> mvo: it's like a stale base snap prolem
<mvo> zyga: oh, snap-exec is not coming from snap?
<zyga> mvo: but a stale core snap sub-problem
<mvo> zyga: not from the snapd snap?
<zyga> mvo: when it comes from core
<pedronis> there is snapd snap aroung yet
<zyga> mvo: core18 + core (as source of snap tools) + app
<pedronis> there is *no*
<zyga> mvo: core refreshes
<zyga> mvo: now you have stale tools in the app snap
<mvo> ok
<zyga> mvo: or perhaps that is exactly what ackk observed, an tools just disappear somehow
<ackk> zyga, fwiw "core" refreshed 10 days ago
<pedronis> zyga: basically  all the snaps that compose the mount namespace can have a staleness prolem no?
<pedronis> also content snaps
<zyga> mvo: thank you
<zyga> pedronis: yes
<mvo> zyga: what do we need to do to unstable the mount namespace?
<pedronis> zyga: we check only base though?
<zyga> pedronis: content snaps are better
<zyga> pedronis: because those are new paths that change in the mount profile
<zyga> pedronis: so they are correctly updated
<zyga> pedronis: it's just the core tooling for now
<zyga> pedronis: nothing else exists outside of the snap-update-ns system
<zyga> pedronis: yes, we check for base only explicitly because that's the do-I-rebuild-from-scratch decision
<zyga> mvo: can you rephrase the question please?
<ackk> zyga, should I try refreshing core18 (to stable perhaps)?
<zyga> ackk: to aid in debugging? no, to lower the inconvenience for your development: yes
<mvo> zyga: what do we need to do to fix this .) ?
<zyga> ackk: you can discard the mount namespace to fix it
<zyga> mvo: I dont know yet, I don't fully undestand the reason /usr/lib/snapd was empty
<zyga> but I think we should be able to reproduce it now
<ackk> zyga,  the var/lib/snapd in the snap?
<zyga> ackk: sorry?
<zyga> mvo: perhaps it's one issue after all
<ackk> zyga, oh sorry, discard the namespace I see
<ackk> zyga, I thought you meant unmounting something
<zyga> mvo: sudo /usr/lib/snapd/snap-discard-ns mass
<zyga> er
<zyga> ackk: ^ :)
<ackk> zyga, thanks
<ackk> zyga, oh refreshing to stable also worked
<zyga> yes
<zyga> because then you have new base
<zyga> and you get a fresh mount ns
<ackk> I see
<zyga> ackk: thank you very much for this
<zyga> please do report the bug
<zyga> we may split it if this turns out to be a pair of issues
<ackk> zyga, thank you for digging it
<zyga> I will work on it next week for sure
<pedronis> fyi, I need to do some non-PR work before getting back to reviewing
<ackk> zyga, is "snap stops working after base refresh" accurate as a title?
<zyga> ackk: /usr/lib/snapd unmounted in app + core18 + core (tooling) use case; possibly on core refresh
<zyga> that is the summary in my head
<ackk> zyga, but it was a core18 refresh, not core
<zyga> ah, sorry
<zyga> I will check all combinations though
<zyga> there are clearly missing bits there
<zyga> brb, coffee ran out
<ackk> zyga, https://bugs.launchpad.net/snapd/+bug/1821302
<mup> Bug #1821302: /usr/lib/snapd unmounted in app + core18 + core (tooling) use case; possibly on core18 refresh <snapd:New> <https://launchpad.net/bugs/1821302>
<zyga> ack :)
<zyga> this is the week of snap-confine fixes and changes
<ackk> zyga, IDK if it could be related, but I still see the issue where if I install a core18-based snap on a clean system (no core snap) it fails to install (the configure hook fails)
<ackk> zyga, e.g. snap install --edge maas
<zyga> ackk: yes, this is related
<zyga> ackk: we track that bug separately now
<ackk> zyga, do you have the link?
<zyga> ackk: I have a draft solution on my system but it will not be ready yet
<zyga> ackk: there's a forum thread aboug this, i have not upgraded it to a bug report yet: https://forum.snapcraft.io/t/problems-installing-a-base-core18-snap-on-bionic/10084/
<ackk> zyga, ah cool thanks
<zyga> mborzecki: https://www.omgubuntu.co.uk/2019/03/linux-data-cap-survey
<mborzecki> aah survey
<mborzecki> nice
<pstolowski> mvo: hey, added some extra tests you suggested for #6591
<mup> PR #6591: overlord/ifacemgr: basic measurements <Created by stolowski> <https://github.com/snapcore/snapd/pull/6591>
<mborzecki> zyga:  haha 'RSS feeds' in question 'How would you prioritise these data to download if you had limited internet access?'
<zyga> yeah
<zyga> who cares about that
<zyga> who ordered RSS?
<mvo> pstolowski: thanks, looking
<zyga> completed the survey
<zyga> as someone who is on capped links 24/7 it's important that people care about this
<mup> PR snapd#6637 opened: interfaces: deal with the snapd snap correctly for apparmor 2.13 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6637>
<pedronis> mvo: there's a card for that https://trello.com/c/1h4hrY3W/180-implement-snapd-snap-support-in-apparmor-backend-dbus-backend-setup-etc  ^
<pedronis> also I think there were todo left in other backends too
<mvo> pedronis: indeed, added the PR and will see what else needs to be done there
<pedronis> mvo: should also be moved to doing :)
<pedronis> mborzecki: hi, do you know why we would get a line like this:
<pedronis> content                   gnome-calculator:gtk3-themes      gtk-common-themes:gtk3-themes
<pedronis> in connections,  there is not content discriminant there
<mborzecki> pedronis: that with 2.38?
<pedronis> with edge
<pedronis> but anyway I get the other ones with []
<pedronis> but not that one
<pedronis> I thought we always set one internally
<pedronis> mborzecki: I'm doing snap connections gnome-logs
<mborzecki> pedronis: mhm, installing the snap right now
<mborzecki> hmmm pinner with 'Automatically connect eligible plugs and slots of snap "gnome-calculator"', didn'g we have a fix that would switch to showing progress of the download if a dependncy is being installed?
<mborzecki> s/pinner/spinner/
<mborzecki> pedronis: .38 has 		//
<mborzecki> content[gnome-3-28-1804]  gnome-calculator:gnome-3-28-1804  gnome-3-28-1804:gnome-3-28-1804  -
<mup> PR snapd#6638 opened: interfaces: add support for the snapd snap in the dbus backend  <Created by mvo5> <https://github.com/snapcore/snapd/pull/6638>
<pedronis> mborzecki: I'm talking about gtk3-themes
<pedronis> but I don't see that in the snaps
<pedronis> mmh
<mborzecki> content[gtk-3-themes]     gnome-logs:gtk-3-themes     gtk-common-themes:gtk-3-themes   -
<mborzecki> content[icon-themes]      gnome-logs:icon-themes      gtk-common-themes:icon-themes    -
<mborzecki> content[sound-themes]     gnome-logs:sound-themes     gtk-common-themes:sound-themes   -
<pedronis> mborzecki: it's the issue that we don't remove non-existent connections I suppose
<pedronis> mborzecki: it's  not a connections problem, it's other issues
<pedronis> mborzecki: if you just installed it you won't see that
<mborzecki> pedronis: buf if i disconect, remove and reinstall?
<pedronis> yes, a different case
<zyga> mvo: fun bug, command-not-found is still in use while in snap run- --hell
<zyga> (I meant --shell)
<zyga> but the binary is not there anymore
<pstolowski> failed to prepare google:opensuse-15.0-64:project, do we have an issue with opensuse in gcloud again?
<mup> PR core18#122 opened: hooks: add apt/apt-get/apt-cache warning <Created by mvo5> <https://github.com/snapcore/core18/pull/122>
<zyga> pstolowski: what was the failure?
<zyga> pstolowski: ah, I see it now
<zyga> cachio: ^ we need to change how we install packages
<zyga> mborzecki: ^ any ideas, is that a stale cache?
<zyga> openSUSE Leap 15.0 package installation issue in spread https://www.irccloud.com/pastebin/Z5UvBD4B/
<mborzecki> hmm
<pstolowski> zyga: interesting, i didn't see any error output for google:opensuse-15.0-64:project, just failed to prepare
<zyga> I saw this in one of my own runs
 * zyga needs to take a break
<zyga> to avoid the chronic back pain
<zyga> mborzecki: there will be an interesting patch later today
<zyga> mborzecki: another unixy thing :)
<mborzecki> no clue about that opensuse thing, perhaps unfinished mirror sync?
<zyga> I think it's like dnf upgrade vs dnf distrosync
<pedronis> pstolowski: is there anything left for 6491 that can't be follow ups about improving the test?
<zyga> we are probably doing something wrong and should be using "dnf dup" instead of another operation
<mborzecki> but it's leap, zypper up should be enough
<zyga> mborzecki: up != dup
<zyga> mborzecki: but not sure :/
<zyga> anyway, I spawned some larger testing for an important snap-confine change, I will break for an hour to move around a bit
<mborzecki> zyga: i mean zypper up should be enough for leap, tw has it's own weirdnness :)
<zyga> I'm on telegram if anyone needs me urgently
<MattJ> \\\\\\!
<MattJ> Sorry, words of wisdom from my daughter there
<zyga> haha :)
<ackk> zyga, just to confirm, I hit the issue again (no core refresh this time) and calling snap-discard-ns fixed it
<ackk> zyga, actually not so much, now I get a "read only filesystem" error
<ackk> cannot create user data directory: /root/snap/maas/x1: Read-only file system
<zyga> ackk: x1 got unmounted somehow?
<ackk> zyga, well I suspect it's because of the discard ns ?
<zyga> ackk: is your snap "broken" (as in snap list shows broken next to it)
<zyga> no, that's not doing that
<ackk> no it wasn't
<zyga> discard will not change /snap/anything
<ackk> (now I actually removed it)
<zyga> ah, wait
<zyga> I misread that
<zyga>  what is /root/snap/maax/x1
<zyga> is that a bind mount?
<zyga> it would only be a ROFS in case it's a bind mount or if /root inside the mount namespace was unmounted
<zyga> but if _that_ is the case then I would really like to know what's going on
 * zyga is AFK now
<ackk> zyga, it's the user dir
<mborzecki> the fun start when offset 0 is a valid value
<mborzecki> looks like some of the fields in our gadget structures should be pointers
<mborzecki> off to the kids' school for a bit
<pstolowski> pedronis: sorry, missed your earlier message; no, nothing left to do in #6491
<mup> PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>
<pstolowski> nb it failed on 14.04 with 'system does not fully support snapd: cannot mount squashfs image' ?!
<pstolowski> among 2 other unrelated test failures.. interfaces-daemon-notify seems to be flaky
<geodb27> People : hi ! I've come to this issue with the snap version of lxd : https://github.com/lxc/lxd/issues/5590 is that related to snap or to lxd and is there a way to get things work as they are expected to ? To be more specific, I guess that snap don"t like user's home directory to be out of /home
<pstolowski> geodb27: correct, user homes need to be in /home currently, no way around that
<geodb27> So, my guess was right, thanks for you answer pstolowski. However, to my knowledge, snap is the only one I encounter that relies on this. Is there any technical reason for that (I'm only curious) ? There is an env var set at user login which is filled in with the home directory. Why not use it ?
<pedronis> pstolowski: did it have a recent master merge?
<pstolowski> pedronis: hmm possibly not, i merged yesterday. doing
<pstolowski> geodb27: it's more complicated due to confinement (apparmor profiles etc)
<geodb27> oki, I see, thanks again for your kind explanation pstolowski. This will lead me to to many changes on my servers... I'll see how I can go with the less damages.
<pstolowski> geodb27: you're welcome!
<cachio> zyga, taking a look  to opensuse now
<zyga> geodb27: I can refer you to the technical reasons but I am AFK now
<zyga> Thanks cachio
<mborzecki> re
<mup> PR snapd#6639 opened: snap: tweak parsing errors of gadget updates <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6639>
<ackk> zyga, why would snapd try to create that directory (/root/snap/maas/x1 when starting a service?
<zyga> ackk: we create SNAP USER DATA
<zyga> because snaps themselves cannot
<ackk> yeah but that dir is there
<ackk> why does the snap  suddenly thinks it's readonly
<mup> PR snapd#6640 opened: spread: refresh metadata on openSUSE <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6640>
<mborzecki> zypper tell me the latest version of libudev is 234-lp150.20.15.1, not 234-lp150.19.1.x86_64
<mborzecki> cachio: was opensuse-15.0 image already updated?
<diddledan> did the forum fall over? https://usercontent.irccloud-cdn.com/file/kZeiOkOL/image.png
<diddledan> seems opening a different tab rectified it
<diddledan> ignore me
<cachio> mborzecki, no yet
<cachio> mborzecki, found more problems
<cachio> mborzecki, some package digests are different
<cachio> mborzecki,  the image is ready and uploaded
<cachio> uploading
<mborzecki> cachio: cause before asking i tried running zypper in <packages> that were failing in the test and it worked, so maybe just a mirror sync problem
<mborzecki> cachio: still, zypper up show a number of updates avaialble at that point, will try with an updated image now
<cachio> mborzecki, yes, the mirrors are giving us problems
<cachio> mborzecki, I already updated all the packages to make the update process faster
<cachio> I is almost uploaded
<cachio> mborzecki, image ready
<mborzecki> cachio: it probably was something with mirror sync, #6640 started before an updated image was uploaded and it's green
<mup> PR #6640: spread: refresh metadata on openSUSE <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6640>
 * cachio lunch
<Wimpress> The next Snapcraft Summit has been announced - https://snapcraft.io/blog/snapcraft-summit-montreal
<mup> PR snapd#6641 opened: snap-gdb-shim: switch to the SUDO_UID when available <Created by mvo5> <https://github.com/snapcore/snapd/pull/6641>
<kenvandine> zyga: we're continuing to see reports on the forum of users not able to run the gnome snaps because the content interface isn't mounted
<kenvandine> zyga: it's something i've only seen a couple times and  snap-discard-ns seems to resolve it
<kenvandine> zyga: latest reference https://forum.snapcraft.io/t/gnome-calculator-problem/4579
<mup> PR snapd#6640 closed: spread: refresh metadata on openSUSE <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6640>
<kenvandine> zyga: if i can't find an existing bug report, i'll file a new one
<pstolowski> pedronis: you've requested John's review on #6591; is it required or can it land now that it has mvo's review?
<mup> PR #6591: overlord/ifacemgr: basic measurements <Created by stolowski> <https://github.com/snapcore/snapd/pull/6591>
<pedronis> pstolowski: it can land, I asked him in case mvo didn't have time
<pstolowski> ack
<pstolowski> thx
<mup> PR snapd#6591 closed: overlord/ifacemgr: basic measurements <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6591>
<kenvandine> zyga: bug 1785410
<mup> Bug #1785410: Can not open Gnome snaps as they are not connected to Â«gnome platform snapÂ» <amd64> <apport-bug> <bionic> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1785410>
<popey> zyga: what do we need to do to bump the priority of that bug? It's pretty harmful as people use it as a reason to remove snaps entirely
<kenvandine> mvo: ^^
<mvo> kenvandine: in a meeting, adding it to our trello, we get back to you
<kenvandine> mvo: thanks
<diddledan> user: "compiling this application is difficult with no docs on what it depends upon proving that linux sucks" my reply: "I made a snap of this app so you don't need to compile it!" their retort: "another packaging system isn't the solution. compiling stuff is proving that linux is terrible" <-- I tried to point out that compiling the application on Windows or Mac would be just as difficult, but they insisted that it proves
<diddledan> linux is crap
<mvo> kenvandine: I have not looked at all at this though, sorry :/ will also check with zyga
<diddledan> specifically starruler2 (game) was what they were trying to compile
<zyga> re
 * zyga reads backlog
<zyga> kenvandine: I will investigate several related reports next week,
<zyga> kenvandine: thank you for the bug report
<zyga> kenvandine: right now no immediate smoking gun but we know of one issue related to core18
<zyga> kenvandine: but perhaps there's more magic to uncover there
<zyga> kenvandine: anyone with instructions on how to reporduce would be awesome as all of those bugs are "not sure how I got there but..."
<zyga> kenvandine: I will write a few new tests next week, specifically when there's a mount namespace consisting of an app snap a base snap (e.g. core18) and the core or snapd snaps providing the tools, each of those can refresh / change
<zyga> kenvandine: we don't have full test coverage for that scenario as we learned
<zyga> kenvandine: all of the snap-update-ns / snap-confine bugs are my priority and I will investigate them ASAP
<kenvandine> zyga: yeah, this is something we've seen randomly for ages now, since the gnome-24 content snap
<zyga> kenvandine: we fixed one known issue: base snap refresh was buggy (in two ways actually)
<zyga> kenvandine: we know of several more issues: when base snap changes (core -> core18) we do bad stuff if the app is still running
<zyga> kenvandine: and when the snapd tooling (snap-exec snapctl) is coming from core/snapd on a snap using base: core18 there is no handling for that becoming stale
<zyga> kenvandine: I was discussing with ackk earlier today when his try snap was misbehaving
<zyga> kenvandine: and some of the observations indicated that various things got unmounted
<zyga> kenvandine: next week I will collect all the bugs and recent forum postings, try to file missing bugs and triage them, then write extra tests to see if anything can be reproduced this way
<kenvandine> zyga: thanks
<pedronis> pstolowski: I created a meeting for Monday, let me know if it doesn't work
<pstolowski> pedronis: it's fine, thank you
<cachio> mvo, I see this error on nightly test suite https://paste.ubuntu.com/p/Bp2xw9H8p6/
<mvo> cachio: this looks like a store timeout: Client.Timeout
<mvo>        exceeded while awaiting headers
<cachio> mvo, it is weird because it failed many times
<cachio> yesterday and today
<mvo> cachio: oh, ok - maybe a real problem on the store, might be best to ask in #snapstore
<cachio> ok
 * zyga resumes work on the cwd fixes
<zyga> first test corrected
<LinAGKar> I can't run any snaps on OpenSUSE Tumbleweed. I just get "cannot read mount namespace identifier of pid 1: Permission denied", and prevously I have gotten "libmount.so.1 snap shared library not loading".
<zyga> second test also corrected
<zyga> jdstrand: do you want to see it?
<zyga> LinAGKar: hello
<zyga> LinAGKar: what version of snapd are you on?
<zyga> LinAGKar: can you look at /var/log/audit/audit.log (as root) and grep for "DENIED"
<zyga> LinAGKar: give me the denials please
<zyga> and thank you for reporting this!
<LinAGKar> I have `type=AVC msg=audit(1553279757.513:482): apparmor="DENIED" operation="ptrace" profile="/usr/lib/snapd/snap-confine" pid=24430 comm="snap-confine" requested_mask="read" denied_mask="read" peer="unconfined"` there.
<zyga> LinAGKar: wow, thats' curious
<zyga> LinAGKar: uname -a?
<LinAGKar> zyga: I have snapd 2.37.4-1.8
<zyga> I will upload 2.38 tomorrow
<zyga> I wonder if that's something that was fixed there
<LinAGKar> zyga: `Linux sudda.kvasta 5.0.2-1-default #1 SMP Thu Mar 14 08:29:17 UTC 2019 (d1f1d19) x86_64 x86_64 x86_64 GNU/Linux`
<zyga> 5.0 hmm
<zyga> maybe apparmor regression
<zyga> LinAGKar: thank you for reporting this, would you mind opening a bug
<zyga> LinAGKar: can be either launchpad or opensuse bugzilla
<zyga> LinAGKar: I will fix it, if I can, for next week
<zyga> and sorry for the trouble
<zyga> jdstrand: ^ this is also interestign
<zyga> *interesting even :-)
<LinAGKar> zyga: I'll go file a bug report.
<zyga> thank you very much
<jdstrand> the snap-confine profile already has ptrace read peer=unconfined,
<zyga> yeah
<zyga> maybe some funky 5.0 behavior?
<jdstrand> I'm on 5.0
<zyga> but with ubuntu sauce
<zyga> perhaps the non-upstreamed patches are relevant here
<jdstrand> no sauce for ptrace
<zyga> aha
<zyga> well, that's a good data point
<zyga> I will attempt to reproduce this as soon as I'm done with this patch
 * jdstrand is still heads down on other things. can't look at cwd today
<zyga> jdstrand: sure :)
<zyga> jdstrand: we'll chat next week
<zyga> I will finish the extra descriptions and open the PR
<zyga> enjoy your weekend :)
<LinAGKar> zyga: Bug report here: https://bugs.launchpad.net/snapd/+bug/1821396
<mup> Bug #1821396: cannot read mount namespace identifier of pid 1: Permission denied, on OpenSUSE Tumbleweed with Linux 5.0 <snapd:New> <https://launchpad.net/bugs/1821396>
<zyga> LinAGKar: assigned, thank you
<zyga> I will check if 2.38 fixes it and upload ASAP
<zyga> if not, I will debug further
<LinAGKar> I guess I didn't need to put it her myself.
<zyga> LinAGKar: snapd will soon-ish be in the opensuse repository
<zyga> LinAGKar: I'm sure this will improve the quality aspect as it will be so much easier to just try it
<LinAGKar> zyga: In the official repos?
<zyga> yes
<zyga> I suspect that 2.37.5 will be first
<zyga> and then 2.38 and onwards, I'm not sure what the release schedule impact will be though, yet
<zyga> regression test added
<zyga> mvo: https://github.com/snapcore/snapd/pull/6642 patch of the day
<mup> PR #6642: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642>
<mup> PR snapd#6642 opened: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642>
<mvo> zyga: nice
<zyga> LinAGKar: I've booted my TW machine, let me update to see if I'm missing something
<zyga> LinAGKar: on 5.0.2-1 it is still working but I often use bleeding edge local builds
<zyga> jdstrand: I pushed the regression test for TIOCSTI
<mup> PR snapd#6643 opened: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
<zyga> okay, that's all for today for me
<zyga> have a fantastic weekend everyone
<zyga> LinAGKar: in case it keeps working for me, can you think of any customization you did on top of the vanilla installation?
<LinAGKar> zyga: I've done quite a bit, hard to tell what would affect it. This machine did originally run OpenSUSE 13.2.
<zyga> aha
<zyga> I will investigate
<zyga> not giving up :)
<LinAGKar> zyga:  I've also had it suspended, no sure if that affects it.
<zyga> but not tonight, need to sleep
<zyga> no, it would not
<zyga> can you be on IRC next week?
<LinAGKar> zyga: I will.
<zyga> thank you
<zyga> enjoy your weekend too :) see you on Monday
<LinAGKar> Enjoy your too
<LinAGKar> Thank you
<mup> PR snapcraft#2511 opened: build providers: modify the _run signature <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2511>
 * cachio EOW
<mup> PR snapcraft#2510 closed: Release changelog for 3.3 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2510>
#snappy 2019-03-23
<mup> Bug #1812605 changed: snap find crached <Snappy:Expired> <https://launchpad.net/bugs/1812605>
<handsome_feng> Hi, I want to upgrade an software offline, and I make a delta file by 'xdelta3 -s telegram-desktop_637.snap telegram-desktop_617.snap telegram-desktop_637.snap.xdelta3', Does anyone know how to refresh the software in the offline computer using this xdelta3 file?
<zyga> handsome_feng: hey
<zyga> handsome_feng: instead of a delta perhaps just get "snap download telegram-desktop" on an online computer and copy the  pair of files over
<zyga> handsome_feng: then use "snap ack" on the assertion file
<zyga> handsome_feng: followed by "snap install" on the snap file
<zyga> handsome_feng: this has the same effect as a normal online installation
<handsome_feng> zyga: Thank you, but is it possible to refresh the software with the xdelta3 file only, since a software can be very big and I have post this in the snapcraft.io: https://forum.snapcraft.io/t/how-to-update-a-software-using-xdeltal3-file/10533 :)
<zyga> handsome_feng: yes but you need to do it manually
<zyga> just compute the delta of the revision you have there
<zyga> handsome_feng: normally the store does that
<zyga> handsome_feng: but if you want manually, go ahead
<zyga> handsome_feng: just reconstruct the file on the offline machine
 * zyga goes AFK 
<handsome_feng> zyga: Thanks, Do you know the details of reconstruct the file on the offline machine? I got the xdelta command from the snapcraft source code, and I think the "apply xdelta3" part is in the source code of snapd, but I'm not familiar with 'go' language, :(
<zyga> handsome_feng: it's not related to go, you can use any delta system you want
<zyga> handsome_feng: I'm not personally familiar with it but I'm sure xdelta manual page shows how to use it
#snappy 2019-03-24
<handsome_feng> zyga: Got it, thank you very much! :)
<Son_Goku> zyga, can you poke robert-ancell about this? https://github.com/snapcore/snapd-glib/pull/58
<Son_Goku> my snapd + snapd-glib update is blocked on this
#snappy 2020-03-16
<RingtailedFox> thank
<RingtailedFox> thanks Eighth_Doctor
<RingtailedFox> how do i go about turning that ./spec file into an RPM?
<mborzecki> morning
<mborzecki> starting around 9, need to run an errand and do groceries before the panicked crowds show up
<pedronis> mvo: hi, maybe it was already noticed, but it seems we have a real issue with seccomp unit tests on 20.04: https://api.travis-ci.org/v3/job/662738603/log.txt
<mvo> pedronis: yeah, I'm checking that right now
<mvo> pedronis: also the postrm test is still flaky, a bit annoying
<mup> PR snapd#8262 closed: interfaces/udisks2: also allow Introspection on /org/freedesktop/UDisks/** <Simple ð> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8262>
<mup> PR snapd#8263 closed: interfaces/udisks2: also allow Introspection on /org/freedesktop/UDisks2/** - 2.44 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8263>
<pedronis> mvo: this test seems also flaky sometimes snap-session-agent-socket-activation
<pedronis> seems a timing issue
<mvo> pedronis: on all OSes or just specific ones? I noticed it only on ubuntu-core-16
<mup> PR snapd#8261 closed: interfaces: work around apparmor_parser slowness affecting uio (2.44) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8261>
<pedronis> I seen it also on non-core
<mvo> pedronis: ok, I see what I can find
<pedronis> mvo: maybe jamesh can also help with that one
<zyga> good morning
<zyga> pedronis: this is known, I reported it on tumbleweed about a week ago
<pedronis> zyga: well we have it on 20.04 now
<zyga> https://bugs.launchpad.net/snapd/+bug/1866183
<mup> Bug #1866183: seccomp tests fail in tumbleweed on 2020-03-05 <snapd:New> <https://launchpad.net/bugs/1866183>
<zyga> fun :|
<zyga> ok
<zyga> I had a terrible night, I'm barely awake
<zyga> how can I help?
<zyga> should I jump at seccomp, at reproducible maas content bug, at something existing like app tracking?
<mvo> zyga: I'm looking at this right now
<mvo> zyga: maas content bug sounds worthwhile
<mvo> zyga: I can reproduce the seccomp one
<pedronis> mvo: is it segfaulting ?
<zyga> I'll get to it
<mvo> pedronis: not sure yet, seccomp got upgraded from 2.4.2 to 2.4.3
<mvo> pedronis: this is triggering it
<pedronis> ok, seccomp upgrade seemed the most likely candidate
<zyga> mvo: if you do please check if the list in the bug I referenced is the same as in ubuntu now
<zyga> I hope it's the same bug
<mvo> zyga: yeah, output looks exactly the same
<mvo> zyga: I bet the same lib update happend there too
<zyga> yeah, that's a good sign
<zyga> whatever it is we will need just one solution
<pedronis> this is fixed now:  https://bugs.launchpad.net/snapd/+bug/1863807 ?
<mup> Bug #1863807: core snap rev 8716 breaks keyboard input in chromium and inkscape <snapd:New> <https://launchpad.net/bugs/1863807>
<zyga> pedronis: I think it was
<zyga> pedronis: it was a change in input handling in ibus or something alike
<zyga> pedronis: jamie fixed it a few weeks ago
<pedronis> mvo: they asked you a question here: https://bugs.launchpad.net/snapd/+bug/1863816
<mup> Bug #1863816: trusty: snapd deb package does not start systemd <snapd:New> <https://launchpad.net/bugs/1863816>
<zyga> https://bugs.launchpad.net/snapd/+bug/1867415 is interesting :|
<pstolowski> morning
<mup> Bug #1867415: Hardlinking snaps wastes 400 MB tmpfs RAM in live CDs <snapd:New> <https://launchpad.net/bugs/1867415>
<zyga> hey pawel
<zyga> pstolowski: it's a morning but not particularly good one ;)
<pstolowski> zyga: oh, bugs?
<zyga> pstolowski: bugs and spiders
<zyga> oh
<zyga> public service announcement
<zyga> if you are running focal
<zyga> be careful not to break your system
<pedronis> zyga: I assigned this to you: https://bugs.launchpad.net/snapd/+bug/1866855  not sure what's it's overall priority
<mup> Bug #1866855: nvidia driver integration is incompatible with Debian <snapd:Triaged by zyga> <https://launchpad.net/bugs/1866855>
<zyga> pedronis: ack, I can check on my nvidia box
<zyga> thank you
<zyga> I'll look at it to evaluate after maas bug
<zyga> I suspect it might go away if we update snapd in debian though
<zyga> probably a worthy goal anyway
<zyga> mvo: debian question, is debian in some sort of freeze? new queue is full of things that are many weeks old
<zyga> or is that just shortage of ftp masters?
<zyga> re about focal: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1866844
<mup> Bug #1866844: package libc6:amd64 2.31-0ubuntu3 failed to install/upgrade: installed libc6:amd64 package post-installation script subprocess returned error exit status
<mup> 127 <amd64> <apport-package> <focal> <package-from-proposed> <glibc (Ubuntu):Fix Released> <glibc (Ubuntu Focal):Fix Released> <https://launchpad.net/bugs/1866844>
<zyga> I got affected, need to spend some time to fix my laptop so that it boots normally again
<zyga> I see it's got fixed now, that's really good
<pedronis> mvo: one you have a moment: https://bugs.launchpad.net/snapd/+bug/1867415 is this medium or high?
<mup> Bug #1867415: Hardlinking snaps wastes 400 MB tmpfs RAM in live CDs <snapd:Triaged> <https://launchpad.net/bugs/1867415>
<zyga> pedronis: note, we can use statfs to detect overlayfs and switch to symlinks
<zyga> it sucks we only learned this the hard way so close to release date :/
<pedronis> what was the conclusion on this at the sprint: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1865519 ?
<mup> Bug #1865519: apparmor depends on python3 <snapd:Triaged> <apparmor (Ubuntu):New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1865519>
<zyga> pedronis: I think jamie said that it's not bad that python3 is a dependency but I don't remember if the people in the room had another consistent opinion
<pedronis> anyway is not a snapd bug strictly
<pedronis> why is this bug is saying install/update, when it looks like a purge op: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1866932 ?
<mup> Bug #1866932: package snapd 2.44~pre1+20.04 failed to install/upgrade: installed snapd package post-removal script subprocess returned error exit status 1 <amd64> <apport-package> <focal> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1866932>
<mborzecki> morning
<mborzecki> mvo: got logs from the postrm test?
<mvo> mborzecki: yes, one sec
<mvo> mborzecki: I was initially suspecting a race, i.e. the output not quite in sync
<mvo> mborzecki: but my naive (late night) adding a sleep did not help at all so it's probably something else
<mvo> mborzecki: https://api.travis-ci.org/v3/job/662738604/log.txt
<mvo> mborzecki: + grep -E 'snap\..*\.(service|timer|socket)'
<mvo> Ã¢âÂ snap.test-snapd-service-stop-timeout.svc.service                                            not-found failed failed    snap.test-snapd-service-stop-timeout.svc.service
<mvo> + echo 'found unexpected leftovers'
<mvo> found unexpected leftovers
<mvo> + exit 1
<mborzecki> ha a different service this time
<mborzecki> mvo: should be a simple fix
<mvo> mborzecki: oh, ok
<pedronis> zyga: this is not fixed yet https://bugs.launchpad.net/snapd/+bug/1821302 right?  I'm marking it just high
<mup> Bug #1821302: /usr/lib/snapd unmounted in app + core18 + core (tooling) use case; possibly on core18 refresh <snapd:Triaged by zyga> <https://launchpad.net/bugs/1821302>
<zyga> pedronis: correct
<mvo> zyga: did suse upgrade to libc6 2.31 too? I suspect it's actually the libc6 update that breaks the tests (and I think I have a fix, just making sure I understand it)
<mborzecki> mvo: well, maybe not that simple though, it's the same thing as i investigated last week, there's systemd service state leaking between the tests, even though we call systemctl reset-failed in restore :/
<zyga> mvo: I don't know, let me check
<mvo> mborzecki: yeah, that part confused me
<mvo> mborzecki: it looks like we explicitly reset it :(
<mvo> mborzecki: hence suspecting the race
<mborzecki> mvo: and it's on sid, before the problem was seen on arch
<zyga> mvo: but I would expect so, tumbleweed rolls weekly
<zyga> booting now
<mborzecki> mvo: systemd 245 here on arch, same in sid
<mborzecki> zyga: what's the current version of systemd in tw?
<zyga> mborzecki: still updating, give me a moment
<pedronis> mvo: again, once you have a moment:  should this be won't-fixed also on the package: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1673247
<mup> Bug #1673247: package snapd 2.23.1 failed to install/upgrade: trying to overwrite '/etc/apparmor.d/usr.lib.snapd.snap-confine', which is also in package snap-confine 2.23.1 <amd64> <apport-package> <package-conflict> <patch> <xenial> <snapd:Won't Fix> <dpkg (Ubuntu):In Progress> <snapd (Ubuntu):In
<mup> Progress by mvo> <dpkg (Ubuntu Trusty):Confirmed> <snapd (Ubuntu Trusty):In Progress> <dpkg (Ubuntu Xenial):Confirmed> <snapd (Ubuntu Xenial):Confirmed> <dpkg (Ubuntu Yakkety):Invalid>
<mup> <snapd (Ubuntu Yakkety):Invalid> <dpkg (Ubuntu Zesty):Confirmed> <snapd (Ubuntu Zesty):Confirmed for slavikstar> <https://launchpad.net/bugs/1673247>
<mvo> mborzecki: focal has systemd 244, so that's the most recent we have
<mvo> pstolowski: I opened it now and once I'm done with the test issue will look in detail
<mvo> pedronis: ^-- (and thanks for the pointer)
<mvo> pstolowski: ups, sorry
<mvo> zyga: according to their website also glibc 2.31, I think that's the one that breaks things for us, fixing now
<pedronis> pstolowski: hi, maybe you can review #8264 when you have a moment
<mup> PR #8264: many: introduce snapdenv to present common snapd env options <Created by pedronis> <https://github.com/snapcore/snapd/pull/8264>
<pstolowski> pedronis: sure
<zyga> mborzecki: 244
<zyga> zyga@yantra:~> systemctl --version
<zyga> systemd 244 (+suse.138.gf8adabc2b1)
<zyga> +PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 -IDN +PCRE2 default-hierarchy=hybrid
<zyga> mvo: glibc version 2.31-2.1
<mvo> zyga: ta
<mborzecki> zyga: thx
<mup> PR snapd#8265 opened: tests: add regression test for MAAS refresh bug <Created by zyga> <https://github.com/snapcore/snapd/pull/8265>
<zyga> so some good news
<zyga> if mborzecki can help me with selinux denials
<mborzecki> hm?
<zyga> I can fix the bug affecting maas by just enabling robust mount ns updates
<mborzecki> i shuld hijack my wife's fedora laptop for a couple of days and try to weed out all the denials if there's any left
<zyga> https://github.com/snapcore/snapd/pull/8089 is critical
<mup> PR #8089: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089>
<zyga> as in, fixing those denials will really improve snap experience for people
<mborzecki> i investigated one on thursday evening (because there's better to do on a day off), and i think that desktop-helpers were causing a problem by doing cp -a on user-dirs.locale
<zyga> mborzecki: not all denials are equal
<zyga> if we just get over the hump that allows 8089 to land
<zyga> it will mean a lot
<mborzecki> omg, reproduced the problem with postrm-purge in a spread run where i forgot to add -debug /o\
<zyga> mborzecki: ouch :|
<zyga> btw, it failed for me today
<pedronis> zyga: btw, I did work on 8242 end of last week
<zyga> yeah, I noticed, I didn't review the changes yet but I plan to soon
<zyga> thank you :)
<zyga> I looked at snapdenv just now and it looks good
<zyga> it's a much needed cleanup
<pedronis> yea, though it was an indirect reminder that store (and daemon) are still our least loved code
<mvo> fwiw, I will work more on 8266 but wanted to unblock you guys
<mup> PR snapd#8266 opened: snap-seccomp: allow mprotect() to unblock the tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/8266>
<mborzecki> heh, so with new systemd, there's a unicode dot printed in the sssytemctl line
<mborzecki> â snap.test-snapd-service-stop-timeout.svc.service not-found failed failed snap.test-snapd-service-stop-timeout.svc.service
<mborzecki> ofc it doesn't match the awk pattern we search
<pedronis> fun, otoh we are culpable of those kind of changes to info or list, so can't blame
<mborzecki> heh
<pedronis> mborzecki: mvo: on the UC20 uboot front, I worked a bit on it and #8228 needs 2nd reviews
<mup> PR #8228: boot,image: ARM kernel extract prepare image <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8228>
<mvo> pedronis: nice, thank you!
<mborzecki> pedronis: we got ourselves a deadlock in the reviews of that PR, looks like each of us pushed a bit there :)
 * mvo will look at this
<pedronis> mborzecki: well, I think if both mvo and you look at it again, we are ok
<pedronis> mborzecki: mvo: it's missing a unit test though, but that can come in a follow up, anyway there's the todo and rename as well
 * mvo is in a meeting but will look at the PR after that
<mborzecki> hmm reset-failed does not clear the status though, the unit is still in not-found/failed state, wtf?
<mborzecki> maybe someone in #systemd has a clue
<zyga> mborzecki: sergio said he needs to reset twice
<mborzecki> reset what? the service?
<zyga> reset failed
<zyga> just do it twice
<mborzecki> google:debian-sid-64 .../tests/main/postrm-purge# systemctl reset-failed --force snap.test-snapd-service.test-snapd-service-refuses-to-stop.service
<mborzecki> Failed to reset failed state of unit snap.test-snapd-service.test-snapd-service-refuses-to-stop.service: Unit snap.test-snapd-service.test-snapd-service-refuses-to-stop.service not loaded.
<mborzecki> google:debian-sid-64 .../tests/main/postrm-purge# systemctl reset-failed --force snap.test-snapd-service.test-snapd-service-refuses-to-stop.service
<mborzecki> Failed to reset failed state of unit snap.test-snapd-service.test-snapd-service-refuses-to-stop.service: Unit snap.test-snapd-service.test-snapd-service-refuses-to-stop.service not loaded.
<mborzecki> zyga: ^^ :)
<zyga> not loaded
<zyga> but does it list as failed?
<zyga> weird
<mborzecki> yup
<zyga> maybe deamon reload and then?
<mborzecki> however, i can do `systemctl reset-failed` (no params, resets all units) and the status is cleared
<zyga> huh
<zyga> magic
<zyga> or
<zyga> maybe the unit is really gone
<zyga> and it cannot be referred to by name anymore
<zyga> and reset-failed can clear "unreachable" units somehow
<mborzecki> it is, but we were able to reset-failed a unit that was not found before
<zyga> ackk: hey
<zyga> ackk: some good news :)
<ackk>  hi zyga, I saw :)
<zyga> ackk: please try that and let me know if you run into any issues having that enabled
<ackk> zyga, how do I enable?
<zyga> ackk: like this https://github.com/snapcore/snapd/pull/8265/files#diff-09aaa35036aab4cfb8a7a8ae90869822R14
<mup> PR #8265: tests: add regression test for MAAS refresh bug <Created by zyga> <https://github.com/snapcore/snapd/pull/8265>
<ackk> oh I see, thanks
<ackk> zyga, I'll let you know if I hit the issue again, thanks
<zyga> ackk: I just wanted to say I'm very grateful for the bug report with information on how to reproduce
<ackk> zyga, is the plan to enable the feature by default in the next release?
<zyga> ackk: I know this was plaguing you for many weeks now
<zyga> ackk: yes, we just need to adjust the selinux policy because it currently blocks the branch that enables this from landing
<ackk> zyga, no problem, happy that it was helpful :)
<ackk> zyga, thank you for jumping on it
<zyga> my pleasure :) I really like making things robust
<ackk> heh
<mup> PR snapd#8267 opened: tests/lib/reset: workaround unicode dot in systemctl output <Simple ð> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8267>
<mborzecki> now i can't reproduce the reset-failed problem on sid, wth?
<mborzecki> anyways, mvo ^^ 8267 shoudl fix the postrm-purge and snap-mgmt tests
<mvo> mborzecki: nice, thank you
<pedronis> mborzecki: then maybe more than it alone needs to reset-failed
<mborzecki> zyga: suse is using /var/lib/snapd/snap too?
<zyga> nope
<ackk> mvo, hi WRT https://bugs.launchpad.net/maas/+bug/1867571 (ISTR we talked about the issue in the past) looking at snapd core it seems there is an apparmor rule allowing read access to /run/uuidd/request, is the denial because of the "w" ?
<mup> Bug #1867571: apparmor denied warning for /run/uuidd/request <MAAS:Triaged> <https://launchpad.net/bugs/1867571>
<mvo> ackk: in a meeting right now, will get back to you
<ackk> mvo, np, thanks
<zyga> ackk: looks like it
<zyga> ackk: let me check snapd to be ure
<zyga> *sure
<ackk> zyga, fwiw it seems you need write access too, as libuuid does write to the socket to get the uuid
<ackk> I'm not sure of the protocol
<zyga> ackk: you get write access with openvswitch-support
<zyga> ackk: everyone else get s read access by default
<ackk> zyga, right, but read access is probably useless?
<zyga> I don't know
<zyga> I suspect not
<zyga> it is a socket
<zyga> perhaps just reading is enough?
<ackk> zyga, https://paste.ubuntu.com/p/kfNs4pkMyS/ is what "uuidgen -t" does
<zyga> ackk: as I said, I don't know
<zyga> one would have to read the source of uuidd
<zyga> and check what's the protocol
<mvo> the mprotect() fix failed aparently in non-ubuntu, does anyone have details? if it's something silly like the postrm-purge failure I can merge and override the failure
<mvo> but it looks like I can't see the reason for the restart of the testrun unfortunately
<zyga> wasn't me
<sparkiegeek> appreciate y'alls thoughts on https://forum.snapcraft.io/t/uuidd-apparmor-denial/16013
<ackk> zyga, looking at https://github.com/karelzak/util-linux/blob/master/libuuid/src/uuidd.h#L43-L49 you have to write the type of operation you want, so you need write access
<ackk> zyga, I suspect the current rule isn't really working (although libuuid will still work as it falls back to local getrandom() if the socket fails)
<zyga> ackk: I see
 * ackk adds comment to sparkiegeek's post
<zyga> pedronis: I reviewed 8264
<zyga> ackk, sparkiegeek: thank you
<zyga> I suspect it's a jamie topic
<zyga> I can change stuff but he needs to ultimately review that anyway
<ackk> zyga, can we test locally by hacking apparmor rules for the maas snap? (adding "w" support)
<zyga> yes
<zyga> always :)
<ackk> zyga, how do I do that?
<zyga> ackk: you need to edit the appropriate text file
<zyga> they are stored in /var/lib/snapd/apparmor/profiles
<zyga> and are named after the snap and application name
<zyga> the correct one should be easy to locate
<zyga> then you need to locate the line that mentions uuidd
<zyga> and change "r," to "rw," - mind the comma, they are relevant
<zyga> and issue a command to compile and insert the profile into the kernel
<zyga> sudo apparmor_parser -r /path/to/that/profile/file
<zyga> mind you that snapd will regenerate profiles for many operations
<zyga> so your changes may get undone
<zyga> let me know if you need ehlp
<zyga> *help
<ackk> zyga, that seems to fix the issue
<ackk> sparkiegeek, ^
<sparkiegeek> ackk: ack
<mup> PR snapd#8266 closed: snap-seccomp: allow mprotect() to unblock the tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8266>
<mup> PR snapd#8267 closed: tests/lib/reset: workaround unicode dot in systemctl output <Simple ð> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8267>
<pedronis> zyga: thanks, I tried to answer your questions
<zyga> looking
<pedronis> zyga: also notice that the description has a list of TODOs for follow-ups already, this PR is already quite big given what is doing
<zyga> ok
<zyga> ah
<zyga> I missedthe PR message somehow
<pedronis> the main motivation for this is actually PreseedMode, but yes ideally all SNAPD_/SNAPPY_ vars would be handled like this, buit is quite a bit of work that is hard to justify atm
<pedronis> at least we have a place now
<zyga> pedronis: LGTM, happy to see progress in this area :)
<jdstrand> sparkiegeek: note that 8537ba5b2816ac1a2f77dc03ba709947b11a2531 added it to snap-update-ns profile. it was only in 2049f2c8245da1d97c96fcc76bab871eb0491d23#diff-a34e166c5b3016c122430c5884f41e9b from last week where it was added to the default template.
<cachio> mvo, hey
<jdstrand> it still only had 'r' though
<sparkiegeek> jdstrand: thanks
<jdstrand> has*
<mup> PR snapd#8268 opened: snap-seccomp: robustness improvements <Created by mvo5> <https://github.com/snapcore/snapd/pull/8268>
<cachio> mvo, snapd,failure is failing also on uc18 na uc20, on PR #8252
<mup> PR #8252: tests: update test to make snapd snap fixed twice <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8252>
<ijohnson> guten morgen from the quarantine :-)
<sparkiegeek> jdstrand: ninja-edit'd post to reference the correct commit
<mborzecki> pedronis: added StoreAcount in #8246
<mup> PR #8246: client, daemon, overlord/devicestate: structures and stubs for systems API <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8246>
<cachio> Saviq, hey
<Saviq> cachio: oi!
<cachio> I plan to delete fedora 28/9 images from gce, are you using them ?
<pedronis> mborzecki: reviewed
<cachio> I need to clean up a bit
<mborzecki> pedronis: thanks!
<Saviq> cachio: fire away https://github.com/MirServer/mir/blob/master/.travis.yml#L47
<cachio> nice, thanks
<Saviq> or more importantly https://github.com/MirServer/mir/blob/master/spread.yaml#L5
<pedronis> ijohnson: hello, I pushed a bit forward your PRs on Friday
<ijohnson> hey pedronis
<ijohnson> Great, I see some of them were merged
 * zyga breaks for coffee
<zyga> or actually
<zyga> maybe I'll grab lunch and then coffee
<zyga> ahead of the standup
<mup> PR snapd#8269 opened: apparmor: add rw for uuidd request to default and remove from snap-update-ns <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8269>
<jdstrand> sparkiegeek, ackk: fyi, ^
<ackk> jdstrand, thanks!
<sparkiegeek> jdstrand: thank you
<ackk> jdstrand, fwiw the openvswitch interface also grants that, so it could maybe be dropped from there?
<pedronis> zyga: ijohnson: #8258 needs your reviews
<mup> PR #8258: interfaces/kubernetes-support: allow autobind to journald socket <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8258>
<ijohnson> Yes it's on my list thanks pedronis
<pedronis> mvo: #8249 needs a master merge?
<mup> PR #8249: interfaces: make gpio robust against not-existing gpios in /sys <Reviewed> <Security-High> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8249>
<pedronis> pstolowski: #8235 probably also needs master merged in
<mup> PR #8235: cmd/snap-preseed: handle --reset flag <Preseeding ð> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8235>
<pstolowski> pedronis: ack, doing
<dot-tobias> zyga: hey there ð Short ping about https://bugs.launchpad.net/snapd/+bug/1844496/comments/8
<mup> Bug #1844496: âDevice or resource busyâ error during snap refresh when using layout with variable <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1844496>
<popey> mvo is something blocking an update to snapd in debian? I have snaps which cannot be installed because they need 2.43
<mborzecki> mvo: can you take a look at 8246?
<mvo> popey: nothing is blocking, I wanted to upload 2.44 once out (this week), re-exec should handle most cases though, I can put this on higher priority
<popey> Oh, debian has re-exec?
<mvo> mborzecki: yes, once the fires are out
<mvo> popey: yes, should be
<ijohnson> hey mvo!
<popey> ah okay. Is it locked to debian via os-release or somesuch?
<mvo> hey ijohnson, welcome back
<ijohnson> what's on fire today :-)
<popey> Because I have seen reports of outdated snapd on debian derivatives, which suggest they don't get re-exec
<mvo> popey: iirc yes, I don't remember the details
<jdstrand> mvo: this is the same bug we saw on trusty: snapd snap not getting pulled down
<popey> hm, ok
<mvo> popey: aha, interessting
<mvo> jdstrand: aha, ok
<popey> Seen it on the forums mentioned a bit
<mvo> popey: for some stuff we need an update
<mvo> popey: I will do a new upload
<popey> <3 thanks
<jdstrand> ackk: ok, yes, done
<jdstrand> ackk: (updated the PR)
<popey> e.g. snapctl is-connected is in 2.43, I would *love* that :D
<mvo> ijohnson: tests were failing left and right
<popey> I'll leave you alone, thanks mvo
<ijohnson> mvo: :-/ anything I should look at right away? I'm currently trying to triage all my notifications/PR requests and things
<mvo> ijohnson: that's fine, I think test are good again
<ijohnson> cool
<mborzecki> zyga: this is what i have https://paste.ubuntu.com/p/jXh8yNzGqQ/
<cjwatson> popey: Certainly works for me on Debian stable
<cjwatson> dpkg -l snapd says 2.37.4-1+b1, snap version says 2.43.3
<mborzecki> zyga: should I push a patch with policy update to your PR?
<pedronis> jdstrand: is #8269 meant for 2.45 or 2.44 ?
<mup> PR #8269: apparmor: use rw for uuidd request to default and remove from elsewhere <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8269>
<zyga> mborzecki: please!
<zyga> pedronis: ack, after lunch
<zyga> dot-tobias: replied
<dot-tobias> zyga: Thanks!
<mborzecki> zyga: hmm any clue why snapd would trigger this on remove? list_dirs_pattern(snappy_mount_t, snappy_var_lib_t, snappy_var_lib_t)
<mborzecki> list_dirs_pattern(snappy_mount_t, snappy_var_lib_t, snappy_var_lib_t)
<mborzecki> pff
<mborzecki> type=AVC msg=audit(1584364147.373:402): avc:  denied  { getattr } for  pid=2756 comm="snapd" path="/run/user/1000/snap.snap-store/dconf" dev="tmpfs" ino=63262 scontext=system_u:system_r:snappy_t:s0 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=dir permissive=1
<mborzecki> this ^^
<mborzecki> what's snapd doing with /run/user/<id>/snap.<snap> ?
<zyga> I don't know off hand
<zyga> but it is dconf
<zyga> perhaps that is managed by something (helpers or interface)
<pedronis> mborzecki: zyga: is simply space that we let the snap use afaict
<mborzecki> pedronis: that i know, but i'm wondering why we poke anything under /run/user/<uid>/snap.<snap>/ it when removing a snap
<mup> PR snapcraft#2975 opened: specifications: experimental features guidelines <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2975>
<pedronis> mborzecki: looking, one sec
<pedronis> mborzecki: yes, RemoveSnapCommonData removes filepath.Glob(snap.XdgRuntimeDirs()) afaict
<mup> PR core20#26 closed: Disable emergency.target & debug-shell, unless kernel cmdline is dangerous <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/26>
<mborzecki> pedronis: thanks!
<mup> PR snapd#8270 opened: store: support for search API v2 <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8270>
<mborzecki> ok, so that explains getattr (caused by globbing probbaly) and then unlinking
<mborzecki> zyga: couple more tweaks to the policy
<zyga> mborzecki: sure, I will check soon
<mborzecki> zyga: np, haven't pushed yet, want to make sure it builds on centos7 too
<mborzecki> there's some interfaces that may not be available there :/
<jdstrand> pedronis: 2.45
<jdstrand> pedronis: I mean, it could be 2.44, but I'm trying to actually let you release the thing :)
<jdstrand> pedronis: and nothing is actually broken, it is just noise
<jdstrand> (since fallback behavior allows things to work ok)
 * mvo had the same question
<jdstrand> the k8s one I did on friday though would be good to have in 2.44
<jdstrand> actually, I think it was thursday, but yeah
<mup> PR snapd#8258 closed: interfaces/kubernetes-support: allow autobind to journald socket <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8258>
<pedronis> jdstrand: I asked people to review the k8s one
<mup> PR snapd#8259 closed: interfaces/kubernetes-support: allow autobind to journald socket - 2.44 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8259>
<jdstrand> pedronis: I saw, thanks! :)
<ppd> @zyga: If you need a tester for https://bugs.launchpad.net/snapd/+bug/1866855, I'm in the office @ my nvidia machine
<mup> Bug #1866855: nvidia driver integration is incompatible with Debian <snapd:Triaged by zyga> <https://launchpad.net/bugs/1866855>
<ijohnson> pedronis: re the unit test you mentioned https://github.com/snapcore/snapd/pull/8228#discussion_r392221605 should I add that before we merge that?
<mup> PR #8228: boot,image: ARM kernel extract prepare image <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8228>
<pedronis> ijohnson: not particularly if it get green before, anyway I think we should do the todo as well
<ijohnson> ok
<pedronis> in a follow up
<zyga> ppd: thank you, I need to debug the issue first
<zyga> ppd: I have nvidia and debian at home
<zyga> ppd: I plan to switch to that soon
<mup> PR core20#25 closed: hooks/200-console-conf-after.chroot: perform console-conf ordering checks <Created by bboozzoo> <Merged by xnox> <https://github.com/snapcore/core20/pull/25>
<mborzecki> xnox: yay
<mup> PR snapcraft#2975 closed: specifications: experimental features guidelines <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2975>
<mup> PR snapd#8271 opened: interfaces: add hugepages-control <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8271>
<zyga> mvo: and now it is stuck on considering re-refresh
<zyga> and now it completed
<zyga> so on 2nd try it did towrk
<zyga> *did work
<mvo> zyga: so racy :(
<zyga> huh, but the snap change says it worked
<zyga> what?
<zyga> ah, no
<zyga> just lots of changes
<zyga> but I see the error
<mvo> zyga: could you attach it to the bug with the snapd logs please?
<mvo> zyga: both the bad and good case
<mvo> zyga: (if you haven't already)
<zyga> yeah
<zyga> done now
<zyga> looking at journal logs for more details
<zyga> mborzecki: ^
<zyga> gosh why doesn't launchpad do markdown
<zyga> and why does it wrap text
<zyga> I have 60%+ whitespace on my screen
<zyga> because LP wraps everything to 800x600 or something :/
<zyga> logs added
<zyga> mborzecki:
<zyga>  Mar 16 15:37:40 $HOSTNAME systemd[1]: snapd.service: Current command vanished from the unit file, execution of the command list won't be resumed.
<zyga> what the :) ?
<zyga> I'll switch gears to Debian now
<zyga> if you need anything just ping me please
<cachio> ijohnson, hey, this is the pr for the snapd.failure serivce #8252
<mup> PR #8252: tests: update test to make snapd snap fixed twice <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8252>
<cachio> if you want to add the fix there should be great
<zyga> mborzecki: how can I toggle gadget asset writes?
<zyga> er trigger
<mup> PR snapd#8272 opened: data/selinux, tests/main/selinux: cleanup tmpfs operations in the policy, updates <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8272>
<mborzecki> zyga: ^^
<zyga> looking
<zyga> and *thank you8
<zyga> * :)
<mborzecki> zyga: can you cherry pick the patch to your PR and see if it's ok now?
<zyga> mborzecki: sure
<zyga> first or both?
<mborzecki> zyga: i've only tried it locally with experimental.robust-mount-namespace-updates=true, the default ran on spread
<zyga> ok, I'll try
 * cachio lunch
<mborzecki> zyga: hm afaict that systemd line is because we replace the snapd service file, so the file on disk is no longer the same as it was when the service was started
<pedronis> mborzecki: what does command vanished though?
<pedronis> *mean
<zyga> Iâm helping with kids upstairs. Afk
<zyga> First few days are hard
<mup> PR snapcraft#2976 opened: cli: formalize developer debug as hidden build option <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2976>
<mborzecki> pedronis: afair from the last time we investigated this, this happens when there's a reload, systemd does serialze/deserialize sequence, and the service unit it serialized does not match the one that was read again from disk
<mborzecki> pedronis: though in the case of this bug, the problem appears to be elsewhere imo
<ijohnson> mvo: I looked into extracting just the bit from #8169 that drops RemainsAfterExit=true from snapd.failure.service, but that requires a bit of tests changes that would also need to be pulled out
<mup> PR #8169: tests/many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8169>
<ijohnson> mvo: I can certainly pull those out into a PR if you like, but it may be easier to just review the PR as it is IMHO
<mborzecki> pedronis: zyga: it unexpectedly exits with an error when a restat was requested: Mar 16 12:50:29 $HOSTNAME snapd[680]: cannot run daemon: context deadline exceeded
<ijohnson> let me know how you want to procee
<ijohnson> d
<mborzecki> whgat triggers the rollback
<mborzecki> pedronis: zyga: afaict this is caused by a graceful shutdown of the snapd.socket ?
<mborzecki> 	d.tomb.Kill(d.serve.Shutdown(ctx))
<zyga> mborzecki: I don't know w
<zyga> I have my laptop upstrairs and will try to resume work
<pedronis> mborzecki: what has changed in this area though ?
<mborzecki> pedronis: in that particular daemon shutdown code nothing spectacular, last change was in june 2019
<zyga> I think maciek had a good hunch
<zyga> the device agent is poking snapd api
<zyga> so it may be interacting with snapd as it shuts down
<zyga> we may need the /etc/nologin equivalent for the API
<pedronis> but we close our sockects
<pedronis> before getting there
<zyga> are we closing the snapd.socket?
<zyga> as in
<zyga> are we preventing socked-based activation?
<zyga> we may shut ourselves down
<zyga> but unless we do it in a way that doesn't disable activation
<mborzecki> pedronis: so looking at http.Server.Shutdown(), it loops waiting for all connections to become idle
<pstolowski> pedronis: #8264 can land
<mup> PR #8264: many: introduce snapdenv to present common snapd env options <Created by pedronis> <https://github.com/snapcore/snapd/pull/8264>
<zyga> it may be that a constant ping is enough to break frefresh
<mup> PR snapcraft#2977 opened: cli: merge build options into provider options <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2977>
<zyga> *refresh
<mborzecki> heh, more, the shutdown timeout we use is 25s, the logs are 25s apart :P
<mborzecki> Mar 16 12:50:04 $HOSTNAME snapd[680]: daemon.go:539: done waiting for running hooks
<mborzecki> Mar 16 12:50:29 $HOSTNAME snapd[680]: cannot run daemon: context deadline exceeded
<pedronis> are we seeing snapd restarts in the middle though?
<pedronis> anyway at that point we closed the sockets but are still running
<pedronis> so systemd shouldn't start a new version of snapd
<pedronis> afaiu
<mborzecki> pedronis: but there's a failure instead of clean restart
<pedronis> mborzecki: this means that some handler is taking very long
<pedronis> I think
<mborzecki> pedronis: api endpoint handler right?
<mborzecki> pedronis: what if a client is slow to receive the response, would it look the same?
<pedronis> yes, or something is keeping a connection alive
<pedronis> but I think Shutdown deals with that
<pedronis> (our old code did)
<pedronis> I can double check for the latter
<mborzecki> pedronis: we use the stdlib now, and run it with a context.WithTimer()
<mborzecki> when it times out, the error becomes tomb status, and the core that runs later returns that as an error
<mborzecki> maybe we should just suck it up if it's a timeout and exit
<zyga> I switched the machine on
<zyga> checking for changes
<zyga> there are changes of the sort "Running service command for snap ..."
<zyga> and that has tasks that ... install snapd?
<zyga> ah, sorry no
 * zyga there are commands but they restart a service of another snap
<mborzecki> zyga: i think you need SNAPD_DEBUG=1 to see if anything is poking the api
<zyga> aha
<zyga> mborzecki: done, I will watch the log
<zyga> snapd.failure.service failed on the first restart
<zyga> cmd_snapd.go:136: restarting snapd socke
<zyga> error:
<zyga> -----
<mup> PR snapd#8273 opened: interfaces/greengrass-support: add new 1.9 access <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8273>
<zyga> Job for snapd.socket failed.
<zyga> See "systemctl status snapd.socket" and "journalctl -xe" for details.
<zyga> fun
<pedronis> mborzecki: took a while but, no, the stdlib code doesn't let reuse a connection once in shutdown
<zyga> then
<zyga> snapd.socket: Socket service snapd.service already active, refusing.
<zyga> Failed to listen on Socket activation for snappy daemon.
<pedronis> mborzecki: so it would be a handler<->client taking too long
<pedronis> mborzecki: ignoring the timeout is what we do with RestartSystem btw
<mup> PR snapd#8274 opened: interfaces/greengrass-support: add new 1.9 access (2.44) <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8274>
<mborzecki> pedronis: right, but we only refresh snapd here, so a simple restart
<pedronis> yea
<mborzecki> hm maybe we should ungracefully call d.serve.Close() when timeout occurred
<pedronis> mborzecki: it's the reserve we close the socked below the server ourselves
<pedronis> before
<mup> PR snapd#8264 closed: many: introduce snapdenv to present common snapd env options <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8264>
<pedronis> pstolowski: thanks,  I'll work on snapdenv.Preseeding next (I'll probably rename PreseedMode to Preseeding in places)
<pstolowski> pedronis: great, ty
<mup> PR snapd#8235 closed: cmd/snap-preseed: handle --reset flag <Preseeding ð> <Squash-merge> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8235>
<pedronis> mvo: ^ that was still targeted for 2.44
<pedronis> mborzecki: anyway doing what we do for a system restart seems neccesary, otoh it would still be good to understand what is blocking us for 25s
<zyga> mvo: I remembered the gpg key :D
<mup> PR snapd#8275 opened: daemon: do a forceful serer shutdown if we hit a deadline <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8275>
<mborzecki> pedronis: we could try something like this ^^^
<mborzecki> anyways, need to go, kids got their homework, since the school is in lockdown it's e-learning now ;)
<mvo> zyga: yay!
<mvo> pedronis: yeah, 8235 looks sane for 2.44, no?
<pedronis> mvo: yes
<zyga> I've pushed my keys to debian and ubuntu
<zyga> whee
<pedronis> mvo: needs to be cherry picked
<zyga> I'm so happy
<mvo> pedronis: will do in a sec
<mvo> pedronis: thanks, cherry picked now
<mup> PR snapd#8276 opened: snap: whitelist lzo as support compression for snap pack <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8276>
<mup> PR snapd#8277 opened: asserts,o/devicestate: support model specified alternative serial-authority <Created by pedronis> <https://github.com/snapcore/snapd/pull/8277>
<mup> PR snapd#8278 opened: devicestate: disable cloud-init by default on uc20 <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8278>
<pedronis> mvo: left some comments ^
<pedronis> it's almost dinner for me
<mvo> pedronis: thanks \o/ ! checking
<cachio> mvo, I made uc20 tests work on nested vm
<cachio> so no hurry with cloud init
<mvo> cachio: !!! how did you do that? amazing \o/
<ijohnson> cachio: nice
<cachio> mvo, small change on how we modify snapd snap to use the current branch
<cachio> mvo, cmatsuoka helped a lot on the process
<cachio> I'll add some tests to the branch and pushed again
<mvo> thanks cachio and cmatsuoka
<cachio> mvo, just a clarification, uc20 works but still the secure boot is not ready on the machine
<cachio> so the test which checks the secure boot is currently failing
<cachio> but we can boot and check uc on a nested vm with all the tpm machinery
<cmatsuoka> cachio did all the stuff, I just tried to boot his images here
<cachio> when cmatsuoka branch is landed, that test should pass
<mvo> cachio: nice!
<mvo> cmatsuoka: and nice job of you too
 * mvo hugs cachio and cmatsuoka (totally virus safe!)
<cachio> hehehe
<cachio> virtual hugs
<mup> PR snapd#8279 opened: snap: do not hardlink on overlayfs <Created by mvo5> <https://github.com/snapcore/snapd/pull/8279>
<mup> PR snapd#8249 closed: interfaces: make gpio robust against not-existing gpios in /sys <Reviewed> <Security-High> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8249>
<ijohnson> cachio: cmatsuoka: which branch should I take a look at to enable uc20 nested tests ?
<mup> PR snapd#8280 opened: many: introduce snapdenv.Preseeding instead of release.PreseedMode <Created by pedronis> <https://github.com/snapcore/snapd/pull/8280>
<mup> PR snapcraft#2978 opened: tests: add microk8s spread test <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2978>
<cmatsuoka> ijohnson:  I was using sergio's tests-enable-nested-on-core20 branch
<ijohnson> cmatsuoka: is there a PR open for that?
<cmatsuoka> cachio: ^^
<cmatsuoka> ijohnson: I think sergio opened it last friday
<ijohnson> I'll take a look
<ijohnson> looks like https://github.com/snapcore/snapd/pull/8260 is the branch
<mup> PR #8260: tests: enable nested on core20 and test current branch <â Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8260>
<ijohnson> err PR
<cmatsuoka> I see I have pending comments there
<mup> PR snapcraft#2979 opened: tests: add multipass adhoc spread backend <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2979>
<mup> PR snapcraft#2980 opened: vcs: add direnv files to .gitignore <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2980>
<popey> wgrant i have another snap which seems to be randomly using snapcraft deb rather than snapcraft snap in build.snapcraft.io :S
<popey> https://launchpadlibrarian.net/469283263/buildlog_snap_ubuntu_bionic_s390x_f575d29e94f650a871d01c059930838d_BUILDING.txt.gz
<popey> sergiusens have you seen this happening in lp? ^
<sergiusens> popey: what triggered this build?
<sergiusens> popey: using the wrong snapcraft is sort of out of my hands
<sergiusens> unless it is remote-build
<sergiusens> if it is build.snapcraft.io triggered, we need to ask Lukewh and verify that they are inadvertingly setting the "snap" fields
<popey> it says build trigger unknown
<popey> we have a few threads on the forum about it now
<sergiusens> popey: seems it is build.snapcraft.io https://launchpad.net/~build.snapcraft.io/+snap/f575d29e94f650a871d01c059930838d/
<popey> what would cause this though?
<popey> wonder if it's the new build button
<sergiusens> popey: well if you are using something new, yeah, most likely, specially since it sends a call to the launchpad APIs, this is where you can incorrectly be setting to NOT use the snap
<cjwatson> popey: Has anyone filed a bug against LP about this yet?
<popey> no because we couldn't figure out where the bug should be
<cjwatson> I don't think it can be a BSI bug
<cjwatson> We haven't figured out what's going on, but it's currently hard to see how it could be outside Launchpad (much though I'd like that to be the case)
<popey> where should I file a bug?
<sergiusens> cjwatson: well, the webteam (I just learned) added a new "build" button which might be calling the api and setting the snap fields incorrectly
<cjwatson> popey: https://bugs.launchpad.net/launchpad
<sergiusens> cjwatson: would be nice to have launchpad show that info in the logs, I can log a bug about just that :-)
<cjwatson> sergiusens: On build.snapcraft.io?  I don't see a recent change like that in its repository
<cjwatson> sergiusens: It kind of does if you know how to read it :)
<sergiusens> popey: where is this new build button
<cjwatson> sergiusens: Or maybe I'm misunderstanding what info you're talking about
<popey> login to the store, any snap page and you'll see a new tab next to Listing
<cjwatson> Oh, that's been rolled out has it?
<popey> yes
<cjwatson> That would be the obvious recent change then I suppose
<sergiusens> cjwatson: in .requestBuild you can pass a "channels" dict or snaps as keys, channels as values. This is what I suspect is incorrectly being set
<cjwatson> sergiusens: Yes but LP is supposed to infer that itself in the case of bases
<sergiusens> *dict with
<cjwatson> I know about the requestBuild(s) API :)
<popey> https://bugs.launchpad.net/launchpad/+bug/1867689
<mup> Bug #1867689: snap builds via bsi use the deb rather than snap of snapcraft <Launchpad itself:New> <https://launchpad.net/bugs/1867689>
<cjwatson> Thanks - we can redirect if that turns out to be the wrong place
<sergiusens> cjwatson: I know you do, I was just trying to be specific of what my thought was on why it could have started failing
<cjwatson> If nothing else we could use some better debugging information in our own logs
<cjwatson> (internally)
<cjwatson> sergiusens: Right, I agree it's a candidate place for things to go wrong, I just haven't been able to work out how that could concretely happen from the code flow
<cjwatson> I'll have a look at the new web team changes as soon as I can find where the backend bits for it life
<cjwatson> *live
<cjwatson> Oh
<cjwatson> Hahaha
<cjwatson> You may be right
<cjwatson>         data = {
<cjwatson>             "ws.op": "requestBuilds",
<cjwatson>             "channels": "snapcraft,apt",
<cjwatson> Why
<cjwatson> sergiusens: So yeah, sorry, I didn't expect that they'd have specifically gone out of their way to override this wrongly :-/
<sergiusens> hah
<popey> oopsie
<cjwatson> Filing a bug
<popey> thanks cjwatson
<mup> PR snapd#8228 closed: boot,image: ARM kernel extract prepare image <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8228>
<cjwatson> https://github.com/canonical-web-and-design/canonicalwebteam.launchpad/issues/13
<cjwatson> Glad to have found that, that was super-puzzling this morning
<popey> heh
<mup> PR snapcraft#2981 opened: colcon plugin: rewrite poco absolute library paths <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2981>
<nottrobin> thanks for the bug cjwatson. I'll chase it up tomorrow.
#snappy 2020-03-17
<mborzecki> morning
<mborzecki> zyga: hey, have you tried #8272 with #8089?
<mup> PR #8272: data/selinux, tests/main/selinux: cleanup tmpfs operations in the policy, updates <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8272>
<mup> PR #8089: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089>
<zyga> good morning
<zyga> mborzecki: I did
<zyga> mborzecki: I ran a local test and it passed
<zyga> I pushed the update to GH
<zyga> haven't looked since
<mborzecki> cool
<zyga> man, my dog decided to do a marathon this morning
<zyga> we woke up at 6:30
<zyga> and I took him for a walk because Iza was sleepy
<zyga> and I just got back
<mborzecki> nice
<zyga> I left my coffee in the office and now it's cold :)
<zyga> on the up side it is lovely outside
<mborzecki> chance to get another one ;)
<zyga> I need to charge my mouse, it ran out
<zyga> time for that coffee I guess
<zyga> mborzecki: yeah, it is green
<mborzecki> yay
<zyga> mborzecki: please review 8089 :)
<zyga> or just leave a comment
<zyga> I think we should get it for 2.44
<zyga> though I see it's marked for 2.45
<zyga> but I think only because it was red
<zyga> I'll talk to mvo
<zyga> mborzecki: btw, did you read about the new x13, t14, t14s and t15?
<zyga> mborzecki: lenovo's new lineup of thinkpads
<mborzecki> new thinkpads?
<zyga> based on both 10th gen intel and ... 4th gen mobile ryzen :)
<zyga> and
<zyga> you won't believe this :)
<zyga> the ryzen parts have longer battery life
<zyga> 17.5h vs 17h intel
<zyga> how the world has changed
<mborzecki> hopefully they work better than the previous mobile lineup
<zyga> x13 touts 8 core, 16 thread 32GB monster
<mborzecki> people complained about the drivers and overall stability
<zyga> and it has rather superb GPU for a x13-like box
<zyga> time will tell
<zyga> I wonder what they will do with naming though
<zyga> will next year model be called just x113
<zyga> and then x213
<zyga> ok, mouse is charged now
<zyga> oh, it seems there's also x13s
<zyga> I will probably skip it as 16" is just superb and I rarely think about the thikpad now
<zyga> but perhaps the next year refresh will go to the update of the linux-running laptop
<zyga> I kind of want the x13 with +1 gen mobile ryzen
<zyga> that has ray tracing acceleration
<zyga> as I bet that the other life of that machine will be minecraft RT
<zyga> ok, let's look at PRs
<zyga> mborzecki: do you think https://github.com/snapcore/snapd/pull/8265 should be merged
<mup> PR #8265: tests: add regression test for MAAS refresh bug <Created by zyga> <https://github.com/snapcore/snapd/pull/8265>
<zyga> or skipped
<mborzecki> hm still drivers are key, hopefully they have resource to make linux support great
<zyga> it's probably a "heavy" test
<zyga> mborzecki: yeah, it's a big mystery as to how this works on linux
<mborzecki> last mobile apu lineup ha bad support even on windows
<zyga> mborzecki: I was briefly considering not putting linux on it as well
<zyga> mborzecki: and tie this with WSL2 release in 2004
<zyga> (2004 as in windows 10 version)
<mborzecki> idk if i want to trade one broken system for another ;)
<zyga> are you sure?
<zyga> have you seen it
<zyga> it's pretty remarkable
<zyga> say what you want but the chance that suspend and wifi works ok on windows is pretty much close to 100%
<zyga> I think it will be the next battleground, what works best in WSL2
<zyga> I really think snapd should be a prime contender there
<mborzecki> hm occasionally play witcher 3 on windows, kinda works, but there's tiny little details that could be improved
<mborzecki> for one, getting my bt headphones connected is way easier with bluez & pa than on windows xD
<mborzecki> or prehaps sony makes crap headphones that only work great with smartphones
<zyga> mborzecki: I think you have to think wider
<zyga> not use windows for witcher :)
<zyga> mborzecki: use it for the witcher _and_ for work
<zyga> for snapd
<zyga> for hangouts
<zyga> and see how that behaves
<zyga> what's the experience of ubuntu on windows
<zyga> I also think desktop vs laptop is key
<mborzecki> haha no i'm too far gone
<zyga> laptops are the majority of sold devices and, historically, those that struggle more on linux
<zyga> are you sure, you might just like it :)
<zyga> my point is, keep an open head
<zyga> people will use WSL2
<zyga> it will explode
<zyga> it will have more users than all non-virtual linux combined
<zyga> and many times over
<zyga> we should provide a great experience there
<zyga> hard to know unless we try
<zyga> mborzecki: and I'm not saying we should all switch to it entirely
<zyga> just add it to the pool of thins we consider
<zyga> mvo: hey
<zyga> mvo: https://github.com/snapcore/snapd/pull/8279 is LGTM
<zyga> I marked it as 2.44
<mup> PR #8279: snap: do not hardlink on overlayfs <Bug> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8279>
<zyga> I think we haven't released it yet, right?
<mborzecki> mvo: hey, 8272 is also marked for 2.44, be great to include it
<mvo> zyga, mborzecki good morning
<mvo> thanks guys, looking over the 2.44 stuff now
<zyga> mvo: oh, one more thing
<zyga> mvo: can we please reconsider https://github.com/snapcore/snapd/pull/8089 as 2.44
<mup> PR #8089: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089>
<zyga> it's flipping the robust ns switch
<zyga> and it should just go out already
<mvo> zyga: let's talk with samuele, a bit worried that it makes it very late into 2.44 so we won't spot regression that easily (and then it's on the 20.04 cd)
<mup> PR snapd#8279 closed: snap: do not hardlink on overlayfs <Bug> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8279>
<mup> PR snapd#8281 opened: snap: tweak comment in Install() for overlayfs detection <Simple ð> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8281>
<mvo> mborzecki: did you push the 1.10 formating changes to whitelist-lzo on purpose?
<mborzecki> mvo: yues
<mvo> mborzecki: some unhappy static test there or what's the reason?
<mvo> mborzecki: aha, I see now
<mvo> mborzecki: it looks like the static test failure is a red-herring, there is a real unit test issue it seems that I overlooked
<mvo> mborzecki: in TestPackPacksASnapWithCompressionUnhappy
<mborzecki> heh, missed that
<mvo> mborzecki: no worries
<mvo> mborzecki: I fixed and force pushed
<mvo> mborzecki: I often wondered why the go test output we have is so unreadable :(
<mborzecki> mvo: ta
<mvo> mborzecki: but never had enough energy to look
<mvo> mborzecki: like, when a unit test in the middle fails it's really hard to spot
<mborzecki> mvo: yeah, it's a wall of text
<pstolowski> morning
<mborzecki> pstolowski: morning, may i entertain you with a review https://github.com/snapcore/snapd/pull/8272
<mup> PR #8272: data/selinux, tests/main/selinux: cleanup tmpfs operations in the policy, updates <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8272>
<mborzecki> it's green and ripe for landing ;)
<pstolowski> mborzecki: looking
<zyga> mvo: we could test without -verbose
<zyga> hey pawel :)
<mborzecki> pstolowski: thanks!
<mvo> zyga: interessting, yeah, I think that helps a bit
<mup> PR snapd#8282 opened: run-tests: disable -v for go test to avoid spaming the logs <Simple ð> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8282>
<mup> PR snapd#8273 closed: interfaces/greengrass-support: add new 1.9 access <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8273>
<mup> PR snapd#8274 closed: interfaces/greengrass-support: add new 1.9 access (2.44) <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8274>
<mup> PR snapd#8272 closed: data/selinux, tests/main/selinux: cleanup tmpfs operations in the policy, updates <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8272>
<mborzecki> yay
<mborzecki> mvo:  can you cherry pick the patches from 8272 to 2.44?
<mvo> mborzecki: yes, just did that, thank you!
<mborzecki> mvo: thanks!
<mvo> mborzecki: once you see samuele, we need a review for 8275, I would love to include that too
<mborzecki> mvo:  i want to add a unit test there too
<mup> PR snapd#8217 closed: o/devicestate: delay the creation of mark-seeded task until asserts are loaded <Bug> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8217>
<mup> PR snapd#8246 closed: client, daemon, overlord/devicestate: structures and stubs for systems API <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8246>
<mup> PR snapd#8283 opened: overlord,timings,daemon: separate timings from overlord/state <Created by pedronis> <https://github.com/snapcore/snapd/pull/8283>
<mborzecki> wow, our daemon tests setup is complicated
<cjwatson> nottrobin: thanks!
<pstolowski> pedronis: #8280 +1, thank you!
<mup> PR #8280: many: introduce snapdenv.Preseeding instead of release.PreseedMode <Created by pedronis> <https://github.com/snapcore/snapd/pull/8280>
 * zyga is not feeling very good today and will focus on reviews 
<zyga> at least for a while
<mvo> pedronis: if you have a chance, could you please check https://github.com/snapcore/snapd/pull/8275 ?
<mup> PR #8275: daemon: do a forceful server shutdown if we hit a deadline <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8275>
<pedronis> mvo: yes, it was one of the first things I wanted to look at today
<mup> PR snapd#8280 closed: many: introduce snapdenv.Preseeding instead of release.PreseedMode <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8280>
<pedronis> pstolowski: thx for the review, I also made this: https://github.com/snapcore/snapd/pull/8283 bit annoying
<mup> PR #8283: overlord,timings,daemon: separate timings from overlord/state <Created by pedronis> <https://github.com/snapcore/snapd/pull/8283>
<pstolowski> pedronis: yes, i'll review it soon
<ackk> zyga, hi, I just got this error: https://paste.ubuntu.com/p/pv3MQwTGTk/ with robust namespaces on. not sure if it's the same issue as before
<zyga> hmm
<zyga> it is a different issue
<zyga> not device or resource busy (removing a mount point)
<ackk> zyga, trying again (the snap is still there) I get: https://paste.ubuntu.com/p/nTZvF7s6mq/
<zyga> do you have instructions to reproduce
<zyga> the mount system is not perfect, there are known limitations that end up with things like that
<ackk> zyga, well, I just had a maas snap installed via "snap try" and tried to remove it
<zyga> ackk: can you try (as in wipe and try again) to see if it happens
<ackk> zyga, you mean reproduce from a clean state?
<zyga> yes please
<zyga> if it is reproducible that's awesome
<ackk> zyga, I'll try
<ackk> zyga, how do I get out of this situation though? I'd need to remove the maas snap
<ackk> shoulld I just reboot?
<ackk> *should
<zyga> discard the ns
<ackk> ah yeah that worked thanks
<ackk> zyga, clean bionic container: https://paste.ubuntu.com/p/PBVtYywcJF/
<zyga> thanks, I'll jump into it after today reviews
<ackk> zyga, you want me to file a bug or are you ok with just the paste?
<zyga> a bug is best
<zyga> those regression/lp- things are great way to organize things like that
<pedronis> mborzecki: hi, +1 on 8275 with some suggestions
<mborzecki> pedronis: thanks!
<mup> PR snapcraft#2976 closed: cli: formalize developer debug as hidden build option <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2976>
<mup> PR snapcraft#2981 closed: colcon plugin: rewrite poco absolute library paths <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2981>
<ackk> zyga, https://bugs.launchpad.net/snapd/+bug/1867752
<mup> Bug #1867752: Unable to remove snap with content interface (with robust namespace on) <snapd:New> <https://launchpad.net/bugs/1867752>
<zyga> snapd in focal fails to build with unit test error
<ackk> zyga, sparkiegeek added some extra info to that bug, FTR
<sparkiegeek> right, specifically output with SNAPD_DEBUG=1
<sparkiegeek> but that was after attempting the initial removal (install, remove, set debugging, reload snapd, remove again)
<zyga> filed https://bugs.launchpad.net/snapd/+bug/1867755 if someone wants to dig
<mup> Bug #1867755: snapd fails to build in focal, unit test clientSuite.TestClientFindFromPathErrIsWrapped fails <snapd:New> <https://launchpad.net/bugs/1867755>
<zyga> thanks, ackk, sparkiegeek: I will look at that soon
<sparkiegeek> zyga: thanks!
<ackk> zyga, ty
 * zyga has some annoying back pain all morning :/ 
<zyga> pleas forgive me if I'm somehow grumpy
<pedronis> mborzecki: when you have a moment can you do a first pass #8159 as well
<mup> PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
<mborzecki> pedronis: sure, will do
<mup> PR snapd#8281 closed: snap: tweak comment in Install() for overlayfs detection <Simple ð> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8281>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8275/files is really interesting (the test)
<mup> PR #8275: daemon: do a forceful server shutdown if we hit a deadline <Squash-merge> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8275>
<zyga> abeato: reviewed https://github.com/snapcore/snapd/pull/8271#pullrequestreview-375973389
<mup> PR #8271: interfaces: add hugepages-control <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8271>
<abeato> zyga, cool, thanks
<mup> PR snapd#8276 closed: snap: whitelist lzo as support compression for snap pack <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8276>
<pstolowski> mvo: #8251 has a conflict
<mup> PR #8251: overlord: remove unneeded overlord.MockPruneInterval() mocks <Created by mvo5> <https://github.com/snapcore/snapd/pull/8251>
<mvo> pstolowski: thanks, will fix
 * zyga did some stretching and feels less pain :)
<mup> PR snapd#8268 closed: snap-seccomp: robustness improvements <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8268>
<mup> PR snapd#8282 closed: run-tests: disable -v for go test to avoid spaming the logs <Simple ð> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8282>
<ijohnson> hi folks
<zyga> hey ian
<ijohnson> hey zyga
 * zyga installs debian on metal
<mup> PR snapcraft#2974 closed: project_loader: use -isystem instead of -I for system include paths <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2974>
<zyga> ackk: hey, can you tell my why maas puts a layout on /root ?
<ackk> zyga, so ssh can find authorized_keys
<zyga> ssh?
<zyga> does maas bundle ssh?
<ackk> zyga, yes (the client)
<zyga> aha
<zyga> hmmm
<zyga> I mean
<zyga> that ssh goes into maas
<zyga> not into the host, right?
<mup> PR snapcraft#2978 closed: tests: add microk8s spread test <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2978>
<mup> PR snapcraft#2979 closed: tests: add multipass adhoc spread backend <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2979>
<mup> PR snapcraft#2980 closed: vcs: add direnv files to .gitignore <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2980>
<ackk> zyga, maas uses ssh to connect to remote virsh
<zyga> I see
<zyga> and there's no way to say, hey, ssh, pick those keys?
<zyga> I mean
<zyga> layout over /root feels a bit too powerful
<zyga> not that it buys you anything
<zyga> but it's a bit weird too
<ackk> zyga, no, ~/.ssh is hardcoded
<ackk> (I would think for security purposes)
<zyga> ah
<zyga> can you put a layout over /root/.ssh
<zyga> would be cleaner IMO
<ackk> zyga, why powerful? it's not exposing the host /root, it's putting a dir over /root
<ackk> the snap container one
<zyga> powerful in the sense that is has broad effect for the app
<zyga> it's not a security issue
<ackk> zyga, sure, but that's kinda intended
<ackk> zyga, is this causing issues with snapd?
<ackk> zyga, I mean, would it be different if we changed the overlay?
<zyga> yes
<zyga> but that's a real bug I will fix anyway
<zyga> it just happens to happen that this causes a bug :)
<zyga> I will have details soon
<zyga> and a fix
<zyga> I was mostly curious about /root,
<ackk> zyga, cool
<zyga> ackk: in addition I would suggest using $SNAP_COMMON
<zyga> otherwise each revision has lots of mount changes for that
<zyga> but it's not cancelling that two other layouts so perhaps not that important
<zyga> as you wish
<ackk> zyga, ah I see
<sparkiegeek> Lukewh:
<sparkiegeek> bah
<Lukewh> bah to you too
<ackk> lol
<zyga> ackk: https://bugs.launchpad.net/snapd/+bug/1867752/comments/6
<mup> Bug #1867752: Unable to remove snap with content interface (with robust namespace update) <snapd:In Progress by zyga> <https://launchpad.net/bugs/1867752>
<zyga> we should really run *all* tests in lxd
<zyga> eh
<ackk> zyga, thanks. great that you found the source of the issue
<ackk> zyga, why does LXD make a difference in this case?
<zyga> ackk: as I indicated, because the filesystem type for snaps is no longer squashfs but fuse
<ackk> oh, I missed that detail, I see
<zyga> thank you for this bug report
<zyga> it's a great find
<zyga> I think this never worked correctly
<zyga> to the extent that all the squashfs checks were moot
<ackk> it'd be great if lxd could passthrough kernel modules to containers, so that they could use proper squashfs
<zyga> ackk: it's not that
<zyga> ackk: containers cannot mount things because that's really the kernel mounting things
<zyga> ackk: so containers could attack all FS code
<zyga> and that's considered unsafe
<ackk> I see
<zyga> I would love if lxd had some magic where it could identify squashfs that is signed and trusted (fs_verity maybe) and allow mounting that
<zyga> stgraber: ^ maybe crazy idea
<stgraber> the problem is that if the user has access to the underlying file, they can still mess with it while the kernel has it mounted
<stgraber> so us doing any kind of hashing would just be a TOCTOU race
<stgraber> and dm-verity on loop would similarly only really be trustable if there was no way for root in the container to modify the file that's assigned to the loop
<zyga> stgraber: indeed, that's true
 * zyga breaks for lunch
<alvesadrian> hello guys
<alvesadrian> since snap
<alvesadrian> is an squashfs
<alvesadrian> means read only
<alvesadrian> how u can write data on it?
<alvesadrian> I hafe a case where i need to write data afer install in conf files of the snap
<alvesadrian> user data
<alvesadrian> how this can be orted if snap is an squashfs?
<alvesadrian> there is a way to sort this out???
<ijohnson> hey cachio, have you had a chance to look at https://github.com/snapcore/snapd/pull/8169 ?
<mup> PR #8169: tests/many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8169>
<alvesadrian> maxiberta ping
<cachio> ijohnson, I'l do it now
<ijohnson> thanks cachio
<ogra> alvesadrian, snaps have two dirs they can always write to ... these are defined in the SNAP_DATA (root/services) and SNAP_USER_DATA (enduser) environment variables
<zyga> alvesadrian: you have $SNAP_DATA and $SNAP_USER_DATA
<zyga> alvesadrian: and $SNAP which is what you ship in the package
<alvesadrian> the problem is
<ogra> alvesadrian, just make sure your snap writes to the respective dir
<zyga> alvesadrian: the data things are not immutable
<alvesadrian> the app is a java app
<alvesadrian> and sometimes need to write war files jar files
<ogra> there are many snapped java apps
<zyga> alvesadrian: you can write those to $SNAP_DATA
<zyga> alvesadrian: I explained this last week, you cannot modify the $SNAP in any way apart from shipping an update of the pacakge
<ogra> well, then write them to a writable dir and make sure to also read them from there
<zyga> alvesadrian: so either disable the self-update and use snapd to update
<zyga> alvesadrian: or use $SNAP_DATA as a writable space for the things you download
<zyga> mvo: we fail to build for s390x: Failed to fetch stage packages: Error downloading packages for part 'mokutil': The package 'libefivar-dev' was not found..
<zyga> sorry, this was for ppcel64
<xnox> zyga:  well, mkutil only makes sense on arm64 & amd64
<xnox> *mokutil
<xnox> zyga:  as neither s390x nor ppc64el use UEFI with Shim and MokManager
<ogra> only i you use secureboot anyway, no ?
<ogra> *fi
<ogra> bah
<zyga> yeah
<ogra> *if
<xnox> ogra:  unrelated to secureboot, people can use mokmanager without secureboot
<ogra> to manage what ?
<ogra> modules ?
<xnox> ogra:  and we do have secureboot on s390x and ppc64el without uefi
<xnox> ogra:  to manage keys
<ogra> ah, k
<xnox> ogra:  MokManager => machine owner key
<ogra> (i thought it only signs unsigned modules)
<xnox> ogra:  it doesn't even do that
<ogra> oh
<xnox> ogra:  it only manages a keyring of keys that shim may use to validate stuff.
<xnox> in an UEFI environment.
<ogra> <-- full of ignorance when it comes to secureboot on non-armhf systems :)
<xnox> private key should be stored/handled externally
<mvo> zyga: do you have a url for me?
<mvo> zyga: I don't remember us adding these dependencies
<diddledan> U. E. F. I. ting tang walla walla bing bang.
<diddledan> U. E. F. I. ting tang walla bing bang!
<zyga> yeah AH
<zyga> mvo: sorry that's a test snap
<zyga> https://launchpad.net/~snappy-dev/+snap/test-snapd-mokutil/+build/871766
<zyga> alvesadrian: does what we say make sense to you?
<alvesadrian> zyga
<ijohnson> mvo: #8169 is merged now, shall I open an equivalent PR to 2.44, even if just for a possible 2.44.1 ?
<mup> PR #8169: tests/many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8169>
<mup> PR snapd#8169 closed: tests/many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8169>
<zyga> ackk: I tentatively fixed it now
<ackk> zyga, awesome
<mvo> ijohnson: for a possible 2.41 and it would be nice to see if it also fixes sergios 2.44 issue
<mvo> ijohnson: possible 2.44.1
<mvo> ijohnson: there will be one
<ijohnson> sure I will open the PR now then
<mvo> ijohnson: for the search v2 api
<mvo> ijohnson: \o/
<mvo> zyga:  google:ubuntu-20.04-64:tests/main/snap-confine-undesired-mode-group :  fails, is that something you might know about? full log in https://api.travis-ci.org/v3/job/663438502/log.txt
<alvesadrian> zyga PM
<zyga> yeah
<zyga> mvo: looking
<zyga> mvo: ah, interesting
<zyga> so spawning a user session and leaving it behind is a bad idea
<zyga> mvo: this just tells us that there's a user logged
<zyga> specifically test
<zyga> and that it has lingering stuff
<zyga> mvo: is that failing reliably or is that some leftover from a prior test
 * zyga looks what ran before
<mvo> zyga: only saw it now for the first time
<zyga> mvo: ok
<zyga> mvo: what I learned while working on session-tool
<zyga> mvo: is that session cleanup is async
<zyga> mvo: so none of our tests synchronize against that (except for the test for session-tool)
<zyga> mvo: I guess restore-each should do something like this:
<zyga> https://github.com/snapcore/snapd/blob/master/tests/main/session-tool/task.yaml#L16
<zyga> mvo: we can later drop that once we transition everything over from su - ... test
<zyga> to session-tool
<zyga> *and* have a restore section much like this one in said tests
<mvo> zyga: ok, this sounds like I can merge this pr desite the test failure?
<zyga> yeah
<zyga> I would also say that kill-user is not enough
<zyga> because that will just kill the proceses
<zyga> cgroup cleanup is another async step after that
<zyga> it's a sad sad sad thing but reality
<zyga> this is in scope for my work on session-tool and fixes for the pending tracking branch
<zyga> I will write this down to fix
<mvo> zyga: ta
<mvo> mborzecki: I will squash merge 8275, any specific commit message you want there?
 * ijohnson should have squash-merged 8169 :-(
<zyga> I need to run an errand
<zyga> ttyl
<mup> PR snapd#8275 closed: daemon: do a forceful server shutdown if we hit a deadline <Squash-merge> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8275>
 * cachio lunch
 * ijohnson -> lunch
<mvo> pedronis: I created a snapd-ssl-certs update with the snap revert test we talked about and as predicted it hits the "on-revert-we-don't-run-configure-hook" bug. do you have some ideas about how the fix could look like? mostly wondering, I can dig myself, just finished the test
<pedronis> mvo: interesting, I thought we run configure hook, it probably doesn't do the correct thing?
<pedronis> mvo: can you confirm if we don't run it? or we run it but is not doing something sensible?
<pedronis> anyway I would need to look at the code a bit to make a suggestion
<ogra> diddledan, https://bugs.launchpad.net/bugs/1863904 ...
<mup> Bug #1863904: Gimp 2.10 snap doesn't start, and you can't even reinstall it. <amd64> <apport-bug> <xenial> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1863904>
<diddledan> thanks ogra, I'll take a look
<mup> PR snapd#8284 opened: config: add system.certs.[a-zA-Z0-9] support <Created by mvo5> <https://github.com/snapcore/snapd/pull/8284>
<mvo> pedronis: no worries, I can poke at it a bit
<mvo> pedronis: maybe the revert is indeed just doing something silly in the cert case, I dig a bit
<mvo> pedronis: I think the issue is that on a revert there are no changes, my code is too naive and only looks at changes right now but it really needs to also sync disk<->conf
<mvo> pedronis: i.e. the transaction.Chnages is empty (just to clarify what I mean with the above)
<pedronis> mvo: yes, we need to think a bit in which cases that is true and what it means
<pedronis> mvo: in the case of a revert, we would have to empty disk and copy out all the values from the conf
<pedronis> but I don't know if that is what we should do for all cases where Changes is empty
<pedronis> and also whether there are corner cases
<mvo> pedronis: yeah, I think we need to think a bit, I updated the PR to improve the XXX and will see what I can do tomorrow
<pedronis> mvo: also because our own code might do tr.Set at some point which would change Changes
<pedronis> so empty Changes needs to be checked earlier
<pedronis> or we need to flag Transaction by purpose early on
<pedronis> somehow
<mvo> pedronis: yeah, there are some options, I think I sketch something tomorrow that syncs the on-disk state with the config state. this should also fix the case that something tries to bypass our snapd configuration mechanism
 * mvo takes a break first
<diddledan> is anyone tracking problems from classic-confinement snaps when launching an HTTP(s) URL via xdg-open where firefox pops a dialog saying it can't find your profile?
<diddledan> e.g. I just installed slack and can't login to any workspaces because of this
<RingtailedFox> how would i go about compiling a .spec file into an RPM for my distro? i want to try to port snapd/snapcraft to mageia Linux
<diddledan> ... at least I presume it's via xdg-open. I need to double check that. it might be spawning firefox directly?
<diddledan> ok. it is spawning firefox inside the slack cgroup. possibly slack is trying to launch firefox directly?
<zyga> re
 * zyga delivered some food to his parents
<diddledan> well done :-)
<diddledan> good deed for the day :-)
<zyga> RingtailedFox: snapcraft is distributed as a snap
<zyga> RingtailedFox: snapd is already available in mageia, no?
<RingtailedFox> no
<zyga> ok, time to focus on work :)
<RingtailedFox> zyga, i want to port snapd
<zyga> RingtailedFox: could you look at snapd in fedora
<zyga> it is well maintained there
<RingtailedFox> yes, i was doing so.  a user here said they got the fedora spec file to work on mageia
<RingtailedFox> mageia is just a reincarnation of the old Mandrake/Mandriva linux
<zyga> RingtailedFox: good luck, I need to focus on a test I was writing
<RingtailedFox> good luck with your test :D
<zyga> RingtailedFox: if you are serious about mageia support it really requires cooperation with snapd team
<zyga> RingtailedFox: as we develop changes rapidly and heavily rely on CI
<zyga> RingtailedFox: and our CI is invoked against different real distributions
<RingtailedFox> CI?
<RingtailedFox> mageia's a real distribution... it's not a re-labelling like kubuntu
<zyga> RingtailedFox: continuous integration, we run thousands of integration tests on specific real distributions for each patch
<RingtailedFox> ohh
<zyga> RingtailedFox: packaging snapd is just a step towards proper long-term support
<RingtailedFox> so it'll be more work than just some guy in canada can provide :P
<zyga> RingtailedFox: all help is welcome
<zyga> RingtailedFox: not all help can be supported at all times, we also have our priorities and commitments
<RingtailedFox> of course
<RingtailedFox> i can provide bug reports and testing at least
<zyga> starting with a package available for testing is great
<zyga> getting around of feedback
<zyga> trying snaps
<zyga> checking what works and what doesn't
<zyga> there's the forum so if you want I would recommend you to post about your experiences and progress there
<zyga> as others may find it and join the cause
<RingtailedFox> ok
<mup> PR snapd#8252 closed: tests: update test to make snapd snap fixed twice <Simple ð> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8252>
<diddledan> this is slack trying to open firefox: http://cloud.bowlhat.net/index.php/s/A6wjmRp3tqm9wby
<mup> PR snapd#8285 opened: cmd/snap-update-ns: ignore EROFS from rmdir/unlink <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8285>
<zyga> kenvandine: ^
<zyga> ackk: https://github.com/snapcore/snapd/pull/8285
<mup> PR #8285: cmd/snap-update-ns: ignore EROFS from rmdir/unlink <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8285>
<zyga> sparkiegeek: ^
<zyga> is the maintenance window now? LP is throwing errors left and right
<sparkiegeek> zyga: nice, thanks
<zyga> I guess it only makes sense
<zyga> now from the perspective of knowing about it
<sparkiegeek> zyga: AIUI maintenance window not until tomorrow (00:30 - 01:30 UTC)
<zyga> hmmm
<zyga> I'll try again in a moment
<zyga> I got timeouts on anything I do
<mup> PR snapcraft#2982 opened: specifications: experimental snap compression <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2982>
<sparkiegeek> if username == zyga: time.sleep(20)
<zyga> *knew it*
 * zyga shakes fist
<sparkiegeek> :)
<sergiusens> zyga: fwiw I pointed RingtailedFox to Neil G.
<zyga> thanks
<sergiusens> zyga: have you ever seen someting like this https://pastebin.ubuntu.com/p/3DKvfQRcfV/ ?
<zyga> no
<zyga> I don't think so
<diddledan> what are you breaking now, sergiusens?!
<diddledan> #blamepopey
<sergiusens> diddledan: installing lxd I just built in a multipass adhoc spread backend and trying to remove it right after install
<diddledan> weird
<sergiusens> well LXD is a special snowflake
<diddledan> haha
<diddledan> just like me, then ;-)
<sergiusens> and installing with --dangerous might not get me all my required connections
<diddledan> that's an interesting thought
<diddledan> it'ld be handy if there was an easy way to install a local package (--dangerous) but use the connections that the store would normally mandate
<diddledan> maybe --really-really-dangerous mode?
<mvo> cachio: I'm preparing 2.44 now (-final) - anything you need in there that e.g. fails with tests or something?
<diddledan> mvo, 2.44-final-final-really_final-latest-v2?
<mvo> diddledan: exactly 2.44-really-really-really-i-mean-it-this-time-final :)
<diddledan> immediately followed by 2.44-really-really-really-i-mean-it-this-time-final-dammit-popey!
<mvo> diddledan: lol
<pedronis> we do plan a 2.44.1
<pedronis> already
<sdhd-sascha> hey, i'm still here. If you need help, then just say ;-)
<mvo> hey sdhd-sascha ! nice to see you. I'm good right now but appreciate the offer! hope you are doing well?
<sdhd-sascha> Nice to hear :-) My wife and I are okay. Thank you
<mup> PR snapd#8286 opened: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8286>
<mup> PR snapcraft#2982 closed: specifications: experimental snap compression <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2982>
<mup> PR snapd#8287 opened: tests, many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests (2.44) <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8287>
<ijohnson> mvo: I unfortunately didn't remember to squash merge 8169, so I spent too much time trying to port the changes to 2.44, and ended up just squash merging that branch on top of master locally, then cherry picking that squash merge onto a branch off release/2.44 and submitting that as the above PR ^
<ijohnson> it was rather complicated to port all the commits to release/2.44, because the PR was opened before 2.44 branched, and had merges from master both before and after release/2.44 was branched :-/
<sdhd-sascha> mvo: last week, i just send  some application to canonical  ;-)
<mvo> ijohnson: thanks, this will make merging 2.44 back into master a bit painful :/
<ijohnson> ah hmm hadn't thought about that
<mvo> sdhd-sascha: oh! you need to tell me some details tomorrow, good luck with that
<sdhd-sascha> thank you :-)
<ijohnson> mvo: yeah I just tried locally and there were conflicts with it
<mvo> ijohnson: you can try to merge that back into master and see how bad the conflicts are, if it's not too much it's fine, otherweise we should probably chat tomorrow, maybe we can do something minimal
<ijohnson> grr
<mvo> ijohnson: some conflicts are fine
<mvo> ijohnson: happens all the time, if it's a gazillion that is annoying :)
<ijohnson> let me see how bad that is
<ijohnson> mvo: the conflicts aren't too bad, the big thing was actually just the changelog, the rest of the conflicts are trivial to resolve it seems
<ijohnson> mvo: see https://pastebin.ubuntu.com/p/kSMKG5nGcf/
<mvo> ijohnson: aha, nice
<mvo> ijohnson: yeah, that sounds fine
<ijohnson> okay, cool
<mvo> ijohnson: thank you!
<ijohnson> sorry about that I know either I or someone else mentioned to mark that original PR as squash-merge and I forgot to tag it as such and then forgot to merge it as such /o\
<mvo> ijohnson: no worries
<mup> PR snapd#8288 opened: release: 2.44 <Simple ð> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8288>
<mvo> cachio: core 2.44 should be in beta in ~1-2h, unfortunately the snapd snap is not ready tonight, LP is hanging on code import it seems
<cachio> mvo, awesome
<cachio> I'll start as soon I have resutls
<cachio> thanks!
<mvo> cachio: looks like snapd snap will also build tonight, LP finally imported the updated code. should also be ready in ~1h
<cachio> nice
<cachio> tests should start automatically once the snap is published
<mvo> very cool
<mup> PR snapcraft#2977 closed: cli: merge build options into provider options <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2977>
<mup> PR snapcraft#2983 opened: tests: add LXD spread test <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2983>
<mup> PR snapcraft#2983 closed: tests: add LXD spread test <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2983>
<sdhd-sascha> hello, ijohnson: didn't look much about the PR. Thank you, for your advice. Really much thank's :-) If there is something i didn't see, then i like critism ....
<ijohnson> sdhd-sascha: we're always open to contributions like yours, just in that specific case I think it doesn't add very much utility to our current workflow
 * ijohnson -> EOD
#snappy 2020-03-18
<mborzecki> morning
<mup> PR snapd#8289 opened: xdgopenproxy: forward requests to the desktop portal <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8289>
<mborzecki> hmm the code in master isn't formatted according to gofmt 1.10?
<mborzecki> jamesh: thanks for opening the PR! thre's some unit tests failures in the travis job
<jamesh> mborzecki: yep.  Just looking into that (borrowing some logic from gio)
<mup> PR snapd#8290 opened: run-checks: tweak formatting checks <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8290>
<jamesh> mborzecki: I was adjusting the testing to run against a real bus rather than trying to mock everything
<mborzecki> jamesh: right, userd tests did that too iirc
<mborzecki> mvo: hey, a trivial PR to start your day with: https://github.com/snapcore/snapd/pull/8290
<mup> PR #8290: run-checks: tweak formatting checks <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8290>
<mvo> mborzecki: sure!
<mup> PR snapd#8288 closed: release: 2.44 <Simple ð> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8288>
<zyga> good morning
<mvo> good morning zyga
<zyga> how is everyone?
<zyga> it looks like a record-hot day today
<zyga> I gave up and bought a disk for debian :/
<zyga> I could not find any spare drives at home, that were not filled with stuff
<zyga> did you guys noticed the github app went live yesterday
<zyga> I tried it and it's pretty slick
<zyga> it feels almost better than using the browser on a desktop
<mborzecki> zyga: instead of just one browser you can run n instances now :)
<pstolowski> morning
<zyga> hey :)
<zyga> pstolowski: still waiting?
<pstolowski> zyga: yep; not even dispatched
<zyga> it will come
<zyga> just thinking about some stuff I talked about with mborzecki earlier
<zyga> mborzecki: RGB HDD FTW
<zyga> mvo: is 2.44 out?
<mvo> zyga: yes, since last night in beta
<zyga> woot
<zyga> is that expected to be the 2.44 final that goes out to ISOs?
<mvo> zyga: there will be a 2.44.1 that will probably go on the iso
<mvo> zyga: with search v2
<zyga> aha
<zyga> ok
<zyga> should I target fixes to it or to 2.45
<zyga> thinking about stuff like EROFS from yesterday
<mvo> zyga: fixes for 2.44
<mvo> zyga: please mark everything that is worth for 2.44
<zyga> https://github.com/snapcore/snapd/pull/8285 is like one
<mup> PR #8285: cmd/snap-update-ns: ignore EROFS from rmdir/unlink <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8285>
<mvo> zyga: we don't really have time for a 2.45 before the release
<zyga> sure
<zyga> I was thinking if we are doing any .1 or not at all
<mvo> zyga: yeah, most likley a .1
<mvo> zyga: (like ~95%)
<mvo> zyga: I added the 2.44 milestone to you pr and will cherry-pick
<zyga> I'll make a milestone on LP and retarget thebug
<mborzecki> zyga:  haha rgb hdd, how about a transparent rgb hdd with a led platter  on top of the magnetic ones? :)
<zyga> mborzecki: as soon as we have that transparent aluminum ;)
<zyga> mborzecki: but I would totally buy an RGB HDD
<zyga> because, why not :)
<mborzecki> zyga: heh, already auto-filed https://bugzilla.redhat.com/show_bug.cgi?id=1814552
<zyga> yeah I got the mail ping a moment ago
<zyga> ITSABUGFIXITNOOOW
<zyga> mvo: will you make the release tarballs?
<zyga> brb
<mvo> zyga: sure
<zyga> thank you :)
<mvo> pedronis: I pushed an update to the nocloud, probably needs a lot of naming tweaks
<pedronis> mvo: #8278 ?
<mup> PR #8278: devicestate: disable cloud-init by default on uc20 <Simple ð> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8278>
<mvo> pedronis: yes
<pedronis> mvo: ok, I will look at it, looking at the next secboot PR atm
<mvo> pedronis: no rush, thanks!
<mvo> pedronis: actually let me tweak it a bit more, I think it's silly at this point to split it into two
<mborzecki> i can't decide whether go allowing to embed `*type` and `type` is good or bad thing
<pstolowski> zyga: question to the env fix PR
<zyga> pstolowski: ok
<pstolowski> zyga: ah, it's splitN, so it's fine
<zyga> heh, I just replied the same :)
<zyga> I believe this is also tested
<zyga> there's a test like K=V=...
<zyga> anyway
<zyga> I need to take half day off
<zyga> until we figure out home schooling
<zyga> Lucy is constantly with me
<zyga> crying if she is with grandparents
<zyga> and I just cannot focus
<zyga> until enough discipline and getting over the fact working at home is working is understood by older kids
<zyga> sorry, I'll file the time off later :/
<zyga> we're walking up and down the stairs all morning
<mup> PR snapd#8234 closed: devicestate: support for "cloud.cfg.d" cloud-init in uc20 with grade: dangerous <Needs Samuele review> <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8234>
<pedronis> mvo: I'm a bit unsure why you think is silly to split it? I asked it to be split that way
<pedronis> mvo: what I mean, please don't merge 8234 into 8278
<mvo> pedronis: ok, I will do them separately, sorry
<mvo> pedronis: then 8278 should be ok for a first look, probably lots of tweaks still needed but hopefully it captures what we discussed
<pedronis> mvo: 8278 is not that small anyway, with more stuff it would maybe >500 lines
<mvo> pedronis: yeah, makes sense
<pedronis> mborzecki: how close do you think is #8159, apart your comment?
<mup> PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
<mborzecki> pedronis: it's just some nitpicks
<mborzecki> pedronis: i think a helper called from Run() before CreateMising() that explicity mutates LaidOutVolume based on options would be fine there
<pedronis> mborzecki: I see, I sort of feel there already too many helpers but maybe is just me
<mborzecki> pedronis: perhaps that should even be something in gadget, since gadget is looked at from other places too (eg. boot assets update)
<mborzecki> pedronis: wdyt?
<ijohnson> morning folks
<mborzecki> ijohnson: hey!
<ijohnson> hey mborzecki o/
<pedronis> mborzecki: I honestly wonder if overreding what the gadget says is worth the trobule
<pedronis> the specs says anyway that the normal partitions can be luks
<pedronis> afaiu
<mborzecki> pedronis: leave a type as it is then?
<pedronis> yes
<pedronis> mborzecki: see here: https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
<mborzecki> pedronis: mhm, cryptsetup open probably does not even look at the partition type in gpt/mbr
<pedronis> it's cute to have the "right" type but atm it just seem grief
<mborzecki> haha fair enough
<pedronis> notice that I didn't request that
<pedronis> also as you said, not sure other gadget code will be happy
<pedronis> about the changed type
<ijohnson> any idea why snap prepare-image would fail to find the account-key here: https://pastebin.ubuntu.com/p/Qz3RvprPK6/, this is from #8286
<mup> PR #8286: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8286>
<ackk> zyga, hi, is https://paste.ubuntu.com/p/Yv9dkYThZr/ the same issue with mounts you're fixing?
<mvo> zyga: hrm, hrm, the debian package fails with https://paste.ubuntu.com/p/P674rpMTMB/ which in my pbuilder, which is super strange given that this is building travis, I wonder if we do something silly there like not excluding the vendor stuff or sillyness like this
<mborzecki> pedronis: ok, let's discuss that with claudio after the standup maybe?
<pedronis> mvo: I +1ed one 8278 but it needs a 2nd review given all the changes, also Opts name need to change. Lots of details are still unclear to me but shouldn't be a blocker for what is there currently
<zyga> ackk: no, you cannot chown $SNAP
<zyga> hmmm
<ijohnson> pedronis: I'm reviewing 8278 right now
<zyga> mvo: weird
<zyga> is golang-evdev in the vendor tarball>
<zyga> or are we de-vendoring?
<zyga> I mean, are we really building the devendorized tarball in our spread runs?
<pedronis> we shouldn't be building things that need on debian
<pedronis> need it
<pedronis> anyway
<zyga> pedronis: good point
<zyga> Lucy is asleep now but I think today is rather hectic :
<pedronis> maybe we are because
<zyga> :/
<pedronis> mborzecki: I'm not sure there is more to discuss, that PR is open since forever
<mvo> pedronis: yeah, I'm unhappy that we did not caught this, the sbuild nightly test is failing since days and it was not noticed
<mborzecki> pedronis: ok, let me add a note that we drop the type chane
<ackk> zyga, that's not $SNAP, it's $SNAP_DATA
<ijohnson> mvo did you see my comment about cloud-init spread test on 8278 ?
<ackk> zyga, oh wait, I'm dumb
<zyga> ackk: snap/maas/current/usr/lib/postgresql/10/bin seems like $SNAP
<ackk> zyga, I saw the "current" there and thought it was SNAP_DATA, sorry :)
<pedronis> ijohnson: I think we need core 20 specific cloud-init tests, I suppose that's mvo plan
<zyga> :D
<zyga> mvo: do you know what is missing in our spread setup?
<pedronis> ijohnson: given the behavior will be tied to grade etc
<ijohnson> ok, sure I would still like to see a TODO:UC20: somewhere about that so that we remember to write that :-)
<mvo> zyga: not sure yet, just checking one idea
<pedronis> ijohnson: that's ok, my point is that the TODO should simply say re-enable this for UC20
<pedronis> heh
<pedronis> should not simply say
<ijohnson> :-)
<mvo> zyga: in any case, the nightly suite did notice the issue we just did not pay attention, I think we need alerting here
<zyga> :/
<mvo> ijohnson: yeah, sorry, need to reply, but I think we need special tests, uc20 behaves differently from the other oses we have
<ijohnson> yes that's fine
 * ijohnson just likes todos so we don't forget
<pedronis> I like todos too
<pedronis> I like to do todos sometimes too
<pedronis> or even done todos too
<pedronis> :)
<ijohnson> haha nah I'm not much for that, I just like them to add up
<ijohnson> :-)
<ijohnson> there's a benjamin franklin quote something like "I love deadlines, I love the whooshing sound they make as they go by"
<zyga> lol pedronis :D
<zyga> we need to do do more todos
<mup> PR snapd#8291 opened: packaging,tests: ensure debian-sid builds without vendor/ <Created by mvo5> <https://github.com/snapcore/snapd/pull/8291>
<zyga> mvo: lol :)
<zyga> sorry :)
<zyga> mvo: approved
<mvo> zyga: it's all very sad
 * zyga elbow-hugs mvo 
<zyga> not _all_ very sad :)
<mup> PR snapd#8292 opened: travis.yml: run unit tests on master as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/8292>
<zyga> mvo: small review for 8292
<zyga> mvo: I also wonder if this bug is related https://bugs.launchpad.net/snapd/+bug/1867755
<mup> Bug #1867755: snapd fails to build in focal, unit test clientSuite.TestClientFindFromPathErrIsWrapped fails <snapd:New> <https://launchpad.net/bugs/1867755>
<mborzecki> kinda meh that dh_auto_build is so magical you need to remove parts of the source tree
<zyga> mborzecki: when it works it is useful
<zyga> no packaging is good
<mup> PR snapd#8293 opened: packaging: add README.source for debian <Created by mvo5> <https://github.com/snapcore/snapd/pull/8293>
<zyga> mborzecki: ha
<zyga> mborzecki: check this out please
<zyga> https://www.irccloud.com/pastebin/5hCE1Blq/
<zyga> specifically line 4
<mvo> zyga: 1867755 is fun, it seems to be a race
<zyga> does it seem to you that dbus activation is somehow not working?
<mvo> zyga: which is so strange - I saw it sometimes in a PPA build (rarely) and even once in travis I think
<zyga> heh
<zyga> mvo: use teasaiding they
<cmatsuoka> mborzecki: for some reason I can't answer your review comment on #8159 but you're right, we're mutating external data that shouldn't be touched there
<mup> PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
<mvo> zyga: can't parse that
<zyga> mvo: use threads they said | scramble
<mborzecki> cmatsuoka: left a note there, after discussing with pedronis it probably makes most sense to not update the type at all and leave what's defined in the gadget
<mvo> zyga: hahahahaa
<cmatsuoka> mborzecki: ok, will do it that way
<mborzecki> zyga: hmm session systemd has no love for the session tool?
<zyga> mborzecki: it fails on 18.04
<zyga> but not in others somehow
<zyga> I collected some more data, let me go through it
<pedronis> ijohnson: as discussed apart the test renames #8208 seems good to go, it needs 2nd review though
<mup> PR #8208: boot_test: add many boot robustness tests for UC20 kernel MarkBootSuccessul and SetNextBoot <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8208>
 * cmatsuoka hates when you notice something strange in your code, check the branch to see if it's right (it is) and then realize you're on the wrong host
<pedronis> ijohnson: I reviewed #8286, thanks for it
<mup> PR #8286: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8286>
<mup> PR snapd#8285 closed: cmd/snap-update-ns: ignore EROFS from rmdir/unlink <Bug> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8285>
<mborzecki> ah, damn, should have squash merged
<pedronis> #8292 (small) needs a 2nd review
<mup> PR #8292: travis.yml: run unit tests on master as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/8292>
<zyga> making progress :)
<zyga> brb, I'll make coffee and check up on kids
<cmatsuoka> ijohnson: did you change anything related to grubenv yesterday? cachio reports boot errors in the ci tests
<cmatsuoka> ijohnson:  qemu-system-x86_64[62371]: error: file `/EFI/ubuntu/grubenv' not found.
<pedronis> last things merged 2 days ago, was the start of uboot support
<pedronis> shouldn't have broken amd64
<pedronis> don't know if something was done to the gadget or somewhere else
<zyga> ha, ok I think I got it
<zyga> mborzecki: it works :)
<zyga> now the only thing I need is to inject one more exec
<zyga> as the pid I get is not the pid of the app
<zyga> but of the intermediate bash
<pedronis> zyga: not urgent, but if you could look at my changes to #8242 it could be otherwise be landable
<mup> PR #8242: many: improve environment handling, fixing duplicate entries <Bug> <Needs Samuele review> <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
<zyga> ack
<pedronis> Pawel reviewed it as well
<zyga> in a few minutes
<zyga> I had a look originally but I need to read it again now as it paged out of my memory
<zyga> oh, right. 2.44 is branched so we can land 2.45 things again
<ijohnson> cmatsuoka: that sounds like the same issue you and cachio had at the sprint no?
<sil2100> zyga, mvo, xnox: as part of my SRU verification for ubuntu-image, I just built an amd64 uc20 image, but I can't get a working system - I just get the grub menu, and whatever I select I get some errors, is that expected?
<sil2100> I just want to know if it's ubuntu-image broken or something else
<zyga> sil2100: I don't know
<cmatsuoka> cachio: could you check for "bootloader files not found" messages in the system journal?
<cmatsuoka> cachio: of see if the bootloader is actually there
<cmatsuoka> ijohnson: that's a possibility, I asked sergio to confirm if that's the case
<cmatsuoka> cachio: s/of/or/
<cachio> cmatsuoka, what I see now is that the system is restarting in a loop
<ijohnson> sil2100: what are the menu items in the grub you see
<cachio> the last thing I see is Mar 18 13:49:05 mar181302-158658 qemu-system-x86_64[61560]: [   16.102470] systemd[1]: Started Create Static Device Nodes in /dev.
<cachio> then allways restarts in install mode
<cmatsuoka> cachio: that didn't happen with the bootloader error in the sprint, right?
<cachio> cmatsuoka, I thinks it is not the same but not totally sure
<cachio> cmatsuoka, sometimes I even see Mar 18 13:51:27 mar181302-158658 qemu-system-x86_64[61560]: Press enter to configure.
<cachio> and then reboots again automatically
<sil2100> ijohnson: 'Recover using /systems/*', 'Install using /systems/*' and 'System setup'
<cachio> cmatsuoka, this is the last log v
<cachio> https://paste.ubuntu.com/p/6bNqps9Np2/
<cmatsuoka> cachio: that's very strange, what changed from the latest build that worked? is there a new kernel snap, or new ubuntu-image?
<sil2100> There has not been a new ubuntu-image in stable since a while, 1.9 is the latest
<cmatsuoka> sil2100: thanks for the information
<cmatsuoka> cachio: so let's see what the differences are, something must be different
<sil2100> cmatsuoka, cachio: when did you start noticing the problems? And are you using ubuntu-image from the snap or deb?
<sil2100> That being said, I don't think we had any uc20 related changes to 1.9 even
<cachio> sil2100, snap
<cachio> cmatsuoka, I think the problem was already there
<cachio> the system is restarting and restarting until at some point it does not restart
<cachio> then it works
<cmatsuoka> cachio: coming to SU?
<sil2100> cachio: while we're at it, what's up with core18 the snap? I see it's not marked as ready for beta all the time, is something failing for the pi3?
<cachio> it started failing now because I reduced the timeouts because I am tryting to speed up a bit the tests because it is taking like 40 minutes each test
<sil2100> cwayne, plars: ^
<cachio> sil2100, let me check
<cachio> sil2100, this is the problem https://trello-attachments.s3.amazonaws.com/5da8bc830df86851446e9d4e/5e688b02c26ce805a8a979ef/8bb39aabc282ceb61f07f599cd7d72b6/core18_20200311_(1705)_pi3_arm32.log
<cachio> the system fails to flash the image
<sil2100> cachio: oh, so not really an issue with the snap itself - should we poke plars around it and see if he can help?
<cachio> I think the issue is with the device in the lab
<cachio> sil2100, not related to the image
<cachio> I trigegred it again
<cachio> lets see
<ijohnson> sil2100: what error do you see when you try to use the `install using ...` menu item?
<xnox> sil2100:  did you boot in UEFI mode, with secureboot, and snakeoil UEFI VARS?
<xnox> using OVMF firmware?
<xnox> sil2100:  if you see "*" it means you booted in bios mode
 * xnox should push a grub change to print something sensible
<cwayne> cachio: that doesnt make any sense, we use that image on that pi a lot
<plars> cachio: cwayne: I can't even reach that device at the moment, so I have no idea, but it's dead now. My best guess is that something was wrong with the sd card on it, but I can't login to check
<cachio> plars, ok
<cachio> cwayne, I just tried to run smoke tests for core18 and that happend
<Eighth_Doctor> mborzecki, zyga: so this is now a thing: https://docs.fedoraproject.org/en-US/ci/how-to-add-dist-git-test/
<Eighth_Doctor> perhaps one day we could add some tests for snapd for fedora infra to run (similar to autopkgtests for debian)
<mborzecki> Eighth_Doctor: oh nice, we had some ideads about testing packages before pushing to distros
<zyga> nice, thank you
<Eighth_Doctor> you can kind of thank pitti here, he pushed for this to become a thing, and learned from the mistakes in making autopkgtests
<zyga> yay, so session tool can now track PIDs of the started processes
<zyga> separately from the session manager
<zyga> so that's good
<zyga> I added that to the cgroup-tracking test
<zyga> let's see what we get
<zyga> Eighth_Doctor: can you ask him to push it back to Debian ;D
<Eighth_Doctor> hah, you know as well as I do that debian doesn't do change :P
<zyga> Eighth_Doctor: it does, in debian stable ;)
<zyga> \o/
<zyga> jdstrand: I reproduced the issue reliably in spread now
<zyga> woot
<zyga> Mar 18 14:56:41 mar181449-606426 systemd[20017]: snap.8661f9ab-6dbb-4fd5-bb75-9bb871f5dddc.test-snapd-sh.sh.scope: Failed to add PIDs to scope's control group: Permission denied
<zyga> I can now push some simple fixes for session-tool
<zyga> and start working on untangling this particular error
<zyga> let me just quickly verify that it's not affecting other releaes
<zyga> *releases
<cachio> pedronis, mvo this is the log for the retries on uc20 https://paste.ubuntu.com/p/kjhYcqcmrw/
<pedronis> it is saying:  error: file `/EFI/ubuntu/grubenv' not found.
<pedronis> quite a bit
<ijohnson> cmatsuoka: I had a look at the log for PR 8159, and if you merge master that snapd-failover issue should go away
<mup> PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
<cmatsuoka> ijohnson: thanks, will do
<zyga> 16.04 passes
<zyga> I'm pretty sure 18.04 has a bug
<zyga> that's not present in 20.04 or 16.04
<zyga> ah, sorry 20.04 passed, 16.04 still running
<pedronis> cachio: mvo: we don't even get to systemd in the first couple of those reboots
<pedronis> afaict
<mvo> pedronis: hm, yeah, this looks like initramfs snafu
<pedronis> or something uefi related
<pedronis> mvo: there first time we get to EFI Variables Facility v0.08 2004-May-17
<pedronis> and then there's a reboot there
<cachio> pedronis, could be related to the gadget snap version?
<cachio> I am retrying with the edge version now, this run was using the stable version
<mvo> cachio: yeah, that sounds like it could be
<cachio> mvo, I'll have results soon
<mvo> cool
<mup> PR snapd#8294 opened: seed: make Brand() part of the Seed interface <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8294>
 * cachio lunch
<cachio> mvo, pedronis using gadget from edge I see the same
<cachio> this is the full log https://paste.ubuntu.com/p/bsmwC5Q52b/
<mvo> xnox: does https://paste.ubuntu.com/p/bsmwC5Q52b/ ring any bells?
<mvo> xnox: the funny part is that after some reboots this goes away, is there maybe something in initramfs that looks for it, if it's missing the unit fails and reboots and sometimes we run stuff with the right timing and things work, would the initramfs reboot if a unit fails?
<xnox> in a meeting
<mvo> xnox: no worries, sry
<xnox> mvo:  hey
<xnox> mvo:  so that message about lack of grubenv is from grub. it failing to read and load grubenv, seems to indicate that this is not a UC20 boot? because UC20 gadget relies on grubenv to be present and valid.....
<mvo> xnox: aha, that's interessting (cc cachio) - what's strange is that apprerntly for cachio it works after a bunch of reboots in his VM setup
<xnox> mvo:  i am concerned on how you are starting the VM and whether or not you passed which disk is the expected correct bootdevice
<xnox> mvo:  because it seems like your tpm state will be corrupted.
<cachio> xnox, https://paste.ubuntu.com/p/JTGNRh7djq/
<cachio> xnox, should I change anything in the command?
<xnox> mvo:  the boot does not seemed to be complete. as the boot is in install mode, and the next one is as well.....
<xnox> do the tests reboot twice correctly? and again, without grubenv being written correctly, it will not have pointer to boot into run mode.
<xnox> cachio:  you have bootindex=1 set correctly there, so boot device is there.
<cachio> xnox, do you want to inspect the image?
<xnox> mvo:  cachio: i'd like to see the VM image ubuntu-core-new.img contents after it was created, but before it is booted. And the file listing of all files on all partitions, and contents of grubenv file.
<xnox> =)
<xnox> cachio:  we think alike ;-)
<mborzecki> #8249 is super simple and needs a 2nd review ;)
<mup> PR #8249: interfaces: make gpio robust against not-existing gpios in /sys <Reviewed> <Security-High> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8249>
<mborzecki> heh
<mborzecki> #8294 this one
<mup> PR #8294: seed: make Brand() part of the Seed interface <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8294>
<pedronis> mborzecki: could you review #8208 when you have time (is not simple)
<mup> PR #8208: boot_test: add many boot robustness tests for UC20 kernel MarkBootSuccessul and SetNextBoot <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8208>
<xnox> cachio:  mvo: the image looks quite small, i don't know if we have enough disk space to complete the install
<xnox> it is 5.4GB big, and I usually locally make 8G/10G big images.
<cachio> xnox, ahh, I can try with 10GB
<cachio> does it makes sense?
<xnox> mvo:  cachio: the failing to load grubenv is a red herring, and i should fix our grub.cfg to not print that pointlessly
<xnox> cachio:  please try with a 10GB image, yes.
<pstolowski> pedronis: #8270 updated with the extra fields, ready for review
<mup> PR #8270: store: support for search API v2 <Needs Samuele review> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8270>
<cachio> xnox, sure, running
<pedronis> #8286 needs a 2nd review, it's simple (mostly adding tests and improving code behavior a bit)
<mup> PR #8286: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8286>
<xnox> cachio:  i'm afk / busy until end of day, sorry. Can chat tomorrow, if you will have uc20 logs from a bigger image.
<cachio> xnox, sure, I'll try again and send you the logs in case it fails again
<cachio> thanks for your help
<zyga> jdstrand: hey
<zyga> jdstrand: I've debugged the issue
<mborzecki> pedronis: ack
<zyga> jdstrand: dbus-user-session
<zyga> jdstrand: the new app tracking feature depends on it and we just didn't notice because it's pre installed since eoan (on server)
<zyga> jdstrand: I've expanded the test to completely cover running as user
<zyga> and with this package it all passes
<zyga> and without it it behaves just as your system did
<zyga> jdstrand: a bionic desktop has it installed by default
<zyga> jdstrand: but a bionic server does not
<zyga> jdstrand: can you, if you remember, confirm where you were testing my branch at the time?
<jdstrand> zyga: hi! (sorry, was doing 360s)
<zyga> jdstrand: no worries :)
<zyga> I'm so glad I made some progress on this branch
<jdstrand> zyga: iirc, it was a bionic desktop amd64 vm, logging in over ssh
<zyga> jdstrand: do you have dbus-user-session installed in that VM?
<jdstrand> I'm checking now
<jdstrand> zyga: it is installed. when I login I see this in the environ: DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
<zyga> hmmm
<zyga> ookay
<zyga> that's interesting, and it's not installed recently?
<zyga> I'll double check in any way
<zyga> thank you
<jdstrand> zyga: let me look at the PR again. I think I said what I was using
<zyga> right now the tests do pass in all xenial+ systems
<zyga> as root and as user
<zyga> but not as user logged in via ssh
<zyga> (I didn't write that test since it's all kind of remote)
<zyga> but maybe it's a relevant factor
<jdstrand> "Unfortunately, on (at least) bionic, when logged in via ssh or directly via the console"
<zyga> ok, I'll get to it
<zyga> I suspect something else is a factor then
<zyga> but I'm closer, I think
<jdstrand> zyga: sounds like you are getting there! :)
<jdstrand> zyga: it's the feature that won't stop giving :)
<zyga> oh yes
<jdstrand> zyga: and for completeness, logging into a vt, DBUS_SESSION_BUS_ADDRESS was set on the console as well
<jdstrand> I suspect that is logind for both
<zyga> I took a snapshot of my 18.04 desktop vm and I'll dig in
<zyga> yes, that's pam-systemd
<zyga> though that's really
<zyga> dbus-session-bus started in the session
<zyga> jdstrand: is your desktop VM logged in as a desktop user?
<jdstrand> zyga: the vm came up and is sitting at the gdm prompt. I did not login. I then ssh as the normal user (ie, the one I would use at the gdm login)
<zyga> ok
<zyga> thanks
<zyga> I have the same setup now
<zyga> and when you are logged in via ssh
<mup> PR snapd#8295 opened: osutil: do not leave processes behind after the test run <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8295>
<zyga> loginctl shows only two sessions?
<zyga> one for gdm
<jdstrand> zyga: I can say that /run/user/1000/bus exists and it is /lib/systemd/systemd --user that setup that socket
<zyga> and one for your ssh
<jdstrand> zyga: however, there is no dbus-daemon running under this user. just dbys-daemon --system (root) and dbus-daemon --session (gdm)
<zyga> hmmm
<zyga> I see
<zyga> https://www.irccloud.com/pastebin/H3nx0PgY/
<jdstrand> (well, there is also the accessibility bus for gdm)
<zyga> zyga       1689  0.0  0.1  49792  3840 ?        Ss   18:26   0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
<jdstrand> zyga: loginctl shows gdm and the user I logged in as
<jdstrand> zyga: you have that running as 'zyga' without logging into gdm?
<zyga> I ssh'd in
<zyga> yes
<zyga> but I have dbus-user-session installed
<zyga> let me log out and double check PIDs recyce
<zyga> oh wait
<zyga> it's gone now
<jdstrand> I have dbus-user-session installed, logged in via ssh and do *not* have the above in ps for my user
<zyga> maybe it's just activated
<zyga> ha
<zyga> wait
<zyga> it didn't
<zyga> zyga@bionic-desktop:~$ systemd-run --user --scope ls
<zyga> Job for run-re0d33bd5a3334fc39992748ea3053b88.scope failed.
<zyga> See "systemctl status run-re0d33bd5a3334fc39992748ea3053b88.scope" and "journalctl -xe" for details.
<zyga> that's exactly what you saw
<zyga> what the...
<zyga> I think my auto-login spawned dbus
<zyga> and it was around
<zyga> I logged out, killed that session
<jdstrand> ah, yes, that would do it
<zyga> logged out from ssh
<zyga> logged back in
<zyga> and no dbus
<zyga> *progress*
<jdstrand> \o/
<zyga> thank you, I won't bother you anymore until I crack this
<jdstrand> zyga: it feels so close! :)
<zyga> mar 18 18:32:12 bionic-desktop systemd[2002]: run-re0d33bd5a3334fc39992748ea3053b88.scope: Failed to add PIDs to scope's control group: Permission denied
<zyga> mvo: small review on 8295
<zyga> mvo: will kill-sleeper work without job control in tty?
<mvo> zyga: I don't know, I tested it locally and it was ok
<zyga> locally it would have your pty
<mvo> zyga: yeah
<zyga> let's see what happens
<zyga> mvo: I think exec sleep is better
<zyga> then you can kill it
<mvo> zyga: but I need the pid?
<zyga> exec :D
<zyga> h
<zyga> ah
<zyga> sorry
<zyga> :/
<zyga> missed that
<mvo> zyga: :)
<mvo> zyga: no worries
<zyga> you could echo $$ > /tmp/pid
<zyga> and kill that
<zyga> but uck
<mvo> zyga: happy about better ideas, feel free to push to the PR, it was the best I could think of
<zyga> yeah, that's fine
<zyga> let's see if it passes
<zyga> I'm debugging systemd behavior now
<zyga> but happy to look next
<mvo> zyga: no worries, if it's good enough that would be nice if not we can iterate
<zyga> I think I found the systemd bug
<zyga> mkdir("/sys/fs/cgroup/pids/user.slice/user-1000.slice/user@1000.service/run-rbabf8a8b75af4ad68cf81da60da72a47.scope", 0755) = -1 EACCES (Permission denied)
<zyga> https://bugzilla.redhat.com/show_bug.cgi?id=1413075
<zyga> seems related
<mup> PR snapd#8294 closed: seed: make Brand() part of the Seed interface <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8294>
<zyga> I give up for today
<zyga> I'm attached to systemd --user that exhibits the error
<zyga> I have debug symbols and all that
<zyga> I can reproduce the error at will
<zyga> need to jump into this with fresh head tomorrow
<zyga> jdstrand: ^ FYI
<zyga> I also have the same setup with newer systemd on focal where it doesn't fail
<zyga> that's all for today folks
<zyga> o/
<cmatsuoka> cachio: booting the test image it worked, but auto-import from /dev/sda failed (with exit code 127)
<cachio> cmatsuoka, perhaps mvo knows about which other thing to check
<cmatsuoka> cachio: auto-import.assert is indeed in /dev/sda
<ijohnson> cmatsuoka: any more output from auto-import ?
<cmatsuoka> ijohnson: not much, let me retrieve the actual log entries
<cmatsuoka> ijohnson: https://pastebin.ubuntu.com/p/8B3JyXMsbx/
<zyga> cmatsuoka: 127 is command-not-found IIRC
<cmatsuoka> ijohnson: /dev/sda is where the assertion is, I mounted it and it's there
<cmatsuoka> oh
<zyga> so /bin/snap whatever is not tehre
<cmatsuoka> that's embarrassing
<zyga> ;D
<ijohnson> well then
 * zyga goes away
<cmatsuoka> cachio: I think it's explained then, let me check the initramfs to see if the executable is there...
<cmatsuoka> I mean
<cmatsuoka> it's on the real system, right? so no, it's not tehre
<cmatsuoka> there
<mvo> cmatsuoka: this indicates that the snap command is not there, this usually happen on the very first boot when snapd is not seeded yet
<cachio> cmatsuoka, do you see any error during the seeding?
<cmatsuoka> mvo: ah yes, that makes sense
<cmatsuoka> cachio: seeding seems good to me
<cmatsuoka> cachio: no more auto-import messages later
<cachio> if you restart it does it work?
<zyga> does the auto-import service depend on seeded system?
<zyga> it probably shold
<zyga> *should
<cmatsuoka> zyga: it seems that it doesn't but it should, from what we see here
<pedronis> I think mvo has thoughts on it already
<ijohnson> this is the same bug that came up during the sprint
<pedronis> yes
<pedronis> it's a known bug atm
<mvo> cmatsuoka, pedronis yeah, I think we either need to just echo the device paths and catchup or do a udev scan of the block devices in snap.autoimport.service. it's mostly jfdi but I didn't manage to find the time for it yet
<pedronis> it's not an immediate blocker, the cost is rebooting again
<cachio> pedronis, in uc20 is taking so long to boot
<cmatsuoka> ok then, now I see how this ties to the sprint conversation
<cachio> we were researching why
<pedronis> cachio: well, I new run reboot shouldn't take that longer
<pedronis> cachio: isn't the issue the multiple reboots?
<pedronis> or is this something else
<pedronis> cachio: I mean, did we fix the issue you showed today, were we get a bunch of reboots
<pedronis> that don't even reach systemd
<cachio> it is something else, it was caused becuase the zise of the image was 5g and we needed 10g
<cmatsuoka> cachio: anyway, in all my tests it booted correctly to run mode without any boot loops
<pedronis> interesting, that seems big, do we know what's the space needed for?
<cachio> I don't yet
<pedronis> ok
<cmatsuoka> pedronis: that's curious because the partition grow code is not there yet
<cmatsuoka> so the partition sizes should stay the same
<pedronis> do we have a weird bug in install code that makes a partition of the wrong sizes?
 * zyga EODs
<cmatsuoka> cachio: could you generate a 5G image for me?
<cmatsuoka> cachio: so I can check if there's something funky in partitioning
<cachio> sure
<cachio> first, could you try restart that vm
<cachio> in my case when I restart the vm it goes in a rrboot loop
<cachio> and I see error: file `/EFI/ubuntu/grubenv' not found.
<pedronis> do we know if it's in the image?
<pedronis> it should be (at least we put one there end of Feb)
<cachio> I am generating a new image to check again
<pedronis> ijohnson: cachio: so I made an image and there's no grubenv, but that's expected I think, there will be one now with the new code
<ijohnson> pedronis: there won't be a grubenv on the root ubuntu-seed grubenv
<pedronis> yes
<pedronis> not until we set mode to run
<ijohnson> err sorry there won't be any variables set, I guess I don't know for certain whether there would be an empty grubenv or not
<pedronis> there isn't one
<ijohnson> yes when we run makeBootable20RunMode then we set grubenv on ubuntu-seed
<pedronis> I just made an image and mouunted
<ijohnson> iirc
<pedronis> it
<pedronis> https://paste.ubuntu.com/p/w3NbfYdt5V/
<pedronis> cmatsuoka: is #8159 ready for a re-review ?
<mup> PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
<cmatsuoka> pedronis: yes, I also fixed issues raised my maciek (the struct pointer issue and better attribute parsing)
<pedronis> cmatsuoka: ok, thanks, I'll look at it in my morning
<cmatsuoka> pedronis: I'm currently skipping partitions that have a type that's not in our list. the alternative would be to fail and abort installation
 * cachio afk
<mup> PR snapd#8296 opened: httputil/client_test.go: add two TLS version tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8296>
<pedronis> ijohnson: seems here failover failed again, but it seems that PR got the latest code for that: https://api.travis-ci.org/v3/job/664035070/log.txt
<ijohnson> pedronis: which pr
<pedronis> ijohnson: your latest
<ijohnson> 8287 ?
<pedronis> #8286
<mup> PR #8286: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8286>
<pedronis> also the ubuntu-image test change breaks it
<pedronis> su => session-tool
<pedronis> s/ubuntu-image/prepare-image/
<zyga> hmm?
<zyga> session-tool broke something?
<pedronis> I'm also not sure why using session-tool there
<pedronis> it seems overkill, but I may be missing something
<zyga> where?
<zyga> I just came to check on something and noticed
<pedronis> zyga: https://github.com/snapcore/snapd/pull/8286/files
<mup> PR #8286: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8286>
<pedronis> zyga: ijohnson replaced a su invocation with session-tool, do the test is just calling prepare-image, and things break
<zyga> do you know why it is invoked as user in the first place?
<ijohnson> mvo wrote the original test fwiw
<pedronis> to check that it works
<pedronis> as a normal user
<zyga> aha
<zyga> and how does it break/
<pedronis> it's not finding an assertion, the breakage is strange
<pedronis> anyway not sure it needs to use session-tool
<pedronis> zyga: there's spread logs there
<ijohnson> I mean isn't this why we have session-tool though ...
<zyga> ok
<ijohnson> zyga: https://pastebin.ubuntu.com/p/sJzvXy3dWw/
<pedronis> ijohnson: do break working tests?
<zyga> thanks!
<pedronis> to break working tests?
<zyga> pedronis: true always works ;)
<ijohnson> no I mean to have a tool that "does all the right things"
<ijohnson> su doesn't do all the right things
<pedronis> what is right or wrong is very contextually dependent
<zyga> hmm
<zyga> is /home/test/tmp//model.assertion sensible
<zyga> as in // that feels like something not expanded
<pedronis> it's just a var ending in /
<zyga> ah, $ROOT has / at the end
<pedronis> anyway works with just su
<ijohnson> it's easy enough to back out that change but it's just frustrating that we have these problems :-/
<zyga> what places model.assertion there?
<ijohnson> also the snapd-failover failure is very depressing tbh
<pedronis> ijohnson: yes, that one is
<pedronis> definitely
<zyga> ijohnson: I made some improvements to session-tool, fixed some issues with quoting
<zyga> but I don't suspect it's a factor in this case
<pedronis> ijohnson: the other one I would just move back to su and be happy for a while
<zyga> oh wait
<zyga> hmm
<pedronis> I'm quite all the other tests like this one use su anyway
<pedronis> so we would have to change all or none
<zyga> session-tool expects stuff normally, not as one big string
<zyga> maybe my quoting fix would actually help
<pedronis> and it doesn't seem a good use of time at this moment
<zyga> ijohnson: yeah, leave it to me
<zyga> I plan to do a pass
<ijohnson> awesome, thanks zyga
<ijohnson> I wonder if we should just stop snapd.socket then start it again rather than a restart
<ijohnson> I just really really wish we understood why that keeps happening anyways
<pedronis> I reverted to su for now
<pedronis> we have 29 places using it still
<zyga> I pushed some fixes to session tool
<zyga> https://github.com/snapcore/snapd/pull/8297
<mup> PR #8297: tests: session-tool improvements <Created by zyga> <https://github.com/snapcore/snapd/pull/8297>
<pedronis> that's good, I don't think converting su to session-tool is somethign anybody should work on unless there is a good reason for specific tests at this point in time
<pedronis> though
<pedronis> too many other things
<mup> PR snapd#8297 opened: tests: session-tool improvements <Created by zyga> <https://github.com/snapcore/snapd/pull/8297>
<zyga> pedronis: I think it's that they are definitely not really testing the feature
<pedronis> which feature?
<zyga> pedronis: su is not representative of a user running the code
<zyga> pedronis: anything
<zyga> pedronis: it's really 90% root
<zyga> pedronis: 10% user
<pedronis> maybe
<pedronis> it depends
<zyga> pedronis: if the point of the test is to check if it runs for normal people
<zyga> su is not it
<zyga> it does depend
<zyga> but we should generally not use su, because it depends is complicated
<pedronis> is still not a good use of time all things considered
<pedronis> at this point in time
<zyga> sure, at some point it will though
<pedronis> yea
<pedronis> let's try to get there
<zyga> indeed :)
 * zyga wrote a comment on https://github.com/snapcore/snapd/pull/7825#issuecomment-600861003 that is sad but relevant
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> (not to this discussion though)
<zyga> and I'm back to being away
<mvo> zyga: we prefer "win the lottery" instead of "hit by bus" - just saying :)
<zyga> mvo: if I win a lottery I will perpetually send patches for things I like and not worry about paycheck ;)
<zyga> mvo: *then* you get the bus :)
<zyga> I've installed buster now
<zyga> and installing nvidia driver
<ijohnson> haha
<mvo> ha!
 * mvo really calls it a day
<zyga> mvo: can you dput to buster-backports?
 * zyga wonder if he saw that
<zyga> nvidia + debian = :(
<zyga> + snaps
<ppd> zyga: Not so nice to hear. Thanks for investigating the Nvidia problem though
<cmatsuoka> cachio: #8260 tests failed
<mup> PR #8260: tests: enable nested on core20 and test current branch <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8260>
<cachio> cmatsuoka, I'll push a small change now to retrigger this
<cachio> need to wait until tests pass here
<cmatsuoka> it seems that tests are especially slow today
#snappy 2020-03-19
<mup> PR snapcraft#2984 opened: plugins: move the existing plugin to a new package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2984>
<mborzecki> morning
<zyga> Uh
<zyga> Morning
<zyga> Iâm so tired today
<zyga> Too much work yesterday
<zyga> Is mvo around?
<mborzecki> zyga: hey
<mborzecki> zyga: he doesn't seem to be online yet
<pedronis> mvo: hi, #8278 can be merged if you are ok with my last bit of changes
<mup> PR #8278: devicestate: disable cloud-init by default on uc20 <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8278>
<mvo> pedronis: let me check, I just summarzied the core refresh issue but that's summarized now, still in the dark about it
<mvo> pedronis: how are tests looking? lots of red yesterday I noticed
<pedronis> mvo: snapd-failover still fails sometimes, Ian knows
<pedronis> mvo: other tests are flaky as well, the cgroup named one fails sometimes
<mvo> pedronis: meh, that one is really a tough one
 * mvo nods
<mvo> pedronis: I go over the prs and see if there is anything I can do
<pedronis> mvo: there are some uc20 that need 2nd reviews, I need to re-review some as well
<pedronis> mvo: zyga left a comment in #8295 about 14.04
<mup> PR #8295: osutil: do not leave processes behind after the test run <Created by mvo5> <https://github.com/snapcore/snapd/pull/8295>
<pedronis> mvo: there might be 2.44 things to backport for .1 ?
<pedronis> I mean things landed on master
<pstolowski> morning
<mvo> pedronis: yeah, checking that too, thank you
<mvo> pstolowski: good morning
<mvo> hm,snap-confine-undesired-mode-group seems to fail fairly often, should we disable it until we have a fix?
<mup> PR snapd#8292 closed: travis.yml: run unit tests on master as well <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8292>
<mup> PR snapd#8291 closed: packaging,tests: ensure debian-sid builds without vendor/ <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8291>
<pedronis> mvo: it does
<mup> PR snapd#8290 closed: run-checks: tweak formatting checks <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8290>
<pstolowski> pedronis: hi, re search v2 pr & 400s, i think they were temporary (proxies catching up with latest fix?), i  think i saw them before when working on this after Tony deployed new fix. i've re-run two of the failing tests a moment ago and they passed. just kicked travis on that PR again, let's see how it goes today
<mup> PR snapd#8278 closed: devicestate: disable cloud-init by default on uc20 <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8278>
<pedronis> pstolowski: ok, please also sync with him because I think they are discusing s/search/find/ in the endpoint
<pedronis> as well
<pstolowski> yes i saw the email
<pedronis> mborzecki: hi, can you look at #8159 again, I don't think it's doing what we discussed, but maybe I'm confused
<mup> PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
<ackk> zyga, hi, do you need any other info WRT #1841137 ?
<mup> Bug #1841137: /dev/loopX devices left around for removed snap revisions <snapd:Confirmed for zyga> <https://launchpad.net/bugs/1841137>
<mborzecki> pedronis: yeah, tweaking it a bit already, idk but sfdisk manpage is super confusing abut the attrs format
<mborzecki> at least the way it's printed seems stable, even if not 'well defined'
<pedronis> mborzecki: ok, if you are working on it, let's drop forcing the luks type (I think overriding the gadget content without thinking it through is risky/unexpected)
<pedronis> this was discussed already anyway yesterday
<zyga> ackk: hey
 * zyga is so tired today
<zyga> mvo: about that issue affecting that customer device
<zyga> mvo: I was wondering
<zyga> is it the only one that crashes?
<zyga> or is it affecting other identical devices
<zyga> mvo: please don't disable it, I'll filter out files that are not made by this test from it
<zyga> mvo: it really shows we leak cgroups/sessions across tests
<zyga> mvo: not that the test is broken per se
<mvo> zyga: in a meeting, will get back to you
<mvo> zyga: multiple identically devices are not refreshig (3/3)
<zyga> mvo: in that case it's a real bug :|
<mup> PR snapd#8298 opened: many: enumerate system seeds, return them on the /v2/systems API endpoint <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8298>
<mborzecki> pedronis: mvo: ^^
<mvo> mborzecki: thanks, in a meeting right now
<ackk> zyga, fwiw it seems the snap-discard-ns trick doesn't always work before removing the snap. I had to run it multiple times
<ackk> zyga, also: https://paste.ubuntu.com/p/dcwFrV6yxp/ (the script does a bunch of snap connect)
<zyga> ackk: oh?
<zyga> ackk: I'm in a call
<ackk> sorry
<zyga> uh
<zyga> 360 reviews are due today
<pedronis> zyga: they were due, the window is closed
<zyga> yeah, I noticed now :/
<zyga> oh bummer
<zyga> mvo: I'm connected to Tw VPN
<mup> PR snapd#8286 closed: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8286>
<mup> PR snapd#8293 closed: packaging: add README.source for debian <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8293>
<zyga> brb
<mborzecki> mvo: an idea to play with in https://github.com/snapcore/snapd/pull/8295#discussion_r394941827
<mup> PR #8295: osutil: do not leave processes behind after the test run <Created by mvo5> <https://github.com/snapcore/snapd/pull/8295>
<mborzecki> mvo: seems to work locally here
<mvo> mborzecki: nice one, do you think that's easier/more reliable? I have no strong opinion either way
<mborzecki> mvo: we could turn it into a cleanup helper and reuse ;)
<mvo> mborzecki: sure, works for me
<mborzecki> mvo: hmm still, it's not enough for mocks, we should probably track the main pid in the template
<mvo> mborzecki: yeah, let's not spend too much time on this until we have more time (unless it's quick :) we have some bigger fish to fry right now
<mborzecki> mvo: otoh, when we exec.Command(), we ought to take care of the child process too and kill the whole group
<mvo> mborzecki: (if you have something relatively quick and clean, by all means, that's fine of course, use your judgement)
<ackk> zyga, fwiw I'm getting that "read only" error even in a VM (so no snapfuse)
<mvo> mborzecki: indeed
<mup> PR snapd#8299 opened: devicestate,sysconfig: support "cloud.cfg.d" in uc20 for grade: dangerous <Created by mvo5> <https://github.com/snapcore/snapd/pull/8299>
<mborzecki> mvo: oh, and we even have a osutil.KillProcessGroup helper ;)
<ackk> zyga, n/m, I didn't have robust namespace on
<zyga> :)
<mborzecki> mvo: wdyt about this: https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/process-fun-fun ?
<mvo> mborzecki: +1
<mvo> mborzecki: that looks pretty neat
<mvo> mborzecki: looks like the exit 1 on gofmt makes a bunch of stuff red
<mborzecki> mvo: which PR?
<mvo> mborzecki: the most recent two ones, mine and yours
<mborzecki> hmm wth is the diff output trimmed?
<mborzecki> mvo: ehh https://github.com/snapcore/snapd/pull/8300
<mup> PR #8300: boot: apply Go 1.10 formatting <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8300>
<mup> PR snapd#8300 opened: boot: apply Go 1.10 formatting <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8300>
<mborzecki> at least we can skip spread now ;)
<mvo> mborzecki: indeed, thanks for that!
<mborzecki> uhh
<mborzecki> #8300 is green
<mup> PR #8300: boot: apply Go 1.10 formatting <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8300>
<mup> PR snapd#8269 closed: apparmor: use rw for uuidd request to default and remove from elsewhere <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8269>
<pstolowski> mvo: restarted #8251, would be nice to land it after it gets 2nd review
<mup> PR #8251: overlord: remove unneeded overlord.MockPruneInterval() mocks <Created by mvo5> <https://github.com/snapcore/snapd/pull/8251>
<mvo> pstolowski: yeah, thank you!
<mup> PR snapd#8300 closed: boot: apply Go 1.10 formatting <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8300>
<pstolowski> zyga: do we have any plan to move https://github.com/snapcore/snapd/pull/7205 forward? should we close it and re-open when needed?
<mup> PR #7205: rfc: introduce confinement options failsafe flag <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7205>
<zyga> I think the plan is to emit warnings indeed
<pedronis> pstolowski: thanks for the review of 8277 , I haven't yet looked at why/which of the spread tests fail
<pstolowski> sure
<pstolowski> pedronis: btw #8283 has a conflict
<mup> PR #8283: overlord,timings,daemon: separate timings from overlord/state <Created by pedronis> <https://github.com/snapcore/snapd/pull/8283>
<pedronis> fun, not
<pedronis> anyway I'll look when it gets a 2nd review
<pedronis> thanks for noticing it though
<mup> PR snapd#8191 closed: [RFC] cmd/snap-recovery-chooser: add a recovery chooser <Needs Samuele review> <UC20> <â Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/8191>
<ijohnson> morning folks
<cmatsuoka> good morning ijohnson
<ijohnson> hey cmatsuoka
<pstolowski> hi ijohnson
<ijohnson> o/ pstolowski
<pstolowski> and hi cmatsuoka !
<pstolowski> #8251 needs 2nd review (and is super simple)
<mup> PR #8251: overlord: remove unneeded overlord.MockPruneInterval() mocks <Created by mvo5> <https://github.com/snapcore/snapd/pull/8251>
<mup> PR snapcraft#2985 opened: static: ignore direnv created artifacts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2985>
<pedronis> pstolowski: I did another pass on search v2, looking good, still some comments/questions though
<pstolowski> pedronis: thanks
<pedronis> pstolowski: also seems they are going ahead with /find, sync with Tony about timeline for that
<pedronis> we'll have to bump the version check as well
<jdstrand> mvo: hey, are you still collecting PRs for 2.44 or is it baked?
<pedronis> jdstrand: 2.44 itself is kind of baked, but we'll do a .1 very likely
<pedronis> jdstrand: OTOH we are looking only for really neccesary or low risk even for .1
<pedronis> mborzecki: I reviewed #8298, thank you
<mup> PR #8298: many: enumerate system seeds, return them on the /v2/systems API endpoint <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8298>
<mborzecki> pedronis: thanks!
<jdstrand> pedronis: I may have something that meets that criteria to address an issue in the firefox snap that kenvandine and jamesh highlighted elsewhere
<pedronis> cmatsuoka: I re-reviewed #8159
<mup> PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
<cmatsuoka> pedronis: thanks, re-checking it...
<mvo> jdstrand: still collecting for a 2.44.1 that will happen
<jdstrand> mvo: ok, don't wait on me. if I get you something fine, if not, also fine :)
<jdstrand> mvo: thanks!
<mvo> jdstrand: yeah, 2.44 is out but we already know we will do a point release with some tweaks we want to have in 20.04-final
<jdstrand> kenvandine: hey, can you read and comment on my assessment in https://bugs.launchpad.net/snapd/+bug/1868051 ?
<mup> Bug #1868051: browser-support[allow-sandbox=true] should not grant access to /var/lib/snapd/desktop/applications <snapd:Triaged> <https://launchpad.net/bugs/1868051>
<mup> PR snapcraft#2986 opened: packaging: use find_namespace_packages in setup.py <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2986>
<jdstrand> kenvandine: to be clear, I'd like your (or jamesh) feedback in a bug comment in bug #1868051 before I do anything
<mup> Bug #1868051: browser-support[allow-sandbox=true] should not grant access to /var/lib/snapd/desktop/applications <snapd:Triaged> <https://launchpad.net/bugs/1868051>
<kenvandine> jdstrand: thanks!
<kenvandine> jamesh: can you please comment on that?
<kenvandine> jdstrand: another issue is what to do when firefox wants to open a file rather than download it
<kenvandine> right now that goes in TMPDIR
<kenvandine> which of course apps do not have access too
<jdstrand> kenvandine: I think you mean that the file goes in firefox's /tmp but the other app isn't able to open it because either a) firefox says it is in /tmp when it is actually in /tmp/snap.firefox and b) the permissions on /tmp/snap.firefox are such that non-root can't access it
<jdstrand> kenvandine: IME, firefox plugs 'home'. patch it to default to ~/Downloads instead
<jdstrand> kenvandine: there is another option using the content interface to export 1777 $SNAP_COMMON/tmp or similar, but then other snaps need to know to plugs it so not really scalable
<kenvandine> yeah
<kenvandine> jdstrand: i've played with setting TMPDIR and have proven it works
<kenvandine> but, $HOME/Downloads has a couple issues
<kenvandine> $HOME isn't $REALHOME in the snap
<kenvandine> and
<kenvandine> ~/Downloads could be translated
<jdstrand> kenvandine: other options are what were discussed before, a special way to opt out of per-snap tmp. this needs design and snapd changes. that also doesn't work for other snaps since we actually want per-snap /tmp and they wouldn't be able to access host /tmp
<kenvandine> I guess I could add a script to the command-chain to get $REALHOME and the translated Downloads dir
<kenvandine> just worry about that being fragile
<jdstrand> kenvandine: well, yes, of course you would have to do reall hame (getent passwd $(id -u) | cut -f 6 -d ':')
<jdstrand> real home*
<jdstrand> kenvandine: and the snap would be free to use a translated Downloads
<kenvandine> yeah, that's well known.  just need a script to set that.  can't do it in the yaml
<kenvandine> i'd need to shell out to xdg to get the translated Downloads
<kenvandine> should work fine... but i worry about corner cases :)
<jdstrand> kenvandine: iirc, you only need to do this once since firefox remembers the last one
<jdstrand> kenvandine: I know that is true for when downloading a file
<jdstrand> kenvandine: it might not be for /tmp itself
<jdstrand> kenvandine: but, it could be adjusted to follow the download location
<jdstrand> kenvandine: perhaps it honors TMPDIR?
<kenvandine> it does
<kenvandine> so i just need to set TMPDIR in the snap
<jdstrand> kenvandine: in which case, on snap startup you could in a wrapper, calculate realhome, calculate the translated dir name and then set TMPDIR before firefox starts
<kenvandine> i'm just thinking through what i want to set that too before submitting a patch to mozilla
<jdstrand> kenvandine: maybe you want to set it to realhome/Downloads/firefox.tmp.
<jdstrand> kenvandine: in this manner, actually temp files don't clutter Downloads and if things don't get cleaned up like they should, someone can clean it out
<jdstrand> actual*
<kenvandine> i like that idea
<jdstrand> kenvandine: or even .firefox.tmp
<jdstrand> kenvandine: firefox itself (or the wrapper), could clean up things, deleting stuff older than say, a week
<jdstrand> (be careful doing that, don't follow symlinks!!)
<jdstrand> kenvandine: basically, there is no clear way to make /tmp work that works will with other snaps too (not without some rather deep and/or super magical integration with snapd), but home is shared by most everything that would open a file in this manner
<jdstrand> man typos
<jdstrand> works well*
<kenvandine> :)
<kenvandine> jdstrand: ok, thanks for the feedback.  i'll continue with my original plan
<kenvandine> but add firefox.tmp to it
<jdstrand> np
<jdstrand> kenvandine: fyi, from with snap run --shell firefox:
<jdstrand> $ xdg-user-dir DOWNLOAD
<jdstrand> /home/jamie/Downloads
<kenvandine> yeah
<jdstrand> so you don't need the getent at all
<kenvandine> # Set TMPDIR to be under the user's default Downloads dir
<kenvandine> export TMPDIR=$(xdg-user-dir DOWNLOAD)/firefox.tmp
<kenvandine> handy
<kenvandine> and i'll add that to command-chain after desktop-launch to ensure xdg user dirs are all setup
<jdstrand> kenvandine: you probably know this, but xdg-user-dir just looks at ~/.config/user-dirs.dirs whish in the case of firefox is $SNAP_USER_DATA/.config/user-dirs.dirs
<kenvandine> jdstrand: yeah, desktop-launch does some stuff to ensure those are set properly
<jdstrand> kenvandine: I guess so long as that user-dirs.dirs is setup right, you're good
<jdstrand> cool
<jdstrand> kenvandine: this should really help. the wrapper may want to mkdir that directory. it is too bad that the snap probably needs to keep it clean, but hey, not a terrible solution to the problem overall
<pstolowski> pedronis: hey, do you have a moment for HO?
<kenvandine> firefox does create it if it doesn't exist
<pedronis> pstolowski: yes
<pstolowski> pedronis: joining standup HO
<tkamppeter> jdstrand, hi
<tkamppeter> jdstrand, what about a meeting about the interface for the new CUPS Snap?
<kyrofa> ijohnson, any insight into how to make https://forum.snapcraft.io/t/no-interfaces-without-core-snap a better experience?
<kyrofa> It's an unfortunate situation
<ijohnson> kyrofa: upgrade snapd everywhere ?
<ijohnson> kyrofa: the issue is that its a bug we have solved everywhere in new snapd, and devices keep hitting the bug because there seems to be old snaps in many places
<kyrofa> ijohnson, that's not a solution I'm afraid
<kyrofa> ijohnson, not one that scales
<kyrofa> ijohnson, the problem is that it's standard practice to only install security updates in prod
<ijohnson> I mean whatever solution I can come up with involves changes to snapd, which only happens if you get an upgraded snapd ... hence the problem
<ijohnson> perhaps others have thoughts, but I don't know how we can make old snapd's change behavior without updating old snapd
<kyrofa> ijohnson, we have abused the security component in the past, is that an option?
<ijohnson> kyrofa: you mean push an update to -security ?
<kyrofa> Indeed
<ijohnson> yeah that doesn't sound like a bad idea to me, I think there is some precedent for that, we have done that to solve this exact problem on trusty for example
<ijohnson> that would be a mvo request though
<kyrofa> Exactly my thinking. Not pretty, not ideal, but not unprecedented
<ijohnson> yep
<kyrofa> mvo, you should consider that as core18 becomes the standard
<kyrofa> ijohnson, mvo, I'll add a comment about this to the forum post
<ijohnson> kyrofa: thanks
<pedronis> kyrofa: we do need the agreement of the security team to do that
<pstolowski> pedronis: --mask/unmask work with --root ð
<pedronis> pstolowski: good
<jdstrand> tkamppeter: hey, I saw the discussions. can you put something in the calendar for sometime next week? Tue, Wed or Thu is best for me
<jdstrand> tkamppeter: I've been wanting to review all the discussions again (I've read them) and think through everything in preparation for the meeting
<tkamppeter> ijohnson, around?
<ijohnson> tkamppeter: yes
<ijohnson> Next week is fine for me
<ijohnson> tkamppeter Please include pedronis in the meeting though
<pedronis> I will not be available Thu or Fri
<tkamppeter> OK, should we do wed, 25, at 3pm UTC?
<tkamppeter> jdstrand, ijohnson, pedronis, me, someone else?
<tkamppeter> Or better mon, 23, at 3pm UTC?
<ijohnson> tkamppeter: I don't think we need anyone else in the meeting, and 3 pm UTC works for me, but I prefer Wed instead of Mon
<tkamppeter> So let us do Wed then.
<tkamppeter> jdstrand, ijohnson, pedronis: Done. You should have gotten an invitation.
<ijohnson> got it, thanks tkamppeter
<mvo> kyrofa: sorry, lacking context
<mvo> kyrofa: can you give me a tl;dr
 * cachio lunch
<kyrofa> mvo, quick read: https://forum.snapcraft.io/t/no-interfaces-without-core-snap . tl;dr if you have a bionic install with a snapd that hasn't been updated, you can't install a core18 snap
<jdstrand> tkamppeter: you didn't check for meeting conflicts :(
<kyrofa> At least, not without also manually installing the core snap or manually updating snapd first so it installs the snapd snap
<tkamppeter> jdstrand, so I hit another meeting of yours? I will go through all three where I find a slot.
<jdstrand> tkamppeter: that is in conflict for me. all day tuesday is open for me, and most of thursday. wednesday my morning has a conflict
<jdstrand> tk thanks
<jdstrand> tkamppeter: thanks :)
 * jdstrand lunch
<tkamppeter> jdstrand, pedronis, ijohnson: How do I check the participant's meeting schedules?
<tkamppeter> ijohnson, pedronis, what do you prefer? Tue, or Thu?
<pedronis> Thu I'm off
<tkamppeter> So Tue is left, ijohnson, does it work for you?
<jdstrand> tuesday, again, is good for me at around the same time up to two hours earlier or 6 hours later
<jdstrand> tkamppeter: (to answer your question, I temporarily add people to Other calendars to see if there is a conflict. there might be a better way)
<mvo> kyrofa: yes, that's correct, we fixed this a while ago but not everybody got the fix :(
<jdstrand> ok, really going to lunch now
<kyrofa> mvo, right, exactly
<mvo> kyrofa: it's a good question what we can do, we could (ab)use the security pocket so that people get the update via unattended-upgrades but it's a bit borderline
<tkamppeter> So let me do a time guess which should hit a slot on all of you: Tue, 24, 1pm UTC
<ijohnson> tkamppeter: sorry I was away
<tkamppeter> ijohnson, jdstrand, pedronis: Is  Tue, 24, 1pm UTC OK for all of you?
<ijohnson> tkamppeter: yes that's fine for me
<kyrofa> mvo, indeed. Is there any other option?
<jdstrand> tkamppeter: yes
<tkamppeter> pedronis?
<pedronis> tkamppeter: doesn't work for me, but maybe you should have a first meeting just with ijohnson and jdstrand and see how far you get
<mvo> kyrofa: we could grow something in the wrapper/command-chain that detect snap versions older than the fixed one (2.41? need to check changelog) and warn but that won't work so well for gui apps and is also not a amazing UX
<tkamppeter> pedronis, do you have another slot, which could hit a free slot of jdstrand?
<kyrofa> mvo, wouldn't that also be a snapd update, though?
<pedronis> Tue 3p pm UTC
<mup> PR snapcraft#2985 closed: static: ignore direnv created artifacts <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2985>
<ijohnson> tkamppeter: I looked at everybody's calendars and propsoed a time which should work for everybody
<kyrofa> mvo, or is that something you can put in core18?
<ijohnson> tkamppeter: pedronis ah I think I proposed the same time that pedronis said
<tkamppeter> ijohnson, which one is that time?
<ijohnson> it's 10 am cst, I don't know what UTC time it is
<tkamppeter> ijohnson, could you create a meeting at that hour, and invite me, so I will see where it falls.
<ijohnson> tkamppeter: if you check your email you should get an email with the proposed time
<mvo> kyrofa: a warning from the installed snap would be on the snap side, i.e. when you install snap foo and run "foo.bar" it would detect in the wrapper/command-chain. but it's not a great experience, I'm not really advocating it, just trying to come up with ideas
<mvo> kyrofa: oh, maybe we could put "assumes: [snapd2.41]" into core18
<mvo> kyrofa: I wonder if that would work
<tkamppeter> ijohnson, nothing appeared yet.
<kyrofa> mvo, ah, which implies a snapcraft change, and an assumption that the snap being installed was built recently
<kyrofa> mvo, the assumes would just prevent install, right?
<mvo> kyrofa: correct, not a great option
<kyrofa> But at least it TELLS them something
<mvo> kyrofa: it would but with a somewhat useful message
<kyrofa> Indeed
<mvo> kyrofa: it might be worth a shot
<kyrofa> Right now it's just broken, and the user is left holding the pieces wondering what to do
<kyrofa> sergiusens, you around?
<mvo> kyrofa: exactly, we would have to test it, not sure how exactly the UX looks like but I think it's probably better than what we do right now
<mvo> kyrofa: thank you for raising this btw
<ijohnson> tkamppeter: I sent an invite, I guess you have a meeting that goes til 10:30, I think a 30 minute meeting is enough for now
<kyrofa> mvo, my pleasure. I think it would be trivial to add this to snapcraft, which will move things in the right direction. Mull over the -security abuse, though
<kyrofa> mvo, I'll update the forum thread with this
<sergiusens> kyrofa: yes
<tkamppeter> ijohnson, could we move it to half an hour later?
<sergiusens> kyrofa: a bit hectic today though... the country is closing down and I am dealing with accomodations for a period where we do not know what will stay open
<tkamppeter> Or is it really the only 1-hour hole in the week for all the 3 of you?
<kyrofa> sergiusens, then ignore me. I'll ping you in the forum, look when you can
<sergiusens> kyrofa: it is fine now :-) Might not be later :-)
<tkamppeter> If so, our Desktop team meeting is only IRC and usually ends after 30 minutes.
<mvo> kyrofa: thank you!
<ijohnson> tkamppeter: I moved it
<tkamppeter> ijohnson, I have moved it again, WDYT about this time?
<ijohnson> tkamppeter: which meeting, the tuesday one I set up or the monday one you set up ?
<kyrofa> sergiusens, to save you the scrollback then, I pinged you anyway: https://forum.snapcraft.io/t/no-interfaces-without-core-snap
<tkamppeter> ijohnson, the tuesday one, I did not realize that I have put mine on monday, because the Calendar is starting weeks with Sun.
<ijohnson> okay so the tuesday meeting is the one we will do
<tkamppeter> ijohnson, so I will remove my meeting and let the rest up to you. OK?
<ijohnson> sure sounds good
<mup> PR snapd#8159 closed: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
<sergiusens> kyrofa: replied on forum, short answer: we can
<tkamppeter> ijohnson, done.
<tkamppeter> Could you add the link https://forum.snapcraft.io/t/interface-request-cups-control-on-cups-snap-and-including-d-bus/ to the description? Thanks.
<ijohnson> done
<cmatsuoka> cachio: #8260 is still failing, shellcheck didn't like some stuff there
<mup> PR #8260: tests: enable nested on core20 and test current branch <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8260>
<abeato> ijohnson, hey, is it possible lready to run UC20 on kvm?
<tkamppeter> ijohnson, jdstrand, pedronis, I have sent you all an e-mail with the final settlement for the meeting. Please check.
<jdstrand> tkamppeter: ack, thanks! (accepted)
<cachio> cmatsuoka, fixed
<ijohnson> abeato: yes, do you have a dire need to boot uc20 on kvm soon? it's easy enough to seup but building images and such may change a bit from now until the release, so rather than have you get caught up in those changes if you can wait until the release that would be best
<abeato> ijohnson, I'm starting to develop snaps with base: core20, and I'd like to do some testing. But it looks like I can run them on UC18, it downloads core20. Is that a good enough environment for some initial testing?
<ijohnson> abeato yes for now that's probably good enough, as we can get closer we can help you run on actual uc20
<tkamppeter> jdstrand, thanks for the feedback.
<abeato> ijohnson, ok, then I have all I need, thanks
<mup> PR snapd#8260 closed: tests: enable nested on core20 and test current branch <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8260>
<mup> PR snapd#8301 opened: interfaces/many: deny arbitrary desktop files and misc from /usr/share <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8301>
<jdstrand> mvo: fyi, ^ was the PR I was thinking of for 2.44.1. after implementing it, I think it is too much for 2.44.1 and have milestoned if for 2.45 instead
<jdstrand> jamesh (cc kenvandine): I referenced https://github.com/snapcore/snapd/pull/8301 in https://github.com/snapcore/snapd/pull/8301
<mup> PR #8301: interfaces/many: deny arbitrary desktop files and misc from /usr/share <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8301>
<mvo> jdstrand: thanks
<jdstrand> erf
<jdstrand> jamesh (cc kenvandine): sorry, mispaste. I referenced https://github.com/snapcore/snapd/pull/8301 in https://bugs.launchpad.net/snapd/+bug/1868051
<mup> PR #8301: interfaces/many: deny arbitrary desktop files and misc from /usr/share <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8301>
<mup> Bug #1868051: browser-support[allow-sandbox=true] should not grant access to /var/lib/snapd/desktop/applications <snapd:In Progress by jdstrand> <https://launchpad.net/bugs/1868051>
<kenvandine> jdstrand: thanks!  I dropped jamesh and email earlier asking him to comment when he's back online
<mup> PR snapd#8302 opened: interfaces/greengrass-support: fix typo <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8302>
<mup> PR snapd#8303 opened: interfaces/greengrass-support: fix typo <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8303>
<mup> PR snapd#8283 closed: overlord,timings,daemon: separate timings from overlord/state <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8283>
<jdstrand> zyga: for tomorrow's standup. I wonder if bug #1866932 and bug #1867952 are dupes of bug #1865063
<mup> Bug #1866932: package snapd 2.44~pre1+20.04 failed to install/upgrade: installed snapd package post-removal script subprocess returned error exit status 1 <amd64> <apport-package> <focal> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1866932>
<mup> Bug #1867952: package snapd 2.44+20.04 failed to install/upgrade: installed snapd package post-installation script subprocess was killed by signal (Terminated)  <amd64> <apport-package> <focal> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1867952>
<mup> Bug #1865063: snapd package hangs on deb postinst <focal> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1865063>
<jdstrand> zy
<jdstrand> oh, ijohnson is here. zyga, nm
<jdstrand> ijohnson: fyi ^
<jdstrand> ijohnson: that might be something for 2.44.1. I don't have any more info to add; just fyi
<ijohnson> jdstrand: sorry what's this
<jdstrand> ijohnson: it is just so mvo is aware that there might be an issue with 2.44 and (at least) deb upgrades
<ijohnson> jdstrand: ack I'll make sure it's in the SU notes, but I don't have bandwidth to investigate right now unfortunately
<jdstrand> ijohnson: postinst isn't finishing
<jdstrand> ijohnson: oh, I wasn't asking you to look :) just bubbling it up so you can maybe mention it in standup
<mwhudson> what is the expected lag between pushing to an automatically built branch in launchpad and the build starting?
<mwhudson> i never quite know what to expect
<ijohnson> jdstrand: also did you see I needed to open another greengrass-support PR ? apparently what I had was insufficient
<ijohnson> they needed a slightly different access
<jdstrand> mwhudson: that is a good question. sometimes it seems fast and other times less so
<jdstrand> ijohnson: oh, not yet
 * jdstrand looks
<ijohnson> 8302 and 8303 IIRC
<jdstrand> ijohnson: approved
<ijohnson> thanks jdstrand !
<jdstrand> np
<mwhudson> jdstrand: i wonder if it's a */15 cron or something
<mwhudson> anyway my snap is now building
<jdstrand> mwhudson: it probably is cron. I had a fanciful idea that it would do it quickly if you hadn't committed in a while and then back off if you had :)
<jdstrand> mwhudson: sometimes I'm impatient and trigger it manually
<mwhudson> yeah i thought there was a threshold like that too but idk
<mwhudson> yeah and then you end up with two builds going at once :)
<jdstrand> it makes it twice as fun that way :)
<cjwatson> mwhudson,jdstrand: There is indeed a */15 cron job; it runs for any snap that's configured to build automatically, whose source branch has been modified since the last automatic build was dispatched, and which hasn't had an automatic build dispatched in the last hour.
<cjwatson> When the build actually *starts* after that will of course depend on build farm load etc.
<mwhudson> cjwatson: does pushing a new tag count as modification?
<mwhudson> cjwatson: and, hah for me guessing the frequency
<cjwatson> mwhudson: No.
<cjwatson> mwhudson: Modification is detected per-ref, so you'd need to actually change the specific branch that the snap builds from.
<mwhudson> cjwatson: makes sense
<cjwatson> (More specifically, when you push changes to a git repository in LP, any snaps based on refs that have changed are marked as stale.)
<cjwatson> It's fairly similar to the recipe staleness logic, which you may distantly remember from bzr.
<mwhudson> very distantly :)
#snappy 2020-03-20
<mup> PR snapd#8304 opened: usersession/userd: add zoommtg url support <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8304>
<mborzecki> morning
<zyga> hey :)
<zyga> coffee
<zyga> I'm a bit tired today
<zyga> cannot stop working till NaN o clock
<zyga> yawn
<zyga> I need a break today
<zyga> I'll be back later
<zyga> I just need to rest
<mborzecki> zyga: fwiw it's officially spring now
<mborzecki> hmm broke snapd somehow
<zyga> oh spring
<zyga> too bad we cannot leave home
<zyga> I need to burn overtime
<pstolowski> mornings
<mvo> hey pstolowski
<mvo> and good morning mborzecki
<mborzecki> pstolowski: mvo : hey!
<zyga> hey mvo and pawel
<pstolowski> o/
<zyga> mvo: I filed for the day off, I just need to slow down and not work till 22
<zyga> plus, it's spring as maciek told me
<mup> PR snapd#8251 closed: overlord: remove unneeded overlord.MockPruneInterval() mocks <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8251>
<mup> PR snapd#8302 closed: interfaces/greengrass-support: fix typo <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8302>
<mup> PR snapd#8303 closed: interfaces/greengrass-support: fix typo <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8303>
<pstolowski> zyga: do you know if the focal can be safely updated now?
<pedronis> pstolowski: snap-preseed -reset in actually in beta now I think
<pstolowski> pedronis: but they need the deb for snap-preseed command (or build it themselves)
<pedronis> pstolowski: yes, just pointing out that is not just in edge
<pstolowski> pedronis: i see, ok, i'll send an update, core from beta + ppa for snap-preseed
<mvo> pedronis, pstolowski it's in 2.44 which is in focal right now if that helps
<pedronis> I suppose it might not, but mostly to show some progress in releasing this
<zyga> pstolowski: yes it can
<pstolowski> mvo: that's nice, thanks, i suppose they need xenial though
<zyga> I just fixed my laptop
<pstolowski> (nonetheless i'll mention this)
<pstolowski> zyga: ack, ty
<zyga> pstolowski: yah, now back in graphical mode
<zyga> if you need to fix but don't have a bootable helper
<zyga> you can enable debug shell
<zyga> set static IP address over eth0
<zyga> and upgrade libcrypt
<zyga> then it works
<pstolowski> zyga: i just upgraded, didn't have to do anything (but i haven't updated for a while, had ~250 packages to upd)
<zyga> pstolowski: it was only bad if you upgraded over that weekend when it was broken
<pstolowski> zyga: yeah, i just avoided a bad package
<mup> PR snapd#8305 opened: cmd/snap-recovery-chooser: add recovery chooser <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8305>
<mborzecki> mvo: ^^
<mborzecki> time to tweak do the tweaks in 8298
<mup> PR snapd#8200 closed: [RFC] cmd/snap-chooser-ui-demo: a demo of recovery chooser UI <Skip spread> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/8200>
<mvo> mborzecki: thank you
<pedronis> #8208 still needs a 2nd review
<mup> PR #8208: boot_test: add many boot robustness tests for UC20 kernel MarkBootSuccessul and SetNextBoot <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8208>
<axino> hey bdx have you seen https://github.com/snapcrafters/sentry/issues/29 ?
<mvo> pedronis: looking at this now
<mup> PR snapd#8208 closed: boot_test: add many boot robustness tests for UC20 kernel MarkBootSuccessul and SetNextBoot <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8208>
<zyga> I'm technically off today but +1 on https://github.com/snapcore/snapd/pull/8242 - let's land it
<mup> PR #8242: many: improve environment handling, fixing duplicate entries <Bug> <Needs Samuele review> <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
<zyga> I have a moment while lucy is sleeping
<zyga> shall I just merge it?
<mvo> zyga: it has two +1 so should be fine
<zyga> ok
<zyga> squashing and merging
<mvo> thanks!
<zyga> I *love* fixing bugs
<mup> PR snapd#8242 closed: many: improve environment handling, fixing duplicate entries <Bug> <Needs Samuele review> <Squash-merge> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8242>
<pedronis> mvo: about cloud-init and u-i, are you thinking of making --cloud-init work somehow for 20, at least for dangerous?
<pedronis> I'm not quite sure what it does for 16/18
<ackk> hi, when an automated snap refresh fails, does hook stdout/stderr get logged somewhere?
<mup> PR snapd#8306 opened: snap-bootstrap: add partition creation helper <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8306>
<pedronis> mvo: master has formatting issues now, I think the env pr had still those test off so we didn't notice:  https://travis-ci.org/github/snapcore/snapd/jobs/664797858?utm_medium=notification&utm_source=github_status
<axino> hi, does anyone have any idea if this is a snap bug or a snapd bug ? https://github.com/snapcrafters/sentry/issues/30
<mvo> pedronis: uh, ok. is someone on it already or should I do a quick PR?
<ackk> axino, snaps can only access shm files under /dev/shm/$SNAP_NAME.*
<ackk> axino, snapcraft-preload can help there
<ackk> axino, https://github.com/sergiusens/snapcraft-preload
<mup> PR snapd#8307 opened: snap: run gofmt -s <Simple ð> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8307>
<pedronis> mvo: thanks, I was having lunch
<mvo> pedronis: me too
<jdstrand> cjwatson: ah, thanks for confirming! hey mwhudson, we weren't too far off :)
<mup> PR snapd#8307 closed: snap: run gofmt -s <Simple ð> <Skip spread> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8307>
<ijohnson> hello folks
<mup> PR snapcraft#2987 opened: spread tests: set appropriate default base in snapcraft.yamls <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2987>
<pedronis> ijohnson: hi
<ijohnson> hey pedronis
<ijohnson> you were up pretty late last night :-)
<pedronis> indeed I was
<ijohnson> any more thoughts on what else might be triggering snapd/snap things to run in early boot?
<ijohnson> as I mentioned in the SU doc, I don't think it's necessarily the autoimport, because with the removal of that it still took a long time to boot, suggesting that there's something else that needs lots of entropy from 2.44 in early boot
<pedronis> ijohnson: I think really early boot was probably "snap auto-import", after that I would say any snap service
<pedronis> because of the implied snap run
<pedronis> ijohnson: the syslog thing would tell us for sure
<ijohnson> I see you have a branch in the SU doc, shall I try that one?
<pedronis> ijohnson: yes, that's the real fix I would do for 2.44 , if it still works
<pedronis> it might not, depending
<ijohnson> should I do that before the syslog branch then?
<ijohnson> in any case, probs won't get results til after SU, I have to re-reserve the system
<pedronis> ijohnson: I thought you needed help for the syslog one, whatever order works best for you
<ijohnson> well for the syslog branch if I add that with the removal of the autoimport, the system does eventually boot, so I think we should be able to get the data there, it just will take a while
<pedronis> ijohnson: ah, yes combining would work well, we should be able to see what is the first requester
<pedronis> knowing that otherwise it would be one of the auto-import
<ijohnson> yes, but I also need to turn on persistent logs, because I noticed from the auto-import system journal logs I added to the SU doc that they didn't go all the way back
<pedronis> ok
<pedronis> ijohnson: anyway as I said in the SU doc, it's good we have likely a fix, but it would be also good to understand the full problem because other it might get back later
<pedronis> ijohnson: also mvo is pursuing seeing if the kernel can help, because we control snapd, but other things might start wanting entropy early
<mup> PR snapcraft#2988 opened: tests: add two more workers to the 18.04 systems <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2988>
<mup> PR snapd#8308 opened: tests: umount partitions which are not umounted after remount gadget <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8308>
<ijohnson> pedronis: still waiting for that syslog change + no autoimport to boot, been like 20 minutes now so it should be any minute now, but it also could be racy that the no autoimport change from yesterday booted :-/
<pedronis> ijohnson: worse case we can mix my full fix and logging
<ijohnson> yes
<pedronis> ijohnson: I can propose something if you want
<ijohnson> if you want to sure, but I think I'll give it some more time
<pedronis> ijohnson: https://github.com/pedronis/snappy/tree/randutil-syslog-fixed-sim-2.44
<ijohnson> pedronis: yeah the boot failed, I gave up on it, I'm gonna retry one more time
<ijohnson> then I'll try your branch
<pedronis> pstolowski: fyi #8277 is now green and I have applied your comments
<mup> PR #8277: asserts,o/devicestate: support model specified alternative serial-authority <Created by pedronis> <https://github.com/snapcore/snapd/pull/8277>
<pstolowski> pedronis: ok
<ijohnson> it would be great to land #8308 asap, since a number of open PR's are hitting the issued fixed there
<mup> PR #8308: tests: umount partitions which are not umounted after remount gadget <â  Critical> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8308>
<mup> PR snapd#8308 closed: tests: umount partitions which are not umounted after remount gadget <â  Critical> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8308>
<mup> PR snapd#8309 opened: o/configcore: implement Apply method for early configuration of core <Created by stolowski> <https://github.com/snapcore/snapd/pull/8309>
<abeato> ijohnson, hey, iptables is not included in the core20 snap, is that a bug?
<abeato> ijohnson, firewall-control gives permissions to use it
<ijohnson> abeato: yes sounds like a bug, perhaps xnox can fix that easily
<ijohnson> core20 is also on github if you wanted to take a look you're self and file a MP
<ijohnson> abeato: https://github.com/snapcore/core20
<abeato> ijohnson, thanks, I'll create an issue there
<mup> Issue core20#27 opened: iptables is missing <Created by alfonsosanchezbeato> <https://github.com/snapcore/core20/issue/27>
<xnox> hm https://github.com/snapcore/core20/issue/27 is 404 for me?!
<mup> Issue core20#27: iptables is missing <Created by alfonsosanchezbeato> <https://github.com/snapcore/core20/issue/27>
<xnox> oh
<xnox> can we fix mup?
<xnox> it needs to be "issues" not "issue"
<ijohnson> xnox: I've mentioned it before to niemeyer
<niemeyer> We can.. I've been working on mup in the last couple of weeks.. that will certainly be addressed
<niemeyer> I'm replacing the whole database backend.. that's why it's taking a bit.. apologies for that
<mup> PR snapd#8310 opened: randutil: ask for less entrop during boot  <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8310>
<mup> PR snapcraft#2989 opened: tests: only run catkin based snap on 16.04 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2989>
<cachio> mvo, hey, is cloud init PR already merged?
<cachio> mvo, or it is #8299 ?
<mup> PR #8299: devicestate,sysconfig: support "cloud.cfg.d" in uc20 for grade: dangerous <Squash-merge> <UC20> <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8299>
<ijohnson> cachio: #8278 was merged, but that just disables cloud-init for uc20, 8299 as you see is the PR which supports cloud-init from the ubuntu-seed partition
<mup> PR #8278: devicestate: disable cloud-init by default on uc20 <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8278>
<cachio> ijohnson, any idea when it is going to be merged?
<cachio> because the user assertion alternative is taking to much time
<ijohnson> cachio: I think it is close, afaik just needs pedronis to approve the new dir
<ijohnson> cachio: although maybe we need to wait for the cloud folks to approve the new dir location, not sure
<cachio> ijohnson, ah, ok
<ijohnson> i.e. rharper and company
<mvo> cachio: unfortunately not yet, it pending
<mup> PR snapd#8311 opened: randutil: don't consume kernel entropy at init, just mix more info to try to avoid fleet collisions <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8311>
<pedronis> mvo: ijohnson: ^
<ijohnson> thanks looking now
<mvo> pedronis: \o/
<mvo> pedronis: looking
<mvo> pedronis: added a small question, looks very good
<pedronis> mvo: I answered
<mvo> pedronis: aha, so seed is cumulative? it does not reset the state of the crng (sorry if that is a stupid question)?
<pedronis> mvo: the contrary, it resets it
<pedronis> but we use a value derived from the old one to make the new one
<mvo> pedronis: aha, of course, sorry, misread the code. makes perfect sense
<pedronis> mvo: and to be clear I'm not doing all this in init because I don't want by chance to slow down snap run
<pedronis> which shouldn't care
<mvo> pedronis: +1
<pedronis> mvo: cachio: I don't we should be blocked on the cloud people, they just need to be aware of the slightly different location, the other one was anyway different from 16/18
<pedronis> *I don't think
<pedronis> mvo: cachio: but I need to re-review it, which I will first thing Monday
<cachio> sure
<cachio> pedronis, is it any way to workaroud it while I am testing the new smoke suite executen in a nested uc20?
<cachio> pedronis, I mean, using cloudinit
<mvo> pedronis: thanks, enjoy your weeknd
<pedronis> mvo: I'm still around, waiting for the other results, but I don't think I can reviews right now
<mup> PR snapd#8310 closed: randutil: ask for less entropy during boot  <Squash-merge> <â  Critical> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8310>
<mup> PR snapcraft#2989 closed: tests: only run catkin based snap on 16.04 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2989>
#snappy 2020-03-21
<mup> PR snapd#8306 closed: snap-bootstrap: add creationSupported predicate for partition types <Simple ð> <UC20> <Created by cmatsuoka> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8306>
<TJ-> Hitting an issue on Ubuntu 20.04 trying to install charmed kubernetes. ssh fails to execute due to linking to the host's libpthread which doesn't have a symbol ssh expects - symbol exists in the snap/core libphthread but I assume due to operating unconfined the host's copy is being linked.
<TJ-> "ssh: symbol lookup error: /snap/core18/current/lib/x86_64-linux-gnu/libpthread.so.0: undefined symbol: __libc_vfork, version GLIBC_PRIVATE']"
<TJ-> seems related to bug #1860660
<mup> Bug #1860660: Strict confinement (was: microstack.init is broken on eoan) <MicroStack:Fix Released> <https://launchpad.net/bugs/1860660>
<mup> PR snapd#8312 opened: many: fix packages having mistakenly their copyright as doc <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8312>
<alvesarian> hello
<alvesarian> am getting a run time issue with jetty on a snap for a java server app
<alvesarian> $ gluu-server.jython
<alvesarian> Jython 2.7.2rc1 (v2.7.2rc1:1fcef1abf1d6, Mar 1 2020, 16:27:06)
<alvesarian> [OpenJDK 64-Bit Server VM (Amazon.com Inc.)] on java1.8.0_222
<alvesarian> Type "help", "copyright", "credits" or "license" for more information.
<alvesarian> >>>
<alvesarian> >>> f=open("/tmp/text.txt",'w')
<alvesarian> >>> f.write("test")
<alvesarian> >>> f.close()
<alvesarian> >>> import os
<alvesarian> >>> os.getuid()
<alvesarian> 1000
<alvesarian> >>> os.system('chown 1000 /tmp/text.txt')
<alvesarian> chown: changing ownership of '/tmp/text.txt': Operation not permitted
<alvesarian> 1
<alvesarian> >>> os.stat("/tmp/text.txt").st_uid
<alvesarian> 1000
<alvesarian> >>> >>> os.stat("/tmp/text.txt").st_gid
<alvesarian> 1000
<alvesarian> >>> os.getuid()
<alvesarian> 1000
<alvesarian> >>> os.getgid()
<alvesarian> 1000
<alvesarian> >>> os.chown("/tmp/text.txt", 1000, 1000)
<alvesarian> Traceback (most recent call last):
<alvesarian>   File "<stdin>", line 1, in <module>
<alvesarian> OSError: [Errno 1] Operation not permitted: '/tmp/text.txt'
<alvesarian> i cant chown or su -c
<mup> PR snapd#8311 closed: randutil: don't consume kernel entropy at init, just mix more info to try to avoid fleet collisions <Squash-merge> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8311>
<mup> PR snapd#8313 opened: release: 2.44.1 <Simple ð> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8313>
<mup> PR snapcraft#2990 opened: ci: remove osx test from Travis <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2990>
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145
<mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134, core18#144, core18#146, core18#148
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145
<mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134, core18#144, core18#146, core18#148
#snappy 2020-03-22
<mup> PR snapcraft#2990 closed: ci: remove osx test from Travis <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2990>
<mup> Issue pc-amd64-gadget#20 closed:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Issue pc-amd64-gadget#30 closed: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue pc-amd64-gadget#36 closed: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<mup> PR pc-amd64-gadget#35 closed: grub.cfg-boot: drop compatibility mode <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/35>
<mup> PR pc-amd64-gadget#37 closed: Drop duplicate grub.cfg-* <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/37>
<mup> PR pc-amd64-gadget#38 closed: grub.cfg-recovery: fix typo, filter vars when loading them <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/38>
<mup> Issue pc-amd64-gadget#20 opened:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Issue pc-amd64-gadget#30 opened: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue pc-amd64-gadget#36 opened: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<mup> PR pc-amd64-gadget#35 opened: grub.cfg-boot: drop compatibility mode <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/35>
<mup> PR pc-amd64-gadget#37 opened: Drop duplicate grub.cfg-* <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/37>
<mup> PR pc-amd64-gadget#38 opened: grub.cfg-recovery: fix typo, filter vars when loading them <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/38>
<mup> PR snapcraft#2986 closed: packaging: use find_namespace_packages in setup.py <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2986>
<mup> PR snapd#8314 opened: cmd/snap-failure,tests: try to make snap-failure more robust <Created by pedronis> <https://github.com/snapcore/snapd/pull/8314>
<sdhd-sascha> Hello everyone :-) stay healthy ;-)
