#snappy 2016-03-14
<netphreak> Hi, guys!
<netphreak> Are os updates to Ubuntu snappy automatically installed/pushed, or does it require some manual process?
<dholbach> good morning
<didrocks> good morning dholbach!
<dholbach> salut didrocks
<netphreak> Are os updates to Ubuntu snappy automatically installed/pushed, or does it require some manual process?
<didrocks> netphreak: they are automatically pushed, it will tell you and you will just need to reboot for some snaps to activate the new versions
<zyga-phone> good morning
<netphreak> ok.. If Ubuntu snappy is running on some IOT device. How do one manage a reboot?
<kyrofa> Good morning
<kyrofa> Daylight savings should die
<ogra_> kyrofa, it wouldnt be that bad if it'd actually bring in interest ;)
<kyrofa> ogra_, yeah that would improve things
<kyrofa> ogra_, any idea why I can't use screen within the classic dimension? I figure maybe a mount is missing
<ogra_> hmm, i never tried ...
<ogra_> (and working mostly on the dragonboard these days i dont have a working classic dimension)
<kyrofa> Ah, right
<ogra_> i'd blame lxc/lxd though
<kyrofa> ogra_, yeah I a
<kyrofa> m
<ogra_> ppisati, hmm, i have a hard time inplementing dragonboard kernel tarball/snap creation in livecd-rootfs due to a missing linux meta package for it
<ogra_> do you think we could have one ?
<ppisati> ogra_: we are discussing right now which 4.4 kernel to push to the archive for the db410c
<ogra_> (something like: "apt-get install linux-image-*-generic-dragon410c" installs all existing packages by that name for example, so i end up with three of them)
<ppisati> ogra_: you'll probably get that one
<ogra_> ppisati, we also need the firmware in the archive (restricted i guess)
<ogra_> (or in linux-firmware even ... if thats possible(
<didrocks> hey kyrofa, how are you?
<kyrofa> didrocks, excellent! And yourself?
<didrocks> kyrofa: I'm good, escaping meetings for a while, but blocked on some snapcraft thingy :p
<kyrofa> didrocks, let me help
<didrocks> kyrofa: do you have a minute for some very quick HO? I'm unsure if I'm doing it wrong or not
<kyrofa> Sure!
<netphreak> When os updates for Ubuntu snappy are pushed, do they require a reboot of the device?
<ogra_> netphreak, yes, but as long as you go with the defaults the system will care for that on its own
<ogra_> mvo_, hmmm ... seeding grub on arm64 ?
<netphreak> ok..
<netphreak> Good to know i don't have to deal with that in a IOT device
<ogra_> netphreak, well, you have to deal with the fact that it can do unexpected reboots though
<netphreak> This part has been taken care of ;)
<netphreak> Is there an eta on the Ubuntu Snappy version for Raspberry Pi 3?
<ogra_> not yet, no ... thats a) something i do in my spare time ... and b) depends on the status of u-boot for the board
<ogra_> not sure where b stands currently, it wasnt ready last week
<mvo_> ogra_: sure, ricmm asked for that, grub-efi-arm64
<ogra_> bah, waste of space
<netphreak> hmm.. looking at github for u-boot for rpi3 - looks like there was a commit for rpi3 compatibility..
<netphreak> https://github.com/zeldin/u-boot-rpi3/commits/master
<ogra_> i know that swarren did start work on it last week
<ogra_> but it wasnt complete back then
<ogra_> https://github.com/swarren/u-boot/tree/rpi_dev
<zyga-phone> hey ogra_ :)
<ogra_> still marked WIP
<ogra_> note that for 64bit mopde there are a bunch of kernel patches missing ... and i think the binary blob bootloader also needs to support it
<ogra_> hey zyga-phone
<netphreak> Ok.. thx for status :)
<zyga-phone> jdstrand: https://github.com/ubuntu-core/snappy/pull/658
<zyga-phone> jdstrand: this is going to ensure that configuration files for {apparmor,seccomp,...} are exectly what we want
<jdstrand> cool :)
<jdstrand> zyga-phone: and hi :)
<zyga-phone> hey, good morning :)
<dholbach> didrocks, shall we get together tomorrow some time to look at the survey results together?
<ogra_> mvo_, so with your seeding of grub, what will happen with the always failing grub snappy service on arm64 ?
<ogra_> (i dotn want to end up in a grub shell after reboot ... is that safe ?)
<mvo_> ogra_: what grub service is failing? the migrate-grub one?
<ogra_> yeah
<mvo_> ogra_: we never call grub-install, so it should be ok
<mvo_> ogra_: migrate-grub is also no more in the current snappy
<ogra_> i just want to be sure it doesnt overwrite anything on the uboot side
<zyga-phone> jdstrand: one request this week, we'd like to have a working developer mode and, before any launcher changes happenm the easiest path to getting that done is to write permissisve seccomp profile and complaining apparmor profile; do you think you could share a "permissive" seccopm profile with me (I suspect it would just contain all the syscalls but I'd rather have expects write that)
<ogra_> beuno, soo ... ho0w do we get my cdimage snaps into the store automatically ? it would really be good if they could go in without human action
<ogra_> could we pull them somehow from the store side ?
<didrocks> dholbach: sure! whenever time is best for you as long as it's not lunch time
<beuno> ogra_, the store won't pull stuff in, but there are APIs for a script running $wherever to do that
<ogra_> beuno, hmm
<ogra_> under what credentials would that run then ?
<dholbach> didrocks, cool
<ogra_> it needs to use the canonical account
<beuno> ogra_, right, you'd generate a token specifically use for that script
<beuno> soon to be replaced with macaroons
<ogra_> is there a doc about that API ?
<beuno> ogra_, I think you can just use snapcraft nowadays instead of learning about the API
<ogra_> beuno, i have a bunch of binary snaps and will have to write a script in my home on the cdimage server (which doesnt have snapcraft instaklled, it is 12.04 iirc)
<ogra_> so i doubt i can use snapcraft here
<kyrofa> ogra_, yeah, store uploading requires debs in xenial only
<ogra_> kyrofa, debs ?
<kyrofa> ogra_, I mean snapcraft dependencies in the archives that are only in xenial
<ogra_> yeah
<kyrofa> ogra_, you might be able to get away with running snapcraft 1.x on 12.04, but not 2
<ogra_> and i cant use a chroot or some such (no root access on that machine)
<kyrofa> Ah, right
<beuno> ogra_, lp:click-toolbelt is a self-contained ish script
<beuno> that describes the APIs as well
<ogra_> beuno, can i use it right away with snaps ?
<ogra_> (looks easy)
<ogra_> (judging by the README :) )
<beuno> ogra_, yes
<ogra_> yay
<ogra_> i'll play with it, thanks a lot !"
<beuno> ogra_, np, pindonga is a good source of help in that area
<ogra_> ok, i'll bug him if i hit roadblocks
<pindonga> ogra_, fwiw snapcraft has support for uploading snaps as well
<ogra_> pindonga, not on a 12.04 machine :)
<pindonga> that is true
 * ogra_ needs to auto-upload the snaps from http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<ogra_> (and the macghine is 12.04 based without root access)
<ogra_> the toolbelt looks promising though
<ogra_> but since everyone mentions it ... does snapcraft have upload support for already existing snaps ?
<jdstrand> zyga-phone: just have @unrestricted in the seccomp profile
<ogra_> i.e. ones that arent built using snapcraft ?
<zyga-phone> oh?
<pindonga> ogra_, I think so, you just point it to the file
<ogra_> cool
<pindonga> eg, snapcraft upload /path/to/nsp
<zyga-phone> just []byte(`@unrestricted`) ?
<zyga-phone> jdstrand: ^^
<jdstrand> zyga-phone: you might want a trailing newline
<zyga-phone> ok
<zyga-phone> Thanks, that's easy to do
<zyga-phone> looks like developer mode is not going to be hard to create
<didrocks> kyrofa: bug #1557018 FYI
<ubottu> bug 1557018 in Snapcraft "Access from the build system to $SNAPCRAFT_STAGE directory when after: keyworld is used in parts" [Undecided,New] https://launchpad.net/bugs/1557018
<kyrofa> didrocks, thank you!
<didrocks> zyga-phone: FYI, I changed xkcd-webserver to be compatible (see https://github.com/ubuntu-core/snappy/pull/653)
 * zyga-phone looks
<zyga-phone> didrocks: thanks, I re-started integration tests
<didrocks> zyga-phone: hum, it's pulling it from the store
<didrocks> I didn't upload it yet
<zyga-phone> didrocks: ah, then you'd better push it there :)
<zyga-phone> and restart tests again (just say "retest this please" in the comment)
<didrocks> zyga-phone: oh, great that we have this trigger and do it myself
<didrocks> zyga-phone: I need to have the canonical account access then, asking mvo, he was supposed to give it to me :)
<zyga-phone> ack
<attente> Chipaca, stevebiscuit: hi, is there an api for asking snapd to authenticate?
<Chipaca> attente: not yet
<Chipaca> attente: why?
<Chipaca> attente: `snappy login` authenticates the whole system
<Chipaca> attente: after which requests to the store from snapd will use those creds
<Chipaca> attente: is that enough for your current needs?
<attente> Chipaca: for gnome-software to authenticate without using the CLI
<Chipaca> attente: there will be one shortly, when we implement macaroon support probably
<attente> Chipaca: ok, thanks
<seb128> Chipaca, that's going to be before xenial right? ;-)
<stevebiscuit> :D
<Chipaca> seb128: I have made no promises, I'm not about to make any now
<seb128> Chipaca, k, thanks
<Chipaca> seb128: macaroon support should be ready server side this week, after which we'll be doing the client side work as soon as we can
<seb128> Chipaca, good to know, we just need to figure out what we do client side for xenial if that's not ready before release
<didrocks> zyga-phone: when you got a second: https://github.com/ubuntu-core/snappy-testdata/pull/6 :)
<zyga-phone> Sure
<didrocks> thx!
<didrocks> thanks zyga-phone :)
<zyga-phone> my pleasure :)
<jdstrand> oh, meh, the description was legitimate. description shouldn't be down in the apps section
 * jdstrand makes error more clear
<jdstrand> kyrofa: hey, can you explain how icons are supposed to work these days? my understanding is the in snapcraft.yaml you specify the icon and it is copied to meta/icon.png and meta/snap.yaml has no reference to it
<jdstrand> kyrofa: is that accurate? how does meta/gui/icon.png fit into this?
<ogra_> i thought it lives in a subdir now
<ogra_> next to the .desktop file
<jdstrand> or is that wrong...
<ogra_> (yeah, meta/gui/ )
<ssweeny> is there something special needed to expose a service from a snap over dbus? I have what I *think* is an unconfined snap running but I get an error when starting the service
<kyrofa> jdstrand, yeah your understanding fits with mine
<kyrofa> jdstrand, the meta/gui/icon discussion is new to me
<jdstrand> ok
<jdstrand> it looks like trunk has meta/gui/icon.png
<kyrofa> jdstrand, are we talking .desktop files and whatnot?
<jdstrand> desktop files is for another time. just wondering about the icon for the moment
<jdstrand> ssweeny: is this on 15.04 or 16.04?
<ssweeny> jdstrand, 16.04
<ssweeny> jdstrand, the error is Problem executing the daemon: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.44" is not allowed to own the service "core.trust.dbus.Agent.UbuntuLocationService" due to security policies in the configuration file
<kyrofa> jdstrand, ah. Yeah sorry, I wasn't involved with that
<jdstrand> ssweeny: yes, the dbus bus policy is not set
<ssweeny> jdstrand, ok, how does one set that? :)
<jdstrand> ssweeny: atm, you can't. once zyga's stuff lanks, you'll be able to use interfaces
<ssweeny> aha
<jdstrand> ssweeny: you used to be able to do a little with type: framework and bus-name (eg, like on 15.04), but frameworks don't work on 16.04 and are going away in favor of interfaces
<ssweeny> jdstrand, any ETA on that? Or a branch I can follow?
<ssweeny> jdstrand, yeah all I could find documentation-wise was the old framework stuff
<jdstrand> I'm going to defer to zyga-phone on that. I know he wants to lands parts of the interfaces very soon. the dbus stuff we are probably going to need to work through a bit
<ssweeny> jdstrand, ok, fair enough
<ssweeny> jdstrand, thanks for the explanation
<zyga-phone> dbus should "just work" assuming we have an interfaces that uses dbus for some configuration
<zyga-phone> we don't have any yet
<zyga-phone> (I'm being optimistic but it seesm simple)
<ssweeny> zyga-phone, ok, so I'm blocked on this issue. Do you have any timeframe for something I could play with?
<jdstrand> I have some conerns that we will define only a few dbus interfaces for people to use but the world will want 100s or more
<jdstrand> but I guess we'll see how that shakes out
<zyga-phone> day-few-days
<ssweeny> zyga-phone, ok I can work with that, thanks
<zyga-phone> for the moment we can start to look at a specific interface
<zyga-phone> e.g. the one that will unblock you
<zyga-phone> I'd encourage you to look at that earlier, to define what you need to interact with and how
<zyga-phone> otherwise you can spend most of the time designing that part alone
<ssweeny> zyga-phone, sure
<attente> hi, is there a way for me to run snapd on my desktop? i keep getting a "error: daemon does not handle 0 listeners right now, just one"
#snappy 2016-03-15
<dholbach> good morning
<didrocks> hey dholbach!
<dholbach> salut didrocks
<kyrofa> Good morning
<Marin_> Hey, anyone here to help with snappy service problem?
<ogra_> Marin_, you have to be a bit more specific i guess :)
<kyrofa> ogra_, can the auto-update be disabled in ubuntu core?
<ogra_> kyrofa, yeah, tghrough snappy config ubuntu-core
<ogra_> echo -e "config:\n  ubuntu-core:\n    autoupdate: false\n" | sudo snappy config ubuntu-core -- -
<ogra_> something like that should work
<kyrofa> ogra_, thank you!
<ogra_> mvo, regarding bug 1546821 .... do we need to omit -no-xattrs too for os snaps ? (see the last comments)
<ubottu> bug 1546821 in Snappy "please add -all-root and -no-xattrs to mksquashfs options" [Undecided,New] https://launchpad.net/bugs/1546821
<mvo> ogra_: the OS snap is not using xattrs AFAIC
<mvo> AFAIC
<mvo> AFAIK
<mvo> *sigh*
<mvo> ogra_: this is something in snappy
<ogra_> mvo, so it wouldnt break if that was used ?
<mvo> ogra_: I think it won't break either way
<ogra_> ok
<mvo> ogra_: but we can not use -root-only (or wahtever it was called)
<mvo> that will definitely break
<ogra_> just making sure that fixing bug 1557513 will be enough to drop snappy build
<ubottu> bug 1557513 in Snapcraft "please add option to override -all-root in "snapcraft snap"" [High,New] https://launchpad.net/bugs/1557513
<ryanleesipes> Hello!
<ogra_> mvo, Chipaca http://paste.ubuntu.com/15391784/ :(
<ogra_> (this is todays dragonboard image)
<kyrofa> Hi ryanleesipes!
<mvo> ogra_: in qemu?
<ogra_> mvo, ? arm64 in qemu ?
<mvo> ogra_: or on real HW?
<ogra_> thats the dragoboard image i just built from the most recent snaps on cdimage
<ogra_> there is another issue
<mvo> ogra_: and its running on your dragonboard? hm, the traceback looks scary
<ogra_> http://paste.ubuntu.com/15391819/
<mvo> ogra_: its not even touching our go code yet when it panics
<ogra_> mvo, well, snap install seems to work, it is only the old "snappy install"
<mvo> ogra_: interessting
<ogra_> 2016/03/15 14:08:31.229390 kernel_os.go:167: can not get boot settings: cannot determine bootloader
<mvo> ogra_: can not get boot settings is also not cool
<ogra_> this one looks scary though
<mvo> ogra_: how does ls /boot/uboot look ? do you have the uboot.env there?
<ogra_> perhaps due to having grub installed now ?
<mvo> ogra_: yeah, I was wondering this too
<mvo> ogra_: iirc the code looks for a grub.cfg in /boot so it should not affect it, but maybe it does
<ogra_> oh man
<ogra_> ubuntu@localhost:~$ ls /boot/uboot/
<ogra_> ubuntu@localhost:~$
<ogra_> ...
<ogra_> ubuntu@localhost:~$ ls /boot/efi/
<ogra_> EFI                                                install.yaml
<ogra_> canonical-dragon-linux.sideload_IPAIJHReTMLK.snap  snappy-system.txt
<ogra_> dtbs                                               uboot.env
<ogra_> ubuntu@localhost:~$
<ogra_> lovely
<ogra_> so it now mounts under /boot/efi
<ogra_> ubuntu@localhost:~$ mount |grep boot
<ogra_> /dev/mmcblk1p8 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
<ogra_> /dev/mmcblk1p8 on /boot/grub type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
<ogra_> and ....
<ogra_> ubuntu@localhost:~$ sudo mount /dev/mmcblk1p8 /boot/uboot
<ogra_> ubuntu@localhost:~$ snappy list
<ogra_> Name                   Date       Version      Developer
<ogra_> canonical-dragon       2016-02-12 0.7.1        canonical
<ogra_> canonical-dragon-linux 2016-03-15 IPAIJHReTMLK sideload
<ogra_> ubuntu-core            2016-03-15 IPAIJIIJHeDL sideload
<ogra_> Reboot to use canonical-dragon-linux version IPAIJHReTMLK.
<ogra_> Reboot to use ubuntu-core version IPAIJIIJHeDL.
<ogra_> (note that i installed webdm before i noticed that issue ... there is no webdm listed now)
<ogra_> it sits under /snaps though
<mvip> ricmm you around?
<mvip>  /msg nickserv set password 6V8gEoK.HYzUY6XpAsF
<mvip> lol ops
<kyrofa> mvip, might want to change that now... ;)
<mvip> kyrofa lol yeah done already
<ogra_> Mar 15 14:32:53 localhost kernel: [ 1416.561031] audit: type=1400 audit(1458052373.895:292): apparmor="DENIED" operation="create" profile="xkcd-webserver.canonical_xkcd-webserver_16.04-4" pid=1908 comm="xkcd-webserver" family="inet" sock_type="stream" protocol=0
<ogra_> hmpf
<ogra_> so our latest rootfs is definitely heavily broken in various ways
<jdstrand> it needs 'network-client'
<jdstrand> oh, maybe this is what didrocks was talking about yesterday
<ogra_> (bootloader broken, snappy list not showing packages)
<ogra_> (snappy itself throwing exceptions)
<ogra_> jdstrand, yeah, i guess
<jdstrand> didrocks: btw, the 'description' warning from the review tools for xkcd was accurate-- there is a 'description' tucked in the apps section. I made that warning more clear in trunk. the other issue I fixed in trunk
<jdstrand> (couldn't find binary)
<ogra_> ubuntu@localhost:~$ snappy list|grep webdm
<ogra_> ubuntu@localhost:~$ snappy list|grep xkcd
<ogra_> xkcd-webserver         2016-03-14 16.04-4      canonical
 * ogra_ scratches head
<jdstrand> didrocks: there is a new review tools rollout to the store imminent, but these changes won't be until the next one
<ogra_> ubuntu@localhost:~$ ps ax|grep webdm
<ogra_>  1244 ?        Ssl    0:02 /snaps/webdm.canonical/0.16.1/bin/aarch64-linux-gnu/snappyd
<ogra_> funnily it runs and i can use itr
<didrocks> jdstrand: ah, great! We will fix the description with next upload then :)
<mvip> Hey didrocks. How are things? You recovered from MWC? ;)
<ogra_> mvo, mind if i revert the grub stuff for now ?
<mvo> ogra_: ok
<ogra_> mvo, at least the grub migration error on boot is now gone on the dragonboard :P
<mvo> ogra_: heh
<didrocks> mvip: I fortunately did yeah! :) Quite busy to prepare content for 16.04 (dev website, slide decks and such)
<didrocks> mvip: how about you?
<kyrofa> Hey ogra_ I'm trying to automate a way to get the writable partition on an external HD. Ideally I'd be able to create two images, one for the SD card that doesn't contain the writable partition, and one for the external HD that does. Then each image can be flashed to its respective device and voila. Does that sound possible?
<ogra_> kyrofa, we only have two partitions (well, plus bootloader if needed)
<ogra_> kyrofa, technically you want to split bootloader+boot vs writable ...
<ogra_> thats indeed possible to do using scripts and kpartx
<ogra_> (i.e use sgdisk/fdisk to find the writable partition in the img file, create a fresh img for writable, format it, mount it, copy the contents, delete the writable partition on the original img)
<kyrofa> ogra_, ah, excellent
<kyrofa> ogra_, I'm going to take a crack at this. I'm sure I'll have questions if that's alright?
<ogra_> sure
<elopio> fgimenez: are you coming?
<fgimenez> elopio, yep omw
<mvip> didrocks: good good. Lots of events as of lately, but i guess one cannot complain ;)
<mvip> didrocks: any progress on the dev website?
<didrocks> mvip: quite some on the getting started, the rest will take longer obviously :)
<didrocks> mvip: I can share with you some mockups if you are interested
<jdstrand> zyga-phone: with all the feedback on https://github.com/ubuntu-core/snappy/pull/658 and your most recent comment, thinking I'll hold off on my portion of the review?
<zyga-phone> jdstrand: looking
<zyga-phone> jdstrand: ah, I think that has stabilized now
<zyga-phone> jdstrand: a review of that would help
<zyga-phone> jdstrand: from the security POV
<jdstrand> ok
<zyga-phone> jdstrand: note that I've dropped the checks for UID/GID since it makes no sense in snapd context
<zyga-phone> jdstrand: and it was making the code a lot more complex given the atomic renames we do
<ogra_> mvo, just FYI, after removing grub the dragonboard image totally behaves ... no more segfaults or anything ... seems seeding grub confused the system mmore than just through mounting everything under /boot/efi
<ogra_> hmm, though snappy list still doesnt show webdm
<ogra_> oh !
<ogra_> it shows webdm if i sudo ...
<ogra_> seems to be a permission prob
<ogra_> wow, weird
<ogra_> so installing xkcd-webserver makes it show up without me using sudo
<ogra_> (but webdm is hidden from the list)
 * ogra_ doesnt get that
<ricmm> mvip: yes?
<ogra_> ricmm, i had to remove grub from arm64 again, it made everything explode
<ogra_> ricmm, what is it neede for ?
<ogra_> *needed
<ricmm> ogra_: well obviously arm64 devices that use grub ;)
<ricmm> what explodeD?
<ogra_> the whole boot process ... everything got mounted under /boot/efi regardless
<ogra_> that in turn completely broke snappy itself
<ogra_> <ogra_> ubuntu@localhost:~$ mount |grep boot
<ogra_> <ogra_> /dev/mmcblk1p8 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
<ogra_> <ogra_> /dev/mmcblk1p8 on /boot/grub type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
<ogra_> (thats on a uboot system)
<ogra_> that caused: http://paste.ubuntu.com/15391784/  and http://paste.ubuntu.com/15391819/
<ricmm> why would that have happened
<ogra_> removing the grub package and everything is back to normal
<ricmm> its a core bug then
<ogra_> yeah, somewheer
<ogra_> *where
<ricmm> could you send mvo/me an email about this with all the info
<ogra_> surely needs fixing .... but i guess we are not expecting a grub based arm64 arch within the next few weeks ?
<ricmm> I have one on my table right now
<ogra_> damn
<ogra_> port it to uboot :P
<ricmm> well, they went through an effort to make it uefi :p
<ricmm> anyways, just send us an email
<ricmm> should be a simple bug
<ogra_> will do
<ricmm> no reason why things cant coexist :)
 * ricmm adds to board
<ogra_> well, doesnt u-d-f handle them differently ?
<ogra_> i.e. grub is installed out of the rootfs
<ricmm> it does, but it should work fine
<ogra_> while uboot has to come with the gadget
<ricmm> i.e. armhf supports it
<ogra_> and iirc there are also checks for mountpiints
<ricmm> only thing we did was add arm64 bits
<ricmm> right it might be doing some hackish thing to determine the bootloader setup
<ogra_> i.e. if /boot/grub exists (which the package created) we assume grub
<ricmm> by probing mountpoints
<ricmm> right
<ricmm> thats not necesarily a nice thing to do :)
<ogra_> yeah, i guess that causes the wrong mounts
<ogra_> the other bits are fallout
<ricmm> ok send the email will track tomorrow
<ricmm> thanks for pointing that out
<ogra_> will do
 * ogra_ is close to having auto-uploads of the daily builds ready ... then we should have daily snaps in the store ;)
<ogra_> and with these snaps auto-resize on dragonboard finally works \o/
<ricmm> \o/
<ogra_> (these = http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ )
<zyga-phone> ogra_: woot, great
<zyga-phone> ogra_: is there something I should change in ubuntu-image?
<ogra_> hmm, the amd64 image exposes the same weird snappy list behavior
<ogra_> zyga-phone, nah, i plan to auto-push them to the store ... rolling edge should always have the dailies ... promoting them to rolling stable should then stay a manual process
<zyga-phone> ogra_: nice
<zyga-phone> ogra_: will existing images auto-resize?
<ogra_> (perhaps we can tie that to the testing infra later though)
<zyga-phone> ogra_: or is that some firstboot speciallity
<ogra_> the check happens on every boot ... if there is more than 10% free space it will resize to full disk size
<ogra_> so technically not a first boot thing ... but likely to run on first boot and never again :)
<ogra_> with the smally all-snaps setup we could now default to 1GB images btw
<ogra_> it is ~180MB per kernel+os snap (by 2 since we have two of them installed usually) ... and ~130MB for /boot
#snappy 2016-03-16
<code1o6> Hey guys, I'm writing my first snappy app. Could someone take a look at my snapcraft.yaml ... I'm having issues following the tutorial basically the section on extending the metadata. http://pastebin.com/smaw2XAr
<dholbach> good morning
<zyga-phone> good morning
<dholbach> didrocks, I almost finished the review of the replies
<dholbach> didrocks, maybe you can take a look and see how we can summarise this in a mail? :)
<didrocks> dholbach: sure, I'll have a look in 10 minutes
<dholbach> awesome
<dholbach> didrocks, did you get to it already? :-P
<didrocks> dholbach: I did read what you wrote
<didrocks> dholbach: want to write the email together or me to have a first pass?
<dholbach> as you like it
<didrocks> dholbach: I would prefer writing this email and you debugging my systemd issue under snappy :p (good deal! ;)
<dholbach> did you write a mail to the list about it already?
<dholbach> maybe somebody there can help?
<didrocks> dholbach: tried already with pitti and mvo, I don't see anyone else better at those systemd issues though
<dholbach> writing an email shouldn't take very long :-)
<dholbach> it's worth a try, no?
<didrocks> dholbach: I'm just afraid we'll reash those 4 hours of exploring and retrying everything
<dholbach> I could imagine that you're not the only one to run into a problem like this
<dholbach> so it might be worth discussing
<didrocks> dholbach: from what pitti said he has never seen this
<dholbach> right
<pitti> well, it seems fairly specific to vlc, so no wonder
<pitti> running it under a minimal environment without $HOME and such
<didrocks> pitti: the difference between the service and the app launched from the cmdline is when it succeeds, there is a core access debug: connection succeeded (socket = 6)
<didrocks> and 6 is /dev/urandom
<didrocks> pitti: is it something that rings a bell, like systemd preventing access to this socket? ^
<pitti> no, there is usually no access restrictiosn for services, unless you specifically request them
<didrocks> it's in net_Connect() which is where the network issue happens!
<kyrofa> Good morning
<didrocks> good morning kyrofa!
<kyrofa> Hey didrocks!
<pindonga> jdstrand, finally, crt @ 606 on prod \o/
<jdstrand> pindonga: yay! :)
<jdstrand> pindonga: thank you :)
<pindonga> yw
<kyrofa> Morning jdstrand! I hit that hash issue again with the owncloud snap and requested a manual review. Mind taking a look when you're able?
 * jdstrand wonders what versions of the tools ran
<jdstrand> 601
 * jdstrand runs automated review again
<jdstrand> hmm
<jdstrand> pindonga: I did 'run automated tools again' on https://myapps.developer.ubuntu.com/dev/click-apps/2431/rev/11/ and see that 606 was attempted, but 'Unexpected failure while running click-review. click-review'
<jdstrand> let me try them locally
 * pindonga checks and hopes he didn't break anything
<jdstrand> PYTHONPATH=./ ./bin/click-review /tmp/owncloud.canonical_8.2.2ubuntu2_armhf.snap
<jdstrand> Errors
<jdstrand> ------
<jdstrand>  - security-snap-v2:cap_exists:listener:network-listener
<jdstrand> 	unsupported cap 'network-listener'
<jdstrand> /tmp/owncloud.canonical_8.2.2ubuntu2_armhf.snap: FAIL
<jdstrand> so, they are ok
<jdstrand> [2]
<pindonga> "they are ok" meaning it's ok the review failed?
<pindonga> but it should have displayed the errors though
<jdstrand> granted, that is with r610
<jdstrand> pindonga: yes
<jdstrand> I mean, the tools didn't crash or anything. they correctly failed and corrected errored with '2'
<kyrofa> jdstrand, oh it's no longer network-listener?
 * pindonga checks the logs
<pindonga> jdstrand, the 'unexpected error' is bc we now avoid displaying tracebacks
<jdstrand> kyrofa: it is for the moment
<pindonga> so I presume the tools crashed and didn't return a valid json
<jdstrand> kyrofa: when interfaces land, it will be network-bind
<jdstrand> pindonga: unfortunately, the output in the store didn't give anything useful
<jdstrand> let me try with --json
<kyrofa> jdstrand, ah, so that snap is okay then?
<pindonga> jdstrand, can you run the tools at 606 with --json
<pindonga> yesh
<zyga-phone> jdstrand: I got connect to work via the state engine yesterday
<jdstrand> zyga-phone: woo!
<zyga-phone> jdstrand: disconnect is up for review, intents are almost done (I'll return to them soon),
<zyga-phone> jdstrand: I'm waiting for snap manager to stabiliize to detect snap changes
<zyga-phone> jdstrand: and a few more loose ends but very very much close
<zyga-phone> (I keep saying that)
<jdstrand> pindonga: python -mjson.tool is happy
<jdstrand> zyga-phone: nice :)
<zyga-phone> jdstrand: oh while you are here and I remember
<zyga-phone> jdstrand: I'd like to land apparmor branch - I think we can do it without unloading any *.snap profiles unconditionally
<jdstrand> we are still using *.snap even though the security team doesn't like it and mvo and Chipaca gave us their support?
<zyga-phone> jdstrand: let's have a hangout
<zyga-phone> jdstrand: in a few moments, how do you feel about that?
<zyga-phone> jdstrand: to understand what the problems are and what we want to do about it
<zyga-phone> jdstrand: https://plus.google.com/hangouts/_/canonical.com/snappy-devel
<jdstrand> zyga-phone: I can't come right this second
<zyga-phone> jdstrand: when would it be convenient for you?
<jdstrand> 30 minutes?
<zyga-phone> jdstrand: okay
<plars> elopio: around?
<plars> elopio: I'm a bit confused by your comment on that PR yesterday
<pindonga> jdstrand, ok, I think the problem is that the tools are returning a non-zero exit code
<zyga-phone> jdstrand: invite sent
<pindonga> jdstrand, I know I probably asked you to do that... but I think we should return 0 if the tools succeeded (even if there are errors reported)
<kyrofa> ogra_, running gdisk -l on an amd64 image makes it pretty obvious which partition is the writable one. However, running it on a pi2 image I get "Microsoft basic data" and "Linux filesystem." I assume "Linux filesystem" is the writable one, but why doesn't it have that label?
<ogra_> kyrofa, hmm, you probably want to look at the filesystem label for msdos (vs GPT) partitions
<ogra_> instead of the partition label
<ogra_> (i.e. make that check conditional based on what partition table is used)
<pindonga> jdstrand, nm that.. I'll see to adapt the store's code to cope with non-zero exit codes
<kyrofa> ogra_, I'm afraid my familiarity with such things is really limited. Does that mean for the pi2 image I should use fdisk? Or am I misunderstanding?
<jdstrand> zyga-phone: actually, 30 minutes is not going to work for me. in 30 I have another meeting to prepare for and then attend. 2.5 hours?
<zyga-phone> jdstrand: let's check
<jdstrand> meh
<jdstrand> I have a meeting not long after that too
<zyga-phone> hmm
<jdstrand> really, I said what I needed to in the review
<zyga-phone> that could be difficult
<zyga-phone> how about we try quickly in 10 minutes?
<zyga-phone> jdstrand: ^ ?
<ogra_> kyrofa, i suspect you actually need to access the filesystem (so use kpartx to have a loop device and then inspect that with some e2fs tool)
<ogra_> i.e. dumpe2fs should give you the label
<zyga-phone> jdstrand: so you cannot meet in roughly two minutes for a moment just for a quick chat?
<kyrofa> ogra_, ah okay, playing with that now. Thank you!
<ogra_> MBR is a bit more unpleasant than GPT here
<niemeyer> Hello
<niemeyer> jdstrand: Aroud?
<niemeyer> nnnd
<jdstrand> was in a meeting. gathering notes
<jdstrand> I can meet for a few minutes
<jdstrand> but give me a minutes
<jdstrand> zyga-phone: ^
<zyga-phone> jdstrand, niemeyer: ok, see you in the HO
<niemeyer> Okie dokie
<elopio> plars: I'm here. I was talking about the changes in this file: https://github.com/ubuntu-core/snappy/pull/650/files#diff-2b427437cfbad1b468fc4b05d0218bf1
<plars> elopio: yes, those came from your PR!
<plars> elopio: but it never landed
<plars> elopio: https://github.com/ubuntu-core/snappy/pull/650/commits/12fa9a4eb73461d4177fdfc900fe4283ef6441ba
<plars> elopio: it was in this PR: https://github.com/ubuntu-core/snappy/pull/242
<elopio> plars: right. What I mean is that the change in that file should be in a different PR. The one we discussed an approved is about: "Avoid autopilot stop"
<plars> elopio: I did not requthor it, just cherry-picked it because it's needed for my PR to be of any use
<plars> elopio: but it already is in another PR... I'm confused
<elopio> plars: I'm just requesting to split your PR in two, to keep a better changelog.
<plars> elopio: can't we just land your PR and rebase mine?
<elopio> plars: sure. So let me propose the list flag in a new PR.
<plars> elopio: ah, is there no way to just use the original one? seems like you should just be able to reopen/resubmit it rigth?
<elopio> you are right, I can reopen it. Give me a second to merge it with trunk and test it again.
<kyrofa> jdstrand, pindonga now the failure says "Unexpected failure while running click-review. click-review"
<pindonga> kyrofa, yes, I'm aware, just submitted a fix for that in the store
<pindonga> will try to get it out asap
<pindonga> kyrofa, it's basically bc the store wasn't expecting a non-zero exit code from the tools
<pindonga> which they now do when there are errors
<pindonga> but it swallows the actual errors (which is what I fixed)
 * sergiusens wants to say that if anyone PM'ed him that his computer crashed and has no idea who it was
<sergiusens> good morning!
<kyrofa> pindonga, but it seems that the snap shouldn't have failed, right? Because those caps are actually correct right now?
<kyrofa> Hey sergiusens! Everything okay now?
<sergiusens> kyrofa, after a reboot you mean? :-)
<pindonga> kyrofa, if the tools returned non-zero then the store considered that as a failure
<kyrofa> pindonga, didn't jdstrand say it was because of the network-listener cap though, which is apparently still valid?
<kyrofa> It's like the review tools are too new or something. If I switched the snap to use network-bind I don't think it would run right now... ?
<sergiusens> kyrofa, elopio are we standing?
<kyrofa> sergiusens, yup, on my way
<pindonga> kyrofa, the tools report an error: security-snap-v2:cap_exists:listener:network-listener (unsupported cap 'network-listener')
<pindonga> kyrofa, so the store rejects the review
<jdstrand> kyrofa, pindonga: don't get hung up on network-listener. it is actually good that it failed because it showed a problem with the store
<jdstrand> kyrofa: as for network-listener itself, it is understood that manually reviews will have to happen until the interfaces code lands
<jdstrand> kyrofa: I didn't want to add a bunch of compat for 1 week when everything is changing after
<kyrofa> jdstrand, ahh, that makes total sense
<kyrofa> jdstrand, so that snap looks okay then? It can be approved?
<elopio> plars: you are frozen.
 * ogra_ sighs about 90+ min turnaround time for a simple fix ....
<jdstrand> kyrofa: I can approve it, yes
<jdstrand> pindonga: do you need that snap to hang around? ^
<pindonga> jdstrand, nopes
<kyrofa> jdstrand, awesome, thank you!
<kyrofa> ogra_, there's the rebuilt owncloud you asked about a while back ^^
<ogra_> yay
<ogra_> v9 ?
<kyrofa> ogra_, no, though I have that one built already, there just seems to be a bug in the upgrade process that wipes out the calendar
<kyrofa> ogra_, still investigating
<ogra_> oh
<qengho> Hmm. This is new to me. "Inconsistency detected by ld.so: dl-open.c: 691: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!"
<beuno> pedronis, ^
<pedronis> beuno: that's a c assertion
<kyrofa> sergiusens, using the kernel plugin, do you think it's possible to have another part that builds more kernel modules?
<kyrofa> sergiusens, that builds "after" the kernel part?
<qengho> "ldd" output doesn't look suspicious to me.
<sergiusens> kyrofa, yeah, discussed it with ricmm already
<kyrofa> sergiusens, sweet, happy to hear it
<ogra_> sergiusens, oh, btw ... note that i'm working on a script atm that prevents us from fully re-packing the initrd
<ogra_> (cpio being a tape archive tool actually has a concept of "append to existing archive" ... so we only need to decompress,  append and recpmpress instead of completely unpacking and re-building)
<jdstrand> niemeyer, zyga-phone: hey, so I had a lengthy discussion with the apparmor lead (jjohansen) and 'profile name: profile "/snaps/<name>.<app>" {}' does not behave the way I expected.
<jdstrand> niemeyer, zyga-phone: I was thinking that 'profile' made it a profile name and not do binary attachment, but that is not the case. if '/' is the first character of the profile name, the profile does binary attachment
<jdstrand> niemeyer, zyga-phone: so, while /snaps/<name>.<app> isn't an actually file on disk and would technically work, this is weird because there is a trap for whenever /snaps/<name>.<app> did exist
<jdstrand> niemeyer, zyga-phone: so we revisited policy namespaces and .snap
<jdstrand> niemeyer, zyga-phone: short answer-- consider niemeyer's excellent reasoning that we are already doing a sort of namespacing currently (since you can filter on the '_' tuple in the profile name), appending .snap is no worse
<jdstrand> niemeyer, zyga-phone: please go with appending .snap at this time
<jdstrand> niemeyer, zyga-phone: we also talked through policy namespaces and I created a card to explore the topic more fully after 16.04 (it would need to be prioritized)
<niemeyer> Yo
<niemeyer> jdstrand: Okay, thanks for following up on that
<jdstrand> niemeyer, zyga-phone as for the filename on disk-- I have no preference other than to say I find it very convenient to have the label be the same as the filename (so '<name>.<app>.snap' now)
<jdstrand> niemeyer, zyga-phone: but if you prefer something else, I'm ok with that
<jdstrand> niemeyer, zyga-phone: sorry it took so long to come to a conclusion-- there were quite a few things to think through, including particulars on attachment and policy namespaces that needed to be worked out
<niemeyer> jdstrand: No worries at all, happy we're finding some reasonable alternatives
<niemeyer> jdstrand: Would snaps.<snap>.<app> be any better, in terms of being slightly closer to the current apparmor convention?
<jdstrand> well, we are a bit outside of convention here
<niemeyer> Or perhaps snap.<snap>.<app>, to avoid the potential conflict with an actual binary at that location in the future
<jdstrand> what might be interesting to consider is what does a policy namespace look like
<jdstrand> in the future if we do policy namespaces, the label would look like: :snappy://<name>.<app>
<jdstrand> (where 'snappy' is whatever we choose)
<jdstrand> so, perhaps prepending is better since in the future we might change to policy namespaces
<jdstrand> and in this manner, it will be similar to what people will have already been looking at
<jdstrand> I think I am leaning towards snap.<snap>.<app>
<niemeyer> Okay deal
<niemeyer> zyga-phone: ^^^
<jdstrand> then in the future, we might have: :snap://<snap>.<app>
<niemeyer> +1
<fgimenez> elopio, it seems that we need more executors :D http://162.213.35.179:8080/
<elopio> I wonder why those unit tests are so slow when we build the deb.
<fgimenez> elopio, not the best moment for the update
<fgimenez> yep it seems to get stuck with some of them
<elopio> fgimenez: indeed. I will prepare it when all the devs have gone to bed.
<elopio> pindonga: do you have some time for me?
<elopio> I want to know how can I upload a snap to edge, and then promote it to beta in our CI process.
<ogra_> elopio, i recently asked the same and was pointed to bzr branch lp:click-toolbelt
<ogra_> (there is a README)
<elopio> thanks ogra_
<ogra_> though i'm not sure you can do channel switching with it ...
<ogra_> but the upload bit should be covered (if you cant use snapcraft upload)
<elopio> I can use snapcraft upload, but I would be missing the publishing to edge part.
<ogra_> isnt that the default ?
<ogra_> i thought new uploads of an existing package automatically go to edge
<elopio> as I understood, you first upload and the package is in no channel. Then you publish to a channel.
<ogra_> uuh, that would be bad
<ogra_> (if all subsequent uploads just went through)
<ogra_> i thought you always need to publish them
<ogra_> with an explicit step
<ogra_> at least thats how beuno always made it sound
<beuno> snapcraft is missing the publishing command atm, yes
<ogra_> but there are ways 5to do it through the store api directly, right ?
<pindonga> elopio, ogra_ we don't yet support publishing via the api
<pindonga> it's in the trello board though
<ogra_> hmm, i kind of need that for the cdimage built kernel and os snaps ...
<ogra_> preferably they would get uploaded to the edge channel ... then get tested in an image and only then get auto-published to stable
<code1o6> Hello guys
<code1o6> When you run snapcraft snap you should get a .snap file correct?
<ogra_> indeed
<ogra_> (or an error message)
<zyga-phone> jdstrand: ack, thank you for the explanation
<ogra_> stevebiscuit, is it known that webdm doesnt auto-start after reboot anymore ?
<ogra_> (it works fine right after install, but never comes up on boot afterwards)
<ogra_> "sudo snappy service webdm start" starts it fine
<ogra_> Chipaca, ^^ did anything change there recently ?
<elopio> ogra_: why is it that we don't have usb networking but debian has?
<ogra_> elopio, gadget you mean ?
<elopio> ogra_: gadget? I mean that when I plug my bbb and boot into debian, it shares my network connection through the usb cable and I can ssh magically into the board.
<ogra_> elopio, right, thats the usb gadget driver
<ogra_> elopio, that would need some very BBB specific hacks, but is indeed just a setup thing (though i doubt it works on other boards that easily)
<elopio> ogra_: and that's the kind of things that we would put in the gadget snap, right?
<ogra_> well, you need to make sure the kernel has the gadget modules you want ... you need to force-load them through /etc/modules (yes, that would be gadget) ... and then you need the proper network setup through some hacks/scripts
<elopio> interesting.
 * elopio reads about usb gadget driver.
<ogra_> Chipaca, mvo, bug 1558181 and bug 1558179 for you guys ...
<ubottu> bug 1558181 in Snappy "services are not started on boot anymore" [Undecided,New] https://launchpad.net/bugs/1558181
<ubottu> bug 1558179 in Snappy "snappy list does not show webdm anymore, while sudo snappy list does" [Undecided,New] https://launchpad.net/bugs/1558179
<stevebiscuit> ogra_: that's the first time I've seen that behaviour, I believe mvo made some changes to how avahi is managed in Go which may affect webdm on reboot
<ogra_> stevebiscuit, yeah, i just tried a kvm amd64 image, there it behaves ... might be that actual HW adds some slowness that triggers races
<stevebiscuit> ogra_: iirc there was discussion to make starting webdm on boot a special case but I don't think that's been done
<stevebiscuit> ogra_: Chipaca knows the finer details of the Go/avahi trouble I think
<ogra_> k
<ogra_> i havent seen any discussions here
<stevebiscuit> ogra_: the discussion was in the #snappy-devel Telegram channel if you want to join that
<ogra_> stevebiscuit, no, i dont
<ogra_> that excludes everyone
<zyga-phone> ogra_: I know more about webdm issue
<stevebiscuit> ogra_: don't blame you ;)
<ogra_> zyga-phone, well, as long as it is being fixed at some point, its all fine
<zyga-phone> ogra_: it's complicated
<zyga-phone> ogra_: long story short, webdm cannot start without having eth0/wlan0 ready
<zyga-phone> ogra_: fixing this would require major go surgery
<zyga-phone> ogra_: right now we don't have a way to start a particular service only after network is available
<ogra_> zyga-phone, huh ? cant we just make the systemd unit wait ?
<ogra_> why would go be involved at alll there
<zyga-phone> ogra_: and AFAIR the idea is to special case webdm once and fix it after 16.04
<zyga-phone> ogra_: webdm uses go
<ogra_> sure
<ogra_> but it ships a systemd service file
<zyga-phone> ogra_: go has no way to set a socket option that would make this problem go-away
<ogra_> and that can wait for the network
<zyga-phone> ogra_: no, it doesn't
<zyga-phone> ogra_: we generate all systemd units
<ogra_> oh ?
<ogra_> ah
<zyga-phone> ogra_: hence the special casing to just hack that dependency in there for webdm for 16.04
<ogra_> ok, got it :)
<ogra_> thanks
<zyga-phone> ogra_: in the past that was magically tied to the network-client capability
<ogra_> right, it should be again :)
<zyga-phone> ogra_: but we're trying to break that coupling (as in, the coupling is gone now AFAIK)
<zyga-phone> (I could be wrong, I don't touch that code lately)
<zyga-phone> ogra_: the real fix is to fix go and webdm to have a way to set socket options
<zyga-phone> ogra_: so then it can just start as soon as it can
 * zyga-phone has a very offtopic question
<zyga-phone> does anyone have a puff instead of a chair for their daily sitting needs?
<zyga-phone> after moving I didn't bring any quality chairs and the one I was using so far fell apart
<zyga-phone> and I'm considernig buying a puff instead of a regular char
<zyga-phone> chair* (too much C and I cannot see chairs but chars)
<ogra_> puff ? why not a ball ?
<zyga-phone> ball doesn't hold your back in any way
<zyga-phone> and I'd rather have something that does
<ogra_> it makes your back hold itself
<ogra_> and trains your muscules
<zyga-phone> + I think it's more comfy
<ogra_> that for sure ...
<zyga-phone> I only used a ball like that when my wife was pregnant - big red ball, moves around all the time, not something that works well in an office :/
<ogra_> thats the purpose :)
<ogra_> (moving around so your body makes the right counter movements)
<zyga-phone> well 15 hours a day?
<zyga-phone> I don't know, do you work like that?
<ogra_> no, i have a comfy armchair in the living room and a semi-proper office chair ... and i switch between them several times per day
<zyga-phone> mmm
<zyga-phone> I found that they make those puffs where I live
<zyga-phone> just 10 minutes away from here literally
<zyga-phone> we've been at the factory and we'll get a quote for a custom model
<zyga-phone> that's somewhat bigger so it'd be more like an office chair as far as height is concerned
<enoch85> so basically kyrofa I'll check if the app works standalone, and then talk to you about how to integrate it, right?
<pindonga> jdstrand, kyrofa can you try uploading some snap? I've deployed the "fix" for the previous issue
<pindonga> it should now display the reported errors despite the non-zero exit code
<kyrofa> enoch85, yeah, sounds good
<kyrofa> pindonga, alright thank you! I'll check it out when I've rebuilt
<enoch85> kyrofa: +1 :)
<Mr_Cake> Hello guys
<code1o6> Hi
<jdstrand> pindonga: hey, sorry. fyi, kgunn uploaded this: https://myapps.developer.ubuntu.com/dev/click-apps/4520/rev/2/
<mvo> ogra_: is this a non-networked board maybe?
<jdstrand> pindonga: so it looks like the store dtrt. there were review tools errors and the store handled them
<pindonga> jdstrand, so this looks a bit better than before, right?
<jdstrand> pindonga: very much so. it is correct
<pindonga> cool
<pindonga> thx jdstrand
<jdstrand> pindonga: thank you for the quick fix! :)
<pindonga> nw
<jdstrand> and thanks kgunn for beating me to an upload :)
<pindonga> :)
<jospoortvliet> kyrofa: keep me updated on progress of the image, got a test setup here but I'm guessing 'tonight' was 'tonight Virginia time' right... ;-)
<kyrofa> jospoortvliet, ah, yes I suppose so!
<jospoortvliet> ;-)
<jospoortvliet> that's cool of course, will play with the results tomorrow or Friday.
<kyrofa> jospoortvliet, sounds good :)
<mvip> hey manik. How are things?
<manik> hey mvip
<manik> mvip: i am good, how are you?
<mvip> manik: not bad. Recoverd from BCN and a few events following that. :)
<mvip> manik: now there will hopefully be some time before the next one.
<manik> mvip: that's great. how was the rpi party?
<mvip> manik: Great. Full house. Lots of cool DIY projects.
<manik> that's nice
<manik> was anything public?
<manik> amongst the projects?
<mvip> manik: oh yeah, i think all of it was
<mvip> manik it's more a community event
<mvip> manik: with invited vendors/partners etc
<mvip>  manik: i need to step out in few to grab a bite before i starve to death, but a quick question for you
<manik> i see
<manik> sure
<mvip> manik: what's the status on the disk wear and tear things?
<manik> the team's reviewing it, its a little early to say
<manik> 16.04
<manik> 16.04s keeping things very busy atm
<mvip> but it will make it into 16.04 at some point in a not too distant future?
<manik> i'll check on it again
<mvip> thanks.
<manik> sure
<mvip> and it will be part of an OS update, correct?
<manik> its a little early to say honestly
<manik> let me find out where we are and circle back
<mvip> manik: thanks. that's probably the most important issue for us.
<manik> sure
<ogra_> mvo, nope, properly networked
<mvo> ogra_: hm, hm
<ogra_> mvo, it is a dragonboard ... so wlan ... might be that starts a bit later than wired
<ogra_> (or slower)
<mvo> ogra_: so there is a unfortunate dependency on network for services but if its networked it should work
<mvo> ogra_: is it just webdm?
<mvo> ogra_: or also e.g. xkcd-webserver?
<ogra_> mvo, cant tell much about xkcd-webserver since it is broken :P .- it starts but doesnt have networking allowed
<ogra_> so it just idles in the processlist
<mvo> ogra_: uh
<mvo> ogra_: wuut? that works in the integration tests I thnk
<ogra_> well i get errors here ....
<mvo> hm, maybe its a new issue
<ogra_> note that i use daily images though ... i'm on todays os snap from cdimage
<ogra_> so there might be changes in the security layer that your all-snaps images dont have yet
<mvo> could be, little has changed in this particular area though recently
<mvo> I will check tomorrow
<ogra_> yeah, no hurry
<ogra_> that snapps list thing is really curious though
<ogra_> *snappy list
<jdstrand> no changes in the security layer that I am aware of *except* that snappy no longer grants network-client if nothing is specified
<jdstrand> mvo: ^
<jdstrand> is network-client specified in old-security/caps? is it reflected in /var/lib/snappy/{apparmor,seccomp}/profiles/xkcd...?
<ogra_> plugs:
<ogra_>  xkcd-webserver:
<ogra_>   interface: old-security
<ogra_>   caps:
<ogra_>    - network-client
<ogra_>    - network-service
<ogra_> thats the snap.yaml that got installed
<jdstrand> ogra_: can you paste what is in /var/lib/snappy/{apparmor,seccomp}/profiles/xkcd* ?
<ogra_> http://paste.ubuntu.com/15404146/ is the relevant snippet from the apparmor profile
 * jdstrand notes that others mentioned this and that there weren't any denials
<ogra_> looks all commented out to me
<jdstrand> no it isn't
<ogra_> k
<jdstrand> it is correct
<jdstrand> the #include lines are pulling in things
<jdstrand> didrocks mentioned this issue. he said it was only with services and cli commands didn't have the issue
<jdstrand> I suggest someone look at what systemd is doing
<ogra_> hmpf
<ogra_> ubuntu@localhost:~$ snap find pastebinit.mvo
<ogra_> Name           Version   Summary
<ogra_> pastebinit.mvo 1.4.0.0.2 pastebinit
<ogra_> ubuntu@localhost:~$ sudo snappy install pastebinit.mvo
<ogra_> Installing pastebinit.mvo
<ogra_> pastebinit.mvo failed to install: snappy package not found
<ogra_> lovely ...
 * ogra_ wishes snap find wouldnt be full of false positives
<ogra_> anyway ... back to doing evening stuff :)
<kyrofa> Ah ogra_ ... you're so very helpful to me. Thank you for your help on the writable stuff. It works perfectly
<mvo> ogra_: uh, that should work
<mvo> ogra_: its all going downhil
 * mvo goes to bed
<kyrofa> jdstrand, did you get a chance to approve that owncloud snap by any chance?
<jdstrand> I thought I did
 * jdstrand checks again
<jdstrand> I certainly meant to
<jdstrand> there are no packages pending for review
<kyrofa> jdstrand, oh, after the review ran again it was taken out of the manual review queue. Put it again!
<kyrofa> Put it in again*
<kyrofa> You should see it now
<jdstrand> kyrofa: let me run it one more time. please keep an eye on it and ping me
<kyrofa> jdstrand, will do
<jdstrand> kyrofa: it seems when that review ran it didn't have pind onga's fix
<kyrofa> jdstrand, indeed, I think it was before that
<kyrofa> jdstrand, much better now: "unsupported cap 'network-listener' security-snap-v2_cap_exists (listener, network-listener) "
<jdstrand> kyrofa: cool. can you request a manual review again?
<kyrofa> jdstrand, done
<jdstrand> kyrofa: done
<kyrofa> jdstrand, thank you!
<kyrofa> sergiusens, will the u-d-f --install option pull from the store, or does it sideload the app?
<kyrofa> sergiusens, nevermind, from the store, awesome
<zyga-phone> jdstrand: https://github.com/ubuntu-core/snappy/pull/658#discussion_r56430318
<zyga-phone> niemeyer: ^^
<kyrofa> Huh... ogra_ you're right, u-d-f's --install option doesn't seem to create systemd units. zyga-phone, do you know anything about that?
<zyga-phone> kyrofa: which units?
<zyga-phone> for services from snaps?
<kyrofa> zyga-phone, right
<zyga-phone> that's AFAIK expected, snappy does that
<zyga-phone> when a snap is activated
<kyrofa> zyga-phone, huh... snappy-list doesn't show the snap
<kyrofa> zyga-phone, do I have to do something special after creating the image with --install?
<zyga-phone> kyrofa: that's different, did you try snap list?
<zyga-phone> I don't know
<zyga-phone> which u-d-f did you use
<zyga-phone> only mvo's custom fork is useful
<kyrofa> zyga-phone, yeah, the one from your ubuntu-image
<zyga-phone> ok
<zyga-phone> hmm, then I don't know, maybe something has changed recently
<zyga-phone> this is a very volatile week
<kyrofa> zyga-phone, and I have a .mount file for it in /etc/systemd/system... so _something_ happened anyway :P
<kyrofa> zyga-phone, okay, I'll ping mvo tomorrow
<zyga-phone> oh
<zyga-phone> I think we do write .mount files ourselves too
<zyga-phone> but I'm not really familiar with how we install snaps using u-d-f
<zyga-phone> so yeah, ask mvo perhaps
<kyrofa> zyga-phone, no problem, thanks for your thoughts!
#snappy 2016-03-17
<stgraber> jdstrand: sent lxd 2.0 rc4 to the store, no packaging change
<dholbach> good morning
<didrocks> hey dholbach!
<dholbach> salut didrocks
<sabdfl> sync
<sabdfl> hah
<sabdfl> nervous twitch, that
<ogra_> heh
<renat> Hi all! It's Renat from Screenly!
<renat> I have a question. Does this page contain up-to-date documentation? https://developer.ubuntu.com/en/snappy/guides/gadget/
<kyrofa> Good morning
<renat> Because when I moved assign part to the boot-assets branch it stopped to produce udev rules with hw-assing information
<renat> Hi, kyrofa!
<renat> There is a code block after the "Structure and layout" heading.
<renat> PS. We moved to 16.04 and now I can't build a gadget snap properly.
<renat> I used canonical-pi2 snap as a base.
<renat> Just added config and assign part.
<renat> Then tried to flash it using the ubuntu-device-flash tool from here: https://people.canonical.com/~mvo/all-snaps/
<ogra_> renat, that should work fine
<renat> If I place assign part as usual - I get other error: http://pastebin.com/RCmFFguP
<renat> orga_, hello!
<renat> ogra_, hello!
<renat> Sorry=(
<renat> ps. My os version it 16.04
<ogra_> hmm ... mvo ^^^ ?
<ogra_> (i didnt even know that files out of /boot were ever supported, did that work before ? )
<ogra_> (supported from gadget snaps i mean)
<renat> Here is my snap.yaml: http://pastebin.com/UANSHjkN
<renat> ogra_, that worked fine on the  15.04
<renat> With regular ubuntu-device-flash
<ogra_> i guess the new "interfaces" security system gets in your way here
<ogra_> zyga-phone, or mvo should eb able to tell something about it
<zyga-phone> hmm?
<zyga-phone> what's that?
<ogra_> zyga-phone, hw-assign stuff from gadget snap as i understand it
<renat> zyga-phone, hi!
<zyga-phone> did it break?
<zyga-phone> renat: hey!
<zyga-phone> renat: AFAIK gustavo will publish spec on how gadget snaps can do this but it's not the same way as it was in 15.04
<ogra_> renat, btw, did you try without the "assign:" bit ? does it work then ?
<zyga-phone> renat: you will have to express connection between plugs in snaps and slots in the system
<renat> Yes. It works. But I need to assign=)
<ogra_> indeed
<ogra_> i just want to be sure it is only that bit that breaks :)
<ogra_> zyga-phone, it might be technically very complicated though ... looking at the u-d-f error it seems like it tries to add files to the os snap (which is obviously readonly) http://pastebin.com/RCmFFguP
<ogra_> tghe new implementation needs to take that into account
<zyga-phone> ogra_: yeah that sounds plausible
<zyga-phone> ogra_: looks like it's just broken now
<ogra_> yeah
<zyga-phone> on the up side, I can now install a snap and see the interfaces instantly :)
<zyga-phone> and connect them
<zyga-phone> (I don't write security files yet, still waiting for a few branches to land)
<zyga-phone> but integration is progressing nicely
<kyrofa> Hey ogra_ you mentioned a few days ago that u-d-f --install seemed broken. It seems broken for me as well (not in snappy list, no systemd units for the services, etc.). Did you ever find a way around that?
<ogra_> zyga-phone, well, this is for an appliance image so nobody will interact with the system, the assignment needs to be there by default
<zyga-phone> yes
<zyga-phone> that's supported but the syntax cannot be the same as hw-assign is gone
<kyrofa> ogra_, failing that, do you know where we keep the rpi2 gadget sources so I can customize it a bit?
<ogra_> kyrofa, nope, and i forgot to file a bug even ... what i saw was that the snap actually got installed under /snaps but the "current" link and all generated files (systemd services etc) were missing
<zyga-phone> there's going to be a connection, in the model or gadget, not sure, that says "snap S1, plug P is connected to snap S2, slot S"
<zyga-phone> and snappy will honor that
<kyrofa> ogra_, yup, same
<ogra_> kyrofa, http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
<renat> Hmm... I was able to do hw-assign on the 16.04 snappy.
<renat> Is it the other way of setting up access rights to devices on 16.04?
<ogra_> yes, it all changed
<ogra_> (and i think hw-assign itself is actually gone in the latest images)
<renat> Where can I read how it's done now? Or is there any example gadget snap where I can find hardware assigning stuff?
<kyrofa> ogra_, where would you log that bug, anyway? https://bugs.launchpad.net/ubuntu/+source/phablet-tools ?
<ogra_> kyrofa, https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+filebug
<kyrofa> ogra_, ahh
<ogra_> if you give me the bug number i can confirm it :)
<kyrofa> ogra_, bug #1558517
<ubottu> bug 1558517 in goget-ubuntu-touch (Ubuntu) "ubuntu-device-flash --install option doesn't work" [Undecided,New] https://launchpad.net/bugs/1558517
<ogra_> confirmed
<kyrofa> Thank you :) . So is trunk of that tool the version that actually works?
<ogra_> i dont think so ... afaik the all-snaps stuff has not been merged yet
<kyrofa> Ugh
<kyrofa> So I can't even try to fix this
<kyrofa> Maybe lp:~snappy-dev/goget-ubuntu-touch/all-snaps ...
<kyrofa> I was hoping maybe the gadget would be as simple as "here's the stuff to preload" but it has all sorts of stuff in it that I don't want to duplicate. I'm not even sure I'd call that a workaround for this problem
<kyrofa> ogra_, I'm willing to bet it's simply using an old version of snappy
<renat> Ok. I found a little bit more information about new mechanism of slots and plugs. As far as I can understand - I need to create a plug to the file on the gadget snap. (I need access to the /dev/vchiq). But I still can't find how it's done on the gadget snap side=(
<renat> Seems I'm digging to chaotically without knowing right direction=(
<renat> Guys, can you help me with this, please?
<kyrofa> renat, sorry, I'm afraid you have more gadget snap experience than I do :(
<kyrofa> I'd love to help
<kyrofa> renat, have you tried looking at the sources for the gadget snaps that already exist?
<renat> kyrofa, I investigated these packages: ~snappy-dev/snappy-hub/snappy-systems but nothing useful there=(
<kyrofa> renat, bah, sorry
<renat> Interesting that there is two commands, snappy and snap. I can install snapcraft 2.4 generated snaps using "snappy" command, but not using "snap" command.
<kyrofa> renat, yeah, we're in the midst of transitioning to snap
<kyrofa> didrocks, I'm not sure what you're saying in your comment here: https://askubuntu.com/questions/746791/snappy-ubuntu-core-on-beaglebone-black/746814#746814
<renat> I will continue using snappy for now.
<didrocks> kyrofa: can you se my edit on your answer?
<didrocks> kyrofa: it needs peer reviewing
<kyrofa> didrocks, no, I'm not that cool on askubuntu apparently
<kyrofa> didrocks, how might I get that ability?
<didrocks> kyrofa: more credits/points
<kyrofa> Boo
<didrocks> hum, it seems that my edit was rejected :/
<didrocks> let me retry
<didrocks> and see if you can see it
<didrocks> "This edit was intended to address the author of the post and makes no sense as an edit. It should have been written as a comment or an answer.
<didrocks> "
<didrocks> no, it was another option
<didrocks> kyrofa: ok, let me write it as another answer then, and you can plus it :)
<kyrofa> didrocks, ooo, rejected!
<niemeyer> jdstrand: Heya
<kyrofa> didrocks, alright, I'll plus it ;)
<niemeyer> jdstrand: When you are around, would you mind to have another look at https://github.com/ubuntu-core/snappy/pull/658?
<didrocks> kyrofa: https://askubuntu.com/questions/746791/snappy-ubuntu-core-on-beaglebone-black/747087#747087
<didrocks> kyrofa: I'm plussing your answers so that you get credits as well :)
<kyrofa> didrocks, I know, it gives me fuzzy feelings every time
<didrocks> heh
<kyrofa> Thank you :)
<didrocks> thanks to you! :)
<jdstrand> niemeyer: sure
<jdstrand> niemeyer: and hi :)
<niemeyer> jdstrand: Thanks!
<ogra_> renat, i fear only zyga-phone and niemeyer can help with your prob (i havent used hw-assign from gadget before and they are the ones implementing the new featureset in 16.04 for such bits)
<ogra_> there will at least be new syntax that i dont know where it is documented ...
<renat> ogra_, thanks. Let me disturb them again, then=)
<niemeyer> renat, ogra_: This is likely the best docs we have on it ATM: https://docs.google.com/document/d/1Q5_T00yTq0wobm_nHzCV-KV8R4jdk-PXcrtm80ETTLU/edit
<niemeyer> Please note this is work in progress.. fast progress as we speak
<niemeyer> renat: hw-assign will soon not be there
<renat> niemeyer, already read them=( Decided to leave my question here: https://askubuntu.com/questions/747090/allow-access-to-the-device-file-on-the-snappy-16-04
<renat> But the guy with nick "techraf" sends me back here=)
<techraf> renat: I was suggesting, not sending you back
<renat> techraf, hi!=)
<ogra_> niemeyer, sadly that doesnt cover gadget vs oem snap defaults
<ogra_> niemeyer, renat used to use the "assign:" bits in his oem snap in 15.04 and wants to convert that part to his 16.04 gadget snap now
<niemeyer> ogra_: I don't recall us touching the gadget snap in that sense yet, although that's definitely going to be broken soon indeed if it's already not
<ogra_> right, it used to call hw-assign during image creation in u-d-f .... but with all-snaps it cant actually create the udev rules inside the os snap (since it is readonly now)
<niemeyer> ogra_, renat: Aha, indeed.. that's not going to work
<renat> niemeyer, we need to wait for an update?
<ogra_> yeah, we need to have some equivalent by release though
<niemeyer> renat: So the answer is that this isn't working yet, sorry.. it will once interfaces land entirely and we get the gadget to express the default connections to be made
<niemeyer> renat: What is in that document explains how that's going to work, but it doesn't document how the gadget snap will express those default connections
<niemeyer> renat: That's on me to specify over the next few days
<renat> niemeyer, understood, thanks.
<ogra_> i'd suggest to use your app snap unconfined for now so you are not blocked by this
<ogra_> (temporary indeed)
<renat> ogra_, yes. I can do hw-assign for now. At least - it worked today=)
<ogra_> heh, or that :)
<ogra_> (as long as it still works)
<jdstrand> niemeyer: should I concern myself with the 'Handling errors' email to snappy-devel?
<niemeyer> renat, ogra_ : Sweet.. hw-assign will probably be broken very soon.. but we'll introduce the development mode before or while we do that so snaps can continue to evolve while we finish the proper logic
<niemeyer> So you'll be able to do something along the lines of "snap install --devel <snap>" and get something that is "unconfined" (it'll have more logic to aid in development, besides unconfinement)
<ogra_> neat !
<renat> niemeyer, ogra_, thanks!
<ogra_> (it would even be cooler if it could convert from squashfs to ext2 at install time so you can edit in place ;) )
<jdstrand> niemeyer: it seems resolved in the comments of the PR, so I guess I'll just ignore the email thread
<niemeyer> jdstrand: It's sorted.. let me answer Zygmunt's email
<niemeyer> ogra_: You'll be able to do the equivalent of that, in a much nicer way
<ogra_> wow
<niemeyer> ogra_: we will get a "snap try" or "snapcraft try" subcommand, which you can call inside the snap development tree
<ogra_> cool
<qengho> Hi hi. So, when a process calls "snappy config $p yamlfile", it's the responsibility of the config program in the package to verify and then write a new configuration file for the program, right? Is it supposed to signal the running process to reload right then?
<ogra_> qengho, thats the job of what you defined as "config:" in the snap..yaml of $p
<qengho> ogra_: Okay, so the config program in-package should both write the native config file AND reload the process right away.
<ogra_> qengho, http://bazaar.launchpad.net/~ogra/+junk/ircproxy/view/head:/snapcraft.yaml uses http://bazaar.launchpad.net/~ogra/+junk/ircproxy/view/head:/config.sh in my ircproxy package to generate a bip.conf file for the bip binary it ships for example
<ogra_> (though shell for parsing yaml is perhaps not what you want :) )
<qengho> Python3 forever
<ogra_> yeah, i dont really like to ship megabytes of python in my snap for just that
<ogra_> (the python interpreter in the os snap isnt guaranteed to be there ... we might drop it now that we got rid of system-image)
<qengho> ogra_: gasp! Sounds like some better yaml tool should be a to-do item.
<ogra_> you can use a go or C binary ::)
<qengho> If I delighted in doing things the hard way, I would not be using snappy at all.
<ogra_> well, in any case relying on anything from the os will make your snap not os independent ... which it should be since nothing (except snappy itself) is guaranteed in there
<ogra_> we might even drop the shell at some point (for some snappy shell implementation)
<ogra_> sorry ... s/the shell/bash/ .... /bin/sh will have to be there for boot scripts and the like
<qengho> ogra_: can I have some kind of built-in programming language that isn't 1975 Bourne shell? Tcl? Awk?
<ogra_> qengho, whatever you ship :)
<qengho> ogra_: And? Can I rely on coreutils?
<ogra_> you can guess for them :)
<ogra_> one of the core feastures of snappy is that apps and the os can be updated completely independently ... that only works if you dont make such assumptions
<ogra_> the question for coreutils is if confinement allows you to use them at all
<ogra_> (you can indeed make an assumption that python is there or that you always have a certain libc version. but you will risk that the independence breaks when one of them gets in incpmpatible update ... we do not have any actual dependency support)
<ogra_> s/in/an/
<noise][> Chipaca or mvo: do you know if it's on anyone's plate to tweak the autoupdate frequency (https://bugs.launchpad.net/snappy/+bug/1537793) ?
<ubottu> Launchpad bug 1537793 in Snappy "Autoupdate should be less frequent and more randomly distributed" [Undecided,New]
<kyrofa> ogra_, looking at the pi2 gadget, autopilot is false. But when I create an all-snaps image it's true. Does that mean another gadget is being used?
<ogra_> kyrofa, no, it means the option isnt called autopilot anymore :)
<kyrofa> ogra_, hahaha
<ogra_> legacy code is legacy :)
<kyrofa> ogra_, so I can safely remove that, then. Auto-updates seem to work in all-snaps anyway
<kyrofa> Yeah?
<ogra_> yeah
<kyrofa> ogra_, is gadget->software->preinstalled still valid?
<ogra_> not sure
<ogra_> (i always used --install to get preinstalled snaps)
<kyrofa> ogra_, I'm not sure how I'd find out. Dive into the snappy source I guess
<ogra_> or just add something and see if it gets installed :)
<kyrofa> ogra_, I just learned that --install will never work for 16.04, by the way
<ogra_> oh
<kyrofa> ogra_, it's not a bug in u-d-f, it's a snappy thing
<kyrofa> ogra_, where the snaps used to be activated upon boot, but no longer are
<kyrofa> ogra_, u-d-f installs them without activating them
<ogra_> well, we surely want webdm preinstalled as we had it before ... in the official imgs
<kyrofa> ogra_, we'll have to do it with model assertions then
<ogra_> whatever works :)
<kyrofa> ogra_, yeah, they're be a way to do it anyway
<kyrofa> there'll
<ogra_> as long as we know early enough to implement it for the release all is fine i guess
<kyrofa> Agreed
<kyrofa> jdstrand, I'm trying to upload a gadget that is essentially the rpi2 gadget with a preinstalled snap
<kyrofa> jdstrand, it failed review, obviously because it's a gadget, but also with "found binaries for architecture 'all': boot-assets/bcm2709-rpi-2-b.dtb, boot-assets/start_x.elf, boot-assets/bcm2708-rpi-b.dtb, boot-assets/fixup.dat, boot-assets/fixup_x.dat, boot-assets/bootcode.bin, boot-assets/uboot.bin, boot-assets/start_cd.elf, boot-assets/uboot.env, boot-assets/bcm2708-rpi-b-plus.dtb, boot-assets/start.elf, boot-assets/fixup_
<kyrofa> cd.dat lint-snap-v2_valid_contents_for_architecture"
<ogra_> thats normal
<kyrofa> Ah, okay
<kyrofa> jdstrand, I requested manual review. Do you mind checking it out?
<ogra_> gadget is a special case :)
<kyrofa> ogra_, the error message didn't tell me why any of that was actually an error, either
<ogra_> because your snap is arch: all ... cant contain arch specific binaries
<kyrofa> ogra_, I thought you could do that, as long as you had a shell script to dispatch
<ogra_> (i.e. you ship armhf binary files ... technically your snap should be arch: armhf then ... but thats not true for gadgets)
<ogra_> if you would do that in an app snap with a dispatcher script you had to define all arches you ship binaries for (but not use "all")
<ogra_> not sure if it still exists ... we used to have arch: multi as well
<kyrofa> Oh right, I forgot about that!
<ogra_> which indicated multiple binary arches
<kyrofa> Okay, that makes sense then
<ogra_> (i forgot why exactly gadgets have to be arch: all though ... but there was a reason :) )
<kyrofa> ogra_, yeah I'm sure there's some technicality there somewhere
<jdstrand> kyrofa: yeah. I may use it as a guinea pig for a change
<ogra_> do we actually allow snaps inside snaps ?
<kyrofa> jdstrand, sure! I'm on a bit of a timeline though, can I still get that through this morning?
<jdstrand> yes
<jdstrand> just be a few minutes
<kyrofa> jdstrand, not a problem at all then, thank you :)
<sergiusens> ogra_, I left a cliffhanger for you in that initrd.img thread; hope you don't mind
<kyrofa> sergiusens, hahaha, you piqued my curiosity
<kyrofa> "Wait... what?"
<sergiusens> kyrofa, lol
<sergiusens> well we have to wait :-)
<sergiusens> jdstrand, ogra_, given the thing about models and the architecture will be defined there it seems perfectly reasonable to make the gadgets arch specific now
<jdstrand> kyrofa: fyi, I pressed the button.
<kyrofa> jdstrand, I appreciate it! Did it work for your test?
<jdstrand> kyrofa: my change worked locally, yes. I suspect the store will need a pull, but wanted to run through the tests again to make sure
<kyrofa> jdstrand, wait, it says failed review
<kyrofa> jdstrand, should I request manual again?
<jdstrand> kyrofa: yes, I pushed the run the tests again button
<jdstrand> please do
<kyrofa> Oh, THAT button
<ogra_> sergiusens, not a cliffhanger at all :P
<jdstrand> :)
<kyrofa> jdstrand, done
<sergiusens> ogra_, oh, the why we don't mount part
<kyrofa> Still a cliffhanger! Even more intense now as ogra_ totally ignored it
<jdstrand> oh hrmm, I thought this was like yesterday's owncloud
<jdstrand> this is a gadget snap
<ogra_> lol
<kyrofa> jdstrand, right, it's just reloading yesterday's owncloud
<kyrofa> preloading, rather
 * ogra_ wonders if he has all mails in that thread already ... my old mailserver often delays delivery 
<jdstrand> sorry, got a wire crossed cause I was asked to do another one that needed a different review tools fix
<kyrofa> jdstrand, oh oops, I'm sorry!
<jdstrand> kyrofa: ok, let me look at this more closely
<jdstrand> kyrofa: I guess this is following all the new gadget yaml?
<kyrofa> jdstrand, honestly I don't know. I just copied the rpi2 one and added the preinstalled key
<jdstrand> kyrofa: what command did you use to generate the snap?
<kyrofa> jdstrand, snappy build
<jdstrand> ok, you hit bug #1546821
<ubottu> bug 1546821 in Snappy "please add -all-root and -no-xattrs to mksquashfs options" [Undecided,New] https://launchpad.net/bugs/1546821
<jdstrand> kyrofa: can you do: mksquashfs <dir> <snap> -noappend -comp xz -all-root -no-xattrs
<kyrofa> jdstrand, oh darn, I forgot about that
<jdstrand> kyrofa: and reupload?
<ogra_> or snapcraft snap ;)
<kyrofa> jdstrand, will do. I'm comparing that YAML to https://github.com/ubuntu-core/snappy/blob/master/docs/gadget.md though, and it doesn't match up. Should it?
<kyrofa> ogra_, I tried snapcraft snap and it gave me a wonderfully cryptic error
<kyrofa> ogra_, I'll look into that later ;)
<ogra_> oh
<jdstrand> kyrofa: honestly? idk
<kyrofa> jdstrand, I'm going to assume the pi2 one is valid... and I'll test it out as soon as it's in the store
<jdstrand> sure
<jdstrand> when the docs are all up to date, I'll update the tools for gadget snaps
<jdstrand> they'll always trigger a manual review and I can see who uploaded, so I can just waive it through atm
<ogra_> should gadgets probably stay manual forever ?
<jdstrand> that is my current thinking. that doesn't mean the tools can't do lint checks though
<ogra_> sound like the place i'd  actually do the malicious stuff since it is the most powerful snap in the chain
<ogra_> yeah
<jdstrand> kyrofa: so, this should specify the architecture, no?
<jdstrand> that is what sergiusens suggested
<kyrofa> jdstrand, there we go, no more hash mismatch error
<kyrofa> (uploaded again and in the manual review queue)
<kyrofa> jdstrand, this has gadget->hardware->architecture, but it seems the gadget snaps are arch all
<jdstrand> ok, thanks
<jdstrand> I'll approve and add a todo to fix that
<jdstrand> kyrofa: this one has a .git directory
<kyrofa> Argh
 * jdstrand rejects
<sergiusens> jdstrand, today they are arch all
<sergiusens> jdstrand, or u-d-f won't find them
 * kyrofa alters the layout of the repo
<jdstrand> I see
<sergiusens> jdstrand, as it doesn't know before hand what arch a gadget targets
<jdstrand> is gadget->hardware->architecture something to look at?
<sergiusens> jdstrand, the functionality of the gadget has been split out and some of it moved to the model
<jdstrand> is https://github.com/ubuntu-core/snappy/blob/master/docs/gadget.md accurate?
<sergiusens> jdstrand, but that is not there yet, when it happens, gadgets can be arch specific
<jdstrand> I see
<jdstrand> I'll just wait then
<ogra_> this btw makes all gadget snaps show up in snap find/webdm on all arches
<ogra_> which is rather ugly
<sergiusens> ogra_, that is probably a bug; we used to filter out gadget snaps completely
<sergiusens> as they are only selectable during build time
<ogra_> yeah,m we should do again
<sergiusens> stevebiscuit, ^
<ogra_> well, there were discussions about bootloader updates
<ogra_> for that you would at least want to see the installed gadget
<sergiusens> ogra_, yeah, but you should only see your own gadget
<kyrofa> jdstrand, uploaded again, sorry about that
<ogra_> right
<sergiusens> I guess for browsing you can say "show me uninstallables"
<sergiusens> and it will show you other arches and gadgets
<jdstrand> kyrofa: approved. thank you for being patient
<kyrofa> jdstrand, ha! Barely any time at all, thank you for taking the time to check it out :)
<stevebiscuit> sergiusens, ogra_: noted
<kyrofa> jdstrand, I needed to switch the preinstalled key to built-in on that gadget snap. Mind checking it out again?
<kyrofa> ogra_, FYI, preinstalled isn't supported in 16.04, only built-in
<ogra_> someone should clean up the docs ;)
<kyrofa> ogra_, yeah didrocks is working on revamping it quite a bit actually
<kyrofa> ogra_, though it sounds like the content of the kernel and gadget snaps will still be changing here soon
<ogra_> well, nothing that touches the user actually
<kyrofa> ogra_, well, developers though
<ogra_> that will all be internal stuff (if you refer to the initrd discussion)
<kyrofa> Oh, no. I mean all the extra stuff currently included in the gadget might get thinned out/put into other snaps (e.g. the kernel)
<ogra_> ah
<kyrofa> beuno, I pinged jdstrand about this but I just noticed that he's away. Can I get someone to take a look at the owncloud-pi2.kyrofa gadget snap's update?
<beuno> kyrofa, sure
<beuno> kyrofa, approved
<kyrofa> beuno, thank you!
<qengho> Ugh. Slots and plugs are bewildering.
<kyrofa> qengho, how so? Can we help?
<qengho> kyrofa: Is https://github.com/ubuntu-core/snappy/blob/master/docs/meta.md supposed to be up to date?
<kyrofa> qengho, doesn't look like plugs are mentioned in there, eh?
<kyrofa> qengho, so no, I'd say not
<kyrofa> Want some examples to look at instead?
<qengho> kyrofa: I think that page is wrong in at least a dozen ways.
<kyrofa> qengho, I think I agree with you
<kyrofa> qengho, looks like sections of it have been updated while others have languished
<ogra_> like our code :P
<kyrofa> ogra_, hahahahahaha
<kyrofa> qengho, but in all seriousness, there are several examples here that can show you how to use plugs/slots: https://github.com/ubuntu-core/snapcraft/tree/master/examples
<kyrofa> qengho, sorry about the docs, things are still in flux leading up to 16.04
<qengho> kyrofa: I understand. Thanks.
<qengho> ls
<jdstrand> kyrofa, beuno: I'm back now
<kyrofa> jdstrand, all good now, thanks! Tested and works
<jdstrand> kyrofa: was this another upload? did I not approve it?
<kyrofa> jdstrand, it was another upload
<jdstrand> ok
<jdstrand> I really thought I was losing it
<ryanleesipes> Hey folks, how's it going?
<ogra_> ryanleesipes, busy ... heading towards a stable 16.04  :)
<ryanleesipes> ogra_, haha, makes sense
<ryanleesipes> how far out is it you think?
<ogra_> stabilizing every day :)
<ogra_> it should be in beta state when the deb based ubuntu release comes out ... and finished a few weeks after that
<ogra_> (deb release date is april 21st or so)
<kyrofa> jdstrand, just uploaded another owncloud.canonical using network-listener. Mind pressing the button on that one?
<kyrofa> jdstrand, sorry for this today
<kyrofa> jdstrand, I'll have one more in a minute as well, same package but for armhf
<kyrofa> jdstrand, then I should be done
<jdstrand> done
<kyrofa> jdstrand, alright, armhf is in queue now
<kyrofa> jdstrand, now I think I'm done ;)
<jdstrand> done
<jdstrand> kyrofa: np :)
<kyrofa> jdstrand, awesome, thanks so much!
<jdstrand> :)
<qengho> I thought Launchpad's snap-building feature would be too good to be true. I guess the builders don't download "parts".
<noise][> is this the proper way to get outbound network access for a snap:
<noise][> plugs:
<noise][>   old-security:
<noise][>     caps: [network-client]
<kyrofa> qengho, yeah internet access is disabled right now, but that will be fixed soon
<kyrofa> qengho, kinda useless right now unless your snap is archive-only
<kyrofa> qengho, I was told "a week or two"
<kyrofa> jospoortvliet, images FINALLY done, email sent. So sorry for the delay
<qengho> f
<plars> elopio: *hopefully* I managed to fix the merge breaks from recent updates with my two PRs, have a look if you get a sec
<plars> elopio: I'm off tomorrow
<qengho> Yay, uploaded first package. Boo, fails automatic review because of network listener.
<kyrofa> qengho, that's to be expected!
<kyrofa> qengho, request a manual review
<kyrofa> qengho, network-listener will be changing names shortly, and the review tools are a little ahead of the times. jdstrand knows about this
<jdstrand> I know about this and added it back in trunk and requested a fix
<jdstrand> a pull*
<qengho> kyrofa: how does one request a manual review?
<qengho> kyrofa: state is still "pending review".
<kyrofa> qengho, oh... how do you know it failed then?
<kyrofa> jdstrand, heh, got tired of all my reviews eh?
<kyrofa> qengho, in my experience there's a big red bar say that it failed the review, and it's a link. If you click that link and scroll to the bottom of the review log you'll see "Request manual review"
<qengho> kyrofa: At what web site? myapps.develeloper.u.c?
<kyrofa> qengho, right
<kyrofa> qengho, so you must have just gotten an email, eh?
<qengho> kyrofa: I did.
<qengho> kyrofa: and I found the button. Submitted.
#snappy 2016-03-18
<dholbach> good morning
<morphis> sergiusens: ping
<sergiusens> morphis, pong?
<sergiusens> morning
<morphis> sergiusens: morning :-)
<sergiusens> 5:30am here :-)
<morphis> quite early
<sergiusens> but wide awake due to jetlag
<sergiusens> 11 hour time jumps can do that
<morphis> even better ;)
<morphis> sergiusens: with snapcraft on xenial I am currently getting: https://paste.ubuntu.com/15413380/
<morphis> sergiusens: nothing in snapcraft seem to create those two directories during the stage process
<morphis> so I am wondering what goes wrong
<morphis> loosk like snapcraft is adding them statically to CFLAGS
<morphis> just creating both fixes the problem
<sergiusens> morphis, interesting; this seems to be a snapcraft bug; it declares that include path (just in case)
<sergiusens> thanks for pointing me out that inherited legacy code again :-)
<sergiusens> morphis, can you file a bug?
<morphis> sergiusens: sure, on github or launchpad?
<sergiusens> and include your snapcraft.yaml
<sergiusens> morphis, https://bugs.launchpad.net/snapcraft/+filebug
<morphis> sergiusens: aye
<dholbach> ogra_, mvo: do you know who's responsible for the Mt7623 snap?
<dholbach> or who has access rights for it?
<dholbach> we received a request to change the logo
<morphis> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1558965
<ubottu> Launchpad bug 1558965 in Snapcraft "Snap building fails due to missing include directory" [Undecided,New]
<mvo> dholbach: I have no idea, probably best to ask in #u1-internal
<dpm> dholbach, ogra_, if I'd want to create a snap from a .deb package, which is not on the archive, is there any snapcraft.yaml trick I can use to download the .deb from a URL, just as if it had been specified in 'stage-packages'?
<dholbach> dpm, can you put it in a PPA and use either the launchpad build or the LOCAL SOURCES trick?
<dpm> dholbach, I was trying to avoid that, as sergiusens mentioned that LOCAL_SOURCES was rather deprecated
<dholbach> I think the official way we want to use is PPAs and LP builds
<dholbach> but for local testing, while it's still available in the code, I'd recommend the local sources trick
<dholbach> but maybe sergiusens has a different idea
<ogra_> dholbach, havent heard of that snap
<dpm> dholbach, right, but is not PPAs = LOCAL_SOURCES?
<dpm> or do can the LP builds somehow use external PPAs?
<dholbach> dpm, I have never used it yet, but I assume that it's like normal PPAs - you can make them depend on each other
<sergiusens> dholbach, dpm just make sure it is in you local sources.list
<dpm> I'm a bit confused now
<dpm> so the package I'm trying to snap is both in a PPA and available as a downloadable .deb
<dpm> so what's the recommended way to snap it if I just want to package the binaries, and not build them?
<dholbach> ogra_,
<dholbach>  Mt7623
<dholbach> MT7623 support package MT7623 OEM snap for IoT demo purpose
<dholbach> (https://developer.ubuntu.com/en/snappy/start/gadget-snaps/)
<ogra_> dholbach, see PM :)
<dholbach> gracias!
<morphis> sergiusens: also looks a bit like snapcraft is not extracting all deb packages I put into stage-packages correctly
<morphis> sergiusens: is there some condition around what gets extracted and what not?
<morphis> sergiusens: https://paste.ubuntu.com/15413620/
<sergiusens> morphis, can you check in parts/<part>/install ?
<morphis> sergiusens: sure
<morphis> sergiusens: hm there it is
<sergiusens> morphis, do you have a stage or snap entry in your snapcraft.yaml?
<morphis> sergiusens: ah .. my fault :-)
<morphis> I strip it from the list of staged files
<sergiusens> morphis, I'm fixing this in a pkg-config branch I have
<morphis> sergiusens: but looks like the build is referencing to stage/ somehow
<sergiusens> morphis, so you won't be hit by this again and what you did might as well be correct in the future
<zyga> good morning
 * sergiusens starts getting breakfast ready
<morphis> zyga: morning
<morphis> sergiusens: you mean stripping it from files being staged affects the build through pkg-config?
<morphis> sergiusens: https://paste.ubuntu.com/15413661/ is still what I get during the build, shouldn't the build only point to parts/<current>/install?
<sergiusens> morphis, the problem is pkg-config can only have one SYSROOT at a time
<Chipaca> pitti: you around?
<sergiusens> morphis, I've been fixing that; but not there yet (missing some corner cases)
<morphis> sergiusens: ok, got it, thanks
<sergiusens> morphis, and then yes, you would use 'install' for the part and not need to stage if not needed
<morphis> sergiusens: ok
<dpm> mvo, is there a way to query snapd for all the metadata of an app?
<mvo> dpm: I don't think we have this right now, you can query the status if it is a service. why do you ask, what do you need here?
<dpm> I think it's returning outdated metadata, and I wanted to check
<kyrofa> Good morning
<morphis> is there still a way with the new snappy stuff for 16.04 to let a snap being unconfined? like the security-template: unconfined switch we had with 15.04?
<sergiusens> morphis, there is with old-security; look at the snapcraft examples
<morphis> oh great
<morphis> sergiusens: is that documented somewhere too?
<sergiusens> morphis, that is an mvo question
<morphis> sergiusens: basically I have a daemon I want to run unconfined
<sergiusens> morphis, the only form of documentation I have on snapcraft's side are the examples and https://github.com/ubuntu-core/snapcraft/blob/master/schema/snapcraft.yaml#L57
<morphis> sergiusens: I see
<sergiusens> morphis, I don't want to write more until the snappy guys get some ticks on interfaces themselves
<sergiusens> morphis, and that lands from here https://github.com/ubuntu-core/snapcraft/blob/master/schema/snapcraft.yaml#L248
<sergiusens> morphis, which needs to ref'ed from `apps` in https://github.com/ubuntu-core/snapcraft/blob/master/schema/snapcraft.yaml#L185
<morphis> I see, so defining a plug I then use in my app
<sergiusens> morphis, this https://github.com/ubuntu-core/snapcraft/blob/master/examples/ros/snapcraft.yaml and this https://github.com/ubuntu-core/snapcraft/blob/master/examples/busybox/snapcraft.yaml should get you the gist of it
<morphis> sergiusens: so something like https://paste.ubuntu.com/15414149/ should do the trick
<sergiusens> morphis, yes
<morphis> lets see
<sergiusens> morphis, I hope we did a good job with the schema to detect incompatible options/combinations
<morphis> sergiusens: I must say I like snapcraft more and more, got quite more solid then when I used it the last time back in november last year
<morphis> sergiusens: but yeah, that trick works
<morphis> mvo: ping
<jospoortvliet> kyrofa: awesome! Sorry I only see it now - will push the blog in a few minutes OK :D
<jospoortvliet> thanks a lot
<kyrofa> jospoortvliet, no problem! Good afternoon :)
<jospoortvliet> now for putting them on a stick, so I can demo it at Chemnitzer Linux Tage (conference happening this weekend) ;-)
<kyrofa> Ooo, good luck!
<jospoortvliet> will be fun, np
<noizer> Hello guys
<noizer> I have some trouble with changing my apparmor. I think an issue in Snappy. here is the following error that I have. :http://pastebin.com/t87eZpjz
<noizer> error: http://pastebin.com/t87eZpjz
<noizer> Does somebody got any idea how I can fix it?
<jdstrand> we talked about this before
<jdstrand> this is possibly a bug in the ubuntu-core-launcher
<noizer> jdstrand: Yes but can it be fixed?
<noizer> jdstrand: In some later version?
<jdstrand> /home/ubuntu/snaps/ad.sideload/LTKVlHMSjhpm/snaps/ is not a valid path that the launcher should be looking at
<noizer> Maybe i can make that path so ...
<jdstrand> noizer: please file a bug at https://bugs.launchpad.net/snappy/+filebug with steps to reproduce if you're sure you are setting up everything correctly
<mvo> morphis: pong
<noizer> jdstrand: But you knows more about it what I'm trying to do and thats not in the filosofie of snappy
<jdstrand> noizer: sure-- it might be you are not setting an env var correctly. you should look at how things are set in /snaps/bin to see why the last /snaps/ is being appended. only when you are sure that the launcher is doing the wrong thing, file the bug
<kyrofa> noizer, yeah, check the $SNAP_USER_DATA variable
<noizer> jdstrand: I will look into it and let you know for more advice
<noizer> kyrofa: jdstrand Can i check it just over SSH to my raspi pi?
<kyrofa> noizer, first off, I'm assuming this is a binary, not a daemon, right?
<kyrofa> noizer, if yes, you can SSH in and check out the /snaps/bin/<binary> wrapper. If it's a daemon, you can SSH in and check out the /etc/systemd/system/<service>.service file
<sergiusens> kyrofa, here's one for you https://github.com/ubuntu-core/snapcraft/pull/379 :-)
<sergiusens> kyrofa, if you know of a stable snap on the staging server I can add an int test; I'm weary to add one otherwise
<kyrofa> sergiusens, not really-- everything I've ever done on staging was temporary :P
<kyrofa> sergiusens, though we have an upload test-- maybe couple them together a little?
<sergiusens> jdstrand, hey, the sudo problem needs to be solved regardless of what dir we default to as one of the system components creates the dir layout and if it is the first run and sudo is involved we create a boo boo
 * sergiusens speaks in loose terms since it is Friday after all
<kyrofa> sergiusens has kids
<sergiusens> just the one ;-)
<sergiusens> nice coveralls is giving me nice messages now
<kyrofa> sergiusens, explain this PR to me. How does the kernel needs snaps?
<mvo> ogra_, kyrofa: you had issues with services not starting, i assume this is still the case? I am testing this right now
<kyrofa> mvo, indeed-- they aren't activated on boot in 16.04 anymore
<sergiusens> kyrofa, look at the kernel pr :-)
<mvo> kyrofa: ok, let me try that
<sergiusens> kyrofa, in summary, generic initrd
<mvo> kyrofa: only when using u-d-f, right?
<sergiusens> mvo, is there any other tool?
<kyrofa> mvo, according to Chipaca and niemeyer I found out it isn't supposed to, though. Right, u-d-f
<mvo> kyrofa: eh, wuut?
<kyrofa> mvo, I learned that model assertions will be the way to do this
<mvo> kyrofa: indeed and yet that should still activate them
<mvo> kyrofa: plus we don't have them
<kyrofa> mvo, so I ended up making a gadget snap with built-in to work for now (preinstalled doesn't work either)
<mvo> sergiusens: I heard some talk about ubuntu-image ;)
<kyrofa> mvo, indeed
<mvo> kyrofa: but build-in does work?
<sergiusens> mvo, blocked on generic initrd and model assertions ;-)
<kyrofa> mvo, yeah, the gadget.go code parses that bit and activates on boot
<mvo> kyrofa: ok
<mvo> kyrofa: hm, hm, still awkward that we have --install in u-d-f and it does not work
<mvo> kyrofa: I guess I kill that for now at least
<kyrofa> mvo, yeah it's really hard to preinstall stuff now :P
<kyrofa> mvo, I had to fork the entire rpi2 gadget
<mvo> ogra_: you also had an issue with stuff not activated, was it the same?
<mvo> kyrofa: that sucks (pardon my language)
<sergiusens> mvo, btw, you may want to add StartLimitBurst= to the service units created; it would palliate the network requiring snaps a bit
<mvo> kyrofa: actually I think we need to do something about this because webdm is something we want to preinstall
<kyrofa> mvo, we could always add it to our gadgets if we don't want to support --install
<sergiusens> mvo, right, the correct path for preinstalling is to define it in the model
<sergiusens> mvo, but it is in a limbo state right now
<mvo> sergiusens: no disagreement
<mvo> sergiusens: I just don't like the limbo state, would be nice to be able to build images
<mvo> sergiusens: so that people can use/test them
<kyrofa> mvo, yeah, agreed
 * mvo scratches head
<sergiusens> mvo, of course; so many things have changed lately though that it is hard to unbreak everything :-)
<mvo> sergiusens: yeah
<mvo> sergiusens: I think we are very much in agreement :)
<sergiusens> kyrofa, so the os.snap holds the generic initrd.img that ogra_ built; the intermediate plan is to compose a full initrd.img until snappy learns about N initrd's that can be chainloaded
<noizer> jdstrand: kyrofa I got the following path
<noizer> export SNAP_USER_DATA="$HOME/snaps/ad.sideload/LTKWTFRHRRWC"
<jdstrand> kyrofa: did I hear correctly, model assertions are required for service start?
<kyrofa> jdstrand, oh no, just pre-installing snaps in a generated image
<sergiusens> mvo, I wish agreeing would magically fix things :-D
 * sergiusens is in a very Friday mood
<jdstrand> kyrofa: ok, I was going to say :)
<kyrofa> jdstrand, starting to sweat?
<jdstrand> noizer: I think what might be happening is when you call the scripts in /snaps/bin, your HOME is not /home/ubuntu, it is /home/ubuntu//snaps/ad.sideload/LTKWTFRHRRWC, so then the launcher looks at $HOME, tacks on /snaps and messes up
<jdstrand> noizer: the fix is doing HOME=/home/`id -u` /snaps/bin/...
<jdstrand> noizer: or similar (that won't work for root of course, but you get the idea)
<kyrofa> sergiusens, ahh, okay I see now. So this is (hopefully) temporary, then?
<jdstrand> err, id -un
<kyrofa> sergiusens, the downloading, I mean
<kyrofa> sergiusens, until we get them chained
<sergiusens> kyrofa, yeah; but if we lived in a beatiful world this storeapi thing would be its separate project and we'd use it for ubuntu-image as well (to download snaps)
<sergiusens> kyrofa, yes, until then
<noizer> jdstrand: But I can't fix it right now?
<kyrofa> sergiusens, that's not a bad idea. It might save us some work later, but it means facing the NEW queue
<sergiusens> kyrofa, new queue is easy once you know the right people ;-)
<kyrofa> sergiusens, ha!
<kyrofa> sergiusens, what do you think then? Shall we extract it?
<sergiusens> kyrofa, well now is not the time
<kyrofa> Or even implement the API in ubuntu-image?
<kyrofa> Okay
<sergiusens> kyrofa, it's in snapcraft since you know what
<kyrofa> Gotcha :)
<jdstrand> noizer: this is in your code
<jdstrand> noizer: you are calling /snaps/bin/... iirc
<noizer> jdstrand: yes thats my code how can i fix it then?
<roadmr> heya folks! I installed ubuntu-snappy-cli on a xenial system and there's no "snappy try". How can I try a locally built snap? I do have the snappy-dev ppa enabled
<qengho> Is there any preferred idiom for restarting one's self after a config change? Just use local config program to kill or something? No systemd poking or anything?
<jdstrand> noizer: I told you: you need to reset HOME to /home/ubuntu (or /home/`id -un` or something else smarter) before you call /snaps/bin/...
<jdstrand> HOME=/home/`id -un` /snaps/bin/...
<noizer> jdstrand: sorry i was a little confused :s
<jdstrand> np
<noizer> jdstrand: I set my HOME to /home/ubuntu and it won't help
<jdstrand> noizer: otoh not sure. look at the env vars being set in /snaps/bin/... (they are just shell scripts) and try to figure out what you need to do
<sergiusens> kyrofa, elopio I'm at a coffee shop that just got loud, mind if we start 10' late so I run home?
<kyrofa> sergiusens, sure thing
<kyrofa> sergiusens, no rush
<ogra_> mvo, yeah, it was the same issue (webdm got unpacked in /snaps but no "current" link and no systemd services were created)
<ogra_> mvo, we also used to be able to just build images without defining kernel and os (the oem snap used to define which ones it needs) ... that was very convenient, could we have that back ?
<mvo> ogra_: I pushed a branch that activates the installed snaps now, the other one is probably simple too, I need to look at an example, can't remeber the syntax that the gadget defines kernel/os
<ogra_> yeah, me neither, ricmm just pointed me to that yesterday, i'm alsready so used to define --os and --kernel :)
<ogra_> mvo, also, when do you plan to land the udf changes so people dont need to pull your binary ?
<ogra_> is there anything blocking ?
<mvo> ogra_: well, ubuntu-image, but I suspect more and more that this is not going to happen before 16.04 so maybe we should go ahead. my branch was proposed ages ago
<ogra_> (looks stable to me after using it for more than a month)
<mvo> ogra_: my branch for u-d-f
<ogra_> yeah, even if ubuntu-image happens we should have something that matches the current setup in the archive
<kyrofa> mvo, +1 on landing
<ogra_> until u-image is done
<kyrofa> mvo, we're still waiting on a number of things to happen before ubuntu-image anyway
 * ogra_ would like to disable tarballs on cdimage ... which will break the system-image setup, so u-d-f shouldnt use it for 16.04 anymore
<mvo> ogra_: hm, did ricmm point to the agreed syntax for kernel/os snap in gadget.yaml :) ? I can't find that right now
<ogra_> mvo, no, he just pointed out that it was possible with the old oem snaps ...
<mvo> kyrofa: yeah, I think that makes sense
<mvo> ogra_: right, well, hmmm
<mvo> ogra_: we may need to wait until there is agreement on the syntax but in principle its a simple change I think
<ogra_> probably nobody thought about that and it isnt in the spec
<ogra_> (i personally hd completely forgotten about it :) )
<morphis> mvo: nevermind, solved the problem already
<ogra_> sergiusens, thanks for the cliffhanger btw ... looks like we might re-discuss merged initrds vs loop mounted modules :)
<ogra_> (which in case we decide for the latter means changing the partitioning scheme )
 * ogra_ will try to preapre a prototype
<ogra_> sergiusens, so looking at https://github.com/ubuntu-core/snapcraft/pull/379 ... why not just pull the deb from the archive ... seems like overkill to use the whole os snap just to extract the img file
<sergiusens> ogra_, we can't know which OS and deb relate
<sergiusens> as in no traceability
<sergiusens> ogra_, this is jus temporary though as you now know ;-)
<ogra_> well, the generic initrd will have to come from somewhere
<ogra_> even in the future
<sergiusens> ogra_, yeah, but the kernel plugin won't need to pull it down
<ogra_> how else would you get it then ?
<kyrofa> ogra_, won't it be in the image?
<ogra_> kyrofa, it currently is ... but that wont help you if you build your arm kernel via snapcraft on your PC
<ogra_> then it would again need to pull the file from somewhere
<ogra_> (unless you limit it to only building in the classic dimension)
<roadmr> heya folks! I installed ubuntu-snappy-cli on a xenial system and there's no "snappy try". How can I try a locally built snap? I do have the snappy-dev ppa enabled
<kyrofa> ogra_, I guess I'm not super clear on what the end goal is. I imagined the kernel snap having its own initrd and the OS having another one, and at boot they get chained together. Perhaps I've misunderstood?
<elopio> mvo: ping. So, what should we use as the version of this deb we dput on changes to master?
<elopio> I was thinking that the sha1 doesn't work because it's not increasing.
<kyrofa> ogra_, i.e. they're independent
<ogra_> kyrofa, well, the discussion about the implementation is still ongoing (or ongoing again since yesterday), but yes, the generic part in either scenarion can then come from the os on boot
<ogra_> *scenario
<ogra_> sorry, i'm judging by waht we currently have :)
<ogra_> (which is "merge at build time")
<dholbach> davidcalle, you can set SNAPCRAFT_LOCAL_SOURCES as an environment variable and use what's in your /etc/apt/sources.list*
<kyrofa> ogra_, right, same page. I guess we're just assuming that the end goal will be to have them completely independent at build time, so we just have this temporary workaround for now
<dholbach> davidcalle, that'd trump whatever snapcraft's using by default and you could work around the mirror which has a broken hashsum (or is in the middle of mirroring)
<dholbach> at some stage, sergiusens will make me pay for every time I mention the local sources trick
<ogra_> kyrofa, i learned to only trust end golas if the code exists ... i guess thats my prob :)
<dholbach> it looks like a few people need this after all
<ogra_> *goals
<kyrofa> ogra_, heh
<davidcalle> dholbach: perfect, thanks :)
<mvo> elopio: ideally just whatever version we already have and we append ~ppaN (~ppa1, ~ppa2 etc)
<mvo> elopio: the "~" is important to ensure the version is smaller
<sergiusens> dholbach, I will make it default after I am done with this <josepht> jdstrand: I uploaded another revision
<sergiusens> dholbach, err https://github.com/ubuntu-core/snapcraft/pull/335
<sergiusens> not sure how that got copy/pasted ???
<sergiusens> darn xchat
<jdstrand> heh
<dholbach> oooh, nice
<dholbach> thanks sergiusens!
<sergiusens> dholbach, which will allow you to also mostly use build packages instead of stage packages for most things again
<dholbach> excellent
<dholbach> all rightie... I call it a day - have a good one everyone!
 * mvo hugs dholbach
<kyrofa> Bye dholbach!
 * dholbach hugs mvo and kyrofa 
<dholbach> mvo, email! :-)
<dholbach> see you!
<ogra_> mvo, how about we target next week to do an all-snaps 16.04 alpha release on cdimiage.u.c/ubuntu-snappy (independent of u-d-f being merged or my autosubmit of snaps from cdimage to the store i think we should have some recent image we can point people at in an official space)?
<mvo> ogra_: absolutely, this is why dholbach was bugging me about "send this mail"
<ogra_> ah
<roadmr> how can I try a locally-built snap?
 * ogra_ always uses a kvm image or if i build for arm i actually use the target device to try it 
<kyrofa> ogra_, yay for cdimage!
<ogra_> roadmr, i'm not sure that "snappy try" is working yet
<ogra_> s/that/if/
<roadmr> ogra_: thanks! this is amd64 so a kvm image would work. I'm happy to be pointed to docs if there are any :)
<ogra_> roadmr, http://people.canonical.com/~mvo/all-snaps/amd64-all-snap.img.xz ... unxz that ... then: kvm -m 512 -redir :8022::22 amd64-all-snap.img.
<ogra_> (and you can ssh/scp to localhost at port 8022)
<roadmr> ogra_: yay, thanks!
<ogra_> kyrofa, did you consider giving your "split /writable to separate img" script snippets to zyga so he can include it in his ubuntu-image script ?
<kyrofa> ogra_, no, but if you imagine it being more generally useful I totally can
<ogra_> i think it is, yeah
<ogra_> (for everyone wanting to have the payload on USB and boot on SD)
<kyrofa> ogra_, yeah I have a custom version of his ubuntu-image as well, so I should upstream the whole thing
<ogra_> yeah
<kyrofa> ogra_, I'll make a few PRs, thanks for the poke :)
<ogra_> thanks for the code :)
<sergiusens> dpm, `snappy build` is going bye bye, might be better to say `snapcraft snap [DIR]`
<kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/381
<kyrofa> elopio, ^^
<dpm> sergiusens, ah I've actually never used it, I've always used snapcraft so far. Any particular docs you've seen it mentioned?
<sergiusens> dpm, the one you just shared in the call
<dpm> sergiusens, ah, I see
<dpm> updating it
<sergiusens> dpm, you also mention 'clock' in there  ;-)
<sergiusens> dpm, I only have View; else I would of commented/suggested inside the doc :-)
<dpm> sergiusens, updated permissions, you should be able to edit/comment now :)
<dpm> thanks!
<ogra_> sergiusens, and now you own it !
<sergiusens> thanks
<sergiusens> ogra_, nah
<ogra_> :)
<dpm> dammit, it was worth a try :)
<kyrofa> sergiusens, have any atom plugins to recommend?
<sergiusens> kyrofa, you transitioned :-)
<kyrofa> sergiusens, I'm taking it for a spin anyway
<kyrofa> sergiusens, perhaps my combination of gedit vi and grep could be improved upon. Perhaps
<ogra_> gedit and vi ?
<ogra_> heh
<sergiusens> kyrofa, atom-python-debugger, git-plus, linter (A Base Linter with Cow Powers), linter-flake8, linter-golinter, linter-gotype, linter-govet, linter-pep8 (although flake8 takes care of the same) and the best of all vim-mode
<kyrofa> sergiusens, ah, it was watching your vim-mode that convinced me to try it out
<sergiusens> kyrofa, I like "linter" most of all for the description
<kyrofa> Hahaha
<sergiusens> kyrofa, the reason I stopped using vscode was that its vim-mode wasn't that good
 * kyrofa wonders how atom's ruby support is
<kyrofa> sergiusens, what about python-tools?
<dpm> davidcalle, I think the getting started doc is ready - if you want to have a quick review whenever you've got time, that'd be awesome
<davidcalle> dpm, alright, on my end, I'm still trying to figure how to handle runtime deps
<dpm> davidcalle, just put them all in :)
<dpm> have you tried with "stage-packages"?
<sergiusens> kyrofa, I just use the linter tools
<sergiusens> kyrofa, btw https://owncloud.org/blog/wd-labs-raspberry-pi-owncloud-and-ubuntu/
<davidcalle> dpm: that's the "all in" part I'm running after. Things build, but always choke on some missing lib when I try to run them. I'm tempted to add ubuntu-desktop ;)
<dpm> davidcalle, ah, I had that issue too, it's a bit of trial and error :)
<davidcalle> dpm: any way to not have to redownload anything when you change stage-packages?
<kyrofa> sergiusens, hey thanks!
<dpm> davidcalle, I haven't tried that yet, but the last comment on bug 1550679 might work
<ubottu> bug 1550679 in Snapcraft "Allow selective cleanup" [Undecided,Incomplete] https://launchpad.net/bugs/1550679
<davidcalle> dpm: thanks, doesn't work (yet?), but nice to see it's planned
<sergiusens> kyrofa, very nice
<sergiusens> kyrofa, I'll start looking at your PR in a bit btw
<joc_> sergiusens: hi, i've been trying to push this snapcraft PR along but keep hitting issues with the automated checks:
<joc_> https://github.com/ubuntu-core/snapcraft/pull/364
<kyrofa> Hey mvo do we have a bug for the unversioned data directory?
<joc_> sergiusens: do you know if that is a problem with the tools or my PR?
<sergiusens> joc_, given that other PRs are testing fine I'd guess with your PR; elopio mind checking?
<sergiusens> joc_, if you have vpn access just click on details to see
<joc_> sergiusens: ah thanks, didnt have vpn enabled
<kyrofa> sergiusens, okay I admit. Atom is an improvement
<sergiusens> kyrofa, it is nice; I downloaded it for a test run and here I am still 8 months in
<kyrofa> sergiusens, and it's light and fast. That's why I was using my previous solution-- everything was so slow
<kyrofa> everything else, rather
<sergiusens> kyrofa, what other things were you using?
<sergiusens> vim wouldn't be slow, but package management and the packages can get slow/flaky
<kyrofa> sergiusens, no that's what I mean-- vi and gedit are both super light. But like, eclipse for instance
<elopio> joc_: http://paste.ubuntu.com/15416550/
<joc_> elopio: thanks, where did you get that output from?
<joc_> elopio: i.e. can i get to it myself from the PR?
<elopio> joc_: yes, just enable the vpn and go to the details link
<elopio> http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/176/console
<ogra_> kyrofa, hahahaha (reading the blog article you linked)
<ogra_> "This brings a very familiar operating system to the device"
<ogra_> :D
<kyrofa> ogra_, yeah I noticed that myself
<kyrofa> Some people might be surprised
<ogra_> yeah
<ogra_> well, we need to promote the classic dimension more ... there we are actually a familiar choice ;)
 * ogra_ wishes we had a "snappy enable-classic-with-snapcraft" 
<ogra_> kyrofa, nontheless, awesome !!!!
<kyrofa> ogra_, thanks! :)
<wililupy> Question: In Xenial, how do we run snappy-remote?
<ogra_> is it broken ?
 * ogra_ never uses it 
<ogra_> (being just a wrapper around two scp and ssh commands)
<wililupy> I try to install snappy-tools from the ppa, but it says unable to locate package.
<wililupy> This is on a xenial workstation.
<ogra_> there might not be a xenial build for it indeed ... since "snappy try" is actually supposed to replace it (but i think thats not complete yet)
<wililupy> I guess I could always just scp the .snap to the device and locally run snappy install, but I was hoping to do everything remote.
<wililupy> Heh, I tried snappy try on xenail and it said, "Unknown command `try', did you mean `activate'?"
<ogra_> sergiusens, ^^ any chance we could have a xenial build of snappy-tools (at least til snapcraft try works)
<wililupy> There's room for a Star Wars Easter egg there ;)
<sergiusens> ogra_, just copy_package it into xenial if you want
<verterok> Hi, used snapcraft to build a snap of a python CLI app, but when I try to install it (kvm) but fails with: "failed to install: Signature verification failed with exit status 14"
<verterok> couldn't find anything regariding the exit status 14, any ideas what might be going on?
<kyrofa> verterok, you need --allow-unauthenticated when installing
<kyrofa> snappy install <snap> --allow-unauthenticated
<kyrofa> verterok, only snaps in the store are signed
<verterok> kyrofa: I'm using --allow-unauthenticated
<kyrofa> verterok, oh
<kyrofa> verterok, 15.04 or 16.04?
<verterok> kyrofa: ubuntu-core/15.04/stable
<verterok> kyrofa: following the docs on both: 1) how to build a snap and 2) get snappy running on kvm
<kyrofa> verterok, is it a large snap?
<verterok> kyrofa: 48M
<verterok> I can upload it somewhere if it helps, but will take a bit with my current connection
<kyrofa> verterok, how much RAM do you have in the VM?
<verterok> kyrofa: 512
<verterok> should I bump it?
<kyrofa> verterok, can you run  debsig-verify -d on the snap manually?
<kyrofa> It sounds like the code checks for a signature and then decides whether or not to ignore it
<verterok> kyrofa: http://paste.ubuntu.com/15417537/
<kyrofa> verterok, how did you create the snap?
<verterok> kyrofa: snapcraft
<kyrofa> verterok, which version?
<verterok> kyrofa: 2.4
<verterok> I'm in xenial
<kyrofa> verterok, ah, you are a victim of the currently terrible documentation situation
<verterok> kyrofa: :)
<kyrofa> verterok, if you're targeting pre-16.04, you must use Snapcraft 1.x (available pre-xenial back to trusty)
<kyrofa> Snapcraft 2.x packages totally differently
<verterok> kyrofa: oh, ok.
<verterok> kyrofa: will add the ppa and install 1.0
<verterok> kyrofa: thanks for the help
<kyrofa> verterok, no problem! Note that you still may run into issues running Snapcraft 1.x on xenial, as the generated snap may end up wanting a newer libc than snappy 15.04 offers
<kyrofa> verterok, we recommend running snapcraft on the same version of ubuntu you're targeting
<verterok> kyrofa: got it, will create a trusty lxd ;-)
<kyrofa> verterok, that's what I do as well :)
<verterok> or just create a 16.04 snap vm
<kyrofa> verterok, good luck, and I'm sorry about that! We're trying to clean up the docs now
<verterok> np, just trying to get my first snap working
<kyrofa> verterok, that works too, images here: http://people.canonical.com/~mvo/all-snaps/
<verterok> thanks
<sergiusens> ogra_, is this a correct path /usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 ? fwiw I can't x-compile upstream busybox :-)
<sergiusens> or asked differently, is this sort of the same issue you saw when doing the generic initrd work?
<kyrofa> sergiusens, strip cleaning: https://github.com/ubuntu-core/snapcraft/pull/382
<leftyfb> will snappy run on the rpi3?
<sergiusens> kyrofa, looking
<sergiusens> leftyfb, not yet
<leftyfb> sergiusens: will it run on it or is it just "unsupported"? Is it the kernel that lacks something for the new arm8?
<sergiusens> leftyfb, it will not run yet; afaik we are waiting on broadcom to release their bootloader bits
<sergiusens> but I haven't been paying attention
<sergiusens> it's all about the dragonboard for me now :-)
<sergiusens> kyrofa, do you know how to regenerate the PR view? I don't want to see code I already saw :-)
<leftyfb> sergiusens: https://mailman.owncloud.org/pipermail/devel/2016-March/002273.html ?
<leftyfb> https://mailman.owncloud.org/pipermail/devel/2016-March/002273.html
<leftyfb> oh, pi2
<leftyfb> nevermind :)
<leftyfb> though according to this https://owncloud.org/blog/wd-labs-raspberry-pi-owncloud-and-ubuntu/ it looks like you can build your own 16.04 snap
<sergiusens> leftyfb, still pi2
#snappy 2016-03-19
<enoch85> hey kyrofa
<enoch85> kyrofa: what about adding redis to the owncloud snap, would that be possible?
<mvip> Hey guys. Is the RasPi 3 supported in the latest upstream images?
<ogra_> not yet, no
<mvip> ogra_ :(
<ogra_> we rely heavily on u-boot ... thats not 100% done yet foor the pi3
<mvip> ogra_ Should be relatively easy to do by pulling in the latest kernel, no?
<mvip> ah ok
<ogra_> it is on my TODO and we'll definitely have images once it is ready
<mvip> well, it will be the same image, won't it?
<ogra_> not sure yet ... it might need a different devicetree
<ogra_> (which means differennt gadget snap in our current design)
<ogra_> (which in turn means separate image)
<mvip> hmm that would make our life a lot more painful as a vendor
<mvip> as we'd need to maintain twice as many images
<mvip> The upstream Raspbian images works fine with both RasPi3 and RasPi 2 fwiw
<ogra_> well, after all i'd be shooting for a 64bit image in the long term
<ogra_> which would mean separate image in any case
<mvip> yeah, i guess that's a good point
<ogra_> i'l try my best to get a single image for us ... but no promises :)
<ogra_> (for 32bit)
<mvip> Thanks, ogra_
<mvip> It would be *very* cool to have a single image and then have the system auto-detect the 64 bit and pull down the 64 bit system as a system upgrade for the next a/b system. :)
<mvip> not sure how viable that would be
<ogra_> that would need quite some work
<ogra_> (it is likely that you need a specific kernel for aarch64 ... we dont support switching kernels at all on installed images)
<ogra_> i.e. it would only work if you hade two kernels in the same kernel package so it could be switched
<mvip> IIRC, Raspbian uses the same kernel, but I'm not sure if it's fully 64 enabled yet
<ogra_> it isnt
<mvip> oh ok
<ogra_> pi3 isnt 64bit capable yet ...
<mvip> Wasn't that one of the major things in the Pi3?
<ogra_> the SoC is 64bit ... bt afaik neither th bootlloader can initialize it in that mode yet nor are all kernel patches there
<ogra_> and i'm rather doubtful that you can have a single kernel that does both
<mvip> Interesting. Well, sounds like you're far more on top of this stuff than me. ;)
<ogra_> just by trial and error ;)
<mvip> Hahah
<mvip> I just rebuilt my 4x RasPi cluster today with 3 RasPi 3s hoping to do some more QA/testing on Snappy. Didn't even think about that it wasn't supported.
<popey> yeah, I have a pi3 on my desk which is waiting for snappy too :(
<mvip> ogra_: yeah you're right. Looking at /proc/cpuinfo on Raspbian, I can confirm that the RasPi 3 is running as an ARMv7 and not ARMv8.
<ali1234> ogra_: did you get the writable partition resize thing fixed?
<ali1234> also someone got a 64 bit kernel to boot on the pi 3. but no communication between the videocore and arm
<ogra_> ali1234, the GPT resizing is fixed since a while in the cdimage snaps
<ali1234> cdimage.ubuntu.com?
<ali1234> it only has 15.04?
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<ali1234> oh, you renamed it again?
<ogra_> has kernel and os snaps (i'm working on auto-upload to the store atm)
<ali1234> i can't keep up with all this
<ogra_> renamd ?
 * ogra_ didnt rename anything
<ali1234> what is http://cdimage.ubuntu.com/ubuntu-snappy/
<ogra_> officially released img files
<ali1234> what is ubuntu-core then?
<ogra_> the prodcut
<ogra_> *product
<ali1234> what is the difference?
<ogra_> no difference
<ogra_> different stages of the build
<ogra_> in 15.04 we used to use a system-image server that pulled the tarballs from cdimage daily builds
<ogra_> in 16.04 everything was switched to be snaps from the store (withou system-image server)
<ogra_> so the interim step switched from tarball to snap
<ali1234> has it ever occurred to you that all of this might be so complicated that hardly anyone will be able to understand it?
<ali1234> and that this might hamper adoption?
<ogra_> why would anyone need to understand it
<ali1234> if i didn't need to understand the software i am running i would just use microcoft
<ogra_> you will use ubuntu-device-flash to build an image (and later ubuntu-image)
<ogra_> or you download a per-made image from http://cdimage.ubuntu.com/ubuntu-snappy/
<ogra_> nothing has changed there
<ogra_> (just the backend process has)
<ali1234> let's say i have to do disaster recovery on a snappy drive
<ali1234> where do i even look for "the files"?
<ali1234> stuff like this
<ali1234> that's just a hypothetical question
<ogra_> in /writable
<sergiusens> that should be the front facing website, not cdimage though
<ogra_> nothing changed there
<ogra_> sergiusens, well, the downloads will come from cdimage
<ali1234>  /writable isnt mounted, the disk is dead
<sergiusens> and if you want the 'os' you'd probably go to the vendor's website
<ogra_> right
<sergiusens> ogra_, only under dev; we also plan to put these under releases.ubuntu.com
<ogra_> well ... s/"os"/"img"/
<sergiusens> well infinity does
<sergiusens> yeah img
<ogra_> crazy canadians :)
<ogra_> but yeah, might be under release.u.c
 * sergiusens continues to fight python mocking
<ogra_> in ayn case fro the enduser nothing really changed
<ogra_> you either use u-d-f or dd a downloaded img file
<ogra_> for the developer it is interesting to doownload the artefacts from cdimage to get the latest stuff atm though
<ogra_> in case you want to try something thats not in the released img files yet
<ogra_> which is why i pointed ali1234 there
<ogra_> (like the fixed GT resizing)
<ogra_> *GPT
<ogra_> (though on the rpi that doesnt kick in anyway, since it uses an msdos table ... and that has not been broken to my knowledge)
<ali1234> huh?
<ogra_> huh ? huh ?
<ogra_> :)
<ali1234> so why doesn't /writable get resized on rpi?
<ogra_> i havent heard of it not being resized ... nobody filed a bug
<ali1234> two days ago you said you were fixing it
<ogra_> (and i have personally not touched rpi in a while ... only tired the pi3 for a quick test)
<ogra_> ali1234, hmm, not on the pi though ... the GPT resizing on dragonboards is known to be broken ... thats what i fixed ... (about aa week ago thouh)
<ogra_> (well, GPT on dragonboard and amd64 in fact)
<ogra_> ali1234, soory, that might have been some miscommunication ...
<ali1234> it's broken on the pi
<ali1234> with the all-snaps image
<ogra_> i'll check that on monday then ... shouldnt be broken ... the code hasnt changed in ages
<ali1234> http://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz
<ogra_> (it simply calls parted resizepart ... pretty dumb code)
<ali1234> i'll test it again just to make sure
<ali1234> then i'll try building my own image with ubuntu-device-flash and test that
<ali1234> ogra_: confirmed that http://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz does not resize /writable. i built an image with ubuntu-device-flash and make-rpi2-all-snap.sh and it does not boot at all.
#snappy 2016-03-20
<netpheak> HI, guys!
<danny_> noob here hoping to find a way to install curl on snappy
#snappy 2017-03-13
<jjgalvez6500> does anyone know what the issue is wit nvidia drivers and snaps, I am getting the libGl issue, failed to load swrast, and how to fix it?
<jjgalvez6500> does anyknow how to fix the nvidia GL issue, I'm still having it
<soffokl_> Good morning everyone.
<soffokl_> Can someone help me with configuring logging for snap package. journalctl shows only last 5 min of logs. Older records trancated.
<soffokl_> Is there a way to configure a period of storing logs for snap service?
<soffokl_> /etc/systemd/journald.conf is readonly
<liuxg> ogra_, ping
<mup> PR snapd#3017 opened: tests: prevent automatic transition before setting the initial state of the test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3017>
<mup> PR snapd#3012 closed: [interfaces] Enable location.Service.Provider in dbus policy <Created by vosst> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3012>
<mup> PR snapd#3018 opened: tests: add empty initrd failover test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3018>
<kalikiana_> soffokl: Have a look at bug 1504645
<mup> Bug #1504645: please add syslog support to snappy config ubuntu-core <Snappy:Confirmed for ogra> <ubuntu-core-config (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1504645>
<soffokl> Good morning everyone.
<soffokl>  Can someone help me with configuring logging for snap package. journalctl shows only last 5 min of logs. Older records trancated.
<soffokl>  Is there a way to configure a period of storing logs for snap service?
<soffokl> `/etc/systemd/journald.conf` is readonly.
<Son_Goku> zyga, yo
<kalikiana_> soffokl: Did you see the bug 1504645? It was just very recently fixed
<mup> Bug #1504645: please add syslog support to snappy config ubuntu-core <Snappy:Confirmed for ogra> <ubuntu-core-config (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1504645>
<ogra_> kalikiana_, not complete yet
<kalikiana_> ogra_: Right, but the directory soffokl was asking about is writable at least
<ogra_> yes
<soffokl> kalikiana_: looks like fix for 1504645 related only to rsyslog.d. Services from snap served by journald, and catch all standard output.
<ogra_> and the option fix was in there already for like 4 weeks
<ogra_> (but got dropped when the build scripts moved to github)
<soffokl> My problem that it rotates logs every 5 minutes. And I do not see the way to configure it.
<ogra_> soffokl, that would be a new bug ... (though not sure how you got into that situation, it definitely doesnt do that by default)
<ogra_> logrotate should only run once a day in a default setup
<ogra_> oh, wait you are talking solely about journald ... if you search in the journald output through the right journalctl filters it should show more than 5min
<ogra_> (i.e. everything the log has for your service since startup)
<soffokl> looking logs of my service like this "journalctl -u snap.myapp.myservice-service" and records older than 5 mins disappearing every minute
<soffokl> filters didn't help
<ogra_> well, file a new wishlist bug to make journald configurable ...
<ogra_> journald uses a ringbuffer, perhaps your stuff logs to much for that
<soffokl> ogra_: just checked, it's only 27 records in 5 min
<soffokl> journalctl option --since with wider period does not add anothing
<soffokl> ogra_, kalikiana_: looks like I found the reason, problem related to the common size of all logs in the system. When "journalctl --disk-usage" showing more than 85MB of logs, it starts to clean old records. Some other service floods to logs. Thanks for your help.
<ogra_> soffokl, well, if it is one of the preinstalled services, please file a bug :) that should indeed not happen by default
<soffokl> looks like it's auditd tracks all actions and logs it in devmode :(
<ogra_> oh, yeah, thats by design
<soffokl> and no way to stop it? :D
<ogra_> there might be, wait til jdstrand gets up ... he might know if you can perhaps hack the apparmor rules to quieten it
<ogra_> (would indeed be a hack but if you need to debug something else ....)
<soffokl> thanks, I will wait him. It could help me a lot at this moment.
<tim_> hey there, I
<tim_> *I'm not sure if this is the right place to ask for things like this. Does anyone know who I can contact for account-related issues with rocket.ubuntu.com?
<OerHeks> tim_, not sure where, maybe contact form ? https://rocket.chat/contact
<zyga> Son_Goku: hey, not paying much attention to IRC, sorry
<Son_Goku> :(
<zyga> Son_Goku: what's up? :)
<Son_Goku> zyga: any progress on packaging the missing golang deps?
<tim_> OerHeks: Thanks, but isn't rocket.ubuntu.com self-hosted?
<OerHeks> not sure, i just joined
<OerHeks> thanks for the tip !
<tim_> The problem is that I changed my email address for the Ubuntu One SSO service but now rocket.ubuntu.com doesn't let me connect anymore.
<zyga> Son_Goku: as you know I drowned on gofed, I'll do more today
<zyga> Son_Goku: but first snap-update-ns work
<JamesTait> Snapcraft hackers: I'm about to approve a code change to the store that modifies an error message when someone attempts to register a snap with a reserved name. The same Django form is used in the API and the web UI. I want to make sure that if I change just the error message, but leave the error code the same, snapcraft will just map the error code to a message ...
<JamesTait> ... internally and so be unaffected by the change. This seems to be the case judging by snapcraft.storeapi.errors
<ogra_> JamesTait, your chances catchging a snapcraft hacker are bigger on rocket i think (see topic)
<JamesTait> Thanks, ogra_.
<ogra_> (communication around snappy is sadly very fragmented nowadays)
<JamesTait> https://xkcd.com/927/
<ogra_> 1
<ogra_> err
<ogra_> +1
<mup> PR snapd#3019 opened: cmd/snap-update-ns: use bidirectional lists for mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3019>
<sqrt> hi
<mup> PR snapd#2644 closed: snapctl: support running by the snap app itself, not only just from hooks <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2644>
<sqrt> whats the difference between snapd-plus-vendor and snapd on https://github.com/snapcore/ ?
<nuclearbob> I'm running into an issue with the auto-refresh spead test in snapd 2.23: https://bugs.launchpad.net/snapd/+bug/1672426
<mup> Bug #1672426: spread auto-refresh test failing in snapd 2.23 <snapd:New> <https://launchpad.net/bugs/1672426>
<mup> PR snapd#3020 opened: osutil: fix double expand in environment map code and add test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3020>
<mup> PR snapd#2942 closed: tests: add core-snap-refresh test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2942>
<mup> PR snapd#2952 closed: release: detect if we are in ForcedDevMode by inspecting the kernel <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2952>
<mcphail> Is there any way to trigger an email when a snap updates?
<mup> PR snapd#3021 opened: asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets <Created by pedronis> <https://github.com/snapcore/snapd/pull/3021>
<mup> PR snapd#3022 opened: cmd: validate SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/3022>
<mup> PR snapd#3022 closed: cmd: validate SNAP_NAME <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3022>
<mup> PR snapcraft#1186 opened: demos: add ROS content sharing demo <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1186>
<mup> PR snapd#3023 opened: cmd: validate SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/3023>
<soffokl> jdstrand: Hello, ogra_ metioned that you can help me. I'm looking for a way/hack to prevent auditd to log all actions of my snap package that installed in devmode.
<zyga> soffokl: I believe jamie is off this week
<soffokl> zyga: oh, thanks for the update
<mup> PR snapcraft#1187 opened: tests: take into account the new current link <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1187>
<mcphail> Is there any way to trigger an email when a snap updates?
<mup> PR snapd#3024 opened: interfaces: use apparmor spec in the apparmor backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/3024>
<mup> PR snapcraft#1160 closed: cli: rename `history` to 'list-revisions' with `revisions` alias <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1160>
<mup> PR snapd#3017 closed: tests: prevent automatic transition before setting the initial state of the test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3017>
<mup> PR snapd#3019 closed: cmd/snap-update-ns: use bidirectional lists for mount entries <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3019>
<mup> PR snapd#3025 opened: cmd/snap-update-ns: compute the actions required to transform mount environment <Created by zyga> <https://github.com/snapcore/snapd/pull/3025>
<mup> PR snapcraft#1188 opened: store: set User-Agent header in store requests <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1188>
<mup> PR snapcraft#1189 opened: core: resolve ld link first <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1189>
<mwhudson> what would make snapcraft suddenly fail to find a local plugin?
<mwhudson> Searching for local plugin for x-gobuild
<mwhudson> Issue while loading plugin: unknown plugin: x-gobuild
<mwhudson> oh an importerror in my plugin
<mwhudson> hooray python
<mwhudson> ah aaah can we please get a traceback when my plugin fails?
<qengho> snapcraft --debug
<mwhudson> qengho: thanks
#snappy 2017-03-14
<mwhudson> er i thought there was some way i could embed a part's git sha1 into the snapcraft version, am i making that up
<mwhudson> ?
<sergiusens> mwhudson: that has been discussed but not possible yet
<sergiusens> in should be soonish but I need to send a proposal out
<mwhudson> sergiusens: ah i'll stop looking for how to do it in the source then :-)
<zyga> o/
<mup> PR snapd#2995 closed: interfaces: extend location-control out-of-process provider support <Created by vosst> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2995>
<outsidecontext> hi. I have searched a lot, but found no definitive answer. is there some generic way to give my snapped app access to call a DBus interface?
<outsidecontext> or does this always require implementing a snapd interface which gives access to the specific DBus interface?
<zyga> outsidecontext: it depends, we now have a generic dbus interface
<outsidecontext> zyga: ok. would it allow me to configure my snapped app to access e.g. org.freedesktop.FileManager1 ?
<mup> PR snapd#3026 opened: cmd/snap-confine: use defensive argument parser <Created by zyga> <https://github.com/snapcore/snapd/pull/3026>
<zyga> outsidecontext: if that thing is running unconfined then the answer is no, for that you need a proper interface
<zyga> outsidecontext: we have a dbus interface for apps that want to provide dbus services
<zyga> outsidecontext: or talk to dbus services provided by other snaps
<zyga> outsidecontext: but if you want to talk to something outside of the sandbox you need a new interface as this has unpredictable security impact
<outsidecontext> zyga: I see. I am aware that I can expose a DBus interface, but that doesn't help in this case
<outsidecontext> zyga: so a generic interface to access unconfined DBus interfaces will not happen? that's a pitty :(
<outsidecontext> zyga: but thanks for confirming my suspicion. that makes it a bit hard to package anything that relies on DBus services not covered by the existing interfaces
<zyga> outsidecontext: it's the only way to make security sensible
<zyga> outsidecontext: would you feel comfortable knowing that any snap you install can talk to *anything* on your system session or service bus?
<zyga> outsidecontext: outside of any supervision?
<outsidecontext> zyga: wouldn't it be similar to e.g. the x11 interface? or any other available service granting me access to dbus services? any app can use those, too
<zyga> outsidecontext: no, it would not; x11 is going away and we cannot mediate it (if we could, it would be confined already)
<zyga> outsidecontext: all the other interfaces that grant dbus access were reviewed by the security team
<zyga> outsidecontext: in many cases new services are created as old services were insecure
<zyga> outsidecontext: and many sensitive apis are blocked
<zyga> outsidecontext: the security review goes into reviewing the actual code on the other side of the dbus connection
<outsidecontext> zyga: ok, I see. so the idea is to have interfaces only for secure, well behaving DBus services. makes sense
<zyga> outsidecontext: well, in general the idea is not to give blank checks
<zyga> outsidecontext: that give you access to unconfined processes
<zyga> outsidecontext: please file a bug on snapd, describe your case and we can simply add an interface for what you need
<outsidecontext> zyga: how would one go forward with general services like  org.freedesktop.FileManager1 ? does it make sense for me to open a feature request for snapd?
<outsidecontext> zyga: was too slow, you already gave the answer. I will do that
<zyga> outsidecontext: I'm not sure yet, but the way to start is to file a bug I think :)
<zyga> outsidecontext: the security team will review the code and we can make decisions
<outsidecontext> zyga: thanks a lot :)
<zyga> outsidecontext: I'm sorry security isn't easier :)
<gbisson> Hi all, what is the best way to debug snapd modules mounting? I'm asking because since Friday I can't seem to create an image which loads the modules/firmware in /lib/, don't know why
<gbisson> I've looked at the syslog/journalctl/snap changes etc... the only thing I can see is that lib-firmware.mount and lib-modules.mount (systemctl) don't happen any more
<mup> PR snapd#3027 opened: snap: run snap-confine from core if snap is also running from core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3027>
<mup> PR snapd#3028 opened: interfaces: seccomp tests cleanup <Created by stolowski> <https://github.com/snapcore/snapd/pull/3028>
<mup> PR snapcraft#1189 closed: core: resolve ld link first <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1189>
<mup> PR snapd#3020 closed: osutil: fix double expand in environment map code and add test <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3020>
<gbisson> I'm answering my own question, /lib/modules or /lib/firmware is only mounted if the folders are in the root directory of the kernel snap https://bugs.launchpad.net/snapcraft/+bug/1658177
<mup> Bug #1658177: snapcraft kernel plugin puts module and firmware under 15.04-era lib/ directory <Snapcraft:Fix Released by lool> <https://launchpad.net/bugs/1658177>
<gbisson> my snapcraft version was apparently too old
<barry> hi all.  is there anything i have to explicitly do in order to get my classic snap reviewed?
<alecu> ogra_, morphis: any idea why bluetoothctrl on the raspi3 with core can't find any bluetooth controller?
<alecu> I'm trying out the steps here: https://docs.ubuntu.com/core/en/stacks/bluetooth/doc/overview
<alecu> but it gets stuck waiting for the line that reads: "[NEW] Controller 1C:C3:E4:79:43:4C localhost.localdomain [default]"
<morphis> alecu: don't know, need to check with koza
<alecu> Sounds good, let's ask koza then
<Son_Goku> zyga, any luck on those two golang deps?
<pmcgowan> ogra_, question about time updates on core images
<Marco_> Hi
<Marco_> I have a question about installing snapd on debian
<Marco_> Can someone help me ?
<pmcgowan> zyga, maybe
<seb128> or you can just ask and see if somebody knows the answer
<Marco_> I just have one question, what debian sources i need to add to  my sources list, because now apt install snapd does not work
<Marco_> Ty :)
<nacc> Marco_: what version of debian are you on?
<Marco_> nacc, Last one debian 8,4
<nacc> Marco_: that's stable, right?
<Marco_> nacc: Yup :)
<nacc> Marco_: snapd is only in testing and unstable curently
<Marco_> Ah, thats maybe why, because i want to install Rocket.Chat but i have some issues, and it seems easier with snapd
<Marco_> Thanks also for you help
<nacc> slangasek: funny 'snapd' in sid says "Manage an Ubuntu system with snappy." and "Tool to interact with Ubuntu Core Snappy."
<nacc> slangasek: which i guess might be true, but is odd to read in Debian
<nacc> Marco_: yeah, that's my guess -- i don't know much beyond that, was just reporting what i saw in rmadison
<Marco_> OK, So thank you all for helping me,
<Marco_> Have a great day
<mup> PR snapcraft#1187 closed: tests: take into account the new current link <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1187>
<mup> PR snapcraft#1190 opened: .travis.yml: Don't use sudo to install dependencies as it's not even installed yet <Created by Roadmaster> <https://github.com/snapcore/snapcraft/pull/1190>
<mup> Bug #1672803 opened: Console-conf crashes on db with wrong wlan SSID <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1672803>
<mup> PR snapd#3013 closed: cmd/libsnap: simplify sc_string_quote default case <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3013>
<mup> PR snapcraft#1191 opened: tests: run the CLA check in a docker container <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1191>
<mup> PR snapcraft#1190 closed: .travis.yml: Don't use sudo to install dependencies as it's not even installed yet <Created by Roadmaster> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1190>
<marcoceppi> How do I prime packages from a PPA?
<mup> PR snapd#3029 opened: snapstate: introduce helper to apply to disk a alias states change for a snap <Created by pedronis> <https://github.com/snapcore/snapd/pull/3029>
<elopio> marcoceppi: you can't. There are a few whishlist bugs, like https://bugs.launchpad.net/snapcraft/+bug/1493081
<mup> Bug #1493081: Ubuntu plugin: allow downloading of binary packages from PPAs <first-steps> <Snapcraft:Triaged> <https://launchpad.net/bugs/1493081>
<marcoceppi> elopio: not even with like, scriptlets?
<elopio> marcoceppi: oh, well, on a scriptlet you can do whatever you want, even add-apt-repository. And then add to stage-packages something from that repository.
<marcoceppi> elopio: is there an example of that?
<elopio> that's not like, really supported, but you can.
<elopio> marcoceppi: no. The guideline is to support snaps as build-packages and snaps as remote parts first. We shouldn't recommend to use PPAs.
<elopio> I recently updated my go examples to use the go part, instead of the go ppa.
<mup> PR snapcraft#1192 opened: repo: refactor into a package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1192>
<mup> Bug #1672472 opened: Date and time reports the wrong timezone <Snappy:New> <snapweb:Confirmed for justinmcp> <https://launchpad.net/bugs/1672472>
<mcphail> kyrofa: is there any way to set snapd to email me when nextcloud updates, so I can re-enable the apps?
<mup> PR snapd#3030 opened: assertstate,snapstate: have assertstate.AutoAliases use the "aliases" header <Created by pedronis> <https://github.com/snapcore/snapd/pull/3030>
<King_InuYasha> sergiusens: first round of comments on the PR :)
<coreycb> sergiusens, hi, i narrowed this down a bit more: https://bugs.launchpad.net/snappy/+bug/1670852
<mup> Bug #1670852: python console_scripts not installed into /snap/<snap>/current/bin <openstack> <Snappy:New> <https://launchpad.net/bugs/1670852>
<sergiusens> coreycb: interesting, btw, this is a dup, now I don't know which to make a dup of which
<coreycb> sergiusens, oh ok.  well it doesn't matter to me.
<mwhudson> oh ho
<mwhudson> has anyone tried reproducing this setuid issue on a newer kernel, say zesty?
<mwhudson> oh hm
<mwhudson> kernel git is slightly different in a way that i have no idea is important or not
<mwhudson> but zesty does not have that change yet
<sergiusens> coreycb: https://bugs.launchpad.net/bugs/1670323
<mup> Bug #1670323: binary entry (and lib) for python projects not installed in final snap <amd64> <apport-bug> <xenial> <Snapcraft:New> <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1670323>
<sergiusens> coreycb: but you raise an interesting point, isn't pip_command a list in your tests? such as `python -m pip install ...' ?
<sergiusens> King_InuYasha: thanks!
<King_InuYasha> sergiusens: np, I'm glad to see us finally moving forward on it! :D
<coreycb> sergiusens, you mean as opposed to a string?
<sergiusens> coreycb: yeah, a list of those elements in the string I gave you above
<mup> Bug #1672872 opened: error while loading shared libraries: libpython2.7.so.1.0 <openstack> <Snappy:New> <https://launchpad.net/bugs/1672872>
<coreycb> sergiusens, it is in fact a list
<sergiusens> coreycb: ah, good, so then I need to be smarter about pip_command
<sergiusens> python is really messy sometimes :-/
<coreycb> sergiusens, :)
<sergiusens> can't wait to see what other ripple effects there are after changing this
<coreycb> sergiusens, happy to give it a test run if you want
<mup> PR snapcraft#1193 opened: asset-tracking: track per-part build-packages <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1193>
<mup> PR snapcraft#1140 closed: [WIP] catkin plugin: support building with an underlay <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1140>
<mup> PR snapd#3031 opened: cmd/snap-confine-suid-trampoline: add new helper <Created by zyga> <https://github.com/snapcore/snapd/pull/3031>
#snappy 2017-03-15
<mup> PR snapcraft#1186 closed: demos: add ROS content sharing demo <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1186>
<olympionex> has anybody used snapcraft with a source file on dropbox?  It appears that whatever mechanism dropbox is using to download the source is not following the redirects.  There is just a file with html.  I'm looking through the snapcraft code, but is it not using wget or something similar/
<olympionex> hmm, looks like its using requests.get with allow_redirects=True
<sergiusens> olympionex: seems like a credentials thing, can the file be downloaded anonymously?
<sergiusens> can you wget the file?
<olympionex> yeah
<sergiusens> from the link that is
<olympionex> copied and pasted the url from the yaml just to make sure
<olympionex> and it works fine with wget
<olympionex> but the pull phase of snapcraft is only getting some html
<olympionex> its a link share on dropbox which means anyone with the link should be able to download it, so no required login
<olympionex> sergiusens: here is a demo pastebin
<olympionex> http://pastebin.com/jdZuNVD4
<mup> PR snapcraft#1194 opened: tests: remove repo.Ubuntu patch for plugins <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1194>
<olympionex> sergiusens: nevermind, I was misinformed by something I read earlier.  Apparently the url param at the end of the dropbox links determines whether its for a direct download or for just viewing the file on dropbox.  I had read that dl=1 compressed the file but that appears not to be true
<olympionex> changing the links to dl=1 caused snapcraft to work fine
<sergiusens> great
<sergiusens> oh dear, it is already Wednesday here
<mup> PR snapcraft#1191 closed: tests: run the CLA check in a docker container <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1191>
<mup> PR snapcraft#1194 closed: tests: remove repo.Ubuntu patch for plugins <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1194>
<shuduo> zyga: hi, i tried to run "dnf install snapd" on fedora 25 but failed with "Failed to synchronize cache for repo 'zyga-snapcore', disabling." I believe it need be built against fedroa 25 as it works well on 24.
<zyga> shuduo: hi
<shuduo> zyga: hi
<zyga> shuduo: there are no build for fedora 24/25/26 yet; still on a TODO list, I need help if you are interested (we need two prerequisites packaged)
<zyga> shuduo: the COPR build is disabled now
<zyga> shuduo: and we have a package almost ready to release into the archive but because of the extra work to de-vendorize everything (which is starved for time) it has not been released
<zyga> shuduo: I may re-start the COPR package with vendorized deps as that would help to unblock people
<zyga> shuduo: but I really need help with extra maintenance work as my main duties are as upstream developer
<shuduo> zyga: interesting I just tried 24 today and see snap works good.
<zyga> shuduo: it must be an older build
<zyga> shuduo: we are at snapd 2.23.1 now (2.24 will release today)
<zyga> shuduo: and 2.24 is good to release for fedora (like I built it for opensuse) but the extra golang deps are a blocker onw
<zyga> *now
<shuduo> zyga: it's 2.22.1 on fedora 24.
<zyga> hmmmm?
<zyga> that's super odd :)
<zyga> shuduo: where did you get your package again?
<zyga> shuduo: did you build it yourself?
<zyga> the CORP repo is unused for months
<shuduo> zyga: sorry i'm not familiar to dnf/copr since i did not use fedora quite long time. i am checking snapd status on other distro since it may help to some customer engagement
<zyga> shuduo: I try to document the current status on the snapd wiki here ...
<shuduo> zyga: i just follow the instructions of snapcraft.io
<zyga> https://github.com/snapcore/snapd/wiki/Distributions
 * zyga goes to add opensuse to supported list there
<zyga> (opensuse is supported since last week-ish)
<shuduo> then i find it from https://copr.fedorainfracloud.org/coprs/zyga/snapcore/
<zyga> shuduo: but that is snapd 2.14
<zyga> anyway
<zyga> I need to spend some time on Fedora support
<zyga> ideally after the 2.24 release tonight
<zyga> I could re-enable COPR easily with the vendorized deps
<zyga> (so same bits you get on ubuntu)
<zyga> and I could work towards packaging missing stuff
<zyga> shuduo: stick around; I can do this on Friday
<shuduo> zyga: i have customer ask if snap acn run with centos
<zyga> shuduo: do you need fedora or centos?
<zyga> shuduo: it can, though package is still far away
<zyga> https://new.zygoon.pl/post/case-study-snapd-on-centos/
<shuduo> zyga: i believe commercial customer need centos
<zyga> but you can build it from source to see
<zyga> shuduo: if you want to help on that I'll gladly welcome you on board :)
<zyga> shuduo: centos package could be built from COPR
<shuduo> zyga: great. i will try it.
<zyga> shuduo: with all vendorized bits it should not be hard (famous last words ;-)
<zyga> shuduo: but the issue is strictly on packaging, the code works fine
<shuduo> zyga: i would like to study how to do that first. :)
<zyga> shuduo: look at the blog post and stick around, I'm sure you can help
<shuduo> zyga: btw, seems debian is broken. https://bugs.launchpad.net/snapd/+bug/1672984.
<mup> Bug #1672984: can't install hello-world snap on debian <snapd:New> <https://launchpad.net/bugs/1672984>
<shuduo> zyga: yes, dnf info snapd show it's 2.14. sorry my wrong msg.
<zyga> shuduo: that's ok then, no mystery :)
<zyga> tyhicks: hey, could you do a review for us today?
<gbisson> hi all, when booting a board with TI WL127x chip on it I get the following "warning" at bootup: set_link_flags failed File "/usr/lib/python3/dist-packages/probert/network.py", line 454, in wlan_event self.rtlistener.set_link_flags(ifindex, IFF_UP) RuntimeError: rtnl_link_change failed -16
<gbisson> has anyone seen this? It seems that my interface is busy at the time of the request
<mup> PR snapd#3032 opened: cmd: rename all unit tests to $command/unit-test <Created by zyga> <https://github.com/snapcore/snapd/pull/3032>
<mup> PR snapd#3033 opened: cmd/libsnap: make mountinfo structures public <Created by zyga> <https://github.com/snapcore/snapd/pull/3033>
<zyga> gbisson: looks like kernel/driver issue
<gbisson> zyga: well the driver is working fine though, and the connection is working just fine after that message
<gbisson> zyga: the driver is pretty well supported in mainline: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/wireless/ti
<zyga> gbisson: "fine" may not be "correct" though, I'm not a kernel expert
<zyga> tyhicks: specifically this PR: https://github.com/snapcore/snapd/pull/3031
<mup> PR snapd#3031: cmd/snap-confine-suid-trampoline: add new helper <Created by zyga> <https://github.com/snapcore/snapd/pull/3031>
<gbisson> zyga: but I agree I don't see that warning on RPi, maybe someone else will try with TI someday, we'll see, thanks anyway
<mup> PR snapd#3034 opened: interfaces: log if the system goes into ForceDevMode <Created by mvo5> <https://github.com/snapcore/snapd/pull/3034>
<liuxg> mvo, currently, my application has the problem described in the bug, https://bugs.launchpad.net/snappy/+bug/1590679 in strict mode. However, I cannot find any missing apparmor policy output when I use snappy-debug
<mup> Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:Fix Released by jdstrand> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1590679>
<jacekn> hello. Where can I find some examples of "scriplets"? I'm interested in finding out how to use them with go plugin
<liuxg> jdstrand, ping
<mup> PR snapd#2979 closed: tests: add ubuntu-core-16-32 system to the external backend and fix docker test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2979>
<brunch875> guys I see that apt's python3-scipy version is 1.7 but pip3's version is 1.9. Will snaps solve these outdated issues?
<brunch875> and... how friendly is snappy with other managers?
<stub> snaps embed dependencies, and by default you will embed the latest version. Snaps don't conflict at all with other package managers, because they keep everything separate in /snap.
<gbisson> since today's udpate to stable core my system gets stuck at "Run configure hook of "core" snap if present" when looking at "snap change 1"
<gbisson> note that I couldn't do a "snap refresh" since it would get stuck. So I've created another image with latest core inside, and now the "Initialize system state" is stuck
<mvo> gbisson: hello, thanks for reporting that issue! do you still have access to the system that is stuck?
<mvo> gbisson: and you mention a fresh image is also stuck? what system is that? what version/architecture?
<gbisson> mvo: yes, here is our source code: https://github.com/boundarydevices/ubuntu-core
<gbisson> mvo: it is based on the roseapple tree but targets our (Boundary Devices) platforms which are i.MX processors based
<mvo> gbisson: aha, thank you! I was wondering how to reproduce this myself, but it looks like might be tricky :)
<mvo> gbisson: on the fresh system I assume you can not even get to a login/create-user screen ?
<gbisson> yes I can
<gbisson> mvo: as said above, I can ssh and look at snap change 1
<mvo> gbisson: aha, great!
<gbisson> mvo: this is where I've seen it got stuck at step
<mvo> gbisson: could you pastebin or mail /var/log/syslog  please?
<gbisson> mvo: sure, give me a minute or two
<mvo> gbisson: maybe we can get a clue from that data what is going on
<mvo> gbisson: no problem, take your time, I'm here for at least 3 more hours :)
<tyhicks> zyga: hey - I can have a look at that today
<tyhicks> zyga: I'll also have a look at 2624 today
<gbisson> mvo: here it is: http://pastebin.com/ubNsYu7A
<pedronis> tyhicks: we are trying to do without #3031 it seems, mvo is working on that
<mvo> gbisson: thanks, that is very interessting. it seems like http://paste.ubuntu.com/24182859/ might be crucial, two apparmor denials
<zyga> tyhicks: thanks
<mvo> gbisson: if you run scmp_sys_resolver 282 - what do you see on this system?
<zyga> tyhicks: we're looking at writing snap-update-ns in go to avoid putting more and more complexity in C
<mvo> pedronis, tyhicks: #3031 might still be needed, unfortuantely, I was looking into a static linked version of snap-confine but udev is not available as a static lib it seems
<gbisson> mvo: returns "bind"
<tyhicks> ok, I'll leave 3031 on the list of reviews to do today
<gbisson> mvo: what can I do to overcome that issue? what I really don't understand is how previous rev could work
<mvo> gbisson: thanks first of all for the syscall info
<mvo> gbisson: the previous rev was not using the configure hoook in the core snap, that is something new so there is an actual behaviour change here
<mvo> gbisson: but I'm confused why its a problem on your platform but not on our platforms :/ it should just work for you too
<gbisson> mvo: oh ok, thanks that explains the difference indeed
<gbisson> mvo: could it be that I'm missing a kernel configuration?
<gbisson> mvo: I'm using our regular Ubuntu defconfig
<mvo> gbisson: that should be ok then, also if normal snaps work then things with this new configure hook should also work. its the same class of confinement
<zyga> interesting error mvo, gbisson
<zyga> is this the configure hook on core?
<gbisson> mvo: I still have my working image available too if needs to make some comparison
<zyga> mvo: it must have network-bind, network plugs
<mvo> zyga: yeah, it looks like it
<zyga> mvo: otherwise no game (because golang design)
<gbisson> zyga: yes, the hook on core
<zyga> mvo: this is the issue I looked at months ago
<zyga> mvo: it's still reported somewhere on snapd
<mvo> zyga: core support does not have it
<zyga> mvo: golang probes for network support on startup (to see if it has ipv6)
<zyga> mvo: there we go, a simple workaround for 2.24 is needed
<mvo> zyga: the core snap only has "core-support" as the available plug
<mvo> zyga: ok, I can easily add this to the core snap
<zyga> I'll try to find the bug report now
<mvo> zyga: but *why* is this happening for gbisson and not on our test machines?
<gbisson> mvo: I agree, I have a RPi3 which I updated and it worked
<zyga> mvo: not sure
<gbisson> mvo: at first I blamed my own snaps (gadget and kernel) but it actually fails before even looking at those
<gbisson> mvo: which is why I suspect the kernel configuration (or the kernel revision)
<mvo> gbisson: this is arm32, right (armhf in ubuntu terms)?
<gbisson> mvo: RPi3 is based on 4.4 but I'm on 4.1
<gbisson> mvo: yes
<mvo> gbisson: the kernel version is an interessting data point
<zyga> I cannot find it now
<zyga> mvo: maybe (long shot) different syscalls on arm
<mvo> zyga: was thinking that too
<zyga> mvo: like i386/amd64 do totally different stuff for socket related calls
<mvo> zyga: its "bind" (seccomp) and "net_admin" (appamror) that is denied
<zyga> mvo: we had issues that only showed on one arch and not the other
<zyga> right
<zyga> why is net_admin needed?!?
<zyga> bind is golang for sure
<zyga> it really sucks that this magic happens
<mvo> maybe net_admin is also bind?
<zyga> and we cannot just say "don't"
<zyga> mvo: I doubt that
<zyga> feels like another golang query on startup
<zyga> gbisson: what hardware is this on?
<zyga> gbisson: and what kernel?
<mvo> gbisson: if you run "snap changes" coud you pastebin that as well please
<mvo> zyga: see above, he said this, one sec
<mvo> zyga: https://github.com/boundarydevices/ubuntu-core
<zyga> aha
<mvo> zyga: pretty cool, its a port to  Boundary Devices Nitrogen
<mvo> (whatever that is :)
<mvo> armhf based
<zyga> warp speed ahead!
<mvo> zyga: and kernel 4.1
<zyga> maybe a kernel bug/config/whatever
<gbisson> mvo: http://pastebin.com/HSmGYQtF
<zyga> not sure
 * zyga -> reboot
<mup> PR snapd#3035 opened: tests: fix interfaces-cups-control for zesty <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3035>
<mvo> gbisson: nice, thank oyu
<mvo> gbisson: I think there is at least one bug in our code, it should not hang in there, I assuem you don't have a configure process running in this system anymore (or do you)? the code should have noticed that the child died
<gbisson> mvo: still there: /bin/sh -e /snap/core/1443/meta/hooks/configure
<mvo> gbisson: ohhh
<gbisson> mvo: can I kill it?
<mvo> gbisson: can you strace that?
<gbisson> sure
<mvo> gbisson: please don't kill it :)
<mvo> gbisson: you will have to scp strace to the system first most likely
<gbisson> mvo: strace not found haha
<gbisson> mvo: oh ok
<gbisson> mvo: do you have one binary I could use by any chance? (for armhf)
<gbisson> mvo: I have a weird output: read(3,
<mvo> gbisson: lsof -p should tell you what fd this read is (adn you need to copy lsof again)
<gbisson> mvo: using procfs instead: 3 -> pipe:[12466]
<mvo> gbisson: I would like to add the network-bind to the plugs of the core snap to see if that fixes the issue for you. is that something you could do yourself ? by just snap download core, unsquafs, adding the plug and re-squash and ubild an image? if its too dificult I could add it to our edge snap and you would have to build an edge image
<gbisson> mvo: well yes I'd rather have you do that
<gbisson> mvo: I've never messed with snap manually before
<mvo> gbisson: :) no problem, I'm super happy about a test case for this issue, we had some anecdotal reports but never someone who could reproduce it
<mvo> gbisson: let me create that and I will ping me
<gbisson> ok
<mup> PR snapd#3015 closed: interfaces: alphabetize framebuffer in base decl and add it to all_test.go <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3015>
<mvo> gbisson: I added the plug and triggered a new build, there should be a new core snap in "edge" in ~30min or so, I can ping you once its there. I assume building with a core from edge is no problem? curious to see/hear if the result is different with that :)
<gbisson> mvo: sure, please ping me when it's ready and then I'll need 5minutes to create and flash a new image
<gbisson> mvo: thanks!
<zyga> gbisson: hey
<zyga> gbisson: can you please pastebin /var/lib/snapd/seccomp/profiles/snap.core.hook.configure
<gbisson> zyga: sure, give me a few minutes to reboot the board
<zyga> gbisson: thank you
<zyga> gbisson: and can you please do one more thing once the board is up
<zyga> though not sure how yet,
<zyga> one sec
<gbisson> zyga: there: http://pastebin.com/PD5hYd7p
<gbisson> sure, it stays up now
<zyga> checking!
<zyga> gbisson: tip, pastebin.ubuntu.com == no ads
<mvo> with noscript and umatrix also no adds :)
<mvo> ads
<gbisson> zyga: pastebin.ubuntu.com = one more word to type ;) I'll try it next time
<zyga> gbisson: ok, you need strace for armhf
<gbisson> I have strace for armhf
<zyga> gbisson: there's a .conf file you can use
<zyga> gbisson: ok, run strace -o log /snap/core/current/usr/bin/snapctl
<zyga> gbisson: and pastebin that
<gbisson> zyga: I took strace from our Ubuntu xenial release
<zyga> that's good
<zyga> gbisson: I use the classic snap (sudo snap install classic; sudo classic) to get apt-get and then install/copy strace to ~
<zyga> but it's the same thing you got
<gbisson> error: snapctl cannot run without args
<zyga> that's fine
<zyga> we care about what it does earlier
<zyga> (it did some things that it chokes on under confinement)(
<zyga> (it did some things that it chokes on under confinement)
<zyga> can you pastebin the log now?
<gbisson> zyga: http://pastebin.ubuntu.com/24183212/
<zyga> bind(4, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
<zyga> so far so good
<zyga> ok, one more sec and one more test
<zyga> gbisson: can you now run: SNAP_NAME=core /usr/lib/snapd/snap-confine snap.core.hook.configure /snap/core/current/usr/bin/snapctl
<zyga> gbisson: this is a smoke test, it should crash
<gbisson> zyga: should I sudo? doesn't seem to do much
<zyga> gbisson: no
<zyga> gbisson: no sudo, just as is
<zyga> gbisson: what happens when you ran that?
<gbisson> zyga: nothing
<zyga> did it crash?
<zyga> anything in journal?
<gbisson> zyga: it doesn't return so far but no trace whatsoever
<gbisson> zyga: the journal gives the same SECCOMP denial as before
<gbisson> zyga: which makes sense I guess
<mvo> and its hanging? so the same symtpoms as before
<elopio> didrocks: do you know how to add an event to the Ubuntu facebook page?
<gbisson> mvo: yes, but it's normal I haven't changed the image yet, is the edge core ready yet?
<zyga> gbisson: perfect
<mvo> gbisson: not quite but close
<zyga> gbisson: kill it (remains)
<zyga> mvo: one of the thread gets killed
<zyga> mvo: and go doesn't recover
<zyga> mvo: I have a theory, just making a simple case to try
<mvo> zyga: oh, that makes sense
<didrocks> elopio: I don't, but you should talk to amrisha, she owns the facebook page
<zyga> gbisson: ok, ready
<zyga> gbisson: a few things you need to do:
<zyga> gbisson: go to /var/lib/snapd/ then in {apparmor,seccomp}/profiles/snap.core.hook.configure you need to make two changes:
<zyga> gbisson: look at http://pastebin.ubuntu.com/24183261/
<zyga> gbisson: in the seccomp profile you need to add "ptrace" and "process_vm_readv" (on separate lines, without quotes)
<mup> PR snapd#3036 opened: tests: fix classic-ubuntu-core-transition race <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3036>
<zyga> gbisson: in apparmor profile you need to add, before the final closing brace, "/writable/strace ixr," (the trailing comma is relevant)
<zyga> gbisson: and then "ptrace,"
<zyga> gbisson: then copy strace to /writable "sudo cp strace /writable" (wherever you had strace)
<zyga> gbisson: and reload apparmor profile with "sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.core.hook.configure"
<zyga> gbisson: this should set the stage to the real test:
<zyga> SNAP_NAME=core sudo -E /usr/lib/snapd/snap-confine snap.core.hook.configure /writable/strace /snap/core/current/usr/bin/snapctl
<zyga> gbisson: this should give us at least partial log of the thing crashing
<zyga> mvo: ^^
<zyga> gbisson: gbisson (sorry add -f after strace)
<zyga> SNAP_NAME=core sudo -E /usr/lib/snapd/snap-confine snap.core.hook.configure /writable/strace -f /snap/core/current/usr/bin/snapctl
<zyga> gbisson: don't redirect this anywhere as it will change the test
<zyga> gbisson: once we have some data we can tweak the profile on your disk to pass
<mvo> zyga: the new core snap is available
<zyga> gbisson: and figure out why this is happening
<zyga> gbisson: before you update, please finish this test
<zyga> mvo: thanks!
<gbisson> zyga: http://pastebin.ubuntu.com/24183281/
<gbisson> zyga: the first part is the journal
<gbisson> zyga: below is the command output as-is
<mvo> zyga: so once you are ready gbisson can create a new image. or do you have a new theory already (sorry have not read all of the scrollback yet)
<zyga> re
<zyga> looking at logs
<zyga> gbisson: can you append "bind" without quotes to the end of /var/lib/snapd/seccomp/profiles/snap.core.hook.configure
<zyga> gbisson: and re-run the test
<zyga> gbisson: (we should be ready to try mvo's idea next)
<zyga> hmm, curious
<zyga> mvo: so ...
<zyga> this is different:
<zyga> in my run I see:socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = -1 EACCES (Permission denied)
<zyga> socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = -1 EACCES (Permission denied)
<zyga> so nothing happens next (no bind)
<zyga> but in gbisson's run I see:
<zyga> [pid  1720] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
<zyga> [pid  1720] close(3)                    = 0
<zyga> so my run doens't reach bind
<zyga> it fails on socket
<zyga> but there (somehow) socket passes
<zyga> no idea why
<zyga> gbisson: maybe your kernel doesn't have the full apparmor patchset, are you actively pulling new changes from the apparmor directory in the ubuntu kernel?
<gbisson> zyga: no, definitely not, it is based on 4.1.15 with no particular apparmor backport
<zyga> gbisson: ah
<zyga> gbisson: then you should not expect this to work much
<zyga> mvo: ^
<mvo> zyga: well, maybe
<zyga> gbisson: snapd really requires a particular version of apparmor
<mvo> zyga: we have forced-devmode now based on apparmor
<zyga> gbisson: sadly the one that is not upstream yet
<mvo> zyga: but then, snap-confine is not ready for this yet :/
<zyga> mvo: I'm super curious to see if it gets picked up
<zyga> mvo: how can I check if a given system is devmode?
<zyga> mvo: IMO we should print a note (each time) "snap list" is used in devmode distro
<mvo> zyga: there is a PR for this ;)
<zyga> "This system does not offer effective confinement. Running untrusted applications can put your systemd and data at risk"
<zyga> mvo: devmode is just too dangerous
<zyga> (silent devmode)
<mvo> zyga: agreed
 * zyga typed "systemd" instead of system
<zyga> eh :)
<mvo> zyga: so once gbisson refreshes to the new version syslog should have somthing like "started snapd/2.23 (series 16,devmode)"
<zyga> gbisson: so my recommendation, port the apparmor tree and the problem goes away
<gbisson> zyga: will try that, is the latest linux-stable ok or should another tree be used?
<gbisson> zyga: well there's no change on apparmor with latest 4.1 stable anyway
<mvo> gbisson: I'm curious what will happen if you switch to an image from edge
<mup> PR snapd#3037 opened: interfaces: dbus backend spec <Created by stolowski> <https://github.com/snapcore/snapd/pull/3037>
<mvo> gbisson: if it is apparmor missing (what zyga suggested) then this version will be a step forward but it will still not fully work, we will need to fix snap-confine for this too which is planned but not quite there yet
<gbisson> mvo: ok, so I should still try that edge image?
<zyga> gbisson: unfortunately no
<zyga> gbisson: you need ubuntu-specific patches that are not upstream yet
<zyga> gbisson: those can be found on the kernel.ubuntu.com
<gbisson> zyga: so what you are telling is that no-one can create its own OS image right now
<zyga> gbisson: not sure if this is hard to port, apparmor is self-contained but maybe some patches span subsystems
<zyga> gbisson: not with confinement on stock kernel
<zyga> gbisson: each sponsored kernel from canonical has apparmor ported
<zyga> gbisson: and we're merging this upstream but it's a queue
<gbisson> zyga: and what happens if I change the confinement to devmode?
<zyga> gbisson: old stuff gets merged but more bugfixes and features are added
<zyga> gbisson: no confinement
<zyga> gbisson: it switches off entirely (see mvo's update)
<zyga> gbisson: while more fixes and features land upstream it may be 4.13 where our current patches are zero
<zyga> gbisson: but I cannot promise that we don't have more after
<zyga> gbisson: apparmor is pushed by many things we're doing
<zyga> gbisson: and more exposure shows more bugs that we fix (the latest set that landed in 4.11 was mostly just bugfixes)
<gbisson> zyga: ok but the problem is that my kernel is common across OSes so far (Ubuntu, Debian, Yocto, Buildroot) and don't want to backport things from 4.13 is I risk to break anything
<zyga> gbisson: you don't need to backport from 4.13
<zyga> gbisson: but you need to backport security fixes from ubuntu's apparmor tree to get effective confinement
<zyga> gbisson: earlier we had a few kernels published where this was done (for common kernel versions)
<zyga> gbisson: but I don't know if those are supported and maintained
<gbisson> zyga: can you point me to the specific tree?
<zyga> gbisson: which version are you on now?
<gbisson> zyga: 4.1
<zyga> thanks
<zyga> https://github.com/snapcore/sample-kernels/branches
<zyga> gbisson: I can get you in touch with someone commercial at Canonical if you'd like to get backported security patches for 4.1
<zyga> gbisson: but looking at those they feel unmaintained (more like a one off that was done earlier)
<zyga> gbisson: you can also review http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/ for UBUNTU SAUCE matching apparmor
<zyga> all such patches are really desired
<zyga> gbisson: e.g. http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/?qt=grep&q=apparmor
<mvo> gbisson: I will be off for some minutes, if you have a chance to boot a fresh edge core based image, I'm keen to see the results :)
<mvo> gbisson: i.e. I will read backlog
<zyga> gbisson: I'm off to, kids home, need to attend stuff
<gbisson> zyga: thanks for your help! I'll look at the apparmor patches
<gbisson> mvo: but will I need the apparmor patches anyway?
<mup> PR snapcraft#1195 opened: [experimental] run unit tests in osx <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1195>
<gbisson> mvo: cause if I do I'm not sure I want to spend much time on this
<zyga> gbisson: (quick look) it depends on what you are after
<zyga> gbisson: if you are are after a quick demo you don't need much
<zyga> gbisson: if you want a real product that is supported you need to patch security issues
<zyga> gbisson: there's nothing in between
<gbisson> zyga: we usually give OS images freely available for all our platforms on our website (https://boundarydevices.com/wiki/operating-systems/) so our customers can pick the one they want
<gbisson> zyga: but here the problem is that if I give an image where if the customer does a "snap refresh" it breaks I'm not sure I want them to experience that
<zyga> gbisson: that is a bug and that will get fixed (in current master you will be in devmode and won't use apparmor)
<zyga> gbisson: seccomp probably won't be used either
<zyga> gbisson: but this will not be the best way to experience snapd as it will be insecure
<zyga> gbisson: so my only point was that to really say you support snaps you should support security features of your kernel
<gbisson> zyga: I'm fine if I can be in devmode for this "demo" image, all I want is customers being able to snap install etc..
<gbisson> mvo: I get an error when logging in:  error: while creating user: cannot communicate with server: Post
<gbisson> http://localhost/v2/create-user: EOF
<elopio> thanks didrocks
<mup> PR snapd#3024 closed: interfaces: use apparmor spec in the apparmor backend <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3024>
<mup> PR snapd#3036 closed: tests: fix classic-ubuntu-core-transition race <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3036>
<mvo> gbisson: uh, so the edge image is clearly worse :/
<mup> PR snapd#3034 closed: interfaces: log if the system goes into ForceDevMode <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3034>
<mup> PR snapd#3023 closed: cmd: validate SNAP_NAME <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3023>
<mup> PR snapd#3038 opened: misc: revert "Log if the system goes into ForceDevMode" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3038>
<gbisson> mvo: I'm curious where is the RPi3 kernel tree for the image you provide?
<mup> PR snapcraft#1175 closed: demo files for snaping the bitcoin-qt client <Created by torusJKL> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1175>
<zyga> tyhicks: hey
<zyga> tyhicks: did you have a chance to review 2624?
<tyhicks> zyga: yeah - I'm testing the apparmor rule
<zyga> thanks
<zyga> tyhicks: release night so if you want to block it please hurry up ;-)
<tyhicks> ah, didn't realize
<tyhicks> zyga: do I need to review 3031 immediately, too?
<zyga> tyhicks: I think we rejected that already because udev cannot be linked statically so we cannot use it
<zyga> tyhicks: please review 2624 first if you cna
<zyga> can*
<tyhicks> zyga: done
<tyhicks> zyga: I don't guess I'll review 3031 unless I hear that it is still needed
<mup> PR snapd#3028 closed: interfaces: seccomp tests cleanup <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3028>
<mup> PR snapd#3038 closed: misc: revert "Log if the system goes into ForceDevMode" <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3038>
<mup> PR snapd#3035 closed: tests: fix interfaces-cups-control for zesty <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3035>
<zyga> tyhicks: thank you!
<zyga> tyhicks: I made the profile tighter as suggested; both rules
<zyga> tyhicks: with two +1's I'll merge it once it shows up all green
 * zyga waves goodbye
<zyga> see you tomorrow
<tyhicks> zyga: np - have a good one
<liuxg> jdstrand, ping
<torusJKL> I have created a snap of a QT program.
<torusJKL> When I run it using the desktop link the GUI looks really bad.
<torusJKL> If I run it directly from /snap/myApp/current/bin/ then it looks nice and integrated into my system.
<torusJKL> What am I missing here?
<torusJKL> Here is my snapcraft.yaml file: https://github.com/torusJKL/snapcraft-projects/blob/master/bitcoin-qt/snapcraft.yaml
<torusJKL> It looks to me like the following: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1584357
<torusJKL> I'm using the part desktop-qt5 but how do I add the gtk3 dependencies (e.g. "canberra-gtk-module")?
#snappy 2017-03-16
<zyga_> tyhicks: hey, so I had to revert the "capability sys_ptrace" removal
<zyga> tyhicks: if you could have a look at the rationale I posted in     Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
<zyga> 7373ee8938cebb82c88f5925d448b290d18a7122
<zyga> tyhicks: it seems to fail if you're not root when starting snap-confine
<cwayne> zyga: did a new snapd with that fix land in candidate?
<zyga> tyhicks: https://github.com/snapcore/snapd/pull/2624/commits/7373ee8938cebb82c88f5925d448b290d18a7122
<mup> PR snapd#2624: cmd/snap-confine: re-associate with pid-1 mount namespace if required <Blocked> <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>
<zyga> tyhicks: we didn't release last night; we plan to relase early today
<zyga> er
<zyga> cwayne: ^
<zyga> cwayne: candidate will be made after mvo investigates a packaging error we ran into
<mvo> cwayne: what fix in particular?
<cwayne> mvo: snap-confine bug about namespaces
<mup> PR snapd#3033 closed: cmd/libsnap: make mountinfo structures public <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3033>
<mup> PR snapd#3031 closed: cmd/snap-confine-suid-trampoline: add new helper <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3031>
<mup> PR snapd#2990 closed: cmd: link libcap dynamically <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2990>
<Son_Goku> zyga: I'd really like to have gnome-software have snappy support in Fedora for F26
<Son_Goku> so we need to get snapd going into the archive, since someone rewrote the snappy plugin to require snapd-glib
<Son_Goku> and snapd-glib won't install without snapd
<zyga> Son_Goku: will you review a hand-made spec for the two deps?
<Son_Goku> I can
<Son_Goku> did you also file a bug about gofed's problems with gopkg.in?
<zyga> no, I should really do that
<zyga> may be easier than patching
<Son_Goku> well... yes
<zyga> actually
<zyga> https://github.com/gofed/gofed/issues/75
<zyga> it's there for two years
<zyga> so...
<Son_Goku> now bug them to say they broke things without it :)
<zyga> Son_Goku: them == upstrem gofed?
<Son_Goku> yes
<Son_Goku> if it helps, you can file a bug in rhbz against gofed about it :)
<Son_Goku> they might pay attention there
<mup> Bug #1673435 opened: /lib/systemd/system-sleep/ is read-only <Snappy:New> <https://launchpad.net/bugs/1673435>
<Son_Goku> zyga: http://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=gofed&version=25
<mup> PR snapd#3039 opened: many: add support for partially static builds <Created by zyga> <https://github.com/snapcore/snapd/pull/3039>
<mup> PR snapd#3040 opened: cmd: enable large file support <Created by drizzt> <https://github.com/snapcore/snapd/pull/3040>
<mup> Bug #1673465 opened: Cannot set a timezone on dragonboard core system <Snappy:New> <https://launchpad.net/bugs/1673465>
<mup> Bug #1672472 changed: Date and time reports the wrong timezone <snapweb:Fix Released by justinmcp> <https://launchpad.net/bugs/1672472>
<mup> Bug #1673465 changed: Cannot set a timezone on dragonboard core system <Snappy:New> <https://launchpad.net/bugs/1673465>
<tyhicks> zyga: thanks for checking into that - I'm fine with leaving the rule in
<mup> PR snapcraft#1196 opened: store: enable delta uploads by default when pushing <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1196>
<zyga> tyhicks: OK, thanks for confirming
<cachio> tyhicks, any chance to see the dbus tests?
<cachio> tyhicks, currently I have the spammer and the handler in the same snap, could it affect the resutls? should I split in different snpas?
<Cynerva> How do I add auto aliases to a snap?
<Cynerva> i.e. remove the need to `snap alias my-snap my-alias`
<tyhicks> cachio: no, sorry but I'm still trying to climb out from under work that cropped up last week
<Cynerva> I've seen references to this but I'm having trouble figuring out what enables that
<tyhicks> cachio: I don't think it'll affect the performance since both ends will still be confined
<cachio> tyhicks, yes
<tyhicks> cachio: I think I mentioned it last week but when we originally benchmarked the dbus mediation performance, the typical case was a confined client and an unconfined service which resulted in a max of ~10% overhead when generating a lot of traffic
<cachio> tyhicks, yes
<mup> PR snapd#3041 opened: cmd/snap: handle missing snap-confine <Created by chipaca> <https://github.com/snapcore/snapd/pull/3041>
<cachio> last execution I got 32% of overhead
<cachio> but most of the them are around the 40%
<cachio> tyhicks, the metrics are at the end of this graphic https://platform-qa-dashboard.canonical.com/dashboard/db/kpi-zesty-dashboard
<cachio> tyhicks, User: perf pass: ubuntuPERF
<tyhicks> cachio: is it safe to publicize those credentials?
<qengho> Hah.
<tyhicks> cachio: I thought you reported a 15% overhead last week?
<tyhicks> (with some blips up to around 40%)
<cachio> tyhicks, no
<cachio> tyhicks, all the overheads that I saw but client and service confined are more than 30%
<cachio> tyhicks, in the graphics you can see the messages by second fof the execution in confinment and without confinment
<cachio> those results are for zesty and the execution is in real hardware
<cachio> tyhicks, the tests for those graphics are sending 20K messages with a paylod of 256 bytes
<mup> PR snapd#3042 opened: cmd: discard the C implementation of snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3042>
<tyhicks> cachio: you just publicized the credentials (this is a public channel)
<cachio> tyhicks, firgit ut
<cachio> fforgot it
<cachio> tyhicks, but it is a read only user
<cachio> and the dashboar is public
<Rumple> Anyone have any idea how long 'manual review' takes when publishing to the snap store?
<oky> Rumple: one hour
<Rumple> oky: I have had a snap with 'Manual review pending' for over a week
<cachio> tyhicks, I'll change the password just in case
<oky> Rumple: ok, i'm sorry! i don't know - good idea to come here and get help
<Rumple> oky: thanks for the guess at least
<cachio_lunch> tyhicks, change done
<cachio_lunch> tyhicks, ping me if could take a look to those results please
<morphis> alecu: you talked with koza about your bluez problems on your pi3?
<tyhicks> cachio_lunch: I've looked at the results but what I haven't yet had time for is to reproduce the results locally and begin poking at test and the dbus-daemon code
<alecu> morphis: no... was expecting some pong here.
<alecu> morphis: should I report a bug somewhere?
<morphis> alecu: ok, koza ^^ alecu has problems getting the bluez snap to work on a pi3
<morphis> alecu: let koza reply here first, then we can if we need a bug
<koza> alecu, hey
<alecu> hi koza!
<koza> alecu, what is going on?
<koza> alecy, just fyi we have sprint planning so I will be slow on re for a while but feel free to describe the problem
<koza> alecu, ^^
<alecu> koza: I'm using ubuntu core on a raspi3, and would like to use a bluetooth keyboard with it
<trapchat> IS THIS THE NEW PPA?
<alecu> koza: so, I've installed the bluez snap, and I'm trying to follow the steps here: https://docs.ubuntu.com/core/en/stacks/bluetooth/doc/overview
<alecu> koza: but, bluetoothctl never prints the line that would read something like: "[NEW] Controller 1C:C3:E4:79:43:4C localhost.localdomain [default]"
<alecu> koza: so, I guess there must be a missing driver, or something like that?
<koza> alecu, what if you type: power on just after the bluetoothctl is started
<alecu> koza: I can't type a thing there :-/
<alecu> koza: can't see anything I type
<alecu> I'll give it a try anyway
<koza> alecu, how come? how do you start bluetoothctl then?
<alecu> koza: (sorry, on a meeting too)
<cachio> tyhicks, ok
<mup> PR snapd#2624 closed: 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>
<koza> alecu, I do not see bt controler on my pi either. I have all the time used a usb dongle plugged in to the pi. with that keyboards do work. i will try to figure out why the bt is not there
<alecu> koza: ah, good to know
<alecu> koza: perhaps it's a missing kernel compile option in the pi3. We should also ask ogra_
<koza> ogra_, ^^^^
<om26er> Hi! What could cause: - Fetch and check assertions for snap "core" (35) (internal error: circular assertions are not expected: account (canonical)) ?
<om26er> Note: my snapd is pointing to staging.
<pedronis> om26er: wrong snapd or wrong setup
<didrocks> pedronis: hey, speaking of which, is there any way to tell snapd to forget about one snap assertion? (removing a snap doesn't remove the assertions)
<pedronis> didrocks: no, they are facts, they don't become wrong (we might gc them at some point)
<om26er> pedronis: I have snapd 2.22.5 with testkeys, while 2.22.6 is available. Could that be the reason or did I screw something in my build ?
<didrocks> pedronis: yeah, I'm trying to illustrate the assertions in a tutorial, but if people already installed the snap in the store, I can't have them to then download the snap and try to install it without acking the assertion first
<didrocks> pedronis: I would have thought that removing the snap would GC the corresponding assertions for that rev
<pedronis> as I said we might to do at some point, but it would be an optimisation
<didrocks> yeah, sounds unwanted to keep piling up cruft
<pedronis> om26er: what does  snap known account-key authority-id=canonical reports,  mostly interested what is in name: of those keys
<pedronis> didrocks: thank you
<didrocks> pedronis: want a bug for this?
<om26er> pedronis: returns nothing
<pedronis> om26er: you sure, that's weird in different ways
<pedronis> didrocks: if you want, unlikely to get high priority for a while
<om26er> pedronis: yep.
<didrocks> pedronis: yeah, still good to log it, will do, thanks!
<pedronis> om26er: a couple come from inside snapd itself, that's why I'm perplexed
<pedronis> om26er: "snap known account-key authority-id=canonical" is what I'm typing here
<mup> PR snapd#3043 opened: interfaces: use spec in the dbus backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/3043>
<om26er> pedronis: right, that's the command, I ran. OTH, here is mostly how I built snapd in my ppa: http://paste.ubuntu.com/24046002/
<pedronis> om26er: not sure, I'm quite confused tbh
<pedronis> there should be at least one key listed by that command
<pedronis> even for a snap/snapd that have done nothing
<mup> Bug #1673539 opened: snapd doesn't clean up imported (snap) assertions <Snappy:New> <https://launchpad.net/bugs/1673539>
<mup> PR snapd#3041 closed: cmd/snap: handle missing snap-confine <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3041>
<om26er> pedronis: figured that out, it was a mistake on my end, I had broken debian/rules file
<pedronis> om26er: ah, ok
<om26er> pedronis: I have another issue though.
<om26er> pedronis: - Download snap "core" (35) from channel "stable" (read tcp 10.162.50.23:47680->69.88.149.140:443: read: connection reset by peer)
<om26er> pedronis: this happens when I try to install a snap in my digitalocean droplet.
<om26er> the issue does not happen on my local machine.
<pedronis> seems some networking issue
<om26er> pedronis: fwiw snap download works fine
<pedronis> even stranger, but not sure what is happening
<om26er> :/
<pedronis> they use the same code more or less
<om26er> actually snap download also has the same issue. (sometimes it works other don't)
<om26er> atleast I am not alone, bug 1617765
<mup> Bug #1617765: Connections reset when downloading snaps from CDN <Software Center Agent:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1617765>
<mup> PR snapd#3044 opened: snapstate: more helpers to work with alias states (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3044>
<datajerk> anybody else hear having problems with autoupdate (16.04) removing snapd?  happened to all of my cloud-based servers last night. thanks.
<qengho> datajerk: Eh? What does your /var/log/apt/ log say?
<datajerk> from my logs: Remove: snapd:amd64 (2.22.6)
<datajerk> Commandline: /usr/bin/apt-get -o quiet=1 dist-upgrade -q -y -o APT::Get::Show-Upgraded=true -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/security.sources.list -o DPkg::Options::=--force-confdef -o DPkg::Options::=--force-confold
<qengho> datajerk: And "apt install snapd" didn't warn of conflict with something you have installed?
<datajerk> nope, no conflict warning
<qengho> Weeeeeird.
<qengho> datajerk: Pastebin "apt policy snapd" ?
<datajerk> http://pastebin.com/v1NGbfAh
<qengho> datajerk: Paste the entire log stanza, too, from /var/log/apt/history.log ?
<datajerk> http://termbin.com/fr3z
<qengho> zyga: ^back 10 min.
<zyga> gouchi: hmm?
<zyga> not sure if related but snapd hit a bug in dpkg
<zyga> dpkg was fixed and tomorrow we will issue an update that pre-depends on the updated dpkg
<gouchi> zyga: ??
<zyga> qengho: hmm
<zyga> gouchi: sorry, I'm tired and misread notification
<gouchi> zyga: np
<zyga> datajerk: thank you, we are looking into this
<datajerk> zyga qengho thanks
<barry> does snap and/or snapcraft not support the snapcraft.yaml `environment` section in xenial and yakkety?
<mup> PR snapcraft#1197 opened: tests: increase the timeout in the shared ros test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1197>
#snappy 2017-03-17
<sergiusens> barry: snapcraft does, but there's a snapd bug going around which breaks it (introduces a rogue \n and doesn't expand variables in the value of the envvar)
<mup> PR snapcraft#1196 closed: store: enable delta uploads by default when pushing <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1196>
<mup> PR snapcraft#1198 opened: tests: add manual tests for the kernel snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1198>
<mup> PR snapd#2855 closed: interfaces/builtin: add intel realsense udev rules into camera interface <Created by swem> <Closed by swem> <https://github.com/snapcore/snapd/pull/2855>
<mup> PR snapd#3045 opened: Adds hw-random interface <Created by femdom> <https://github.com/snapcore/snapd/pull/3045>
<mup> PR snapd#3046 opened: many: release/2.23 <Created by zyga> <https://github.com/snapcore/snapd/pull/3046>
<koza> ogra_, ping
<zyga> koza: I think ogra is at a conference
<koza> zyga, thanks
<mup> PR snapd#3047 opened: tests: adjust network-bind test <Created by zyga> <https://github.com/snapcore/snapd/pull/3047>
<mup> PR snapd#3048 opened: interfaces: add media-hub interface <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3048>
<mup> PR snapd#3042 closed: cmd: discard the C implementation of snap-update-ns <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3042>
<mup> PR snapd#3049 opened: interfaces: allow writing config.txt.tmp  in the core-support interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/3049>
<Son_Goku> zyga, you just hate me, don't you?
<Son_Goku> turning more of this stuff into golang?!
<mup> PR snapd#3040 closed: cmd: enable large file support <Created by drizzt> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3040>
<zyga> Son_Goku: hey
<zyga> Son_Goku: yeah, the complexity just grows and grows
<zyga> Son_Goku: so we decided to give golang a try
<Son_Goku> :(
<mup> PR snapd#3050 opened: interfaces/mount: WIP towards computing mount changes for snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3050>
<mup> PR snapd#3021 closed: asserts: introduce a snap-declaration "aliases" header to list auto aliases with explicit targets <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3021>
<zyga> Son_Goku: with this move we may be able to reuse some code from opencontainers
<Son_Goku> it's not like you'll be able to use OCI format images like mattdm was asking about a while ago
<zyga> no, we're not doing containers
<zyga> but we are using some of the same kernel features
<mup> PR snapd#3051 opened: interfaces: add consoles interface <Created by femdom> <https://github.com/snapcore/snapd/pull/3051>
<mup> PR snapd#3037 closed: interfaces: dbus backend spec <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3037>
<mup> PR snapd#3052 opened: overlord: remove snap config values when snap is removed <Created by stolowski> <https://github.com/snapcore/snapd/pull/3052>
<mup> PR snapd#3047 closed: tests: adjust network-bind test <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3047>
<mup> PR snapd#3053 opened: asserts: don't allow revocations with other items for the same developer <Created by emgee> <https://github.com/snapcore/snapd/pull/3053>
<mup> PR snapd#3054 opened: many: rename "snap-confine" to "snap-wrap" to workaround LP:1673247 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3054>
<mup> Bug #1673757 opened: On empty aliases response <Snappy:New> <https://launchpad.net/bugs/1673757>
<facubatista> hi! is there a snap command to actually know if I'm logged in?
<mup> Bug #1673763 opened: Help for 'version' <Snappy:New> <https://launchpad.net/bugs/1673763>
<zyga> facubatista: I think not
<mup> PR snapd#3055 opened: cmd/snap: fix help string for version command <Created by zyga> <https://github.com/snapcore/snapd/pull/3055>
<mup> PR snapcraft#1192 closed: repo: refactor into a package <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1192>
<facubatista> zyga, thanks (for the response here and for the help for version)
<mup> PR snapd#3056 opened: overlord: when shutting down assume errors might be due to cancellation so retry <Created by pedronis> <https://github.com/snapcore/snapd/pull/3056>
<mup> PR snapd#3057 opened: systemd: mount the squashfs with nodev <Created by mvo5> <https://github.com/snapcore/snapd/pull/3057>
<micah> hello, i'm on debian (unstable), i tried to install a snap for the first time, but I've been at this stage for over 2 hours now: [/] Run configure hook of "core" snap if present
<mup> PR snapd#2230 closed: interfaces: add an interface that allows clients to use media-hub over dbus <Created by jhodapp> <Closed by jhodapp> <https://github.com/snapcore/snapd/pull/2230>
<mup> PR snapd#3058 opened: tests: skip lp-1644439 test on older kernels <Created by zyga> <https://github.com/snapcore/snapd/pull/3058>
<zyga> micah: hey, I think we ran into some issues and we're trying to unbreak that
<zyga> mvo: ^^
<zyga> micah: can you run "snap changes"
<zyga> micah: and then "snap change 111" where 111 is the number of the change you see?
<mvo> zyga: ta
<mup> PR snapcraft#1199 opened: cleanbuild: packaging independent detection <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1199>
<mup> PR snapd#3049 closed: interfaces: allow writing config.txt.tmp  in the core-support interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3049>
<micah> zyga: sure
<micah> zyga: https://share.riseup.net/#GyxpEZu7_63AFkT1whpwBA
<micah> sorry, wrong one
<micah> zyga: https://share.riseup.net/#0-F0_9DbtPI1AR7blXw17A
<om26er> Hi! I am trying to build snapd to enable staging. Should this change be enough to achieve that ? http://paste.ubuntu.com/24195818/
<om26er> apparently when I push snapd to my ppa with above change applied, staging does not get enabled and I am not sure what to do. Note: I do export SNAPPY_USE_STAGING_STORE=1 in /etc/environment
<om26er> `snap known account-key authority-id=canonical` returns empty
<om26er> launchpad build logs here https://launchpad.net/~om26er/+archive/ubuntu/snapd-candidate/+build/12139026
<zyga> micah: message taken; we're going to figure out what to do about it and fix debian
<om26er> hmmm, seems launchpad is exporting DEB_BUILD_OPTIONS=noautodbgsym parallel=4 in the environment -- could that be eating my export ?
<mup> PR snapd#3030 closed: assertstate,snapstate: have assertstate.AutoAliases use the "aliases" header (aliases v2) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3030>
<mup> PR snapd#3059 opened: Fix retries on ubuntu-core-reboot for Pi 2/3 <Created by vrruiz> <https://github.com/snapcore/snapd/pull/3059>
<mup> PR snapd#3060 opened: interfaces: allow "sync" to be used by core support <Created by mvo5> <https://github.com/snapcore/snapd/pull/3060>
<mup> PR snapd#3060 closed: interfaces: allow "sync" to be used by core support <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3060>
<coreycb> sergiusens, hi, do you think this will get a fix soon?  https://bugs.launchpad.net/snappy/+bug/1670852
<mup> Bug #1670852: python console_scripts not installed into /snap/<snap>/current/bin <openstack> <Snappy:New> <https://launchpad.net/bugs/1670852>
<sergiusens> coreycb: was going to work on it MOnday
<sergiusens> coreycb: but now I see why I couldn't find it anymore, let me change the bucket
<coreycb> sergiusens, oh cool
<coreycb> sergiusens, thanks for prioritizing it
<mup> Bug #1670852 changed: python console_scripts not installed into /snap/<snap>/current/bin <openstack> <Snapcraft:New> <https://launchpad.net/bugs/1670852>
<sergiusens> coreycb: so far I have 3 similar bugs and need to see if they are all the same... I hope they are different to be able to harden the feature with a bunch on integration tests (the python plugin must be the plugin with most fixtures today already)
<sergiusens> I can believe we still have gaps!
<coreycb> sergiusens, ok let me know if you want me to give anything a spin before it gets merged
<mcphail> Is there any way to trigger an email when a snap updates?
<mcphail> kyrofa: is there any way for the nextcloud snap to notify me when it updates so I can log in to reenable the apps?
<cachio> niemeyer, hey, I have seen this error running kpi tests in dragonboard
<cachio> http://paste.ubuntu.com/24197137/
<cachio> niemeyer, I install / remove a snap many times and at some point i start seen this
<cachio> niemeyer, any idea, could be a bug?
<cachio> jdstrand, any idea about what I have shown?
<mup> PR snapd#3059 closed: Fix retries on ubuntu-core-reboot for Pi 2/3 <Created by vrruiz> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3059>
<pedronis> cachio: well it means you have a ubuntu-core which is not expected, especially on a board? what are you running on that board?
<cachio> pedronis, I run some tests which get the time off the app call
<cachio> pedronis, those tests are always making sure the app is just installed before its execution
<pedronis> cachio: my question is more which version of ubuntu/snapd ?
<pedronis> that error is because snapd is trying to move away from ubuntu-core to core
<pedronis> but IÂ wouldn't expect ubuntu-core on anything but an oldish classic system
<cachio> pedronis, I think it is getting the last from edge
<pedronis> cachio: is it a core system?Â or classic?
<cachio> pedronis, core
<pedronis> might it's in a broken state?
<pedronis> is not expected to do that
<pedronis> what does snap list says on it?
<cachio> pedronis, not sure. I can't tell you due to I don't have the hardware here, I am looking at the logs
<pedronis> either way it's in a strange state
<cachio> pedronis, the hardware/os is in the taipei lab
<pedronis> afaict
<pedronis> maybe now it fixed itself
<pedronis> or not
<cachio> I ran twice and got the same results
<pedronis> sorry, I don't know enough
<cachio> pedronis, It isntall first time and the snaps are instlaled correctly
<cachio> pedronis, then after the first remove, it starts with this message
<pedronis> but IÂ wouldn't expect a core system to have ubuntu-core around and need to transition away from it again and again
<pedronis> cachio: it's not about your installs
<pedronis> it's trying to do something in parallel  (converting from have a core snap called ubuntu-core to the one called just core)
<pedronis> but a)Â I don't think ubuntu core system should do that, not anything new/sane  b)Â it seems it's failing again and again if you are seeing that error all the times
<pedronis> without access to debug more is hard to tell tough
<pedronis> you may ask the people that manage to reflash it or something
<cachio> ok, I'll try it
<cholcombe> are private snaps a thing now?  I haven't looked in a long time
<cachio> pedronis, I'll see if I can reproduce it here too
<cholcombe> cool.  looks like there's a --private flag now.  can launchpad utilize that?
<zyga> o/
<zyga> maybe we can discuss this in a private channel?
<zyga> maybe in #ce-certification-qa on canonical IRC
<zyga> cachio: who is managing those devices?
<cachio> zyga, those are attached to a maas solution and I access by using teestflinger
<cachio> zyga, plars is managing that solution
<zyga> noted
<cachio> zyga, tell me if you want to see the full log
<zyga> cachio: if you could send me an email with the details
<zyga> cachio: anything you can tell me will help
<zyga> cachio: to my canonical email
<zyga> cachio: I will gladly check it out next week
<cachio> zyga, sure
<cachio> zyga, I'll do that
<zyga> cachio: thank you!
<mup> PR snapd#3058 closed: tests: skip lp-1644439 test on older kernels <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3058>
#snappy 2017-03-18
<glimcoil> Hmmm.. going desperate trying to setup project on "build.snapcraft.io". Whatever name I give to register (existing from my account or new one), it always errors with "Unauthorized"
<glimcoil> This is for the "Registered for publishing" field. I have the github repo added already.
<mup> PR snapd#3053 closed: asserts: don't allow revocations with other items for the same developer <Created by emgee> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3053>
<pachulo> Hi all! 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?
#snappy 2017-03-19
<mup> PR snapd#3032 closed: cmd: rename all unit tests to $command/unit-test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3032>
<mup> PR snapd#3055 closed: cmd/snap: fix help string for version command <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3055>
<mup> Bug #1674093 opened: Cannot refresh a snap with error "cannot refresh local snap" <Snappy:New> <https://launchpad.net/bugs/1674093>
<mup> PR snapcraft#1200 opened: tests: allow to run individual autopkgtest suites <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1200>
<mup> Bug #1612440 changed: Full systemd socket activation support <lxd> <Snapcraft:New> <snapd:Confirmed> <https://launchpad.net/bugs/1612440>
#snappy 2018-03-12
<Son_Goku> TingPing, you might want to try with the 2.31.1 snapd
<Son_Goku> it is in testing for Fedora
<Son_Goku> https://bodhi.fedoraproject.org/updates/?packages=snapd
<TingPing> Son_Goku, i tested on ubuntu 16.04, which honestly is the only version i particularly care about
<Son_Goku> ah
<Son_Goku> I thought you were a Fedora user...
<TingPing> i am
<Son_Goku> apologies for assuming
<Son_Goku> snapd in Ubuntu 16.04 has had a tumultuous time getting updated
<Son_Goku> so they've been lagging behind Fedora on updates
<TingPing> funny
<Son_Goku> well, I try to keep things fresh ;)
<Son_Goku> Fedora also beat Ubuntu to getting an updated Mir, too ;)
<Son_Goku> despite all the issues caused by gcc8
<Son_Goku> and fweimer's change to the distro compiler flags
<TingPing> sounds masochistic
<TingPing> while i'm here are there any download "badges" for snap?
<Son_Goku> badges?
<Son_Goku> what do you mean?
<TingPing> like a standardize logo to indicate a snap download
<Son_Goku> ah
<Son_Goku> you mean like the things Apple/Google do?
<TingPing> yea
<Son_Goku> yeah
<Son_Goku> there's a "snap|built and released" button
<Son_Goku> you can get it through build.snapcraft.io when you connect your GitHub account to the build system
<Son_Goku> but a regular button? I don't think so
<Son_Goku> an example badge: https://github.com/snapcrafters/atom/blob/master/README.md
 * TingPing is working on this https://i.imgur.com/XP2i53v.png
<Son_Goku> snaps have an official logo
<Son_Goku> and generally speaking, the usage of the ubuntu logo isn't permitted in association with snaps, jfyi
<TingPing> link to their logo?
<Son_Goku> TingPing, yep, trying to find it
<Son_Goku> one sec
<Son_Goku> TingPing: https://assets.ubuntu.com/v1/d24ea71e-10.+SNAPCRAFT_LOGO_AW.zip
<Son_Goku> you'll want {PNG,SVG}_stacked/snapcraft_green-red_st_hex.{png,svg}
<Son_Goku> hmm
<Son_Goku> TIL that cloud-init has a logo
<TingPing> bit annoyingly sized
<mborzecki> morning
 * mborzecki is afk for ~1h
<zyga-ubuntu> good morning
<mborzecki> aand i'm back
<mborzecki> zyga-ubuntu: morning
<zyga-ubuntu> hey
<zyga-ubuntu> it's good to be home :-)
<mborzecki> yay ;)
<mvo> hey zyga-ubuntu and mborzecki !
<zyga-ubuntu> hey mvo! :)
<mborzecki> mvo: hey
 * zyga-ubuntu updates his fedora system
<mborzecki> zyga-ubuntu: some intersting fedora work coming up?
<zyga-ubuntu> I wanted to fix a build issue on newer gcc's
<zyga-ubuntu> and since I have ubuntu on my laptop now I could play on fedora on my desktop for some time
<mborzecki> zyga-ubuntu: what build issue on newer gcc? i have 7.3 here and rebuilt the package yesterday
<zyga-ubuntu> I don't remember; Neal said there are some issues
<zyga-ubuntu> I just rebooted and I'll make a rawhide chroot
<mborzecki> zyga-ubuntu: maybe that's the media-sharing interace thing?
<mborzecki> zyga-ubuntu: /media vs /run/media
<zyga-ubuntu> I'll find out soon
<zyga-ubuntu> that one was supported for long time now
<zyga-ubuntu> but maybe it regressed
<mborzecki> zyga-ubuntu: ok, ping me if you need help
<mborzecki> hah, had to do blood tests in the morning, now i can make up for the lost blood with some chocolate :P
<zyga-ubuntu> yum yum
<pstolowski> morning!
<mvo> hey pstolowski ! good morning
<mborzecki> pstolowski: hey
<zyga-ubuntu> mvo: hey, did you try the tea by any chance? :-)
<user9445> hello everyone! I am not a linux expert and I have a question. Can I turn any program into a snap package if I can get its source code? I was thinking about virtualbox.
<user9445> the official tutorial looks quite easy
<zyga-ubuntu> user9445: hey,
<zyga-ubuntu> user9445: virtual box may be a bit harder to snap unless you want to make the kernel modules optional
<zyga-ubuntu> user9445: but in general, with enough persistence, yes you can snap anything, it's just a format for packaging
<zyga-ubuntu> mborzecki: do you know how to get a fedora chroot?
<zyga-ubuntu> I'd rather have a chroot with rawhide than a VM with one
<mborzecki> systemd-nspawn is probably the easiest way, but you'll probably need dnf to install everything, maybe they still publis the raw rootfs images, so this might be a second way to try
<zyga-ubuntu> oh, I didn't think about that
<zyga-ubuntu> the host if F27
<mvo> zyga-ubuntu: yeah, its interessting. pretty strong flavor, not what I am used to but I will drink it a bit and see if it clicks :)
<mborzecki> zyga-ubuntu: https://download.fedoraproject.org/pub/fedora/linux/releases/27/CloudImages/x86_64/images/Fedora-Cloud-Base-27-1.6.x86_64.raw.xz raw image
<mvo> zyga-ubuntu: I will definitely get you some for the next sprint as well :)
<zyga-ubuntu> mvo: not sure how many leaves did you use, I usually use a few for a sizable mug (~1L)
<kalikiana> o/
<pstolowski> how was your travel back home guys?
<mborzecki> pstolowski: short :P
<mborzecki> pstolowski: and we got a chance to do some sightseeing on Saturday morning (at least me, zyga-ubuntu and koza, the rest were leaving earlier)
<mvo> zyga-ubuntu: ok, I try a smaller one then :)
<pstolowski> mborzecki: nice!
<morphis> mvo: zyga-ubuntu: any idea about https://forum.snapcraft.io/t/nvidia-gl-libs-access-broken-on-ubuntu-18-04/4440 ?
<zyga-ubuntu> morphis: ah, interesting
<zyga-ubuntu> I will respond on the forum
<zyga-ubuntu> morphis: done
<morphis> zyga-ubuntu: thanks!
<Chipaca> moin moin
<Chipaca> mborzecki: would you mind doing the fuzzing thing again on the puritan pr?
<Chipaca> mborzecki: I lopped a bunch of checks off
<Chipaca> which should be fine, given they were unreachable :-)
<mborzecki> Chipaca: ok, will try in a couple of minutes
<Chipaca> mborzecki: thanks!
<mvo> Chipaca: hey, good morning! do you think 4805 can be merged? or because of it being api we need a gustavo review?
<Chipaca> mvo: I don't think rob addressed my concerns
<Chipaca> let me check
<Chipaca> mvo: "the correct behaviour is if the field is omitted to assume that classic is supported." <- that's not what we do for eveyr other boolean
<mvo> Chipaca: please mark as "request change" then, just to ensure it does not get merged accidently
<pstolowski> mvo: is https://github.com/pilebones/go-udev the udev implementation you found last week?
<mvo> pstolowski: yes
<mup> PR snapd#4811 opened:  tests/main/media-sharing: improve the test to cover /media and /run/media <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4811>
<mborzecki> nice & easy PR ^^
<pstolowski> mborzecki: commented
<pstolowski> hey Chipaca!
<Chipaca> pstolowski: hi!
<mborzecki> pstolowski: cmd/snap-confine/spread-tests/main/media-visible-in-devmode this test?
<pstolowski> mborzecki: yes
<mborzecki> pstolowski: i don't think these are run at all
<pstolowski> mborzecki: nb I misread the systems clause there, it's run everywhere but debian it seems; what makes you think it's not executed?
<mborzecki> pstolowski: cmd/snap-confine/spread-tests is not referenced in the top level spread test file
<zyga-ubuntu> mborzecki: it's not used
<zyga-ubuntu> man, we should drop most of those tetsts
<zyga-ubuntu> those are from when snap-confine was in a separate repository by itself
<Chipaca> mborzecki: it's left there by zyga to catch the unwary
<pstolowski> mborzecki: allright
<pstolowski> +1
<mborzecki> haha,  are those kept for reference or shall we make them go away then? :)
<zyga-ubuntu> one by one either enable and port or drop
<Chipaca> zyga-ubuntu: every seen this?
<Chipaca> execl failed: Permission denied
<Chipaca> child exited with status 1: File exists
<Chipaca> zyga-ubuntu: https://api.travis-ci.org/v3/job/352240343/log.txt
<zyga-ubuntu> Chipaca: yes, on Friday
<zyga-ubuntu> is this against master or release?
<Chipaca> zyga-ubuntu: master
<zyga-ubuntu> hmmm
<Chipaca> zyga-ubuntu: not a new master though, it's probably a few commits behind
<zyga-ubuntu> perfect, 14.04, no logs
<zyga-ubuntu> so what we saw in the release branch on Friday is that apparently something mixes old profile and new profile on disk
<mvo> zyga-ubuntu: can you remind me again why 2.32 is broken and also why it seems not to be broken when I run an isolated 2.32 test in qemu?
<zyga-ubuntu> great question mvo, still investigating that
<zyga-ubuntu> so I don't really know yet
<mvo> zyga-ubuntu: aha, great. can you reproduce it somehow?
<zyga-ubuntu> yes
<mvo> zyga-ubuntu: how?
<zyga-ubuntu> I mean, I just ran it in qemu
<zyga-ubuntu> was I just lucky?
<mvo> zyga-ubuntu: I don't know :) did you run just a single failing test or the full ting? I just did the former and do the later now
<zyga-ubuntu> I ran tests/main
<zyga-ubuntu> my goals today are to fix that, fix the bug that manifests itself as /etc and get back to the bigger bug of /etc being writable
<mvo> zyga-ubuntu: ok
<Chipaca> zyga-ubuntu: should I just restart this particular test?
<zyga-ubuntu> hmm hmm
<zyga-ubuntu> there's nothing in the debug log there
<zyga-ubuntu> yeah, restart it for now
<zyga-ubuntu> I need to get this under control
<mborzecki> Chipaca: got some panics
<Chipaca> mborzecki: woo
<Chipaca> mborzecki: show me :-)
<mborzecki> Chipaca: i can let it run for a bit and then upload the corpus
<Chipaca> mborzecki: ok
<mvo> zyga-ubuntu: as a data point - tests seem to be ok if run in isolation so something is bleeding into it
<zyga-ubuntu> yeah, I'm mid way and nothing failed now
<zyga-ubuntu> :-(
<mborzecki> Chipaca: https://paste.ubuntu.com/p/v45xJKWvSY/
<zyga-ubuntu> do you have the seed with a failure by any chance?
<mvo> mborzecki: one of the errors in 4811 looks real
<Chipaca> mborzecki: can i see the fuzz function?
<Chipaca> mborzecki: (i suspect you're calling marshal directly :-) )
<mborzecki> Chipaca: yes i do
<Chipaca> *unmarshal
<mvo> zyga-ubuntu: maybe, let me try
<Chipaca> mborzecki: ah, yes that won't work, now -- it's called on things that json already knows is valid json
<zyga-ubuntu> mvo: I'm looping through this on my laptop
<zyga-ubuntu> it did fail on Friday
<mvo> zyga-ubuntu: 1520606008 is what travis was using
<zyga-ubuntu> thanks, I will try that with another backend
<zyga-ubuntu> not sure if this is reliable
<mborzecki> Chipaca: https://paste.ubuntu.com/p/ngFTQqvD4Y/ corpus https://send.firefox.com/download/d3fc9b236a/#CmR2CZR9_Ej7kx3qLjX_JQ
<Chipaca> mborzecki: ah! hm! oh!
<Chipaca> mborzecki: thanks
<mborzecki> Chipaca: that's the tool(ing) https://github.com/dvyukov/go-fuzz
<Chipaca> mborzecki: so maybe I should put those checks back in; the bad data needs to be fed to UnmarshalJSON directly, but that's a public function so why wouldn't it
 * Chipaca feels dumber and wiser at the same time
<mborzecki> haha :) anyways, the fuzzer is a nice thing to play with
<Chipaca> mborzecki: on the next run I got two of them: https://api.travis-ci.org/v3/job/352240343/log.txt
<Chipaca> um
<Chipaca> zyga-ubuntu: you ^
<Chipaca> zyga-ubuntu: one on 16.04
<zyga-ubuntu> wow
<zyga-ubuntu> that's master + stuff right?
<mborzecki> hm device cgroups stopped working or what?
<Chipaca> zyga-ubuntu: master up to 275d1cac4a774fe784f764c0788a689e60cc9d0a
<zyga-ubuntu> man
<Chipaca> zyga-ubuntu: then it's jsonutil/puritan and using it from store; at the opposite end from cgroups :-)
<mvo> this might be a race, I saw those failing sometimes (just saying)
<zyga-ubuntu> it would be way better if spread would say which machine is running a given test
<zyga-ubuntu> to show a trace of failure on a given machine
<mvo> (I mean, we need to look into this but I wonder if its consistent)
<zyga-ubuntu> reproducing this takes tons of time :/
<mborzecki> catching --strace='--raw' would be useful
<zyga-ubuntu> I mean
<zyga-ubuntu> I know what happens
<zyga-ubuntu> not sure why it happens
<zyga-ubuntu> what happens is that snap-confine doesn't have permission to run snap-update-ns
<mborzecki> zyga-ubuntu: shouldn't the denial be logged?
<zyga-ubuntu> yes
<zyga-ubuntu> it should
<zyga-ubuntu> and it's not
 * Chipaca -> physio gym thing
<mborzecki> mvo: i'll into tests/main/snap-service-refresh-mode as it's still failing randomly
<mborzecki> look into
 * Chipaca -> really leaves
<mvo> mborzecki: \o/ thank you
<mvo> mborzecki: maybe its a real issue :(
<mvo> (even though its hard for me to see from the code how this could be)
<mvo> zyga-ubuntu: slightly frustrating, I have no luck reproducing the 2.32 failure in qemu so far, I did two runs, one with random seed and one with seed from a failing PR against qemu:ubuntu-16.04-64 but no failures so far (and almost finished)
<zyga-ubuntu> could it be, perhaps, caused, by any changes in core that landed since?
 * zyga-ubuntu looks at the logic in prepare code
<pedronis> #4789 needs a 2nd review
<zyga-ubuntu> for me it's not failing anymore either
<mup> PR #4789: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4789>
<zyga-ubuntu> mvo: are you running all of it or just some
<zyga-ubuntu> maybe the update test leaks something into the system?
<mvo> all of main
<cachio> mvo, hey
<mvo> cachio: hey
<mvo> cachio: hope you are well!
<mvo> zyga-ubuntu: *cough* 2.32 is green again
<zyga-ubuntu> :/ yeah same here
<zyga-ubuntu> it's driving me nuts
<zyga-ubuntu> so what changed since friday
<zyga-ubuntu> is it just bad luck
<zyga-ubuntu> what's the real problem we're not seeing
<mvo> zyga-ubuntu: also green in travis
<zyga-ubuntu> 1st world problems, tests are green but WHY :)
<mvo> zyga-ubuntu: indeed, very peculiar
<zyga-ubuntu> ok, I'll keep running and look at our prepare/restore code
<zyga-ubuntu> and maybe, just maybe, something will come up
<zyga-ubuntu> how come there's no shellcheck snap yet
<zyga-ubuntu> mvo: I found a small bug in spread.yaml
<zyga-ubuntu> mvo: the tests/completion suite's restore  code doesn't remove snap-confine
<zyga-ubuntu> it's not a big deal (maybe)
<zyga-ubuntu> I've patched it locally now
<zyga-ubuntu> snap-confine is supposed to be just transitional now
<mvo> zyga-ubuntu: ta
<mup> PR snapd#4639 closed: store: enable deltas for core devices too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4639>
<zyga-ubuntu> same with the regression suite
<zyga-ubuntu> mvo: I just got a failure on the 2.32 branch
<zyga-ubuntu> [Mon Mar 12 12:57:05 2018] audit: type=1400 audit(1520855826.802:795346): apparmor="DENIED" operation="exec" profile="/snap/core/4224/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snap-device-helper" pid=31151 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<zyga-ubuntu> I have a debug shell
<mvo> zyga-ubuntu: what test is that?
<zyga-ubuntu> https://www.irccloud.com/pastebin/47FjVl3F/
<zyga-ubuntu> security-device-cgroups
<zyga-ubuntu> with the uinput sub-test
<zyga-ubuntu> the previous one was validate-container
<zyga-ubuntu> this is on a single-machine qemu
<mvo> zyga-ubuntu: thanks, looking
<zyga-ubuntu> the profile on disk is: http://paste.ubuntu.com/p/BNBk4526cC/
<zyga-ubuntu> this is /etc/apparmor.d/snap.core.4224.usr.lib.snapd.snap-confine
<zyga-ubuntu> there is no snap-device-helper here
<mvo> zyga-ubuntu: hm, yeah
<zyga-ubuntu> looking at the core snap
<zyga-ubuntu> maybe the core snap got repackaged
<zyga-ubuntu> with some broken stuff inside
<mvo> zyga-ubuntu: oh, I think this is the snapd that uses the symlink, so looks like one more thing to cherry pick
<zyga-ubuntu> this is the profile in the core snap there: http://paste.ubuntu.com/p/tcQ42chRQK/
<zyga-ubuntu>     /usr/lib/snapd/snap-device-helper ixr, # drop
<zyga-ubuntu> it _has_ permission to run this
<zyga-ubuntu> so this is clearly broken
 * zyga-ubuntu diffs the two files
<mvo> zyga-ubuntu: meh, how can this happen? this looks like test prepare is broken
<zyga-ubuntu> https://www.irccloud.com/pastebin/KmbgETkf/
<zyga-ubuntu> hum
<zyga-ubuntu> this makes no sense
<zyga-ubuntu> -    /usr/lib/snapd/snap-device-helper ixr, # drop
<zyga-ubuntu> +    /lib/udev/snappy-app-dev ixr, # drop
<zyga-ubuntu> how did we go from - snap-device-helper (from the core snap) to + snappy-app-dev from the apparmor.d dir?
 * zyga-ubuntu looks at the preserved test tarball helper thing
<zyga-ubuntu> mvo: I bet you this will show the prepare/restore is wrong
<mvo> zyga-ubuntu: yeah, I need to get lunch now, biab
<mborzecki> zyga-ubuntu: are you running just this test or the whole bunch?
<zyga-ubuntu> mvo: confirmed, the tarball has junk inside
<zyga-ubuntu> mborzecki: all of main each time
<zyga-ubuntu> let me give you the seed
<zyga-ubuntu> this is on top of release/2.32
<zyga-ubuntu> zyga@t470:~/snapd$ spread -debug -v qemu:ubuntu-16.04-64:tests/main/
<zyga-ubuntu> 2018-03-12 12:07:55 Found /home/zyga/snapd/spread.yaml.
<zyga-ubuntu> 2018-03-12 12:07:58 Project content is packed for delivery (3.88MB).
<zyga-ubuntu> 2018-03-12 12:07:58 Sequence of jobs produced with -seed=1520852878
<zyga-ubuntu> mborzecki: can you please run that and see if you get the exact same bug?
<zyga-ubuntu> I will look at why this happens
<zyga-ubuntu> I have an idea now
<zyga-ubuntu> and man
<zyga-ubuntu> mborzecki: I can send you my spread binary if that is a factor
<zyga-ubuntu> 2018-03-12 12:16:21 Preparing qemu:ubuntu-16.04-64:tests/main/interfaces-many...
<zyga-ubuntu> # ls -ld $SPREAD_PATH/snapd-state.tar.gz
<zyga-ubuntu> -rw-r--r-- 1 root root 366991360 Mar 12 12:16 /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz
<zyga-ubuntu> so at around the time when we ran interfaces-many test, the state tarball was made
<zyga-ubuntu> and it wasn't touched since
<zyga-ubuntu> and it contains _wrong_ code
<zyga-ubuntu> as in, it captures a state that is wrong
<zyga-ubuntu> and much much later
<zyga-ubuntu> 2018-03-12 12:57:06 Error executing qemu:ubuntu-16.04-64:tests/main/security-device-cgroups:uinput :
<zyga-ubuntu> this test failed because of that
<zyga-ubuntu> that test doesn't fiddle with snapd
<zyga-ubuntu> now
<zyga-ubuntu> we have code that detects this and writes a correct profile
<zyga-ubuntu> but when I inspected the system it wasn't apparent it ran
<zyga-ubuntu> aha
<zyga-ubuntu> but this code only runs when we install core
<zyga-ubuntu> and if none of the preceeding tests tired to run snap-devce-helper / snappy-app-whatever it was
<zyga-ubuntu> it would not trigger
<zyga-ubuntu> mvo: so we still have an issue that may need addressing
<zyga-ubuntu> apart from 1) how did we get there we have the problem that on startup we 2) may run with stale profile for snap-confine because it is only remade when we install "core"
<zyga-ubuntu> I also looked at the backend initialize function and I doubt it is loading the stale profile  because it would only do so on system-key like events (nfs or overlay)
<zyga-ubuntu> the system-key file also looks sensible
<zyga-ubuntu> I added some debug and I will try to reproduce that with the same seed ( -seed=1520852878)
<zyga-ubuntu> mvo: one thing that _may_ be related is that /var/cache/apparmor is full of things
<zyga-ubuntu> as is /etc/apparmor.d/cache
<zyga-ubuntu> the biggest question is if the seed will reproduce the issue
<cachio> niemeyer, hey, when you have a time
<cachio> https://github.com/snapcore/spread/pull/52
<mup> PR spread#52: Add storage option for google <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/52>
<cachio> that shoul fix the issue that savic was reporting about out of space
<cachio> tx
<mup> PR snapd#4812 opened: tests/main/snap-service-refresh-mode: refactor the test to rely on comparing PIDs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4812>
<zyga-ubuntu> so, I wonder about an idea
<zyga-ubuntu> let's say I get a failure again, and that -seed works
<zyga-ubuntu> how can we make spread bisect the test suite to find what breaks
<zyga-ubuntu> that is, run the failing test after running half of the preceding tests, etc
<cachio> mvo, niemeyer I am waiting for a doctor at home, perhaps I'll be starting later the standup
<zyga-ubuntu> excellent, I can reproduce the issue reliably now mvo
<mborzecki> zyga-ubuntu: my test run is still in progress, should i abort?
<zyga-ubuntu> no sure, why?
<mborzecki> zyga-ubuntu: thought that maybe reuse the seed, and only use those 2 tests that you mentioned
<zyga-ubuntu> aga
<zyga-ubuntu> aha
<zyga-ubuntu> well, which test are you on now?
 * kalikiana will go try and have lunch without being too soaked in the rain
<mborzecki> (143/234)
<zyga-ubuntu> no, please wait then
<zyga-ubuntu> it's on 155 AFAIR
<zyga-ubuntu> so "soon"
<mborzecki> taking ages :/
<zyga-ubuntu> mborzecki: when did you start it?
<mborzecki> 12:40, but then it got stuck in a debug shell in a test i was working on, and took a while before i noticed
<zyga-ubuntu> ah
<zyga-ubuntu> for me it's ~30 minutes
<zyga-ubuntu> +/- 15 minutes
<mvo> zyga-ubuntu: part of the problem is that edge is not really edge
<mvo> zyga-ubuntu: I just pushed a pr
<zyga-ubuntu> oh?
<zyga-ubuntu> mvo: can you explain please
<zyga-ubuntu> I see
<mup> PR snapd#4813 opened: release: snapd 2.31.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4813>
<mvo> zyga-ubuntu: snap info core :/ its on 2.31.2 in edge right now
<zyga-ubuntu> mvo: but how would it be a factor
<zyga-ubuntu> mvo: since we change the version to leet
<mvo> zyga-ubuntu: 2.31 is still using snappy-app-dev
<zyga-ubuntu> I mean, is it a factor?
<mvo> zyga-ubuntu: so that explains why the profiles are strange
<zyga-ubuntu> yes but whatever is in whatever channel we start with
<zyga-ubuntu> we are repackaging core, no?
<mvo> yes
<Son_Goku> mvo, can we get this merged so I can rebase? https://github.com/snapcore/snapd/pull/4811
<mup> PR #4811:  tests/main/media-sharing: improve the test to cover /media and /run/media <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4811>
<mborzecki> Son_Goku: merged
<mup> PR snapd#4811 closed:  tests/main/media-sharing: improve the test to cover /media and /run/media <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4811>
<mup> PR snapcraft#1985 closed: tests: document arm testing setup <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1985>
<zyga-ubuntu> mborzecki: did it fail?
<mborzecki> zyga-ubuntu: nope, (214/234)
<zyga-ubuntu> so it's past that test
<zyga-ubuntu> were you on release/2.32
<mborzecki> zyga-ubuntu: i used the same seed as you
<mborzecki> yes
<zyga-ubuntu> and on qemu of xenial?
<zyga-ubuntu> that's not great then :/
<zyga-ubuntu> thank you, I wonder what this says then
<mborzecki> yes, tip of release/2.32 branch
<pstolowski> niemeyer: so, the interface is named "dummy" atm, with a description saying "snapd dummy test interface"
<niemeyer> pstolowski: What's the PR?
<niemeyer> pstolowski: After the conversation we just had, that's not too bad actually.. perhaps "snapd-dummy".. I'd just like to have a look at the code first
<pstolowski> niemeyer: #4358
<mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
<pstolowski> niemeyer: look for dummy.go
<niemeyer> Thanks
<zyga-ubuntu> niemeyer: no-op interface?
<mborzecki> Chipaca: #4800 is the same as #4799 and the title suggests it ought to be a different thing
<mup> PR #4800: cmd/snap: in changes and tasks, default to human-friendly times <Created by chipaca> <https://github.com/snapcore/snapd/pull/4800>
<mup> PR #4799: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <https://github.com/snapcore/snapd/pull/4799>
 * Chipaca looks
<Chipaca> wtf
<mborzecki> Chipaca: bad rebase?
<Chipaca> mborzecki: thanks, i'll take a look
<Chipaca> mborzecki: shouldn't be, but maybe? 'tis a mystery
<Chipaca> :-)
<Chipaca> mborzecki: probably fat fingers of some sort
<mborzecki> Chipaca: hopefully nothing that cannot be fixed with the reflog :P
<mborzecki> zyga-ubuntu: sorry to disappoint you, found this in my shell history 'git checkout -b release/2.32', i'm restarting the tests
<zyga-ubuntu> :D
<mborzecki> if i use the same -seed=.. and list jus 2 tests, will they be run in the same order as if i used tests/main/ ?
<zyga-ubuntu> mborzecki: I don't think so
<zyga-ubuntu> not sure
<zyga-ubuntu> niemeyer: ^
<niemeyer> pstolowski: This is not a dummy interface, because it actually has expectations in its logic
<niemeyer> pstolowski: People in general will expect "dummy" or "nil" or "no-op" or anything similar to actually not do anything
<niemeyer> So we need a name to represent that
<zyga-ubuntu> sunshine
<pstolowski> niemeyer: it's dummy in a sense that it doesn't provide any functionality; it's only useful to test against
 * Chipaca brb
<niemeyer> pstolowski: Yeah, maybe that's fine, and then we can expose this as a general dummy interface that any snap can use.. I'm adding some comments to the PR
<mvo> zyga-ubuntu: *maybe* I found the issue with the 2.32 tests, its tests only, I'm running a test now
<zyga-ubuntu> mvo: I'm all ears
<zyga-ubuntu> I'm iterating on narrowing down the set of tests that causes it
<pstolowski> niemeyer: thanks
<kalikiana> re
<niemeyer> pstolowski: Please have a look
<mup> PR snapd#4814 opened: tests: fix re-exec profile generation in tests on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4814>
<mvo> zyga-ubuntu: just pushed a PR that hopefully explains it (for 2.32) and will also push one for master
<zyga-ubuntu> ack
<mvo> zyga-ubuntu: its essentially a race
<zyga-ubuntu> what's racing?
<mvo> zyga-ubuntu: between us modifying the core and the auto-generated snap-profiles for the core. because we have the system key now we need to make sure to re-generate them
<mvo> zyga-ubuntu: so your idea about ensure-dir-state was correct, its just that the system-key now prevents security profile generation if nothing has changed
<mvo> zyga-ubuntu: (nothing in the inputs)
<pstolowski> niemeyer: looking, thanks
<zyga-ubuntu> I see
<zyga-ubuntu> mvo: any ideas why this would explain why I can reproduce the problem with a given seed?
<mup> PR snapd#4815 opened: tests: fix re-exec profile generation in tests on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4815>
<cachio> jdstrand, hey, I see this denial executing the security-device-cgroups:uinput
<cachio> https://paste.ubuntu.com/p/gDqTw7JPrp/
<zyga-ubuntu> cachio: jamie is off this week
<zyga-ubuntu> cachio: and this is the issue we are discussing with mvo now
<cachio> zyga-ubuntu, ah, ok, good to know, thanks
<mvo> zyga-ubuntu: maybe, its a mystery why it is not reproducible with the seed. however the race is that for some tests the profile is close enough, so if for whatever reason we force re-generation of security profiles in any test and that happens before the failing test things are good
<zyga-ubuntu> mvo: I managed to reproduce it by running one test now
<zyga-ubuntu> mvo: maybe it depends on my CPU speed or something like that?
<zyga-ubuntu> I'll try your patch on my system, thank you for pushing the fix and finding the problem
<mup> PR snapd#4816 opened: Tests move xenial i386 to google <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4816>
<mvo> zyga-ubuntu: thank you!
<zyga-ubuntu> I will try -resend next
<zyga-ubuntu> now that I can essentially iterate on one test
<mup> PR snapd#4812 closed: tests/main/snap-service-refresh-mode: refactor the test to rely on comparing PIDs <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4812>
<mvo> Chipaca: how do you feel about 4486? it will run `snap advise` when `snap run not-installed-command` is used. but given our command-not-found work I think we can kill this. wdyt?
<mup> PR snapd#4799 closed: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4799>
<mvo> Chipaca: and one more silly question, why does https://github.com/snapcore/snapd/pull/4800/files#diff-dbcb08a7fd2e809c90019780f0ae6cf6R562 change the format in the tests?
<mup> PR #4800: cmd/snap: in changes and tasks, default to human-friendly times <Created by chipaca> <https://github.com/snapcore/snapd/pull/4800>
<mup> PR snapd#4817 opened: overlord:  implement policy of holding refreshes for up to 6h since seeding on classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/4817>
<mup> PR snapd#4486 closed: snap: make `snap run not-install` output advise for not installed commands <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4486>
<Chipaca> mvo: kill it :-)
<Chipaca> mvo: i mean, #4486
<mup> PR #4486: snap: make `snap run not-install` output advise for not installed commands <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4486>
<Chipaca> mvo: i messed up a rebase and need to fix it
<pedronis> Chipaca: seems you landed something that conflicts with 4789
<pedronis> bit of a mess given that we probably want to cherry pick the latter
<Chipaca> #4789
<mup> PR #4789: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4789>
<pedronis> for 2.32
<Chipaca> in my defense, it was mvo that landed it :-)
<Chipaca> mvo: the rebase I messed up was the 'changes' one, fwiw
<pedronis> mvo: ^^^
 * zyga-ubuntu feels he's getting sick :/
<zyga-ubuntu> this sucks
<Chipaca> digging in the reflog as i type
<Chipaca> well, not as i type
<mvo> Chipaca: uuhhh, what pr was that?
<pedronis> mvo: it's a bit of a mess if we land cosmetics over things we want for 2.32
<Chipaca> mvo: #4800
<mup> PR #4800: cmd/snap: in changes and tasks, default to human-friendly times <Created by chipaca> <https://github.com/snapcore/snapd/pull/4800>
<mvo> pedronis: yes, sorry for that
<pedronis> I'm quite sure we already we will have fun with the changes to store tests
<Chipaca> mvo: I'd recommend removing #4799 from master
<mup> PR #4799: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4799>
<Chipaca> mvo: make your life easier
<Chipaca> (and by removing i mean 'git revert --hard && git push --force' :-)
<mvo> Chipaca: not sure we can do that, but an old fashioned revert seems to be ok
<Chipaca> mvo: we can (we just need to untick the --force protection around it)
<Chipaca> (bah, that might involve niemeyer)
<mvo> zyga-ubuntu: it looks like spread is disagreeing with my fix :(
<pedronis> anyway a 2nd review for #4789 so it can land would also help
<mup> PR #4789: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4789>
<zyga-ubuntu> mvo: my results will come up soon,
<zyga-ubuntu> mvo: I'm still looking
<mvo> zyga-ubuntu: its very annoying, it all made sense. I hope to get a debug shell soon
<zyga-ubuntu> Thank you
<mvo> zyga-ubuntu: maybe its something silly and I can cling on to my theory
<zyga-ubuntu> I hope the tea will help you on the way :)
<zyga-ubuntu> added more debug, with your patch and restarted
<mup> PR snapd#4818 opened: Revert "cmd/snap: use timeutil.Human to show times in `snap refresh -â¦-time`" <Created by mvo5> <https://github.com/snapcore/snapd/pull/4818>
<Chipaca> mvo: about changing the format in the tests, which one do you mean? I presume it's something in https://github.com/snapcore/snapd/pull/4799/files
<mup> PR #4799: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4799>
<Chipaca> mvo: (i changed a few formats for different reasons...)
<mvo> Chipaca: let me just ask in the PR that is easier
<Chipaca> mvo: ok :-)
<Chipaca> mvo: but I _think_ the one you're asking about is because before it just blatted whatever came in the json, and the json in the test was not kosher
<pedronis> mvo: did you just review #4789 ?
<mup> PR #4789: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4789>
<Chipaca> pedronis: yes he did
<pedronis> thx
<mvo> Chipaca: aha, ok. that was my question - i.e. if the json was incorrect or something changed
<mvo> pedronis: yes, sorry that it took so long
<Chipaca> mvo: the json was fanciful
<Chipaca> :-)
<pedronis> mvo: np,   was confused by the fix reference,  is that about the last change there?
<Muravey> Hi
<Chipaca> Muravey: hi
<zyga-ubuntu> hey hey
<mvo> pedronis: the fix reference to zyga-ubuntu ? that was about the test failures on master and 2.32. I thought I had found the issue (race with the core profile rewrite)
<mvo> pedronis: but then spread failed in a similar way so there must be more to it
<Muravey> Can anyone help me? I tring to make snap package for cataclysm dda game
<pedronis> mvo: no, the fix in your +1 comment to 4789
 * zyga-ubuntu is still looking
<mvo> pedronis: oh, I mean, thanks for fixing this issue, i.e. thanks for this new feature :)
<Chipaca> Muravey: sure (but if it gets long we might ask you to take it to the forum instead)
<Muravey> After install package i cant run game and it's crashed with file not found
<pedronis> mvo: ah
<pedronis> :)
<zyga-ubuntu> Muravey: run snap run --shell yoursnapname
<zyga-ubuntu> and explore the environment
<zyga-ubuntu> that may explain some things to you
<zyga-ubuntu> mvo: it didn't fail with your patch now ://
<Muravey> zyga-ubuntu: sorry for my english
<zyga-ubuntu> I'll try again with all of main
<zyga-ubuntu> and the same seed as before
<Muravey> zyga-ubuntu: what environments i need see? PATH?
<zyga-ubuntu> Muravey: no, I mean more than that, the whole filesystem
<Chipaca> Muravey: tell us more about your snap
<zyga-ubuntu> your snap is mounted at /snap/yoursnapname/somenumber/
<zyga-ubuntu> and if you open a file, say from /usr/share/yourapp/foo
<zyga-ubuntu> that won't work
<Chipaca> Muravey: for example, show us your snapcraft.yaml, and your snap.yaml (use pastebin.ubuntu.com)
<zyga-ubuntu> it's a typical problem in snapping software
<Muravey> zyga-ubuntu: will you here in an hour? I'm driving.
<zyga-ubuntu> Muravey: probably not
<zyga-ubuntu> I need to leave soon
<mvo> zyga-ubuntu: yeah, my patch seems to be not sufficient
<zyga-ubuntu> I'll look at what exactly happens on restore in this test
<cachio> mvo, hey
<cachio> I ran some tests for 2.32.2 today in my dragonboard and I see an error
<mup> PR snapd#4819 opened: interfaces/serial: change pattern not to exclude valid devices <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4819>
<cachio> https://paste.ubuntu.com/p/zwRWvmx4GZ/
<cachio> mvo, it is strange because I did not see that error when I executed the tests in testflinger devices for beta validation
<Chipaca> mborzecki: mvo: fwiw #4800 is now what it should've been (probably)
<mup> PR #4800: cmd/snap: in changes and tasks, default to human-friendly times <Created by chipaca> <https://github.com/snapcore/snapd/pull/4800>
<cachio> any idea what be causing that?
<Chipaca> cachio: you don't have policykit installed
<Chipaca> cachio: try again with sudo
<mvo> cachio: what Chipaca said, the error is quite confusing though, it should indicate that it is systemd not the unit that has the problem
<Chipaca> cachio: is tht 14.04?
<cachio> core-16-arm-64
<niemeyer> mvo, Chipaca: Anything I can help with or is it sorted?
<Chipaca> cachio: do we ship policykit in core?
<cachio> Chipaca, with sudo is working
<cachio> the test suite is failing to save the state
<cachio> the snapd service is not running
<Chipaca> cachio: AFAICT we don't ship policykit in core, but I don't know how to improve that error message
<cachio> but I can't see why
<Chipaca> cachio: what happens if you run: SNAPD_DEBUG=1 /usr/lib/snapd/snapd
<mvo> Chipaca: that is coming from systemctl/systemd, right?
<Chipaca> cachio: (as root)
<Chipaca> mvo: yes
<mup> PR snapcraft#1866 closed: lxd: setup LXD remote for multipass <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1866>
<cachio> Chipaca, mvo https://paste.ubuntu.com/p/yM5Tz2qFMw/
<cachio> I found that
<cachio> it is causing snapd doesn't start
<Chipaca> cachio: where is that coming from?
<Chipaca> cachio: and what snapd are you running?
<Chipaca> that change _just_ landed on master
<cachio> + systemctl stop snapd.refresh.timer
<cachio> Failed to stop snapd.refresh.timer: Unit snapd.refresh.timer not loaded.
<cachio> sorry, this was the real proble
<cachio> m
<Chipaca> the abs-time change is on master only
<mvo> cachio: oh? I thought we fixed that everywhere, what branch are you on?
<Chipaca> the snapd.refresh.timer, i thought that was fixed
<cachio> 2.32.2
<Chipaca> yeah something is awry
<Chipaca> cachio: where did the abs-time message come from?
<cachio> Chipaca, sorry, that was from another tests executed on master
<cachio> this is what I see in 2.32.2
<cachio> Failed to stop snapd.refresh.timer: Unit snapd.refresh.timer not loaded.
<cachio> on my device
<Chipaca> cachio: and that is stopping snapd from starting?
<cachio> Chipaca, no, it is making fail the step to create the initial state
<cachio> Chipaca, then the suite fails because the initial state was not created
<mvo> cachio: could you please pastebin "git status" and "git rev-parse HEAD"?
<mvo> cachio: I really though we fixed this timer issue :/
<cachio> mvo, you are right
<cachio> was my fault
<mvo> cachio: no worries
<cachio> mvo, I used 2.32.2 instead of 2.31.2
<cachio> that's why all the tests passed on testflinger
<mvo> cachio: yeah, that is confusing
<cachio> and failed on my device
<cachio> Chipaca, mvo sorry
<cachio> mvo, that happens when I don't sleep well :(
<Chipaca> mvo: speaking of sleeping well, when're you swapping
<Chipaca> ?
<mvo> cachio: with release/2.32:bb05e2fe9539b8728b9d219858125e5f98aed2d5 things should be good in there. 2.31 should be ok as well
<mvo> Chipaca: friday
<Chipaca> mvo: ok
<cachio> Chipaca, my dauther is seek so I could not sleep last night
<mvo> cachio: I hope she gets well soon
<cachio> Chipaca, I planned to rest :(
<cachio> mvo, yes, she is better today
<mvo> cachio: double hard with jetlag I suppose :(
<cachio> mvo, yes, I think I'm not buying chacolates anymore during the sprints
<pedronis> Chipaca: mvo: I'll very likely swap Wed
<mup> PR snapd#4818 closed: Revert "cmd/snap: use timeutil.Human to show times in `snap refresh -â¦-time`" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4818>
 * Chipaca hugs cachio 
<Chipaca> cachio: take care dude
<cachio> Chipaca, :) tx
<cachio> mvo, last thing today for you
<Chipaca> mvo: pedronis: any reason not to merge #4789?
<mup> PR #4789: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4789>
<cachio> mvo, we need the user assertion
<cachio> to run again in nightly the core revert test
<Muravey> zyga-ubuntu: i thought that app in snap package after installing get it's own mount name space.
<pedronis> Chipaca: no, was waiting for ther revert
<Chipaca> pedronis: already there
<mup> PR snapd#4789 closed: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4789>
<pedronis> saw that now, merged
<Chipaca> who was it I chatted with about shipping an empty squashfs? zyga-ubuntu and mvo? or was niemeyer also involved
<niemeyer> Chipaca: Not me
<Chipaca> FYI, https://people.canonical.com/~john/bare.squashfs <- 4k, including a README
<Chipaca> niemeyer: ok
<Chipaca> niemeyer: FWIW it's about not having a good way of detecting / pulling in squashfs support in some situations
<Chipaca> easiest way being to just try to mount something
<niemeyer> Chipaca: Not sure I understand what's the advantage vs. trying to actually mount the thing you indeed want to mount
<Chipaca> niemeyer: 'snap install foo -> download core -> cryptic message because mount failed' vs 'snap install foo' -> 'no squashfs support lolz'
<Chipaca> making it easy and cheap to detect before downloading stuff
<Chipaca> (especially as the error is currently cryptic, but even fixing that knowing in advance the install isn't going to work has value)
<niemeyer> Chipaca: Yes, I understand that part. The question is why is it easier to have a good message when mounting something empty fails, vs. when mounting the real thing you in fact want to mount. In both cases we're mounting a filesystem, and can introspect the result.
<niemeyer> Chipaca: Also, when do we do that?  Every time we're trying to install anything?  Everytime we start?  What if the kernel changes and squashfs stops being supported?
<niemeyer> Chipaca: My gut feeling is to introspect the system and have good feedback on the real operation, instead of the fake one preceding it
<Chipaca> niemeyer: that would still come after the download (and is a rather large amount of work)
<Chipaca> i mean, it's not just looking errno codes up in the manpage
<Chipaca> it's looking at 'systemd show', probably
<Chipaca> ('systemctl show' i meant -- 'systemctl status's machine-friendly cousin)
<Chipaca> - Mount snap "core" (4110) ([start var-lib-snapd-snap-core-4110.mount] failed with exit status 1: Job for var-lib-snapd-snap-core-4110.mount failed.
<Chipaca> See "systemctl status var-lib-snapd-snap-core-4110.mount" and "journalctl -xe" for details.
<Chipaca> )
<Chipaca> ^ that's what's there now
<niemeyer> Chipaca: [niemeyer@nomad ~]% sudo mount -t squashfs /tmp /tmp
<niemeyer> mount:  /tmp is not a block device
<niemeyer> [niemeyer@nomad ~]% sudo mount -t blah /tmp /tmp
<niemeyer> mount: unknown filesystem type 'blah
<Chipaca> niemeyer: we don't call mount ourselves
<Chipaca> niemeyer: if we were doing so, getting the error reason would be easier
<niemeyer> Chipaca: The point is that it seems rather simple to tell whether the system supports it or not
<Chipaca> niemeyer: 'exit status 1' is a lot less information than checking errno == ENODEV
<Chipaca> niemeyer: I'm assuming there is more information somewhere in the guts of systemctl, such that 'systemctl show' with the appropriate --property would let us figure out that it's ENODEV
<Chipaca> niemeyer: if not, then Â¯\_(ã)_/Â¯
<niemeyer> Chipaca: Sorry.. I don't really understand what the goal is anymore..
<Chipaca> niemeyer: did you see the error we're currently giving users when their system doesn't support squashfs
<niemeyer> Chipaca: Are you saying that shipping a dummy squashfs and performing real system calls ot mount it and checking the result is simpler than calling a function and checking its result?
<Chipaca> niemeyer: which function?
<niemeyer> mount("/tmp", "/tmp", "squashfs", MS_MGC_VAL, NULL) = -1 ENOTBLK (Block device required)
<Chipaca> where would we do that?
<niemeyer> Chipaca: Wherever you want?
<niemeyer> Chipaca: release.SupportsSquashfs?
<Chipaca> niemeyer: on the snap itself, once downloaded? to be umounted immediately after?
<niemeyer> Chipaca: Which snap? Download what? I'm lost...
<niemeyer> Chipaca: Isn't the goal to check if squashfs is supported?
<Chipaca> niemeyer: what are you mounting?
<niemeyer> Chipaca: Nothing... /tmp
<niemeyer> Chipaca: /not-something-relevant-or-dangerous
<Chipaca> niemeyer: but it's not going to be a squashfs
<niemeyer> Chipaca: It does not matter what it is.. this is checking whether squashfs is supported
<niemeyer> Chipaca: The result when it is supported is different from when it is not supported
<niemeyer> If that's the goal, that's a handful of lines in a function
<zyga-ubuntu> re (briefly)
<niemeyer> Chipaca: Or so I assume.. I haven't tested this on a system that does not in fact support squashfs.. I assume the metadata that describes how to mount the filesystem lives in its module.
<Chipaca> niemeyer: so, there's a more minor issue, and that's that this won't tell you if it supports xz
<Chipaca> niemeyer: but you're right that this would work if that's good enough
<Chipaca> (we've had people not enabling xz, but it's probably an order of magnitude less than people without squashfs)
<niemeyer> Chipaca: For that I'd indeed resort to checking the result of the operation instead of preempting what the operation supposedly looks like ahead of itme
<Chipaca> niemeyer: I'm not sure what you mean, there
<niemeyer> Chipaca: If we change the compression format (or more likely, support many), we don't want to have an empty squash per compression format
<niemeyer> Chipaca: Or per whatever feature
<pedronis> what about /proc/filesystems
<Chipaca> pedronis: not there if the module exists but isn't loaded
<niemeyer> pedronis: !!!
<pedronis> Chipaca: well if nobody loads it we fail anyway, no?
<pedronis> mount() would have the same problem I suppose
<Chipaca> pedronis: mount knows to load modules, if you specify the type
<niemeyer> Ah
<pedronis> mount the syscall?
<Chipaca> yes
<Chipaca> I think it's via an alias (metadata in the .ko) to "fs-<the argument to -t>", but i'm not 100% on that
<Chipaca> a bit like how pci modules have aliases to some gibberish 'pci:v00001180d00000822sv*sd*bc*sc*i*' so they get picked up automatically
<pedronis> Chipaca: I think basically it seems we can use mount to detect if squashfs is there, but if the compression is not right
<pedronis> we still need to dig into the systemd job errors
<niemeyer> Chipaca, pedronis: Still sounds nice to go through the actual method:
<Chipaca> I need to see if that still works with the module-exists-but-not-loaded
<niemeyer> 1. Does it exist in /proc/filesystems => do nothing, works
<Chipaca> but sounds good
<niemeyer> 2. insmod squashfs => works? okay
<niemeyer> 3. unsupported
<Chipaca> eh.. i wouldn't have snapd doing insmod, no (but i'm fine with triggering it via mount)
<niemeyer> modprobe actually, not insmod, sorry
<niemeyer> Chipaca: Yeah, that's likely cleaner
<mup> PR snapcraft#2000 opened: elf: remove dead code <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2000>
<muravey_omsk> zyga-ubuntu: My snapcraft.yaml https://pastebin.com/sKkUBwDd
<muravey_omsk> what about add "organize" key to snapcraft.yaml with replace /usr/share/game to $SNAP/usr/share ?
<zyga-ubuntu> re, sorry, my system crashed on kernel bug
<zyga-ubuntu> muravey_omsk: can that game be modified to load things from a config file, variable of some kind?
<zyga-ubuntu> muravey_omsk: if not we will have a new feature in snapd 2.32 that you can use to put those files in /usr/share/game
<muravey_omsk> zyga-ubuntu: i don't know. It's need to read man or Compiling.md
<zyga-ubuntu> muravey_omsk: you can read about it here: https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471
<zyga-ubuntu> muravey_omsk: today edge is "busy" with release process but you can use it in edge soon
<zyga-ubuntu> mvo: I will be home soon, my system crashed and took all the debug state along with it
<zyga-ubuntu> mvo: darn kernel :-(
<zyga-ubuntu> Chipaca: remember about the container use case
<zyga-ubuntu> Chipaca: where squashfs is present but we cannot use it
<zyga-ubuntu> Chipaca: and we must use the internal fuse helper
<Chipaca> zyga-ubuntu: I've forgotten already
<cachio> zyga-ubuntu, selinux is showing denials for the fakestore in the google instace of fedora 27
<zyga-ubuntu> cachio: are those breaking or just warning?
<cachio> zyga-ubuntu, should add a rule to allow it in data/selinux?
<cachio> zyga-ubuntu, giving permission denied
<zyga-ubuntu> cachio: I don't know really, someone needs to sit down and see what the warnings are about
<cachio> type=AVC msg=audit(1520876348.249:536): avc:  denied  { execute } for  pid=31385 comm="(akestore)" name="fakestore" dev="sda1" ino=23835 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
<zyga-ubuntu> cachio: yes but we have some special things that make all the denials into warnings
<zyga-ubuntu> I don't really know the details
<zyga-ubuntu> cachio: is this a new thing?
<cachio> zyga-ubuntu, yes
<cachio> it is the new image we have in google backend
 * kalikiana heading out o/
<Chipaca> zyga-ubuntu: what container does this? so i can play with it
<cachio> the config is the same that the one in linode
<zyga-ubuntu> do we know how is this different from the old image?
<zyga-ubuntu> Chipaca: just LXD is fine
<Chipaca> zyga-ubuntu: ah, not fedora-cloud-in-lxc-trusty? :-)
<zyga-ubuntu> cachio: something about it is wrong but not sure what
<zyga-ubuntu> well
<zyga-ubuntu> not wrong, just different
<zyga-ubuntu> Chipaca: no I mean just xenial+xenial is fine to show this
<zyga-ubuntu> the fedora cloud issue was different
<cachio> the image in linode is created upgrading an old one
<zyga-ubuntu> we just had no module for the kernel we booted on
<Chipaca> Ill need to write this down
<Chipaca> â¦ tomorrow
<zyga-ubuntu> Chipaca: :-)
<cachio> zyga-ubuntu, the one in google was downloded
 * zyga-ubuntu resumes debugging
 * Chipaca is wrapping up for the day
<cachio> so I think could be many differences
<zyga-ubuntu> cachio: sure I'm saying I don't know what's the real problem and this needs some investigation
<zyga-ubuntu> perhaps in the old image the fake store ran unconfined
<zyga-ubuntu> no idea
<cachio> zyga-ubuntu, ok, I'll take a look in that case, it is only only one issue remaining for fedora
<zyga-ubuntu> cachio: ack, I'm sorry I'm not of much help
<cachio> zyga-ubuntu, np
<zyga-ubuntu> cachio: perhaps Pharaoh_Atem can help you faster, he wrote all of the selinux support code
<Pharaoh_Atem> wut?
<zyga-ubuntu> Pharaoh_Atem: selinux denial from fakestore (go implementation of trivial store for tests)
<Pharaoh_Atem> what's the denial?
<zyga-ubuntu> Pharaoh_Atem: they stated showing up when we switched away from linode to google cloud
<zyga-ubuntu>  type=AVC msg=audit(1520876348.249:536): avc:  denied  { execute } for  pid=31385 comm="(akestore)" name="fakestore" dev="sda1" ino=23835 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
<zyga-ubuntu> cachio knows the details
<mup> PR snapcraft#1998 closed: pluginhandler: add {pre,post}-build scriptlets <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1998>
<cachio> Pharaoh_Atem, hey
<cachio> Pharaoh_Atem, https://paste.ubuntu.com/p/Gby6tcmsQn/
<cachio> Pharaoh_Atem, sorry, it is the denial https://paste.ubuntu.com/p/dvBtrhvbKj/
<cachio> it happens running in a google mashine
<cachio> which I recently created downloading from here https://alt.fedoraproject.org/cloud/
<zyga-ubuntu> I suspect it's a config difference
<zyga-ubuntu> but we should check if the kernel is the same as before as well (apart from things like micro release updates)
<cachio> zyga-ubuntu, both configs are identical
<zyga-ubuntu> kernel configs?
<cachio> SELINUX=enforcing SELINUXTYPE=targeted
<zyga-ubuntu> did you compare all of the kernel config of the two running kernels?
<cachio> zyga-ubuntu, sorryselinux configs
<zyga-ubuntu> ah
<zyga-ubuntu> well
<zyga-ubuntu> maybe some other changes then
<cachio> I could do that
<zyga-ubuntu> yeah
<zyga-ubuntu> essentially try to guess what is different now
<zyga-ubuntu> maybe the build config is different
<zyga-ubuntu> maybe some selinux policy is custom
<zyga-ubuntu> it's a cloud image after all
<zyga-ubuntu> but really no idea
<cachio> zyga-ubuntu, selinux configuration in kernel config is the same
<cachio> :(
<cachio> zyga-ubuntu, I know
<cachio> which is the diff
<cachio> linode:fedora-27-64 .../tests/main/interfaces-snapd-control-with-manage# sestatus -v
<cachio> SELinux status:                 disabled
<cachio> google:fedora-27-64 .../tests/main/interfaces-snapd-control-with-manage# sestatus -v
<cachio> SELinux status:                 enabled
<cachio> :s
<cachio> zyga-ubuntu, is it on porpouse?
<zyga-ubuntu> mvo: this issue is driving me crazy
<Pharaoh_Atem> cachio: it's because of this: https://pagure.io/Fedora-Council/tickets/issue/99
<Pharaoh_Atem> our images are based on the version of the image with no SELinux support
<cachio> Pharaoh_Atem, ok
<cachio> Pharaoh_Atem, so is it possible to add a rule to make the fakestore run unconfined?
<Pharaoh_Atem> so this means that for the first time ever, we're going to see failures consistent with users
<Pharaoh_Atem> is fakestore a snap or something else?
<cachio> it is a systremd service
<Pharaoh_Atem> I mean, how is it getting on there?
<cachio> it is not a snap
<Pharaoh_Atem> ah
<Pharaoh_Atem> is the code somewhere?
<cachio> exactly
<cachio> in the snapd project
<Pharaoh_Atem> guh
<Pharaoh_Atem> it's not part of snapd itself, is it?
<cachio> https://github.com/snapcore/snapd/tree/master/tests/lib/fakestore
<cachio> Pharaoh_Atem, no
<cachio> Pharaoh_Atem, we setup it for each test when it is required
<cachio> https://github.com/snapcore/snapd/blob/master/tests/lib/store.sh#L50
<Pharaoh_Atem> the systemd service needs the following added
<Pharaoh_Atem> SELinuxContext=unconfined_t
<cachio> Pharaoh_Atem, great, I'll try with that
<Pharaoh_Atem> ah sorry
<Pharaoh_Atem> it needs fully qualified context
<Pharaoh_Atem> that's "system_u:system_r:unconfined_t:s0", I believe
<Pharaoh_Atem> cachio: if "unconfined_t" doesn't work, try the above
<cachio> SELinuxContext=system_u:system_r:unconfined_t:s0
<Pharaoh_Atem> the documentation isn't clear if just declaring the type is enough
<cachio> Pharaoh_Atem, I'll try one by one in that case
<Pharaoh_Atem> thanks
<om26er> popey: could you please merge this https://github.com/snapcrafters/sublime-text/pull/8 -- flexiondotorg seems away.
<mup> PR snapcrafters/sublime-text#8: Remove '3' from snap name <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/8>
<Pharaoh_Atem> normally, just defining the type is enough, because everything else is inherited
<muravey_omsk> hey, how to debug or find a problem with fonts at my snap app?
 * zyga-ubuntu looks at sublime-text-3 PR
<popey> om26er: is that really desired? I mean, we already have sublime-text-3, why not just create sublime-text-2?
<om26er> popey: the suggestion from zyga-ubuntu (and others) was to use a single name  and make use of 'tracks'
<zyga-ubuntu> yes
<popey> Not sure it's worth it, given how few updates there are. Having two snaps also means you can have both installed should you want to
<zyga-ubuntu> popey: that will be available too
<zyga-ubuntu> though I doubt that is something that people really want in _this_ case
<zyga-ubuntu> popey: I think it's better to use 2.x track for the old sublime-text and the latest track for what's out there now
<popey> I am unconvinced.
<zyga-ubuntu> (especially since we could use edge for the dev builds)
<zyga-ubuntu> popey: I think this also shows the nice features of snap design
<zyga-ubuntu> where developers can release multiple tracks nicely
<popey> flexiondotorg: ^ what do you think?
<om26er> (side question: is there no change needed to snapcraft.yaml for a track ?)
<popey> if we use build.snapcraft.io we can only push to edge, and then release to tracks/channels
<om26er> popey: in case of sublime, we have two separate download urls, so how do we upload the _old_ version (aka 2.X) ?
<zyga-ubuntu> om26er: just release to other track
<zyga-ubuntu> om26er: snap info mysql (the same way)
<om26er> cool but how do I update a version 2 snap ? Do I change my yaml file manually, create a build and upload it with snapcraft cli ?
<om26er> s/update/upload
<popey> you can have two projects in github
<popey> one for 3, one for 2
<popey> both push to the same edge channel though
<zyga-ubuntu> re
<zyga-ubuntu> my kernel crashed again :/
<zyga-ubuntu> bionic is not happy
<mup> PR snapd#4820 opened: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <https://github.com/snapcore/snapd/pull/4820>
<mup> PR snapd#4817 closed: overlord:  implement policy of holding refreshes for up to 6h since seeding on classic <Critical> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/4817>
<Chipaca> slangasek: question about today's live cd
<Chipaca> zyga-ubuntu: you still around?
<zyga-ubuntu> Yes
<zyga-ubuntu> Chipaca: how can I help
<Chipaca> zyga-ubuntu: ah drat, i just closed it, give me a bit to start it up again
<Chipaca> zyga-ubuntu: snap-confine error on today's live cd, about it not running to prevent escalation attacks or sth
<pedronis> Chipaca: which snapd version is on that?
<Chipaca> 2.31.sth iirc
<zyga-ubuntu> Hmmmm
<Chipaca> booting still
<muravey_omsk> hey, could you help me, again?
<pedronis> there were some fixes for livecd but IÂ don't know if they are related/when then landed
<muravey_omsk> smirnovav@techadm03:/home/smirnovav/snap/cataclysm-dda$ locale
<muravey_omsk> locale: Cannot set LC_CTYPE to default locale: No such file or directory
<muravey_omsk> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
<zyga-ubuntu> I think that doesnât have the fix yet
<muravey_omsk> locale: Cannot set LC_ALL to default locale: No such file or directory
<zyga-ubuntu> Only master has that fix Chipaca
<Chipaca> zyga-ubuntu: ah ok
<pedronis> Chipaca: in other news IÂ should have squashed #4789 when merging and didn't :/
<mup> PR #4789: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4789>
 * muravey_omsk interesting in how to paste small command output? Pastebin?
<Chipaca> pedronis: and now?
<zyga-ubuntu> Yes
<zyga-ubuntu> Pastebin
<pedronis> Chipaca: IÂ don't know, will not be fun to merge into 2.32 I suppose
 * Chipaca hugs mvo
<pedronis> I'll see in the morning, anyway IÂ also saw I can simplify the follow-up
<muravey_omsk> https://pastebin.com/vy1WB7Hk
<muravey_omsk> What am I doing wrong?
<muravey_omsk> my program do not see my locale and don't show messages on my language
<fireclawTheFox> Hey everyone, can someone help me get the desktopfile of my snap package show up in the dash? I've tried quite a lot of things but none have helped so far.
<popey> fireclawTheFox: hiya
<popey> fireclawTheFox: can you link to your yaml maybe?
<popey> Note that some desktops have bugs that require you to logout/back in to make the icon appear
<fireclawTheFox> Hey popey, sure, here's the yaml: https://bazaar.launchpad.net/~fireclawthefox/thetravelingfox/snap/view/head:/snap/snapcraft.yaml
<popey> fireclawTheFox: ah, easy one, name your .desktop file the same as the snap
<popey> so thetravelingfox.desktop
<mup> PR snapd#4813 closed: release: snapd 2.31.2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4813>
<fireclawTheFox> popey: I thought it already fits the name as the snap also is also named the-traveling-fox
<popey> oh, you're right. huh.
<fireclawTheFox> I've also tried naming it the-traveling-fox_the-traveling-fox as well as directly add it in the yaml file using desktop:
<popey> lemme take a better look, one moment
<mvo> zyga-ubuntu: yeah, its rather unfortunate
<mvo> zyga-ubuntu: my latest PR seems to get a step further, but it now fails in interfaces-content-mkdir-writable:snap
<popey> fireclawTheFox: the snap fails to build here. Do you rely on having PPAs or something enabled?
<fireclawTheFox> I don't rely on PPAs, just on a pipy package. Which version of snapcraft do you use? I've just pushed a version of my custom plugin to make it build on the version used on LP.
<popey> snapcraft, version 2.39.2
<popey> on 16.04 (well, I'm doing snapcraft cleanbuild)
<popey> I need to disappear soon to get my daughter from dancing, if we don't fix it here, I'd recommend a thread on the forum
<fireclawTheFox> ok, then the x-panda3d.py script has to be changed for that version
<popey> ahh
<fireclawTheFox> I've once opened up a thread in the forums but it didn't got much attention.
<fireclawTheFox> Anyways, in the x-panda3d.py script just two things have to be changed, first enable the code from line 38 and disable line 49 to 54 as well as switch line 78 and 79
<cachio> Pharaoh_Atem, no way
<cachio> didn't work
<Pharaoh_Atem> :'(
<cachio> it is rejecting to set the type as unconfined_t aparently
<popey> fireclawTheFox: ok, lemme rebuild and see
<cachio> Pharaoh_Atem, even if I do it manually with chcon
<Pharaoh_Atem> hmm
<Pharaoh_Atem> it's probably not letting you transition domains from init_t to unconfined_t
<cachio> any other idea to exec that file?
<cachio> Pharaoh_Atem, create a new test domain to set as permissive?
<popey> fireclawTheFox: ok, that built! :D
<Pharaoh_Atem> either that or just set the VM to permissive while running the tests
<fireclawTheFox> awesome
<Pharaoh_Atem> and collecting the audit results
<popey> fireclawTheFox: ah, your exec line is wrong
<popey> fireclawTheFox: the exec line should not be launching the command name, but the app name
<popey> exec=the-traveling-fox
<fireclawTheFox> popey: ah, yeah now that you say it, makes sense.
<popey> also, add this
<popey> https://www.irccloud.com/pastebin/XsBC54Nc/
<popey> to the game part
<popey> that will put the pulseaudio library in an accessible place
<popey> oh, you mung the LD_LIBRARY_PATH... never mind
<popey> also if you put libs in $SNAP/lib you won't need to "cd ${SNAP}"
<popey> because $SNAP/lib is automagically in the path
<zyga-ubuntu> mvo: I will check your pull request tomorrow. Spending time with homework and kids
<mvo> zyga-ubuntu: sure, thats fine, I had some strange results, I suspect there is also the cache (apparmor cache) that is making things compilicated
<mvo> zyga-ubuntu: I will let the tests run over night, fingers crossed
<fireclawTheFox> popey: sorry, my laptop just crashed, did you wrote anything after (22:16:58) popey: oh, you mung the LD_LIBRARY_PATH... never mind
<mvo> zyga-ubuntu: lets talk tomorrow :)
 * mvo waves
<popey> fireclawTheFox: no
 * cachio afk
<fireclawTheFox> popey: just got the snap built, the desktop file works fine now, thanks so much for your help.
<popey> Yay
<popey> Good. Looking forward to playing it
#snappy 2018-03-13
<jaitaiwan> Hey folks, just wondering if snaps are supposed to be apart of your $PATH by default or if there's some sort of setup steps I'm missing before using CLI snaps
<nacc> jaitaiwan: /etc/profile.d/apps-bin-path.sh on ubuntu (from snapd)
<mborzecki> morning
<mup> PR snapd#4800 closed: cmd/snap: in changes and tasks, default to human-friendly times <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4800>
<zyga-ubuntu> good morning
<zyga-ubuntu> jaitaiwan: hey, it's supposed to be automatic but if you just installed the snapd package you may need to reboot / log out for the changes to take effect
<zyga-ubuntu> mvo: good morning
 * zyga-ubuntu was up at 6AM but $KIDS needed more help today
<mvo> zyga-ubuntu: hey, good morning
<zyga-ubuntu> man, this bug is more elusive than we thought :/
<mvo> zyga-ubuntu: yeah, I was thinking it was caching
<mborzecki> zyga-ubuntu: mvo: morning guys
<zyga-ubuntu> mvo: did you get to a point where you can reproduce it on your machine?
<mvo> hey mborzecki
<mvo> zyga-ubuntu: I did manage that
<zyga-ubuntu> mvo: and if so did you have to run all of main or was a subset sufficient?
<zyga-ubuntu> mborzecki: hey! :)
<mvo> zyga-ubuntu: I have to run all
<zyga-ubuntu> mvo: I tried just the cgroup tests and I was "lucky"
<mvo> zyga-ubuntu: I managed to get into a shell last night and changed the profile and reload and then things were good again
<zyga-ubuntu> mvo: so just *one* test (with sub-tests)
<mvo> zyga-ubuntu: I suspect its something subtle like the cache
<zyga-ubuntu> ok, I can try disabling all of the cache
<mvo> zyga-ubuntu: oh, just the cgroup tests, cool
<zyga-ubuntu> and see if that helps
<mvo> zyga-ubuntu: sounds great, how do you disable the caches?
<mvo> zyga-ubuntu: I rm -f them in my PR but that is not enough
<zyga-ubuntu> mvo: apparmor_parser explicitly controls this so we'd have to pass some options in a few places, the patch should be minor
<zyga-ubuntu> mvo: the only exception is /etc/init.d/apparmor
<zyga-ubuntu> but I _think_ we can ignore that
<zyga-ubuntu> because it just runs once on boot
<zyga-ubuntu> hmm hmm
<zyga-ubuntu> but then again, some tests do reboot
<zyga-ubuntu> I'll focus on the cgroup test
<zyga-ubuntu> and on disabling cache
<zyga-ubuntu> maybe it will show us something usefil
<zyga-ubuntu> oh
<mvo> zyga-ubuntu: is there magic to dump a profile from memory? i.e. to see if the in-memory state matches the on disk state?
<zyga-ubuntu> and I have a small patch, though not a bug fix, related to what I did yesterday
<zyga-ubuntu> yes
<zyga-ubuntu> ish
<zyga-ubuntu> you can dump the profile from memory
<zyga-ubuntu> hold on, I will show you how
<mvo> zyga-ubuntu: cool, when I am in the broken state I will try that
<zyga-ubuntu> mvo: it's not easy or useful without some extra tools
<zyga-ubuntu> mvo: you can go to /sys/kernel/security/apparmor/policy/raw_data/
<zyga-ubuntu> (raw_data is a magic symlink which behaves as a magic directory)
<zyga-ubuntu> then you will see a lot of numbers
<zyga-ubuntu> each time you insert a new profile you get a new number (including replaces I think)
<zyga-ubuntu> then you can see the raw_data file inside the number directory
<zyga-ubuntu> now
<zyga-ubuntu> this doesn't match the cache I think
<zyga-ubuntu> but there is a way to compile a profile and get the raw data
<zyga-ubuntu> from apparmor_parser that is
<zyga-ubuntu> so with some tooling we might compile all the profiles from disk
<zyga-ubuntu> to get their raw_data
<zyga-ubuntu> and compare that to the raw_data that the kernel knows about
<zyga-ubuntu> and in the end try to match files to loaded profiles
<zyga-ubuntu> I wrote a decompiler for the raw_data format a while ago
<zyga-ubuntu> but did not manage to get the most interesting part of the policy
<zyga-ubuntu> that is the set of regular exressions and matching permissions
<zyga-ubuntu> I do get profile names and a lot of other things out though
<zyga-ubuntu> the format is not documented well, I did this by following the kernel code that parses the binary profiles
<zyga-ubuntu> so, that's that, not sure if useful
<mvo> zyga-ubuntu: uh, ok
<zyga-ubuntu> *fun* :-)
<mvo> zyga-ubuntu: yeah
<zyga-ubuntu> the format is not hard either
<zyga-ubuntu> it's mostly tagged strutures and some tables
<zyga-ubuntu> the devil is in the details
<zyga-ubuntu> and the yet-not-understood (by me) format to which the DFAs are compiled
<zyga-ubuntu> it's also coupled with some compression
<zyga-ubuntu> mvo: though having such a decompiler would be very useful as it's our backbone in many ways
 * mvo nods
<pstolowski> mornings
<zyga-ubuntu> hey hey
<mvo> zyga-ubuntu: so you reproduced it without the core transition tests? I suspected those might be the culprits :/
<zyga-ubuntu> yes, I did
<zyga-ubuntu> I'm running another pass now
<zyga-ubuntu> I'm tweaking prepare/restore debugging
<mvo> zyga-ubuntu: ta
<mup> PR snapd#4821 opened: tests: define MATCH from spread <Created by zyga> <https://github.com/snapcore/snapd/pull/4821>
<mvo> zyga-ubuntu: I replied to your question about the system-key
<mvo> zyga-ubuntu: let me know if that is reasonable, if not happy to have a quick HO to discuss
<zyga-ubuntu> thanks, looking
<mvo> zyga-ubuntu: my theory is essentially that during one of the tests we generate/load a snap.core.*.snap-confine profile from the real core in edge instead of from our modified core
<mvo> zyga-ubuntu: and never undo this
<zyga-ubuntu> hmm hmm
<mvo> zyga-ubuntu: and then things fall apprt
<zyga-ubuntu> can you explain when system key would be stale and we would not regenerate it?
<mvo> zyga-ubuntu: and also its super confusing because we restore the profile *on-disk* (via tar) but of course do not reload
<zyga-ubuntu> ahh
<mvo> zyga-ubuntu: the core snap is 4422 (or whatever)
<mvo> zyga-ubuntu: that is the one in edge
<zyga-ubuntu> maybe as a part of restore we can do apparmor_parser -r /some/path/*
<mvo> zyga-ubuntu: and also the one we "hack"
<mvo> zyga-ubuntu: yes, that could be it
<zyga-ubuntu> I just ran the cgroup tests and they didn't fail
<zyga-ubuntu> your patch from yesterday (the 1st one) makes it less likely things break
<mvo> zyga-ubuntu: the core transition tests will (most) definitely do that, use the "real" edge with the "wrong" snap-confine profile and load that
<mvo> zyga-ubuntu: yeah
<zyga-ubuntu> I'll run the core transition tests and the cgroup test in sequence now
<zyga-ubuntu> mvo: so to get back to the PR with the system-key question
<mvo> zyga-ubuntu: I suspect that we will see the error now in the 2.32 branch only, edge is up-to-date with core again so the apprmor profiles are essentially the same
<mvo> zyga-ubuntu: sure
<zyga-ubuntu> if I understand you correctly, you are saying that because we remove system key we trigger profile loads
<mvo> zyga-ubuntu: correct
<zyga-ubuntu> yeah, I work on the release branch all the time
<zyga-ubuntu> mvo: I would strongly prefer if this was a bit less magic and more organized
<mvo> zyga-ubuntu: we *could* also force this in restore as a big hammer
<zyga-ubuntu> there's a lot of voodoo in our scripts
<mvo> zyga-ubuntu: I think we are all in agereement about this :)
<mvo> zyga-ubuntu: part of the problem is that the problem domain itself is confusing, I mean, re-exec make things confusing and we do some strange things in the suite
<mvo> zyga-ubuntu: if we could rely on snapshots, that would be best
<zyga-ubuntu> yeah, no question about that, a snapshot (though at a right time, this is tricky too) would be wonderful
<mvo> zyga-ubuntu: or some way to ensure that prepare/restore really go back to a pristine state but given the amount of things that could change (apparmor profiles in memory, kernel bootloader vars, on-disk state) this is really hard
<zyga-ubuntu> ahem
<mvo> zyga-ubuntu: haha
 * mvo hugs zyga-ubuntu 
<zyga-ubuntu> https://github.com/snapcore/spread/pull/47
<mup> PR spread#47: Add support for project-wide measure-each stanza <Created by zyga> <https://github.com/snapcore/spread/pull/47>
<mvo> zyga-ubuntu: do you feel better today?
<zyga-ubuntu> mvo: yes, less coughing :)
<mvo> zyga-ubuntu: I remember this one!
<zyga-ubuntu> I wish we could just land it
<mborzecki> could we dump the profiles, clean the state  in prepare/restore each steps instead of just the selected tasks?
<mvo> zyga-ubuntu: btw when I use less leaves from your tea its not so strong, I like this better
<zyga-ubuntu> mborzecki: I think part of the problem is how our prepare/restore is organised, it's not really prepare and restore
<zyga-ubuntu> prepare does restore internally
<zyga-ubuntu> and restore is mostly a no-op
<mvo> mborzecki: I think the profile restore is something to explore, I'm try to reproduce now again and then will add it
<mvo> zyga-ubuntu: yeah, this part is also slightly terrible
<zyga-ubuntu> mvo: yeah, I also use the same set of leaves throughout the day, it's easily good enough for 2-3 infusions
<zyga-ubuntu> mvo: I'm fixing that now
<mvo> zyga-ubuntu: \o/
<zyga-ubuntu> mvo: the MATCH pr is the first step now
<zyga-ubuntu> chipaca had this idea some months ago
<zyga-ubuntu> mvo: I'm making it so that prepare really prepares (applies tarball) and restore really cleans up
<zyga-ubuntu> using the measure feature to ensure it's happening for real
<zyga-ubuntu> though it will be a few PRs to review
<zyga-ubuntu> mvo: what I found interesting is places that are not covered by the tarball
<zyga-ubuntu> like various caches
<zyga-ubuntu> like the apparmor cache you started cleaning now
<mborzecki> afair apparmor has an in kernel db so even if you clean the cache, the rules may still be there right?
<zyga-ubuntu> yes
<zyga-ubuntu> totally
<zyga-ubuntu> that is another thing we should clean
<zyga-ubuntu> but it's not trivial as we really want to restore the right state
<zyga-ubuntu> not discard it
<zyga-ubuntu> part of the state is "competed" by the Apparmor init script
<zyga-ubuntu> it will parse, compile, cache and load all the profiles
<mborzecki> clean by rebooting :)
<zyga-ubuntu> haha
<zyga-ubuntu> yeah ;)
<zyga-ubuntu> mvo: I ran core transition and security cgroups and it passed :/
<zyga-ubuntu> (I don't have your branch in yet)
<zyga-ubuntu> hey chihchun_afk :-)
<zyga-ubuntu> mvo: would the edge being really newer affect the failure rate in the release branch?
<mborzecki> zyga-ubuntu: otoh reboot is pretty much instant with the cloud images running under qemu
<itsfemme[m]> is there a way to search for free software snaps?
<zyga-ubuntu> itsfemme[m]: yes though it's not exposed in the UI yet AFAIK
<itsfemme[m]> got a URL?
<zyga-ubuntu> no
<zyga-ubuntu> it's just implemented on the store now
<mvo> zyga-ubuntu: yeah, the fact that edge is now in sync (more or less) with master means even with the "wrong" profiles being loaded things are ok because the profile in edge is pretty much identical
<mvo> zyga-ubuntu: I have some hopes in release/2.32 but its only on 22/232 and ok so far
<mvo> zyga-ubuntu: I run one with just the cgroups now
<zyga-ubuntu> mvo: can we do an experiment that would not affect master
<zyga-ubuntu> mvo: publish 2.31 in some channel
<zyga-ubuntu> and I can run tests against that channel
<zyga-ubuntu> I want to nail the issue, not hide it till next time
<mvo> zyga-ubuntu: again, we are in agreement, lets nail it
<mvo> zyga-ubuntu: I would need a track to publish 2.31 (or a branch). I think I need store support for this
<zyga-ubuntu> yes,
<zyga-ubuntu> perhaps pedronis and noise][ can arrange that
<mup> PR snapd#4815 closed: tests: fix re-exec profile generation in tests on classic <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4815>
<pedronis> I cannot create tracks, but for sure store can help with a track or branch
<mwhudson> do i want to think about why downloading snaps is way slower inside a lxd than outside?
<zyga-ubuntu> proxy settings not used?
<zyga-ubuntu> how much slower is slower?
<zyga-ubuntu> mvo: do you want to keep https://github.com/snapcore/snapd/pull/4814/files ?
<mup> PR #4814: tests: fix re-exec profile generation in tests on classic (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4814>
<mvo> zyga-ubuntu: for now, I want to see if it breaks and in what way
<zyga-ubuntu> ok
<mvo> zyga-ubuntu: I will set it to blocked if the tests pass
<mvo> zyga-ubuntu: I think the first commit is actually correct and should land but the rest is dubious
<mvo> zyga-ubuntu: also, the first commit is not sufficient (as we established) so :(
<mborzecki> anyone wants to take a look at #4781?
<mup> PR #4781: wrappers: refactor desktop file sanitizer to support autostart files <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4781>
<mvo> zyga-ubuntu: yay, now I have the bug in the 2.32 PR
<zyga-ubuntu> !!
<zyga-ubuntu> where?
<mvo> zyga-ubuntu: in the fix-reexec-snap-confine-profile-generateion (2.32 based) branch
<mvo> zyga-ubuntu: in canonical-livepatch
<mvo> zyga-ubuntu: the on-disk profile is correct AFAICT
<mvo> zyga-ubuntu: but I get an error
<zyga-ubuntu> if you reload the profile
<zyga-ubuntu> is that fixing things?
<zyga-ubuntu> I assume you have a shell now
<mvo> zyga-ubuntu: just reloading does not help
<zyga-ubuntu> ok, what is the denial you see
<mvo> zyga-ubuntu: *but* changing the profile (adding a whitespace) and reloading
<mvo> zyga-ubuntu: fixes it
<zyga-ubuntu> exactly the same as before?
<zyga-ubuntu> oooooooh
<zyga-ubuntu> so caching?
<mvo> zyga-ubuntu: yeah, looks very much like it
<zyga-ubuntu> head.wall()
<mvo> zyga-ubuntu: its "funny", I had this discussion back in the click days iirc, that the cache should use more data than just the mtime :/
<mvo> zyga-ubuntu: I suspect it is something like "a new aa profile is written; profile is cached; we restore to the previous aa profile in the restore step; the apparmor-parser sees that the mtime of the cache is nwewer than the mtime of the profile -> does nothing"
<zyga-ubuntu> yeah
<zyga-ubuntu> that's very likely
<mvo> zyga-ubuntu: the question is how to nuke all apparmor caches
<zyga-ubuntu> one sec
<mvo> zyga-ubuntu: i.e. what to do short term, then what to do longer term
<zyga-ubuntu> I have a patch for the nuclear option
<mvo> zyga-ubuntu: bring it on!
<mvo> pedronis: are you working on a backport of the refrsh hold PR that was recently merged? or shall I have a look?
<mvo> pedronis: fwiw, 2.32 is blocked right now on this apparmor caching bug zyga-ubuntu and I are chasing
<pedronis> mvo: I will work on it,  I forgot to squash it though, so it will be a bit annoying
<pedronis> mvo: it needs a follow up anyway, with the actual policy (which is what I'm working on right now, IÂ had a variant yesterday but I had some ideas to simplify it a bit)
<mvo> pedronis: cool, please let me know if I can help in any way
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4822
<mup> PR #4822: interfaces/apparmor: skip apparmor cache <Created by zyga> <https://github.com/snapcore/snapd/pull/4822>
<zyga-ubuntu> mvo: just for consideration
<zyga-ubuntu> I wonder what will happen
<mup> PR snapd#4822 opened: interfaces/apparmor: skip apparmor cache <Created by zyga> <https://github.com/snapcore/snapd/pull/4822>
<mvo> zyga-ubuntu: lets run that against 2.32 and we will know :)
<zyga-ubuntu> ah, sorry, I'll make a 2.32 variant
<zyga-ubuntu> mvo: the backport is https://github.com/snapcore/snapd/pull/4823
<mup> PR #4823: interfaces/apparmor: skip apparmor cache <Created by zyga> <https://github.com/snapcore/snapd/pull/4823>
<mup> PR snapd#4823 opened: interfaces/apparmor: skip apparmor cache <Created by zyga> <https://github.com/snapcore/snapd/pull/4823>
<mvo> zyga-ubuntu: cool, lets see what the tests say
<zyga-ubuntu> just in case the smoking gun is found
<zyga-ubuntu> what do we do
<zyga-ubuntu> fix apparmor parser caching ourselves?
<mvo> zyga-ubuntu: its mostly test related, I think we fix the tests and "gently" remind the team that the apparmor caching could need some love
<mvo> zyga-ubuntu: I suspect https://bugs.launchpad.net/snappy/+bug/1460152
<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>
<zyga-ubuntu> mvo: I recall we had a spike on error.u.c
<zyga-ubuntu> could that be related?
<mvo> zyga-ubuntu: maybe, but I suspect its different reason, this looks tests related to me still (but maybe I'm wrong)
<zyga-ubuntu> on a related note, can you look at https://github.com/snapcore/snapd/pull/4821
<mup> PR #4821: tests: define MATCH from spread <Created by zyga> <https://github.com/snapcore/snapd/pull/4821>
<zyga-ubuntu> it will help me land small refactors to prepare-restore next
<mvo> zyga-ubuntu: sure, looking
<mvo> zyga-ubuntu: why tail -n +2 ?
<mvo> zyga-ubuntu: what is in the first two lines?
<zyga-ubuntu> thank you
<zyga-ubuntu> https://www.irccloud.com/pastebin/4E4oqQqV/
<mvo> zyga-ubuntu: aha, I see
<mvo> zyga-ubuntu: replied in the PR
<zyga-ubuntu> â¨replied as well
<mvo> ta
<zyga-ubuntu> mvo: I see an error
<zyga-ubuntu> but it makes no sense
<zyga-ubuntu> + MATCH gadget
<zyga-ubuntu> + snap list
<zyga-ubuntu> error: pattern not found, got:
<zyga-ubuntu> Name  Version                   Rev   Tracking  Developer  Notes
<zyga-ubuntu> core  16-2.31.2+git610.7a79b84  4229  edge      canonical  core
<zyga-ubuntu> this is in https://github.com/snapcore/snapd/pull/4822
<mup> PR #4822: interfaces/apparmor: skip apparmor cache <Created by zyga> <https://github.com/snapcore/snapd/pull/4822>
<mup> PR snapd#4768 closed: [RFC] snap userd autostart v2 <Sprint> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4768>
<zyga-ubuntu> mvo: shall I restart?
<zyga-ubuntu> those were in master
<zyga-ubuntu> (not in the 2.32)
<mvo> zyga-ubuntu: yeah, master is probably not it
<zyga-ubuntu> does the error make any sense to you?
<mvo> zyga-ubuntu: does apparmor have more caches except /etc/apparmor.d/cache - do you happen to know?
<Chipaca> very unhappy with the tests state right now :-(
<mvo> zyga-ubuntu: no
<zyga-ubuntu> yes
<zyga-ubuntu> it has two caches
<zyga-ubuntu> one legacy
<mvo> Chipaca: we are as well
<zyga-ubuntu> and one "modern"
 * Chipaca hugs everybody
<zyga-ubuntu> one is in /var/apparmor/cache
<mvo> Chipaca: we are head first diving into it and its not pretty
 * Chipaca is still grumpy tho
<mvo> Chipaca: rightfully so
<zyga-ubuntu> another one is in /etc/apparmor.d/cache AFAIR
<zyga-ubuntu> hey Chipaca :)
<mvo> zyga-ubuntu: thanks
<zyga-ubuntu> why are you grumpy?
<Chipaca> zyga-ubuntu: tests breakage
<zyga-ubuntu> Chipaca: hug the tests
<zyga-ubuntu> :D
<Chipaca> zyga-ubuntu: my huggage would be to feature flag errything
<Chipaca> so maybe not the best approach
<zyga-ubuntu> mvo: any ideas?
<zyga-ubuntu> (caches in /etc are "fun")
<zyga-ubuntu> mvo: shall we restart that PR/
<mvo> zyga-ubuntu: works for me
<mvo> zyga-ubuntu: I'm trying different things in parallel but its seems to be all not quite fixing it :(
<mvo> zyga-ubuntu: I think I am getting annoyed as well
<mvo> Chipaca: master at least should be more happy now, no? tests there?
<zyga-ubuntu> mvo: that's good, this is a great motivation technique
<mvo> Chipaca: because we got a new core overnight
<zyga-ubuntu> mvo: let's merge my MATCH pr (with changes if you wish) and let's reorganise prepare-restore
<Chipaca> mvo: dunno master; #4820 has been red five times already, for everything from layouts to cgroups to network
<mup> PR #4820: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <https://github.com/snapcore/snapd/pull/4820>
<zyga-ubuntu> mvo: and the 2.32 PR failed now
<mvo> Chipaca: oh, right - layout will still be a problem
<zyga-ubuntu> cannot execute snap-update-ns: Permission denied
<mvo> Chipaca: but cgroups should be ok now, did that run today?
<zyga-ubuntu> :-(
<zyga-ubuntu> I don't know what's going on now
<mvo> zyga-ubuntu: meh, that is exactly the failure that I think comes from a stale cache
<zyga-ubuntu> mvo: hold on, maybe the --skip-cache does something silly
 * zyga-ubuntu looks
<Chipaca> mvo: it might've been late yesterday, or today, one side or the other of the date line
<zyga-ubuntu>        -K, --skip-cache
<zyga-ubuntu>            Perform no caching at all: disables -W, implies -T.
<mvo> zyga-ubuntu: also maybe for some reason aa thinks the profile has not changed?
<mvo> Chipaca: ok, just for "fun", please restart
<zyga-ubuntu> mvo: but without any caching how could it decide?
<mvo> Chipaca: if it still fails in the cgroups I will consider start drinking
<zyga-ubuntu> mvo: one more idea
<Chipaca> mvo: i did (and then it failed on another thing)
<mvo> zyga-ubuntu: I have no idea
<zyga-ubuntu> actually, not sure
<mvo> Chipaca: aha, what is this other thing?
<zyga-ubuntu> I wanted to say that we could wrap apparmor_parser
<mvo> zyga-ubuntu: ohhhh
<zyga-ubuntu> oh?
<mvo> zyga-ubuntu: you probably need my first commit
<mvo> zyga-ubuntu: wait a sec
<zyga-ubuntu> kk
<zyga-ubuntu> just push to those PRs
<Chipaca> mvo: a bunch of unrelated stuff like econnreset
<Chipaca> mvo: and now it's failed yet again, this time in suite prepare
<mvo> zyga-ubuntu: I think you need https://github.com/snapcore/snapd/pull/4814/commits/8c065f9f22547497ca0c925009fe1b448ea78045 or you will never have the right profile in the first place
<mup> PR #4814: tests: fix re-exec profile generation in tests on classic (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4814>
<Chipaca> so that's six times
<mvo> zyga-ubuntu: i.e. without that commit the snap-confine profile for core is always incorrect
<zyga-ubuntu> Chipaca: in suite prepare?
 * Chipaca gives up on this programming stuff and goes shopping
<mvo> zyga-ubuntu: with that commit it becomes a caching issue (I think)
<mvo> Chipaca: in prepare suite :(
<mvo> Chipaca: what is the link to the log?
<zyga-ubuntu> mvo: will you push or do you want me to cherry-pick?
<Chipaca> https://api.travis-ci.org/v3/job/352504456/log.txt
<zyga-ubuntu> + tar -C/ -xf /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz
<zyga-ubuntu> tar: /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz: Cannot open: No such file or directory
<zyga-ubuntu> I have no words
<zyga-ubuntu> is there a gnome pissing into the milk
<zyga-ubuntu> and messing up our tests
<Chipaca> zyga-ubuntu: s/gnome/elephant/
<mborzecki> hmm GNOME? :)
<mvo> zyga-ubuntu: if you could cherry-pick
<zyga-ubuntu> sure
<zyga-ubuntu> mvo: pushed,
<zyga-ubuntu> do you think it's worth to try to wrap apparmor_parser
<zyga-ubuntu> and do caching ourselves?
<zyga-ubuntu> we can use apparmor_parser to get the raw data
<zyga-ubuntu> and use any logic we wish to cache or discard the raw data (compiled profiles)
<pedronis> zyga-ubuntu: is the branch just to check if it helps? or is the plan to really turn off the cache?
<zyga-ubuntu> pedronis: just to check
<zyga-ubuntu> (hence the rfc)
<zyga-ubuntu> if the caching system is broken we can work around it
<zyga-ubuntu> I think we really could cache ourselves
<zyga-ubuntu> since the parser gives us the primitives
<pedronis> the rfc?
<pedronis> the description is very not rfcs
<pedronis> but maybe I'm misunderstanding
<Chipaca> mvo: are you still using that log, or can i nuke it?
<mvo> Chipaca: nuke it
<mvo> zyga-ubuntu: thats a nice idea, use our own wrapper at least in the tests to understand things better
<zyga-ubuntu> ok, I'll get to it
<mvo> zyga-ubuntu: but same deal I think all followup work needs https://github.com/snapcore/snapd/pull/4814/commits/8c065f9f22547497ca0c925009fe1b448ea78045 first
<mup> PR #4814: tests: fix re-exec profile generation in tests on classic (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4814>
<mvo> (so that the initial profile is ok)
<zyga-ubuntu> mvo: is this ok? https://github.com/snapcore/snapd/pull/4823
<mup> PR #4823: interfaces/apparmor: skip apparmor cache (2.32) <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/4823>
<mvo> zyga-ubuntu: yes, can't wait to see the result
<mvo> zyga-ubuntu: its also super annoying, spread failed, my local run is still going strong :(
<mvo> zyga-ubuntu: for 4814
<zyga-ubuntu> yeah, it's a day that keeps giving
<zyga-ubuntu> Son_Goku: hey, I have a working F28 chroot now
<zyga-ubuntu> thank you for that!
<mvo> zyga-ubuntu: hm, another problem is that we have ~8 workers, so ideally I would like to know what tests run on exactly the worker that failed. but spread does not give me this info, does it?
<zyga-ubuntu> no, it does not
<zyga-ubuntu> I wish it did
<zyga-ubuntu> a sequence of tests on the worker who failed
<mvo> zyga-ubuntu: yeah, in the travis run it fails after ~70 tests so with 8 works that is not that many that run on each worker
<zyga-ubuntu> mvo: I'll work on a wrapper for the cache
<zyga-ubuntu> just a small prototype
<zyga-ubuntu> to see where this goes
<mvo> ok
<pedronis> can't we keep tab of the relevant raw_hash and see when it changes?
<zyga-ubuntu> pedronis: can you explain please?
<BjornT_> mvo: hi! could you please rebuild and push base-18 to the store again, so that it gets the latest glibc?
<pedronis> zyga-ubuntu:   /sys/kernel/security/apparmor/policy/profiles/usr.lib.snapd.snap-confine.17/raw_hash
<zyga-ubuntu> yeah but that's the hash of the (assuming, I didn't check) blob that comes out of the compiler
<zyga-ubuntu> how does that help with the parser?
<mvo> BjornT_: started a build now
<mvo> BjornT_: https://code.launchpad.net/~mvo/+snap/base-18 <- sorry for the delay
<pedronis> zyga-ubuntu: I assume the parser is deterministic?
 * zyga-ubuntu knocks on wood
<zyga-ubuntu> I hope so
<pedronis> so we can track the values of that and when it changes
<zyga-ubuntu> hold on
<zyga-ubuntu> when what changes?
<pedronis> or also try hold of what we expect to be sane
<zyga-ubuntu> is the idea designed to optimise the cache or to do something else?
<pedronis> zyga-ubuntu: when we load the profile for real  and the profile is different that should change no?
<mvo> pedronis: yeah, we can store the value when the suite starts and fail if the fails, then we can narrow down what test breaks it
<pedronis> zyga-ubuntu: to understand if we have loaded what we expect
<zyga-ubuntu> pedronis: yes, I agree
<BjornT_> mvo: thanks
<mvo> fail if the value changes
<mvo> sorry
<zyga-ubuntu> (this assumes we understand what that value is)
<zyga-ubuntu> there are more hashes there
<zyga-ubuntu> I don't know what they do
<zyga-ubuntu> (yet)
 * zyga-ubuntu is experimenting 
<pedronis> mvo: something like that, to make this a bit tractable
<zyga-ubuntu> pedronis: for debugging yeah
<pedronis> yes, for debugging
<zyga-ubuntu> though it's not super clear how to map that, the profiles are loaded into subsequent slots
<zyga-ubuntu> and each loaded profile is really a set of profiles
<zyga-ubuntu> but I think we can come up with something
<zyga-ubuntu> I have an idea
<zyga-ubuntu> that we can use to make the cache reliable
<zyga-ubuntu> it's essentially the same problem as ccache
<zyga-ubuntu> resolve all imports, use some hash of the full text as key
<zyga-ubuntu> compile the pre-processed text
<zyga-ubuntu> and store that in the cache under that key
<zyga-ubuntu> that's it
<zyga-ubuntu> ccache for apprmor
<pedronis> zyga-ubuntu: afaiu   raw_hash  is the sha1sum of raw_data
<mup> PR snapd#4824 opened: tests: fix re-exec profile generation in tests on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4824>
<zyga-ubuntu> mvo: can you vote on 4821
<zyga-ubuntu> I can make it a stub if that's what you want
<pedronis> zyga-ubuntu: mvo: piece of good news  afaict  (here) : apparmor_parser -S  of the snap_confine profile  |sha1sum produces the same value as raw_hash
<mvo> zyga-ubuntu: I'm a bit on the fence, if there is a use case for it, then lets keep it, otherwise I would say make it a stub (YAGNI and all that)
<zyga-ubuntu> good
<mvo> pedronis: \o/
<zyga-ubuntu> mvo: I can make it a stub
<zyga-ubuntu> mvo: I need it for real stuff after that
<pedronis> mvo: zyga-ubuntu: I mean this:   https://pastebin.ubuntu.com/p/4XGYSmk8zt/
<mvo> zyga-ubuntu: ok, if a stub is enough lets do that (if you don't mind)
<zyga-ubuntu> yes
<zyga-ubuntu> that's fine
<mborzecki> why do we enable the services first and the do a daemon-reload?
<zyga-ubuntu> I'll finish the parser wrapper and do it in a moment
<zyga-ubuntu> mborzecki: huh?
<zyga-ubuntu> that's odd
<mborzecki> https://github.com/snapcore/snapd/blob/master/wrappers/services.go#L244 runs before daemon-reload
<pedronis> mvo: saw I think we could compute the hash in prepare somewhere and fail when it changes (and decide when is expected and what we need to do)
<pedronis> s/saw/so/
<mup> PR snapd#4825 opened: overlord/snapstate:  implement policy of holding refreshes for up to 6h since seeding on classic <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4825>
<mvo> BjornT_: core build failed with what looks like a snapcraft error:   if ElfFile.is_elf(path):
<mvo>   File "/usr/lib/python3/dist-packages/snapcraft/internal/elf.py", line 152, in is_elf
<mvo>     with open(path, 'rb') as bin_file:
<mvo> OSError: [Errno 6] No such device or address: '/build/base-18/prime/dev/tty'
<mvo> sergiusens: -^
<mup> PR snapd#4826 opened: wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4826>
<mvo> zyga-ubuntu: and no build slots right now, a bit frustrating
<zyga-ubuntu> I have a wrapper
<zyga-ubuntu> man
<mborzecki> mvo: sorry, feel free to cancel the job for my PR, i'll restart it later
<BjornT_> mvo: ah. we saw those errors when building locally. i think it's fixed already in snapcraft master, though.
<mvo> mborzecki: no worries, I think cacneling will not even help
<mvo> BjornT_: aha, ok
<mvo> BjornT_: thank you!
<mborzecki> zyga-ubuntu: https://forum.snapcraft.io/t/race-condition-between-snapd-and-nm-when-providing-permissions/4451 serial devices go though device cgroups too right?
<zyga-ubuntu> yes
<zyga-ubuntu> mvo: can you please look at https://github.com/snapcore/snapd/pull/4827
<mup> PR #4827: cmd/snap-apparmor-parser: add a prototype apparmor parser <Created by zyga> <https://github.com/snapcore/snapd/pull/4827>
<zyga-ubuntu> I will replace the real stuff with this now, ok?
<zyga-ubuntu> and we can implement the cache in a real language next
<mup> PR snapd#4827 opened: cmd/snap-apparmor-parser: add a prototype apparmor parser <Created by zyga> <https://github.com/snapcore/snapd/pull/4827>
 * Chipaca goes for a walk
<mvo> zyga-ubuntu: looks good but I think we first need to figure out if that fixes our issues before replace the real thing (i.e. one step at a time :)
<zyga-ubuntu> mvo: hold on, how do we know that if we replace the real thing
<zyga-ubuntu> I meant to write it and use it to see if this makes anything better
<zyga-ubuntu> we don't have to merge it
<zyga-ubuntu> s/if we replace the real thing/if we *don't* replace the real thing/
<pedronis> do we even know what is broken?
<zyga-ubuntu> pedronis: mvo ran a test where the profile on disk was ok, in memory was bad, running the parser did nothing unless a trivial whitespace change was introduced
<zyga-ubuntu> this hints at a bug in the cache
<zyga-ubuntu> which is based solely on mtime
<pedronis> well, it would be good to have a reproducer then
<pedronis> to submit a bug
<pedronis> it also sounds very bad
<zyga-ubuntu> upstream knows about this bug
<zyga-ubuntu> we had this conversation a few times now
<Son_Goku> zyga-ubuntu, \o/
<pedronis> is the mtime a problem for us in general or because the tests do strange things?
<mvo> pedronis: I think our tests make the story more complicated
<mvo> pedronis: and +100 for a reliable reproducer
<zyga-ubuntu> yeah, but I want to say that pedronis is right we don't have a single, well defined problem
<zyga-ubuntu> we had a problem with edge version
<zyga-ubuntu> how "went away" (not really fixed)
<zyga-ubuntu> we definitely have a problem with mtime and cache but it is unclear why
<zyga-ubuntu> and we may have more problems we don't know about yet
<pedronis> I still think that adding logic to the tests that check what we expect to be loaded
<zyga-ubuntu> the wrapper is meant to make the mtime problem void
<mvo> pedronis: so what I ran into was that I got a denial from "canonical-livepatch status" about it being not able to run snap-device-helper. then I tried appamror_parser -r which did not help, then a whitespace change in the profile and then apparmor_parser -r and things were ok
<pedronis> vs what is laoded match would halep
<pedronis> help
<mvo> pedronis: unfortunately super hard to get into the right (i.e. broken) state
<zyga-ubuntu> mvo: I pushed the stub MATCH
<zyga-ubuntu> and I'll merge when green
<pedronis> anyway if it's naively mtime based
<zyga-ubuntu> but first, I need to take a break and take the dog for a walk
<pedronis> problem should occur only if we go back in time
<mvo> zyga-ubuntu: ok
<pedronis> I suppose our revert might not work
<pedronis> anyway we could test this stuff out
<mvo> pedronis: I have not looked in ages how it works, it used to be mtime based and the pattern I saw indicates it but I did not double check
<cachio> mvo, hey, I didn't see any error reported in the forum on candidate
<Chipaca> zyga-ubuntu: good idea wrt making the stub MATCH dummy
<cachio> mvo, may I promote to stable?
<Chipaca> zyga-ubuntu: if you visit that file again, maybe make it echo to stderr instead of stdout
<pedronis> mvo: ok,  as I said I just fear that fixing things before understanding them will just add to the confusion
<mvo> cachio: yay, then I would say lets just give a quick heads up in the store channel
<mvo> cachio: and go
<pedronis> of which it seems we have plenty
<mvo> pedronis: yeah
<cachio> mvo, sure
<mvo> pedronis: not disagreeing at all
<Chipaca> brb, changing machines around
<mvo> pedronis: we found one thing that is broken
<mvo> pedronis: but there is more lurking, I added a crude hash compare now to one of my test PRs
<mvo> pedronis: essentially what you suggested, maybe that gives us a clue
<mvo> pedronis: it hooks into restore so hopefully it gives us a hint what test is changing things
<pedronis> mvo: -k seems also interesting for debugging
<mvo> pedronis: indeed
<pedronis> anyway the man page is quite explicit about it being time based
<pedronis> fwiw
 * mvo nods
<Chipaca> mvo: zyga-ubuntu: any problem about merging things to master right now? (finally got green..)
<cachio> mvo, well, core promoted to stable
<Chipaca> niemeyer: it seems you changed spread to only build with a go newer than 1.6 and it's breaking autopackagetest
<Chipaca> niemeyer: âgo get -u github.com/snapcore/spread/cmd/spreadâ spits out âpackage context: unrecognized import path "context" (import path does not begin with hostname)â with 1.6 now
<zyga-ubuntu> Chipaca: still Alf
<zyga-ubuntu> Afk
<zyga-ubuntu> But I think it is ok
<Chipaca> zyga-ubuntu: https://i.imgur.com/ZTNhK7W.png
<zyga-ubuntu> lol
<zyga-ubuntu> Alf says âletâs eat this catâ
<mvo> cachio: thanks
<mvo> Chipaca: should be fine
<Chipaca> ack
<mup> PR snapd#4820 closed: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4820>
<cachio> mvo, niemeyer I'll be few minutes late today in the standup
 * cachio afk
<zyga-ubuntu> re
<zyga-ubuntu> Chipaca: can you please look at https://api.travis-ci.org/v3/job/352784798/log.txt
<zyga-ubuntu> it looks like logger unit tests panicked
<Chipaca> ahahaha
<Chipaca> zyga-ubuntu: yes i can look
<zyga-ubuntu> ah
<zyga-ubuntu> sorry, not logger
<zyga-ubuntu> osutil
<zyga-ubuntu> RunWithContext
<zyga-ubuntu> hmm hmm
<Chipaca> zyga-ubuntu: timeout
<Chipaca> zyga-ubuntu: that's a timeout
<Chipaca> zyga-ubuntu: *** Test killed with quit: ran too long (10m0s).
<mup> PR snapd#4788 closed: packaging/fedora: Merge changes from Fedora Dist-Git plus trivial fix <Created by Conan-Kudo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4788>
<zyga-ubuntu> Chipaca: real bug or shall I restart
 * zyga-ubuntu tries to figure out what the test is
<zyga-ubuntu> TestRunRace?
<Chipaca> zyga-ubuntu: yes
 * zyga-ubuntu asks the wrong precise questions
<Chipaca> zyga-ubuntu: this shouldn't happen, but if it happens again let me know; there should be a way to make it exponentially less likely to happen
<Chipaca> I thought this was less-likely-enough :-)
<zyga-ubuntu> can you explain what went wrong here?
<zyga-ubuntu> we called RunWithContext
<Chipaca> zyga-ubuntu: it times how long it takes /bin/false to run
<Chipaca> zyga-ubuntu: then it calls /bin/false in a loop with a timeout of exactly that time
<Chipaca> zyga-ubuntu: it _should_ fail to finish, at least once, after a little bit
<Chipaca> zyga-ubuntu: and it also _should_ be able to succeed, at least once, after a little bit
<zyga-ubuntu> so how come it did not? after 10 minutes
<Chipaca> zyga-ubuntu: it was really (un)lucky the first time
<Chipaca> zyga-ubuntu: or the vm got clamped as soon as it got into a tight loop
<zyga-ubuntu> I see
<zyga-ubuntu> ok, I'll reboot
<Chipaca> so an easy way would be
<Chipaca> if it happens even one more time
<Chipaca> to do two things in each loop: once with dt/2, once with 2*dt
<Chipaca> if that still sometimes hiccups, change it to 4, etc :-)
<Chipaca> zyga-ubuntu: that test is meant to have some surety around it not failing if the deadline happens at just the same time the command finishes though, which is why it's written as it is
<Chipaca> (that's why the only thing it reports as an error is an unexpected error)
<Chipaca> the more i try to work on 18.04, the less productive it feels and the more i stick with 16.04 :-(
<Chipaca> can no longer alt-space x to maximize a window, for example
 * Chipaca working in the 18 live cd
<zyga-ubuntu> Chipaca: how is it? I heard that snapd doesn't work but it was on old build
<Chipaca> zyga-ubuntu: snapd works
<Chipaca> zyga-ubuntu: snaps don't :-)
<zyga-ubuntu> Chipaca: SHIP IT ;-)
<Chipaca> zyga-ubuntu: yesterday I was getting the thing about snap-confine escalation yadda yadda
<zyga-ubuntu> on the same ISO?
<Chipaca> today i'm getting 'cannot create lock directory'
<zyga-ubuntu> Chipaca: do you get an apparmor denial?
<Chipaca> zyga-ubuntu: http://cdimage.ubuntu.com/daily-live/20180313/ vs http://cdimage.ubuntu.com/daily-live/20180312/
<zyga-ubuntu> are you getting a denial on /run/snapd/ns/ stuff?
<zyga-ubuntu> aha
<zyga-ubuntu> so daily
<mvo> Chipaca: oh, you are working on the script? how nice
<Chipaca> zyga-ubuntu: [ 2114.200898] audit: type=1400 audit(1520943269.861:58): apparmor="DENIED" operation="open" profile="/snap/core/4206/usr/lib/snapd/snap-confine" name="/upper/" pid=4392 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<Chipaca> mvo: trying to
<zyga-ubuntu> Chipaca: that's interesting
<Chipaca> mvo: I'm going to have to rebuild it at some point, do you know if there's an easy way of doing that?
<zyga-ubuntu> Chipaca: can you look at /var/lib/snapd/apparmor/snap-confine
<zyga-ubuntu> and can you please paste system-eky
<zyga-ubuntu> *key
<zyga-ubuntu> Chipaca: unsquash, dpkg --extract
<zyga-ubuntu> Chipaca: _probably)
<Chipaca> zyga-ubuntu: which system key?
<zyga-ubuntu> Chipaca: in /var/lib/snapd/system-key
<Chipaca> zyga-ubuntu:  /var/lib/snapd/apparmor/snap-confine is empty
<zyga-ubuntu> Chipaca: that's expected given the symptom
<zyga-ubuntu> it says that there's no overlay workaround in place
<Chipaca> zyga-ubuntu: /var/lib/snapd/system-key does not exist
<zyga-ubuntu> if it's also not in the system-key then either you have an old snapdo
<zyga-ubuntu> or the logic is broken
 * zyga-ubuntu looks
<Chipaca> 2.31.2
<zyga-ubuntu> that's too old :/
<zyga-ubuntu> you need master or 2.32
<Chipaca> I wasn't expecting it to work given just yesterday you were saying it was only fixed on master
<zyga-ubuntu> I wonder why there's no system-key though
<zyga-ubuntu> 2.31 should have it
 * Chipaca takes a break from 18.04 and looks at lunch
<zyga-ubuntu> lunch sounds nice
<zyga-ubuntu> I'm preparing a prototype of snapd-side apparmor cache
<Chipaca> zyga-ubuntu: cuban black beans sounds a'ight today, with it being dull outside
<Chipaca> pedronis: if you have a bit of time I could use a look at #4790 (which purports to fix #1750527)
<mup> PR #4790: jsonutil/puritan: introducing puritan.String & etc <Created by chipaca> <https://github.com/snapcore/snapd/pull/4790>
<mup> PR snapd#4828 opened: many: support holding refreshes by setting refresh.hold (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4828>
<pedronis> mvo: IÂ made the backport ^   needs to go together with #4825 (once landed in master)
<mup> PR #4825: overlord/snapstate:  implement policy of holding refreshes for up to 6h since seeding on classic <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4825>
<mborzecki> Chipaca: do you recall if `snap pack --check-skeleton` was to run ValidateContainer too?
<Chipaca> mborzecki: the way we talked about it I imagined ValidateContainer growing a no-fail-on-missing mode
<Chipaca> mborzecki: (or equivalently checking for and ignoring snap.ErrMissingPath when calling ValidateContainer from --check-skellie)
<Chipaca> mborzecki: it'll still _log_ the error though (not sure if that's a pro or a con)
<mborzecki> Chipaca: ok, i like the error checking approach better ;)
<pedronis> Chipaca: I'll try to look at 4790 later today,    4825 from me also needs a review
<Chipaca> pedronis: thanks
<Chipaca> I'm grabbing lunch now, will look at it after
<mup> PR snapd#4829 opened: 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-ubuntu> mvo: hey, +1 to merge 4821 now?
 * zyga-ubuntu finishes lunch
<mvo> zyga-ubuntu: sounds good
<mup> PR snapd#4821 closed: tests: define MATCH from spread <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4821>
<zyga-ubuntu> mvo: interesting, on a 2.32 branch that passed --skip-cache to apparmor_parser I got the denial again
<zyga-ubuntu> and this PR includes your patch for re-exec profile g eneration
<zyga-ubuntu> I will look at apprmor_parser now
<zyga-ubuntu> maybe it ignores that flag
<zyga-ubuntu> this is https://github.com/snapcore/snapd/pull/4823
<mup> PR #4823: interfaces/apparmor: skip apparmor cache (2.32) <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/4823>
<tyhicks> it definitely doesn't ignore the --skip-cache flag
<zyga-ubuntu> tyhicks: hey
<zyga-ubuntu> so something else is broken
<tyhicks> I use --skip-cache regularly and I also know that there's quite a bit of test coverage for that in parser/tst/caching.py
<zyga-ubuntu> tyhicks: I'll try the snapd-side-cache prototype next
<tyhicks> hey zyga-ubuntu :)
<zyga-ubuntu> thank you for confirming that
<zyga-ubuntu> tyhicks: I wrote https://github.com/snapcore/snapd/pull/4827 as a shoot-in-the-dark (ish) on the issues we are seeing
<mup> PR #4827: cmd/snap-apparmor-parser: add a prototype apparmor parser <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/4827>
<tyhicks> zyga-ubuntu: is there a short writeup on the issues you're seeing?
<tyhicks> (I need to finish publishing a security update before I get too involved here)
<zyga-ubuntu> tyhicks: we see an apparmor denial on snap-confine, the rest is hazy but in one case we confirmed that calling apparmor_parser --replace did _not_ fix the issue without making a no-op whitespace change.
<zyga-ubuntu> tyhicks: it's probably an error related to just our testing process but it's keeping a few people busy as tests are broken.
<tyhicks> zyga-ubuntu: have you been able to reproduce the issue manually, outside of your testing process, or are you stuck having to tickle the issue via the testing process?
<zyga-ubuntu> it's inside the testing process
<zyga-ubuntu> and it's not super reliable to reproduce because one factor changed
<zyga-ubuntu> we'll try to restore that factor so that we can really understand and nail the issue
<zyga-ubuntu> if we nail the issue I'll tell you what it was for sure
<tyhicks> ok, let me know if I can answer any questions or help wade through apparmor_parser code
<zyga-ubuntu> thank you
<mvo> zyga-ubuntu: does http://paste.ubuntu.com/p/4TcqxcRdgh/ ring a bell?
<zyga-ubuntu> yes
<mvo> zyga-ubuntu: I see this on 14.04 and the profile does not allow running update-ns from core snap
<zyga-ubuntu> it looks like we are in the system where we try to run snap-update-ns without profile transition
<zyga-ubuntu> do you have a debug shell?
<zyga-ubuntu> can you look at the profile for snap-confine from core
<zyga-ubuntu> what's at the bottom?
<mvo> zyga-ubuntu: I am
<zyga-ubuntu> is is the rule -> snap-update-ns.*
<zyga-ubuntu> it looks like this thing we had on Thursday
<zyga-ubuntu> right?
<mvo> zyga-ubuntu: http://paste.ubuntu.com/p/B2fXb62yy4/
<zyga-ubuntu> we didn't get to the bottom of that problem
<zyga-ubuntu> this is the wrong profile :(
<zyga-ubuntu>     /var/lib/snapd/hostfs/usr/lib{,exec,64}/snapd/snap-update-ns Cxr -> snap_update_ns,
<zyga-ubuntu> this is the old code, we changed that in 2.32 and master now
<zyga-ubuntu> can you look at the profile in the core snap
<zyga-ubuntu> is it the same?
<zyga-ubuntu> mvo: to be clear, I'm saying this looks like a 2.31 profile
<dan_it__> hi all, I need some help with snapcraft, not sure if this is the right channel
<dan_it__> is there anyone online?
<Chipaca> dan_it__: yesish
<mborzecki> i'm off to pick up the kids
<Chipaca> dan_it__: things are a little hectic today
<mup> PR snapd#4830 opened: many: generate and use per-snap snap-update-ns profile (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4830>
<zyga-ubuntu> that's the backport
<zyga-ubuntu> I'll work on layout fixes noww
<mvo> zyga-ubuntu: ta
<niemeyer> dan_it__: The forum is always a good place.. lots of eyes, and async so people respond as soon as they can
<niemeyer> Chipaca: hangout?
<Chipaca> omw
<Chipaca> niemeyer: standup one?
<niemeyer> Yeah
<Muravey> Hi
<zyga-ubuntu> coffee
<Muravey> What variables are available in snapcraft.yaml
<Muravey> ?
<Muravey> And how to install fonts into package?
<zyga-ubuntu> Muravey: we have a very very busy week, can you please look at the forum, there are (probably) people with the same desires as you now
<zyga-ubuntu> Muravey: you can also open a new topic and ask your questions there
<Muravey> zyga-ubuntu: ok..sorry
<zyga-ubuntu> Muravey: no worries, it's not your fault we're busy today, just ask your questions there as there are more than just the snapd and snapcraft teams participating there
<zyga-ubuntu> the whole snapcraft community is there
<zyga-ubuntu> making and using snaps
<zyga-ubuntu> it's the best place to talk
<zyga-ubuntu> mvo: 4830 is green now
<zyga-ubuntu> mvo: or, green from 1st try
<mvo> zyga-ubuntu: green on first run? woah
<zyga-ubuntu> it's magic
<zyga-ubuntu> also
<zyga-ubuntu> it never uses stale profiles
<zyga-ubuntu> actually, it would still use stale profile for the transition
<mvo> zyga-ubuntu: does it keep changing what is loaded? it must do something different
<zyga-ubuntu> it does change things but it would still be affected by a stale profile
<zyga-ubuntu> because it cannot do a transition without confinement permission
<mvo> zyga-ubuntu: then maybe it was a lucky PR
<mvo> zyga-ubuntu: still strange
<zyga-ubuntu> maybe
<zyga-ubuntu> I suspect there's something to it though
<mvo> yeah I think so too
<mvo> zyga-ubuntu: maybe it is because now edge and 2.32 are close?
<zyga-ubuntu> shall we land it?
<mvo> zyga-ubuntu: no
<mvo> zyga-ubuntu: please not
<zyga-ubuntu> yes, I suspect something like that
<zyga-ubuntu> ok
<mvo> zyga-ubuntu: lets wait a wee bit, I guess we could land it and then use 2.31 as the testcase
<zyga-ubuntu> 2.31 as a test case? what do you mean?
<mvo> zyga-ubuntu: running release/2.31 with the edge core should also show the bug
<zyga-ubuntu> interesting
<zyga-ubuntu> does it?
<mvo> zyga-ubuntu: i.e. we probably don't need 2.32 for this
<mvo> zyga-ubuntu: I have not tried yet :) but I would be surprised if not
<zyga-ubuntu> careful what you wish for :)
<mvo> zyga-ubuntu: haha
<zyga-ubuntu> oh man
<zyga-ubuntu> 16:30
<mvo> zyga-ubuntu: well, if the bug shows itself for core snap-confine profile != our snap-confine profile
<zyga-ubuntu> and I forgot about the coffee
<mvo> zyga-ubuntu: thenâ¦
<zyga-ubuntu> yes
<mvo> zyga-ubuntu: heh, go for it!
<zyga-ubuntu> it will be a second
<mvo> zyga-ubuntu: no worries - fwiw, test-classic-firstboot is another one of the tests that will use a unmodified core and install it. all these tests will trigger the issue I bet. /me tries
<zyga-ubuntu> mvo: keep me posted, I'm curious
<mvo> zyga-ubuntu: trying this now, hopefully its a minimal testcase
<mvo> zyga-ubuntu: aha, maybe 2.31 is not enough - we need the system-key to trigger the bug I think
 * mvo tries that too
<mup> Issue snapcraft#2001 opened: node-engine does not support NodeJS 8.X.X <Created by arkuhn> <https://github.com/snapcore/snapcraft/issue/2001>
<sergiusens> mvo: that's fixed on edge, the 2.40 release will be this week which fixes that
<zyga-ubuntu> hey sergiusens how are you
<mvo> sergiusens: cool, thank you
<zyga-ubuntu> did you get home safely and without surprises?
<sergiusens> zyga-ubuntu: doing well. I am home, no further surprises or incidents
<Chipaca> niemeyer: what does 'spread -list' do, to take 2s to print out the list?
 * Chipaca is too lazy to go look
<Chipaca> niemeyer: if that could take an order of magnitude less, I'd write a tab-completer for it :-)
<niemeyer> Chipaca: Generates the full matrix of tests, which includes reading and parsing everything
<mvo> $GOPATH/bin/spread -v qemu:ubuntu-14.04-64:tests/main/classic-firstboot qemu:ubuntu-14.04-64:tests/main/interfaces-broadcom-asic-control
<mvo> zyga-ubuntu: -^
<mvo> zyga-ubuntu: that works for me to reproduce, I'm testing on 16.04 now, also 4814 seems to be good now
<mvo> zyga-ubuntu: slightly heavy handed though
<Chipaca> mvo: completely left-field question: is there a way to tell apt to not use /var/cache/apt/archives?
<mvo> cachio: yes, run "sudo apt install foo -o dir::cache=/tmp/my-cache
<cachio> mvo, it was for Chipaca perhaps
<mvo> Chipaca: you may need to create archives/partial in there
<mvo> cachio: ups
<mvo> Chipaca: -^
<Chipaca> heh
<Chipaca> mvo: gotcha
<mvo> Chipaca: why?
<Chipaca> mvo: chatting with a guy just now and they were talking about how they have a load of space wasted in their vms because of that dir
<Chipaca> mvo: an always-do-apt-clean would probably also work
<mvo> Chipaca: yes
<mvo> Chipaca: also unattended-upgrades cleans properly after itself
<Chipaca> mvo: is there a way to do the latter? :-)
<mvo> Chipaca: not right now it seems, would be very easy to have a "apt::tidy=1" option that does that automatically
<mvo> Chipaca: in fact, "ulink" right after the deb was installed sounds prudent
<Chipaca> mvo: thanks
<mvo> Chipaca: sounds like a fun evening patch, please remind me, I think it will be a good way to forget this apparmor profile drama I'm in right now
 * Chipaca hugs mvo
<popey> hi fireclawTheFox , hows the snap coming along?
<fireclawTheFox> Hey popey, haven't done much yesterday and just came back from work. But yeah so far it looks good everything works. Just need to see if I can lower the size again, I think it got a few things that doesn't need to ship.
<popey> ooh, we have done some of that optimisation in other snaps
<zyga-ubuntu> mvo: re (dog), so does it mean you still see the issue but now have a better way of reproducing it?
<Chipaca> zyga-ubuntu: mvo: FWIW my new laptop is nvidia (prime, so it has an intel mode as well), running 16.04, if you ever need to test something there (not 18 because lots of oem stuff)
<zyga-ubuntu> !!!
<zyga-ubuntu> wooot
<zyga-ubuntu> perfect
<zyga-ubuntu> first step
<zyga-ubuntu> update to 18.04 :D
<zyga-ubuntu> just kidding
<Chipaca> zyga-ubuntu: i would, but even if i didn't hate it, i'd still not have some of the hardware
<zyga-ubuntu> but some 2nd disk (usb is fine) to boot into 18.04 once in a while would help
<Chipaca> ah, that i could do
<zyga-ubuntu> Chipaca: I think you can reproduce the GLVND issue easily then
<zyga-ubuntu> Chipaca: and you could beta-test fixes
<Chipaca> i had to choose between a second disk and more battery (and i chose battery of course)
<zyga-ubuntu> nah, I mean external disk
<zyga-ubuntu> even a usb thumb drive
<zyga-ubuntu> just for testing at home
<zyga-ubuntu> no need to affect your daily experience
<Chipaca> :+1:
<zyga-ubuntu> you can install on it, if you are careful that is (don't overwrite your boot records)
<zyga-ubuntu> are you on the nvidia driver now?
<Chipaca> yes
<zyga-ubuntu> and if so, which version is it?
<zyga-ubuntu> does Minecraft snap work?
<popey> fireclawTheFox: I find doing "ncdu /snap/<snapname>/current" is a good way to see what's taking up space in the snap
<Chipaca> zyga-ubuntu: 384.111
<fireclawTheFox> popey: ah, thanks will try.
<zyga-ubuntu> Chipaca: that's good, I think you are the missing link :-)
<zyga-ubuntu> Chipaca: I wish you had this machine last week, I'd love to see it :)
<Chipaca> minecraft snap installing
<popey> \o/
<Chipaca> zyga-ubuntu: it arrived at 11am on the monday
<zyga-ubuntu> Chipaca: murphy strikes
<Chipaca> zyga-ubuntu: i sat all through the sprint knowing this was waiting for me on my bed
<fireclawTheFox> popey: Well, basically I shouldn't need much to add aside of the things that are packed by the engine. I think I just needed some libs like pulse, and xlib stuff.
<Chipaca> i had the jitters
<zyga-ubuntu> Chipaca: do you own a copy of Minecraft?
<zyga-ubuntu> (disclaimer: it's a fantastic procrastination helper)
<Chipaca> zyga-ubuntu: 3
<zyga-ubuntu> really?!
<Chipaca> zyga-ubuntu: i play with the boys
<zyga-ubuntu> nice! :)
<Chipaca> the minecraft launcher works
<zyga-ubuntu> (we also own three haha
<zyga-ubuntu> try logging in and see if it works
<zyga-ubuntu> on 16.04 it should be OK
<Chipaca> now downloading minecraft itself
<zyga-ubuntu> so 16.04 is the baseline
<Chipaca> yes it works
<zyga-ubuntu> ok, sometime this week it'd be great to try if Minecraft works with nvidia on 18.04
<zyga-ubuntu> do you have a spare disk to install bionic on?
<Chipaca> zyga-ubuntu: pendrives, yes
<zyga-ubuntu> cool
<Chipaca> actual disk, maybe? still usb though
<zyga-ubuntu> I don't have a fix yet, I'll do one just after layouts (I need two days perhaps, for layouts)
<zyga-ubuntu> pen drives are fine
<Chipaca> zyga-ubuntu: also it'll be good to know if it works when in intel mode
<zyga-ubuntu> I didn't even consider that
<Chipaca> :-)
<zyga-ubuntu> I don't know how the switching works
<Chipaca> i need to log out and back in, so not that magic
<Chipaca> it's not the old voodoo switch thing :-)
<mvo> zyga-ubuntu: I thought so but its random and now its no longer reproducible and its all horrible
<zyga-ubuntu> aaaah
<zyga-ubuntu> so crazy
<mvo> zyga-ubuntu: yes, I think I give up for today
<mvo> zyga-ubuntu: well, almost, one more run
<zyga-ubuntu> mvo: I'm working on something to finish this exercise of the day
<zyga-ubuntu> but tomorrow I focus solely on symlink bug and on the writable leak bug
<zyga-ubuntu> and nothing else
<zyga-ubuntu> so :-)
<zyga-ubuntu> unless you ask
<mvo> zyga-ubuntu: ok, on the layouts bug, right?
<pedronis> mvo: so there is still no  good reproducer?
<pedronis> did you ask for a way to use 2.31 as a baseline?
<zyga-ubuntu> oh right, did that turn out anything?
<mvo> pedronis: I thought I had one (and it all made sense): classic-firstboot installs the real core, that will generate a snap.core.xxx.usr.lib.snapd.snap-confine profile from the "real" core snap (which is out-of-sync with the profile from the branch). that gets loaded into the kernel. now the interfaces-broadcom-asic-control test runs, that runs snap-confine with the wrong profile and boom. except it exploded once and then did not explode even thou
<mvo> gh the order is correct (i.e. first classic-firstboot test runs, then the interfaces test runs)
<mvo> pedronis: 2.31 has no system-key yet so we always re-generate profiles there so its hidden there
<pedronis> so it was 2.31 but a old edge?
<zyga-ubuntu> mvo: I think we want the track/channel
<zyga-ubuntu> and to put 2.31 there
<zyga-ubuntu> and test against that
<mvo> pedronis: yeah, when we had 2.31 on edge briefly things were really wrong
<mvo> zyga-ubuntu: yeah, I think that is a good plan
<pedronis> Chipaca: I did a pass on that branch, is not super easy to review
<niemeyer> cachio: Any news on https://github.com/snapcore/snapd/pull/4778?
<mup> PR #4778: tests: moving debian 9 from linode to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4778>
<niemeyer> cachio: 11 days old, conflicts
<Chipaca> pedronis: sorry...
<Chipaca> pedronis: if it's any consolation mborzecki futzed it and it was a'ight
<Chipaca> (then i broke it, and he futzed it again and found the breakage, so i unbroke it)
<pedronis> Chipaca: it still feels a bit too fiddly
<Chipaca> pedronis: but also, thank you for the pass
<pedronis> Chipaca: I mean, I'm not looking forward about expanding this over more fields in the apis
<Chipaca> pedronis: in what sense?
<pedronis> do we need to use these things in other places?
<pedronis> or is info the only source of things we print?
<pedronis> it also feels like all the fields that are not freeform
<pedronis> should have specific validators and not this
<zyga-ubuntu> jjohansen: hey, I have a question about the kernel apparmor interface
<Chipaca> pedronis: agreed on the latter; on the former I'm still not sure what you mean: currently it's checking everything that comes from the store that doesn't have its own type
<Chipaca> pedronis: if you're asking whether we'd need to do this over the things we get from snap.yaml, I don't know
<zyga-ubuntu> jjohansen: under what circumstances would /sys/kernel/security/apparmor/policy/profiles/$something/raw_{abi,data,sha1} be broken links?
<zyga-ubuntu> I see that on my system and don't understand the cause
<pedronis> Chipaca: no, we have other store apis
<pedronis> do they need the same treatment?
<pedronis> it's a bit strange why we do this to urls for example
<Chipaca> pedronis: yes they'd need the same treatment (or equivalent) (and i just realised what you mean)
<pedronis> I mean, this doesn't seem to scale to me
<pedronis> we need to decide to use it a bit less
<pedronis> or rethink how to make it scale
<Chipaca> pedronis: how doesn't it scale?
<pedronis> Chipaca: we need a checker that we don't use string in our json
<pedronis> or something
<Chipaca> ah
<Chipaca> I can probably do that :-)
<Chipaca> yes
<pedronis> is that sane though?
<pedronis> I understand the fix data on input
<pedronis> but make all our json painful because we might print it
<pedronis> is also strange
<Chipaca> pedronis: I think the alternative would be perhaps to have our own json decoder, but I'm not sure that's a movement towards origin on the sanity line
<Chipaca> pedronis: it seemed saner to clean everything than to answer, for each thing, 'is this going to be printed'
<Chipaca> the latter seems a lot more bug-prone
<fireclawTheFox> popey: do you maybe know if there's a way to automatically install snap-xdg-open with the snap or a way to not have to install it at all?
<popey> What's the problem you want to solve?
<pedronis> Chipaca: people have invented language level solutions for this kind of problems (tainting), so it's hard
<fireclawTheFox> open a weblink from my application in a webbrowser
<Chipaca> pedronis: I'm aware
<pedronis> Chipaca: also afaiu, yes, we need the same for snap.yaml
<Chipaca> pedronis: sigh
<pedronis> Chipaca: I still think we might need to step back and rethink a bit the trade offs
<fireclawTheFox> popey: currently doing this using subprocess.Popen(["xdg-open_", self.website]) as last time I tried webbrowser.open from python didn't work on snaps.
<popey> xdg-open should work AIUI
<pedronis> Chipaca: there are things that definitely don't come from the user
<pedronis> sha3_384, the download urls for example
<fireclawTheFox> yeah, xdg-open does work, but afaik only when the deb package snap-xdg-open is installed, right?
<zyga-ubuntu> fireclawTheFox: no, this is long gone now
<popey> i dont think that's needed anymore
<zyga-ubuntu> fireclawTheFox: the whole setup is now part of snapd
<fireclawTheFox> ah ok, didn't know that
<pedronis> Chipaca: I mean, is there anything that is marked SimpleString that comes from the user? or doesn't have other validation?
<Chipaca> pedronis: there shouldn't be
<pedronis> Chipaca: do we need SimpleString?
<jjohansen> zyga-ubuntu: uh it shouldn't ever be broken links
<zyga-ubuntu> wanna see? :)
<zyga-ubuntu> this is on artful
<jjohansen> under newer kernels its moved to symlinks, but they shouldn't be broken
<pedronis> Chipaca: anyway  we can also start from the other end, what tooling we need to make sure we don't forget any string field? or we mark them somehow
<zyga-ubuntu> https://usercontent.irccloud-cdn.com/file/oZ3RpjNO/Zrzut%20ekranu%202018-03-13%20o%2018.44.34.png
<jjohansen> zyga-ubuntu: yes, if its broken it would be helpful to see how, so I can chase it down
<Chipaca> pedronis: I don't know; what I understood from jdstrand was that I needed to check _everything_
<zyga-ubuntu> https://usercontent.irccloud-cdn.com/file/7ul07q75/Zrzut%20ekranu%202018-03-13%20o%2018.45.12.png
<zyga-ubuntu> jjohansen: I'm not quite sure how I got to this state
<zyga-ubuntu> this is on 4.13.0-36-generic
<pedronis> Chipaca: I don't know if you checked everything, I'm also not if we checked everything tomorrow
<zyga-ubuntu> jjohansen: I was just looking at my system
<Chipaca> pedronis: this does not check everything yet, no
<pedronis> Chipaca: I can add a string field, copy it, and nothing will fail
<Chipaca> pedronis: you're right about needing a static checker if we're taking this route
<zyga-ubuntu> jjohansen: I actually see plenty of broken links
<zyga-ubuntu> jjohansen: if you have any snaps, can you do a quick check
<zyga-ubuntu> jjohansen: maybe the way we remove loaded profiles is wrong
<zyga-ubuntu> and something ends up staying behind
<Chipaca> pedronis: but if I understand correctly, your position is that this route might be wrong
<pedronis> Chipaca: it seems very fiddly and given that we need static checking, we might make lighter weight at that point
<pedronis> Chipaca: is the fear only things that can be printed?
<pedronis> or was the worry something else
<pedronis> Chipaca: who is the attacker?
<pedronis> there's a lot of things that comes in and we print
<pedronis> there is also config
<pedronis> stuff
<jjohansen> zyga-ubuntu: no, there shouldn't be a way to remove profiles wrong, there is the potential for a race of sorts because the symlink doesn't have the same hard reference, but that isn't something you should be seeing
<zyga-ubuntu> find /sys/kernel/security/apparmor/policy/profiles -type l -exec sh -c "file -b {} | grep -q ^broken" \; -print
<Chipaca> pedronis: what sort of lighter weight thing could it be?
<jjohansen> zyga-ubuntu: the raw_data file should not be going away as long as that profile directory exists
<zyga-ubuntu> this reports a load of broken symlinks for me
<pedronis> Chipaca: we could have a white list of things that are store produced
<zyga-ubuntu> Chipaca: ^ can you run that and see if you get any output
<zyga-ubuntu> (anyone with snaps on their system really)
<jjohansen> so yeah there is a bug, I will have to hunt down
<pedronis> like sha3_384 or the download urls
<pedronis> and some other bits
<Chipaca> zyga-ubuntu: no output
<zyga-ubuntu> Chipaca: thank you
<zyga-ubuntu> uptime?
<zyga-ubuntu> for me I only see 3 hours
<Chipaca> zyga-ubuntu: i can try on other boxes; on this one:
<Chipaca>  17:52:01 up 20:36,  1 user,  load average: 0.31, 0.24, 0.35
<zyga-ubuntu> thansk
<zyga-ubuntu> mvo: ^ can you run the find command above
<zyga-ubuntu> pedronis: ^
<Chipaca> hmm
<Chipaca> zyga-ubuntu: i have a lot of output on my other box
<zyga-ubuntu> (unless "broken" is localised)
<zyga-ubuntu> !! thank you
<ubottu> You're welcome! But keep in mind I'm just a bot ;-)
<Chipaca>  17:52:29 up 2 days, 21:14,  3 users,  load average: 0.18, 0.39, 0.27
<zyga-ubuntu> Chipaca: which kernel?
<zyga-ubuntu> jjohansen: where can I report this
<pedronis> nothing here
<Chipaca> 4.13.0-36-generic on the one with lots of broken bts
<Chipaca> 4.4.0-116-generic on the one without
<zyga-ubuntu> ha
<zyga-ubuntu> I have the same kernel as you then (the one with broken symlinks)
<zyga-ubuntu> mvo: ^ a _maybe_ problem related to what we are seeing
<pedronis>  4.4.0
<zyga-ubuntu> mborzecki, and you perhaps?
<pedronis> Chipaca: I'm happy to have a HO on Thu
<pedronis> if we really need to do this for everything we really need a tool
<pedronis> of sorts
<Chipaca> pedronis: to check, or to do?
<Chipaca> i'd be fine with writing a checker, seems not that much work
<pedronis> Chipaca: to check, but I would also understand if we really need SimpleString once we have a checker
<pedronis> the exact attack worries are still a bit unclear to me
<pedronis> s/also/also like/
<Chipaca> pedronis: AIUI it's about decoupling things; we need it on the editable ones, but if it were already on everything we wouldn't have to worry about it at all so why not do it
<pedronis> if it had no costs that would make sense
<pedronis> but is not cost free
<Chipaca> pedronis: do you mean in complexity?
<pedronis> yes
<pedronis> also speed apparently
<pedronis> you had to make it fast
<pedronis> to apply it everywhere
<Chipaca> yes, i worried about this impacting that, as these were potentially big fields
<pedronis> anyway I should almost call it a day
<pedronis> we should chat again on Thu
<Chipaca> (but maybe less than you might think, as the more arcane bits of this are from a de-escaper for terminal stuff i'm working on elsewhere)
<Chipaca> ok
<Chipaca> pedronis: you're off tomorrow?
<pedronis> yes
<Chipaca> hmmm :-)
<Chipaca> pedronis: enjoy
<Chipaca> maybe I should too
<Chipaca> mvo: you're taking friday off, right?
<pedronis> Chipaca: it's a bit unclear to me why anything but description and summary needs the heavy handed approach
<jjohansen> zyga-ubuntu: if you want to file a bug against apparmor or even the ubuntu kernel in launchpad, and subscribe me, that would be the best place atm
<zyga-ubuntu> thank you, I'll file one against artful kernel then
<zyga-ubuntu> jjohansen: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755563
<mup> Bug #1755563: dangling symlinks to loaded apparmor policy <amd64> <apport-bug> <artful> <linux (Ubuntu):New> <https://launchpad.net/bugs/1755563>
<jjohansen> thanks
<zyga-ubuntu> jjohansen: reproduced on bionic just now
<zyga-ubuntu> jjohansen: I updated all the packages and got this (not snaps!)
<zyga-ubuntu>  /sys/kernel/security/apparmor/policy/profiles/libreoffice-senddoc.17/raw_data
<zyga-ubuntu> I updated the bug report
<jjohansen> thanks
<zyga-ubuntu> I cannot reproduce this by simply installing the deb again, tried downgrading and upgrading, nothing
<mup> Bug #1755568 opened: Snaps are refreshed on metered connection <Snappy:New> <https://launchpad.net/bugs/1755568>
<Chipaca> zyga-ubuntu: fwiw the one where i repro this is xenial
<zyga-ubuntu> excellent
<zyga-ubuntu> I updated the bug
<zyga-ubuntu> jjohansen: it affects all supported kernels
<mup> PR snapd#4810 closed: osutil: DropPrivs morphs an *exec.Cmd to drop privileges <Created by chipaca> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4810>
<Chipaca> heh
<Chipaca> that's not what i call 'tentative' :-)
<Chipaca> niemeyer: the driver for that PR is superseded by the hash cache, so, eh
 * Chipaca -> eol
<niemeyer> It's tentative, in that there's a "reopen" button..
<niemeyer> Dear hit-and-run chipaca..
<mup> PR snapd#4831 opened: tests: force profile re-generation via system-key <Created by mvo5> <https://github.com/snapcore/snapd/pull/4831>
<mvo> ^- *might* be enough to workaround the profile issue
<mup> PR snapd#4832 opened: tests: move fedora 27 to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832>
<niemeyer> mvo: Nice
<mvo> niemeyer: well, I was wrong for this particular bug before, so I will hold my breath until the tests pass :)
<Chipaca> niemeyer: i didn't mean to hit-n-run! sorry
<Chipaca> i mean, i didn't mean it as a hit
<Chipaca> i definitely meant to run, because, dinner
<mup> PR snapd#4833 opened: tests: add a detector for kernel bug https://pad.lv/1755563 <Created by zyga> <https://github.com/snapcore/snapd/pull/4833>
<Chipaca> niemeyer: but the order in which i saw things was: your comment about "tentative -1", then mup said "closed" -- I didn't get to see the 'tentatively closing' comment until just now
<Chipaca> so it was funny
<Chipaca> (but also i agreed, because the driver for the pr was gone)
 * Chipaca handwaves more
<niemeyer> Chipaca: No worries :)
<niemeyer> Chipaca: Hope dinner was good
<Chipaca> niemeyer: I am learning to make my mum's cheese roll
<Chipaca> niemeyer: hell yeah it was good :-D
<niemeyer> Wow.. I'm instantly hungry now :)
<Chipaca> still things to tweak but getting better
<mvo> Chipaca: to answer your earlier question - yes
<Chipaca> wooooo
 * mvo hugs Chipaca 
<Chipaca> mvo: wait, was that the "can i have a million euros" quesiton
<Chipaca> mvo: or was it the "are you taking friday off" question
<Chipaca> mvo: either way "woo!", but I need to prepare differently
<Chipaca> with one of them there's going to be a massive party
<Chipaca> with the other, i need a financial advisor
<zyga-ubuntu> does https://amdflaws.com/ mean we will not see the security team for the next few weeks?
<zyga-ubuntu> or was jdstrand going on holidays just a kind way to say he's busy ;-)
<mup> PR snapcraft#2002 opened: pluginhandler: add builtin functions to scriptlets <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2002>
<Chipaca> nice that in writing code I find other code that was tested improperly and wasn't actually testing the thing and we weren't actually doing the thing we were testing for
<Chipaca> /o\
<niemeyer> mvo: Quickie if you're still around: is #4814 still relevant given #4831?
<mup> PR #4814: tests: fix re-exec profile generation in tests on classic (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4814>
<mup> PR #4831: tests: force profile re-generation via system-key <Created by mvo5> <https://github.com/snapcore/snapd/pull/4831>
<zyga-ubuntu> jjohansen: https://api.travis-ci.org/v3/job/353025489/log.txt and look for "kernel bug detected"
<zyga-ubuntu> it looks like a race to me
<jjohansen> zyga-ubuntu: hrmmm, okay I believe you, not that I didn't hours ago ;-)
<zyga-ubuntu> jjohansen: is there anything I can provide that would help you?
<jjohansen> zyga-ubuntu: not atm, but maybe some testing when I get a patch togeth
<jjohansen> together
<cachio> Pharaoh_Atem, hey
<cachio> almost ready fedora 27
<cachio> I just see errors on snaps connecting with dbud
<cachio> Pharaoh_Atem, any idea how to allow snaps connect through dbus?
<cachio> Pharaoh_Atem, this is an example https://api.travis-ci.org/v3/job/353017992/log.txt
<cachio> Pharaoh_Atem, the PR related is 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>
<Pharaoh_Atem> cachio: dbus between snaps should already be allowed
<Pharaoh_Atem> ah
<Pharaoh_Atem> we only allow dbus comms with polkit
<cachio> Pharaoh_Atem, I tested it and selinux is blocking that
<Pharaoh_Atem> so we probably need a policy update to allow snaps to communicate with each other
<Pharaoh_Atem> though I'm not exactly sure how to do that...
<cachio> what I see is that is not aloowed niether connection between snaps nor using dbus-send
<Pharaoh_Atem> cachio: are you able to give me access to the machine that has the denials happening?
<cachio> I need to trigger again the test, it will take 10 minutes
<cachio> Pharaoh_Atem, tests triggered
<Chipaca> slangasek: ping
<slangasek> Chipaca: hi there
<Chipaca> slangasek: hiya
<Pharaoh_Atem> cachio: okay ;)
<mup> PR snapd#4834 opened: snap/squashfs: when installing from seed, try symlink before cp <Created by chipaca> <https://github.com/snapcore/snapd/pull/4834>
<Chipaca> slangasek: so today in the standup we came up with a better plan
<Chipaca> slangasek: ^ that pr is the first (and probably more important) half of it :-D
<Chipaca> slangasek: (this is about first boot from livecd being slow)
<Chipaca> slangasek: second half is doing the hash check only once, which will speed things up; that'll be a bit more code, but the whole thing ended up being a lot more straightforward than we feared
<slangasek> ah, symlink, not hardlink?
<Chipaca> slangasek: yup
<slangasek> seems more portable from my side, if it meets all your requirements on the snapd side
<Chipaca> slangasek: we don't typically do that because we don't control the source (this codepath is used when sideloading for ex), but in the seed case we do
<Chipaca> slangasek: yep, much happier with it
<slangasek> Chipaca: excellent. will we need any changes on the image mastering side to integrate this?
<slangasek> or will it be transparent to us?
<Chipaca> slangasek: it should be entirely transparent
<slangasek> wfm
<Chipaca> niemeyer: ping
<mup> PR snapcraft#2000 closed: elf: remove dead code <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2000>
<Chipaca> niemeyer: before I forget: the ping was about going over a rewrite of the login help with you before pushing it
<Chipaca> niemeyer: also ping about quoting :-)
<mup> PR snapd#4814 closed: tests: fix re-exec profile generation in tests on classic (2.32) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4814>
<mvo> Chipaca: thanks for the PR!
<mvo> niemeyer: I closed 4814 and will close all related ones, 4831 is hopefully enough
<mup> PR snapd#4824 closed: tests: fix re-exec profile generation in tests on classic <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4824>
<mup> PR snapd#4822 closed: interfaces/apparmor: skip apparmor cache <Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4822>
<mup> PR snapd#4823 closed: interfaces/apparmor: skip apparmor cache (2.32) <Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4823>
<mup> PR snapd#4827 closed: cmd/snap-apparmor-parser: add a prototype apparmor parser <Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4827>
 * mvo <- bed
<Chipaca> niemeyer: also question: is it ok to talk about 'tracking channel' and 'channel tip' in user docs
<niemeyer> Chipaca: Yo
<Chipaca> niemeyer: hi
<Chipaca> niemeyer: taking the opportunity to improve the docs for find, install and refresh, via changing the help for login
<Chipaca> niemeyer: but some of these things are hard to explain :-)
<niemeyer> Chipaca: Tracking channel sounds fine, although there's a minor conflict with the term "channel track" which is slightly sad but okayish
<niemeyer> Chipaca: Channel tip feels too developer-oriented
<Chipaca> niemeyer: https://pastebin.ubuntu.com/p/D758SWrydd/
<niemeyer> Chipaca: Expanding it to "current revision in the channel" feels more clear to someone that doesn't have as much baggage, I guess
<niemeyer> Chipaca: Reading...
<Chipaca> yeah, s/tip/current revision/ works
<Chipaca> niemeyer: this comes about because I tweaked the 'login' help: https://pastebin.ubuntu.com/p/BQGfmJQxXw/
<niemeyer> Chipaca: The --beta/etc references doesn't seem necessary there.. --channel is generally more interesting to teach after we introduced tracks and branches as it's the general form that works across all cases
<Chipaca> niemeyer: so then i had to change the 'find' help: https://pastebin.ubuntu.com/p/YKWRbmrnNt/ :-)
<Chipaca> niemeyer: yeah, was in the middle of dropping that
<Chipaca> as in the help output it can be obvious
<nacc> Chipaca: "has access to"
 * Chipaca adds a 'to' to 'has access'
<Chipaca> heh
<nacc> :)
<niemeyer> Chipaca: Mentioning --revision is nice since it's a bit of an edge case, but I think we could do a trick there by mentioning the constraint before mentioning the option, so that people don't stop reading in excitement mid-way through
<niemeyer> E.g.
<Chipaca> hmm, interesting, that might make refresh read easier too
<niemeyer> For revisions that are currently installed in the local system and for personal snaps, --revision will  blah blah blah...
<niemeyer> Or similar
<Chipaca> ok, will tinker a bit more, then push and call it a night
<niemeyer> Chipaca: That last sentence is a bit cryptic.. I mean, I get what you mean, but I suspect most people won't
<Chipaca> niemeyer: the one about security options?
<niemeyer> Yeah
<niemeyer> I suggest just dropping it and letting the error messages play their role..
<Chipaca> niemeyer: perhaps. I'll try to make it obvious in context (ie when the options are spelled out below)
<Chipaca> that's fair
<Chipaca> i mean, it's what we do today :-)
<niemeyer> Yeah :)
<Chipaca> i could drop the whole 'only one at a time' thing in fact
<Chipaca> it's very discoverable and fast
 * Chipaca tinkers
<Chipaca> niemeyer: ah, one more thing
<Chipaca> niemeyer: i had a hard time understanding your comment about 'temporarely', and i don't know if you were making a joke or not :-)
<niemeyer> Chipaca: haha
<niemeyer> Chipaca: Yeah, it was a joke :P
<Chipaca> phew :)
<niemeyer> That's such a great typo, though
<niemeyer> Is there a place we can submit candidate words?
<Chipaca> niemeyer: you'll need a wig and a posh accent
<Chipaca> niice
<Chipaca> https://forum.snapcraft.io/t/explain-permissions-better-or-people-will-freak-out/4456
<Chipaca> I didn't know we had that in place already :-)
<Chipaca> robert_ancell: that you ^?
#snappy 2018-03-14
<Chipaca> not finished, will carry on tomorrow
<Chipaca> off to zzz :-)
<mup> PR snapd#4835 opened: tests: add bionic system to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4835>
<zyga-ubuntu> Good morning
<mborzecki> morning
<zyga-ubuntu> re!
<zyga-ubuntu> kids are handled, wife at work, dog is sleeping (again) and I can finally get to work :)
<mborzecki> zyga-ubuntu: hey
<zyga-ubuntu> hey :-)
<mborzecki> zyga-ubuntu: so the kernel bug with dangling symlinks is real, quite a lot of these came up in your pr
<zyga-ubuntu> yes, it's real
<zyga-ubuntu> now it's unclear if it is related to the issues we saw
<zyga-ubuntu> or if it is just a harmless issue
<mborzecki> zyga-ubuntu: does it also appear in debian sid, or is this part of apparmor ubuntu specific?
<zyga-ubuntu> I don't know
<zyga-ubuntu> my gut feeling is that it's not specific to ubuntu
<zyga-ubuntu> oops, I managed to get an appointment with a doctor at 11
<zyga-ubuntu> good morning mvo
<mvo> zyga-ubuntu: hey! good morning
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mvo> time for 2.32~rc2!
<mvo> zyga-ubuntu: sorry for being a pain, what is the (rough) status of the layout fix we need for 2.32?
<zyga-ubuntu> no change since last week, I know what the problem is and I worked on the first of the two problems (symlink problem) but put this on hold earlier this week
<zyga-ubuntu> I'm adding unit tests
<zyga-ubuntu> though I think I will be changing that code a little as well
<mvo> zyga-ubuntu: thanks!
<zyga-ubuntu> so the status is: known bugs, in progress
<mvo> zyga-ubuntu: could we disable parts of the functionality to get there quicker? or is that a) stupid b) not-needed c) all of the above?
<zyga-ubuntu> it's not worth it, we need the experimental feature flag anyway
<mvo> zyga-ubuntu: aha, ok
<zyga-ubuntu> the symlink bug is "don't make symlinks if one is in place and has good value"
<zyga-ubuntu> the writability leak problem is "don't write over things that are not tmpfs"
<mborzecki> hm the opensuse kernel that we use has apparmor disabled apparently
<mborzecki> uname shows 4.15.7-x86_64-linode102, linode specific kernel?
<zyga-ubuntu> yes, apparently
<mvo> anyone working on the vet failures on 18.04? if not I will do now
<mborzecki> damn, kernel-default-4.4.27-2.1.x86_64 this is installed, but it's running a different kernel, pfff
<mborzecki> mvo: i can take a look
<mvo> mborzecki: its about the vet failures in the test log of 4835
<zyga-ubuntu> there are some people who want to contribute to the gentoo overlay
<zyga-ubuntu> https://github.com/zyga/gentoo-snappy/issues
<zyga-ubuntu> some PRs and issues
<mup> PR snapd#4803 closed: snap-confine, snap-seccomp: utilize new seccomp logging features - 2.32 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4803>
<mup> PR snapd#4831 closed: tests: force profile re-generation via system-key <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4831>
<mup> PR snapd#4828 closed: many: support holding refreshes by setting refresh.hold (2.32) <Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4828>
<mvo> zyga-ubuntu: how safe is 4830?
<mvo> zyga-ubuntu: I am inclinded to merge
<zyga-ubuntu> I don't know of any issues
<mvo> zyga-ubuntu: this runs in edge for some time, right?
<zyga-ubuntu> yes
<zyga-ubuntu> I think it's safe
<zyga-ubuntu> also on reverts
<zyga-ubuntu> since reverting brings the reverted snap-confine
<zyga-ubuntu> and its own profile and startup behavior
<zyga-ubuntu> the only potential downside is if we made a mistake in the apparmor profiles
<mvo> ok
<zyga-ubuntu> but nobody complained so far
<mup> PR snapd#4830 closed: many: generate and use per-snap snap-update-ns profile (2.32) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4830>
<zyga-ubuntu> mvo: hmmmm
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4765
<mup> PR #4765: interfaces: harden snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4765>
<zyga-ubuntu> actually, I'm drunk
<zyga-ubuntu> since that PR you just merged is just the split of the profiles
<zyga-ubuntu> this is the hardening
<zyga-ubuntu> and this is the part when I meant that maybe we missed something
<zyga-ubuntu> the first PR is safe
<zyga-ubuntu> mvo: this PR is the interesting one that jamie wanted to see.
<zyga-ubuntu> man, I thought we merged it already
<zyga-ubuntu> and is full of policy
<zyga-ubuntu> mvo: can you review it?
<mvo> zyga-ubuntu: yes, in a bit, let me go over the essential bits for 2.32 first
<zyga-ubuntu> mvo: I think this is also for 2.32 but I understand if you lack it
<zyga-ubuntu> NACK it
<zyga-ubuntu> (silly spellchecker on macOS)
<kalikiana> moin moin
<zyga-ubuntu> hey kalikiana
<mup> PR snapd#4836 opened: tests: force profile re-generation via system-key <Created by mvo5> <https://github.com/snapcore/snapd/pull/4836>
<pstolowski> morning!
<mborzecki> kalikiana: pstolowski: morning guys
<mborzecki> woow, we use testable examples in snap/info_test.go, never seen it being used before
<mvo> mborzecki: we want 4826 - right?
<mborzecki> mvo: for 2.32?
<mvo> mborzecki: I mean we want it for 2.32
<mvo> mborzecki: yes
<mvo> pstolowski: good morning!
<mborzecki> mvo: yes, it'd be nice to include it, it's a bugfix :)
<mvo> pedronis: 4825 looks almost ready, just one question from gustavo left afaict?
<mvo> mborzecki: cool, lets see if we can find a second reviewer
<mvo> zyga-ubuntu: do we know how the feature flag will look like? environment key?
<zyga-ubuntu> Core setting
<zyga-ubuntu> snap set core experimental.layouts true
<mborzecki> hmm vet does not handle struct methods defined in export_test.go files
<mvo> zyga-ubuntu: do you have code for this or shall I add some? asking because I think with that in place ~rc2 would be ready
<mvo> zyga-ubuntu: I can work on it
<mborzecki> https://github.com/golang/go/issues/23701
<zyga-ubuntu> mvo: I don't have that yet
<zyga-ubuntu> so if you want to pick it up, thanks please do
<mvo> mborzecki: hm, this reads as if the issue should be fixed? do we just need a golang update in bionic?
<mborzecki> go version go1.10 linux/amd64 locally and i can still see this
<mvo> zyga-ubuntu: yeah, I want 2.32~rc2 today if layout have bugs thats ok, we need one more upload for 2.32(-final) anyway
<zyga-ubuntu> ack
<mvo> mborzecki: hm, does that have https://go-review.googlesource.com/c/go/+/92215 ?
<mborzecki> mvo: yes, the commit is in 1.10 branch
<mvo> :(
<mvo> ok
<mvo> mborzecki: if you have a fix for the other vet issues, please push
<mup> PR snapd#4837 opened: many: go vet cleanups <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4837>
<mborzecki> mvo: ^^
<mvo> mborzecki: \o/
<mborzecki> as for the bug that's supposed to be resolved in 1.10, i can still reproduce it with the sample that's provided in the original ticket on both 1.10 from golang.org download and 1.10 from arch packages
<mvo> mborzecki: ok, so we need to reopen upstream? and/or find a local workaround :/
<mvo> and/or disable vet on go1.10 (which would suck)
<mborzecki> i have a sort of a workaround but it's labor intensive :)
<mborzecki> basically changing the struct methods to simple funcs
<mborzecki> and update all call sites
<mvo> mborzecki: hm, that sounds slightly nasty
<Chipaca> moin moin
 * Chipaca realises he still has time for more coffee before official start-of-day
<mborzecki> mvo: it isn't that bad https://paste.ubuntu.com/p/ZPgmsKpM6s/
<mborzecki> mvo: i can push that too
<mvo> mborzecki: yeah, that looks reasonable
<mvo> mborzecki: unfortunate but reasonable
<mvo> Chipaca: hey! good morning!
<mborzecki> Chipaca: morning, more coffee yes, that's a splendid idea :P
<om26er> elopio: Hi! I see you did initial snap packaging for keybase client. Are there any blockers on the way, anyway I could help get that finished ?
 * Chipaca hugs elopio 
 * Chipaca hugs his coffee, also
<mborzecki> mvo: pushed the workarounds
<mborzecki> need to run an errand, bb in ~1.5h
 * zyga-ubuntu -> doctor
<zyga-ubuntu> ttyl
<mup> PR snapd#4838 opened: snapstate: put layout feature behind feature flag <Created by mvo5> <https://github.com/snapcore/snapd/pull/4838>
<zyga-ubuntu> mvo: commented, thank you for writing that
 * zyga-ubuntu waits at the doctors
<zyga-ubuntu> This will take a while (hopefully not too long)
<mvo> zyga-ubuntu: thank you
<mvo> zyga-ubuntu: heh, spread tests> probably, I guess the spread run will be very unhappy!
<mvo> zyga-ubuntu: good catch
<Chipaca> mvo: can you remind me what advise-snap's supposed to do without --command?
<mvo> Chipaca: advice on snap name
<Chipaca> mvo: what's the apt equivalent of that one?
<mvo> Chipaca: so that "apt install spotify" could say something nice like "The spotify snap is available at version 2.0, see snap info spotify for additional versions"
<Chipaca> ah
<Chipaca> a'ight
<mvo> Chipaca: its a bit under speced right now
<mvo> Chipaca: we also probably want mispell there
<mvo> (which should be trivial)
<Chipaca> speling is trivial indeed
<Chipaca> we really struggle with 'temporarily'
<Chipaca> so far i've found temporarely and temporariy
<mvo> Chipaca: *cough* s/we/I/
<zyga-ubuntu> mvo: I will miss standup. I need to do an X-ray now :-(
<zyga-ubuntu> Not sure how soon I will be back today
<zyga-ubuntu> I can work on reviews from my phone
<mvo> zyga-ubuntu: uhh, good luck
<pstolowski> yay, found a bug in go-udev
<zyga-ubuntu> pstolowski: that was quick
<pstolowski> zyga-ubuntu: it's a small project and just a few functions really. and fix is trival thankfully
<Chipaca> huh, there's a new rpi
<zyga-ubuntu> Yep
<zyga-ubuntu> And it has a heat spreader on the chip
<zyga-ubuntu> And does PoE with a hat
<zyga-ubuntu> That latter thing makes it really interesting but there is no information about the availability of the hat yet
<Chipaca> I didn't know Poe used a hat
 * Chipaca imagines ravens with trilbies
<Chipaca> anyway, bbiab
<zyga-ubuntu> Chipaca it is a very stylish poe
 * zyga-ubuntu waits for X-ray
<mup> PR snapd#4839 opened: errtracker: respect the /etc/whoopsie configuration <Created by mvo5> <https://github.com/snapcore/snapd/pull/4839>
<zyga-ubuntu> mvo: reviewed
<abeato> mvo, it looks like the root reason for the bug we chatted around yesterday is device cgroups: https://forum.snapcraft.io/t/race-condition-between-snapd-and-nm-when-providing-permissions/4451/3
<abeato> zyga-ubuntu, ^^
<zyga-ubuntu> Hey
<abeato> zyga-ubuntu, o/
<zyga-ubuntu> Iâm AFK so sorry if I donât respond quickly
<zyga-ubuntu> Let me read the forum thread
<abeato> thanks
<zyga-ubuntu> So a quick question
<zyga-ubuntu> What created the additional device nodes
<abeato> zyga-ubuntu, a script that needs to set some GPIO to power on the device. That takes a few seconds
<zyga-ubuntu> It feels like we are missing an udev rule that adds tags such devices
<zyga-ubuntu> Is it udev tagged by any part of network manager interface?
<abeato> the udev rule is fine, it tags /dev/tty*
<abeato> it is in the ppp interface, used by NM
<zyga-ubuntu> Can you please paste the udev profile generates by snapd for this snap
<abeato> sure
<zyga-ubuntu> Thanks
 * zyga-ubuntu only has a phone with him
<abeato> zyga-ubuntu, https://pastebin.canonical.com/p/jGBrPdkZZq/
<zyga-ubuntu> Aww
<zyga-ubuntu> My token is at home
<zyga-ubuntu> Is it sensitive?
<abeato> zyga-ubuntu, nah, not really: https://paste.ubuntu.com/p/sGWRcj7Ts4/
<abeato> who creates the device cgroup, snap-confine?
<zyga-ubuntu> Yes
<abeato> it would make sense that it adds only the present devices
<abeato> and if a new one appears, apparmor rules are fine thanks to udev, but not the device cgroup
<abeato> which is not updated
<mborzecki> re
<abeato> (well, not thanks to udev, it is just that apparmor has a tty*)
<zyga-ubuntu> Re
<zyga-ubuntu> Well it should be updated
<zyga-ubuntu> Look at those rules
<zyga-ubuntu> We run a tool to change the device cgroup as devices come and go
<zyga-ubuntu> Unless we are hit by a bug
<zyga-ubuntu> We renamed that tool now
<abeato> hm then a bug must be
<abeato> which is that tool?
<zyga-ubuntu> Can you confirm it exists in your system with the given path you see in the udev rule
<zyga-ubuntu> Read the rule please
<zyga-ubuntu> It is raining
<zyga-ubuntu> And typing on a phone is not easy
<abeato> sure :)
<abeato> ok, /usr/lib/snapd/snappy-app-dev
<zyga-ubuntu> Yes
<abeato> zyga-ubuntu, mvo is it possible that core in candidate has been recently upgraded? now I cannot reproduce the issue anymore, although it is a race so I am not 100% sure
<mvo> abeato: candidate got updated on monday
<mvo> abeato: from 2.31.1 to 2.31.2
<abeato> hm...
<mvo> abeato: http://people.canonical.com/~mvo/core-changes/html/candidate/2.31.1r4110_2.31.2r4206.html
 * abeato trying to reproduce again
<zyga-ubuntu> abeato: do you see this on core or on classic
<abeato> core
<zyga-ubuntu> I see
<zyga-ubuntu> Hmm hmm
<zyga-ubuntu> Well
<zyga-ubuntu> If it shows up please tell us
<abeato> yup
<zyga-ubuntu> To the best of our knowledge the system supports devices that are added after startup
<zyga-ubuntu> One possible thing to check for would be a race during cgroup construction
<zyga-ubuntu> That may indeed be buggy
<zyga-ubuntu> I would have to look at the code to confirm this
<zyga-ubuntu> Perhaps the tool should be grabbing the per-snap lock
<zyga-ubuntu> As that would probably rule out the race
<abeato> I can control when the device is created, will tell you if I can reproduce that way in 1min
<zyga-ubuntu> So to be clear
<zyga-ubuntu> If the udev event fires at the same moment as the first process of that snap
<zyga-ubuntu> We may have an issue in that specific case
<zyga-ubuntu> Ok
<zyga-ubuntu> I have my X-ray but results wonât be available till 4PM, Iâm heading home
<abeato> zyga-ubuntu, definitely I can reproduce (ping me when you are back again)
<zyga-ubuntu> Do can you reproduce that and capture udev logs as things happen?
<abeato> yes
<zyga-ubuntu> Please add all findings to the forum thread
<abeato> will do, thanks
<zyga-ubuntu> And can you look at the resulting cgroup and ensure the devices are not there
<zyga-ubuntu> I wonder if we can make the small helper tool log something
<abeato> that's how I checked that I reproduced it :)
<abeato> the new devices are not in devices.list
<abeato> (and I got the EPERM too)
<zyga-ubuntu> Ok
<zyga-ubuntu> Which device is that? The serial port?
<abeato>  /dev/ttyACM0 from a modem
<mborzecki> abeato: is there any indication in dmesg that the port may go away and appear again?
<zyga-ubuntu> The rule looks ol
<zyga-ubuntu> Can you check one more thing
<zyga-ubuntu> Run the tool as udev would
<abeato> mborzecki, it appears and it is kept there
<zyga-ubuntu> Pass the right tings (cannot tell you from the top of my head)
<zyga-ubuntu> And see if it gets added
<abeato> sure, let me try that
<abeato> zyga-ubuntu, https://paste.ubuntu.com/p/hZFQ5XS62g/ :/
<zyga-ubuntu> Woah
<zyga-ubuntu> That looks like a bug
<zyga-ubuntu> Is the tool anywhere in the filesystem?
<abeato>  /lib/udev/snappy-app-dev
<abeato> bad path
<jjohansen> zyga-ubuntu: just a quick update before I bail, I have a patch thats is a wip, I should have something for you to test tomorrow (today?) sometime
<abeato> zyga-ubuntu, so there is a bad path in the udev rule, that's it
<zyga-ubuntu> That is great news jjohansen. Thank you for getting this so quickly! I can test the patch when you have it
<zyga-ubuntu> Mvo: we need a small fix for what abeato just found
<zyga-ubuntu> abeato: which version is that?
<abeato> zyga-ubuntu, 4209
<zyga-ubuntu> And in snap âversion parlance?
<mvo> zyga-ubuntu: oh, what fix is needed?
<zyga-ubuntu> jjohansen: is there any indication that the bug may have other side effects?
<abeato> zyga-ubuntu, https://paste.ubuntu.com/p/tWkMJRP84Y/
<zyga-ubuntu> mvo: udev rules use a wrong path to the helper tool
<zyga-ubuntu> Woah
<abeato> mvo, /usr/lib/snapd/snappy-app-dev -> /lib/udev/snappy-app-dev
<zyga-ubuntu> abeato your snapd is wonky
<zyga-ubuntu> Can you reproduced that on vanilla 2.31.2
<zyga-ubuntu> I will be home soon
<zyga-ubuntu> ~40 minutes maybe
<mvo> abeato: this is slightly strange, the snapd version is pretty out of sync with the snap version
<zyga-ubuntu> (That not super soon though)
<abeato> zyga-ubuntu, mvo well, it is the core from candidate, no hacks I promish
<zyga-ubuntu> That is cery ul ujÄÅy
<zyga-ubuntu> Unlikely
<zyga-ubuntu> Did you push a locally built snapd over?
<mvo> abeato: when I grep snappy-app-dev in master I get only a compat symlink hit, I'm a bit puzzled why its looking in /usr/lib/snapd/snappy-app-dev, is that in the udev rule? or where do you see it?
<zyga-ubuntu> It is in the udev rule but it looks like the snapd there is old or at least based on an old dirty build
<abeato> zyga-ubuntu, hm, wait, I remember I pushed one snapd and mounted it on boot to measure a performance issue
<abeato> let me remove that
<zyga-ubuntu> Thank you!
<mup> PR snapd#4840 opened: many: add `core.problem-reports.disabled` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/4840>
<mborzecki> heh, go vet is flaky in 1.10 and even more so in master, this is what I get with master atm: https://paste.ubuntu.com/p/B2vc9F3CGr/ using a test case https://github.com/golang/go/issues/23701#issuecomment-363187224
<mvo> mwhudson: hm, do you have an opinion about go vet in bionic? we have some problems with 1.10 -^
<mvo> mborzecki: maybe the default of 1.10 is a bit too aggressive :/
<mborzecki> there will be an update to 1.10.1 though?
<mborzecki> i think i'd prefer a slightly broken version if that helps from getting stuck with 1.9 for the next 5 years
<mvo> mborzecki: I guess, worst case is that we disable vet on 1.10 for now
<mborzecki> mvo: the workarounds are there, we can revert them once we know it's fixed again
<abeato> zyga-ubuntu, mvo after reverting the snapd version I see the right path in /etc/udev/rules.d/70-snap.network-manager.rules, so this was my fault. Sorry for the noise
<mvo> mborzecki: aha, ok. I thought you mentioned there are additional errors, am I outdated :) ?
<mvo> abeato: no worries, thanks for reporting it, better this way than if we let a bug escape :)
<abeato> at least I've learned a bit about device cgroups ;)
<mborzecki> mvo: i mean i tried go master, built it and was able to reproduced the problem using a test case posted in the original ticket, got a nice backtrace from go internals :P at least 1.10 did not panic
<zyga-ubuntu> abeato: thank you for confirming that!
<zyga-ubuntu> mvo: alarm is over :)
<abeato> zyga-ubuntu, thank you in fact
<zyga-ubuntu> and I'm back
<zyga-ubuntu> resuming work on fixes
<mvo> mborzecki: ok
<mvo> zyga-ubuntu: thank you for handling it!
<mup> PR snapcraft#1983 closed: snap: update revision of patchelf to use <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1983>
<mup> PR snapd#4841 opened: snap/pack, cmd/snap: add `snap pack --check-skeleton` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4841>
<zyga-ubuntu> Chipaca: would you mind if I bother you with a symlinkat review later today?
<pstolowski> niemeyer: that's the project I was referring to: https://github.com/pilebones/go-udev
<niemeyer> pstolowski: Yeah, that's one I looked into as well, given my browsing history
<niemeyer> pstolowski: Looking for others now
<Chipaca> zyga-ubuntu: yes, I'd be very upset with myself if you asking me for a review bothered me
<Chipaca> niemeyer: wrt the 'halp' pr (#4809) your comments on 'snap pack' seem to imply you want a change of behaviour of snap pack
<mup> PR #4809: cmd/snap: tweak and polish help strings <Created by chipaca> <https://github.com/snapcore/snapd/pull/4809>
<niemeyer> Chipaca: Hmm.. it wasn't intentional at least
<niemeyer> Chipaca: What did I miss?
<Chipaca> i won't be working on that pr until this evening so there's no rush, but
<Chipaca> niemeyer: 'snap pack' already defaults both arguments to '.'
<niemeyer> Chipaca: Huh, ok
<niemeyer> Chipaca: So what's the delta with try?
<niemeyer> Chipaca: That it doens't look for "prime"?
<Chipaca> niemeyer: essentially yes, but also it only sets it to . if there's a meta/snap.yaml in .
<Chipaca> and it only sets it to prime if there's a snapcraft.yaml in one of the usual places
<niemeyer> Chipaca: Okay, I indeed missed those details.. so +1 on your suggestion
<Chipaca> (curiously it doesn't look for meta/snap.yaml in the prime directory, but that's a tweak)
<niemeyer> Chipaca: I think we should ignore snapcraft.yaml and just look for meta/snap.yaml as you suggest
<Chipaca> niemeyer: it's still slightly awkard that it'll happily drop a snap inside the snap (and there are snaps with snaps in them in the store, so it's a real problem)
<niemeyer> (in prime, in .)
<niemeyer> Chipaca: Is there a way to make snap pack ignore those?
 * niemeyer --help
<Chipaca> niemeyer: not currently; snapcraft has an ignore list, but not snap pack
<Chipaca> OTOH most people will be using it via snapcraft so it'll be fine :-)
<Chipaca> anyway, glad that's cleared up, i'll tweak the text and the behaviour (but possibly in a followup)
<Chipaca> this evening though; now to the cache
<Chipaca> hm, maybe, maybe target should default to the parent dir of snap-dir
<mborzecki> Chipaca: or soem /tmp location
<Chipaca> mborzecki: it might not be the best example, but dpkg-buildpackage plops the debs in ..
<niemeyer> Chipaca: Yep, -e works
<niemeyer> Chipaca: Although it's completely undocumented apparently
<niemeyer> Chipaca: -e <filename>
<niemeyer> Chipaca: I suggest using that for any *.snap in the root directory
<Chipaca> niemeyer: fair 'nuff
<niemeyer> Chipaca: I've seen actual snaps shipping the prior revision of their own snaps
<Chipaca> niemeyer: IKR
<niemeyer> Chipaca: Built with snapcraft
<niemeyer> So it looks like a common issue
<niemeyer> In the rare circumstances where people do want to ship snaps, they can just put it in a subdir
<Chipaca> niemeyer: https://i.imgflip.com/26d5u0.jpg
<niemeyer> Yeah :)
 * Chipaca forgets the whole conversation and moves to the hash cache stash
<cachio> mvo, I have tried the upgrade test issue with the last bionic image in google and I see the same problem
<cachio> all the snaps appear as broken
<cachio> mvo, any idea?
<cachio> I could get a debug session with the error
<Chipaca> my / has inode number 2
<Chipaca> how
 * Chipaca doesn't really care and gets back to work
<mvo> cachio: yeah, happy to get into  a debug session
<mvo> cachio: what did you run to trigger it?
<cachio> mvo, https://github.com/snapcore/snapd/pull/4835
<mup> PR #4835: tests: add bionic system to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4835>
<cachio> this branch
<cachio> mvo, but using this image
<cachio> ubuntu-os-cloud-devel/daily-ubuntu-1804-bionic-v20180307
<cachio> which is the last one
<cachio> mvo, nad run spread -debug google:ubuntu-18.04-64:tests/upgrade/basic
<mborzecki> mvo: I'll close #4597 if you don't mind
<mup> PR #4597: snapstate: allow core config via $core <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4597>
<mvo> mborzecki: ok, hope some of the code will still be useful for your work in this area
<mborzecki> mvo: yes, i'll pull in your commit and work on top of it
<mup> PR snapd#4597 closed: snapstate: allow core config via $core <Blocked> <Created by mvo5> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4597>
<mvo> mborzecki: \o/
<mup> PR snapd#4842 opened: 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>
<mvo> ^- this is to test the theory that the system-key needs extending to get rid of the errors we saw with 2.32 and the out-of-sync of the profiles, please ignore until green
<zyga-ubuntu> mvo: interesting
<mvo> zyga-ubuntu: yeah, it usually this is covered by the core rev but not in our tests
<mvo> zyga-ubuntu: lets see if its green or not
<kyrofa> Hey Chipaca, if/when you're able, can I get a sanity check review from you on a snapcraft PR? We're adding the ability to call functions from scriptlets which are then handled by the running Snapcraft instance, and we're doing it via fifos: https://github.com/snapcore/snapcraft/pull/2002
<mup> PR snapcraft#2002: pluginhandler: add builtin functions to scriptlets <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2002>
<Chipaca> kyrofa: fifos, as in fifo(7)?
<kyrofa> Yessir
<kyrofa> Relevant parts of the PR are python (https://github.com/snapcore/snapcraft/pull/2002/files#diff-313e8dc0aa8d02f56e6ec918c25ddd93R74) and shell (https://github.com/snapcore/snapcraft/pull/2002/files#diff-8b247ab4b649deb9ee488e09837eba39R30)
<mup> PR snapcraft#2002: pluginhandler: add builtin functions to scriptlets <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2002>
<kyrofa> Wonder if it would be simpler with a more snapctl-like approach
<Chipaca> kyrofa: what does the 'status' variable get used for?
<kyrofa> Chipaca, to block
<kyrofa> Until the function has been handled
<kyrofa> Otherwise once the "call" fifo has been read, the scriptlet goes on its merry way
<Chipaca> kyrofa: does this work?
<kyrofa> Chipaca, in my testing anyway, yeah. Do you see issues?
<Chipaca> kyrofa: only things that seem strange but they might be connected outside of my limited window into the code
<Chipaca> like, cwd of the popen is not tempdir
<Chipaca> but it finds the fifos
<Chipaca> ?
<kyrofa> The fifos are an absolute path, handed to the script run by the popen
<Chipaca> ah :-)
<Chipaca> hmmm
<Chipaca> kyrofa: another question: why nonblocking?
<kyrofa> Chipaca, on the Python side? So that the scriptlet can actually exit and Snapcraft can move on even if they don't utilize the fifos
<kyrofa> Otherwise Snapcraft will block checking for a function call, and the scriptlet will exit in the meantime
<Chipaca> kyrofa: i'm having trouble hitting that failure mode
<cachio> Pharaoh_Atem, hey
<cachio> Pharaoh_Atem, do you haave time to continue with the dbus test?
<Pharaoh_Atem> cachio: I will in ~20 minutes
<cachio> Pharaoh_Atem, great, thanks
<cachio> Pharaoh_Atem, I'll prepare the environment in that case
<Chipaca> kyrofa: granted my code is a butchering of yours just to test it (mostly because my experience with fifos is that they are finickity)
<kyrofa> Chipaca, that's exactly the kind of info I was hoping you'd have! This approach does not give you warm and fuzzies, then?
<Chipaca> kyrofa: it can work, and when it does it's brilliant
<Chipaca> kyrofa: and most of my bad experiences have been around things deadlockinig, which the nonblocking thing should avoid? I think
<Chipaca> if i understand it correctly at least
<kyrofa> Indeed. But your hacking is confusing, let me try removing the non-blocking and see if I can get it to fail like I expect, hold on
<Chipaca> but, with it nonblocking you do end up spinning quite a bit
<kyrofa> Yeah totally
<kyrofa> It's not beautiful
<kyrofa> Yeah Chipaca remove ` | os.O_NONBLOCK` in `_NonBlockingFifo` and then run a YAML that looks like this: https://pastebin.ubuntu.com/p/V2tZ7GfzBn/
<kyrofa> Whereas, if you add a `snapcraft_build` call to the bottom of the `build` scriptlet, things start working again since you wrote to the fifo to unblock snapcraft
 * zyga-ubuntu goes to pick up xray results, ttyl
 * Chipaca plays with this
<cachio> Pharaoh_Atem, env ready
<Chipaca> kyrofa: I'm not seeing it getting blocked
<kyrofa> Huh. I can't explain that
<Chipaca> kyrofa: https://pastebin.ubuntu.com/p/xpPwjyvKQS/
<Chipaca> that's with O_NONBLOCK commented out
<Chipaca> kyrofa: but it might not be picking up my changes
<kyrofa> Chipaca, how do you have it installed?
<kyrofa> venv?
<Chipaca> kyrofa: i don't, i'm running it from the git repo + venv
<Chipaca> i don't think i installed it to the venv
 * Chipaca checks
<Chipaca> dangit
<Chipaca> yes it's there
<kyrofa> And it's installed into the venv with --editable ?
<Chipaca> there we go
<kyrofa> Oh phew
<Chipaca> kyrofa: somehow doing 'pip install -r requirements.txt .' (as per HACKING) also installed snapcraft itself
<Chipaca> i guess that's the . there :-)
<kyrofa> Indeed. Although below is the guide for actually _developing_ using that method, which requires --editable
<kyrofa> Although even that falls on its face sometimes
<kyrofa> Every once in a while I need to reinstall it and I never know why
<Chipaca> kyrofa: is there a way to tell it to do a clean and then a build?
<kyrofa> snapcraft clean && snapcraft build
<Chipaca> or to jfd a build?
<Chipaca> eh, fair enough
<pstolowski> Chipaca: thanks for staying vigiliant with serial-port interface regexp... completely overlooked what you spotted!
<Chipaca> pstolowski: no
<Chipaca> pstolowski: np*
<Chipaca> :-)
<Chipaca> kyrofa: i need to go for a bit, but i'll carry on looking when ig et back
 * Chipaca afk
<pstolowski> Chipaca: it looked very innocent :}
<kyrofa> Chipaca, of course, I appreciate your time!
<cachio> Pharaoh_Atem, there?
<Chipaca> pstolowski: IKR, I wouldn't've noticed if the regexp hadn't been blatently wrong
<Chipaca> kyrofa: *blush*
<popey> When do we plan to have overlay support landed?
<jjohansen> zyga-ubuntu: no, no indication that the bug has other side effects (well it will break LXD checkpoint/restore). The symlink isn't getting properly updated on profile replacement, to point to the new blob.
<Chipaca> kyrofa: does this code need to run on non-linux?
<kyrofa> Chipaca, I don't believe so, no
<Chipaca> kyrofa: my suggestion about O_RDRW is non-portable, you see :-)
<kyrofa> Chipaca, are FIFOs portable?
<Chipaca> kyrofa: not to cp/m, dos, nor derivatives
<Chipaca> :-)
<Chipaca> kyrofa: but to unices yes
 * kalikiana heading out o/
<Chipaca> niemeyer: question about the approach to the cache
<Chipaca> niemeyer: currrently asserts.SnapFileSHA3_384 calls osutil.FileDigest to get the digest and then asserts.EncodeDigest to format it (prepend sha3-384: etc)
<niemeyer> Chipaca: Ok
<Chipaca> niemeyer: writing osutil.GetPathInfo, I can either make it receive a hasher (the caller would then wrap and pass in SnapFileSHA3_384), or i could move SnapFileSHA3_384 and EncodeDigest to osutil, or I could move GetPathInfo to asserts (or elsewhere)
<Chipaca> niemeyer: the disadvantage of the hasher is that it makes it awkward to add more 'expensive' stuff, if everything is passed in
<Chipaca> but otherwise it seems fine
<Chipaca> niemeyer: so the question is, which approach do you think is best?
<niemeyer> Chipaca: Yeah, I think it should compute internally to make it convenient.. I'm just wondering if it's a bit of a weak design in that if we introduce further hashes, we'll probably want to read the file only once to do them all, instead of asking N hashing functions to each compute it again
<niemeyer> Chipaca: So perhaps neither? Where is the real sha3 algo living?
<Chipaca> niemeyer: which is the 'real sha3'
<niemeyer> Chipaca: The thing that computes the sha3 digest given bytes
 * niemeyer digs in
<Chipaca> niemeyer: osutil.FileDigest takes a generic crypto.Hash
<niemeyer> Chipaca: That's good.. we can cook a crypto.Hash which is actually multiple hashes easily, I suppose
<niemeyer> Chipaca: So the answer to my question above is golang.org/x/crypto/sha3
<Chipaca> fwiw I think I need a thing that takes an io.Reader, not bytes
<Chipaca> but that's minor
<Chipaca> (otoh it's easy to multiplex readers to do multiple hashes)
<niemeyer> Chipaca: I suggest leaving asserts alone for now and just doing the low-level thing inside osutil, leveraging crypto/sha3 directly
<niemeyer> Chipaca: The cache can keep bytes too
<niemeyer> Chipaca: DeriveSideInfo can return the actual bytes too, unencoded
<mup> PR snapd#4843 opened: interfaces/builtin: let MM change qmi device attributes <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4843>
<niemeyer> Chipaca: FWIW, if we find a need to reuse EncodeDigest later, it should probably live inside strutil
<Chipaca> niemeyer: I _think_ i understood what you meant :-)
<Chipaca> niemeyer: basically make SnapFileSHA3_384 call osutil.GetPathInfo instead of osutil.FileDigest to get the digest
<Chipaca> i think that'll work, because i think everything uses that to get the hash
<Chipaca> i'll double check and report back if it's otherwise
<niemeyer> Chipaca: I don't think that will work
<Chipaca> niemeyer: then i didn't understand what you meant
<niemeyer> Chipaca: Well, or maybe it will, if we reuse the StateCache type there as well
<Chipaca> ah, because it doesn't have the state :-/
<niemeyer> Chipaca: The original suggestion was to *return* the digest, but I guess your solution is cleaner actually
<Chipaca> heh
<Chipaca> niemeyer: the problem is what is 'the digest'
<Chipaca> all these functions return 'the digest'
<niemeyer> Chipaca: Right.. but we can pass in the state as a StateCache interface as well
<Chipaca> it's just â¦ different digests
<Chipaca> :-)
<niemeyer> Chipaca: DeriveFooBar doesn't return any digests today
<Chipaca> niemeyer: i never mentioned DeriveFooBar
<Chipaca> ;-)
<niemeyer> Chipaca: I did, both in the call and above
<niemeyer> "Chipaca: DeriveSideInfo can return the actual bytes too, unencoded"
<niemeyer> Chipaca: This is the actual function that performs the digest inside firstboot
<Chipaca> niemeyer: yes, but i'm not sure what the bytes would be useful for
<niemeyer> Chipaca: To cache them
<niemeyer> Chipaca: But... you're right
<Chipaca> i hate being right before understanding the thing
<Chipaca> :-)
<Chipaca> probably a bit late in the day for me
<niemeyer> Chipaca: It's cleaner to pass the StateCache in as an interface, and call GetPathInfo inside it
<niemeyer> Chipaca: Perhaps osutil.ComputePathInfo instead
<niemeyer> Chipaca: So callers realize this is not a trivial op
<Chipaca> niemeyer: HoldOnToYourTrowsersWereGoingToGetPathInfo
<Chipaca> :-p
<niemeyer> Even better :P
<Chipaca> yeah the name was a this-thing-needs-a-name token one, not the actual thing
<Chipaca> ComputePathInfo it is
<Chipaca> and, eod for a while (probably be back later to play with help strings)
<niemeyer> Chipaca: Enjoy
<mup> PR snapd#4837 closed: many: go vet cleanups <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4837>
<cachio> niemeyer, could you please take a look to this one? https://github.com/snapcore/spread/pull/52
<mup> PR spread#52: Add storage option for google <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/52>
<cachio> it is making fail the ubuntu-16.04-32 on google
<Chipaca> niemeyer: ping
<mup> Issue snapcraft#1659 closed: Implement support for supported bases <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1659>
<mup> PR snapcraft#1993 closed: core: initial support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1993>
<niemeyer> Chipaca: Hyea
<Chipaca> niemeyer: noodling around with this stuff, it looks like I should give PathInfos a Rename
<Chipaca> niemeyer: at which point I'm not sure PathInfo is the right name for the beast
 * Chipaca goes back to noodlin' and lets niemeyer worry about names
<niemeyer> Chipaca: I'm not sure about what other name might be appropriate though.. we're effectively associating a bag of knowledge with a particular path
<Chipaca> niemeyer: HashedFile?
<Chipaca> eh, probably not or it'll grow Open() and stuff
<Chipaca> and I guess Rename is actually a method of the hash cache, not the path info
<Chipaca> hrmph
<Chipaca> (the rename thing is because in quite a few places (at least two so far :-) ) we hash just before moving the file_
<Chipaca> the download with deltas path is really interesting
<Chipaca> apply delta hashes the composed file to make sure it's ok
<Chipaca> and if so it's treated like a complete partial
<Chipaca> so it's hashed to make sure it's ok
<mup> PR snapcraft#2003 opened: patches: make the ctypes patch more robust and add armhf arch triplet <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2003>
<Chipaca> and that's in store, before hashing it to make sure it's ok
<Chipaca> :-)
 * cachio afk
<niemeyer> Chipaca: Renaming the path info doesn't sound too bad
<Chipaca> niemeyer: yeah, i was originally thinking of having it do the actual rename
<Chipaca> but it'll just rename the cache and be happy
<niemeyer> Chipaca: The association is still with the path, and it's not just a hash.. we want mtime, size, etc, as well
<niemeyer> Chipaca: Ah, agreed.. it should act just on the cache
<mup> PR snapcraft#2004 opened: errros: add a specific error when running commnds from plugins <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2004>
<cachio> niemeyer, hey
<niemeyer> cachio: Heya
<cachio> niemeyer, when you have 5 minutes, could you please take a look to https://github.com/snapcore/spread/pull/52 ?
<mup> PR spread#52: Add storage option for google <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/52>
<cachio> niemeyer, I have 1 PR waiting for this change
<niemeyer> ACk
<cachio> niemeyer, tx
<cachio> niemeyer, something else
<cachio> niemeyer, I see https://paste.ubuntu.com/p/2Wd5dQX6WS/ after a reboot in debian 9 in google
<cachio> it is like spread tries to connect and for some reason pam is closing the session for the root
<cachio> the sshd config is the same we have in linode
<cachio> did you see that before?
<mwhudson> um
<mwhudson> subiquity is failing to start in a live cd with "cannot create user data directory"
<mwhudson> what can possibly have changed since this worked yesterday
 * cachio eod
#snappy 2018-03-15
<mborzecki> morning
<mwhudson> (answer: snapd in the core snap is newer than snapd in bioinic today)
<zyga-ubuntu> good morning
<zyga-ubuntu> mwhudson: can you give me the denial please
<zyga-ubuntu> mwhudson: grep for DENIED in dmesg
<mborzecki> zyga-ubuntu: mornings
<mwhudson> zyga-ubuntu: i think it's the more or less known thing about apparmor and overlayfs not being friends
<zyga-ubuntu> mwhudson: ah, so it's still the version witohut overrlay support?
<zyga-ubuntu> mwhudson: can you pastebin /var/lib/snapd/system-key
<mwhudson> zyga-ubuntu: i'm going to wait for 2.32 until i get bothersome about it
<mwhudson> zyga-ubuntu: don't have a vm up know
<zyga-ubuntu> that's ok
<zyga-ubuntu> I thought that patch was out already
<mwhudson> zyga-ubuntu: i think xenial is on 2.23.1 or something
<mwhudson> hm that's what xenial-proposed has anyway
<mwhudson> so does the stable core snap have snapd from xenial-proposed in it?
<mwhudson> that seems surprising
 * zyga-ubuntu doesn't know
<zyga-ubuntu> I was a little detached yesterday
<mup> PR snapd#4844 opened: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: can you take a look at #4826?
<mup> PR #4826: wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4826>
<pstolowski> mborzecki: yep
<kalikiana> moin moin
<mborzecki> pstolowski: thanks for the review
<pstolowski> np
<mup> PR snapd#4826 closed: wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4826>
<mup> PR snapd#4845 opened: snap, store: store version numbers in the commands database <Created by mvo5> <https://github.com/snapcore/snapd/pull/4845>
<mvo> mborzecki: could you please create a 2.32 version of 4826 (if there isn't one already)?
<mborzecki> mvo: coming up
<mvo> ta
<mup> PR snapd#4846 opened: [2.32] wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4846>
<mborzecki> mvo: ^^
<mvo> mborzecki: ta
<Chipaca> *yawn*
<Chipaca> just five more minutes
<pedronis> hello
<Chipaca> pedronis: hi
<pedronis> Chipaca: hi,  IÂ need to update a PR after let me know when you want to chat about puritan
<Chipaca> pedronis: knee-deep in the hash cache mash atm
<pedronis> Chipaca: I saw you discussing that,    did you notice that some of those helpers are used when there's no state
<pedronis> StateCache need to be optional
<Chipaca> pedronis: yes I did
<pedronis> IÂ mean snapasserts exist to hold stuff at the intersection of  snap files and assertions (but not needing state)
<pedronis> or at least not requiring state
 * Chipaca nods
<pedronis> Chipaca: are you looking  also into the download case?Â IÂ though the idea was to fix firstboot first
<pedronis> store has its own ways to keep state at distance
<Chipaca> pedronis: firstboot first, but with my eye on download to make the followup easy (or trivial)
<pedronis> easier sounds fair, trivial unlikely
<Chipaca> it's all a bit messy though
<Chipaca> pedronis: did you see the thing about the extra extra hashing during download delta?
<pedronis> yes, I was aware of that
<pedronis> we also check the hash of the delta itself
<Chipaca> i guess i'd forgotten :-)
<Chipaca> that's fine
<pedronis> seems a bit orthogonal
<pedronis> except that we should have picked a different hash for those
<Chipaca> anyhoo, that's  what i'm in
<pedronis> no sense being super expensive
<pedronis> given that we need to recheck the whole thing anyhow
<pedronis> but it's as it is
<Chipaca> pedronis: we can fix that though :-)
<pedronis> yes, it's fixable
<Chipaca> not today
<Chipaca> also, store is a mess, and daemon is a mess
<Chipaca> Â¯\_(ã)_/Â¯
<pedronis> store was worse
<Chipaca> oh, totally
<Chipaca> baby steps
<pedronis> it's improving (slowly)
<pedronis> daemon, no, IÂ don't think we rearchitected much of it yet
<pedronis> let me know if IÂ can help, also happy to review
 * pedronis back to his high prio stuff
<mup> PR snapd#4847 opened: osutil: add symlinkat(2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4847>
<pedronis> grumble, the PR that had a consistently failing spread test now passed once I added a some debug stanza :/ I'm quite sure there is something fragile after the change but who knows now
<Chipaca> pedronis: i'm feeling rather dumb here, but I can't figure out where the second hashing in firstboot is happening
<Chipaca> pedronis: derive side info does one, but the second one...?
<mborzecki> it'd be so nice if i didn't have to fire up a vm with fedora/suse just to check what `rpm -E %configure` expands to
<pedronis> Chipaca: verify-snap
<Chipaca> pedronis: that's not run for firstboot
<pedronis> ?
<Chipaca> pedronis: firstboot does InstallPath
<Chipaca> pedronis: which means the snap is local, so gets no validate-snap task
<pedronis> really
<pedronis> I'm confused
<Chipaca> that's how i read it, but see: dumb
<pedronis> I thought we always did that
<pedronis> if we don't there is nothing to fix
<pedronis> but might be problematic for other reasons
 * Chipaca takes the rest of the day off
<Chipaca> :-)
<pedronis> that's a recent chnage
<Chipaca> pedronis: 2016
<pedronis> nothing to do afaict
<pedronis> now I'll discover it's by me
<mup> PR snapd#4846 closed: [2.32] wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4846>
<Chipaca> pedronis: you'd only discover that if you went looking
<Chipaca> pedronis: I say don't
<pedronis> it's by me
<pedronis> so we never did double hashing
<Chipaca> so the symlink fix should make all the difference we can make
<pedronis> IÂ mean at firstboot
 * Chipaca too
<pedronis> mmh
<pedronis> yes, avoiding the copy is as good as it gets
<pedronis> unless we go back to the cheating script
<pedronis> same also for core btw
<Chipaca> pedronis: well, core links
<Chipaca> pedronis: the symlink only happens if the link fails
<pedronis> yea, there's not win to be had on core
<Chipaca> ah. yeah.
<Chipaca> but
<Chipaca> i do feel that if we had a central place to do hashing this would've not taken so long to figure out
<Chipaca> but, not work for today
<pedronis> not sure how we can achieve that
<pedronis> unless you mean one codeline, not conceptually
<Chipaca> magic ã½(ï½ÐÂ´)âââï¾. * ï½¥ ï½¡ï¾,
<Chipaca> wishful thinking mostly
<pedronis> we would need unify DeriveSideInfo and doValidateSnap, seems worthwhile but not sure how to attack that
<pedronis> it's probably possible, bit of a code pretzel though
 * Chipaca nods
<Chipaca> meanwhile I'll do the cheap thing and skip the extra hash in download after successful applyDelta
<Chipaca> then that'll stop bugging me
<Chipaca> pedronis: can we talk about puritan in ~2h
<pedronis> yes
<zyga-ubuntu> mborzecki: can you please look at 4847 again
<zyga-ubuntu> I added one more syscall
<mvo> mborzecki: go vet is fully happy now again on 1.10, right?
<mborzecki> mvo: yes, it's passing
<mborzecki> mvo: cachio's bionic PR failed in InstallDate() unit test, probably outdated mksquashfs with the bug that you fixed
<ackk> sergiusens, mvo I see that https://github.com/snapcore/snapcraft/commit/10509d590658f1c417b91d66a356700483997d75 has landed now, is there any plan to rename base-18 to core18 soon?
<mvo> mborzecki: yeah, the issue here is that squashfs has not transitioned to bionic yet iirc the autopkgtest for lxd failed
<mvo> ackk: yes, we want to rename it soon, right now a snapcraft issue prevents us from building, this will get fixed this week, then we will do the rename (once we can build again)
<ackk> mvo, ah, cool, thanks
<pedronis> pstolowski: hi, IÂ think IÂ still owe you a bunch of reviews, IÂ will try to have a reviews day tomorrow
<pstolowski> pedronis: hi! no worries, and thanks in advance! I think you can focus on #4358 for now and ignore the rest
<mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
<pstolowski> as they are stacked on top of 4358
<mup> PR snapd#4848 opened: many: cherry-pick relevent `go vet` 1.10 fixes to 2.32 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4848>
<Chipaca> mvo: you'll also want to cherry pick 19a1dc929b89bf8dd5d6ad22bb36942b5a2508c4
<mup> PR snapcraft#1994 closed: docker: add the architecture <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1994>
<Chipaca> mvo: for bubonic i mean
<Chipaca> bah, for bubonic to pass
<Chipaca> bionic*
<mvo> Chipaca: thank you
<Chipaca> there's a go 1.10's behaviour change that breaks our tests (explained in that commit)
<mborzecki> Chipaca: bubonic ;)
<mvo> Chipaca: its not in master yet, is it?
<Chipaca> mvo: no
<mborzecki> hope it's not about the plague
<mvo> Chipaca, mborzecki lol
<Chipaca> mvo: it's pushed to #4835
<mup> PR #4835: tests: add bionic system to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4835>
<Chipaca> but that fails to be green because the google archive mirror doesn't have the new bionic squashfstools
<mvo> Chipaca: we need to enable bionic-proposed there
<mvo> Chipaca: but I can cherry-pick into my 2.32 pr
 * Chipaca nods
<Chipaca> this is why i mention it :-)
<mvo> ta
<mborzecki> Chipaca: can you take a look at #4841?
<mup> PR #4841: snap/pack, cmd/snap: add `snap pack --check-skeleton` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4841>
<mvo> hey stgraber ! the autopkgtests for squashfs-tools fail in the lxd testing right now (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#squashfs-tools), is there a know issue with autopkgtest and lxd? the failures do not look related to the squashfs change
<Chipaca> mborzecki: I can do 4831, and 4861, but not 4841 sorry
 * Chipaca lies
<mborzecki> at least 4861 gives the nice tatooine-ish 404 :P
<mup> PR snapcraft#1996 closed: tests: add SNAPCRAFT_KEEP_DATA to debug <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1996>
<cachio> mvo, the problem of enabling bionic-proposed is that I need to doit suring the prepare, is it ok?
<pedronis> #4829 and #4849 also needs reviews
<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>
<mup> PR #4849: many: propagate contexts enough to be able to mark store operations done from the Ensure loop <Created by pedronis> <https://github.com/snapcore/snapd/pull/4849>
<mup> PR snapd#4849 opened: many: propagate contexts enough to be able to mark store operations done from the Ensure loop <Created by pedronis> <https://github.com/snapcore/snapd/pull/4849>
<cachio> mvo, it will be temporal until is it enabled by default
<mvo> cachio: yeah, I think thats ok
<Chipaca> mvo: how would you feel about sliding 4834 into .32?
<Chipaca> #4834
<mup> PR #4834: snap/squashfs: when installing from seed, try symlink before cp <Created by chipaca> <https://github.com/snapcore/snapd/pull/4834>
<mup> PR snapd#4834 closed: snap/squashfs: when installing from seed, try symlink before cp <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4834>
<mvo> Chipaca: let me look
<ondra> zyga-ubuntu ping
<mvo> Chipaca: absolutely
<Chipaca> mvo: cd7a41b921446bff4ad02ceacf1811c1a6319cc7 fwiw
<mvo> Chipaca: I cherry-pick
<zyga-ubuntu> Hey ondra
<ondra> zyga-ubuntu hey, I have asked this before, but when using layouts, what was the process to read original file?
<mvo> Chipaca: ta
<zyga-ubuntu> ondra: you can attempt to use hostfs
<ondra> zyga-ubuntu any how to do that?
<pedronis> Chipaca: having early lunch, we can chat in ~40 ?
<Chipaca> pedronis: sure
<zyga-ubuntu> ondra: re, sorry, I was afk
<zyga-ubuntu> ondra: so, you can look at the file in /var/lib/snapd/hostfs/$F
<zyga-ubuntu> ondra: but you will need an interface for t hat
<mup> PR snapd#4850 opened: many: fix shellcheck warnings in bionic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4850>
<ondra> zyga-ubuntu which interface is that?
<zyga-ubuntu> none exists now
<Chipaca> mvo: the spellcheck check is also broken in xenial, fwiw, we just don't run it
<zyga-ubuntu> it would depend on $F for sure
<ondra> zyga-ubuntu :)
<zyga-ubuntu> as otherwise it would let  you read any file
<ondra> zyga-ubuntu right
<mvo> Chipaca: spellcheck or shellcheck? I don't mind so much about the spellcheck, we might as well disable it and only run it via a nightly job
<Chipaca> shellcheck
<Chipaca> ah
<Chipaca> sorry
<Chipaca> :-)
<mvo> oh, ok
<zyga-ubuntu> sheepcheck
 * Chipaca shellchecks his spellchecker
<mvo> shellshock
<ondra> zyga-ubuntu wouldn't be easier to allow hook to run before bind mount, and then we can rely on existing permissions?
<Chipaca> ah wait, yes, shellcheck, we're talking of the same thing
<zyga-ubuntu> ondra: no, it's not easy in any way
<ondra> zyga-ubuntu right
<zyga-ubuntu> ondra: and it would still need an interface
<Chipaca> mvo: shellcheck does not run as part of tests; it's not installed on the images
<zyga-ubuntu> ondra: as this way you could read abritrary files
<zyga-ubuntu> ondra: our current design assumes that applications cannot observe pre-layout filesystem at any stage
<zyga-ubuntu> so no partial state is expsed
<ondra> zyga-ubuntu ok, so hostfs it is then
<zyga-ubuntu> as our apparmor profile assumes the layout is in place
<zyga-ubuntu> and grants permissions to the places affected by the layout
<ondra> zyga-ubuntu ah, OK that makes sense
<mborzecki> zyga-ubuntu: regarding #4571 we could move configure.ac/autogen.sh to the top of snapd tree
<mup> PR #4571: data, cmd, packaging: use autotools to generate artifacts under data <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4571>
<zyga-ubuntu> ondra: my advice is to open a thread to request an interface for reading hostfs file (specific file) so that we can grant this
<zyga-ubuntu> mvo: what do you think about mborzecki's proposal?
<zyga-ubuntu> I'm okay but we had a discussion with that and this is how we ended up with "autotools is hidden in cmd/"
<ondra> zyga-ubuntu OK will do
<cachio> zyga-ubuntu, that should be fixed? https://travis-ci.org/snapcore/snapd/builds/353519499#L5247
<cachio> zyga-ubuntu, or it is still in progress
<zyga-ubuntu> cachio: no, not yet. I'm working on that now
<cachio> zyga-ubuntu, ah, ok, thanks
<mvo> zyga-ubuntu: I think to think but to me autotools is just something I dislike whereever it lifes
<mvo> zyga-ubuntu: I mean "I need to think"
<zyga-ubuntu> mvo: any ideas as to what to do then?
<zyga-ubuntu> should we move away from autotools
<zyga-ubuntu> or just use it consistently
<mvo> zyga-ubuntu: sorry, I know my comment was not helpful. but yeah, either consistently or switch but switching must be worth it, mesons seems to be popular but I'm not sure its sufficiently better
<mvo> (to justify the cost)
<mborzecki> mvo: xenial version of meson is outdated, and afaik it's not available in trusty at all
<ondra> zyga-ubuntu mvo any idea what could be causing "run hook "post-refresh": execv failed: No such file or directory"
<zyga-ubuntu> hmmm,
<zyga-ubuntu> ondra: what does the hook look like?
<ondra> zyga-ubuntu https://pastebin.ubuntu.com/p/w22S3q9Y2D/
<ondra> zyga-ubuntu :)
<ondra> zyga-ubuntu I trimmed it down, as I can't figure out what is the problem
<zyga-ubuntu> so you refresh a snap and the hook fails to run?
<zyga-ubuntu> is it reproducible?
<ondra> zyga-ubuntu I have install hook which runs just fine I did sym link as I usually do and it failed to run
<ondra> zyga-ubuntu install works
<zyga-ubuntu> symlink?
<ondra> zyga-ubuntu happening all the time
<ondra> zyga-ubuntu that was before
<zyga-ubuntu> pstolowski: ^ wanna look?
<ondra> zyga-ubuntu so I replaced sym link with file, and still same
<pstolowski> ondra: can you share that snap?
<ondra> pstolowski yeah preparing to share it
<ondra> pstolowski zyga-ubuntu damn, I did clean build and now it works, and I did same before
<zyga-ubuntu> do you have the old snap?
<ondra> so can't reproduce it now
<zyga-ubuntu> maybe look inside
<ondra> zyga-ubuntu so I was using snap try
<ondra> zyga-ubuntu and without rebuild I was modifying prime/meta/hook
<mup> PR snapd#4848 closed: many: cherry-pick relevent `go vet` 1.10 fixes to 2.32 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4848>
<pedronis> Chipaca: I'm back
<Chipaca> pedronis: wb :)
<Chipaca> pedronis: so, if I understand your point of view, using puritan for everything stringish isn't a sustainable practice
<ondra> zyga-ubuntu pstolowski http://people.canonical.com/~okubik/git_2.7.4_amd64.snap
<ondra> zyga-ubuntu so I'm using snap try, so unsquash it first
<pedronis> Chipaca: indeed
<pstolowski> ondra: could this be a missing -x on the hook script?
<ondra> zyga-ubuntu pstolowski so now I have different problem, it will install, but if I try to run I get execv failed: No such file or directory
<Chipaca> pedronis: OTOH my point of view is that unless we do something for every stringish thinig, we're going to eventually miss one we shouldn't
<ondra> zyga-ubuntu pstolowski do $ snap try <>; it will run, call $ snap try <> on same directory and it will break
<Chipaca> pedronis: would you be happier with using a lot more types, for example?
<pedronis> Chipaca: no in general
<pedronis> Chipaca: we need  tooling and a way to mark things
<pedronis> Chipaca: I find needing a special type for snap-id very suspect
<pedronis> it feels very cargo cultish
<Chipaca> pedronis: when you say tooling, do you mean a static checker, or do you mean a json decoder replacement?
<pedronis> whatever works
<pstolowski> ondra: what core are you running with?
<pedronis> Chipaca: atm we are just making a bit of code uglier without clear path forward
<ondra> pstolowski 16-2.31.2+git610.7a79b84 (4243)
<Chipaca> pedronis: what would you do?
<pedronis> Chipaca: also whatevedr is problematic with the store is likely problematic with snap.yaml
<pedronis> as well
<pedronis> Chipaca: I don't know, I'm not even sure I agree with your premise
<pedronis> that we really need to worry about everything
<pedronis> but if we do need to worry about everything the current approach alone doesn't cut it
<Chipaca> pedronis: because of the lack of a static checker?
<pstolowski> ondra: ok, same core here. I un-suqashed it, did snap try twice, it worked. can you do 'snap changes' to find changes correspondin to your snap-try commands, and then 'snap change <ID of the change>' for both to see more info about the failure?
<pedronis> Chipaca: it seems we need to mark all structs with json or yaml tags as either risky or not and then decide what to do with each
<mborzecki> zyga-ubuntu: mvo: tried having just cmd/configure.ac and doing AC_CONFIG_FILES([../data/Makefile ..]) but that doesn't work, the resulting makefiles do some silly thing and try to cd one level above snapd checkout
<pedronis> though sometimes we use map[string]interface{} directly, maybe not on input
<pedronis> not sure
<zyga-ubuntu> mborzecki: thank you for confirming that
<mborzecki> zyga-ubuntu: mvo: just moving configure.ac and autogen.sh to the top level dir (plus adjusting paths) is enough, it will clutter the directory once you autoreconf but at least both cmd and data are built using autohell
<zyga-ubuntu> mborzecki: yeah,
<zyga-ubuntu> you have my +1 but convince gustavo as he was opposing it before
<Chipaca> pedronis: that's a mountain of work, but it does seem the logical conclusion
<mborzecki> zyga-ubuntu: we could easily say with the hack that's right now in the PR :P works too, and does not clutter the directory
<pedronis> Chipaca: well, the non logical solution is say we need to care about everything but then leaving it up to reviewers
<mborzecki> Chipaca: could we do a silly hack with reflection and field tags perhaps?
<ondra> pstolowski https://paste.ubuntu.com/p/7J8yPTrmBG/
 * cachio afk
<mborzecki> Chipaca: then have an unmarshaller that wraps json and goes to inspect all the strings to clean them up, unless there's a tag that says to leave the string as it is
<mborzecki> pedronis: ^^
<pedronis> there are probably a few possible approaches
<pedronis> there are also concerns about runtime speed
<pedronis> also personally don't think we should write a full new json decoder
<mborzecki> agreed, i'm not propsing to write a json decoder, just sanitize the structs when they come out of the decoder somehow, in a separate call perhaps
<ondra> pstolowski here you have whole test https://paste.ubuntu.com/p/2q7PH8cqk4/
<ondra> pstolowski from snap remove
<pedronis> Chipaca: now we also need to understand what everything means,  I suppose you mean that for example store generated error messages are also a concern?
<ondra> pstolowski exactly same error I was getting before about configure hook
<pedronis> Chipaca: IÂ mean is our attacker a user of the store, or the store?
<ondra> pstolowski need to run for lunch, but will be available later
<pedronis> (there are blurry lines there but it still make a difference where to spend our energy)
<Chipaca> pedronis: if it's the store itself i think things fall apart
<Chipaca> pedronis: but, the problem is bugs
<pedronis> I understand
<pedronis> but there are all sorts of bugs
<Chipaca> pedronis: I mean, #1750527 is the bug
<mup> Bug #1750527: dashboard does not validate text fields <review-tools:Triaged by jdstrand> <Snapcraft:New> <snapd:In Progress by chipaca> <Snap Store:Fix Released by matiasb> <https://launchpad.net/bugs/1750527>
<Chipaca> pedronis: even with that change, it's not clear to me everything textish from the store is validated
<pedronis> Chipaca: I'm not arguing for doing nothing, but I'm also not happy to do something cargo cultish and unbounded
<Chipaca> pedronis: I understand, but if the alternative to cargo culting something is having to make a decision about every single field, cargo culting starts to look good
<pedronis> Chipaca: you are saying we should use the store data without knowing what it is / what it is about
<Chipaca> pedronis: "is this something that can be edited by third parties, and is it going to be shown to the user" seemed to be the question
<Chipaca> the first half we can probably answer easily
<pedronis> Chipaca: and snap-id is dubious?
<pedronis> anyway  at this point as I said even if we continue to use string for some things
<pedronis> as I said we need to worry about all the json and all the yaml
<Chipaca> I don't think snap-id is dubious, no
<pedronis> but you made a puritan.SimpleString
<Chipaca> but if you make everything not be a string, you can write a really silly static checker
<Chipaca> the alternative is tagging, which isn't hard (but I hadn't thought of it in this context)
<pedronis> I'm skeptical of that
<pedronis> (the silly part)
<Chipaca> pedronis: it'd be only a little more work than the check in daemon for commands
<pedronis> ?
<pedronis> we define local types sometimes to parse json
<Chipaca> ok
<Chipaca> pedronis: so what do we do
<pedronis> it seems like we need to introduce safejson and safeyaml,   and not use json and yaml, as thin wrappers and go from there
<pedronis> with a silly check that we don't use the other diretly in non-tests
<Chipaca> pedronis: what are safejson and safeyaml?
<pedronis> Chipaca: packages with a subset of what is offered by json and yaml
<pedronis> we can probably then make them have different behavior at test time vs runtime
<pedronis> and at test time they could check the rules that we make for target types
<pedronis> Chipaca: it seems the only approach to make sure we cover all the ground  (I'm a bit worried about the messiness of dealing with our various uses of json statically)
<pedronis> though yaml is probably worse, all of it comes from the user
<pedronis> by definition
<pedronis> if we don't trust snapcraft
<pedronis> otoh we have validation there
<pedronis> Chipaca: are you saying that we should do validation for snap.yaml but not trust any string from the store?
<pedronis> it seems asymmetric, but maybe there's a good reason
<Chipaca> pedronis: aborting a 'snap find' because one of the results had a bogus entry seemed a poor choice
<Chipaca> pedronis: aborting a 'snap install' because of the same seems fine
<pedronis> yea, but validation doesn't check all the fields at the moment
<pedronis> does it?
<Chipaca> it does not
<pedronis> we might print a non-validated field
<pedronis> (for reasons)
<Chipaca> yes
<Chipaca> but it'd be fairly straightforward to fix that
<pedronis> Chipaca: I fear you opened a can of worms
<Chipaca> pedronis: it was already open :-) i might've kicked it a little
<pedronis> Chipaca: anyway  you mighe decide to go validation only for snap.yaml (but we have also other yaml files, like gadget yaml)
<pedronis> but we still need a scalable solution for all the json from the store
<Chipaca> pedronis: (just to keep things interesting, what should it do if the snap yaml ini the json fromo the store is invalid? :) )
<pedronis> are we not validating it?
<Chipaca> pedronis: the one in details? probably not
<pedronis> anyway it's a corner case that shows cargo culting with naive types is not great
<pedronis> false security effect
<pedronis> anyway IÂ think we validate it
<pedronis> and if it's invalid we ignore it
<pedronis> or maybe not
<pedronis> let me check
<pstolowski> ondra, ah wait, the execv error comes from running the app, it's not hooks
<pedronis> Chipaca: no, it's not validated atm
<pedronis> just parsed
<pedronis> we ignore it on "parse" errors but not validation (that we don't do)
<pstolowski> ondra: but ok, i can reproduce what you pasted, investigating
<pedronis> Chipaca: so what I would do is have a way to enforce needing to tag all json fields as either  "user" or something else, all user fields need one of the special dedicated types
<pedronis> (for values of all)
<pedronis> Chipaca: still would need  a plan about how to make sure we validate all snap.yaml fields
<Chipaca> pedronis: would something like puritan still be useful in this context?
<pedronis> Chipaca: yes,   as IÂ said we would String and Paragrah
<pedronis> for some of the user fields
<Chipaca> pedronis: and in particular, if I just used puritan for the known-problematic fields today would that be a reasonable zeroth step
<pedronis> Chipaca: yes,  starting with just a few fields  would an accetable first step
<pedronis> we probably don't need or shouldn't need SimpleString though
<pedronis> for that step
<pedronis> unless I'm confused
<Chipaca> ok, I'll prune puritan back to just those, and nuke everthing but paragraph and string
<Chipaca> (they can easily be brought back -- i'll leave the flags in the underlying code)
<pedronis> Chipaca: I'm also not sure puritan will not offende somebody as a name
 * Chipaca grins
<Chipaca> it's a silly name, but I don't think there are puritans left
<Chipaca> i might be wrong though
<Chipaca> pedronis: i could call it 'safejson', and then also use it to house the tag checker
<pedronis> seems reasonable (to me)
<Chipaca> although this is a particular brand of safe (but then, safe always is)
<Chipaca> safe-against-global-thermonuclear-war
<Chipaca> termite-safe vs thermite-safe, etc
<Chipaca> (also, does termite-safe mean termites can eat it, or won't eat it?)
 * Chipaca needs lunch
<pedronis> mvo: Chipaca: do we have a fix now with test layout and /etc?  do IÂ just need ot merge master
<Chipaca> pedronis: AFAIK the layout test is still a flake
<pedronis> fun not :/
<pstolowski> ondra: I installed your snap normally, then uninstalled, then snap try works. something is fishy here...
<Chipaca> pstolowski: what's going on?
<pedronis> Chipaca: contact(_url) is intersteting btw, it seems we need a type that validates urls or blanks them
<Chipaca> ungh
<Chipaca> pedronis: have you seen the data in contact
<pedronis> it's random?
<pedronis> I thought it was supposed to be a http: or mailto: url
<mborzecki> hm there's a govalidator package that can do some of this magic
<mborzecki> you basically set validate tags in struct fields and then call ValidateStruct()
<mborzecki> Chipaca: pedronis: https://godoc.org/github.com/asaskevich/govalidator
<pedronis> interesting but seems not what we want (speedwise)
<mborzecki> we've used it in mender for some of the APIs
<pedronis> if IÂ understood Chipaca's worries
<pedronis> we need more of a metavalidator than a validator
<mborzecki> speedwise is subjective, my guess would be the i/o part of working with store will be longer than the validation :)
<pedronis> that's not what I gathered from John at the sprint
<pedronis> he was worried about double decoding utf8 basically
<mborzecki> the github page has some nice examples https://github.com/asaskevich/govalidator
<pedronis> anyway our current problem is not so much validation (we have the code), is make sure all the fields
<pedronis> are setup properly for it
<mborzecki> pedronis: yes, that's what i recall to, but looks like we're moving towards verifying the contents/structure of respective fields
<Chipaca> pedronis: mborzecki: well... i wasn't worried about the double utf8 decode, per se
<Chipaca> pedronis: mborzecki: but i needed to do most of the work anyway
<pedronis> it might be underasting for snap.yaml
<Chipaca> that's why it ended up doing it directly
<pedronis> heh
<pedronis> IÂ meant "interesting"
<pedronis> otoh unless is perfect not sure we want one more dep
<pedronis> mborzecki: for  store json we have more of cleaning up problem, than a validation one
<pedronis> if IÂ understand
<zyga-ubuntu> mvo: I have the first and harder half of the layouts fix
<zyga-ubuntu> shall I push it to 4847 so that it can be squashed
<zyga-ubuntu> or would you like to see separate commits
<Chipaca> pedronis: mborzecki: we can also decide to drop invalid json on the floor
<zyga-ubuntu> I haven't pushed the fix there yet, just the prerequisite helpers
<Chipaca> pedronis: mborzecki i'd be fine with taht if we can do it at the snap level
<Chipaca> that is, in a search result, drop individual results
<Chipaca> but then... a typo in a description would stop a snap refresh
<Chipaca> not sure we want that
<Chipaca> (granted you'd really need to work hard to get a typo now the store is fixed)
<pedronis> Chipaca: doesn't that apply to snap.yaml too though?
<pedronis> if the description  comes from the snap.yaml then we clean from the store, but fail when we install anyway?
<Chipaca> pedronis: indeed. and even more vocally.
 * Chipaca turns up the 'everything is terrible' dial another notch, and goes to get some tea
<zyga-ubuntu> Chipaca: hey, sorry for being late with that patch; could you look at 4847, this adds the symlinkat and realinkat functions
<zyga-ubuntu> and some testing helpers
<zyga-ubuntu> it's used in upcoming fix
<Chipaca> zyga-ubuntu: realinkat?
<pedronis> zyga-ubuntu: it's "cannot update snap namespace: cannot create writable mimic over "/etc": no such file or directory" fixed or are you working on that still?
<Chipaca> but yes, after tea is brewed
 * pedronis has lost track
<zyga-ubuntu> I meant to say readlinkat
<zyga-ubuntu> Thank you!
<Chipaca> pedronis: that's the fix he's talking about
<Chipaca> right now :-)
<pstolowski> ondra: ah, ignore my earlier comment, second snap try breaks it
<zyga-ubuntu> pedronis: that's what I fixed just now, it will be a PR in a moment
<zyga-ubuntu> pedronis: just trying to coordinate that with mvo for release (one PR, many PRs, squash or not, etc)
<mup> PR snapd#4836 closed: tests: force profile re-generation via system-key <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4836>
<pedronis> zyga-ubuntu: that's fine, just trying to understand whether IÂ needed to re-run the tests or merge master first
<zyga-ubuntu> re run now
<mup> PR snapd#4838 closed: snapstate: put layout feature behind feature flag <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4838>
<mup> PR snapd#4851 opened: cmd/snap-update-ns: fix creation of layout symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4851>
<zyga-ubuntu> mvo: I've opened https://github.com/snapcore/snapd/pull/4851 to get a feel of the fix in the wild
<mup> PR #4851: cmd/snap-update-ns: fix creation of layout symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4851>
<zyga-ubuntu> after standup I need to go to the doctor again but the 2nd fix for layouts is easier so I will push the PR after returning
<pstolowski> zyga-ubuntu: can you remind me/brief me on how do I inspect namespaces of a snap?
<mup> PR snapd#4809 closed: cmd/snap: tweak and polish help strings <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4809>
<zyga-ubuntu> pstolowski: use nsenter
<zyga-ubuntu> nsenter -m/run/snapd/ns/foo.mnt
<mup> PR snapd#4852 opened: snapstate: put layout feature behind feature flag <Created by mvo5> <https://github.com/snapcore/snapd/pull/4852>
<pstolowski> niemeyer: having network issues, will join in a few moments
<soee_> hey are there any plans to fix the ugly looking snap apps their icons in launchers etc?
<zyga-ubuntu> pstolowski: can you please pastebin the meta/snap.yaml
<zyga-ubuntu> pstolowski: I have a suspicion I know what's going on
<pstolowski> zyga-ubuntu: https://pastebin.ubuntu.com/p/8tCdGtRTcp/
<zyga-ubuntu> pstolowski: aha, that's curious
<zyga-ubuntu> that's not what I assumed
<zyga-ubuntu> can you paste the URL of the snap pelase
<zyga-ubuntu> *please
<zyga-ubuntu> I'll pull and explore
<pstolowski> zyga-ubuntu: http://people.canonical.com/~okubik/git_2.7.4_amd64.snap
<pstolowski> zyga-ubuntu: unsquash and snap try twice
<zyga-ubuntu> thanks
<pstolowski> zyga-ubuntu: ty! let me know what's the outcome
<zyga-ubuntu> I will only check after my doctor appointment though
<pstolowski> sure
<mborzecki> Chipaca: are you fixing snap info output?
<Chipaca> mborzecki: yes
<mborzecki> Chipaca: idk why, but even `fmt.Fprint(w, formatDescr(both.Description, termWidth))` tries to expand %
<Chipaca> mborzecki: it's not formatDescr
<Chipaca> mborzecki: it's strutil.WordWrap
<Chipaca> mborzecki: which is the same one munging the indents
<Chipaca> mborzecki: so guess who's throwing it away
<Chipaca> <- this guy
<Chipaca> :-)
<mborzecki> Chipaca:
<ondra> pstolowski hey
<mborzecki> Chipaca: https://paste.ubuntu.com/p/qXH3Bk4Zkt/ pff poor man's fix, but if it's WordWrap breaking it then strutil is probably better place to fix it
<ondra> pstolowski back now, I saw you can reproduce it now
<ondra> pstolowski anything else I can assist with?
<pstolowski> ondra: yeah, I got to the point where I can point my finger at what breaks and handed it over to zyga as it's his domain, he will look at it
<zyga-ubuntu> I'm going to see a doc now, I'll check it out after that ondra
<zyga-ubuntu> definitely feels like my type of problem
<ondra> zyga-ubuntu yeah no time pressure from me, it's not blocking me personally, just found it as very interesting problem, so happy to help if there need
<zyga-ubuntu> I know what to look at, I'll let you know when I understand the problem
<Chipaca> mborzecki: yeah, by the time formatDescr gets it it's already happened
<mborzecki> Chipaca: http://paste.ubuntu.com/p/F3y8NcpYQZ/
<ondra> zyga-ubuntu thanks bunch :)
<Chipaca> mborzecki: pretty much yes, but as I said on the list, the indent munging needs to die
<mborzecki> Chipaca: death by 1000 tabs
<Chipaca> :-)
<pedronis> niemeyer: #4825 is the PR that needs a 2nd look
<mup> PR #4825: overlord/snapstate:  implement policy of holding refreshes for 2h since seeding on classic <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4825>
<zyga-ubuntu> ondra: I know what the problem is, something for me to fix in do-undo logic for mounts
<zyga-ubuntu> thanks for bringing this to my attention, I will focus on it ASAP
<ondra> zyga-ubuntu happy to help :)
<mborzecki> off to pick up the kids
<mup> PR snapd#4825 closed: overlord/snapstate:  hold refreshes for 2h after seeding on classic <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4825>
<MincePies> Question: After installing spotify snap in Elementary OS - How Do I Start It ?
<kyrofa> MincePies, if they don't pick up the desktop file, check in /snap/bin
<kyrofa> There should be an executable in there you can run
<Chipaca> MincePies: if you just installed snapd, you might need to log out before it has the paths set up right, but you should be able to do 'snap run spotify' (or /snap/bin/spotify if elementary ships it as /snap)
<Chipaca> brb, rebooting
<mup> PR snapd#4853 opened: overlord/snapstate: hold refreshes for 2h after seeding on classic <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4853>
<pedronis> mvo: ^  IÂ made the backport for that bit
<jjohansen> zyga-ubuntu: I'm building test kernels, is there one you would like in particular
<cachio> niemeyer, hey
<cachio> remember the spread issue that I told you during the standup?
<niemeyer> cachio: Hey, sure
<cachio> niemeyer, well, the real problem was different
<niemeyer> cachio: Not surprised ;)
<cachio> debian is killing the networking before the ssh sessions
<cachio> it is a known issue
<niemeyer> cachio: What does that mean in more detail?
<cachio> when we reboot
<cachio> systemd is stopping the network services
<cachio> in this debian
<cachio> it is stopping first the network connection and then the ssh sessions
<niemeyer> How's that an issue?
<cachio> in that case spread is not getting that the session is closed
<cachio> so then when it tries to connect to detect the machine is rebooted
<cachio> it is to late
<cachio> the machine is up again
<cachio> bebian is taking between 7 and 8 seconds to start
<cachio> ubuntu is taking + than 12
<niemeyer> Ah, I see.. the connection is silently dropped
<cachio> yes
<niemeyer> Okay, that makes more sense
<cachio> I created a service to force to stop the ssh sessions before the network
<cachio> when we reboot
<cachio> and the problem is gone
<niemeyer> I'd prefer to workaround it in a way that makes spread more resilient
<niemeyer> Hmm
<cachio> otherwise I could add a keepalive in spread when we reboot
<cachio> to detect if the ssh session is gone
<niemeyer> cachio: Won't work.. too short a time
<niemeyer> cachio: I suggest the following: let's drop all the waits, and make spread look at the actual uptime
<cachio> niemeyer, ok
<niemeyer> cachio: Instead of waiting for the disconnection, it disconnects by itself automatically when asking for the reboot
<niemeyer> cachio: And then immediately tries to reconnect and check the uptime
<niemeyer> cachio: Repeat until timeout
<cachio> niemeyer, ok, makes sense
<cachio> I'll try that
<niemeyer> cachio: WE need to make this logic resilient as we'll often see errors mid-routine
<cachio> which errors?
<cachio> you mean the failed attempts?
<cachio> niemeyer,
<cachio> I'll try that and push it
<cachio> after lunch :)
<cachio> niemeyer, thanks
<niemeyer> cachio: np, thanks for figuring it out
<niemeyer> cachio: I suggest using this to figure the latest boot time:
<niemeyer> date -u --iso-8601=seconds -d "`cut -f1 -d. /proc/uptime` seconds ago"
<niemeyer> cachio: There are backticks in that message, which hopefully your IRC client did not interpret
<niemeyer> cachio: Ah, even better:
<niemeyer>  date -u --iso-8601=seconds -d "$(cut -f1 -d' ' /proc/uptime) seconds ago"
<niemeyer> cachio: Then, we need to tolerate a delta of up to, say, 3 seconds, since there will be a difference between the time we read the uptime from the time date makes the syscall to pick up the time
<Chipaca> niemeyer: cachio: or, you know, 'uptime -s'
<Chipaca> :)
<Chipaca> i'm going to go offline for a while, will bbl
<niemeyer> Chipaca: Does it use utmp or proc?
 * niemeyer checks
<niemeyer> (we want proc)
<Chipaca> should still be able to push the fix for snap info tonight
<niemeyer> Apparently proc, so that's nicer indeed, thanks!
<Chipaca> niemeyer: proc; utmp for who's logged in
 * Chipaca vanishes in a cloud of []rune
<niemeyer> Except cut and date come from coreutils, and uptime comes from procps
<niemeyer> Probably good enough
<MincePies> well that worked - only just! https://paste.ubuntu.com/p/Dj5nxS7t8g/
<MincePies> Where can I find a list of snaps to test ?
<cachio> niemeyer, ok, so I'll use 'uptime -s'
<niemeyer> cachio: Sounds good, thanks
<MincePies> Where can I find a list of snaps to test ?
<MincePies> I have a 1 teraByte SSD
<pedronis> I'm getting again  Job for snapd.service canceled.  on 14.04
<pedronis> did we find what was it about?
<cachio> pedronis, do you have a log?
<cachio> to see where is it failing
<pedronis> cachio:  https://travis-ci.org/snapcore/snapd/builds/353848109?utm_source=github_status&utm_medium=notification  3 prepares on 14.04 are failing with that
<cachio> pedronis, it was giving that error when we tried to stop it and it was not in running state
<cachio> pedronis, it is failig in another place now
<cachio> pedronis, a solution is to encapsulate the stop into a function and there check before the status and then stop the service
<pedronis> it's failing like this on a couple of my branches
<pedronis> that have very different changes
<cachio> pedronis, so, perhaps it is something new
<pedronis> master is also red
<pedronis> trying to see which way
<cachio> same error on master
<cachio> something changed
<pedronis> yes
<cachio> pedronis, I'll take a look
<cachio> right now
<cachio> thanks for the headsup
<mup> PR snapd#4854 opened: devicestate: introduce DeviceManager.Registered returning a channel closed when the device is known to be registered <Created by pedronis> <https://github.com/snapcore/snapd/pull/4854>
<zyga-ubuntu> re
 * zyga-ubuntu needs more examinations 
<zyga-ubuntu> aww, pushed go fmt fixes
<MincePies> question, Where can I find a list of snaps for testing, please ?
<mcphail> https://snapcraft.io/store ?
<mcphail> https://uappexplorer.com/snaps
<MincePies> mcphail: how do I get this to go? https://uappexplorer.com/snap/ubuntu/software-boutique
<mcphail> MincePies: I've never used that snap. I think it is fairly specific for Ubuntu Mate. flexiondotorg may be able to clarify for you
<MincePies> Who is he ?
<zyga-ubuntu> MincePies: he's affiliated with Ubuntu Mate
<mcphail> He's the creator of that snap
<MincePies> Lets see if he shows-up, then (?)
<mcphail> Generally, if you have a snap installed, "snap info name_of_snap" will tell you which commands can be run
<MincePies> Brilliant & Its my first snap install! https://imgur.com/CHByC6U
<ogra_>  oh zyga-ubuntu ....
<ogra_> zyga-ubuntu, will you take pictures of the crowd with pitchforks in fromt of your house ?
<ogra_> "Because flatpak is not the future ..."
<zyga-ubuntu> ogra_: in poland? they will be lost at the train station
<ogra_> lol
<zyga-ubuntu> "track 6 at platform 4 in sector 8"
<zyga-ubuntu> all said in gibberish polish with poor speakers
<zyga-ubuntu> and once they come here they will become infected
<zyga-ubuntu> and then half of them will oppose the other half
<zyga-ubuntu> and they will discuss a substitute topic instead
<zyga-ubuntu> wanna do a code review?
<MincePies> zyga-ubuntu: > wanna do a code review? Answer: Yeah.
<zyga-ubuntu> MincePies: hey
<zyga-ubuntu> I have two related PRs
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4847
<mup> PR #4847: osutil,testutil: add symlinkat(2) and readlinkat(2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4847>
<zyga-ubuntu> and https://github.com/snapcore/snapd/pull/4851
<mup> PR #4851: cmd/snap-update-ns: fix creation of layout symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4851>
<zyga-ubuntu> I will happily take feedback
<MincePies> zyga-ubuntu: I don't Like this: https://paste.ubuntu.com/p/H944SV4kc3/
<zyga-ubuntu> can you be more specific?
<MincePies> Will it work on debian ?
<zyga-ubuntu> yes, why would you worry about that?
<zyga-ubuntu> this is an unit test for a testing helper
<zyga-ubuntu> it will work on any system
<MincePies> zyga-ubuntu:  > it will work on any system | That's abit 'headed' there.
<zyga-ubuntu> ?
<MincePies> Have you tried Rosa ?
<zyga-ubuntu> it will work on windows and macos and plan9
<zyga-ubuntu> because it's totally unrelated to the system
<zyga-ubuntu> because it's a mocking helper for testing other parts of the code
<MincePies> What is a mocking helper, then, when its at home?
<zyga-ubuntu> sorry, I'm looking for people who can review my code
<MincePies> he doesn't know.
<zyga-ubuntu> internet is a funny place
<zyga-ubuntu> jjohansen: hey, do you have a patch I could pull and try out?
<mup> PR snapd#4839 closed: errtracker: respect the /etc/whoopsie configuration <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4839>
<mup> PR snapd#4853 closed: overlord/snapstate: hold refreshes for 2h after seeding on classic (2.32) <Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4853>
<mup> PR snapd#4285 closed: tests, spread: add Arch Linux to CI systems <Created by bboozzoo> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4285>
<mup> PR snapd#4855 opened: Translate polkit strings <Created by gunnarhj> <https://github.com/snapcore/snapd/pull/4855>
<mup> PR snapd#4852 closed: snapstate: put layout feature behind feature flag (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4852>
<oSoMoN> sergiusens, is https://forum.snapcraft.io/t/custom-environment-variables-for-parts/1639/9 being planned / worked on yet?
<oSoMoN> (I might be able to take a stab at it if not)
<zyga-ubuntu> hmmm
<zyga-ubuntu> I'm getting consistent failures
 * zyga-ubuntu wonders what changed
<zyga-ubuntu> + systemctl stop snapd.service snapd.socket
<zyga-ubuntu> Job for snapd.service canceled.
<cachio> zyga-ubuntu, I have fixed that
<zyga-ubuntu> mvo: if you are around, do you have any idea what may have changed?
<zyga-ubuntu> oh
<zyga-ubuntu> cachio: shall I pull master?
 * zyga-ubuntu hugs cachio :-)
<cachio> no yet
<zyga-ubuntu> what do I need?
<cachio> I was testing that
<cachio> I'll push in 5 minutes
<zyga-ubuntu> excellent, thank you
<zyga-ubuntu> I will send kids to bed in the meantime
<sergiusens> oSoMoN: no, not on the roadmap; we could plan for it in Berlin.
<mvo> zyga-ubuntu: hey
<mvo> zyga-ubuntu: I am around, what is the question
<oSoMoN> sergiusens, please do :) I won't be in Berlin but I'll be tracking it
<mup> PR snapd#4856 opened: release: 2.32~pre2 changelogs <Created by mvo5> <https://github.com/snapcore/snapd/pull/4856>
<sergiusens> oSoMoN: if you want to implement I would not be against that either ;-)
<mwhudson> zyga-ubuntu: morning
<mwhudson> zyga-ubuntu: "We can check that we are on an overlayfs, look at the upperdir and check if it is a tmpfs." <- does this mean parsing /proc/mounts or something else?
<mwhudson> if so, does snapd already have code for this?
<cachio> zyga-ubuntu, #4857
<mup> PR #4857: tests: adding checks before stop snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4857>
<mup> PR snapd#4857 opened: tests: adding checks before stop snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4857>
<cachio> is not a super elegant solution but should work
<cachio> We already used that in the past to fix the same problem in the reset
<mwhudson> mmm osutil/mountinfo.go looks like a good start ;)
<mup> PR snapd#4855 closed: data: translate polkit strings (2.32) <Created by gunnarhj> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4855>
<zyga-ubuntu> re
<zyga-ubuntu> hey good morning
<zyga-ubuntu> mwhudson: we have code for this already
<zyga-ubuntu> mwhudson: please look at ... (one sec)
<zyga-ubuntu> https://github.com/snapcore/snapd/blob/master/osutil/overlay.go#L44
<zyga-ubuntu> I believe this can be modified to return both upper and lower dir
<zyga-ubuntu> and then we can inspect the upper dir path to find the fstype
<mwhudson> oh heh that code looks installer relevant
<zyga-ubuntu> it is referenced from ..
<zyga-ubuntu> https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/backend.go#L114 and https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/backend.go#L441
<zyga-ubuntu> which means it ends up in both snap-confine and per-snap profiles
<zyga-ubuntu> er
<oSoMoN> sergiusens, I haven't looked into implementation details yet, but it looks like it shouldn't be too much work
<zyga-ubuntu> per app snap profiles
<mwhudson> yeah that makes sense
<zyga-ubuntu> we could use it as a starting point
<zyga-ubuntu> I think rather than doing elaborate mountinfo analysis just find upperdir and then fstatfs it
<mwhudson> i guess we should change code around here: https://github.com/snapcore/snapd/blob/master/overlord/snapstate/autorefresh.go#L134
<mwhudson> (which seems very fresh, hi pedronis)
<zyga-ubuntu> mwhudson: not sure, ask pedronis via the forum
<mwhudson> zyga-ubuntu: ack
<mvo> cachio: we might have a new 2.32~pre for amd64/i386 soon in beta
<mvo> cachio: arm seems to be a bit slow to build though
<cachio> mvo, perfect
<cachio> tomorrow afternoon I'll be off
<mvo> cachio: no worries
<cachio> mvo, but I can make the tests run
<mvo> cachio: getting it into beta and bionic is the key here, all else is bonus :)
<cachio> so should not be a problem
<mvo> cachio: thank you! that is great
<cachio> np
<zyga-ubuntu> cachio: so, what can I do to unblock PRs?
<cachio> zyga-ubuntu, we need to merge #4857  first
<mup> PR #4857: tests: adding checks before stopping snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4857>
<cachio> it is the first part of the solution
<zyga-ubuntu> ok, reading
<zyga-ubuntu> what's next?
<cachio> then I'll apply that to the other tests and scripts
<cachio> zyga-ubuntu, I just applied that for those tests that were failing
<cachio> basically it fails in tests with script which are stopping snapd in the first line
<cachio> in the prepare
<cachio> it happens because in the prepare-each the last line is starting the snapd.service and socket
<cachio> and for some reason now the start is taking more time than before
<zyga-ubuntu> cachio: can we use systemctl is-active?
<cachio> well, the problem is that the status "activating" makes the mess
<cachio> is-active returns true
<cachio> but it is not fully ready
<cachio> it is just happening in 14.04
<cachio> perhaps we could try to make a change in systemd to prevent that
<cachio> and/or see why the systemd service is taking more time to be active (running)
<zyga-ubuntu> hmm
<zyga-ubuntu> I mean
<zyga-ubuntu> it prints "active"
<zyga-ubuntu> I mainly ask because it looks cleaer than doing status and grepping
<zyga-ubuntu> *cleaner
<cachio> zyga-ubuntu, is-active is not enough
<cachio> zyga-ubuntu, that's the problem
<cachio> zyga-ubuntu, perhaps I am not getting you well, please add a comment in the PR
<zyga-ubuntu> nah, that's ok
<cachio> this solution is temporal
<zyga-ubuntu> I'm fine with good is better than perfect if it ships
<cachio> I think we need to figure out why it is happening now, and not before
<cachio> but I did that to unblock all the other PRs
<cachio> zyga-ubuntu, let's see if all the tests pass
<cachio> zyga-ubuntu, I just tested completion
<cachio> with repeat 50
<oSoMoN> I'm not finding any documentation on build-snaps. how does snapcraft expose the contents of the build-snaps once they are installed?
<mvo> cachio: i386 is in beta now
<mvo> cachio: looks like you need to shepherd amd64/arm* into beta, it takes a long time today :/
<mvo> cachio: or will do the rest in my morning, need to sleep now. cu
<oSoMoN> sergiusens, ^
<cachio> zyga-ubuntu, well, no errors for 14.04
<cachio> still missing to finish one test
<zyga-ubuntu> ok
<cachio> zyga-ubuntu, in green
<Chipaca> niemeyer: ping
<niemeyer> Chipaca: pong but on a call
<Chipaca> niemeyer: ah, give me a shout when you get off, i'll prepare some examples meanwhile
<zyga-ubuntu> Chipaca: wow, you're working late
<zyga-ubuntu> cnk
<zyga-ubuntu> cachio: is it merged?
<Chipaca> zyga-ubuntu: i don't work tomorrow, and i want to fix this snap info description thing
<cachio> zyga-ubuntu, let me check
<zyga-ubuntu> Chipaca: I understand the feeling
<zyga-ubuntu> plus
<zyga-ubuntu> I had coffee
<zyga-ubuntu> that wasn't a smart thing
<cachio> zyga-ubuntu, no reviews yet
<zyga-ubuntu> but it was leftover after some cake we made
<zyga-ubuntu> and now I'm here and looking at a bug
<cachio> Chipaca, zyga-ubuntu #4857
<mup> PR #4857: tests: adding checks before stopping snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4857>
<cachio> please take a look before merging it
<Chipaca> zyga-ubuntu: oooh, i have cake too
<Chipaca> but â¦ it's downstairs
<zyga-ubuntu> Chipaca: let's review 4857
<zyga-ubuntu> it shoud fix master
<Chipaca> i'm looking at it
<Chipaca> and scritching my head
<Chipaca> is systemd really this broken
<zyga-ubuntu> why
<zyga-ubuntu> heh
<zyga-ubuntu> that's a good question
<zyga-ubuntu> I'm inclined to slap a TODO on it and merge it because it's green
<zyga-ubuntu> and red sucks
<zyga-ubuntu> actually
<zyga-ubuntu> maybe we are just silly
<zyga-ubuntu> maybe the "cancelled" error just means
<zyga-ubuntu> yeah, it's off
<Chipaca> zyga-ubuntu: ?
<zyga-ubuntu> but returns an error
<Chipaca> ah, no
<Chipaca> zyga-ubuntu: cancelled means 'i couldn't queue that job you asked me to do'
<zyga-ubuntu> ah
<zyga-ubuntu> hmmm
<Chipaca> where 'that job' is stopping the thing
<zyga-ubuntu> did we report it upstream?
<Chipaca> zyga-ubuntu: AIUI it's fixed in a new enough systemd
<zyga-ubuntu> but not in 18.04
<Chipaca> also if we describe what we're doing to systemd in trusty i suspect pottering will weep
<Chipaca> zyga-ubuntu: isn't this 14.04 fix?
<zyga-ubuntu> but this was affecting 16.04 and others
<zyga-ubuntu> hmm
<zyga-ubuntu> one sec
<cachio> it is affecting just 14.04
<Chipaca> if we can catch it on a new enough  one, yes please let's report it
<Chipaca> i thought it was always trusty
<zyga-ubuntu> ah
<zyga-ubuntu> yes, just 14.04
<zyga-ubuntu> so...
<zyga-ubuntu> meh but yes
<zyga-ubuntu> I wonder why now it became so apparent
<zyga-ubuntu> did something change
<zyga-ubuntu> or is it just google cloud being "better"
<Chipaca> races are racy
<zyga-ubuntu> I have a feeling we are "winning" more often now
<Chipaca> niemeyer: depending on how busy your call is, if you want, take a look at http://people.canonical.com/~john/wrappers.txt
<Chipaca> niemeyer: bottom line the current formatDescr is very buggy, so  i rewrote it, but before pushing i thought i'd compare it with formatDescr and with go/doc's ToText
<Chipaca> niemeyer: in my book, i win
<Chipaca> niemeyer: but i thought i'd check with you
 * zyga-ubuntu -> Zzz
<niemeyer> Chipaca: Which one is yours? Top?
<Chipaca> niemeyer: the one labeled 'wordwrap'
<Chipaca> yes, top
<mup> PR snapd#4857 closed: tests: adding checks before stopping snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4857>
<niemeyer> Chipaca: A bit strange on acestreamplayer
<Chipaca> niemeyer: that's the 'respecting existing \n' thing
<niemeyer> Chipaca: Even worse on autopilot-qt
<niemeyer> Chipaca: I wonder if we should fold
<niemeyer> Chipaca: and respect empty lines instead
<Chipaca> niemeyer: knowing when to fold is hard
<niemeyer> Chipaca: Empty lines?
<Chipaca> niemeyer: look at firefox for an example of folding
<zyga-ubuntu> just buy 100 nvidia GPUs and have them AI the problem away
<Chipaca> zyga-ubuntu: Zzz
<niemeyer> Chipaca: I see..
<Chipaca> zyga-ubuntu: (in reading this i saw there's a gpu-enabled terminal, and i wondered why a terminal would use the gpu for the terminal and not for ai)
<niemeyer> Chipaca: Empty lines and non letters at start, maybe..
<niemeyer> Chipaca: I think it's going into a good direction.. and the exercise you're doing is great
<niemeyer> Chipaca: Thanks for that!
<niemeyer> Chipaca: Let's see if we can do some conservative folding, starting on the cases we're pretty sure is fine.. that might be better than to figure when *not* to fold
<Chipaca> niemeyer: if knowing when to fold were easy there wouldn't be a Common Mark :-)
<niemeyer> Anyway
<Chipaca> but, sure
<niemeyer> I need to run
<Chipaca> niemeyer: aw
<Chipaca> you're no fun any more :-)
<Chipaca> niemeyer: I'll push this, as it's an improvement over formatDescr, and we can loop back next week
<Chipaca> i'm not here tomorrow :-)
<niemeyer> Thank you!
<niemeyer> Me neither
<niemeyer> :)
<niemeyer> Or maybe not anyway ;)
<zyga-ubuntu> haha
<niemeyer> ... nothing to see here ... o/
<zyga-ubuntu> so "see you all tomorrow"
<zyga-ubuntu> this team is so predictibly terrible at not working
 * zyga-ubuntu goes to sleep
<Chipaca> niemeyer: btw in that .txt the "has \n\n" and "has \r" is to help figure out folding heuristics, if they exist
<cachio> zyga-ubuntu, good night
<Chipaca> the "has \t" is because i refuse to care if it looks bad because somebody put tabs in there
<mwhudson> how long should booting ubuntu core on a dragonboard take?
<mwhudson> i haven't booted this one in a long time so it's possible the hardware has died
<mwhudson> but it's hanging at "failed to load macaddress file, using random one instead"
<mwhudson> or it's possible i hadn't inserted the sd card fully
<zyga-ubuntu> mwhudson: hmm, it should boot pretty quickly
<zyga-ubuntu> mwhudson: I had to reflash my SD card after loooong inactivty, not sure why
<zyga-ubuntu> maybe that other card just failed
<mwhudson> zyga-ubuntu: nah i just hadn't pushed the card i was booting off in fully :)
<zyga-ubuntu> ah :)
 * zyga-ubuntu cannot sleep after that coffee
<mwhudson> ok now time to try to remember how to make an ubuntu core image
<zyga-ubuntu> ctrl-r ubuntu-image ;-)
<zyga-ubuntu> you need a model assertion
<zyga-ubuntu> the rest is easy-ish
<mwhudson> yes exactly :)
<mwhudson> uh i also need to download an arm64 core snap
<mup> PR snapd#4858 opened: strutil, cmd/snap: drop strutil.WordWrap, first pass at replacement <Created by chipaca> <https://github.com/snapcore/snapd/pull/4858>
<Chipaca> zyga-ubuntu: ^ special rune-wrangling pr for curing insomnia
<mwhudson> uhh my board rebooted and snapd paniced with "sync: unlock of unlocked mutex"
<zyga-ubuntu> uh
<zyga-ubuntu> not fun
<zyga-ubuntu> what did it do before
<zyga-ubuntu> I recall we had some issues when error cases would panic
<zyga-ubuntu> s/cases/paths/
<zyga-ubuntu> but not deliberatly, more by accident really
<mwhudson> https://www.dropbox.com/s/y2svocouxp7o1h2/IMG_20180316_123326990.jpg?dl=0
<mwhudson> hm not extremely readable
<zyga-ubuntu> no, not much
<zyga-ubuntu> can you focus on the screen and send another one
<zyga-ubuntu> oh
<zyga-ubuntu> invalid memory address or nil pointer dereference
<zyga-ubuntu> looks like pedronis-land
<zyga-ubuntu> I don't know that code much
<zyga-ubuntu> but please drop this in the forum
<zyga-ubuntu> looks like something to fix for the release
<mwhudson> https://forum.snapcraft.io/t/panic-on-dragonboard/4490
<zyga-ubuntu> Chipaca: replied
<zyga-ubuntu> Thank you mwhudson
<zyga-ubuntu> you can drop the image into the forum
<zyga-ubuntu> it is more long-lived than a dropbox URL
<zyga-ubuntu> just drag the image over to the edit field
<zyga-ubuntu> and wow
<zyga-ubuntu> you have a big office :D
<mwhudson> haha i can't work at home any more
<zyga-ubuntu> why not?
<zyga-ubuntu> Chipaca: https://travis-ci.org/snapcore/snapd/builds/354083470?utm_source=github_status&utm_medium=notification
<zyga-ubuntu> this build is done but still "running" on travis
<zyga-ubuntu> it will fail on timeout any moment now
<zyga-ubuntu> ok
<zyga-ubuntu> I will now exercise "can I keep my eyes closed" game
<Chipaca> ok, i'm out of here
<Chipaca> see you all when i see you all
#snappy 2018-03-16
<thiras> hello
<thiras> I got ubuntu 17.10 on my machine and got installed skype as snap package
<thiras> also latest nvidia card with propriety drivers
<thiras> i got no error no the terminal when i start the skype but it just simply doesn't start
<thiras> no hanged process on the ps aux. it's like kills instantly at the start without any error
<thiras> how can i get the error log at least?
<ManxPies> Hello, How Do I get A Spotify Icon (from the Spotify snap) in my menu ?
<ManxPies> CodeMouse92__: sup ?
<CodeMouse92__> ManxPies: Well HELLO there! I know you, methinks ;)
<ManxPies> CodeMouse92__: Can you not see my PM's or something ?
<CodeMouse92__> ManxPies: Hmm? I just PM'd you.
<CodeMouse92__> OH! I have non-registered nicks blocked from PMing. Spam
<ManxPies> CodeMouse92__: So you cannot see this ? https://paste.ubuntu.com/p/6sYv2fKfVm/
<CodeMouse92__> ManxPies: Yeah, no, don't see that. Here, let's move this to an ot, so we don't muck up the room! ##c++-share
<ManxPies> So what #channel - should we talk in (apart from u-o) ??
<ManxPies> okay
<ManxPies> Also, is there a Brave Browser snap ?
<mup> PR snapcraft#2004 closed: errros: add a specific error when running commands from plugins <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2004>
<jjohansen> zyga-ubuntu: http://kernel.ubuntu.com/jj/ubuntu-artful.git#lp1755563
<mborzecki> morning
<zyga-ubuntu> jjohansen: thank you!
<zyga-ubuntu> mborzecki: good morning
<mup> PR snapd#4859 opened: tests: autopkgtest may have non edge core too <Created by mvo5> <https://github.com/snapcore/snapd/pull/4859>
<mborzecki> zyga-ubuntu: hey
<mvo> zyga-ubuntu: hey, good morning - and good morning to mborzecki
<mborzecki> mvo: morning
<zyga-ubuntu> I should not be working today but I just jumped in to look at some things briefly
<mborzecki> are we ready for 2.32 yet? :)
<zyga-ubuntu> not fully
<zyga-ubuntu> woah
<zyga-ubuntu> https://travis-ci.org/snapcore/snapd/builds/354083620?utm_source=github_status&utm_medium=notification
<zyga-ubuntu> the test ran for 6 hours and 58 minutes
<zyga-ubuntu> the log says it succeeded
<zyga-ubuntu> but the job didn't end
<mborzecki> interesting, travis didn't kill it at 60 minutes mark
<zyga-ubuntu> looks like a bug
<pedronis> zyga-ubuntu: from the screenshot that panic from last night is with 2.23.1 (the original dragonboard image?)
<zyga-ubuntu> pedronis: I believe so
<pstolowski> mornings
<zyga-ubuntu> https://forum.snapcraft.io/t/panic-on-dragonboard/4490
<zyga-ubuntu> pedronis: ^
<pedronis> do we make new ones?
<pedronis> can we even fix it?
<mup> PR snapd#4856 closed: release: 2.32~pre2 changelogs <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4856>
<zyga-ubuntu> I don't know who manages those images
<mup> PR snapd#4859 closed: tests: autopkgtest may have non edge core too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4859>
<pedronis> zyga-ubuntu: I think it's a bug we fixed since a long while
<pedronis> https://github.com/snapcore/snapd/blob/2.23.1/store/auth.go#L106  := vs =
<zyga-ubuntu> I think we just need to refresh the image with new snapd build
<pedronis> I don't who makes or what's the refresh policy of those
<mvo> it is foundations managed now, we need to talk to steve if we need a refresh
<mvo> the policy is that it gets only refreshed on regular point releases of the distros
<mvo> (so not very often)
<pedronis> mvo: zyga-ubuntu:  mmh, interesting,  http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/  everything seems from January except dragonboard that is older
<mvo> heh (or not)
<zyga-ubuntu>  woah
<zyga-ubuntu> March 2017
<zyga-ubuntu> yeah
<zyga-ubuntu> slangasek: ^ is the dragonboard image expected to be much older than other images?
 * pedronis breakfast
<kalikiana> moinsen
<mup> PR snapd#4847 closed: osutil,testutil: add symlinkat(2) and readlinkat(2) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4847>
<mup> PR snapd#4808 closed: cmd/snap: use shlex when parsing `snap run --strace` arguments <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4808>
<mup> PR snapd#4738 closed: snap: unify snap name validation w/python; enforce length limit <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4738>
<pedronis> mvo:  I looked into what is involved to backport  #4829 , I got conflicts related  to #4722 , as we discussed yesterday I will try to look how involved/annoying is backporting that
<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>
<mup> PR #4722: store: cleanup test naming, dropping remoteRepo  and UbuntuStore(Repository)? references <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4722>
 * zyga-ubuntu rebased 4851 and keeps it in a debug loop
<zyga-ubuntu> I saw /etc error again so there must be _another_ reason for it
<mup> PR snapd#4860 opened: spread,tests: move suite-level prepare/restore to central script <Created by zyga> <https://github.com/snapcore/snapd/pull/4860>
<jamesh> zyga-ubuntu: hi.  I was having a look at the "safe bind mount" problem, and came up with some initial code based on what we discussed last week
<jamesh> zyga-ubuntu: https://github.com/jhenstridge/snapd/blob/safe-bind-mount/cmd/snap-update-ns/secure_bindmount.go
<jamesh> it isn't identical: I found mount(..., MS_MOVE) doesn't work in the presence of shared mount namespaces
<zyga-ubuntu> looking
<zyga-ubuntu> the remount to read only, that will not handle recursively bind mounted things, will it?
<zyga-ubuntu> you can also use filepath.Clean to simplfy some of the logic
<zyga-ubuntu> lastly, the MS_MOVE issue
<jamesh> zyga-ubuntu: yeah. Just noticed that.  I can also move the remount to the stashDir too, which gets rid of the FIXME
<jamesh> I'
<jamesh> ll check out filepath.Clean
<zyga-ubuntu> so when is MS_MOVE forbidden?
<zyga-ubuntu> when crossing namespace boundaries?
<zyga-ubuntu> or when crossing shared peer group kind? or when?
<jamesh> zyga-ubuntu: I was just getting EINVAL from the system call
<mvo> pedronis: thank you
<jamesh> I got a more expressive error from /sbin/mount, which seems to be due to it doing some checking before hand: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=fcc0413a12efde3f413064a622ea0a0595ede49f
<zyga-ubuntu> I see
<zyga-ubuntu> but
<zyga-ubuntu> can we make the internal stash private?
<zyga-ubuntu> bind from original place
<zyga-ubuntu> to stash
<zyga-ubuntu> make stash private
<jamesh> MS_MOVE is supposed to be atomic, and I guess they decided that making the mount propagation atomic was too hard
<zyga-ubuntu> and move to destination
<zyga-ubuntu> ah
<zyga-ubuntu> the destination is shared too
<zyga-ubuntu> jamesh: I'll pick this up next week when [j]dstrand is back
<jamesh> it looks like the parent of the stash directory would need to be !MS_SHARED
<jamesh> if I'm reading the util-linux patch right
<zyga-ubuntu> yes
<zyga-ubuntu> or the stash dir can be a private bind mount
<zyga-ubuntu> we do something similar to /run/snapd/ns
<zyga-ubuntu> it is privately shared
<zyga-ubuntu> or we would not be able to bind mount mount namespaces there
<zyga-ubuntu> I wrote a patch for linux that explains which of the EINVAL code paths is taken
<zyga-ubuntu> but I did that for pivot_root
<zyga-ubuntu> I think I wrote one for mount too but I cannot find it
<zyga-ubuntu> the one for pivot is in the tree of snapd in snap-confine/misc
<jamesh> do you think the openNoFollow() logic will help cover some of jdstrand's concerns?
<zyga-ubuntu> yeah
<zyga-ubuntu> we have similar code like that in many places
<jamesh> it means we're working with paths that didn't contain symlinks at some point in time, and then only reference those directories going forward as "." after fchdir()ing into them
<zyga-ubuntu> yeah, that is a nice improvement
 * Chipaca isn't here
<zyga-ubuntu> haha, hey John
<mborzecki> Chipaca: so you have a day off too? just like zyga-ubuntu :)
<pedronis> mvo: it's not too terrible backporting #4712,   it's slightly smoother if we backported #4715  as well , your call
<mup> PR #4712: release: version 2.31.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4712>
<mup> PR #4715: store: reorg auth refresh <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4715>
<mvo> pedronis: +1 for 4715
<mvo> pedronis: I get the feeling 2.32 will be a frank2.33 ;) but thats ok, its special circumstances so close to release
<pedronis> mvo: yea,  anyway 4715 it's also a fix,  we run out of stack (admittedly because of strange store bug) once
<pedronis> mvo: anyway as I said my maing argument for backporting these, is that if we get asked to do a close 2.32.x to bring in something to 18.04 it's better if the delta is small (with reason for safety)
<mvo> pedronis: agreed
<mvo> pedronis: I think this is fine
<mvo> meh, everything is terrible - autopkgtest bionic/i386 fails in strange ways (/bin/bash: line 104: 12090 Killed snap connect ...
<mvo> out-of-memory
 * zyga-ubuntu hugs mvo
<zyga-ubuntu> mborzecki: can you look at https://github.com/snapcore/snapd/pull/4860 - it should be a helper NO-OP change
<mup> PR #4860: spread,tests: move suite-level prepare/restore to central script <Created by zyga> <https://github.com/snapcore/snapd/pull/4860>
<mup> PR snapd#4861 opened: store: reorg auth refresh  (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4861>
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4851 is green and needs reviews now
<mup> PR #4851: cmd/snap-update-ns: fix creation of layout symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4851>
<mvo> zyga-ubuntu: my old friend lowmem_reserve again
<zyga-ubuntu> what is lowmem_reserve?
<mup> PR snapd#4862 opened: store: cleanup test naming, dropping remoteRepo and UbuntuStore(Repository)? references (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4862>
<pedronis> mvo: I created backports in 4861 and 4862
<mvo> pedronis: thanks, I have a look
<mvo> zyga-ubuntu: its the same problem we had before, let me try to find the papertrail. essentially the issue is that on i386 each time we load a new profile we eat up kernel memory and on i386 that is lowmem which is apparently not plentiful
<mvo> https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101/4
<pedronis> Chipaca: could you look at #4829 and #4849
<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>
<mup> PR #4849: many: propagate contexts enough to be able to mark store operations done from the Ensure loop <Created by pedronis> <https://github.com/snapcore/snapd/pull/4849>
<mup> Bug #1756285 opened: Gamepads only working in devmode <Snappy:New> <https://launchpad.net/bugs/1756285>
<Chipaca> mborzecki: hah! i did it :-)
<mborzecki> Chipaca: hmm?
<Chipaca> mborzecki: â¦ wait it's buggy
<Chipaca> mborzecki: the string version of wrap1
<mborzecki> Chipaca: haha challenge accepted :)
<mborzecki> Chipaca: i have something too, but it's wrapping a bit too far, idk why yet
<Chipaca> mborzecki: i've done something very similar in my playing around with widths, so i know it's doable, it's just very very fiddly
<Chipaca> mborzecki: I promise not to include fullwidth characters in my testing of your thing
<mborzecki> Chipaca: i have this atm https://paste.ubuntu.com/p/HB9HzJzrHb/ but it wraps too far, probably missed something
<Chipaca> mborzecki: can you pastebin the code, not the diff?
 * Chipaca 's seen too many variations over the last 24h to cope with the diff atm
<mborzecki> Chipaca: https://paste.ubuntu.com/p/FtxH8gPgsk/
<Chipaca> mborzecki: 		idx = strings.LastIndexFunc(text, unicode.IsSpace)
<Chipaca> mborzecki: that's finding you the last space in the whole thing
<Chipaca> mborzecki: not the last space that is <= width
<mborzecki> damn, right
<Chipaca> mborzecki: and... good luck because finding that one needs runes, with that approach
<Chipaca> :-)
<Chipaca> (because width is the number of runes(ish), not bytes)
<mborzecki> Chipaca: yeah, i see what you meant
<mup> PR snapd#4798 closed: snap: don't create empty Change with "Hold" state on disconnect <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4798>
<mborzecki> i'll give it 15 minutes, if i cannot come up with something i'll leave it :P
<Chipaca> mborzecki: https://pastebin.ubuntu.com/p/SMK5NKTMd6/
<Chipaca> mborzecki: that's where I'm at
<Chipaca> mborzecki: i've still got a bug in there but it's close
<mvo> pstolowski: if we need 4798 for 2.32, can you please create a PR that targets 2.32 (if not, just ignore me :)
<mborzecki> Chipaca: truly worthy of /r/dailyprogrammer/
<Chipaca> heh
<mborzecki> tis a nice problem though, it'd be great to have a TextFormatter that is an io.Writer
<Chipaca> I'll push chipaca/forms sometime when i'm happy enough with it
<pstolowski> mvo: it's na old bug. would be nice to have in 2.32. I'll prepare a PR
<pedronis> Chipaca: you +1 but not approved apparently
<Chipaca> pedronis: yes
<Chipaca> pedronis: I thought I understood the other pr until I saw the 'call snap find before  testing stuff' thing :-)
 * Chipaca needs to give it a better read
 * Chipaca is having fun with code on his day off
<pedronis> Chipaca: we had a problem related to switching to use the fakstore before we have a macaroon before, this just make it more likely,  snap find blah is a bit of a hack, but the real solution is annoying too (teach how to fake registration to the store just not to use it at all)
<mup> PR snapd#4849 closed: many: propagate contexts enough to be able to mark store operations done from the Ensure loop <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4849>
<pedronis> Chipaca: if you ever saw strange 418 errors around getting a nonce from the fakestore that was the reason
<pedronis> Chipaca: am I talking gibberish ? :)
<mborzecki> Chipaca: https://paste.ubuntu.com/p/ZRqDHcbJ9s/
<Chipaca> pedronis: no, that makes sense
<Chipaca> pedronis: and although i haven't seen teapots, many of us have
<Chipaca> pedronis: so thank you
<pedronis> Chipaca: :) this branch would increase the teapot spotting probability
<pedronis> before the "hack"
<Chipaca> pedronis: thank you again
<pedronis> :)
<Chipaca> mborzecki: youch
 * Chipaca goes for a walk
<mup> PR snapd#4863 opened: Fix abbreviated disconnect 232 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4863>
<pstolowski> mvo: ^
<mvo> pstolowski: thank oyu
<mvo> you
<cachio> mvo, already testint beta
<cachio> testing
<cachio> mvo, it should be ready today
<mvo> cachio: excellent, thank you
<cachio> yaw
<Trevinho> zyga-ubuntu: hey, do you remember that issue that was causing the desktop interface font's not to be mounted on refreshs? Did you find anything related to that? As I'd like to promote a snap using it to stable, but I'm a bit worried that it could break things
<cachio> mvo, 1 unit test is failing for bionic, how do you do to print stuff inside the unit tests or debug it?
<jibel> seb128, I tried what we discussed in Budapest and moved the preseeded snap from filesystem.squashfs to the CD filesystem directly but there is not so much gain. Only 2s on a 77s boot. unsquashfs and snapd are still the main CPU and IO consumers.
<mvo> cachio: which test is that?
<jibel> seb128, it's on VM, I'll try on HW to compare
<cachio> mvo, https://paste.ubuntu.com/p/7RRpWVCf3V/
<cachio> mvo, last test to fix I think
<mvo> cachio: interessting. I can try this on my bionic system in a bit, otherwise I think a Commentf("Unexpected build date %s", snap.BuldDate()) " next tothe test
<zyga-ubuntu> mvo: how are you today
<zyga-ubuntu> Trevinho: hey, I remember the issue. I didn't manage to reproduce it.
<zyga-ubuntu> although I found something in a related area
<Trevinho> zyga-ubuntu: mh, I see.. I wasn't able to reproduce it either
<Trevinho> zyga-ubuntu: switching from a snap without desktop-interface to one with it could suffice sometimes
<zyga-ubuntu> I didn't investigate the other thing yet, I just found it yesterday
<Trevinho> zyga-ubuntu: like switching from `telegram-desktop` stable to edge
<Trevinho> but... Well, as I said it's not something happening all the times
<zyga-ubuntu> interesting, I will setup a loop
<zyga-ubuntu> and try to reproduce that
<zyga-ubuntu> thank you for this advice, please hold over weekend ok?
<zyga-ubuntu> I will keep looking and if I find something we can fix it or stop the update
<zyga-ubuntu> mvo: +1 on merging 4851?
<zyga-ubuntu> I think it's not everything, I saw one failure but I wasn't able to reproduce locally yet
<zyga-ubuntu> mborzecki: would you be interested in looking at 4765
<zyga-ubuntu> it's not short though
<zyga-ubuntu> so a bit of warning
<greyback> hey, am using "snap try ./prime" and getting "Ensure prerequitites for "snap-name" are available *snap not found)" - any hint what that actually means
<zyga-ubuntu> greyback: one of the default providers for your content interfaces is wrong
<greyback> zyga-ubuntu: aha ok, that is a possibility
<cachio> mvo, Unexpected build date 1969-12-31 23:59:59
<cachio> hehehe
<cachio> a bit old
<pedronis> mvo:  backports #4861 and #4862 are green now but need to be looked at/approved
<mup> PR #4861: store: reorg auth refresh  (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4861>
<mup> PR #4862: store: cleanup test naming, dropping remoteRepo and UbuntuStore(Repository)? references (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4862>
 * zyga-ubuntu runs all of main in a loop since morning and ... no failures
<mup> PR snapd#4864 opened: daemon: support 'system' as nickname of the core snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4864>
<Chipaca> mborzecki: https://pastebin.ubuntu.com/p/yPNh9YB2xQ/
<Chipaca> mborzecki: â¦ and that's why I made it take a []rune :-)
<mborzecki> Chipaca: are you updating the pr with this code?
<Chipaca> mborzecki: should I?
<Chipaca> mborzecki: is it better?
<mvo> cachio: this looks like we did not get the new squashfs-tools in bionic-proposed in this test
<Chipaca> it was fun to write :-)
<mborzecki> aah ok ;) thought that you were planning to push it or sth
<Chipaca> not of my own volition
<Chipaca> i'm open to be convinced though :-)
<cachio> mvo, ok,
<cachio> mvo, is it ok if we add proposed until bionic release date?
 * Chipaca wanders off to to not-work things
 * zyga-ubuntu runs tests since 8 and no failures
<mup> PR snapd#4860 closed: spread,tests: move suite-level prepare/restore to central script <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4860>
<greyback> I swear this worked last week, but this week it fails (using layouts). Anyone mind having a quick look https://pastebin.ubuntu.com/p/vJHMh3DGxN/
<mup> PR snapd#4851 closed: cmd/snap-update-ns: fix creation of layout symlinks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4851>
<zyga-ubuntu> greyback: not sure if this is related
<zyga-ubuntu> greyback: https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/63?u=zyga
<zyga-ubuntu> if you follow edge you must set a feature flag to enable layouts
<greyback> zyga-ubuntu: if I create the directory in advance, it appears to work
<greyback> yep, done that
<zyga-ubuntu> other than that, not sure, I'm not really working today so I cannot help now
<zyga-ubuntu> if you can drop me a note on IRC about how to reproduce that I will try
<greyback> zyga-ubuntu: oh, sorry for bothering you!
<zyga-ubuntu> No worries:-)
<pedronis> pstolowski: I did a pass over the interface hooks PR
<pstolowski> pedronis: ty!
<cachio> mvo, which is the package "squashfs-tools" to install and which version ?
<mvo> cachio: hm, it looks like there is a new sync in bionic, let me check what is going on there
<cachio> mvo, I ask because squashfs-tools deb package was not installed in bionic
<mvo> cachio: what is the version installed in the vm?
<cachio> mvo, there was not
<mvo> cachio: that is strange, do you have /usr/bin/mksquashfs?
<cachio> I installed 1:4.3-6
<mvo> cachio: in the image?
<cachio> sorry
<mvo> cachio: that looks correct
<mvo> cachio: the version
<cachio> it was installed 1:4.3-4ubuntu2
<cachio> I updated with 1:4.3-6
<cachio> is it ok
<cachio> is it the right version?
<mvo> yes, this is the right verson
<cachio> mvo, ok, running again
<cachio> tx
<mvo> good luck
<cachio> mvo beta validation is going very well btw
<mvo> cachio: great to hear
<slangasek> zyga-ubuntu: hmm I'm not sure why dragonboard 410c never saw an update in the latest round, would need to check my logs.  In any case, there is a new round of image updates needed for 16.04.4
<zyga-ubuntu> slangasek: that sounds good, when is that, roughly? when 18.04 gets released?
<slangasek> zyga-ubuntu: no, it should be done already (in line with the 16.04.4 point release that has happened), and I'll be looking at it next week
<zyga-ubuntu> ah, perfect, thank you for looking into that
<zyga> I switched my debug refresh loop to use -reuse, in case that makes the magic bugs show up
<willem> hi all. I'm testing Xubuntu 18.04. Just installed skype from "software" (the xubuntu app to install things). Skype is a snap package. It installed. But it won't start.
<willem> The error in the log says: libGL error: unable to load driver: i965_dri.so
<willem> libGL error: driver pointer missing
<willem> Any advice on what could cause this, and what I can do about it?
<mup> PR snapd#4865 opened: many: propagate contexts enough to be able to mark store operations done from the Ensure loop (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4865>
<mup> PR snapcraft#2005 opened: pluginhandler: special case go patchelf failures for classic confinement <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2005>
<zyga> ah, found one more issue affecting symlinks
<zyga> actually, some code that does nothing but hurt now
<mup> PR snapcraft#2006 opened: many: use packaging logic to get patchelf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2006>
#snappy 2018-03-17
<mup> PR snapcraft#2007 opened: catkin plugin: replace python calls in all profile.d scripts <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2007>
<freakyy> hi all. i have a problem. i yesterday installed the spotify snap. it worked. then i rebooted my pc now suddenly, it says
<freakyy> execl failed: No such file or directory
<freakyy> child exited with status 1
<freakyy> when trying to start spotify
<freakyy> can anyone help me? it says spotify is installed
<freakyy> and its still "executeable"
<freakyy> sorry had to restart somethin was messed up cuz my irc client updated ;D
<freakyy> mso - can anyone hlep me? :)
<magicaltrout> freakyy: over the weekend you're probably better off on the snapcraft forums or ask.ubuntu.com
<bashfulrobot> Question for the snappy team here. Is it possible to use another version besides 16.04 as the base for a snap? I'm working on Krita V4, and the Krita team have eluded that 16.04 is problematic. Just looking at options here.
<Son_Goku> bashfulrobot, no
<bashfulrobot> Son_Goku: thanks for the confirmation
<Son_Goku> bashfulrobot, I'm working on making it possible to have CentOS 7, Fedora, Mageia, and openSUSE Leap 15 as options, but it's not ready yet
<freakyy> ask.ubuntu.com downvoted my question as offtopic
<pcdummy> freakyy: why not install spotify native?
<freakyy> pcdummy: whats spotify native?
<freakyy> u mean using ubuntu apt?
<freakyy> thats cuz because of an unresolved dependency i cant use the spotify repo
<pcdummy> freakyy: libssl1 i think
<freakyy> ubuntu 18.04 bionic beaver uses libcurl4 whereas ubuntu 17.10 works with libcurl3
<freakyy> and spotify requires libcurl3
<freakyy> but when i wanna install libcurl3 it will remove libcurl4 and curl which is required by the login script for my isp hotspot
<pcdummy> ok, i see :/
#snappy 2018-03-18
<MetalThrashing> hello
<MetalThrashing> you need the / slash before the command
<vidal72[m]> is it possible to override persistent sandbox settings per app? i.e. disable network access?
<electrona> I'm getting no file or directory when trying to run snaps. Also they don't appear in my app drawer
<electrona> ubuntu 18.04
<AuroraAvenue> I need a decent single player linux game - is this the right channel ?
<leftyfb> AuroraAvenue: no. Try #ubuntu-offtopic
#snappy 2019-03-11
<mborzecki> morning
<mvo> hey mborzecki - good morning
<mborzecki> mvo: hey
<mborzecki> mvo: did i miss anything on friday?
<mvo> mborzecki: not much was relatively quiet
<mborzecki> mvo: i like quiet :)
<mvo> mee too
<mvo> zyga: 6575 has some conflicts
<zyga> 89.Â§34-[\8p]
<zyga> =
<zyga> good morning
<zyga> mvo: thank you, looking now
<mvo> zyga: good morning!
<zyga> it's good to be back
<pedronis> mborzecki: Hi, I made a couple of suggestions in 6576
<mborzecki> pedronis: thanks, reading now
<pstolowski> morning
<mborzecki> pedronis: tbh i've alawys used determinant in the math sense, but i suppose your suggestion works too
<pedronis> mborzecki: an other option is interfaceConstraint
<pedronis> mborzecki: it's command impl, not an API or something used everywhere
<pedronis> so mostly trying to unblock this
<mvo> hey pstolowski - good morning
<mborzecki> pstolowski: hey
<zyga> mvo: quick question about https://github.com/snapcore/snapd/pull/6574#discussion_r264106985 - can you explain that again please?
<mup> PR #6574: cmd/snap-confine: track per-app and per-hook processes <Created by zyga> <https://github.com/snapcore/snapd/pull/6574>
<zyga> mvo: is the goal to see more than one process at a time?
<mborzecki> pedronis: reading dict output a bit more, 'determinant' sounds good
<mvo> zyga: it was mostly to ensure that the cgroup really tracks all the pids, we know this so maybe silly
<mvo> zyga: otoh *might* be useful when we go to cgroup v2 - otoh there will probably be different interfaces then so maybe again not super useful
<zyga> mvo: wait wait, I'm not sure I understand the comment you made
<mvo> zyga: i.e. to ensure that any children of the test-snapd-tools.sh app are also part of the cgroup that tracks the activity of "sh"
<zyga> mvo: is it really to track two processes?
<zyga> ah
<zyga> thanks!
<zyga> I understand now
<zyga> mvo: I will look at conjuring  something that checks that
<mvo> zyga: great! sorry for the slightly winded way of explaining it
<zyga> thank you for clarifying :)
<mvo> zyga: cool! but don't kill yourself I think its a bit optional, cgroups tend to work
<zyga> I think it's not hard, just a small extra chunk after the two tests there
<mvo> mborzecki: quick question about 6238 - this (probably) needs a master merge to make tests happy and a full review from pstolowski - is that accurate?
<mvo> zyga: nice
<mborzecki> mvo: and a small update, some new denials were found in the tests which need a little bit of investigation
<mborzecki> pedronis: pushed an update
<pedronis> mborzecki: thx
<mvo> mborzecki: thank you
<Chipaca> mborzecki: #6576 seems to be GTG
<mup> PR #6576: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection <Squash-merge> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6576>
<mborzecki> aand merged
<Chipaca> mborzecki: squash-merged?
<mborzecki> Chipaca: yup
<Chipaca> phew
<Chipaca> :-)
<mup> PR snapd#6576 closed: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6576>
<mborzecki> mvo: opening a branch with a cherry picke in a minute
<mup> PR snapd#6578 opened: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection (2.38) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6578>
<mvo> mborzecki: if it can be cherry-picked without a conflcit no need to open a PR
<mvo> mborzecki: thanks for landing this so timely!
<mborzecki> mvo: ah, opened the PR anyway, feel free to close :)
<pedronis> pstolowski: thanks for applying the last round of comment on timings
<mvo> mborzecki: thats fine
<mvo> mborzecki: I just wanted to make your life easier :)
<pstolowski> pedronis: sure, thanks for the suggestions
<pedronis> Chipaca: hi, thanks again for the epochs docs,  there is a couple of things maybe to clarify and degville has some input too, when is a good time to chat for you and and degville
<pedronis> ?
<Chipaca> pedronis: anytime before 6pm :-)
<degville> pedronis: Chipaca: same for me :)
<pedronis> Chipaca: degville: can we have a HO (same as standup) in 10 mins then?
<Chipaca> sure
<degville> Chipaca: pedronis: good for me!
<mborzecki> zyga: updated #6329, please take a look
<mup> PR #6329: cmd/snap-confine, packaging: support SELinux <SELinux> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6329>
<zyga> mborzecki: ack, enqueued
<mborzecki> zyga: thanks!
<zyga> mvo: added the test to https://github.com/snapcore/snapd/pull/6574
<mup> PR #6574: cmd/snap-confine: track per-app and per-hook processes <Created by zyga> <https://github.com/snapcore/snapd/pull/6574>
<mvo> zyga: nice, thank you
<mborzecki> mvo: #6578 is green
<mup> PR #6578: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection (2.38) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6578>
<mvo> mborzecki: yay - thanks
<mup> PR snapd#6578 closed: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection (2.38) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6578>
<Chipaca> pedronis: https://pastebin.ubuntu.com/p/2wMJ6DtjNz/
<Chipaca> pedronis: because the check is done in mount-snap, which isn't done for reverts
<pedronis> Chipaca: ok, so we have a problem
<zyga> brb
<zyga> mborzecki: is https://github.com/snapcore/snapd/pull/6329/files#r261618980 done?
<mup> PR #6329: cmd/snap-confine, packaging: support SELinux <SELinux> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6329>
<mborzecki> zyga: line 64?
<zyga> ahh
<zyga> thanks, I missed that (sorry)
<mborzecki> zyga: how about we switch all of the code to clang-format in a separate PR?
<mvo> mborzecki: the downside of doing this is that we loose a lot of history for git blame
<pedronis> of snap-confine?
<pedronis> I fear we cannot afford that
<mborzecki> hmn wonder if git blame -w would work around that
<mvo> mborzecki: might be worth a quick experiment
<mvo> (in a local PR)
<mvo> eh, local branch
<Chipaca> brb, gym
<zyga> mborzecki: let's not
<zyga> mborzecki: I wanted that but then considered it a bad move
<zyga> mborzecki: it's better to evolve code over time
<zyga> mborzecki: this is why I use new files, things slowly move to clang-format
<mborzecki> zyga: actually git blame -w looks quite good locally, but github blame is all bs now and there's no way to switch it
<zyga> mborzecki: more reasons to refactor snap-confine tree :)
<zyga> mborzecki: sent review on selinux branch
<mborzecki> zyga: not sure how at address your question here https://github.com/snapcore/snapd/pull/6329#discussion_r264181494
<mup> PR #6329: cmd/snap-confine, packaging: support SELinux <SELinux> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6329>
<pedronis> zyga: is that correct in the typical case we expect the /usr hierarchy to come from the base snap?
<mvo> pedronis: I am experimenting a bit more with remodel right now, one thing I noticed is that refresh of the kernel track will now trigger a re-refresh check which is not compatible with our requirement that we can't have things talking to the network in the install phase of the remodel. thats seems to be a bit of a tricky one
<mborzecki> zyga: updated #6329
<mup> PR #6329: cmd/snap-confine, packaging: support SELinux <SELinux> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6329>
<zyga> mborzecki: thanks!
<zyga> pedronis: yes
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6329#discussion_r264181494
<mup> PR #6329: cmd/snap-confine, packaging: support SELinux <SELinux> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6329>
<zyga> ah
<zyga> odd
<zyga> github doesn't  show the replies in some  views
<pedronis> mvo: that's probably easiest to deal with a flag for now
<zyga> mborzecki: approved
<mborzecki> zyga: thanks!
<mup> PR snapd#6579 opened: cmd/snap-confine: make sc_args helpers const-correct <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6579>
<zyga> mborzecki, mvo: quick one please ^
<mvo> pedronis: ok
<pedronis> mvo: we probably want canarying for (automatic) remodeling at some point but is quite premature to have that bit there
<pedronis> we need to decide what it really means
<mvo> pedronis: yeah, a flag for now is fine for me
<mborzecki> off to pick up the kids
<pedronis> Chipaca: could you review #6568 when you have a bit of time?
<mup> PR #6568: overlord/snapstate: fix restoring of "old-current" revision config in undoLinkSnap <Created by stolowski> <https://github.com/snapcore/snapd/pull/6568>
<zyga> mvo: https://github.com/snapcore/snapd/pull/6575 needs a 2nd review now
<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> mvo: probably want to look at #6574 a 2nd time
<mup> PR #6574: cmd/snap-confine: track per-app and per-hook processes <Created by zyga> <https://github.com/snapcore/snapd/pull/6574>
<mup> PR snapd#6580 opened: cmd/snap-confine: drop unused dependency on libseccomp <Created by zyga> <https://github.com/snapcore/snapd/pull/6580>
<zyga> mborzecki: ^ that one might be interesting for you
<zyga> mvo: quick trivial, 2nd review: https://github.com/snapcore/snapd/pull/6579
<mup> PR #6579: cmd/snap-confine: make sc_args helpers const-correct <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6579>
<mup> PR snapd#6581 opened: daemon: move a struct def that was between an other struct and its methods <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6581>
<pedronis> trivial PR ^
<Chipaca> hehe
<Chipaca> pedronis: +1 just from the description
<Chipaca> pedronis: of course github thinks you moved a func def, not a struct def
<pedronis> Chipaca: no,  it's a func,  is just that my brain conceptuall thought it's a struct
<pedronis> (because it's kind of response)
<Chipaca> daemon/ does kinda blur the lines
<Chipaca> there are things in there that are funcs that have methods on 'em
<pedronis> Chipaca: I fixed the descr/commit now
<Chipaca> pedronis: about daemon, I was thinking of slowly (oportunistically) moving api* chunks out to daemon/api/, to separate the api from the daemon bits, and make refactoring the one without breaking the other easier
<Chipaca> pedronis: do you think that might be a good approach for that?
<pedronis> Chipaca: I don't know, I need to understand a bit more what it entails
<pedronis> we don't seem close to that
<pedronis> the tests use daemon often
<pedronis> and they don't use exported things only either
<Chipaca> yeah
<Chipaca> blackboxing has only just started, in daemon
<Chipaca> or is it whiteboxing
 * Chipaca is colourblind
<pedronis> Chipaca: more small scale, I'm about to split out one api_*[_test].go file for asserts
<Chipaca> pedronis: nice
<Chipaca> pedronis: and make it daemon_test?
<pedronis> I don't know is that possible?
<pedronis> debug stuff isn't doing that for example
<pedronis> Chipaca: sorry, to be clear, I'm not doing this to cleanup,  I want to add a feature (returning json stuff for asserts if asked)
<pedronis> but I might as well do that first
<Chipaca> pedronis: I've been moving to _test opportunistically :-)
<Chipaca> pedronis: I need to do something about apiBaseSuite to be able to move to the package
<Chipaca> pedronis: it'll come in time
<Chipaca> might be as simple as adding an exported type alias for it
<Chipaca> but, too fiddly to do as an on-the-fly refactor imho
<pedronis> pstolowski: seems 6568 can be landed
<Chipaca> mvo: *cough*
<Chipaca> ah there you are
<mup> PR snapd#6568 closed: overlord/snapstate: fix restoring of "old-current" revision config in undoLinkSnap <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6568>
<mborzecki> zyga: is there a request to openSUSE:Factory with snapd already open?
<zyga> mborzecki: no, it was  automatically closed
<zyga> we need to fix our "badness" score by allowing setuid root and polkit policy first
<mborzecki> hmm
<zyga> that's why I opened those two bugs about that
<mborzecki> zyga: do you post links to the bugs?
<zyga> https://bugzilla.suse.com/show_bug.cgi?id=1127366 and https://bugzilla.suse.com/show_bug.cgi?id=1127368
<mborzecki> zyga: thanks!
 * zyga goes for lunch
<mup> PR snapd#6581 closed: daemon: move a function that was between an other struct and its methods <Simple ð> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6581>
<ogra> Chipaca, mvo, i'm booting my first core18 image (beaglebone) here and the first boot looks pretty odd doing interactive snap animations (mounting/installing with the spinner and such) on the serial console
<ogra> is that intentional ?
<pedronis> ogra: that sounds odd
<ogra> i mean ... it looks fancy ... but a bit out of place between all the system startup messages
<ogra> :)
<alan_g> cachio, are you the guy to refresh the rawhide image? https://github.com/MirServer/mir/pull/749#pullrequestreview-212741294
<mup> PR MirServer/mir#749: release/1.1 <Created by AlanGriffiths> <https://github.com/MirServer/mir/pull/749>
<mvo> ogra: its intentinal but if its too odd its easy to remove
<mvo> ogra: it was added mostly to show that things are happing but if its too out-of-place its easy to change
<pedronis> mvo: I wasn't aware of this
<ogra> mvo, well, it looks unusual
<mborzecki> zyga: https://forum.snapcraft.io/t/plans-for-sharing-a-gl-lib/10298/4
<ogra> but i'm not sure if i actually find it too odd after overcoming the first shock ;)
<mvo> ogra, pedronis http://paste.ubuntu.com/p/Sjm4j6jXK5/ in core18 is all that is needed to remove the progress
<pedronis> ah
<pedronis> I see
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<ogra> mvo, after letting it sink in i think it is fine ... unless you have a slow enough board that they kick in during console-conf
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<ogra> ppisati, FYI
<ogra> ogra@localhost:~$ uname -a
<ogra> Linux localhost 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:34:18 UTC 2019 armv7l armv7l armv7l GNU/Linux
<ogra> ogra@localhost:~$ snap list |grep kernel
<ogra> pc-kernel  4.15.0-46.49            194   18/edge   canonical*  kernel
<mvo> ogra: console-conf will wait for those
<mup> PR #49: allow (optional) snappy update $pkgname <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/49>
<ogra> mvo, ah, is that new in core18 ? it didnt in core16
<mvo> ogra: correct
<ogra> awesome
<zyga> re
<zyga> mborzecki: ack
<mup> PR snapd#6579 closed: cmd/snap-confine: make sc_args helpers const-correct <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6579>
<zyga> thanks!
<mup> PR snapd#6574 closed: cmd/snap-confine: track per-app and per-hook processes <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6574>
 * cachio lunch
<ogra> ogra@localhost:~$ sudo hostnamectl set-hostname beaglebone
<ogra> Could not set property: Failed to set static hostname: Read-only file system
<ogra> ogra@localhost:~$ ls -l /etc/writable/
<ogra> total 0
<ogra> ogra@localhost:~$ ls -l /etc/hostname
<ogra> lrwxrwxrwx 1 root root 17 Mar  8 10:46 /etc/hostname -> writable/hostname
<ogra> mvo, ^^^
<zyga> mborzecki: replied on that thread
<zyga> mvo: if you have some time https://github.com/snapcore/snapd/pull/6575 would be enough for me to propose the final bit of the core16 fixup
<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: can you please look at https://github.com/snapcore/snapd/pull/6580?
<mup> PR #6580: cmd/snap-confine: drop unused dependency on libseccomp <Created by zyga> <https://github.com/snapcore/snapd/pull/6580>
<ogra> $ sudo timedatectl set-timezone Europe/Berlin
<ogra> Failed to set time zone: Failed to set time zone: Read-only file system
<ogra> mvo, same for timezone :(
<mvo> ogra: *cough*
<zyga> ogra: hey, I got a ping about the pi3 gadget snap
<zyga> ogra: are builds working there?
<zyga> ogra: after fixing the spi interface name supposedly there are no more builds in edge
<ogra> zyga, no idea, thats foundation nowadays
<mvo> ogra: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936
<zyga> ogra: and in addition, someone should plan to release that
<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>
<ogra> zyga, same ... also foundations
<zyga> ogra: who should I ping?
<mvo> ogra: it tells you something about how well our SRUs are working :/
<mvo> ogra: note the date of the patch
<ogra> zyga, sil2100 is the one i always ping (priobably wrongly, who knows *g* )
<zyga> sil2100: ^ pi3 gadget snap
 * zyga hugs sil2100 
<zyga> thank you!
<sil2100> On my TODO list, yes o/
<ogra> mvo, well, not a year yet ... let it ripen a bit more :P
<mvo> ogra: yeah! I'm not bitter, no no
<sil2100> DMB meeting now...
 * zyga wishes for a snap of https://github.com/sharkdp/hexyl
 * ogra points zyga to https://forum.snapcraft.io/t/snap-wishlist-suggestions-wanted/567
<zyga> wow that's a LONG thread
<ogra> our longest :)
<ogra> i blame popey
<zyga> we should open a thread "brexit is good for the economy" to beat that ;)
<ogra> haha
<ogra> ondra, did you ever install avahi alongside lxd on a core image ? ... bad things happen :)
<ondra> ogra I think I did
<ondra> but tell me more
<ogra> well, when lxd brings up its lxdbrX devices somehow avahi considers it needs to attach a -2 to the MDNS hostname
<ogra> there seems to be some race somewhere between the two
<ogra> and avahi restarts avahid with a $hostname-2.local entry
<mup> PR snapd#6583 opened: cmd/snap-confine: move ubuntu-core fallback checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6583>
<zyga> mvo, pedronis: ^ that's the last of the fixes needed for core16
<zyga> (to allow core16  fallback to core)
<zyga> I need to EOD now
<zyga> I can check the status of stuff and merge things in the evening
<mup> PR snapd#6584 opened: spread.yaml: bump delta referece <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6584>
<cachio> mvo, I see errors like this one during the execution https://paste.ubuntu.com/p/WWJR8dhB7Z/
<cachio> mvo, it breaks all the tests restore
<mvo> cachio: hm, hm, this one looks like no snapd is running and system key changed that the same time - if you have access to the system you can probably check if snapd is running
<cachio> mvo, cgecjubg
<cachio> mvo, is not running
<cachio> https://paste.ubuntu.com/p/B9sy66TxMr/
<cachio> mvo, this could help
<mvo> yeah
<pedronis> Chipaca: shouldn't the export_snapshots_test.go etc be called export_api_snapshots_test.go ?
<Chipaca> pedronis: yeah, probably yes
<Chipaca> 'twas the first split one so i might've gotten the pattern wrong Â¯\_(ã)_/Â¯
<pedronis> snap_file is the same
<mup> PR snapcraft#2497 opened: Improved error message for specific cases (type error and bad length) <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/2497>
<mup> PR snapd#6585 opened: tests: add undo test with hanging stop command <Created by mvo5> <https://github.com/snapcore/snapd/pull/6585>
<cachio> mvo, could you identify the problem with that log, do you need anything else?
<cachio> mvo, otherwise I'll kill that vms
<zyga> (re from a coffee shop)
<zyga> pedronis: replied on https://github.com/snapcore/snapd/pull/6583#discussion_r264330080
<mup> PR #6583: cmd/snap-confine: move ubuntu-core fallback checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6583>
<pedronis> zyga: I don't understand the reply
<mvo> cachio: I know what I need to know, we need to make sure sandp runs or the system-key is updated when running the rsync code
<cachio> mvo, nice
<cachio> mvo, that made fail some runs today testing 2.38
<cachio> thanks
<zyga> pedronis: oh, sorry, I wanted to say that perhaps the desire to swap the order of the functions to achieve normal mode on core16 bases is correcet but leads to the correct behavior only happening if the fallback logic is  triggered. If you don't have any  fallback at all  (core16 is installed) then then normal mode should be enabled as well, currently is would not. Therefore we need to ensure *that* happens regardless of the
<zyga> fallback.
<pedronis> ?
<pedronis> maybe we should chat tomorrow
<zyga> pedronis: https://github.com/snapcore/snapd/commit/44e59fbd243b7f64d23a47a87e40c0c977274bdf#diff-0c384f3cd817f18339705204e8e7b788R304 should not depend on https://github.com/snapcore/snapd/commit/44e59fbd243b7f64d23a47a87e40c0c977274bdf#diff-0c384f3cd817f18339705204e8e7b788R299
<zyga> pedronis: sure
<pedronis> zyga: there is only one case where we want no pivot, which is on core 16 if the base is core
<mvo> cachio: let me know if you need help with the fix but I need to run now
<zyga> pedronis: yes, I agree
<zyga> pedronis: note, perhaps I was assuming this implicitly: this patch doesn't implement core16 specific behaviour - it only moves the existing ubuntu-core / core transition logic.
<pedronis> I know
<zyga> I also added a comment to the thread about this
<pedronis> but it does extra things that seems uneeded
<zyga> which things?
<pedronis> (everything being the same, less code is better)
<zyga> pedronis: let's chat tomorrow then, perhaps mvo can merge https://github.com/snapcore/snapd/pull/6575 so that the final diff is short
<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> https://github.com/snapcore/snapd/pull/6584 is green, ok to merge?
<mup> PR #6584: spread.yaml: bump delta reference <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6584>
<zyga> I will squash and fix the typo in the history
<zyga> nobody to complain so I'll just do it
<mup> PR snapd#6584 closed: spread.yaml: bump delta reference <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6584>
<mup> PR snapd#6586 opened: daemon: extract assertions api endpoint implementation into api_asserts.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/6586>
<pedronis> Chipaca: ^
<Chipaca> pedronis: nice :-)
<Chipaca> pedronis: I've been unable to make a table / grid thing for epochs
<Chipaca> pedronis: best i could do was a flowchart
<Chipaca> pedronis: https://snapforum.s3.amazonaws.com/original/2X/6/6fb9858b52acd50165b31a0ba514467790f996e7.png
<pedronis> Chipaca: per user is always going to be tricky right? because home dirs can be not around
<Chipaca> pedronis: yarp
<Chipaca> pedronis: should I make that distinction?
<Chipaca> "this will probably never work" vs "this might work in the future"?
<pedronis> Chipaca: I think we should make the two other work at some point
<pedronis> Chipaca: we can chat on that a bit more tomorrow
<Chipaca> I guess if I make the distinction from right now, when we do it all we need to do is add a "from rNNNN"
<mup> PR snapd#6587 opened: interfaces/apparmor: factor out test boilerplate <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6587>
<Chipaca> pedronis: https://snapforum.s3.amazonaws.com/original/2X/5/5561c2c011ecf21bc0992ec407c18cf550d2ed63.png fwiw
<pedronis> Chipaca: thx
<pedronis> Chipaca: I suppose there will text to clarify what we mean help with migration?
<Chipaca> pedronis: nah, I'll just post the flowchart (in graphviz language) as the documentation
<Chipaca> :-D
<pedronis> :)
<Chipaca> pedronis: (yes, I doubt I'll get it done before EOD tho)
<pedronis> np
<zyga> Chipaca: I remember using sphinx extension that handled that, that was neat :)
<Chipaca> zyga: https://github.com/discourse/discourse-graphviz
 * Chipaca runs
<Chipaca> anyway, I need to make dinner before I am dinner
 * Chipaca has full-on pacman-level teenagers
<zyga> pedronis: FYI, https://github.com/snapcore/pi3-gadget/pull/22 is interesting
<mup> PR pi3-gadget#22: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pi3-gadget/pull/22>
<zyga> there are number of similar PRs across gadget snaps
<zyga> CC ondra (thank you)
<zyga> Chipaca: FYI: I added the special case of encrypted home while user is logged out to https://forum.snapcraft.io/t/limitations-in-snapd/9718
<pedronis> zyga: yes, I have pinged about those
<pedronis> s/I have/I was/
<pedronis> zyga: didn't you EOD a while ago, I misread?
<zyga> yeah
<zyga> I'm in starbucks waiting for $wife
<zyga> (and she is actually coming now, ttyl)
<mup> PR snapd#6586 closed: daemon: extract assertions api endpoint implementation into api_asserts.go <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6586>
<mup> PR snapcraft#2498 opened: python plugin: graceful ret when no packages set <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2498>
<Chipaca> zyga: tweaked it a little
<mup> PR snapcraft#2499 opened: many: support for "base: core" in snapcraft.yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2499>
<mup> PR snapd#6582 closed: daemon, snap: screenshots _only_ shows the deprecation notice, from 2.39 <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6582>
#snappy 2019-03-12
<zyga> Good morning
<mborzecki> morning
<zyga> Hey
<zyga> How are you?
<mborzecki> zyga: fine, thanks
<mborzecki> zyga: it's cold outside :/
<zyga> Yeah
<zyga> I was walking with the dog for two hours last night
<zyga> All the way until midnight
<mborzecki> zyga: nice
<zyga> mborzecki: quick review to start the day? https://github.com/snapcore/snapd/pull/6587
<mup> PR #6587: interfaces/apparmor: factor out test boilerplate <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6587>
<mborzecki> zyga: sure, why not
<zyga> mborzecki: I changed some of the test function names but that is all sensibile in the follow-up patch
<zyga> mborzecki: pushed
<mborzecki> zyga: thanks!
<zyga> thanks
<zyga> I will push something that  enables apparmor on all of suse next
<zyga> then I'll look at debian
<zyga> I think we can handle debian (and derivatives), suse (and derivatives if any) to cover most of apparmor land
<zyga> mborzecki: https://lwn.net/Articles/782786/
<zyga> maybe mvo should apply
<zyga> ;D
<pedronis> zyga: hi, when are you going to address 6360 feedback ?
<zyga> pedronis: hi
<zyga> pedronis: most likely today
<mborzecki> guys, think we can land this now if everyone is happing with the current phrasing? https://github.com/snapcore/snapd/pull/6556
<mup> PR #6556: cmd/snap: hide 'interfaces' command, show deprecation notice <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6556>
<zyga> pedronis: I already started yesterday but haven't finished yet
<pedronis> mborzecki: I didn't see all the bikeshedding there
<mvo> good morning
<mvo> mborzecki: hey, yay (or :cry:) at 6585
<pedronis> mborzecki: I fear the new sentence is too long
<mvo> hey pedronis
<pedronis> mborzecki: I would like John input on htat
<pedronis> *that
<zyga> hey mvo
<pedronis> mborzecki: I commented there
<mborzecki> pedronis: thans
<mvo> hey zyga
<pedronis> mvo: hi
<zyga> mvo: quick review to start the day? https://github.com/snapcore/snapd/pull/6587
<mup> PR #6587: interfaces/apparmor: factor out test boilerplate <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6587>
<mvo> zyga: sure
<mvo> (when typing this the mouse focus was still on mutt - typing random chars into mutt is really scary)
<zyga> mvo: lol
<zyga> yes
<zyga> kind of like vi but then git prevents critical damage
<zyga> no such thing for mutt
<zyga> mvo: do you want to travel more, apply now for the position of debian leader: https://lwn.net/Articles/782786/
<mvo> zyga: *cough*
<mvo> zyga: and no
<zyga> :D
<zyga> join debian they said
<zyga> see the world the said
<mvo> zyga: but it would be interessting, pushing some ideas to moderinize things would be nice
<mvo> zyga: hahaha
<zyga> yeah
<zyga> mvo: I see the reference was recognized :)
<pstolowski> morning
<zyga> hey pawel
<mup> PR snapd#6587 closed: interfaces/apparmor: factor out test boilerplate <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6587>
<mup> PR snapd#6580 closed: cmd/snap-confine: drop unused dependency on libseccomp <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6580>
<mup> PR snapd#6588 opened: interfaces/apparmor: partial confinement on openSUSE <Created by zyga> <https://github.com/snapcore/snapd/pull/6588>
<pedronis> zyga: did you change 6575 since I reviewed it?
<zyga> pedronis: I applied the changes you asked for, fixed a typo that broke he build then merged master and pushed
<zyga> I then noticed that I left duplicate include line and force pushed to clear it
<zyga> that's all
<pedronis> zyga: no, sc_init_invocation was not there when I reviewed it
<zyga> oh? but it is added before your review?
<pedronis> no
<zyga> please double check, perhaps you reviewed a view that was stale
<zyga> it is so according to the github timeline
<pedronis> zyga: you force pushed, not point debating this
<zyga> yes, I said that
<zyga> but that was in the morning  after some things landed and the branch conflicted
<zyga> you can compare the revisions if you want
<pedronis> anyway I removed my +1
<mvo> zyga: yeah, 6575 changed quite a bit since I looked at it - or so it felt to me this morning but I have not looked at the details
<mvo> slightly sad because the previous one was ready for merging afaict
<zyga> mvo: I implemented the changes you suggested
<zyga> mvo: and made it clear in the log as well
<pedronis> zyga: my emails says that stuff was pushed 20 hours ago, and my review was 21 hours ago
<pedronis> but as I said hard to tell with force push
<zyga> pedronis: but that force push was done this morning
<zyga> and after I pushed yesteray I was happy to see your review
<mvo> zyga: sorry, I'm confused, in 6575 I just wrote "looks good" - am I mixing something up?
<zyga> I'm 100% sure github showed this the same way before i did that in the morning
<zyga> mvo: we discussed this durinig the standup and  you suggested that I put additional patches to the same branch
<pstolowski> pedronis: hello, sample output of new timings to discuss - https://paste.ubuntu.com/p/gXrk8sBwwB/ - contains timings of some tasks, ifacemgr startup, snapmgr ensure loop (nb, do we really run ensure so often?). combines doing/undoing times from tasks
<zyga> pedronis: this is especially clear since the three patches starting with cmd/snap-confine: tweak ordering of fields in sc_invocation are added in response to your review
<mvo> zyga: oh, sorry. my bad then. maybe we can go back to the point in time (via a PR) that had the +1 from pedronis  and the "looks good" from me and then land those bits easily?
<ondra> zyga hey
<ondra> zyga wanna talk about those PR for gadget snaps?
<zyga> mvo: but the unclear aspect is what pedronis actually had reviewed
<ondra> zyga unless you already had chat with pedronis
<zyga> ondra: hey, I asked about it yestereday
<pedronis> zyga: I didn't review the init helper
<zyga> ondra: I don't know what I can do to help
<pedronis> maybe it was stale
<pedronis> whatever
<ondra> zyga yeah I was already off when I saw you message
<pedronis> it needs a review from scratch from both of us
<ondra> zyga nothing apart of +1 :D
<zyga> ondra: I don't fully understand the consequence of that, it is  something perdronis should look at first
<ondra> zyga I think rest is on foundation
<ondra> zyga yeah we already talked with him
<pedronis> zyga: if I have too be honest I find snap-confine is starting to be too much split out in helpers, it's a maze to follow
<pedronis> I'm sure they all make sense locally but if in a 2nd time you need to find out what's going on is a chase
<Chipaca> mborzecki: I pushed a tweak to the interfaces deprecation pr
<Chipaca> pedronis: ^
<pstolowski> pedronis: let me know when/if you have a moment to discuss this
<mborzecki> Chipaca: thanks!
<pedronis> pstolowski: we call ensure loop each 5 mins but also each time we need to run more task with EnsureBefore(0)
<mborzecki> Chipaca: is fill() aware of a sequence '..' and will not break it?
<Chipaca> mborzecki: it is not
<Chipaca> mborzecki: Â¯\_(ã)_/Â¯
<Chipaca> I mean, breaking it isn't ideal but isn't the end of the world either
<mborzecki> Chipaca: fits unboken in my term so :)
<Chipaca> mborzecki: also breaks just right on 80
<mborzecki> mhm
<pedronis> Chipaca: I don't understand how using fill helps
<pedronis> it's going to take up vertical space anyway
<Chipaca> pedronis: your issue was with vertical space, not with improper word-splitting?
<pedronis> yes
<mborzecki> pedronis: https://paste.ubuntu.com/p/7qzSqPM4Zc/
<pstolowski> ah, right, EnsureBefore(0)
<Chipaca> pedronis: but the deprecation is only shown on 'snap interfaces'
<pedronis> pstolowski: we really need to be careful with it
<Chipaca> pedronis: which is not concerned with vertical space
<pedronis> Chipaca: no, but is a table
<Chipaca> pedronis: so?
<mborzecki> the message goes to stderr
<pedronis> I know
<pedronis> we are still eating 3 lines
<pedronis> seems too much
<Chipaca> grah
<pstolowski> Chipaca: have you by an chance implemented our TabWriter?
<Chipaca> pstolowski: we don't have a TabWriter
<Chipaca> pstolowski: why?
<Chipaca> pstolowski: we do have a tabWriter, I think, that wraps TabWriter
<Chipaca> as a helper function i mean
<Chipaca> not as a type
<pedronis> Chipaca: 'snap interfaces' is deprecated and replaced by the 'snap connections' command.  is 79
<Chipaca> pedronis: in English
<pedronis> Chipaca: they we just hide it
<pstolowski> Chipaca: ah, nvm, it's a standard go lib thing
<pedronis> thne
<pedronis> Chipaca: then we just hide it
<Chipaca> pedronis: I don't understand why
<Chipaca> I don't understand why 3 lines are too many, on a command that produces 121 lines of output by default
<pedronis> Chipaca: it doesn always produces 121 lines
<pedronis> Chipaca: consider snap interfaces gnome-logs
<Chipaca> pedronis: ok
<Chipaca> pedronis: so what's the issue
<pedronis> Chipaca: we started here  "The 'snap interfaces' command is deprecated, try the new 'snap connections'."
<Chipaca> pedronis: yes
<mborzecki> i don't mind going back to the first version
<Chipaca> We could even go with
<Chipaca> 'snap interfaces' is deprecated; use 'snap connections'.
<Chipaca> this incorporates all the feedback so far
<mborzecki> works for me
<mborzecki> pedronis: ^^ wdyt?
<mvo> Chipaca: +1
<Chipaca> mborzecki: I'll push the change, plus adding the notice to the long help
<mvo> (fwiw)
<mborzecki> Chipaca: thank you!
<mvo> I updated 6401 fwiw
<pedronis> Chipaca: the last version is very long, but it's all facts, it doesn't recommend anything
<pedronis> (except implicitly)
<Chipaca> pedronis: the _last_ version? â'snap interfaces' is deprecated; use 'snap connections'.â?
<pedronis> Chipaca: the last version in the PR
<Chipaca> pedronis: you ok with the last one here? i think it covers all the issues we've come across so far
<pedronis> Chipaca: it's very terse
<pedronis> sorry, that's not the problem
<Chipaca> I'd also add
<Chipaca> NOTE this command is deprecated and has been replaced with the 'connections'
<Chipaca>      command.
<Chipaca> to the longHelp
<pedronis> thanks
<pedronis> Chipaca: have we goon too far the other way around though? is the new one too prompt?
<Chipaca> pedronis: nah, it's fine
<Chipaca> pedronis: adding 'please' and 'try' are both problematic for reasons degville explained in the pr
<pedronis> Chipaca: wondering if we want "the new" , issue with that is that at some point we would need to remove "new" because is untrue
<Chipaca> pedronis: I really think it's fine as is
<pedronis> ok
<mup> PR snapd#6589 opened: daemon: support returning assertion information as JSON with the "json" query parameter <Created by pedronis> <https://github.com/snapcore/snapd/pull/6589>
<pedronis> Chipaca: ^  something for you when you have a bit of time
 * Chipaca looks at next year's calendar
<Chipaca> ok
<pedronis> heh
<Chipaca> :-)
<mup> PR snapcraft#2499 closed: many: support for "base: core" in snapcraft.yaml <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2499>
<ogra> mvo, here is another core18 regression https://bugs.launchpad.net/snappy/+bug/1819629
<mup> Bug #1819629: no default locale in core18 causes pam errors <Snappy:New> <https://launchpad.net/bugs/1819629>
<mup> Bug #1819629 opened: no default locale in core18 causes pam errors <Snappy:New> <https://launchpad.net/bugs/1819629>
<mvo> ogra: thanks - that sounds hopefully straightforward to fix, maybe sil2100  can give 1819629  a stab
<ogra> yeah, just some "echo C.UTF-8 >/etc/default/locale" somewhere would be enough
<ogra> (in the build)
<sil2100> Oh, indeed
<mvo> ogra, sil2100 yeah, the new build system has a "static" dir, we could simply drop static/etc/default/locale into the core18 tree and its fixed :)
<ogra> awesome
<ogra> sil2100, also https://forum.snapcraft.io/t/cant-find-the-spi-interface/7523 ... you might need to pull the latest upstream into the CanonicalLtd branch for the pi3 gadget SPI interface fix
<ogra> i wonder if we could put the snapcore/pi3-gadget tree to rest somehow witout breaking all the forks of it (not sure if github supports re-owning branches and keeps the references)
<ondra> zyga what happens when I change base in snap between revisions, will snapd correctly run new revision agains different base?
<zyga> ondra: when all processes of that snap terminate, yes
<ondra> zyga is there way to check what base it's working
<zyga> ondra: yes, sure, just nsenter and look
<ondra> zyga hmm for me refresh failed, because I think in post-refresh hook it collided on libc versio
<zyga> ondra: can you provide a reproducer?
<ondra> zyga testing now, let me make sure I have it all right
<zyga> ondra: you can set SNAPD_DEBUG=1 and see what happens
<zyga> but I don't know how to set that to see hook output
<zyga> ondra: there's a spread test for this feature if you want to see how it behaves
<ondra> zyga I get hook error and that indicates there was libc collision, but let me validate clean install first
<zyga> https://github.com/snapcore/snapd/blob/master/tests/main/stale-base-snap/task.yaml
<cachio> jamesh, hey
<cachio> jamesh, yesterday I was working with a test error
<cachio> jamon,
<cachio> jamesh, the test desktop-portal-filechooser on snapsd
<cachio> jamesh, https://paste.ubuntu.com/p/wMhG5vdyzK/
<cachio> the test just fails like this on ubuntu 18.04
<ondra> zyga OK so install opengrok from stable, then try to refresh to edge
<cachio> the error itself is that the snap can't write in the mount dir because of lack of permissions
<cachio> jamesh, any idea if this has been already seen/reported?
<ondra> zyga stable is with core16, edge it base core18, there is libpthread library which depends on libc version, this is used in post-refresh hook, which fails
<cachio> jamesh, in ubuntu 18.10 works fine
<ondra> zyga clean install from edge works
<ondra> zyga so only difference I can think og
<zyga> ondra: perhaps something was still running?
<zyga> it's interesting
<zyga> that post  refresh hook can run with old libc
<zyga> I mean
<zyga> it's possible to craft this
<zyga> so that it will happen as you described
<zyga> perhaps snapd should disallow base changes that don't discard the mount namespace
<zyga> pedronis: ^
<ondra> zyga so post-refresh runs with previous base?
<zyga> ondra: please report this
<zyga> ondra: yes, it is possible that this happens
<zyga> ondra: when an app is still active
<zyga> ondra: or perhaps hooks don't depend on their teremination and  we start post refresh hook while  another hook is running
<ondra> zyga doesn't it stop all services before refresh?
<zyga> ondra: it does, but there are hooks and apps
<zyga> those can run longer
<zyga> and there are enduring services
<zyga> it warrants a bug
<zyga> this is funny actually
<ondra> zyga there should not be any app running, so just hooks
<zyga> because it means we cannot correctly refresh in some cases
<zyga> ondra: perhaps more than one bug  then (base awareness across refresh and hook ordering)
<ondra> zyga have you managed to reproduce it?
<zyga> no
<zyga> I have not tried
<zyga> I just explained how it is 100% possible to do that
<ondra> zyga right :)
<zyga> ondra: curious, what was the base change?
<zyga> core -> core18
<zyga> or back?
<ondra> zyga core->core18
<ondra> zyga a bit related, what is correct base in snap.yaml for core16? core16 or core?
<zyga> ondra: and is libc incompatible across that hop?
<ondra> zyga I'm using custom libpthread which I ship in snap, so it's missing things from libc
<zyga> ahh
<ondra> zyga this is error I'm getting mkdir: relocation error: /snap/opengrok/34/lib/x86_64-linux-gnu/libpthread.so.0: symbol __tunable_get_val, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
<zyga> ondra: please report a bug, after an errand later today I will write a test that reproduces thiis
<zyga> ondra: it's unfortunate because it's a design omission
<ondra> zyga sure I will file bug for it
<zyga> thank you for another interesting case :-)
<ondra> zyga you are welcome :)
<pedronis> zyga: we always run at most one hook per single snap
<pedronis> at a time
<zyga> pedronis: and we consider the hook "done" when the initial process exits
<pedronis> zyga: ?
<zyga> pedronis: we probably can craft a hook that leaves a background process behind
<pedronis> probably
<pedronis> is that the case here though?
<mup> PR snapd#6562 closed: timings: base API for recording timings in state <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6562>
<zyga> no, I don't think so, unless that was accidentally what had occurred
<zyga> but regardless of what happened here the issue of running a revision that clearly demands base snap  X with the stale base snap Y needs addressing
<pedronis> yes
<pedronis> shouldn't stale detection find that out?
<pedronis> different base, different device?
<zyga> it is different
<zyga> I bet it's not changed because the namespace is still used
<zyga> howerver here I'd argue that different base snap name should be detected
<zyga> but we have no logic to recover base snap name from the mount namespace
<zyga> (or if it can be done, in general, reliably, apart from parsing path names)
<pedronis> pstolowski: the doc comments in the branch you merged still say Timing a lot
<pedronis> instead of Span
<pedronis> unless I'm confused
<pstolowski> pedronis: uhm you're right, sorry.. i'll address in a followup, this doc will be updated anyway with new helpers
<pedronis> pstolowski: yes, fine for a follow up
<pedronis> Chipaca: the failure on the deprecate interface PR is real, something going with xgettext-go
<pedronis> and the warning
<pedronis> panic: unknown type: interfacesDeprecationNotice
 * Chipaca kills all tests
<Chipaca> pedronis: I'll fix
<Chipaca> after lunch tho
<pedronis> :)
<Chipaca> niemeyer: https://pbs.twimg.com/media/D1dQcvqXcAAaQKs?format=jpg&name=large
<Chipaca> since you were asking about this yesterday
<cachio> mvo, is it ok to move 2.37.4 to stable right?
<niemeyer> Chipaca: There we go.. :)
<mborzecki> anyone up for a review on #6485 ?
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<pedronis> mborzecki: it has grown quite a lot
<zyga> mborzecki: I can enqueue that for later today
<zyga> I need to leave in ~15 minutes
<mborzecki> thanks!
<zyga> mborzecki: enqueued :)
<pedronis> mborzecki: it would be easier to review if the new package added was its own PR
<mborzecki> pedronis: i can split it
<pedronis> mborzecki: if it's not too much painful, I would prefer, it would go faster on the review side that way
 * zyga goes to the doctor 
<pedronis> cachio: let's chat about 2.37.4 in the standup
<cachio> pedronis, ok
<mborzecki> Chipaca: https://github.com/snapcore/snapd/pull/6556#issuecomment-471990121 could that be because of ; in the message?
<mup> PR #6556: cmd/snap: hide 'interfaces' command, show deprecation notice <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6556>
<Chipaca> mborzecki: no, we use ; elsewhere
<Chipaca> mborzecki: it's probably the i18n.G() of const
<Chipaca> checking now
<mborzecki> off to pick up the kids
<Chipaca> how
<Chipaca> how does update-pot work any more
<dot-tobias> ogra / mvo: I'm trying to rebase my fork of ogra's kiosk gadget snap (https://github.com/ogra1/pi-kiosk-gadget) onto the core18-related changes of the âuniversal Pi gadget snapâ (https://github.com/snapcore/pi-gadget). Building the core18 gadget works fine, but my Pi 3B does not boot at all â¦ green LED flickers shortly and then dies, no HDMI output whatsoever. I tried to selectively apply changes from both repos from the point where
<dot-tobias>  they diverted (commit 013c2931230a4b4de419080f8499fca27c51727d), but no success. Do you know if the current revision of the universal Pi gadget works?
<Chipaca> 'go install' now installs binaries in ~/bin/
<Chipaca> :-|
<ogra> dot-tobias, got a link to your current code ?
<Chipaca> oh wait, no, i have GOBIN set for some reason
<Chipaca> hrmm
<ogra> arent you in england ? shouldnt that be GOWASTEBASKET instead ? :P
<Chipaca> ogra: https://en.oxforddictionaries.com/definition/bin
<Chipaca> ogra: 'rubbish bin' is british (vs 'trash')
<ogra> oops
<Chipaca> ogra: bloody europeans, coming over here, stealing our language
<ogra> lol
<dot-tobias> ogra: https://gitlab.com/glancr/gadget-snap-pi-kiosk/ -> master builds fine with LXD container without base (though the attempt to feed mir-kiosk the whole config file does not validate in ubuntu-image); branch core18-WIP has the core18 changes in snapcraft.yaml: https://gitlab.com/glancr/gadget-snap-pi-kiosk/commit/d91cc2386af0da24a8942e52053469f4b920ec7b (other files can be ignored)
<ogra> dot-tobias, the linux-modules package contains dtb files ?!?
<ogra> (i highly doubt that)
<ogra> is that a change made by you or did you copy it from the universal branch ?
<dot-tobias> ogra: Got that from the snapcore/pi-gadget upstream, see https://github.com/snapcore/pi-gadget/blame/988ee427691177de5cee84370b096be3c6a07951/snapcraft.yaml#L89
<dot-tobias> but that would indeed explain why it's not booting â¦ (I have close to zero knowledge about this stuff, so apologies and thank you for beginner explanations  in advance ð )
<ogra> dot-tobias, ok, i checked, devicetrees are in that package, so this is fine
<ogra> o dont see anything else significant that could prevent booting apart from the fact that you use the distro compiler, but that should be v7 or newer anyway in bionic
<ogra> s/o/i/
<ogra> how does your prime folder look like after build ?
<ogra> you should fine the RPi bootloader blobs in there as well as uboot2.img and uboot3.img
<dot-tobias> re: compiler: yeah, that's what I gathered from https://github.com/snapcore/pi-gadget/pull/9
<mup> PR pi-gadget#9: RFC: use ubuntu cross gcc to build uboot <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/pi-gadget/pull/9>
<dot-tobias> let me check
<ogra> actually in prime/boot-assets/
<ogra> $ ls ../../pi3/pi3-gadget/prime/boot-assets/
<ogra> bcm2709-rpi-2-b.dtb  bcm2710-rpi-cm3.dtb  cmdline.txt  COPYING.linux  fixup.dat     fixup_x.dat       overlays     start_cd.elf  start.elf    uboot.bin
<ogra> bcm2710-rpi-3-b.dtb  bootcode.bin         config.txt   fixup_cd.dat   fixup_db.dat  LICENCE.broadcom  psplash.img  start_db.elf  start_x.elf
<ogra> thast what you want to see
<ogra> *that's
<dot-tobias> Ok, thanks. Rebuilding the snap just to be sure, BRB
<dot-tobias> ogra: Side-note â Do you happen to know how I can feed a multiline file to a âdefaultsâ entry in gadget.yaml? I'm trying to accomplish setting mir-kiosk's display config file through the device hook (see https://forum.snapcraft.io/t/prepare-device-hook-questions/9626/5?u=tobias , current attempt at https://gitlab.com/glancr/gadget-snap-pi-kiosk/blob/master/gadget.yaml#L12)
<Chipaca> dot-tobias: > will mangle things for you
<Chipaca> dot-tobias: also the quotes are spurious
<Chipaca> dot-tobias: paste your yaml into http://yaml-online-parser.appspot.com to see what works :-)
<Chipaca> dot-tobias: note these are comments about the yaml itself, I don't know if what you're trying to do should work :-)
<ogra> i'm also not sure if the mir team has even tested this
<ogra> probably ask in #mir-server
<dot-tobias> I tried with a pipe before and the parser complained while building the snap, but maybe I did something else wrong. The online parser shows valid JSON with \n linebreaks at least, will test with ubuntu-image ð Yeah, but having a valid yaml result is at least one step closer to the goal ð Thank you!
<mvo> cachio: 2.37.4 stable> yes - I see no reason why not
<dot-tobias> ogra: Snap build fore core18 version is complete, here's the boot-assets folder:
<dot-tobias> â ls boot-assets/
<dot-tobias> bcm2708-rpi-0-w.dtb     bcm2709-rpi-2-b.dtb       bcm2835-rpi-a.dtb       bcm2835-rpi-b-rev2.dtb  bcm2837-rpi-3-b.dtb  COPYING.linux  fixup_x.dat       start_cd.elf  uboot2.bin
<dot-tobias> bcm2708-rpi-b.dtb       bcm2710-rpi-3-b.dtb       bcm2835-rpi-a-plus.dtb  bcm2835-rpi-zero.dtb    bootcode.bin         fixup_cd.dat   LICENCE.broadcom  start_db.elf  uboot3.bin
<dot-tobias> bcm2708-rpi-b-plus.dtb  bcm2710-rpi-3-b-plus.dtb  bcm2835-rpi-b.dtb       bcm2835-rpi-zero-w.dtb  cmdline.txt          fixup.dat      overlays/         start.elf
<dot-tobias> bcm2708-rpi-cm.dtb      bcm2710-rpi-cm3.dtb       bcm2835-rpi-b-plus.dtb  bcm2836-rpi-2-b.dtb     config.txt           fixup_db.dat   psplash.img       start_x.elf
<ogra> dot-tobias, you are missing the files from the config dir (config.txt and cmdline.txt)
<ogra> oh, no, i'm just blind
<zyga> mvo: standup update: Iâm working on splitting the big refactoring PR; going well and I have several patches that can be proposed but Iâm waiting till the whole complete âsplitâ branch is functioning. Apart from that I briefly interacted and tested MX Linux where there is some desire to run snapd. I will try one more time with init system set to systemd. I plan to re-review Maciejâs seccomp optimization PR.
<mvo> zyga:
<zyga> And as I shared Iâm at a doctor undergoing small surgery (all is good, no limbs lost)
<dot-tobias> ogra: I don't see uboot{3}.img however, or did you mean uboot.bin?
<mvo> zyga: uh get well!
<zyga> No no, all is good, nothing to worry about
<ogra> dot-tobias, yeah
<ogra> if this same stuff ends up properly in the system-boot partition of your image i dont really know what to say ... this should definitely boot
<ogra> do you see these files in the toplevel of the boot partition if you plug the SD into your desktop ?
<mvo> Chipaca: "there are files left in the git tree after the tests:" ?? cmd/snap-seccomp/... you talked aobut this before, didn't you?
<Chipaca> mvo: where are you getting this?
<mvo> Chipaca: at the end of a unit test spread run
<mvo> Chipaca: I thought I saw you talking about something similar earlier
<mvo> Chipaca: did I misremember?
<Chipaca> mvo: not today, not for ages
<mvo> Chipaca: ok, then please ignore me
<Chipaca> mvo: 'git status' should list things
<mvo> Chipaca: yeah, it happend on spread
<mvo> Chipaca: maybe it was a hickup, no worries
<zyga> pedronis: about that branch from this morning. I can split it exactly where it was approved before
<ondra> zyga so I can only reproduce it on one machine, on other machines when I do clean install and then refresh it just works
<zyga> ondra: very interesting
<zyga> Is one machine slower?
<ondra> zyga very likely much slower
<zyga> pedronis: I didnât mean to introduce bumps into the review process
<ondra> zyga I can try to repro on other slow machine
<zyga> ondra: can you please tell me more about the hooks in play
<zyga> What kind of hooks are used
<zyga> And how are the hooks implemented
<ondra> zyga https://github.com/kubiko/opengrok-snap/blob/master/snap/hooks/install
<ondra> zyga install and post-refresh are same
<zyga> ondra: itâs hard for me to look now (I only have my phone and cannot move)
<zyga> So please walk me through this
<ondra> zyga nothing special there, couple of cp and mkdir and then snapctl get and snapctl set
<ondra> nothing else
<zyga> Ah
<zyga> Hmmm
<zyga> Anything using &?
<zyga> (Shell job control and stuff)
<ondra> zyga nope
<ondra> zyga all running in straight line
<zyga> So there are install and post-refresh only, right?
<ondra> zyga also error is from first line of that hook
<zyga> Are there any services?
<zyga> Perhaps we donât wait enough for service shutdown
<zyga> We now kill just the main process, right?
<ondra> zyga there is configure which does nothing
<zyga> Inside services
<ondra> zyga yes there is service
<zyga> (Or am I mistaken?)
<ondra> zyga I have stopped service with systemctl and it still happened
<zyga> Aha
<zyga> That is very useful data
<zyga> Can you reproduce it on the slow machine if you remove the service from snap yaml?
<ondra> zyga there is one time activated service and tomcat, I stopped both and same thing
<zyga> I wonder if you can reduce this to just the hooks
<zyga> Or if services play a role
<ondra> zyga but if I remove service it will be new revision, so would that make difference as service from new snap should not be running before post-refresh hook, or am I missing sometning?
<ondra> zyga so I cannot repro on another slow machine with clean istall
<ondra> zyga BTW unrelated bug: ERROR cannot discard snap namespace "opengrok", will retry in 3 mins: cannot discard preserved namespace of snap "opengrok": cannot unlink opengrok.mnt: Device or resource busy
<ondra> zyga not able to remove snap which was installed with try
<ondra> zyga Remove security profile for snap "opengrok" (x4) (cannot find installed snap "opengrok" at revision x4: missing file /snap/opengrok/x4/meta/snap.yaml)
<ondra> zyga but /snap/opengrok is empty dir, so something out of sync
<jamesh> cachio: was out an event earlier.  I haven't seen that error before.  It looks like it is coming from the xdg-document-portal FUSE file system though
<degville> mvo: I'm having trouble connecting to the stand up! I'll keep trying (I'm in London)
<ondra> zyga removing service made no difference
<jamesh> cachio: I suspect the ENOSYS is this one: https://github.com/flatpak/xdg-desktop-portal/blob/master/document-portal/document-portal-fuse.c#L730 -- but I'm not sure why the test would trigger that code path: the test should be running with a clean document portal DB
<dot-tobias> ogra: So I rebuilt the core18 gadget from scratch, added âbase: 18â to my model assertion and dd'd the image to an SD card. All files show up in the root folder, but there's an additional folder âpi2-kernel_83.snapâ which I didn't notice before. Contains additional dtbs. And unfortunately, the Pi still won't boot ð HDMI output turns the screen on, but nothing visible and green LED doesn't blink once. IIRC that means âno noâ â¦
<zyga> ondra: excellent
<mup> PR snapd#6556 closed: cmd/snap: hide 'interfaces' command, show deprecation notice <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6556>
<zyga> ondra: please report the try issue as well
<ondra> zyga but as I said, this was service in snap to be installed, so it'd not affect already installed snap
<zyga> Iâm happy that the hook is sufficient to reproduce
<zyga> Ah
<zyga> Did you try removing the service from both revisions?
<ogra> dot-tobias, anything on serial (i forgot if u-boot actually prints to the display or serial only)
<dot-tobias> ogra: Bummed to say that I don't really know (or even have the necessary hardware?) how to do that. Will read up a bit on that and get back to you. Thank you!
<cachio> jamesh, I suppose it is something not being cleaned up corrently in that case
<ogra> dot-tobias, https://www.amazon.de/SainSmart-USB-TTL-Console-Raspberry/dp/B00KVUSI30 you want something like this
<cachio> jamesh, it is weird because the package is installed/uninstall as part of the test
<jamesh> cachio: I used to have some paranoid clean up in the prepare for these tests, but was asked to remove it and trust other tests to leave things in a pristine state
<mvo> degville: thanks for letting me know
 * dot-tobias tips hat to ogra
<jamesh> cachio: I suspect it is some user-level configuration rather than something that would be affected by package install/uninstall
<cachio> jamesh, it is weird that I can't reproduce that error on ubuntu 18.10
<cachio> with the same code
<jamesh> cachio: yeah.  We've got 1.0.3 on both 18.04 and 18.10
<jamesh> cachio: scratch that.  On bionic 1.0.3 is still waiting in proposed
<cachio> jamesh, mmm, I'll try to test with 1.0.3 on bionic to see it that fix the issue
<cachio> jamesh, I'll let you know the results}
<jamesh> cachio: we definitely had problems when Cosmic had xdg-desktop-portal 1.0.2, which were fixed by 1.0.3.  Bionic seemed fine with the older 0.11, but we've been trying to get 1.0.3 rolled out to all the old releases.
<jamesh> It wouldn't surprise me if there is some other corner case in the older version that I didn't hit when testing
<ondra> zyga and when I return 0 as result of the hook, then snapd is tricked and refresh works
<zyga> ondra: well, that's expected
<ondra> zyga though of course there are all the errors there
<zyga> the beauty(*) of  shell
<ondra> zyga yep
<ondra> zyga so I have only one machine I'm able to reproduce this one
<ondra> zyga ha, was did you say was trick to check what core I'm running against if I can snap run --shell
<zyga> ondra: it's easier to use nsenter
<zyga> ondra: nsenter -m/run/snapd/ns/foo.mnt
<zyga> then see what / is
<ondra> zyga nsenter: neither filename nor target pid supplied for ns/mnt
<zyga> -marg, not -m ar
<ondra> zyga because even now installed, it still seems to run with wrong base
<zyga> nesenter cli parsing is very strict
<ondra> zyga nsenter: reassociate to namespace 'ns/mnt' failed: Invalid argument
<zyga> what is the command you ran exactly?
<ondra> zyga when running nsenter -m/run/snapd/ns/opengrok.mnt
<zyga> sudo?
<zyga> actually
<zyga> no
<ondra> zyga same with sudo
<zyga> EINVAL means it's not mounted anymore
<zyga> that's ... odd
<zyga> we used to unmount but keep the file
<zyga> but recently we always unlink it for clarity
<zyga> ondra: note that snap-confine may not save a new mount namespace if construction fails
<zyga> ondra: and may discard a mount namespace when it is stale
<zyga> ondra: but that should not happen here (construction should not fail)
<ondra> zyga so I still get into that namespace despite the error
<ondra> zyga and it's indeed using core16 base
<zyga> ondra: uh?
<zyga> the erorr is ... od
<zyga> either setns worked or it did not work
<zyga> ondra: I'm at risk of getting lost here, can you please collect this information in the bug report
<ondra> zyga https://paste.ubuntu.com/p/99Pz3wQ79P/
<zyga> ondra: I think the bug may be separate from the core -> core18 bug
<zyga> ondra: that is, there is something wonky with hook dependency (CC pstolowski)
<ondra> zyga on machine where it works I get: https://paste.ubuntu.com/p/jhCTxk7mwH/
<zyga> ondra: that nsenter looks ok
<zyga> no EINVAL anymore
<ondra> zyga see the difference in library version
<zyga> 2.23?
<ondra> zyga yep, that is wrong glibc
<ondra> zyga should be 2.27
<zyga> ondra: please refresh my memory,  core16 has 2.23 and core18 has 2.27?
<zyga> ondra: can you run findmnt and tell me what / is please?
<ondra> zyga correct
<zyga> ondra: so, one observation, it would be neat to always have logging in snap-confine and log that to syslog or something
<zyga> ondra: this way we would know what happened for sure
<ondra> zyga /                                              /dev/loop0
<zyga> losetup  -l?
<zyga> oh
<zyga> one sec
<zyga> so
<ondra> zyga /dev/loop0         0      0         1  1 /var/lib/snapd/snaps/core_6130.snap (deleted)
<zyga> SNAP_CONFINE_DEBUG=yes snap run --shell ...
<zyga> oh?
<zyga> deleted is certainly interesting
<zyga> (the plot thickens)
<zyga> ondra: that will now tell you what snap-confine detected
<zyga> it should tell you that the mount namespace is stale but occupied
<ondra> zyga on other machine it looks correct
<zyga> is that snap really deleted on the fs?
<ondra> zyga already seeing loop0 indicates something is hanged :)
<zyga> deleted is very nasty :/
<zyga> wait, this is core!
<zyga> right?
<zyga> ooooh
<zyga> man I know
<zyga> so
<zyga> we have a bug
 * zyga slows down to think 
<ondra> zyga /var/lib/snapd/snaps/core_6130.snap does not exist at all
<zyga> ondra: specifically this is ubuntu-core 16 right?
<zyga> a core system
<ondra> zyga classic
<zyga> aha
<zyga> in that case it's back to regularly interestngi
<ondra> zyga 18.04
<zyga> I suspected there  are bugs in core->core18 sans reboot refreshes
<zyga> but let's think
<zyga> do you have snap changes that indicate something happening to revision 6130?
<zyga> I suspect it was just garbage collected
<ondra> zyga yeah nothing in changes
<zyga> ok
<zyga> SNAP_CONFINE_DEBUG=yes snap run --shell ...
<zyga> what does that say?
<zyga> (use the  real snap name there)
<zyga> ondra: (suspense music plays)
<ondra> zyga https://paste.ubuntu.com/p/7w6nRX4Y4J/
<zyga> DEBUG: sending information about the state of the mount namespace (discard)
<cachio> jamesh, same error with 1.0.3
<zyga> DEBUG: the mount namespace is stale and should be discarded
<cachio> jamesh, I have a debug session open, do you want to take a look?
<zyga> when you do this you must  keep something in there running
<zyga> now you should see core18 /
<zyga> ondra: as I said, when the error happens there are still some processes lingering
<zyga> ondra: so snap-confine knows it's supposed to discard but chooses not to
<zyga> ondra: can you confirm that / is now core18?
<ondra> zyga no / is core16 still in that name space
<zyga> ondra: DEBUG: found process 6540 belonging to user 0
<zyga> I missed that
<zyga> what is that process
<ondra> zyga funny ps -aux does not show anything running from old revision
<zyga> ondra: coin on the edge
<zyga> ondra: it's a thread
<zyga> can you find that in /proc please?
<zyga> ondra: a bit of go thread is running and it inhabits that namespace somehow (wild guess)
<ondra> zyga I assume reboot will fix this as whatever is hanging will die, that stale core revision seems pretty old
<zyga> ondra: don't reboot
<zyga> ondra: find out what process 6540 is
<zyga> what's /proc/6540/exe ?
<zyga> ondra: inspect it from the outside please)
<ondra> zyga I refreshed back to base core18 snap, debug log was from revision running against core16 and that was functioning
<zyga> ondra: can you reproduce this enough to see the dangling process and find out what it was please?
<zyga> ondra: you can look at /sys/fs/cgroup/freezer/snap.$SNAP_NAME/cgroup.procs for the list of inhabitants
<zyga> ondra: (to avoid using snap-confine)
<ondra> zyga now same on broken revision, process id I see from snap confine is ssh-agent
<zyga> oh
<zyga> how did that get there?
<pedronis> Chipaca: thanks for the review
<ondra> zyga snap is running ssh-agent
<zyga> ondra: so there's a ssh-agent running in that mount namespace
<zyga> ondra: and that is a "service" (but not)
<zyga> ondra: who starts it?
<ondra> zyga it's forked
<zyga> is that a service / app in the snap>?
<ondra> zyga service will check if it's running and starts it
<zyga> the service that is a part of the snap?
<ondra> zyga I suppose I can add it as service
<zyga> ondra: if you forgete refreshes for a second
<zyga> if you stop the service who started i
<zyga> does it stop ssh-agent?
<zyga> or is that a process that is not stopped across restart (effectively)
<ondra> zyga no it will not stop it when you stop service
<zyga> ondra: so that's that
<zyga> ondra: it's a feature
<zyga> ondra: we don't discard the mount namespace when there are apps or hooks running that would then observe old/new fs together with other processes in that snap
<ondra> zyga shall I kill the process and test refresh?
<zyga> ondra: refresh-app-awareness would refuse to refresh your snap
<zyga> ondra: please
<zyga> ondra: we do have a bug
<zyga> ondra: about core / core18
<ondra> zyga not yet
<zyga> or in general where base snap name changes
<zyga> that should behave in a different (yet undesigned way)
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6098, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491,
<mup> snapd#6502, snapd#6541, snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6585, snapd#6588, snapd#6589
<ondra> zyga lol different error cannot unlink opengrok.mnt: Device or resource busy
<zyga> ondra: uname -r?
<zyga> ondra: that's a known kernel behavior on old (3.10) kernels
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6098, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491,
<mup> snapd#6502, snapd#6541, snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6585, snapd#6588, snapd#6589
<ondra> zyga I'm on 4.15
<zyga> ondra: that's new then :)
<zyga> ondra: new and not fun
<zyga> ondra: can you run SNAPD_DEBUG=1  snap-discard-ns
<zyga> with the snap name
<zyga> well
<zyga> specifically
<zyga> unlink is expected to fail
<zyga> but we should have unmounted it before
<zyga> run stat on that file
<zyga> and stat -f please
<zyga> perhaps before you discard it
<ondra> zyga but since I killed that process I'm now running core18
<zyga> to see what's currently there
<ondra> zyga nothing with stat -f
<zyga> nothing as in?
<ondra> zyga https://paste.ubuntu.com/p/7DmG45TYnz/
<zyga>     ID: 0        Namelen: 255     Type: nsfs
<zyga> this is relevant
<zyga> it's a mounted namespace
<zyga> so it cannot be unlinked
<zyga> the question is: why did  snap-discard-ns not unmount it>
<ondra> zyga so I will redo snap to run ssh-agent as service, I guess this should then fix it
<zyga> which version of snapd are you on?
<ondra> zyga 2.37.2
<zyga> I forgot when snap-confine started  using snap-discard-ns but I suspect it's been before than that
<zyga> what happens if you want to discard the mount namespace and use SNAPD_DEBUG=1 SNAP_CONFINE_DEBUG=yes snap-discard-ns?
<zyga> (note: make sure to use the right binary, reexec wise)
<ondra> zyga where do I get snap-discard-ns
<zyga> ondra: it's right next to snap-confine
<zyga> either in /usr/lib/snapd or in the core snap in the same path
<ondra> zyga https://paste.ubuntu.com/p/fGPY9WNRrp/
<zyga> ondra: what's the version of snapd on the hostt?
<zyga> woah
<zyga> that's neat
<mup> PR snapd#6590 closed: daemon/api: filter connections with hotplug-gone=true <Created by stolowski> <https://github.com/snapcore/snapd/pull/6590>
<zyga> so it unmounted it, supposedly without erorrs
<ondra> zyga 2.37.2
<zyga> and then it ... failed to unlink it because it is still mounted
<zyga> can you re-run
<zyga> with strace  please?
<zyga> (ditch the debug options)
<zyga> and report this as a new bug
<zyga> it's a weird kernel behavior, unless we're missing something
 * zyga cannot wait for the strace
<ondra> zyga https://paste.ubuntu.com/p/SkBMzTPpHX/
<ondra> zyga so you want bug with which exactly? :)
<ondra> zyga I will paste those longs in, jut to know how to call it
<zyga> woah
<zyga> I see
<zyga> fstatfs(5, {f_type=TMPFS_MAGIC, f_bsize=4096, f_blocks=255810, f_bfree=255557, f_bavail=255557, f_files=1279048, f_ffree=1278375, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOSUID|ST_NOEXEC|ST_RELATIME}) = 0
<zyga> so...
<zyga> findmnt?
<zyga> it looks like a kernel bug
<zyga> we look at the .mnt file, see it's a TMPFS (not nsfs), try to unlink it and hit a EBUSY error
<zyga> can you repeat the stat -f call on the file agani
<zyga> you reported it was nsfs before
<zyga> is it still?
<mup> PR core18#119 opened: Add a default locale <Created by sil2100> <https://github.com/snapcore/core18/pull/119>
<zyga> ondra: ?
 * zyga is dying from suspense
<mup> PR snapd#6590 opened: daemon/api: filter connections with hotplug-gone=true <Created by stolowski> <https://github.com/snapcore/snapd/pull/6590>
<ondra> zyga yeah now it's tmpfs
<zyga> ondra: findmnt
<zyga> is it a bind mount?
<zyga> or /proc/self/mountinfo if you fancy that instead
<ondra> zyga findmnt in the namespace?
<zyga> outside, all of discard should be done outside
<zyga> inside that _IS_ expected to happen
<zyga> (AFAIK)
<ondra> zyga https://paste.ubuntu.com/p/4S3VJyJJCv/
<zyga> â   ââ/run/snapd/ns/opengrok.mnt      nsfs[mnt:[4026532246]] nsfs       rw
<zyga> outside it is mounted
<zyga> were you running discard from within the mount namespace by any chance?
<ondra> no from outside
<zyga> and that strace where it showed to be a tmpfs, that was outside as well?
<ondra> yes
<zyga> ondra: please report this
<ondra> all from outside
<zyga> ondra: one bug for base core -> core18 design change on running processes
<zyga> ondra: one bug on discard that we just talked about
<zyga> ondra: I think there are no other things to report at this time, do you agree?
<ondra> zyga agree
<ondra> zyga I will do bugs tonight, now meetings
<zyga> ondra: *thank you*
<zyga> this is super valuable
 * zyga hugs ondra 
<pstolowski> zyga: sorry, i saw you ping but haven't followed the long discussion you had with ondra, is there anything i should look at re hooks?
<zyga> pstolowski: no, it's all clear now
<zyga> there was a hidden app running
<zyga> all is good
 * zyga heads home
<zyga> afk for some time
<pstolowski> ok
<pedronis> zyga: I'm not sure that PR needs to be resplit but I made some comments there
<ondra> zyga you are welcome and thank you!  this was intense :D
<cachio> mvo, we have core 2.37.4 on stable now
<cachio> pedronis, ~
<pedronis> thx
<mvo> cachio: thank you!
 * cachio lunch
<mup> PR core18#120 opened: Backport wpa_supplicant.service.d/snap.conf from core <Created by sil2100> <https://github.com/snapcore/core18/pull/120>
<mup> PR core18#119 closed: Add a default locale <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/119>
<mvo> sil2100: thanks!
<sil2100> mvo: yw! The locale one was very trivial so I just ekhm, self-merged it
<sil2100> We'll make sure it goes out with the nearest snap
<mvo> xnox: do you mind if I do a systemd SRU? with the timedatectl fix and the new 1819728 fix?
<mvo> sil2100: thank you!
<xnox> mvo, go go go =)
<xnox> mvo, but also if mark files a proposed regression bug report, it will be on you to revert ;-)
<mvo> xnox: cool, thank you
<mvo> xnox: sure, its perfectly safe ;)
<mvo> xnox: already in the upstream systemd etc
<xnox> yeah yeah, ddstreet thought so too =)
<mvo> (since 1y almost)
<xnox> yet got caught up by missing pieces of things =)))))
<xnox> mvo, most of them do go through fine.
<mvo> xnox: heh - thats fine, I need to prepare the details and then I will show you the final debdiff
<mvo> xnox: so tomorrow
<mvo> xnox: still thanks for the green light
 * zyga is home
<mup> PR snapd#6591 opened: [RFC] managers: basic measurements <Created by stolowski> <https://github.com/snapcore/snapd/pull/6591>
<mup> PR snapcraft#2498 closed: python plugin: graceful ret when no packages set <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2498>
<jdstrand> pedronis: hey, just for my own prioritizing, when are you shooting for a 2.38 upload to disco?
<jdstrand> mvo: hey, maybe that is a question for you: just for my own prioritizing, when are you
<jdstrand> shooting for a 2.38 upload to disco?
<mup> PR snapcraft#2500 opened: DRAFT: Add remote build <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2500>
<mvo> jdstrand: probably end of this week, why? anything pending?
<jdstrand> mvo: nothing for you. I can't upload apparmor 2.13 without 2.38 is all
<jdstrand> (2.13 will break snap removes with system where apparmor is enabled)
<mvo> jdstrand: ok
 * cachio afk
<mup> PR snapcraft#2501 opened: nodejs pluging: support for type str bin entries <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2501>
<mup> PR snapcraft#2496 closed: many: support the use of build-aux/snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2496>
<Pharaoh_Atem> I was hoping that 2.38 would have the selinux stuff :(
<popey> jdstrand:  is it possible personal-files could grow exec to go with read and write?
<popey> jdstrand: i have an app which uses a go library called byteexec which writes go byte arrays as executables in ~/.byteexec, but fails for me because while it can write, it can't exec
<jdstrand> popey: it isn't really meant for that and that could easily lead to exec transition conflicts. why can't it write to SNAP_USER_DATA (which is $HOME to the snap)?
<popey> jdstrand: no, this doesn't seem to work https://github.com/getlantern/byteexec/blob/master/byteexec.go#L111
<jdstrand> popey: patch that or file a bug to have them look at HOME?
<jdstrand> popey: alternatively, the snap could use personal-files for ~/.bytecode and then create a symlink from there to SNAP_USER_DATA. it is a hack, but should work
<popey> huh, that's interesting
 * popey breaks out the wrapper scripts
<sergiusens> jdstrand: layouts!
<sergiusens> user.Current opens up /etc/passwd to find out the user, so a code patch could work too
<sergiusens> jdstrand: if we are going to commit to HOME being SNAP_USER_DATA perhaps it would be a good idea to have the bind mounted /etc/passwd path to that as home
<jdstrand> sergiusens: it won't work for the user's home atm
<jdstrand> better than bind mounting is likely an nss module that is snap aware
<sergiusens> jdstrand: yeah, but the go std lib opens /etc/passwd and reads straight from there (I haven't looked in detail or seen how they solve nis and such)
<jdstrand> that a dumb way to do it. the home may not even be in /etc/passwd
<jdstrand> maybe they have a fallback that does nss
<popey> should $HOME point to the users outside home dir?
<popey> because now I'm wondering how my launcher can know what the home dir outside the snap is named
<jdstrand> popey: $HOME should be set to SNAP_USER_DATA when the snap starts. you can use 'getent passwd $(id -u) | cut -d : -f 6' to see what the system has to say about it
<popey> hah, that's memorable
<popey> jdstrand:  ok, moving things and symlinking helped my next issue is that the binary which runs is trying to set the system proxy. I don't see any interfaces which can do that. Is it something I should request?
<jdstrand> popey: that is a surprising request for your app but I see no reason why we couldn't have an interface for it. of course, it depends on what it is trying to actually do, but a forum post is good
<popey> What should I capture? strace? :)
<popey> it's a blob which tries to set the proxy
<popey> hmm, looks like it rummages in gsettings. I'll start a thready, thanks
<Guest92> hi all. i'm trying to build a snap that depends on mono. the version of mono from apt is too old, so trying to work out how to pull in the latest versions directly
<Guest92> something roughly equivalent to => echo 'deb https://download.mono-project.com/repo/ubuntu stable-bionic main' | sudo tee /etc/apt/sources.list.d/mono-official-stable.list
<Guest92> from what i've read so far, this doesn't seem to be possible?
#snappy 2019-03-13
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mup> PR snapd#6592 opened: cmd/snap-seccomp: version-info subcommand <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6592>
<zyga> Hey guys :-)
<mborzecki> zyga: hey
<zyga> I missed that review
<zyga> 1st thing today
<mborzecki> zyga: which one?
<zyga> Seccomp
<pedronis> I asked to split it
<pedronis> I put a comment in it about that
<pedronis> now
<mup> PR snapd#6593 opened: sandbox/seccomp: a helper package wrapping calls to snap-seccomp <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6593>
<mborzecki> pedronis: thanks
<mborzecki> zyga: i've pulled out the version-info subcommand and sandbox/seccomp into separate packages
<mborzecki> zyga: left a comment under #6588 hopefully it makes sense for the discussion
<mup> PR #6588: interfaces/apparmor: partial confinement on openSUSE <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6588>
<zyga> ack, thank you
<mvo> xnox: about the systemd sru - for bionic I prepared http://paste.ubuntu.com/p/gkm5MFpYXT/ - if this looks ok I will upload after my testing is complete
<mup> PR snapd#6589 closed: daemon: support returning assertion information as JSON with the "json" query parameter <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6589>
<pstolowski> mornings
<zyga> hey pawel
<mvo> hey pstolowski
<dot-tobias> good morning everyone
<pedronis> mborzecki: I did a pass on those split out PRs, I mostly have questions atm
<mborzecki> pedronis: thanks
<mup> PR snapd#6585 closed: tests: add undo test with hanging stop command <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6585>
 * zyga breakfast
<zyga> re
<zyga> ondra: hey, did  you have the chance to file those bugs?
<zyga> mborzecki: there's a potentially interesting bug or kernel "feature"
<mborzecki> zyga: hm? which one?
<zyga> mborzecki: ondra has the details but seems like inconsistency of what snap-discard-ns sees
<zyga> I cannot explain it yet
<ondra> zyga sorry, I have not, working on them now
<zyga> thanks!
<mborzecki> zyga: the thing with processes/thread still runnin in the cgroup?
<zyga> mborzecki: no, with fstatfs saying one thing to snap-discard-ns and another to  shell (which implies something is missing because this is unlikely)
<mborzecki> oh
<mborzecki> zyga: do you have more details?
<zyga> mborzecki: snap-discard-ns fails because it gets EBUSY on unlink of .mnt file
<zyga> mborzecki: having statted it, seeing it is a tmpfs  so nothing to unmount
<pedronis> Chipaca: hi
<pedronis> Chipaca: I did pas over the epochs doc, here the texts in the boxes in the epochs svg diagram overflow them and also look smushed up, is that just my browser?
<pedronis> Chipaca: degville: I confess, I made also some pedantic tweaks/additions
<Chipaca> pedronis: can i see a screenshot?
<Chipaca> pedronis: as I said yesterday, the whole thing is very disjointed right now so anything helps :-)
<pedronis> well I added more info
<pedronis> not sure that helps
<Chipaca> pedronis: I'd originally pushed the diagram as a png, then re-pushed as an svg hoping it'd be clearer (hidpi being a thing)
<pedronis> Chipaca: it renders better, just now, go figure but still not 100%
<degville> pedronis: Chipaca: no problem. It all helps, but I was waiting until Chipaca had finished editing before I took a proper look.
<Chipaca> degville: all the information is there (i think); i could come back to it in a couple of days if it still needs restructuring then :-)
<Chipaca> need a couple of days head-space
<Chipaca> dunno why
<degville> Chipaca: honestly, that's exactly what I'm like. I think of it like composting my thoughts :)
<Chipaca> :-)
<pedronis> degville: as I said, I looked at it, I think most information is there now, it's not fluid as Chipaca mentioned
<Chipaca> also it's not clear (to me) that the graphic adds anything to it :-) but it helps write it at least
<degville> pedronis: yep, thanks. I'll take a look.
<Chipaca> pedronis: did you mean to write "...a revert that snapd doesn't block", vs. "...a revert, that snapd doesn't lock"?
<Chipaca> block*
<pedronis> Chipaca: there's a which there, not a that. Maybe it needs a comma and a that
<Chipaca> pedronis: a, which and that are (mostly) interchangeable; my point was about the comma
<Chipaca> or lack of it
<Chipaca> by which i mean
<Chipaca> as it stands, it says that some reverts are blocked by snapd
<Chipaca> or implies it at least
<Chipaca> which might be fine, if we should block reverts at some point :-)
<pedronis> I think we should
<pedronis> when we implement that other plan
<mborzecki> zyga: pedronis: i'll add a spread test to verify that list of syscalls
<pedronis> mborzecki: it can be a follow, just trying to understand if we have a plan how to manage it
<pedronis> Chipaca: feel free to add a comma if it helps
<mborzecki> pedronis: i'm afradi that's the best we can do for now
<mup> Bug #1819875 opened: base core16->core18 migration <Snappy:New> <https://launchpad.net/bugs/1819875>
<ondra> zyga https://bugs.launchpad.net/snappy/+bug/1819875
<mup> Bug #1819875: base core16->core18 migration <Snappy:New> <https://launchpad.net/bugs/1819875>
<mup> PR snapd#6594 opened: [RFC] tests: run smoke tests on (almost) pristine systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/6594>
<ondra> zyga is this descriptive enough for core16->core18 bug
<ondra> zyga now creating other bug
<zyga> ondra: thank you
<zyga> mvo: ^ that's a very important bug for core18 transition
<mvo> cjwatson: hey, does https://code.launchpad.net/~mvo/ubuntu-archive-publishing/sync-cnf-metadata/+merge/356117 look ok now with the updated script?
<mvo> zyga: looking
<mvo> zyga: uh, ok
<mvo> zyga: looks scary
<zyga> I added a comment
<mvo> zyga: ta
<zyga> Saviq: ^ important bug for your knowledge on core18 migration
<cjwatson> mvo: I think so, yes, thanks!  I'll work on landing that today
<mvo> cjwatson: thank you!
<Saviq> zyga: aha, and was that Multipass that you encountered this with?
<zyga> no, that's all thanks to ondra
<zyga> but I recall you added a track to fix some migration issues
<Saviq> also, would you then recommend to defer the migration until this is solved?
<zyga> yes
<zyga> it's a blocker IMO
<Saviq> :'-|
<Chipaca> zyga: we touched on this yesterday in the standup
<Chipaca> fwiw
<zyga> Chipaca: aha, thanks
<pedronis> Chipaca: degville: a thing about the epoch docs, we are treating big/slow migration data and SNAP_COMMON (slightly) orthogonally but usually one implies the other, wondering if that can help simplify things a bit or not
<mvo> xnox: new systemd for bionic is uploaded to -proposed, debdiff is unchanged
<Chipaca> mvo: is there a reason to leave get-model as a POST?
<Chipaca> mvo: as opposed to one of the GET options that were mentioned
<mvo> Chipaca: no reason, I can make this a get of course
<mvo> Chipaca: so GET and "model" ?
<ondra> zyga second one with most logs I could collect https://bugs.launchpad.net/snappy/+bug/1819887
<mup> Bug #1819887: snap-discard-ns fails <Snappy:New> <https://launchpad.net/bugs/1819887>
<zyga> ondra: thank you
<ondra> zyga let me know if there was something missing
<mvo> pedronis: I uploaded systemd with a fix for the systemctl race to the edge ppa, so the next core will have that package
<zyga> I will review it
<mup> Bug #1819887 opened: snap-discard-ns fails <Snappy:New for zyga> <https://launchpad.net/bugs/1819887>
<Chipaca> mvo: or a GET on /v2/model (was it?)
<pedronis> Chipaca: as I said that needs design
<mvo> Chipaca: my understanding was that pedronis did not feel we are ready for this as an official api yet
<Chipaca> pedronis: ah ok
<Chipaca> mvo: yes, GET and 'model', i'd like it more
<Chipaca> mvo: also that would let you not use sudo to get the model
<Chipaca> mvo: which seems a'ight
<pedronis> it's not hard design
<pedronis> but I don't think this should block on that
<mup> PR snapd#6590 closed: daemon/api: filter connections with hotplug-gone=true <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6590>
<mup> PR snapd#6098 closed: interfaces/builtin: support hotplug for camera interface <Hotplug ð> <â Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/6098>
<pstolowski> zyga: hey, can you take a look at #6491 again when you have some time?
<mup> PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>
<zyga> hey, sure, enqueued for today
<pstolowski> thanks
<ewp> guys i'm struggling to work something out
<ewp> as far as i understand it, a snap squashfs is readonly, so building a snapcraft.yaml with an app that has a command line cert-sync $SNAP/etc/ssl/certs/ca-certificates.crt seems like it won't be able to modify the filesystem when the snap is running, so I think running something which would modify the filesystem needs to executed during the build pr
<ewp> ocess?
<mup> PR snapcraft#2491 closed: Fix multipass error handling spread test <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2491>
<mvo> the edge core now has the snapd snap with the updated systemd
<Chipaca> ok, breaking for gym and lunch, ttfn
<pstolowski> pedronis: I made a rough estimate for #6591, see last comment
<mup> PR #6591: [RFC] managers: basic measurements <Created by stolowski> <https://github.com/snapcore/snapd/pull/6591>
<pedronis> pstolowski: so it's half the size of my current state.json
<mup> PR snapd#6595 opened: tests: add regression test for systemctl race fix <Created by mvo5> <https://github.com/snapcore/snapd/pull/6595>
<pstolowski> pedronis: yes, not exactly small
<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#2473, snapcraft#2479, snapcraft#2493,
<mup> snapcraft#2495, snapcraft#2497, snapcraft#2500, snapcraft#2501
<pedronis> pstolowski: whare are these two lines about:
<pedronis>  85.590985ms		setup-profiles, Setup snap "htop" (1168) security profiles
<pedronis>  85.367741ms			setup profiles, setup profiles of snap "htop"
<pedronis> they seem to say the same stuff?
<pedronis> are they two entries?
<pedronis> or just one but the printing repeats it
<pstolowski> pedronis: we create Timings at the very start of the doSetupProfiles task handler; then we measure the call to m.setupProfilesForSnap(..), that's the second line and it's indented as it's under the task's Timings
<pstolowski> pedronis: at the moment the structure of these timings more-less reflects call hierarchy in the code
<pstolowski> that's a bit wasteful, yes. i thought it would make it easier to understand
<pedronis> pstolowski: we need to be a bit careful because nesting is mental overhead
<pedronis> though
<mborzecki> pushing the spread test for syscalls in a bit
<mborzecki> had to tweak the PR a bit
<sergiusens> ewp: something like this might help https://docs.snapcraft.io/scriptlets/4892
<ewp> ace, looks promising- thank you
<ewp> if i was going to *-override one of the steps, and wanted to `touch somefile` is there anything else i'd need to do for it to be pulled into the snap, other than just touch it?
<ewp> i guess just touch in the prime-override step?
<cachio> mvo, hey, is it ok to promote snapd snap 2.37.4 to stable?
<pedronis> cachio: you did already, no?
<pedronis> ah, snapd snap
<pedronis> sorry
<cachio> pedronis, :)
<mvo> cachio: yes, if QA is green +1
<cachio> mvo, yes it is
<mvo> cachio: then yes
<sil2100> ogra: hey! So pi3 gadget for 16 should have a new version in edge for testing
<sil2100> ogra: could you give it a spin?
 * sil2100 needs to clean up branch permissions again one day
<mvo> pedronis: just FYI, I pulled the core snap with the xenial version of the systemd fix as it causes issues, I'm investigating but it seems to be only manifesting itself on core systems, part of the problem is that systemd 229->239 is quite a large jump so the diff is less obvious than its for the bionic verison
<Wimpress> degville: We are having a Snapathon at Bluefin today. Basically the whole team helping get developers over then line with their snap.
<Wimpress> It has been great to be able to link directly to our docs in the emails and GitHub issues today.
<Wimpress> Thanks for all your hard work, it is making this way easier for us!
<pedronis> mvo: ok, :(
<pedronis> mborzecki: I made some comment about the compiler lookup, hope they make some sense
<degville> Wimpress: thanks so much for letting me know - especially as I/we know there's still an awful lot to do, but I really appreciate the feedback.
<mborzecki> pedronis: yup, saw that, thanks
<mborzecki> pedronis: zyga: pushed the spread test that checks libseccomp syscalls list
<cachio> mvo, snpad 2.37.4 in stable
<cachio> pedronis, ~
<pedronis> thx
<ogra> sil2100, will do (later today) and let you know
<sil2100> ogra: thanks o/
<cachio> mvo, pedronis I have a school meeting now, I'll try to be back for standup
<cachio> perhaps I'll be joining late
 * cachio afk
<mborzecki> off to pick up the kids, may arrive a bit late to the standup
<mvo> cachio: thanks for letting us know
<zyga> pedronis: I've split the refactoring into small logical chanegs
<zyga> pedronis: I've kept all the tests in main, only adding new tests
<zyga> pedronis: and left a few tiny tweaks that were beyond the refactoring
<zyga> pedronis: I'll run a pass of spread over this
<zyga> pedronis: then I can push the branch, any prefix of history is a good review candidate
<pedronis> zyga: ok, this is about 6360 ?
<zyga> pedronis: from  one patch to roughly one third
<zyga> yes
<pedronis> zyga: it looked like it could be split in 2 or 3
<zyga> (had to double check the PR number :)
<zyga> pedronis: I can easily make 2-3 PRs now
<pedronis> ok
<zyga> pedronis: I just kept the patch granularity smaller for better bisect / review / comments
<zyga> pedronis: I've started a local spread run, I'll grab lunch and push the branch up and open the first review
<pedronis> ok
<pedronis> zyga: we should try to land the snap-confine ones, given it seem it will need further work soon
<zyga> the things that are different from this version and the monolith are only the retantion of tests in main_test
<zyga> pedronis: yes, that will be my next task
<pedronis> ok
<zyga> pedronis: and the small leak from future work on per-user mount persistence for what the assumptions should look like (harmless but I left it out since it belongs logically with the rest of the persistence  work)
<mvo> mborzecki: standup?
<mborzecki> type=AVC msg=audit(1552471518.269:2577): avc:  denied  { read } for  pid=23614 comm="sshd" name="gai.conf" dev="sda1" ino=594389 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file permissive=0
<mborzecki> do we mess with gai.conf in the tests?
<mborzecki> heh we do
<Chipaca> zyga, mborzecki: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1810027
<mup> Bug #1810027: Snaps won't start - stack smashing detected  <snapd (Ubuntu):New> <https://launchpad.net/bugs/1810027>
<mup> PR snapcraft#2497 closed: Improved error message for 'version' specific cases (type error and bad length) <Created by facundobatista> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2497>
<pedronis> mborzecki: we do, or least did on linode, maybe we don't on gcloud, not sure
<mup> PR snapd#6596 opened: spread: restore SELinux context when we mess with system files <SELinux> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6596>
<mborzecki> super simple PR ^^
<ewp> really struggling to understand the snaps documentation. is the dump plugin able to copy files from outside the snapcraft directory?
<mvo> pedronis: good news! my fixed fixed systemd for xenial boots now without segv
<Chipaca> degville: https://mobile.twitter.com/damocrat/status/1105571463778709504 fwiw
<pedronis> great
<pedronis> mvo: ^
<Chipaca> mvo: where's the fun in a non-segv'ing pid 1?
<degville> Chipaca: aha, thanks!
<ondra> zyga not sure how urgent is this one as it's result of use of snap try
<Chipaca> mvo: or split it after fun, and have a little poem
<mvo> Chipaca: heh :) I'm fine with opting out of the fun, I had fun all morning
<ondra> zyga but now I have snap installed, but not really there and I cannot remove it
<mvo> Chipaca: lol
 * mvo hugs john 'the poem' lenton
<ondra> zyga ERROR cannot discard snap namespace "opengrok", will retry in 3 mins: cannot discard preserved namespace of snap "opengrok": cannot unlink opengrok.mnt: Device or resource busy
<mvo> the poet even
<ondra> zyga I have got to this point few times before when using snap try and then deleting linked prime dir
<ondra> zyga on one machine I eventually needed to edit state.json to get out of the trouble :)
<zyga> ondra: I'm afk now, just reboot to fix it
<zyga> ondra: but report things please
<ondra> zyga yeah collecting logs
<zyga> thanks
 * zyga is now AFK
<mup> PR snapd#6597 opened: cmd/snap-update-ns: refactor of profile application (1/N) <Created by zyga> <https://github.com/snapcore/snapd/pull/6597>
<Chipaca> hmmm
 * cachio lunch
<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
<mvo> xnox: fwiw, re systemd SRU, I created 1819278 and uploaded systemd for xenial,bionic into the unapproved queue, please let me know if it looks ok or if I was too trigger happy
<mvo> pedronis: good news, fully spread test with new systemd was successful
<mvo> so I think we have a winner
<pstolowski> pedronis: any good name for interface for both Timings and Span? my current working name is Measurement
<pedronis> pstolowski: I think Measurer though strange it's a more go patterned name
<pstolowski> pedronis: right.. won't be the first.. we have Attrer already, and probably a few others
<mup> PR snapd#6598 opened: overlord/snapstate, store: set a header when auto-refreshing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6598>
<pedronis> pstolowski: not a full review, but I skimmed the in progress PR and the direction looks good, probably we should stare at output/size again
<pstolowski> pedronis: thanks; yes, i trimmed it quite a bit, will recheck the size
<pstolowski> pedronis: i also plan to play with threshold in this PR
<pedronis> pstolowski: added a couple of comments, one about one of you your questions
<pstolowski> great
<ewp> when snapcrafting, how would I go about targeting files into the user's home directory?
<ewp> would like to move some files into ~ but not sure how to do this, could anyone point me in the right direction please
<pedronis> Chipaca: some comments on the PR
<pedronis> Chipaca: & thank you
<mvo> pedronis: 6401 should address your points
<mvo> I mean, it should be ready for a re-review
<pedronis> mvo: thx, probably in the morning at this point
<mvo> pedronis: thats fine, thanks
<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> ewp: hey
<ewp> hi
<zyga> Snapcraft cannot package files into the users home directory
<ewp> damn. useful to know- ok, thanks.
<zyga> Can you tell me more about what you are trying to do?
<zyga> You can write an install hook
<ewp> think i'm a bit stuck then. mono (c#) uses (/home/user/.config/.mono/certs/) and (/usr/share/.mono/certs/) as the TLS root certificate store
<zyga> But even then you should probably not copy stuff to any home location
<zyga> Aha
<ewp> but doesn't give us an option to change those paths, so i'm struggling to find a way to let stuff inside the package access the trusted root stores without breaking containment
<zyga> So at runtime HOME is set to SNAP_USER_DATA
<zyga> A simple workaround is to just copy the certificate store from the snap
<zyga> Alternatively you may use layouts to make /use/share/.mono/certs contain a part of your snap
<ewp> i've been trying this, but I think mono is trying to get at /usr/share/ which I'm assuming is not accessible in strict containment mode?
<zyga> Look for âlayoutsâ documentation on the forum
<zyga> That should make it work
<ewp> layouts! interesting, thank you that's a great pointer, i'll take a look
<zyga> Good luck ð
<ewp> thanks zyga ^_^
<ewp> zyga, i've setup layouts "/etc/ssl/certs:" to "bind: $SNAP/etc/ssl/certs"
<ewp> i've installed the snap, and connected to the shell `snap run --shell my-snap`
<ewp> ll /etc/ssl/certs gives me permission denied, but so does ll /snap/my-snap/x1/etc/ssl/certs
<ewp> i'm not sure if this is expected behaviour, but it doesn't seem to give me (or mono) access to that certs directory
<ewp> oops, had the path wrong. I can infact change directory into /snap/my-snap/x1/etc/ssl/certs, but 0 files contained,  is the layout directive meant to populate that directory with the contents of /etc/ssl/certs ?
<willcooke> Chipaca, ahoy!  Want to do more debugging here?   I'm happy to paste to the forum with anything relevant, but this might be quicker?
<Chipaca> willcooke: as you wish :-)
<Chipaca> willcooke: do you have anything mounted in /snap ?
<Chipaca> willcooke: findmnt -t squashfs ?
<willcooke>  /var/lib/snapd/snaps/core_6405.snap on /snap/core/6405 type squashfs (ro,nodev,relatime,x-gdu.hide)
<willcooke> $ findmnt -t squashfs
<willcooke> TARGET                   SOURCE     FSTYPE   OPTIONS
<willcooke>  /snap/gnome-3-26-1604/82 /dev/loop0 squashfs ro,nodev,relatime
<willcooke>  /snap/core/6405          /dev/loop1 squashfs ro,nodev,relatime
<Chipaca> willcooke: so, no gnome-calculator
<willcooke> correct, no gnome-calc, or any of the other seeded snaps, except the platform snap and core
<Chipaca> willcooke: what's in the seed?
<Chipaca> mvo: are you around?
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502,
<mup> snapd#6541, snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6596, snapd#6597, snapd#6598
<Chipaca> I'm suspecting the old "missing prerequisites in seed"
<Chipaca> but, i dunno
<willcooke> Desktop snaps: these also exist in ubuntu-release-upgrader's DistUpgradeQuirks.py for users who upgrade.
<willcooke>  * snap:gnome-3-26-1604
<willcooke>  * snap:gtk-common-themes
<willcooke>  * snap:gnome-calculator
<willcooke>  * snap:gnome-characters
<willcooke>  * snap:gnome-logs
<willcooke>  * snap:gnome-system-monitor
<willcooke> oh, hold on a sec
<willcooke> that's the minimal file
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502,
<mup> snapd#6541, snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6596, snapd#6597, snapd#6598
<willcooke> seb128, seeds for disco...
<willcooke> http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.disco/desktop-minimal
<willcooke> http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.disco/desktop
<willcooke> The snaps only appear in the minimal file
<willcooke> is that expected?
<willcooke> I'd say it is, that the full layers on top of minimal
<willcooke> but want to be sure
<Chipaca> willcooke: so, the first thing I'd do, is check that those snaps are self-sufficient
<Chipaca> willcooke: that is, if you start with an empty slate, and install those snaps in that order, that no other snaps get pulled in
<Chipaca> but, I'd have to check with mvo about whether this is enough to break seeding
<Chipaca> some work has gone into seeding since I last knew about it
<willcooke> so install a vm for example, remove everything except core, and then install them one by one?
<Chipaca> willcooke: apt purge snapd is probably quicker, but yes
<willcooke> I dont think this is a seeding issue fwiw, since it seems that kenvandine can't recreate the issue on the same ISO.
<Chipaca> OTOH snap remove alt-* shouldn't be too slow :-)
<willcooke> lemme do taht
<Chipaca> willcooke: if it's the old missing-prereq thing, snapd getting into a knot depends on when your network comes up
<Chipaca> so it's racy and machine-dependent
<kenvandine> oh... i'm doing a minimal install
<kenvandine> maybe that's the diff
<willcooke> ahhh
 * kenvandine tries
 * Chipaca slowly steps back into the mist
<kenvandine> but willcooke's "snap tasks" output listed all the seeded snaps
<Chipaca> kenvandine: yeah, it's definitely trying to seed
<Chipaca> kenvandine: in the minimal install that worked, what's the output of 'snap list'?
<kenvandine> i've already started a reinstall with normal
<kenvandine> but i know what it listed
<kenvandine> core, gnome-3-26-1604, gtk-common-themes, and the 4 seeded snaps
<kenvandine> well... i'm pretty sure gtk-common-themes was listed
<kenvandine> i know the others were
<Chipaca> it's in the list to seed, so it should be
<Chipaca> kenvandine: no core18?
<kenvandine> no core18
<kenvandine> shoudn't be
<kenvandine> yet
<Chipaca> kenvandine: and no gnome-99-fancypants
<kenvandine> gnome-3-26-1604 was there
<Chipaca> gnome-3-28-1804?
<kenvandine> nope
<Chipaca> i guess that goes with core18 as well
<kenvandine> yeah
<Chipaca> hm
<kenvandine> those shouldn't be there
<Chipaca> then it's not the missing prereq thing
<kenvandine> yeah
<popey> Welcome valentind :)
<valentind> Hey!
<valentind> So I am pushing this "base" snap and because it is a base, it requires manual review. "snapcraft push" fails because of that.
<valentind> I would like to know if it is possible to see if "snapcraft push" failed for another reason.
<valentind> Because I want to push from a CI.
<willcooke> kenvandine, Chipaca - full install in a vm - no snaps.  Testing minimal now....
<Chipaca> valentind: you should have a list of reasons, if any beyond the fact that it's a base
<pedronis> we changed seeding such that order should not be important anymore, but ideally all deps should be there
<Chipaca> pedronis: right, but it looks like the prereqs are there
<Chipaca> pedronis: dunno
<pedronis> do we have snapd logs of when it fails?
<Chipaca> pedronis: something's broken, and I'm being an egotist and hoping it's SEP
<kenvandine> Chipaca: http://paste.ubuntu.com/p/2TvBgYqCj2
<valentind> Chipaca, Is there any way I can make the output easier to parse? Like a json or yaml outpput?
<kenvandine> they are all there
<kenvandine> on a normal install
<willcooke> kenvandine, smells like a race
<willcooke> kenvandine, did you do yours on a vm?
<kenvandine> willcooke: but it works 100% of the time on my laptop :)
<kenvandine> yes
<kenvandine> all in a VM
<pedronis> a race of what?
<willcooke> dunno
<pedronis> snapd seeding is sequential
<willcooke> before snapd gets involved I expect
<pedronis> (for predictability)
<kenvandine> the output of snap tasks for willcooke's machine that failed looks like they all succeeded
<ewp> could somebody quickly sense check my understanding of layouts please? https://docs.snapcraft.io/snap-layouts/7207 if I create a layout declaration with a target path of /usr/share/foo that maps to a relative path in my snap, then inside the snap running ls on that relative path should show the contents of /usr/share/foo ?
<kenvandine> that smells of a snapd problem to me
<seb128> willcooke, yeah, I think the seed thing is expected, ubiquity/livecd-rootfs handle the snaps
<willcooke> thx seb128
<pedronis> kenvandine: if all the tasks are Done and the changes Done, then things are a success
<Chipaca> ewp: no, the other way around
<pedronis> snapd is pretty boring about that
<Chipaca> ewp: ls of /usr/share/foo would should stuff from inside your snap
<kenvandine> pedronis: right... but "snap list" didn't list all the ones that said done
<Chipaca> pedronis: things aren't mounted
<pedronis> Chipaca: mounted
<pedronis> I thought we added sanity checks about things not mounted
<pedronis> did we lose them?
<pedronis> do they get unmounted later
<kenvandine> pedronis: however i can't reproduce this at all... but a couple others can reproduce it reliably
<ewp> ohh, ok - i had that a bit backwards then, thanks. Is there a way to achieve what I described?
<pedronis> anyway mounting brings in systemd
<pedronis> our dear friend
<pedronis> as well
<pedronis> Chipaca: we had some crazy code that marked infos broken but continued nevertheless, but we fixed that I think
<ewp> I'm trying to bring the contents of /usr/share/foo into the snap, not exactly sure what the best plugin to use for this is
<ewp> so from inside the snap, an application can access "/usr/share/foo" and see the contents of that directory as it exists outside the snap
<willcooke> Chipaca, this lack of messages in the journal is interesting... I have the same empty log on my broken system
<willcooke> kenvandine, ^
<ewp> (reason: mono is looking for its certificate trust store in a hard-coded location)
<kenvandine> willcooke: empty for me as well
<kenvandine> but i have snaps listed
<ewp> so i'm thinking the only way it can work is if code executing inside the snap can open('/usr/share/foo')
<willcooke> ha.  there goes that idea then
<pedronis> Chipaca: this is the code: https://github.com/snapcore/snapd/blob/master/overlord/snapstate/handlers.go#L550
<Chipaca> willcooke: kenvandine: what's eating the logs? :-(
<Chipaca> pedronis: https://forum.snapcraft.io/t/no-more-preinstalled-snap-on-ubuntu-19-04/10339?u=chipaca if you want the whole context
<pedronis> Chipaca: I know, there is not a lot of useful logs there
<pedronis> though
<Chipaca> pedronis: see: missing logs :-(
<Chipaca> :-)
<pedronis> what eats the logs? and are they yummy?
<pedronis> (are they a healthy diet?)
<Chipaca> pedronis: https://i.imgur.com/ZjqZSse.jpg
<pedronis> ah, maybe yummy, definitely not healthy
<pedronis> Chipaca: anyway snaps are done but non mounted, empty logs, something is seriously off there, I doubt is just snapd
<Chipaca> pedronis: same
<Chipaca> pedronis: note not even the mount points exist
<kenvandine> so i checked the media-info file on my last disco installed and it was installed from the 20190309 iso, which is what the forum post first referenced
<willcooke> k, got some logs
<willcooke> adding [Service]
<willcooke> Environment=SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7
<willcooke> to the service file worked
<willcooke> without that, nada
<kenvandine> so logging isn't very verbose by default, i guess
<pedronis> not verbose but in the end relatively chatty
 * pedronis needs to stop
<kenvandine> well... i have reproduced it
<kenvandine> willcooke, Chipaca: ^^
<willcooke> ah!
<willcooke> I'm reintalling again
<kenvandine> snap tasks 1
<willcooke> :)
<kenvandine> shows all the tasks, looks all good
<kenvandine> but only core and gnome-3-26-1604 listed in snap list
<willcooke> kenvandine, what did you do to recreate?  Just keep reinstalling?
<willcooke> I see the same problem in the live session btw
<kenvandine> well, i switched back to the iso from 20190311
<kenvandine> which i am sure i tried yesterday
<kenvandine> my last few installs today was from the 20190309 iso
<willcooke> k, Im going to try a different ISO
<kenvandine> the forum post originally reported based on the 20190309 iso
 * willcooke wonders if he wrote the wrong ISO to his USB stick
<kenvandine> shouldn't matter
<kenvandine> it's definately busted in monday's iso
<kenvandine> i'm downloading today's now
<Chipaca> kenvandine: and what's in the logs?
<kenvandine> Chipaca: the journal is empty
<Chipaca> kenvandine: entirely? or just -u snapd?
<popey> valentind: there is a snap called review-tools which you can find in the snap store. install that and then "snap-review (your snap)"
<ewp> sorry i'm asking so many questions. is it possible to do something like this in the snapcraft file? ln -s /etc/ssl/certs $SNAP/etc/ssl/certs/
<popey> valentind: that will run the same snap review tool that the store runs
<popey> valentind: saves you time by running it locally before pushing to the store
<valentind> popey, Good to know.
<kenvandine> Chipaca: just -u snapd
<kenvandine> Chipaca: this must be related, but at the end of "snap tasks 1" it says waiting for restart
<kenvandine> maybe it's failing to restart the daemon?
<kenvandine> our friendly systemd :)
<Chipaca> kenvandine: is there anything snapd-related in the journal without -u snapd?
<pedronis> did you post tasks 1 somewhere?
<willcooke> I purged snapd on a broken system.  Reinstalled it, installed core, installed gnome-3-26-1604, installed gtk-common-themes, installed gnome-calculator
<willcooke> restarted my session
<willcooke> calculator works
<willcooke> so afaict, installing the snaps as per the seeds file works as expected
<Chipaca> willcooke: is there any way to set SNAPD_DEBUG in the cd such that it's already in debug at seed time?
<Chipaca> ewp: what're you trying to do?
<willcooke> Chipaca, I might be able to get in to the chroot and edit the service file before rebooting... lemme see
<Chipaca> willcooke: it loads /etc/environment if that's easier
<Chipaca> (you might see debug output from snap as well as from snapd, but eh)
<willcooke> kk
<kenvandine> Chipaca: journalctl |grep snap
<kenvandine> returns nothing but udev events
<kenvandine> nothing else
<Chipaca> sÃ±Ã­g
<willcooke> k, I edited /etc/environment, added those debug lines, nothing in the logs.  Checked env and they are set
<willcooke> grr
<mwhudson> let's just skip 19.04, everyone can cope with waiting for 19.10 right?
<mwhudson> willcooke: dmesg? maybe something is segfaulting
<willcooke> looks ok
<willcooke> I'll try editing the service file
<Chipaca> i'm EODing
<Chipaca> willcooke, kenvandine: forum or email with updates plz
<Chipaca> or telegram if you're desperate
<Chipaca> :-)
<Chipaca> ttfn
<willcooke> cheers Chipaca
<kenvandine> cheers Chipaca
<willcooke> I need to go soon too
<willcooke> Still no logs.  I need to admit defeat for today.  Will try again tomorrow
<willcooke> If anyone is interested in playing, it should be as easy as spinning up a new VM with todays disco ISO
<willcooke> night all
<mup> PR snapcraft#2501 closed: nodejs pluging: support for type str bin entries <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2501>
<zyga> Back!
<jdstrand> pedronis: hey, I've been trying for days to get PR 5644 to have a succesful test run, but haven't been able to. the weirdest is CLA check, which says: email: Invalid email &#x27;zyga@xenial-server&#x27;.
<jdstrand> ---
<jdstrand> The command "./tests/lib/cla_check.py" exited with 1.
<mup> PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
<jdstrand> pedronis: I made the changes, but you marked it as blocked, I guess cause the tests hadn't passed, but the failures seem unrelated...
 * jdstrand will keep mashing buttons I guess
<jdstrand> pedronis: fwiw, the CLA failure seemed to happen after a recent merge with master
<zyga> jdstrand: I know what that is
<zyga> You need to rewrite history to fix my email
<zyga> Sorry about that
<jdstrand> zyga: huh?
<sergiusens> jdstrand: the logic might be wonky, usually a rebase with master instead of a merge will fix it
#snappy 2019-03-14
<zyga> Good morning
<mborzecki> morning
<zyga> Hey mborzecki :-)
<mborzecki> zyga: hey
<mborzecki> zyga: simple review ? https://github.com/snapcore/snapd/pull/6596
<mup> PR #6596: spread: restore SELinux context when we mess with system files <SELinux> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6596>
<zyga> On it
<zyga> Done
<mborzecki> zyga: thanks
<zyga> Hello mvo
<mvo> hey zyga
<mborzecki> mvo: hey
<zyga> ãããã¾ã
<zyga> That was what you asked about last time
<mvo> hey mborzecki
<mvo> zyga: !!!
<mvo> zyga: amazing
<mvo> zyga: looking forward for you teaching me some more
<zyga> Iâll be around shortly
<mvo> hey sil2100 ! quick question - can we get https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd into core18 via your foundations ppa maybe? this way we can run our regression test (and full suite) with the fix just like we did with xenial
<pstolowski> morning
<mvo> hey pstolowski
<zyga> Hey Pawel
<mborzecki> mvo: https://www.viva64.com/en/b/0600/
<mborzecki> zyga: ^^
<mborzecki> pstolowski: hey
<mvo> mborzecki: looks good, we should try it
<zyga> Applied
<zyga> Thank you
<pedronis> mvo: couple of Q/comments on 6401  , I didn't notice but we are trying not to add anymore to api.go, see recent work by Chipaca and me
<mvo> pedronis: oh, ok. I have a look, I missed that. thank you
<Chipaca> mvo: i'd gladly pick that up if you're otherwise busy
 * Chipaca dreading the merge-the-health-checks work
<Chipaca> :-)
<mvo> Chipaca: yeah, that is welcome
<Chipaca> ok
<mvo> Chipaca: \o/
 * mvo tries to tame wait-chains right now
<pedronis> Chipaca: did you update the Reason: scheduled one?
<pedronis> and morning
<Chipaca> first i'll address pedronis's comment on #6598
<mup> PR #6598: overlord/snapstate, store: set a header when auto-refreshing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6598>
<Chipaca> pedronis: morning
<Chipaca> pedronis: i'd written up to # and went looking for the number :-)
<Chipaca> pedronis: it's just the flag -> opt thing, right?
<pedronis> Chipaca: there's a suggested if reorg as well
<Chipaca> pedronis: or do you want me to also do the cleanups of things that were already there?
<pedronis> Chipaca: ideally also the cleanups, yes
<Chipaca> (that'll make the diff bigger, meaning less chance convincing pedronis it's minimal and can go in 2.38 :-p)
<pedronis> Chipaca: you can do a follow up instead
<pedronis> but it would be good to address them
<Chipaca> pedronis: your call, I don't mind if this doesn't make 2.38 :-)
<pedronis> Chipaca: either maybe the if, but the rename should be rather innocuous
<pedronis> Chipaca: I mean, I don't think the diff will be that much bigger
<pedronis> the biggest addition are the tests in fact
<Chipaca> i wonder why we decided rate limit would be an int64 (and not a uint64)
<pedronis> Chipaca: no clue, I don't think I reviewed that code
<pedronis> Chipaca: it starts with ParseByteSize returning int64
<pedronis> (but that doesn't support -5b)
<pedronis> Chipaca: anyway that is a bigger change
<pedronis> not for this one
<pedronis> Chipaca: but yes, it makes one wonder if rateLimit can be -128
<Chipaca> totally
<Chipaca> I'll change things around a little, hopefully for the better, and push a change to make the rate thing not be negative separately
<Chipaca> ParseByteSize doesn't support negative numbers more by accident than by design i fear
<pedronis> Chipaca: do negative sizes make sense though?
<Chipaca> no
<Chipaca> I mean, they might be used in the kernel or something to indicate errors
<Chipaca> but for our use, no
<Chipaca> (and our use of ParseByteSize is purely about rate limiting)
 * dot-tobias waves hello
<Chipaca> pedronis: reqOptions() -> downloadReqOpts() ok with you?
<pedronis> Chipaca: yes, it is used in download and connectivity check, right?
<Chipaca> pedronis: yes, and in conn check it's used for the download endpoint
<pedronis> yup
<zyga> hey Chipaca :)
 * zyga is happy despite the rainy day
<Chipaca> zyga: morning sah :-)
<zyga> Chipaca: brexit makes my sleeping pattern erratic
<Chipaca> zyga: welcome to my world
<zyga> Chipaca: on the up side, the current state, as chaotic as it is, feels like an improvement over last few weeks
<zyga> Chipaca: at least from far away here, I don't know how it feels to be directly affected
<Chipaca> zyga: I'm refusing to get my hopes up, but my favourite outcome is still in the race
<mvo> Chipaca: I did an unrelated change (unrelated to the api layout we discussed) you may need to git pull for 6401
<Chipaca> mvo: will do
<pedronis> mvo: thank you for adding that check
<mvo> my pleasure
<Chipaca> pedronis, mvo, pushed to 6401
<Chipaca> maybe i should've pushed two commits
<mvo> Chipaca: thank you!
<Chipaca> instead of one with two changes
<Chipaca> hm
<Chipaca> pedronis: again not daemon_test package because apiBaseSuite is a beast
<pedronis> Chipaca: that's ok, we can look into that at some point
<pedronis> but at least the beasts are not growing
<Chipaca> y
<Chipaca> yes
<Chipaca> ogra: you around?
<mborzecki> #6596 is one unlucky PR
<mup> PR #6596: spread: restore SELinux context when we mess with system files <SELinux> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6596>
<mborzecki> the travis job just keeps on failing and failing, either github, or store timeout, or some from-repo package installation taking too long
<ogra> Chipaca, in a meeting, so half way ...
<ackk> hi, I'm trying to build a core18 snap with multipass, but it seems to just hang there after starting the vm. if I "multipass shell" in it, I don't see anything running. how can I debug this?
<mvo> pedronis: quick question (if you have a moment) - in doUpdate we merge a bunch of taskSets and the "edge" information (DownloadAndChecksDoneEdge) gets lot - one approach would be to transfer edges in ts.AddAll(anotherTs), I drafted this in http://paste.ubuntu.com/p/tDJf9XbTGg/ would love to hear your thoughts http://paste.ubuntu.com/p/tDJf9XbTGg/
<mvo> (ups, sorry for the same url twice)
<mborzecki> guys, so how about we land https://github.com/snapcore/snapd/pull/6270 ?
<mup> PR #6270: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6270>
<pedronis> mvo: Chipaca: I made a help suggestion in 6401
<pedronis> mvo: it's a bit problematic because some edges might not make sense in the larger task set
<mvo> pedronis: I can also just transfer the edge over in doUpdate explicitely
<mvo> pedronis: thats the simplest one
<mvo> pedronis: its slightly annoying that this area of code has to have knowledge about this though
<mvo> pedronis: or I can try to rework the way doUpdate is using []*TaskSet but that seems to be hard
<mvo> pedronis: anyway, would love some ideas :)
<pedronis> mvo: let me look at the code
<mborzecki> pedronis: updated #6593
<mup> PR #6593: sandbox/seccomp: a helper package wrapping calls to snap-seccomp <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6593>
<pedronis> mvo: I think it would be fine to have  separate AddAllWithEdges (my point is mostly tha whether to copy them over, rename them around etc needs to be conscious decision)
<mvo> pedronis: ok - with the same error handling as is in there already? i.e. error on dupes?
<pedronis> mvo: yes
<mvo> pedronis: great, thank you! I make this happen
<Chipaca> pedronis: a problem with that help message is that AIUI it breaks https://forum.snapcraft.io/t/convention-for-command-help-text/1856
<pedronis> Chipaca: fix it
<Chipaca> :-)
<Chipaca> pedronis: the docs, or the help message :-D
<pedronis> Chipaca: I mean the original was saying too little
<Chipaca> a'ight
<pedronis> we need something that respect the style guide
<pedronis> but also tells more
<pedronis> mborzecki: what's the difference between InternalToolPath and the helper? I'm obtuse
<mborzecki> pedronis: in that PR none, in the final one InternalToolPath won't work because it assumes it's either distro libexecdir or a path under snap-mount-dir
<mborzecki> pedronis: and in bootstrap the mount path is none of the 2 locations
<pedronis> mborzecki: does it mean InternalToolPath is broken?
<pedronis> I mean are we sure it doesn't it this issue in some cases
<mborzecki> pedronis: i wouldn't say it's broken, it's more like there is an assumption that snapd is installed in the system in some way, which is true in general, but not true during bootstrap
<Chipaca> huh, Nonce is missing or invalid
<ackk> does snapcraft keep any state other than the usual (parts/ stage/ prime/) dirs when run in --destructive-mode ?
<pedronis> mborzecki: are we failing generate key during bootstrap, I see similar code
<pedronis> there
<pedronis> mborzecki: findSnapdPath
<mborzecki> pedronis: that code is correct
<mborzecki> pedronis: it does not fall back to filepath.Join(dirs.DistroLibexecDir,...)
<mborzecki> pedronis: perhaps an update to InternalToolPath would make sense
<mborzecki> pedronis: after all if the tool is 'internal' it's supposed to be where snapd binary is
<pedronis> afaict it does fallback
<pedronis> maybe I'm reading it wrong
<pedronis> anyway I'm a bit worried about all this places doing slightly different with self/exe
<Chipaca> pedronis: I just split it :-)
 * Chipaca context-switches pedronis for fun & profit
<mborzecki> haha
<pedronis> mborzecki: if I read correctly we do a full seeding with snapd running from the tmp dir
<mborzecki> pedronis: yes
<pedronis> so any place is potentially buggy
<mborzecki> yup, fortunately it's only system key and seccomp at this point
<pedronis> well, no
<pedronis> there's a place using InternalToolPath
<pedronis> maybe it's buggy
<pedronis> or not
<dot-tobias> Can I somehow check how snapd reads my gadget.yaml by invoking some CLI command? I have a default configuration that has to be fed to the configure hook as a string, but it really is a YAML file thus should preserve line breaks.
<mborzecki> pedronis: haha :P
<Chipaca> dot-tobias: have you looked at what the online yaml parser makes of it?
<Chipaca> (was it you i showed that one to yesterday?)
<mborzecki> pedronis: i'd say that in the general case we should just do filepath.Dir(Readlink("/proc/self/exe")) and use that
<pedronis> mborzecki: interfaces/mount/ns.go
<mborzecki> pedronis: unless realdink fails, in which case fallback to distro libexecdir may be ok
<pedronis> mborzecki: the code is not like that though, in most of these places
<pedronis> they all check mount dir
<dot-tobias> Chipaca: Yes, I was the one from yesterday ð I checked and it preserves line breaks as \n, but feeding this to mir-kiosk (display-config can be set as a string) results in an erroneous miral-kiosk.display file with newline printed as literal \n
<Chipaca> dot-tobias: can you show me?
<mborzecki> pedronis: at least for the seccomp tool, I updated this here https://github.com/snapcore/snapd/pull/6485/files#diff-a5ed6485262fae2e80ad61a8b843504eR68
<Chipaca> dot-tobias: to answer your question directly, there isn't a way to do that right now
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<pedronis> mborzecki: I have a bit lost track of why the check
<dot-tobias> Chipaca: Sure, here's the current gadget.yaml: https://gitlab.com/glancr/gadget-snap-pi-kiosk/blob/master/gadget.yaml#L12
<pedronis> we probably need to talk with mvo
<mborzecki> pedronis: a chat then?
<pedronis> yes
<mborzecki> mvo: ^^
<mborzecki> pedronis: mvo: HO?
<mvo> mborzecki: in a meeting right now
<mborzecki> mvo: ok, once you're finished then?
<dot-tobias> Chipaca: If I run "snap set mir-kiosk display-config="$(cat a config file with the exact same contents)", everything works fine. But I suspect the multiline string from gadget.yaml is mangled somewhere.
<dot-tobias> Chipaca: I can't really check what the actual result is from the device intialization as snapd errors (mir-kiosk configure hook can't parse the mess it gets from the yaml default) and rolls back. I occasionally check on-device but I'm always either too early or too late to see the actual file created ð
<Chipaca> dot-tobias: which 'actual file created'?
<Chipaca> dot-tobias: (i'm not super familiar with this part of the code :) )
<dot-tobias> Chipaca: mir-kiosk's configure hook saves display-config to a file in $SNAP_DATA/miral_kiosk.display (cf. https://github.com/MirServer/mir-kiosk/blob/ad041e6b19205acacaf9881568061d8fd5a5742e/snap/hooks/configure#L29).
<Chipaca> right, but the first boot config isn't done from the file
<Chipaca> it's done from reading the snap.yaml
<Chipaca> dot-tobias: let me load and dump that yaml file and see what snapd makes of it
<dot-tobias> Chipaca: That would be great, thank you. Correct me if wrong, but I thought that the gadget setup was roughly this: boot > mir-kiosk snap is installed from prefetched .snap, including any default config > gadget.yaml is read for default settings > snapd basically runs âsnap set snap-name some-setting=specified-value-from-gadget.yaml â if that's the case, I don't quite follow your statement about first boot config
<Chipaca> dot-tobias: snapd does basically run snap set â¦
<Chipaca> dot-tobias: but the file comes after 'snap set', not before
<Chipaca> dot-tobias: so if the file has mangled \n's, it's because whatever called the equivalent of 'snap set' did it wrong
<Chipaca> dot-tobias: and the codepath is simple enough that it's _probably_ reading it wrong in the first place but idunno
<Chipaca> getting there
<Chipaca> dot-tobias: the problematic config is display-config, yes?
<dot-tobias> Chipaca: I guess we're talking about the same thing, but not sure ð
<dot-tobias> Chipaca: yes, display-config is the one I'm trying to set.
<Chipaca> the config is loaded jus' fine
<Chipaca> so the problem is in the setting of it
<Chipaca> hmm
<Chipaca> oh wait what is this normalize code
<dot-tobias> Chipaca: Yes, I suspect that the gadget.yaml multiline string is parsed somewhere and passed to âsnap setâ with literal \n newlines, which mir-kiosk's configure hook does not further parse or validate (just echoes the passed string to miral-kiosk.display) â thus resulting in one long string with literal \n instead of a valid YAML dict
<Chipaca> indeed
<dot-tobias> Chipaca: And that's the part where I don't know if âI'm holding it wrongâ or if preserving a config file with implicit newlines (dunno if that's the correct term) through this whole YAML parsing is currently just not possible. ð
<Chipaca> dot-tobias: so, there's a bug, this should work
<Chipaca> dot-tobias: we should fix it
<Chipaca> dot-tobias: but that doesn't unblock you
<Chipaca> dot-tobias: however, there's a way out for you
<Chipaca> i hope
<Chipaca> dot-tobias: but it's a bit nasty
<dot-tobias> Chipaca: I'm all for nasty workarounds if they do the job until the elegant way is possible ð
<Chipaca> dot-tobias: rewrite the config file yaml using the json-like syntax
<Chipaca> dot-tobias: gimme a sec i'll do it for you
<mup> PR snapd#6596 closed: spread: restore SELinux context when we mess with system files <SELinux> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6596>
<Chipaca> dot-tobias: layouts: {normal: {cards: [{card-id: 0, HDMI-A-1: null}]}, right: {cards: [{card-id: 0, HDMI-A-1: {orientation: right}}]}, left: {cards: [{card-id: 0, HDMI-A-1: {orientation: left}}]}, inverted: {cards: [{card-id: 0, HDMI-A-1: {orientation: inverted}}]}}
<Chipaca> dot-tobias: no comments in this format :-/
<Chipaca> pedronis: pstolowski: we have some issue with spurious escaping of config values coming from gadget.yaml
<dot-tobias> Chipaca: Can live without comments for now. Thank you very much! So I put that into gadget.yaml > defaults > display.config as a string?
<Chipaca> dot-tobias: yes
<Chipaca> dot-tobias: let me know if it actually works of course :-)
<Chipaca> pedronis: pstolowski: meaning the snaps get \\n instead of \n for ex
<dot-tobias> Chipaca: Will do, thank you!
<pedronis> Chipaca: escaping where?
<mborzecki> pedronis: mvo: can we land #6270?
<mup> PR #6270: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6270>
<Chipaca> pedronis: the Configure hook that's run using the values from the gadget.yaml
<pedronis> Chipaca: yes
<pedronis> Chipaca: where is the escaping,   snapctl get? or before?
<pedronis> or it's misunderstanding about what the result is
<Chipaca> pedronis: the loading seems to be fine, no spurious escaping
<Chipaca> pedronis: I don't know where it's happening, don't have an easy way to repro
<pedronis> we do need a repro
 * pedronis lunch
<Chipaca> pedronis: I mean, dot-tobias was hitting this IRL
<Chipaca> pedronis: I mean I don't have a _minimal_ way to reproduce it that doesn't involve a gadget and a device and first-booting it
<Chipaca> fortunately there's a workaround for them, as it's yaml so you can just scrunch it up (ewww), but if it'd been an .ini file we would've been SOL
<pedronis> Chipaca: we do have spread test like that
<pedronis> I mean we should be able to write a spread test
<Chipaca> I know :-) i'm saying I haven't -- I was trying to make it SEP
<pedronis> Chipaca: did we learn anything more about the 19.40 seeeding woes?
<pedronis> 19.04
 * pedronis really lunch
<Chipaca> pedronis: I'm trying to reproduce them locally
<Chipaca> s/them/it/
<Chipaca> them == the woes, clearly
<Chipaca> right now I'm struggling to get a new disco install to _boot_, let alone be snappy
<Chipaca> two different icons for installation, with arrows pointing different ways
<ogra> Chipaca, so what was that ping about ?
<Chipaca> ogra: who knows :-)
<ogra> heh
<mvo> hrm, hrm, whats up with tests
<mvo> ogra: while you are here - you probably like https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd
<mvo> ogra: we just need to convince someone from the sru team to actually approve :)
<ogra> YAY !!!
<mvo> mborzecki: you wanted to talk about something earlire? sorry was in a meeting and then forgot
<mborzecki> mvo: yes, we need pedronis too
<mvo> hey sil2100 ! quick question - can we get https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd into core18 via your foundations ppa maybe? this way we can run our regression test (and full suite) with the fix just like we did with xenia
<mvo> mborzecki: probably after lunch, what was the question?
<mvo> and why are tests unhappy currently :( ?
<mborzecki> mvo: some concerns about finding internal tools
<mvo> mborzecki: ok, so - for snapd its easy, just os.dirname(os.link("/proc/self/exe"))
<mvo> mborzecki: but for the "snap" binary its not
<mvo> mborzecki: I think we need to lookup something (snap-exec?) there
<mvo> mborzecki: maybe the answer is that the toolpath is also just relative for the snap binary "../lib/snapd"
<mvo> mborzecki: am I actually speaking about the right question or am I lost in something else :) ?
<mborzecki> mvo: ../lib{exec}/snapd
<mborzecki> mvo: right, we were discussing the case of 'snapd' and cmd.InternalToolPath which does not work for boostrap environment
<mvo> mborzecki: yeah, for snapd my suggestion is to always look into the same dir
<mvo> mborzecki: and maybe (to support running from a git tree) to fallback to /usr/lib{,exec}/snapd
<mvo> mborzecki: but for snap its slightly more complicated
<sil2100> mvo: hey! Let me take a look
<mup> PR snapd#6599 opened: snapstate,state: add TaskSet.AddAllWithEdges() and use in doUpdate <Created by mvo5> <https://github.com/snapcore/snapd/pull/6599>
<sil2100> mvo: hm, I can review it today for -proposed and then copy it over to the PPA for testing (with a lower version)
<mvo> sil2100: cool, let me know if I can help in any way (but I probably don't have the right permissions)
<mborzecki> mvo: i can try and open a PR cleaning up cmd.InternalToolPath/findSnapdPath/seccompToBpfPath to be consistent
<pedronis> Chipaca: do we understand enough from dot-tobias situation to make a LP bug?
<mvo> mborzecki: I think that would be good
<mvo> mborzecki: maybe a separate PR?
<Chipaca> pedronis: I think so yes
<mborzecki> mvo: right
<Chipaca> dot-tobias: could you do that? file an lp bug about this
<pedronis> Chipaca: could you make one?
<pedronis> or dot-tobias
<Chipaca> pedronis: trying to punt it :-)
<pedronis> mborzecki: yes, simplifiying would be good
<pedronis> mborzecki: mvo: do we compute  system key from snap ? or only from snapd?
<mborzecki> pedronis: only snapd apparently
<pedronis> ok
<pedronis> mborzecki: no, both, snap run uses SystemKeyMismatch
<pedronis> so findSnapdPath is abit more delicate
<pedronis> afaict
<mborzecki> pedronis: right, but only snapd build-id is used in the system key data
<pedronis> mborzecki: well and snap-seccomp output in your PRs? no?
<mborzecki> yes
 * pstolowski lunch
<sil2100> mvo: ok, bionic looks good, accepted for bionic-proposed
<seb128> Chipaca, where do you see those inconsistant arrows for installation?
<Chipaca> heh
<sil2100> I will copy it to the PPA but please please please shepherd the bionic-proposed systemd upload
<Chipaca> seb128: https://snapforum.s3.amazonaws.com/original/2X/6/6db33b0da7456be46210985f939a0e2040284e6b.jpg
<seb128> Chipaca, did you sort out your non booting image? maybe worth mentioning on #ubuntu-desktop
<seb128> if you need help figuring it out
<sil2100> mvo: systemd uploads trigger a lot of tests and a lot of failures and the uploader needs to make sure they pass and/or are identified as flaky
<Chipaca> seb128: it was booting, just not doing anything graphic
<jdstrand> pedronis: can you advise on what to do about https://travis-ci.org/snapcore/snapd/jobs/505983378?
<sil2100> Wouldn't want this upload to be stuck in bionic forever
<seb128> Chipaca, ah, thx
<Chipaca> seb128: -vga qxl fixed that
<seb128> Chipaca, ah, good
<Chipaca> seb128: https://forum.snapcraft.io/t/no-more-preinstalled-snap-on-ubuntu-19-04/10339/49?u=chipaca
<jdstrand> pedronis: hello btw :)
<Chipaca> (just writing random stuff there as i try to repro the issue at hand)
<jdstrand> pedronis: sergiusens said something about a rebase, but I thought that would confuse github
<pedronis> jdstrand: did you see my comment on why it's blocked?  (it was about the tests, I think we talked about it but I forgot to write the reason in the PR)
<seb128> Chipaca, ah, tb didn't charge the image from the email for some reason, I see it now, the 'other arrow' on the desktop is because it's a symlink, it's a bit unfortunate how it 'conflicts' with the icon own arrows placed in the same corner
 * jdstrand doesn't have 'zyga@xenial' anywhere in the tree
<Chipaca> seb128: if it didn't, then it'd have two opposite arrows :-)
<seb128> Chipaca, Ken didn't get the issue every time, might be racy, so I guess "how you reproduce' is by trying a new install again
<zyga> jdstrand: does git log do?
<zyga> jdstrand: it's the history
<Chipaca> seb128: yep
<jdstrand> pedronis: I thought you said it could go in so long as tests came later. you want the tests now?
<seb128> Chipaca, right :)
<pedronis> jdstrand: sorry, it was not about the tests
<pedronis> jdstrand: please read the comment in the PR
<jdstrand> zyga: 'does git log do'? can you rephrase?
<pedronis> and answer there
<zyga> jdstrand: run git log | grep zyga@xenial
<jdstrand> pedronis: "I agree though with niemeyer comments regarding the summaries, we probably want to change those before merging." I did that
<jdstrand> zyga: yes, I have that:
<jdstrand> Author: zyga <zyga@xenial-server>
<jdstrand>     Signed-off-by: zyga <zyga@xenial-server>
<zyga> the author needs to be changed
<Chipaca> every time I try gnome shell i miss the keyboard-friendliness of unity :-(
 * Chipaca hugs his 16.04 to his chest
<pedronis> jdstrand: this comment: https://github.com/snapcore/snapd/pull/5644#issuecomment-472723883
<mup> PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
<pedronis> from this morning
<jdstrand> zyga: uhh, everyone has to do this?
<zyga> jdstrand: perhaps I misunderstand but this is in an incoming PR?
<zyga> jdstrand: if so,  just that needs to change
<dot-tobias> Chipaca / pedronis : I'll open a LP bug (for snapd?) and try to describe the problem as detailed as possible; Chipaca feel free to make amends if I misunderstood the actual issue (but at least I can describe what the outcome is)
<pedronis> jdstrand: we can work on landing it on our side
<Chipaca> dot-tobias: thanks!
<pedronis> jdstrand: I'm still interested if what I described is a blocker or not
<jdstrand> pedronis: I answered in the PR. I don't consider it a blocker since at worst I will see things come into the queue and manually approve them/grant the snap decl while I'm working through all the grants
<jdstrand> pedronis: but if you do, then I can try to get to it. it's several hundred so it will take me a while
<pedronis> jdstrand: what I'm worried is if somebody installs with snapd beta one of the affected snaps before the declaration is changed
<jdstrand> zyga: it isn't a new PR, it is an ancient PR at this point that all of a sudden started failing that cause I did a git fetch/merge
<pedronis> will not the install fail?
<pedronis> well, not fail
<pedronis> but not work until it connects things manually
<pedronis> which is not expected
<jdstrand> yes, that would happen
<jdstrand> that is a fair point
 * jdstrand doesn't understand how all of a sudden 92a096278e040b452125260b00742ae6e62caf2c from October is now causing me problems
<ackk> Saviq, hi, how can I debug what snapcraft is doing inside a multipass vm?
<ackk> Saviq, I'm trying to figure out why a snapcraft build seems to hang after having launched the vm
<jdstrand> zyga: ^ why am I seeing this now and why doesn't master change it so that no one else will be affected?
<zyga> jdstrand: I don't understand, can you tell me where exactly are you seeing it?
<jdstrand> zyga: https://travis-ci.org/snapcore/snapd/jobs/505983378
<zyga> jdstrand: I see your ping now, sorry for the interrupt
<zyga> jdstrand: wow, no idea now
<jdstrand> perhaps tests/lib/cla_check.py should ignore that email if people don't want to rewrite history. how is this passing for anyone?
<zyga> no idea, it's odd
<jdstrand> pedronis: oh, this is all set for 2.39 anyway. that's right. I was thinking as soon as it was committed, I'd get started, do 50 a day or something
<jdstrand> Chipaca: hey, you seem to have written ./tests/lib/cla_check.py
<zyga> jdstrand: sorry I was not of much help
<jdstrand> Chipaca: after a recent fetch/merge with master for an existing PR, I started seeing https://travis-ci.org/snapcore/snapd/jobs/505983378
<zyga> jdstrand: perhaps do a test: rebase and open a new PR
<zyga> jdstrand: if that passes it's a data point
<Chipaca> jdstrand: huh
<jdstrand> Chipaca: the email address that is failing is from 92a096278e040b452125260b00742ae6e62caf2c october
<Chipaca> jdstrand: should be easy to fix
<Chipaca> jdstrand: somehow :-|
<Chipaca> jdstrand: I mean, should be easy to fix the script to catch that exception
<jdstrand> Chipaca: I mean, I can adjust the author with a git rebase, but is that the right thing to do? why aren't others seeing this? (granted, my pr started before october, so maybe the check was added after that and I'm only seeing this cause I'm the only one with commits that stretch that far back?)
<Chipaca> jdstrand: I don't know why it's trying to verify an email already on master though
<Chipaca> hmm
<Chipaca> oh
<zyga> this branch predates october
<zyga> is that the reason?
<Chipaca> jdstrand: there's been a change in travis.yaml that might be relevant
<Chipaca> or was that in snapcraft
<Chipaca> looks like it was just in snapcraft
<jdstrand> Chipaca: at this point I'm happen to be told what to do and I'll mash buttons like a monkey :)
<jdstrand> happy*
<Chipaca> jdstrand: http://paste.ubuntu.com/p/QdXzftpW3b/
<Chipaca> jdstrand: that might help
<jdstrand> pedronis: please advise since this is for 2.39 if I need to slog though all of them or can go at my own pace
 * Chipaca â lunch
<pedronis> jdstrand: I would recommend to start
<jdstrand> pedronis: well there is starting and there is slogging so the PR is unblocked. it sounds like you mean the latter
<sergiusens> jdstrand: we rebase all the time in snapcraft, github is really saavy, it even mentions you rebased in the  PR... the only drawback is when you amend new code from the PR (problem for the reviewer, not github), but stuff that is in master is usually fine
<jdstrand> Chipaca: that shange seems unrelated to my PR and should be in a separate PR. I don't know why that is fixing things or what side effects it may have so am uncomfortable proposing it
<jdstrand> sergiusens: when you say rebase, what are you saying, change the order so the merges happen before my stuff?
<jdstrand> sergiusens: or are you saying change the author
<jdstrand> ?
<sergiusens> git rebase origin/master (it will even remove the merge commit)
<pedronis> jdstrand: sorry, I would prefer not to buy a conscious regression, we already have our fair share of unconscious ones
<jdstrand> pedronis: well, since it is for 2.39, I don't need to drop everything, so I'll go at whatever pace works for me and that makes it commitable for 2.39
<sergiusens> jdstrand: here's an example of a rebase https://github.com/snapcore/snapcraft/pull/2479 (search for force-pushed)
<mup> PR snapcraft#2479: store: support registering to a specific store <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2479>
<pedronis> jdstrand: that sounds good
<pedronis> mborzecki: btw to be clear I don't thik that cleanup should block 6593 but is good to have a plan forward for that area
<mborzecki> off to pick up the kids
<jdstrand> sergiusens: that's fine, and I use rebase all the time. I was wondering what you were specifically suggesting since I have gotten several suggestions. I think I know what to try
<dot-tobias> Chipaca / pedronis: Filed https://bugs.launchpad.net/snapd/+bug/1820060 â let me know if it's clear enough
<mup> Bug #1820060: multiline strings in gadget.yaml defaults are mangled <snapd:New> <https://launchpad.net/bugs/1820060>
<ackk>  sergiusens, hi, I have a snapcraft build that's been stuck for ages at "Launched: <vm>", it seems nothing is happening in the VM itself, how can I debug that?
<mup> PR snapd#6600 opened: timings: add new helpers, Measurer interface and DurationThreshold <Created by stolowski> <https://github.com/snapcore/snapd/pull/6600>
<dot-tobias> Is there a command I can run to retry a failed change? My system init change (gadget snap) is failing and I want to retry so that I can inspect some files which are deleted as soon as it err's
<jdstrand> pedronis, Chipaca, zyga, sergiusens: ok, just a simple rebase was enough to put the PRs changes on top (and after the problematic commit) and make cla check happy
<zyga> woot :)
<Chipaca> zyga: just seen news that A50 is blocked
<Chipaca> zyga: thought you might like to hear that
<kenvandine> Chipaca: well... today's iso seems fixed!
<willcooke> Chipaca, using the great troubleshooting method of "maybe it will just fix itself" kenvandine and I have tested with today's ISO and everything is back to normal.
<kenvandine> no idea what the hell was up with the past few days
<willcooke> II'll keep testing and make sure it's reliable
<willcooke> Sorry for the wild goose chase
<kenvandine> i noticed the iso size is a little different
<Chipaca> kenvandine: willcooke: from the description it was a race, so i'd expect it to come back in the same way
<mvo> sil2100: thanks for accepting
<mvo> sil2100: I will watch out for it
<Chipaca> kenvandine: willcooke: I have been trying to reproduce it, and only saw it happen once in ~20 installs so far
<willcooke> using todays iso?
<Chipaca> kenvandine: willcooke: of course that was before i had debug logs so i leraned nothing :-(
<kenvandine> Chipaca: oh... so you have reproduced it?
<Chipaca> kenvandine: or something very much like it
<Chipaca> willcooke: yes
<willcooke> nod
<Chipaca> willcooke: it _might_ have been something different, but it looked the same :-)
<willcooke> :)
<Chipaca> this was before I got systematic about it, after which nothing
<willcooke> Heisenbug
<Chipaca> do we still have the iso that _did_ have the issue? maybe i should use that one
 * willcooke checks his trash
<kenvandine> so... can we increase the log verbosity in the devel images?
<Chipaca> kenvandine: yes, easily
<kenvandine> Chipaca: yes
<willcooke> I have it
<willcooke> the ISO that is
<kenvandine> it's still up on cdimage
<willcooke> oh, even better
<kenvandine> grab 20190313
<Chipaca> kenvandine: When installing, once it prompts you to restart, before clicking restart edit /target/etc/environment and add SNAPD_DEBUG=1
<Chipaca> kenvandine: that will give you debug logs in the install
<willcooke> I did that yesterday on the broken image and it didnt seem to work
<Chipaca> willcooke: disco seems to rotate journal a lot more aggressively
<Chipaca> willcooke: so you need to look in /var/log/syslog
<willcooke> ooooooooh
<willcooke> thanks
<kenvandine> Chipaca: i meant in the future, during the devel cycle we should just turn up the verbosity in the images
<Chipaca> (which is a pain btw)
<kenvandine> maybe up until RC or something
<Chipaca> kenvandine: i'd like that :-)
<kenvandine> just so when things like this happen we have a means to debug it
<Chipaca> <3
<kenvandine> ok, i've done 2 installs of today's image and both worked fine
<kenvandine> and booted the live session 3 times
<kenvandine> all good
<kenvandine> :/
<Chipaca> kenvandine: did you ever get this in the live session itself?
<kenvandine> yes
<Chipaca> nice
<Chipaca> (for negative values of nice)
<Chipaca> kenvandine: dropping "[Service]\nEnvironment=SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7\n" into /etc/systemd/system/snapd.service.d/debug.conf would do that fwiw
<mup> PR snapd#6601 opened: errortracker: fix panic in Report if db cannot be opened <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6601>
<zyga> joinign
<dot-tobias> Chipaca: re: Workaround for mir-kiosk config: While JSON-like syntax seems to make it through snapd, mir-kiosk's configure hook expects exactly two spaces (== yaml indentation) and fails otherwise: https://github.com/MirServer/mir-kiosk/blob/ad041e6b19205acacaf9881568061d8fd5a5742e/snap/hooks/configure#L62
<dot-tobias> Chipaca: So I'm running from one issue into the next ð Will now try if creating the whole file via clout-init happens at the right time (i.e. after the snap has been installed)
<Chipaca> dot-tobias: maybe that one can be fixed from mir-kiosk
<dot-tobias> Chipaca: I'll open a PR there once I figure out how to check for JSON-like syntax without breaking their (surely sensible) strict grep line in the YAML case. Thanks again so far!
<seb128> kenvandine, willcooke, I would strongly recommend against thinking around the line of 'oh, we did nothing, it's fixed in today's daily, let's move on', that's going to bite us back in release week
<kenvandine> seb128: i agree
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502,
<mup> snapd#6541, snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6597, snapd#6598, snapd#6599, snapd#6600, snapd#6601
<kenvandine> i'm trying to see what's different in the isos
<seb128> it doesn't matter, does it?
<seb128> if it's timing and something changed it's not going to tell us anything on fixing
<seb128> imho someone from the snappy team needs to do an install which has the issue and debug snapd
<seb128> anything else is a waste of effort
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502,
<mup> snapd#6541, snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6597, snapd#6598, snapd#6599, snapd#6600, snapd#6601
<kenvandine> seb128: you're probably right
<kenvandine> Chipaca: are you trying the 20190313 iso?
<Chipaca> kenvandine: y
<Chipaca> kenvandine: yes
<kenvandine> great
<diddledan> does the desktop team have a channel I can discuss desktop non-snap issues?
<mup> PR snapd#6270 closed: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6270>
<mborzecki> btw. if you want to see the tests break and get weird errors like "Settle is not converging" you need to build an image with yocto
<mup> PR pc-i386-gadget#8 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/8>
<mup> PR pc-i386-gadget#9 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/9>
<mup> PR snapd#6602 opened: [RFC] cmd, interfaces: replace local helpers with cmd.InternalToolPath() <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6602>
<Chipaca> kenvandine: willcooke: walk with me please
<Chipaca> kenvandine: willcooke: remember when I asked you if any of the seeded snaps were 'base: core18', and you assured me they weren't?
 * willcooke puts his shoes obn
<mup> PR pc-i386-gadget#8 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/8>
<mup> PR pc-i386-gadget#9 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/9>
<Chipaca> kenvandine: willcooke: this is true of today's image: snap info --verbose /var/lib/snapd/seed/snaps/*  shows no base: core18
<Chipaca> kenvandine: willcooke: this is, however, _not_ true of the 20190313 image
<Chipaca> kenvandine: willcooke: gnome-system-monitor and gnome-calculator in yesterday's image use core18
<Chipaca> so you need to seed core18 as well, or, well, not :-)
<mvo> 6401 needs a second review
<kenvandine> Chipaca: oh... but the revisions of those that were on the iso did not use core18
<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#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502, snapd#6541,
<mup> snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6597, snapd#6598, snapd#6599, snapd#6600, snapd#6601, snapd#6602
<kenvandine> i confirmed that, they were the old revision
<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#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502, snapd#6541,
<mup> snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6597, snapd#6598, snapd#6599, snapd#6600, snapd#6601, snapd#6602
<Chipaca> kenvandine: as I say, in yesterday's iso, the snaps in seed are base:core18
<Chipaca> kenvandine: 'snap info --verbose' on the file says as much
<pedronis> some of them at least
<Chipaca> two of 'em
<pedronis> yup
<Chipaca> gnome-calculator and gnome-system-monitor
<kenvandine> Chipaca: what revision of gnome-calculator was it?
<Chipaca> kenvandine: the file says 335
<kenvandine> that was core18
<kenvandine> sigh...
<pedronis> 335
<kenvandine> i was checking those revisions... but that might have been when i was using the iso from 20190309
<kenvandine> which was the iso the original reported used
<kenvandine> but... i could never reproduce this problem on that iso
<kenvandine> :/
<mup> PR snapd#6603 opened:  snapstate: add new NoReRefresh flag and use in Remodel() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6603>
<Chipaca> kenvandine: I'll comment on the forum, see if it's just been that they downloaded a different one or something
<Chipaca> kenvandine: does an iso 'know' when it was made, anywhere?
<kenvandine> i think that original report for 20190309 had some other issue...
<kenvandine> and started misleading us
<kenvandine> probably
<Chipaca> kenvandine: perhaps, although by comment #3 it looks a lot like this one
<Chipaca> kenvandine: I'm going to explain what we know so far, and see if that explains the whole thing
<kenvandine> Chipaca: we are going to be publishing the seeded snaps based on core18 to stable in the next couple days :)
<kenvandine> so we'll need to update the seed
<pedronis> kenvandine: have you tested the upgrade from old base to new base, somebody reported issues with that (changing the base of a snap over refresh), zyga can tell more
<kenvandine> i actually just tested that on xenial
 * cachio lunch
<kenvandine> refreshed from stable to candidate
<kenvandine> candidate now has base: core18
<kenvandine> worked fine
<Chipaca> kenvandine: did you have core18 before refreshing
<zyga> kenvandine: there's a bug where changing bases runs the new revision on the old base
<kenvandine> i probably did have the old base
<kenvandine> but i can test right now
<kenvandine> Chipaca zyga: started out with no core18, refreshed candidate which did pull down core18
<kenvandine> still installing :)
<kenvandine> Chipaca zyga: works fine!
<kenvandine> on disco, installed from today's iso
<Chipaca> GREAT SUCCESS
<kenvandine> :)
<Chipaca> pedronis: mvo: should I squash-merge #6598 then?
<mup> PR #6598: overlord/snapstate, store: set a header when auto-refreshing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6598>
<mvo> Chipaca: last I looked it was two commits, I can cherry pick two :)
<mvo> Chipaca: so either way is fine
<Chipaca> just regular merge, then
<Chipaca> :-)
<mup> PR snapd#6598 closed: overlord/snapstate, store: set a header when auto-refreshing <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6598>
<mvo> 6401 needs a second review
<Chipaca> jdstrand: when you have a sec, could you tell me if I did something wrong wrt icdiff such that I can't install the version from candidate?
<Chipaca> mvo: would it be very cheeky if I reviewed that myself?
<mvo> Chipaca: its fine, I can review your bits
<Chipaca> mvo: ok, i +1'ed your bits :-p
<mvo> Chipaca: thank you!
<mvo> Chipaca: I did the same
<Chipaca> mvo: also i restarted spread because it hates you
 * mvo nods
<mvo> I wonder if I need to merge master
<mvo> or if it just hates me regardless
<pedronis> mvo: Chipaca: seems we have forgotten about ForSnapSetup  (noticed when looking at the NoReRefresh PR)
<Chipaca> pedronis: ?
<Chipaca> pedronis: in what sense?
<mvo> what is ForSnapSetup?
<pedronis> Chipaca: we have added flags that are not used in handlers, and we are not clearing them
<pedronis> in it
<Chipaca> mvo: a method on flags that drops things in flags that are for snapstate and not snapsetup
<Chipaca> pedronis: ah, in that sense
<Chipaca> pedronis: maybe we should turn it around
<Chipaca> pedronis: less likely to forget to add things to it that are needed
<pedronis> Chipaca: maybe
<pedronis> Chipaca: mvo: anyway afaict only Amend has this problem
<pedronis> but the new flag would as well
<pedronis> (not deep consequences just a bit more unused data in the state)
 * mvo nods
<pstolowski> mvo, cachio can https://github.com/snapcore/snapd/pull/6553 land?
<mup> PR #6553: tests: enable opensuse tumbleweed back <Created by stolowski> <https://github.com/snapcore/snapd/pull/6553>
<cachio> pstolowski, checking
<cachio> pstolowski, done
<cachio> pstolowski, thanks!!
<mup> PR snapd#6553 closed: tests: enable opensuse tumbleweed back <Created by stolowski> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6553>
<cachio> mvo, ./run-checks --static
<jdstrand> pedronis: there is something not right with icdiff. I thought I got the declaration right: https://paste.ubuntu.com/p/sBYQd2PWCB/ based on your comment in https://bugs.launchpad.net/snapstore/+bug/1814592/comments/6
<mup> Bug #1814592: cannot compile personal-files/system-files snap declaration constraints <Snap Store:Invalid> <https://launchpad.net/bugs/1814592>
<pedronis> jdstrand: no, you really need to squash them into one regexp with |
<pedronis> jdstrand: otherwise one of the two entries will fail
<pedronis> for one of the side of your ORed plug-attributes
<pedronis> jdstrand: I said as much:  For the multiple entries in read/write so you need to use a regexp with | and quoting/() as needed
<jdstrand> pedronis: well, that is what I thought until I read your "For the multiple entries in read/write so you need to use a regexp with | and quoting/() as needed." comment
<jdstrand> what did you mean by multiple entries there?
<jdstrand> for say, different snap ids?
<pedronis> jdstrand: the multiple entries in the attribute in the snap.yam plug
<pedronis> the rule matches for a list if each entry in the list matches the regexp
<pedronis> for a list in the attribute in the plug/slot
<jdstrand> you mean that read and write need the | cause they are different
<pedronis> jdstrand: there's no write here?
<jdstrand> no
<jdstrand> but I'm trying to parse "the multiple entries in the attribute in the snap.yam plug"
<pedronis> I mean you need  "read": "\\$HOME/\\.gitconfig|\\$HOME/\\.config/git/config" in the rule
<jdstrand> I get the bit about all the entries in the list need to match the regex
<jdstrand> pedronis: sure, I get that. I need to fix that
<pedronis> jdstrand: ok
<jdstrand> pedronis: but I want to understand when I am supposed to use |
<jdstrand> oh duh
<jdstrand> I got a wire crossed. this whole time I was interpreting '|' as a shorthand for alternate constraints. jeez
<pedronis> np
<jdstrand> you meant in the regex of course
<pedronis> yes
 * jdstrand shakes head
<pedronis> and the entries refered to the entries in the list value of the plug attribute
<pedronis> not rule side entries
<jdstrand> yes
<cachio> mvo
<jdstrand> Chipaca: ok, it installs and it should continue to pass automated review
<jdstrand> pedronis: thank you again. I need to make a small tweak for the alternate constraints bit in the review-tools cause of my misinterpretation of the LP comment, but that's fine
 * jdstrand continues to shake head
<jdstrand> it shouldn't be this hard :)
<Chipaca> jdstrand: huh, it installs here too, now
<Chipaca> i wonder what i'd broken before
<Chipaca> jdstrand: anyway i'm blaming you for it working: thanks!
<sil2100> mvo: hey! So apparently I don't have the permissions to push to the snapcore/pi-gadget branch still
<sil2100> mvo: can you add foundations to it?
<sil2100> mvo: since I'm in the middle of changing the branch ownership back from CanonicalLtd to snapcore
<mvo> sil2100: let me try
<mvo> sil2100: I think I added you now, please check
<jdstrand> Chipaca: what broke was it had the wrond snap decl (see conversation with pedro nis ^)
 * Chipaca reads up
<jdstrand> Chipaca: well, you should blame me for it not working and then fixing it with pedro nis help
<Chipaca> jdstrand: tomahto/tomeito
<Chipaca> it works now \o/
<Chipaca> now i need to figure out why it doesn't build on ppc64el
<Chipaca> :-P
<jdstrand> Chipaca: heh, well, it is hard for me to accept the gratitue since this is like the 3rd time I got this bit wrong. 4th times the charm?
<jdstrand> pedronis may have a higher tally. we will be there today, finally! :)
<sil2100> mvo: yay, works! Thanks! Did you add the foundations group (or whatever that is) or just me?
<sil2100> Since I guess the more the merrier :)
<sil2100> mvo: hm, I still don't seem to have full github powers on the branch like on the others
<sil2100> (like settings etc.)
<mvo> sil2100: the foundations group
<mvo> sil2100: aha, let me see
<sil2100> (git push worked though)
<mvo> sil2100: try now
<mvo> sil2100: this failure on trusty is mysterious, even the LP generated debdiff shows no packaging changes
<sil2100> mvo: works now, thanks!
<sil2100> hmmm
<sil2100> mvo: let me take a look at trusty as well
 * sil2100 checks his trusty schroot
<sil2100> oh, components mismatch maybe? However, this built fine before
<sil2100> mvo: so golang-1.6 is in universe while snapd is in main, but the previous version didn't have a problem with that
<Chipaca> sil2100: snapd uses -1.10
<mvo> Chipaca: that 2.38
<Chipaca> ah
<Chipaca> oh
<Chipaca> uh
<Chipaca> eh
<mvo> Chipaca: in 2.37.4 we should still be fine .)
<mvo> sil2100: yeah, what can we do? demote snapd to universe?
<mup> PR pc-amd64-gadget#12 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <Merged by sil2100> <https://github.com/snapcore/pc-amd64-gadget/pull/12>
<mup> PR pc-amd64-gadget#13 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <Merged by sil2100> <https://github.com/snapcore/pc-amd64-gadget/pull/13>
<mvo> sil2100: I need to run for lunch
 * zyga waves from school meeting
<mup> PR pc-i386-gadget#8 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <Merged by sil2100> <https://github.com/snapcore/pc-i386-gadget/pull/8>
<mup> PR pc-i386-gadget#9 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <Merged by sil2100> <https://github.com/snapcore/pc-i386-gadget/pull/9>
<sil2100> mvo: can we actually demote snapd to universe?
<sil2100> mvo: anyway, first I'd like someone else confirm that's the problem, let me poke someone
<sil2100> vorlon: maybe you have an idea? Is this the problem? ^
<sil2100> vorlon: context: snapd in trusty doesn't build at all, dep-waits on packages even though no new dependencies have been added
<sil2100> vorlon: I was suspecting a component-mismatch here as golang-1.6 is in universe in trusty, but it was building fine in the past
 * sil2100 AFK for a bit
<Chipaca> pedronis: I marked #1819427 as invalid, and also marked the forum topic as solved
<mup> Bug #1819427: Disco daily install doens't include the snaps <ubiquity (Ubuntu):Invalid by chipaca> <ubiquity (Ubuntu Disco):Invalid by chipaca> <https://launchpad.net/bugs/1819427>
<pedronis> thx
<vorlon> sil2100: demote snapd to universe> ... no?
<cachio> niemeyer, hey, I have created a small PR on spread https://github.com/snapcore/spread/pull/74 to enable travis
<mup> PR spread#74: Add .travis.yaml file <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/74>
<cachio> it is the initial step
<cachio> niemeyer, could you please take a look
<cachio> ?
<niemeyer> cachio: That doesn't look very useful :)
<cachio> niemeyer, I know, it is just to have a .tavis.yaml file
<niemeyer> cachio: Right, that's what I'm talking about
<cachio> I already have a set of changes to run the tests
<kenvandine> zyga: i'm having a layouts problem
<cachio> niemeyer, but I need to start running the builds on travis
<niemeyer> cachio: Sorry, I really don't get it
<kenvandine> zyga: specifically refreshing from a snap without the layout to  a snap using layouts
<kenvandine> https://paste.ubuntu.com/p/fVp6Tjd5vb/
<niemeyer> cachio: Running "echo" on Travis is not very useful
<niemeyer> cachio: What am I missing?
<kenvandine> zyga: it seems to only happen if i run the non-layouts revision first
<cachio> niemeyer, I need a way to see in github the execution of the change
<cachio> niemeyer, currently it is not running nothing
<niemeyer> cachio: I consider not running nothing a good thing
<cachio> niemeyer, I already created a change #73 on spread and it didnt trigger the tests
<mup> PR #73: fix a bug in lightweights that set the wrong type for frameworks found by AllPartBags that were lexicographically greater than the oem part <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/73>
<cachio> niemeyer, https://github.com/snapcore/spread/pull/73/files
<mup> PR spread#73: Run tests on travis <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/73>
<cachio> niemeyer, how should I do to start running on travis?
<cachio> do you need to configure that?
<niemeyer> cachio: Michael's point in that PR is that your change is huge
<cachio> or I could add the unit tests execution as part of the change https://github.com/snapcore/spread/pull/74 if you think it is good idea
<mup> PR spread#74: Add .travis.yaml file <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/74>
<niemeyer> cachio: We don't want to review that
<niemeyer> cachio: Instead, the PR should introduce testing with less boilerplate
<niemeyer> cachio: We already have tests in spread
<niemeyer> cachio: Running those in Travis would be nice, and hopefully not as complex
<niemeyer> cachio: What's the minimum we can do for that?
<cachio> niemeyer, ok, I can make a PR to run unit tests
<cachio> then another to run spread tests
<niemeyer> cachio: We already have tests in there
<niemeyer> cachio: And they are not unittests
<niemeyer> cachio: They are functional tests
<kenvandine> zyga: i've reproduced that with both stable and edge channels of the core snap
<cachio> niemeyer, I know, in that case the PR should include to run the spread tests
<cachio> niemeyer, just that
<cachio> niemeyer, does it make sense?
<niemeyer> cachio: Yeah, even just one of those would be enough of a PR
<cachio> niemeyer, great
<cachio> I'll make that
<niemeyer> Thanks!
<cachio> yaw
<cachio> niemeyer, we are going to need a new key to run the tests on google for the travis spread project
<niemeyer> cachio: That's okay.. perhaps first get it working for you, which should work with your key, and once that's happy we can setup something more permanent
<cachio> niemeyer, I already have that working
<cachio> because I did it as part of the PR 73
<mup> PR #73: fix a bug in lightweights that set the wrong type for frameworks found by AllPartBags that were lexicographically greater than the oem part <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/73>
<cachio> I need just to get that part and create a new PR
<niemeyer> cachio: Okay, so submit that alone so we can integrate first, and then submit the PR that enables that to run on Travis
<niemeyer> cachio: and by "that alone" I mean just the changes necessary to make spread tests run on GCE
<niemeyer> cachio: So anyone can fire those in their own environment
<cachio> niemeyer, great, thanks
<cachio> sure
<mup> PR snapcraft#2479 closed: store: support registering to a specific store <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2479>
<zyga> kenvandine: reproduced which issue sir? The one about base snap?
<kenvandine> no
<kenvandine> the layouts issue
<kenvandine> zyga: https://paste.ubuntu.com/p/fVp6Tjd5vb/
<kenvandine> gnome-characters in stable doesn't use layouts and in candidate it does
<kenvandine> if i run gnome-characters from stable once
<zyga> Let me look
<kenvandine> then refresh candidate
<kenvandine> it blows up on refresh
<kenvandine> but it doesn't blow up if i never run it
<zyga> Ahhh
<zyga> Can you report that please
<kenvandine> all the steps to reproduce it is in the pastebin :)
<kenvandine> sure
<zyga> And assign it to me
<zyga> I will otherwise not track it very well
<zyga> Thank you
<zyga> I think I know why
<kenvandine> zyga: what's your LP id?
<kenvandine> LP search is failing me :)
<roadmr> kenvandine: https://launchpad.net/~zyga ?
<cachio> niemeyer, PR ready https://github.com/snapcore/spread/pull/75
<mup> PR spread#75: Make spread tests run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75>
<kenvandine> No items matched "zyga".
<kenvandine> but you are right
<kenvandine> i can't assign a bug to that though
<kenvandine> zyga: bug 1820109
<mup> Bug #1820109: refresh fails with layouts <snapd:New> <https://launchpad.net/bugs/1820109>
<kenvandine> zyga: it won't let me assign it to you
<roadmr> hn the snapd project must have funky bug assignment policies
<kenvandine> yeah
<kenvandine> zyga: i'd mark it as critical if i was allowed... we need to update all the seeded snaps to core18 based so we can seed the new content package at the same time we unseed the old one
<kenvandine> so this is going to block that :/
<roadmr> kenvandine: apparently it only allows assigning bugs to teams, not specific people
<kenvandine> i see other bugs assigned to individuals though
<roadmr> kenvandine: it won't let me select individuals (even me), but see at the top of the assignment window, it says "select a team of which you're a member" or somesuch
<kenvandine> yeah
<kenvandine> saw that
<kenvandine> so i can't even assign it to the snappy team :/
<roadmr> :(
<mup> PR snapd#6401 closed: many: add /v2/model API, `snap remodel` CLI and spread test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6401>
<pedronis> kenvandine: I assigned, I don't know if it has a quick/non risky fix, we'll need to see what zyga says
<mup> PR snapcraft#2502 opened: meta: fix management of snap/local <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2502>
<ogra> hmm, ouch ... core18 misses snapfuse ... so you cant run lxd on top of Ubuntu Core 18 images
<ogra> (well, you can, but not install snaps in the container)
<ogra> stgraber, pedronis ^^^ is that known ?
<jdstrand> roadmr: hi! can you add a pull of r1208 to your queue?
<jdstrand> roadmr: it isn't urgent
<roadmr> jdstrand: pullity pull coming right up
<jdstrand> thank you :)
<roadmr> jdstrand: yep, I don't think we can deploy that before next week but it'll get queued
<jdstrand> pedronis: fyi, that ^ has the small fix I referred to
<Saviq> ackk: hey, sorry for the very late reply... I saw your ping but missed which channel it was on...
<Saviq> ackk: that would be https://github.com/CanonicalLtd/multipass/issues/678 - it's fixed now in our master, but we've another issue we're fighting with on edge (https://github.com/CanonicalLtd/multipass/issues/677) so it's best to stick with --beta for a bit
<stgraber> go get github.com/snapcore/snapd/i18n/xgettext-go: unzip /lxc-ci/build/tmp.GQSoN0Ki3g/go/pkg/mod/cache/download/github.com/snapcore/snapd/@v/v0.0.0-20190314200526-9cca2d5a116a.zip: malformed file path "cmd/snap-confine/spread-tests/distros/debian.": trailing dot in path element
<stgraber> ^ that's go tip failing to "go get" the snapd repo due to something funky going on with unzip
#snappy 2019-03-15
<kenvandine> pedronis: thanks
<mup> PR snapd#6604 opened: tests: tests add check to detect a broken snap on reset <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6604>
<zyga> Good morning
<zyga> stgraber: ouch, thanks for sharing!
<mborzecki> morning
<zyga> Hey hey
<zyga> More rain today
<zyga> Iâll be home soon, just finishing morning walk
<zyga> back in the office now
<zyga> mborzecki: hey, what is https://github.com/snapcore/snapd/pull/6329 blocked on?
<mup> PR #6329: cmd/snap-confine, packaging: support SELinux <SELinux> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6329>
<zyga> or blocked by
<mborzecki> ah, it's not now
<mborzecki> zyga: forgot to take the label off
<zyga> :-)
<zyga> la-la-land-it
<mborzecki> oh, and it's green too
<zyga> quick, before it turns sour ;)
<mborzecki> haha
<mborzecki> pedronis: do you want to take a look at #6329? it's snap-confine
<mup> PR #6329: cmd/snap-confine, packaging: support SELinux <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6329>
<zyga> https://github.com/snapcore/snapd/pull/6601 is a low hanging fruit
<mup> PR #6601: errortracker: fix panic in Report if db cannot be opened <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6601>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6601 is green and +2 :)
<mup> PR #6601: errortracker: fix panic in Report if db cannot be opened <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6601>
 * zyga breakfast
<mborzecki> wow, emacs crashed
<zyga> too many open tabs?
<mborzecki> zyga: backtrace leads back to imagemagick
<zyga> I...
<zyga> well
<mborzecki> must have been that treemacs thing i tried
<zyga> unusual but what can I say
<mborzecki> hmm https://paste.ubuntu.com/p/h7MtPn3cYr/
<pedronis> mborzecki: do we need jdstrand reviews for 6485 and 6592, I thought he +1 the original long branch? did things change a lot from it?
<pedronis> sorry
<pedronis> mborzecki: 6592 and 6593
<pedronis> we can still ask him to (re)review the final bit
<mborzecki> pedronis: only significant change in 6592 is the test to check whether we accounted for all syscalls known to seccomp
<mborzecki> 6593 has a little api tweak, but that's all
<pedronis> mborzecki: yea, I think if they have two review they can land without jdstrand
<mborzecki> pedronis: ack
<mup> PR snapd#6593 closed: sandbox/seccomp: a helper package wrapping calls to snap-seccomp <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6593>
<mup> Bug #1819629 changed: no default locale in core18 causes pam errors <snap-core18:Fix Released by sil2100> <Snappy:Fix Released by sil2100> <https://launchpad.net/bugs/1819629>
<mup> PR snapd#6601 closed: errortracker: fix panic in Report if db cannot be opened <Simple ð> <â  Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6601>
<mvo> sil2100: hey, hope I don't get on your nerves already - if you could upload the bionic version of systemd from -proposed to ppa:canonical-foundations/ubuntu-image that would be awesome, then I can trigger a core18 build and add UC18 to the regression test for the systemctl hang
<mvo> sil2100: (I would love to do that myself and safe you trouble but I don't have the right permissions)
<zyga> hello mvo :)
<pedronis> mvo: hello
<pedronis> mvo: sil2100:  ogra last night was reporting that snapfuse is not available with core18
<mvo> zyga: good morning!
<mvo> pedronis: hm,hm, thats a tricky one, it comes from the snapd binary and is in /usr/bin/snapfuse, we should probably move it to /usr/lib/snapd/snapfuse and make /usr/bin/snapfuse a symlink
<pstolowski> mornings!
<mvo> hey pstolowski
<mvo> sil2100: I'm looking at the xenial systemd ADT issues right now and I see enough failure to think we should pull the update for now :(
<mvo> sil2100: at least the xenial version, looking at bionic next
<sil2100> mvo: I thought I copied systemd to ubuntu-image yesterday
 * sil2100 looks
<sil2100> mvo: yeah, systemd is there since yesterday systemd 237-3ubuntu10.16
<sil2100> (binary copy, identical to the one in -proposed)
<mvo> sil2100: oh, maybe I looked at the wrong thing, sorry
<mvo> sil2100: we need to pull the xenial verison :( I just asked in #ubuntu-release
 * zyga just updated to .4 via SRU
<zyga> thanks everyone!
<zyga> mvo: what's wrong with the systemd update?
<mvo> sil2100: and one last question (promised!) - did steve had any idea why trusty snapd was in dep-wait state?
<sil2100> mvo: no, I guess we'll have to dig into that today again, he just said demoting snapd to universe is not an option, but in the end he didn't say if our predictions about the reason for the failure are correct
<sil2100> mvo: btw. so hmmm, even without us copying systemd to ubuntu-image I guess should have the new systemd?
<sil2100> mvo: I mean, aren't we getting systemd from ubuntu-base?
<mvo> zyga: some failures like this http://autopkgtest.ubuntu.com/packages/p/python-systemd/xenial/i386
<mvo> sil2100: we get it from ubuntu-base - is that building from -proposed?
<sil2100> mvo: yes, which now actually scares me a bit
<mvo> zyga: https://paste.ubuntu.com/p/8hF3mPxKTR/
<mvo> sil2100: uhhhh
<mvo> sil2100: yes, me too
<sil2100> mvo: since it means in the core18 snap we're actually using packages from -proposed everytime ;/
<mvo> sil2100: I was not aware of this
<mvo> sil2100: yeah, also people who build other things on ubuntu-core may not be aware of this
<mvo> sil2100: is this a conscious decision and if so, whats the reasoning behing it?
<sil2100> mvo: yeah, so by default in Ubuntu when a stable lts series is released but still gets its daily-builds, they're by default built using -proposed to ease testing of proposed packages IIRC
<sil2100> Anyway, this needs to be fixed
<sil2100> Somehow
<sil2100> Either by revisiting this policy or by building ubuntu-base without -proposed somewhere for our purposes
 * sil2100 gets the shivers now
<mvo> sil2100: thank you!
 * zyga hugs mvo
<zyga> thank you for being on the front line of systemd issues
<mborzecki> tests unhappy again or something really broke? Remove data for snap "test-snapd-tools" (x1) (failed to remove snap "test-snapd-tools" base directory: remove /var/snap/test-snapd-tools: directory not empty)
<pedronis> mborzecki: there was a change in that area:  273d4853d
<zyga> mborzecki: it sounds like a known issue
<zyga> mborzecki: chipaca and I discussed it about two weeks ago
<zyga> mborzecki: rm -rf vs rmdir
<Chipaca> so, turns out that having a snap confuse snapd with the assertions in a refresh is pretty bad
<Chipaca> i now have a broken snap i can't remove :-|
 * Chipaca encourages snapd to remove it
 * pstolowski runs a quick errand
<ogra> sil2100, the enw gadget is fine ... the user with the issue also confirmed he sees the missing interfaces now
<sil2100> ogra: \o/
<ogra> s/enw/new/ ... (tsk ... *glares at his fingers* )
<sil2100> ogra: hm, crap, forgot to ask CE for validation, anyway, I'll make it move forward today
<ogra> i guess the user is fine using edge for the moment, so i doubt there is any pressure
<mup> PR snapd#6592 closed: cmd/snap-seccomp: version-info subcommand <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6592>
<ogra> mvo, as a reminder ... https://bugs.launchpad.net/snapd/+bug/1820242
<mup> Bug #1820242: snapfuse missing in core18 breaks snap installation in lxd containers <snapd:New> <https://launchpad.net/bugs/1820242>
<pstolowski> re
<mup> PR snapd#6605 opened: cmd/libsnap,osutil: fix parsing of mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/6605>
<zyga> brb, coffee
 * zyga really goes to grab that coffee now
<cachio> niemeyer, hey, I yesterday pushed this one 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>
<mborzecki> i've updated #6485, anyone who was involved in the review, please take a look
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<niemeyer> cachio: Reviewed
<cachio> niemeyer, thanks
<Saviq> oSoMoN: hey, I've been trying to update the subsurface snap for new snapcraft (no remote bases) https://github.com/Subsurface-divelog/subsurface/compare/master...Saviq:update-snap-packaging - but the launcher doesn't seem to be setting the QML env... you seem to be somewhat active in that repo ;), any idea?
<Saviq> `$ snap run --shell subsurface -c '$SNAP/bin/desktop-launch env' | grep QML` turns up empty
<Saviq> ah I think I see the problem
<mup> PR snapd#6606 opened: selinux, systemd: support mount contexts for snap images <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6606>
<mborzecki> another selinux piece ^
<mup> PR snapd#6607 opened: cmd: typedef mountinfo structures <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6607>
 * zyga has a *wild* idea
<zyga> **wild**
<jdstrand> mborzecki: I know you're working on selinux support in snapd. I'm not sure of your grand plans but note there are *many* limitations to ultimately have an selinux backend that is equivalent to apparmor and it really isn't feasible. lsm stacking is the answer for strict snaps on selinux systems
<jdstrand> mborzecki: that's been discussed elsewhere and a long time ago and not sure you were aware
<jdstrand> that isn't to say it is impossible. but there would be a high up front and persistent maintenance cost
<jdstrand> with stacking, that's all avoided (again, I'm talking about strict mode snaps, not targetted policy for snapd to run them (which, aiui, is what you're working on and good))
 * jdstrand might be optimistic on 'not impossible'. there would need to be a lot of investigation
<cachio> mvo, pedronis hey, do you know is anyone is looking at the error: task.go:337: DEBUG: 2019-03-15T10:29:19Z ERROR failed to remove snap "test-snapd-tools" base directory: remove /var/snap/test-snapd-tools: directory not empty?
<pedronis> Chipaca: hi, zyga said you were looking into that area at some point ^
<pedronis> also it's close to were you landed something recently
<Chipaca> yes, i landed a fix for a cleanup that wasn't happening that would cause that
<Chipaca> cachio: you'll have some random revision in /var/snap/test-snapd-tools, rm -r that revision, try the remove again, should work
<cachio> Chipaca, it is failing on the master
<cachio> on the travis executions
<Chipaca> every time?
<cachio> I saw many testa failing because of that
<Chipaca> hmm
<Chipaca> dunno then
<cachio> Chipaca, https://api.travis-ci.org/v3/job/506691205/log.txt
<Chipaca> more cleanup needed?
<Chipaca> whoa
<Chipaca> cachio: could the tar be wrong in some way?
<Chipaca> anyway, I'll look
<cachio> Chipaca, , not sure, It didnt change
<cachio> I though it was related to the clean up changes
<cachio> Chipaca, thanks
<Chipaca> cachio: the cleanup changes should've made it not happen, not happen more :-)
<cachio> Chipaca, :)
<oSoMoN> Saviq, problem solved, then? (just back from lunch and seeing your messages)
<Saviq> oSoMoN: yeah, would be solved even more if https://github.com/ubuntu/snapcraft-desktop-helpers/pull/177 was merged ;) can you review in helpers?
<mup> PR ubuntu/snapcraft-desktop-helpers#177: [qt] fix prepend_dir usage <Created by Saviq> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/177>
<oSoMoN> looking
<oSoMoN> Saviq, that looks fine, I guess the gtk part of the helpers gets much more testing than its qt counterpart, which would explain why this slipped in
<Saviq> indeed
<mvo> cachio: I saw that error in some tests but it does not ring any bell
<mborzecki> jdstrand: no worries, right now it's merely accounting for what snapd, s-c, s-u-n and s-d-n do so that they do not cause unnecessary selinux denials
<mvo> cachio: we did get a new systemd recently though
<mborzecki> jdstrand: similar thing for snaps with sevices, make sure that it's possible to start them without causing additional denials
<mup> PR snapd#6608 opened: cmd/snap-confine: umount scratch dir using UMOUNT_NOFOLLOW <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6608>
<jdstrand> mborzecki: yep, that's all good and thanks for doing that :) just wanted to make sure you got the memo on the other bits
<dot-tobias> I'd like to put configuration in a gadget.yaml for a snap that I have not yet released on the store. I have its snap ID, but putting that in gadget.yaml seems to have no effect. The snap is included in ubuntu-image via --extra-snaps and installs fine, just no configuration applied. Also, connecting another snap to it does not do anything (nothing in snap tasks #id), so I suspect it's something with the ID. An idea, anyone?
<mup> PR snapd#6609 opened: snap/gadget: introduce volume update info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6609>
<Chipaca> dot-tobias: do you have the right id?
<zyga> jdstrand: suse review is going forward, they will be looking at apparmor and snapd proper as well
<zyga> jdstrand: I must say I'm very pleased with the outcome so far and with the interaction in particular
<jdstrand> zyga: curious what they are looking at with apparmor; they have had it for years. I guess the policy
<jdstrand> but regardless, cool and yes
<zyga> jdstrand: yes, they are reviewing the policy
<Chipaca> niemeyer: if you could find the time to read https://forum.snapcraft.io/t/use-of-markdown-in-snap-metadata-summary-description/2128/40 and comment there I'd appreciate it
<niemeyer> Chipaca: Done
<Chipaca> niemeyer: thank you
<Chipaca> pedronis: http://paste.ubuntu.com/p/qKBpN4Zsjz/ fwiw
<pedronis> Chipaca: it looks kind of what I would have expected
<Chipaca> pedronis: I maintain that it works by magic and happy accident
<Chipaca> but if you're happy with it until we refactor, ok
<pedronis> Chipaca: we need store changes too, though?
<Chipaca> pedronis: for the more limited retry strategy, yes?
<pedronis> yes
<Chipaca> pedronis: yes
<Chipaca> but those don't scare me :-)
<pedronis> ok
<Chipaca> trying to repro https://api.travis-ci.org/v3/job/506691205/log.txt now though
 * cachio lunch
<mup> PR # closed: snapcraft#1649, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433,
<mup> snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2473, snapcraft#2493, snapcraft#2495, snapcraft#2500, snapcraft#2502
<mup> PR # opened: snapcraft#1649, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433,
<mup> snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2473, snapcraft#2493, snapcraft#2495, snapcraft#2500, snapcraft#2502
<Chipaca> off to the gym for me
<Chipaca> happy EOW all (i'll bbl to see how spread is doing wrt repro'ing the thing)
<zyga> jdstrand: super-low-hanging-fruit for EOW: 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>
<mup> PR snapd#6610 opened: interfaces/builtin: add add exec "/" to docker-support <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6610>
<sil2100> mvo: hey! I'd need some super-powers to the cm3 and pi2 old core16 gadget snap github repos if you have a moment ;)
<cjwatson> mvo: Hi - did you notice my comments on https://code.launchpad.net/~mvo/launchpad/add-cnf-metadata-to-release-file/+merge/343161 ?  They should be easy, and then I can land it
<mvo> cjwatson: I missed those, looking now, thank you
<mvo> sil2100: what do I need to do?
<sil2100> mvo: we'd need foundations having super-power powers at https://github.com/snapcore/cm3-gadget and https://github.com/snapcore/pi2-gadget
<mvo> sil2100: sure, on it
<mvo> sil2100: please try now - ubuntu-foundations is now marked "admin" in both
<sil2100> \o/
<sil2100> I have power!
<mup> PR snapd#6600 closed: timings: add new helpers, Measurer interface and DurationThreshold <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6600>
<cachio> niemeyer, the PR https://github.com/snapcore/spread/pull/75 has been updated
<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> niemeyer, thanks for reviewing
<cjwatson> mvo: Cheers.  Landing now
<niemeyer> cachio: Responded
<zyga> cachio: question about tumblweed, what happened so that that branch enabling it finally landed?
<mvo> cjwatson: thank you
<cachio> zyga, tumbleweed is being used currently
<cachio> zyga, why?
<cachio> niemeyer, thanks
<zyga> cachio: yes, I noticed
<zyga> cachio: the PR enabling it used to fail
<zyga> cachio: so I wonder what changed
<cachio> zyga, there was a problem with a dependency
<cachio> zyga, which was fixed in the opensuse repo, so then I updated the image and everything worked again
<zyga> nice
<zyga> thank you
<cachio> zyga, np
<mvo> cjwatson: just saw the test failure in my LP branch, fixing it now
<cachio> niemeyer, hey, about the change I did for the residue test
<cachio> niemeyer, do you think it is better to add it in a different PR?
<cachio> niemeyer, I added that to have 100% test passing
<cachio> otherwise we will see 1 error
<niemeyer> cachio: More generically, it's never a good idea to pack side changes that are completely unrelated to the stated purposed for the PR
<niemeyer> cachio: Ah, interesting
<niemeyer> cachio: So it is related to making tests pass.. it doesn't look like so
<niemeyer> cachio: Why is the change necessary?
<cachio> niemeyer, when I added the repeat option for spread I broke this test
<niemeyer> cachio: When you added that option where?
<cachio> niemeyer, so, residue is not working in case hte test fails
<cachio> niemeyer, in spread code
<cachio> niemeyer, long time ago
<niemeyer> cachio: Sorry, I don't get
<mvo> cjwatson: https://code.launchpad.net/~mvo/launchpad/add-cnf-metadata-to-release-file/+merge/364599 <- sorry again for not spotting this earlier
<cachio> niemeyer, I added a options to be able to do > spread -repeat 10
<niemeyer> cachio: Yeah, ok
<niemeyer> cachio: And..?
<cachio> niemeyer, so the residue test it is broken since that time
<niemeyer> cachio: The residue test always fails then?
<cachio> niemeyer, yes
<cachio> niemeyer, this change fixes the problem
<niemeyer> cachio: I see.. do we have a test exercising residue with repeat at the same time?
<cachio> niemeyer, no
<cachio> niemeyer, the residue test checks spread leave residue in 2 scenarios
<cachio> niemeyer, 1 when the test pass
<cachio> niemeyer, 2. when the test fails
<cachio> niemeyer, so the residue test is failing in the second scenario/part
<niemeyer> cachio: Cool, thanks for the explanation.. sounds good
<cachio> niemeyer, nice
<cachio> niemeyer, perfect I'll retest the cache system and leave a message in the PR
<cachio> thanks for reviewing
<niemeyer> cachio: Thank you!
<yotux> Can someone explain why an app has multiple loops directorys
<cjwatson> mvo: Heh, wonder why I missed that.  Landing, thanks
<yotux> I found the answer to my question sorry its like pacman has 3 versions
<mup> PR snapcraft#2473 closed: plugins: improve python and go schema validation <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2473>
<kjackal> Hey snappy people, there is this TGI Kubernetes right now https://www.youtube.com/watch?v=3Px-kbcIaVE . They are going to deploy MicroK8s snap on arch, centos etc. It might be good feedback for snaps
<kjackal> plus you may be able to help in case some distros do not work
<Chipaca> kjackal: thanks for the heads up
<Chipaca> it's being fun
<kjackal> thanks people
<cjwatson> mvo: Don't worry about the next failure - transient glitch, I'll retry until it works
<Chipaca> ok, have great weekends people
 * Chipaca EOWs
<mvo> cjwatson: thank you!
 * mvo calls it a day
<mup> PR snapcraft#2503 opened: cli: disable raven if not running from package <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2503>
<mup> PR snapcraft#2502 closed: meta: fix management of snap/local <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2502>
#snappy 2019-03-16
<mup> PR snapd#6611 opened: interfaces/builtin: add add exec "/" to docker-support <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6611>
<mup> PR snapd#6612 opened: interfaces/builtin: add dev/pts/ptmx access to docker_support <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6612>
<mup> PR snapd#6613 opened: interfaces/builtin: add dev/pts/ptmx access to docker_support (for 2.38) <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6613>
<mup> PR snapd#6614 opened: cmd/snap-confine: use fixed private tmp directory <Created by zyga> <https://github.com/snapcore/snapd/pull/6614>
#snappy 2020-03-09
<mborzecki> morning
<mborzecki> back from school run
<mborzecki> mvo: morning!
<zyga> Hey
<zyga> I will start around 9
<zyga> Looking after Lucy for now
<mborzecki> zyga: hey!
<zyga> How are you all? :-)
<mborzecki> zyga: still a bit tired
<mvo> mborzecki: good morning
<mvo> zyga: hey!
<mborzecki> zyga: though happy i'm no longer on hotel food ;)
<zyga> Or hotel coffee
<zyga> Though I could use a few days of no-work sleep and rest away from family life too :P
<zyga> (I bet my wife would do too)
<mborzecki> yeah, need to make use of those swap and carry over days
<mvo> zyga, mborzecki ++ !
<mup> PR snapd#8223 closed: interfaces/u2f: Add Titan USB-C key <Created by stgraber> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8223>
<mup> PR snapd#8222 closed: wrappers: import /etc/environment in all services <Bug> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8222>
<mborzecki> https://github.com/snapcore/snapd/pull/8221 needs a 2nd review
<mup> PR #8221: ovelord/snapstate: update only system wide fonts cache <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8221>
<mvo> mborzecki: I should have capacity
<mborzecki> mvo:  it's super simple ;)
<mvo> mborzecki: \o/
<mup> PR snapd#8221 closed: ovelord/snapstate: update only system wide fonts cache <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8221>
<mborzecki> yay
<mvo> mborzecki: but this will not fix the fc issue on fedora, right?
<mvo> mborzecki: it's just a drive-by?
<mborzecki> mvo: unfortunately, just a drive by
<mup> PR snapd#8229 opened: overlord: disable Test..AbortShortlyAfterStartOfOperation for 2.44 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8229>
<mvo> hrm, session-tool terminates on centos-8-64 in master
<mvo> c.f. https://api.travis-ci.org/v3/job/658196422/log.txt
<mborzecki> zyga: ^^
<mborzecki> zyga: isn't that the thing you investigated on friday?
<mvo> a review for 8229 would be nice, this is strictly 8229
<mborzecki> mvo: proposed a little change in 8229
<mvo> mborzecki: oh, nice idea!
<mvo> mborzecki: it's not quite true, it will be fixed in master :) but yeah, I think this is much nicer
<zyga> re
<zyga> mvo: I'll check
<zyga> mborzecki: yes but I could not reproduce it after -repeat 100 :/
<mborzecki> duh
<zyga> but yeah
<zyga> that's weird
<zyga> it implies PAM module that sets XDG_RUNTIME_DIR just didn't do it
<zyga> but why?
<mborzecki> hmm all the relevant bits should be fairly recent
<mborzecki> maybe we're missing some confi piece that's enabled for desktops?
<zyga> mborzecki: are you talking about pam?
<zyga> mborzecki: but it passes like 99,9% the tiem
<zyga> it's probably a race or a bug we're hitting (or a mistake in my assumptions)
<mwhudson> hm i have seeding problems in today's live server daily
<mvo> mwhudson: any logs?
<mwhudson> the journal refers to OOPSID
<mwhudson> where are they?
<mwhudson> mvo: "reported install problem for "core" as ..."
<mvo> mwhudson: does "journal -u snapd" report anything? also "snap changes"
<mwhudson> mvo: the journal refers to these OOPSes
<mwhudson> snap changes has "initialize system state" in Error
<mvo> mwhudson: do you have an oops-id for me? I can look at it
<mwhudson> ah i think this may be my fault
<mvo> mwhudson: also "snap change 1" (the error change is probably id 1, right?). a pastebin of this would be great
<mwhudson> mvo: all slightly tedious in the live session :)
<mvo> mwhudson: indeed, sorry for that
<mvo> mwhudson: a picture with a mobile phone is probably also fine :)
<zyga> I picked up the thing I was looking at on Friday
<mwhudson> the task in error in is "failed to start snap.subiquity.subquity-service.service"
<zyga> https://github.com/snapcore/snapd/pull/8230 is just a test case, I'll check how we handle environment across the stack and try to fix it as well
<mup> PR #8230: cmd/snap-exec: add test case for LP:#1860369 <Created by zyga> <https://github.com/snapcore/snapd/pull/8230>
<mwhudson> and "transaction order is cyclic"
<mup> PR snapd#8230 opened: cmd/snap-exec: add test case for LP:#1860369 <Created by zyga> <https://github.com/snapcore/snapd/pull/8230>
<zyga> mborzecki: ^
<mwhudson> and i was messing with after/before nonsense on friday
<mvo> mwhudson: aha, that makes sense
<mwhudson> so yeah, i think this is my fault :)
<mwhudson> sigh, why is boot so hard
<zyga> we should go back to autoexec.bat
<zyga> at least it was deterministic
<mwhudson> er does the service file get deleted again if installing the snap fails?
<zyga> mborzecki: it should
<zyga> er
<zyga> mwhudson: ^
<mwhudson> zyga: this is not maximally helpful :)
<zyga> mwhudson: yeah, I can understand that, perhaps you can prolong the process with a long sleep (assuming you can tty in)
<mwhudson> zyga: in this case what's going on is fairy clear
<zyga> mwhudson: how would it help you if the service file sticked around?
<zyga> mwhudson: perhaps I misunderstand but perhaps a general "--install-even-if-services-fail" mode would be useful for development
<mborzecki> zyga: will you be pushing a fix to #8230 as well?
<mup> PR #8230: cmd/snap-exec: add test case for LP:#1860369 <Created by zyga> <https://github.com/snapcore/snapd/pull/8230>
<zyga> mborzecki: yes
<zyga> mborzecki: the fix is not that hard, just thinking if something else needs to be updated
<zyga> brb
<mborzecki> mvo: added some comments in #8100
<mup> PR #8100: httputil: add support for extra snapd certs <Created by mvo5> <https://github.com/snapcore/snapd/pull/8100>
<mborzecki> mvo: i can post a patch if you like
<mborzecki> zyga: do you have /etc/pulse/client.conf.d/<files-inside> in focal?
<mborzecki> mvo: #8227 for 2.44?
<mup> PR #8227: interfaces/audio_playback: Fix pulseaudio config access <Simple ð> <Created by Erick555> <https://github.com/snapcore/snapd/pull/8227>
<mborzecki> zyga: trivial PR ^^
<zyga> mborzecki: checking
<zyga> yes, I have two files there
<zyga> 00-disable-autospawn.conf
<zyga> and 01-enable-autospawn.conf
<zyga> mborzecki: the latter is a symlink (dangling) to /run/pulseaudio-enable-autospawn
<zyga> weird
<zyga> perhaps we need the /run rule as well?
<mborzecki> zyga: idk, the fix in 8227 seems to fix the problem for the author, so i'd start with that (and it's alrady what the `pulseaudio` iface does)
<zyga> mborzecki: reviewed
<mborzecki> ogra_: hey, does the zoom-client app start at all? just tried it and it coredumps when starting
<mvo> mborzecki: sorry for the delay, had a call
<mvo> mborzecki: looking at backlog now
<mvo> mborzecki: re 8227> yes, let's double check with jamie though
<mvo> mborzecki: just to be sure it's not something deliberate
<mvo> mborzecki: I like the LoadInfo() idea - I think it makes sense. feel free to push a patch. I modelled the interface after samueles suggestion so might be worth checking with him first before spending too much time on this though)
<mborzecki> mvo: yeah, he's away today, but i'll ping him tomorrow
<ogra> mborzecki, it definitely does for me ...
<ogra> let me purge and re-install to be sure
<mvo> mborzecki: sounds great, thank you
<ogra> mborzecki, starts fine here https://paste.ubuntu.com/p/vBnx3CpZBM/ ... (at that point i have a UI on screen (even though nothing would work without connecting the interfaces)
<mborzecki> ogra: i'm trying this on arch, maybe it's a similar case to spotify from snap that segfaults
<ogra> hmm, yeah
<ogra> sadly zoom is 100% proporietary so i cant change any of its code
<ogra> but for snap run --shell to look at pacmd you luckily dont need to run itself
<ogra> mborzecki, also note that i can touch /var/run/1000/pulse/native (the socket) just fine without error
<ogra> (forgot to add that to the forum)
<zyga> mborzecki: so I did some digging
<zyga> mborzecki: and it's not great
<mborzecki> zyga: hm?
<zyga> mborzecki: when environment contains duplicate variables
<zyga> mborzecki: programs disagree as to what is set
<mborzecki> hahah
<zyga> mborzecki: for instance, python prefers the first value
<zyga> mborzecki: but shell prefers the last value
<zyga> mborzecki: C is more like python
<zyga> mborzecki: I think fixing this may "bite"
<zyga> mborzecki: I'll go ahead and see if fixing it breaks anything visibly
<mborzecki> hm wnder if we should maybe do it in 2.45?
<zyga> mborzecki: IIRC it breaks some stuff for snapcraft now
<mborzecki> or 44 and then patch release if things are turn for the worse?
<zyga> mborzecki: let's decide once we know some more
<zyga> mborzecki: https://bugs.launchpad.net/snapd/+bug/1860369/comments/13
<mup> Bug #1860369: Python apps broken in MicroStack (a classic snap) after Jan 14 snapcraft update <core20> <snapd:Triaged by anonymouse67> <https://launchpad.net/bugs/1860369>
<zyga> I'll grab lunch and fix it after
<zyga> sergiusens: https://bugs.launchpad.net/snapd/+bug/1860369/comments/13 can you comment on this and advise us if this will break snapcraft-built snaps?
<mup> Bug #1860369: Python apps broken in MicroStack (a classic snap) after Jan 14 snapcraft update <core20> <snapd:In Progress by zyga> <https://launchpad.net/bugs/1860369>
<sergiusens> zyga: I suspect that it would be mostly ondra's apps as they use adapter: none... mostly everything else has a shell in the middle either through command-chain or a wrapper
<ondra> sergiusens yes, I use heavily adapter: none
<sergiusens> zyga: but yes, python prefers "old", shell prefers "new"...which is the origin for the bug report
<ondra> sergiusens are we removing support of it?
<sergiusens> ondra: adapter: none and "environment: " is buggy in snapd
<mup> PR snapd#8227 closed: interfaces/audio_playback: Fix pulseaudio config access <Security-High> <Simple ð> <Created by Erick555> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8227>
<mborzecki> mvo: can you cherry-pick https://github.com/snapcore/snapd/pull/8227 to 2.44?
<mup> PR #8227: interfaces/audio_playback: Fix pulseaudio config access <Security-High> <Simple ð> <Created by Erick555> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8227>
<sergiusens> ondra: just read a few lines above
<ondra> sergiusens ah, good to know I think one customer is using it as well
<zyga> re
<zyga> ondra: are you okay with us fixing the bug without any extra special compatibility features?
<zyga> ondra: we will correctly override environment along the whole chain
<ondra> zyga sure, I do not think we have hit it so far, and if we have defined env twice, it's also error on our side :)
<zyga> ondra: I think it's not an error in general
<zyga> ondra: let's take PATH
<ondra> zyga true
<zyga> ondra: you have one to begin with, from either system or snap-confine
<zyga> ondra: then you can change it (e.g. extend or override) in snap global environment
<zyga> ondra: then you can do the same again, at the level of a specific application
<zyga> ondra: we're just inconsistent for now
<ondra> zyga ah, that makes sense
<ondra> zyga so I think from I'm aware, we usually use one or another, do not combine both
<zyga> ondra: sure, my point is that combining is fine IMO
<ondra> zyga this was case in one snap I was doing about year ago and that one is dead for now :)
<ondra> zyga agree with you, you should be able to combine
<ondra> it makes sense
<jdstrand> mvo: hey, did you see https://github.com/snapcore/snapd/pull/8100#discussion_r389109976 ? I feel like I am missing something?
<ondra> zyga but it should be predictable :)
<mup> PR #8100: httputil: add support for extra snapd certs <Created by mvo5> <https://github.com/snapcore/snapd/pull/8100>
<jdstrand> mvo: also, saw the timeline for 2.44. I need to prepare a PR for policy updates (wanted to earlier, but alas, focused on PR review backlog)
<jdstrand> mvo: I'll do that today (maybe split into multiple PRs)
<jdstrand> mvo: there is a timing problem though. there is a weird rule I'm trying to chase down for joedborg and the k8s team and until I understand it, I don't know where I want to put it
<jdstrand> mvo: this will be in a separate PR as soon as I figure it out
<joedborg> Morning jdstrand, weâre mostly all on swap.  Whatâs the issue?
<jdstrand> joedborg: there is no new issue. just the timing of when I saw mvo say that he wanted to cut a final 2.44
<mvo> jdstrand: thanks for this update
<clmsy> hi everyone
<clmsy> having a bit of a trouble at the moment
<clmsy> i accidentaly uploaded a package to global store
<clmsy> than on the details page i just want to remove and get rid of it
<clmsy> details page being dashboard.snapcraft.io/snaps/(nameofthesnap)
<clmsy> if i try edit name or any edit in any part i get a 404 back
<mvo> roadmr: is the above question from clmsy something you could help with?
<mup> PR snapd#8229 closed: overlord: disable Test..AbortShortlyAfterStartOfOperation for 2.44 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8229>
<mup> PR snapcraft#2963 opened: project: add fallbacks for os.sched_getaffinity <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2963>
 * zyga -> quick coffee 
 * zyga EODs the online part, will focus on coding for some more time offline
<mup> PR snapd#8231 opened: interfaces/{docker,kubernetes}-support: updates for lastest k8s <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8231>
<mup> PR snapcraft#2964 opened: build providers: remove LXD specific env setup <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2964>
<mup> PR snapd#8232 opened: interfaces: miscellaneous policy updates <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8232>
<mup> PR snapd#8233 opened: snap-confine: unconditionally add /dev/net/tun to the device cgroup <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8233>
<mup> Bug #1859084 changed: tun module is not auto-loaded  on UC18/pi3 despite network-control interface being connected <snapd:In Progress by jdstrand> <https://launchpad.net/bugs/1859084>
<mup> PR snapcraft#2965 opened: rosdep: include EOL ROS distros <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2965>
<mup> PR snapcraft#2966 opened: build providers: move to buildd images <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2966>
#snappy 2020-03-10
<mup> PR snapcraft#2967 opened: requirements: uprev click to 7.1.1 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2967>
<mborzecki> morning
<mborzecki> re
<zyga> Good morning
<mborzecki> zyga: hey
<zyga> I fixed the exec env bug but it will take me some more time to adjust tests in two packages
<zyga> I made it impossible to easily cause bugs like that again
<pstolowski> mornings
<mborzecki> pstolowski: mvo: morning
<mvo> mborzecki: good morning
<mvo> and good morning to pstolowski
<pstolowski> o/
<zyga> hey pawel
<zyga> mvo: I'm considering taking today off
<zyga> I feel super tired somehow
<zyga> I will work some more on wrapping up two things from yesterday
<zyga> and EOD around noon
<mup> PR snapd#8225 closed: snapcraft.yaml: use sudo -E and remove workaround <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8225>
<mvo> zyga: sure, get well
<zyga> mvo: I hope I'm not sick, I just feel tired
<zyga> anyway, I'll finish what I have to first :)
<mup> PR snapd#8233 closed: snap-confine: unconditionally add /dev/net/tun to the device cgroup <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8233>
<mup> PR snapd#8214 closed: tests: test that after "remove-user" the system is unmanaged <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8214>
<mup> PR snapd#8211 closed: tests: run ipv6 network-retry test too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8211>
<mup> PR snapd#7999 closed: devicestate: allow encryption regardless of grade <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7999>
<mup> PR snapd#7673 closed: interfaces/desktop: allow access to system prompter interface <Created by alexmurray> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7673>
<amurray> mvo: thanks for merging my PR :)
<mvo> amurray: thanks for making it in the first place :)
<pedronis> pstolowski: hi, what's the status of #8201 ?
<mup> PR #8201: tests: mock prune ticker in overlord tests to reduce wait times <Created by stolowski> <https://github.com/snapcore/snapd/pull/8201>
<pstolowski> pedronis: hi; it's ready but i'm pondering if it makes sense to pass N to tick
<pedronis> pstolowski: should we close #8198 ? afaiu mvo skipped some tests in 2.44 instead
<mup> PR #8198: o/tests: bump TestEnsureLoopPruneAbortsOld sleep time <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8198>
<pstolowski> done
<mup> PR snapd#8198 closed: o/tests: bump TestEnsureLoopPruneAbortsOld sleep time <â Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/8198>
<mborzecki> we don't have a page that lists know model names do we?
<pedronis> mborzecki: known in which sense?
<mborzecki> pedronis: say, i forgot the actual model name for rpi3 on core18, not sure there's an easy way to find a list of model names of supported devices
<pedronis> mborzecki: ah, no we don't have a list but should have one I suppose in the new UC docs (cc degville)
<mborzecki> pedronis: our use case may be a bit weird, a i know where to find the models repo ;) others may not
<mup> PR snapd#8234 opened: devicestate: support dropping "cloud.cfg" user-data cloud-init <Created by mvo5> <https://github.com/snapcore/snapd/pull/8234>
<degville> pedronis / mborzecki: thanks for bringing this up. So, I guess I can get the model names from the model assertions (http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/). If so, I'll add them to the supported platforms page I've already created.
<mborzecki> degville: sounds good, there's also a repository with model assertions right here https://github.com/snapcore/models in case it's useful
<degville> mborzecki: brilliant, thanks!
<mborzecki> degville: some of those are for core20 though
<degville> mborzecki: ok, thanks.
<pedronis> mborzecki: seems #8185 needs a master merge?  snapd-failover failed there (cc mvo)
<mup> PR #8185: tests: add uc20 kernel snap upgrade managers test, fix bootloadertest bugs <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8185>
<mborzecki> pedronis: i'll merge master and push there, hopefully it's not another unexpected failure more in snapd-failover
<mvo> thanks mborzecki
 * zyga has completed fixing snap environment
<zyga> this was nice
<mup> PR snapd#7731 closed: usersession/userd: add "apt" to the white list of URL schemes handled by xdg-open <â Blocked> <Created by oSoMoN> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7731>
<mup> PR snapd#8235 opened: cmd/snap-preseed: handle --reset flag <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8235>
<mup> PR snapd#7588 closed: cmd/snap: add a "snap routine portal-info" command <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7588>
<mup> PR snapd#8232 closed: interfaces: miscellaneous policy updates <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8232>
 * zyga lunch
 * zyga notices open season for PRs :)
<mvo> zyga: haha - not quite, I think it's just the result of a week of staleness
<jdstrand> mvo: hi! do you want a separate 2.44-specific PR for PR 8232?
<mup> PR #8232: interfaces: miscellaneous policy updates <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8232>
<ackk> hi, I'm seeing these errors when I "snap try" over the current running snap: https://paste.ubuntu.com/p/zQq2cFPCbM/ could it be related to the content interface?
<jdstrand> mvo: also, is ijohnson off? if so, someone else can review PR 8231
<mup> PR #8231: interfaces/{docker,kubernetes}-support: updates for lastest k8s <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8231>
<zyga> mvo: can we merge https://github.com/snapcore/snapd/pull/8230 once green, I have a fix piled up on top and would love to reuse the branch
<mup> PR #8230: cmd/snap-exec: add test case for LP:#1860369 <Created by zyga> <https://github.com/snapcore/snapd/pull/8230>
<zyga> after lunch I'll address the uio issue raised by a customer
 * zyga thanks jdstrand once again for insight on that topic
<jdstrand> np :)
<mvo> jdstrand: 8232> if it's not a burden to you, then yes
<jdstrand> mvo: not at all! coming up :)
<mvo> jdstrand: 8321> I think someone from the team can review it
<mvo> zyga: 8230> we can merge once it has two reviews :)
<zyga> it's just a test showing we have a bug, I guess we can get those quickly
<ackk> with a simplified testcase I get: - Setup snap "maas" (unset) security profiles (cannot update mount namespace of snap "maas": cannot update preserved namespace of snap "maas": cannot update snap namespace: read-only file system)
<mvo> zyga: uio> did you figure out more about this?
<zyga> mborzecki: could you look at 8230 please, super easy
<mvo> zyga: yeah
<zyga> mvo: yes, mostly jdstrand did
<jdstrand> mvo: thanks! I will continue to work on figuring out what to do with a weird k8s access with highest priority. I'd like to say it would be ready today, but I'm not sure yet
<zyga> mvo: I can give you the details now or in the standup, as you wish
<mvo> jdstrand: ok
<mvo> jdstrand: I want to release 2.44-final this week but we are still early
<mvo> zyga: either way is fine, maybe a tl;dr summary here?
<zyga> mvo: tl;dr; is apparor-parser requires hand-holding without the optimizations that we disable; we disable them because they are very slow on smaller systems. The fix involves fine tuning the profile so that we don't hit this pathological case
<jdstrand> mvo: ack. I'm trying not to cause you any delays! :)
<mvo> jdstrand: :)
<mvo> zyga: nice, thank you
<zyga>  brb
<mup> PR snapd#8236 opened: interfaces: miscellaneous policy updates - 2.44 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8236>
<jdstrand> mvo: there you go ^
<mvo> jdstrand: \o/
<jdstrand> I'll do a similar on for PR 8231
<mup> PR #8231: interfaces/{docker,kubernetes}-support: updates for lastest k8s <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8231>
<mvo> jdstrand: +1
<mup> PR snapd#8237 opened: interfaces/{docker,kubernetes}-support: updates for lastest k8s - 2.44 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8237>
<pedronis> mborzecki: there's a arch failure in 8185 now: https://api.travis-ci.org/v3/job/660576207/log.txt
<pedronis> pstolowski: did a pass on #8201, bunch of questions
<mup> PR #8201: tests: mock prune ticker in overlord tests to reduce wait times <Created by stolowski> <https://github.com/snapcore/snapd/pull/8201>
<pstolowski> pedronis: thanks
<mborzecki> pedronis: hmm interesting, we had a workaround for a similar problem with snap services in one of the failover tests, restarted the travis job for now, but we'll probably need to add a litte fix tehre to make the test more robust
<zyga> snapd/boot/export_test.go:38:14 uses type aliases
<mup> PR snapd#8238 opened: many: fix a pari of ineffectual assignments <Created by zyga> <https://github.com/snapcore/snapd/pull/8238>
<zyga> https://www.irccloud.com/pastebin/M7lC1BK4/
<mup> PR snapd#8179 closed: interfaces: power control interface <Needs Samuele review> <â Blocked> <Created by EthanHsieh> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8179>
<zyga> pstolowski: is this still expected? overlordSuite.TestEnsureLoopPruneAbortsOld
<zyga> pstolowski: IIRC you fixed it last week
<pstolowski> zyga: yes, but not landed. the PR is being reviewed
<zyga> ah
<zyga> ok
 * zyga switches to uio
<mup> PR snapcraft#2967 closed: requirements: uprev click to 7.1.1 <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2967>
<mup> PR snapd#8239 opened: interfaces/audio_playback: Fix pulseaudio config access [2.44] <Created by Erick555> <https://github.com/snapcore/snapd/pull/8239>
<cmatsuoka> cachio: I retrieved the image and I'm booting it locally, it's failing in install mode but it's different from what we saw in Frankfurt
<cmatsuoka> hmm, slightly different, but the cause seems to be the same
<mup> PR snapd#8215 closed: interfaces: make the network-status interface implicit on classic <Created by jhenstridge> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8215>
<mup> PR snapd#8239 closed: interfaces/audio_playback: Fix pulseaudio config access [2.44] <Created by Erick555> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8239>
<mup> PR snapd#8236 closed: interfaces: miscellaneous policy updates - 2.44 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8236>
<zyga> 2fa
<zyga> logged out again?
<mup> PR snapd#8240 opened: tests: just remove user when the system is not managed on create-user-2 test (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8240>
<mup> PR snapd#8241 opened: interfaces: work around apparmor_parser slowness affecting uio <Created by zyga> <https://github.com/snapcore/snapd/pull/8241>
<mup> PR snapd#8230 closed: cmd/snap-exec: add test case for LP:#1860369 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8230>
<mup> PR snapd#8242 opened: many: improve environment handling, fixing duplicate entries <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
<zyga> ^ that's a longer PR sorry
<zyga> mvo: about https://github.com/snapcore/snapd/pull/8242 -- let me know if you want a fix that's hacky but small and "maybe ok" for 2.44
<zyga> mvo: otherwise I don't consider it a thing to rush
<mup> PR #8242: many: improve environment handling, fixing duplicate entries <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
<zyga> but please check as the bug affects microk8s
<zyga> so perhaps we may have to
<pstolowski> mvo: should the --reset be tagged for 2.44.x?
<zyga> I did some impact analysis in the bug report, in comment 13
<zyga> https://bugs.launchpad.net/snapd/+bug/1860369/comments/13
<mup> Bug #1860369: Python apps broken in MicroStack (a classic snap) after Jan 14 snapcraft update <core20> <snapd:In Progress by zyga> <https://launchpad.net/bugs/1860369>
<pedronis> mborzecki: now it (8185) failed again on arch and also fedora :/
 * cachio lunch
<mvo> pstolowski: +1
<pstolowski> k
<pstolowski> mvo: i remember you mentioned 'Core snap is installed when reverting a core18 based snap' ~last week; was the problem understood?
<mvo> pstolowski: no :(
<mvo> pstolowski: I think there is a bugreport and a testcase
<mvo> pstolowski: but iirc noone looked at it
<pstolowski> mvo: ack, ty
<mvo> pstolowski: https://bugs.launchpad.net/snapd/+bug/1864944
<mup> Bug #1864944: Core snap is installed when reverting a core18 based snap <original-1853411> <snapd:New> <https://launchpad.net/bugs/1864944>
<mvo> pstolowski: it even has a test case that looks super easy to convert into ta spread test
<pstolowski> mvo: yeah, i saw it, just wasn't sure if it was missing an update. i'm trying the steps right now
<mvo> pstolowski: \o/
<pstolowski> mvo: reproduced
<mvo> pstolowski: nice!
<zyga> back from break
<pstolowski> mvo, pedronis: Revert() does not set base in snapsup, so it gets "core" by default
<pedronis> pstolowski: ah
<pedronis> good catch
<mvo> pstolowski: \o/ nice find
 * mvo hugs pstolowski 
<zyga> pedronis: thank you for the review on environment PR
<zyga> pedronis: I think we could chat about it tomorrow (or when you have time) to figure out what we want to do
<zyga> pedronis: I'll spend the rest of today on fixing the uio performance bug to the point where the draft can be opened and we can try to cherry-pick that to 2.44
<zyga> pedronis: but as I said to mvo earlier, I don't know the priority of the environment bug as it seems to affect microk8s
<zyga> pedronis: could be low (workaround in snapcraft, perhaps) or higher (blocked on us)
<pedronis> zyga: what's the bug number?
<pedronis> anyway if this is the fix, we cannot rush it, it's kind of large
<zyga> pedronis: I agree
<zyga> pedronis: it's referred from the 2nd commit, let me find it
<zyga> https://bugs.launchpad.net/snapd/+bug/1860369
<mup> Bug #1860369: Python apps broken in MicroStack (a classic snap) after Jan 14 snapcraft update <core20> <snapd:In Progress by zyga> <https://launchpad.net/bugs/1860369>
<pedronis> zyga: it seems the branch adds feature that were not there, like ignoring order of hook envs etc
<zyga> ignoring order of hook envs?
<pedronis> zyga: ApplyDelta seems much more powerful than SubstituteEnv
<pedronis> (because of the changed check), I'm not sure fixing a bug and expanding feature should happen together unless they relate to each other
<pedronis> zyga: SubsituteEnv says very precisely: "and substitutes them top-down from the given environment"
<zyga> pedronis: while that is true I think we need to sit down and evaluate what is the semantics we want; We should check what is documented on snapcraft docs and if that makes sense. We should also check how adapters impact anything. I suspect that previous behavior was buggy in more than one way. At the same time I agree that ApplyDelta is more "able" than previous code and can result in what people meant more than what
<zyga> people got
<pedronis> zyga: I can only repeat my point, if we want this in quickly expanding feature is a problem
<zyga> pedronis: I don't know if this is needed urgently, I hope it's not but in such case I also offered a small targeted branch that fixes PATH issue in a more hacky but controlled way
<zyga> pedronis: I think we should discuss and figure out how to evolve the bigger branch to the point where we are happy with it as my main goal was to fix the type system of the problem. We can discuss and change specific bits of implementation if what I did would affect existing snaps in a way we didn't intend
<pedronis> zyga: have you tried what happens with the new code and a circular reference ?
<zyga> I don't believe I have, unless one of the existing tests has effective circular refs
 * zyga looks
<zyga> pedronis: both get expanded to empty
<zyga> pedronis: there's an existing test for that
<zyga> pedronis: in env_test.go:265
<zyga> (it behaved this way before as well)
<pedronis> yes, but for different reasons
<mup> PR snapd#8243 opened: o/snapstate: set base in SnapSetup on snap revert <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8243>
<pstolowski> mvo: ^
<zyga> pedronis: I think this is interesting https://github.com/snapcore/snapd/pull/8242#discussion_r390461058
<mup> PR #8242: many: improve environment handling, fixing duplicate entries <Bug> <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
<zyga> pedronis: I want to EOD soon as I want to sleep a little longer today, would you mind if we parked this until tomorrow?
<zyga> pedronis: I want to spend some more time on the uio code
<pedronis> zyga: that's fine, my general input that we should try to be more convervative with the change
<zyga> I agree
<mvo> pstolowski: nice, thank you
<zyga> I wonder what people would expect in the example I gave, I think it's a good chance we will get 50-50 responses
<pstolowski> eod, need to run an errand
<zyga> pedronis: note that current code (in master) just inserts both PATH values, because of the bug
<zyga> so you kind of get a superposition :)
<zyga> but that's for sure not what we want
<pedronis> unless we promised that we merge values
<pedronis> the one in the app should win
<cjp256> zyga/pedronis: the priority for build env is high for core20, as it won't generate command wrappers.  snapcraft currently forces the wrappers for when adapter != none, and it became a problem when we stopped generating unnecessary wrappers
<cjp256> but core20 still isn't for some time, so it's not a rush imo :)
<zyga> pedronis: I wonder if the fact that this was shoved through shell wrappers meant that we got the expanding semantics at any time in the past
<zyga> pedronis: tomorrow I'll write a regression test for this
<zyga> pedronis: as in end-to-end spread test
<zyga> pedronis: at least then it's measured
<mvo> cachio: if you could double check and approve 8240 that would be great
<mvo> zyga: are you around? I wonder how 1866424 should be attacked, it seems a missing gpio should not cause snapd to stop refreshing forever
<zyga> around
<mvo> zyga: I wonder if we could make missing gpios a warning?
<zyga> mvo: "ish", the problem is what you want to happen then
<mvo> zyga: but it's a bit tricky as it's a real error
<zyga> but yeagh
<mvo> zyga: yeah, the gpio will be missing from the profile
<zyga> it's not really missing, the user was holding it wrong (unexporting behind snapd's back)
<mvo> zyga: so subsequent stuff may misbehave
<zyga> but I agree it's a very bad property
<zyga> mvo: consider this idea:
<zyga> mvo: when an interface instance (plug or slot)'s corresponding method fails, we could mark it as bad and skip it in the profile generation
<zyga> mvo: we could warn (finally a use case for warnings)
<zyga> mvo: it would require some changes around but not too hard
<zyga> mvo: I would rather do it at interface level
<zyga> mvo: rather than at the level of a specific method
<zyga> mvo: because it's more proper, in my eyes, to say "this plug or slot is entirely absent"
<mvo> zyga: yeah, the downside of that is that it requires more discussion/work so it will take longer but I agree
<zyga> mvo: rather than to say "a specific part of the implementation failed so we skipped it"
<zyga> mvo: since those can have security implications
<zyga> mvo: .e.g. apparmor gave you access to /dev but udev tagging failed so you have open access
<mvo> zyga: aha, indeed, I was thinking we would only narrow access down
<zyga> unfortunately that is not the case
<zyga> mvo: I could look at that after UIO tomorrow
<mvo> zyga: yeah, makes sense. i pasted what you wrote into the bug
<zyga> mvo: if you have an agreement on the design
<mvo> zyga: that would be nice indeed
<zyga> perfect, thank you
<mvo> zyga: it sounds like we can have a quick chat during standup/after stnadup
<zyga> that sounds good
<zyga> what I said has a scary component
<mvo> zyga: we certainly need samuele to think about it/agree :)
<zyga> because what it means if an implicit slot misbehaves?
<zyga> mvo: does it mean it is disconnected
<zyga> is it broken?
<zyga> some things to ponder over
<mvo> zyga: we could error in those cases maybe?
<zyga> yes but the devil is in the details, a single interface (plug or slot) interacts with loads of parts
<zyga> in my eyes it would be neutered _for the purpose of a given connection_
<zyga> so not globally
<zyga> so less chance to break the world
 * mvo nods
 * zyga EODs without finishing UIO
<zyga> I'm sorry, need to rest
<mvo> zyga: no worries, get some good rest!
<mup> PR snapcraft#2965 closed: rosdep: include EOL ROS distros <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2965>
<mup> PR snapcraft#2964 closed: build providers: remove LXD specific env setup <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2964>
<ogra> $ grep ubuntu /etc/group
<ogra> sudo:x:27:ubuntu
<ogra> docker:x:113:ubuntu
<ogra> hmm, so why are there entries for a non-existing ubuntu user in my readonly /etc/group file in core16
<mup> PR snapcraft#2962 closed: Go: unable to build snap when using `go mod` and main package is not in the root <Created by pavel-d> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2962>
#snappy 2020-03-11
<mup> PR snapcraft#2968 opened: git: always fetch specified source-commit before using <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2968>
<mup> Bug #1857358 changed: Not yet operational on Fedora systems <fedora> <Snappy:Expired> <https://launchpad.net/bugs/1857358>
<mborzecki> morning
<mvo> hey mborzecki
<mup> PR snapd#8240 closed: tests: just remove user when the system is not managed on create-user-2 test (2.44) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8240>
<mvo> mborzecki: a second review for 8231 would be great
<mborzecki> mvo: wow, that AARE for nvme is scary ;)
<mup> PR snapd#8231 closed: interfaces/{docker,kubernetes}-support: updates for lastest k8s <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8231>
<mborzecki> school run, back in 30
<mvo> mborzecki: aare?
<mup> PR snapd#8243 closed: o/snapstate: set base in SnapSetup on snap revert <Bug> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8243>
<mborzecki> re
<mborzecki> mvo: apparmor regular expressions
<mvo> mborzecki: aha, right
<mborzecki> and with the latest regulations, parents can no longer enter school buildings, at least in my area
<mborzecki> wouldn't be surprised if they close down all schools for a week or so
<mvo> mborzecki: that's likely to happen
<mvo> I think
<mborzecki> hm the failures in 8185 that pedronis saw yday is probably services-watchdog test state leaking into subsequen tests
<mup> PR snapd#8185 closed: tests: add uc20 kernel snap upgrade managers test, fix bootloadertest bugs <Test Robustness> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8185>
<mup> PR snapd#8238 closed: many: fix a pair of ineffectual assignments <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8238>
<mvo> mborzecki: I think 8206 is ready for a review too and hopefully an easy win
<mvo> mborzecki: we are at 52 now, maybe we can hit 50!
<mup> PR snapd#8237 closed: interfaces/{docker,kubernetes}-support: updates for lastest k8s - 2.44 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8237>
<mvo> mborzecki: we have some simple ones like 8220 pending (unfortunately I think this one needs a security review)
<mborzecki> mvo: ha, so it was a hanging sleep command
<mvo> mborzecki: yes
<zyga> good morning
<zyga> how are things?
<mborzecki> mvo: maybe we should set Ptdeahtsig to syscall.SIGKILL for most commands, not sure we use it at all
<mborzecki> zyga: morning
<mvo> mborzecki: I think we don't
<mvo> hey zyga
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> mvo: #8206 is green!
<mup> PR #8206: travis.yml: run unit tests on arm64 as well <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8206>
<mvo> zyga: want to double check 8100 ? it got your +1 already but it changed a bit since (more abstractions mostly)
<zyga> yeah sure
<mvo> zyga: shoudl be simple
<zyga> I am in despair
<zyga> found my gpg key
<zyga> and it's locked
<zyga> and I don't recall the password :)
<mup> PR snapd#8206 closed: travis.yml: run unit tests on arm64 as well <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8206>
<mvo> one more and we are down to 50! maybe 8197? no code change just a refactor for snap downloads via snapd?
<mvo> zyga: oh no!
<zyga> some heavy rain today
<mborzecki> mvo: i'm not dropping SetRecoverySystemEnv from uboot struct yet, for now i've updated ExtractedRecoveryKernelImage.. iface
<mborzecki> mvo: although i don't expect needing to use SetRecoverySystemEnv, we'll know for sure after the meeting with the foundations
<mvo> mborzecki: +1
<mvo> mborzecki: I also added samuele as optional, not sure if he wants to join or not
<mborzecki> ok
<mborzecki> pedronis: hi, #8224 has conflicts now
<mup> PR #8224: many: clean separation of bootenv mocking vs mock bootloader kinds  <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8224>
<pedronis> mborzecki: yes, saw that, will try to merge master and address at least partially the XXXs soon
<pedronis> mborzecki: thx
<mvo> pstolowski: thanks for your update to 8201!
<pstolowski> mvo: np. i'm nervous to see if it passes
<mvo> pstolowski: heh :)
<mvo> pstolowski: *fingers crossed*
<zyga> mvo: can you please refresh my memory
<zyga> how is snap-repair updated?
<mvo> zyga: snap-repair is part of the snapd snap and gets updated when snapd gets updated, was that the question?
<zyga> yes, that's mostly it
<zyga> I recall we had a copy of snap-repair in core16 systems
<zyga> somewhere in writable
<zyga> is that the case?
<mvo> zyga: I think we talked about it, I don't recall we did it
<pedronis> mvo: it's still a todo
<zyga> ok, that's what I was curious about thanks
<pedronis> mvo: there are still current todos:  https://forum.snapcraft.io/t/repair-capability-emergency-fixes/311/39 and https://forum.snapcraft.io/t/repair-capability-emergency-fixes/311/42
<pedronis> so the packaging bits, the task for this cycle, plus consider how early it can be run
<mvo> yeah :/
<zyga> I wonder if snap-repair makes sense in core 20 world
<pedronis> it has a role, going through a recovery reboot is not always acceptable especially if there are other solutions
<pedronis> otoh it hasn't been used yet for real, so hard to judge
<zyga> mvo: reviewed
<pedronis> pstolowski: I reviewed 8201, it needs a 2nd review
<pstolowski> pedronis: ty
<mvo> pedronis, pstolowski I did a pass on 8201
<pstolowski> mvo: thanks!
<mvo> pstolowski: hope it's not too annoying
<pstolowski> mvo: no worries
<pedronis> mvo: the extra ticks might be do go through Ensure as well
<pedronis> it's not just about prune
<pstolowski> yes. but i'll add a comment
<mvo> pedronis: thanks, could be, I am just puzzled because AIUI we only mock the ticks for the pruneC and that calls st.Prune() directly, so not sure how Ensure() comes into play. but it's fine, it's so much nicer than before, just tried to get a good understanding what is going on
<pedronis> mvo: aborting might need two passes through Ensure
<pedronis> mvo: each time we tick prune we also go throgh Ensure
<pedronis> or something like that
<mvo> pedronis: ok
<mvo> cachio: good morning! if you still see this failure of importing the user assertion on uc20 even in the second boot, could you please pastebin/take-a-picture of "journalctl -u systemd-udevd" from the second boot in run mode?
 * zyga feels so so and goes for some tea/coffee upstairs
<zyga> pedronis: when I'm back I'll attack env again
<zyga> pedronis: I read your comments and I'll go and simplify the expression logic and combine it all into Apply
<cachio> mvo, sure
<cachio> mvo, good morning, I just triggered a new run
<cachio> mvo, yesterday it was not goind the run mode, just install mode
<cachio> I was waiting for the new core snap that should help on that
<mvo> cachio: ok
<mvo> cachio: thank you
<cachio> mvo, today it is going into the run mode
<cachio> https://paste.ubuntu.com/p/n6GJpXNjwQ/
<cachio> but still it is not importing the user assertion
<pedronis> zyga: I added some more comments about further simplifications I would like to see for now
<zyga> pedronis: ok
<zyga> I'll read them now
<pedronis> zyga: let me know if you have questions
<zyga> ack
<mvo> cachio: can you do a reboot once it's in run mode and paste me the output of "journalctl -u systemd-udevd" please?
<zyga> weird
<cachio> yes, waiting for the reboot
<zyga> github comments I mean
<zyga> I can respond to some of your comments but not all
<zyga> pedronis: I was thinking and I'm very happy with []osutil.ExpandableEnv
<zyga> because that removes the need for some extra glue logic
<zyga> and expresses more naturally what is really going on
<pedronis> mvo: do we have a formatting problem in interfaces/policy/basedeclaration_test.go or it's just different go versions
<cachio> mvo, https://paste.ubuntu.com/p/GZsNPyNRCC/
<mvo> pedronis: I'm not aware of one, but it could be go version screw
<zyga> pedronis: I ony edit that file in nano
<pedronis> zyga: as far as I know there's no way to "merge" those envs before applying them, that would do what we need
<zyga> pedronis: yeah, I came to the same conclusion
<zyga> pedronis: I'll get to it :)
<pedronis> zyga: we can probably also leave out the Overrides bit from those methods, and just call them Envs() []osutil.ExpandableEnv
<zyga> pedronis: I just wanted something that is distinct from the field (Environment)
<zyga> pedronis: perhaps we don't need a real method after all
<zyga> pedronis: if we change the type to ExpandableEnv
<zyga> we can just reach out to app.Snap.Environment and app.Environment
<zyga> but we'll see
<zyga> first some of the big moves
<pedronis> mborzecki: I merged master and updated #8224, the last changes need a new pass
<mup> PR #8224: many: clean separation of bootenv mocking vs mock bootloader kinds  <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8224>
<mvo> cachio: thanks, do you see /lib/udev/rules.d/66-snapd* in your image?
<cachio> I cant login to the image
<cachio> but let me check if I can unsquash it
<mvo> cachio: oh, so the journal output is also not from inside the image?
<cachio> no
<cachio> the journal output is from the host machine
<cachio> in that case let me try to shell on it
<mvo> cachio: ok, we probably need to somehow create an image that you can add "systemd.debug-shell=1" to the kernel commandline so that you get a root-shell
<mvo> cachio: the output of the udevd would be great to have, that hopefully gives us clues what is brekaing
 * mvo needs to leave for a wee bit
<cachio> {
<cachio> ok
<zyga> kid invasion
<zyga> silly stuff is lucyasd=ad
<zyga> 4WT~WWW
<pstolowski> noo, #8201 failed on google:ubuntu-core-20-64:tests/core/snapd-failover. and on prepare for fedora. and on google-unstable:opensuse-15.1-64:tests/main/session-tool
<mup> PR #8201: tests: mock prune ticker in overlord tests to reduce wait times <Squash-merge> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8201>
<pstolowski> ^ zyga
<pstolowski> zyga: https://api.travis-ci.org/v3/job/660982235/log.txt
<zyga> pstolowski: ack,
<zyga> pstolowski: there must be something I'm missing there
<zyga> as it only fails infrequently, there must be some kind of race that makes PAM module which sets up XDG_RUNTIME_DIR fail
<pstolowski> zyga: grab the log if you need it, i'm going to restart the tests soon
<zyga> done
<cachio> mvo, https://pastebin.com/Gh8rrwNP
<cachio> for some reason it is getting stuck in that line
<cachio> the shell never appeards
<mborzecki> hmm arm64 unit tests still hanging?
<cachio> mvo, could you chekc pleaseif I did it correctly?
<cachio> mvo, https://paste.ubuntu.com/p/fHTdPT2j6Q/
<mvo> cachio: please try setting it in  ï¿½*Run Ubuntu Core 20                                                         ï¿½
<mvo> cachio: so when the second grub screen is there you need to press "e" for edit
<mvo> cachio: and it in the line with the chainload...kernel.efi there
<mvo> cachio: does that make sense?
<cachio> mvo, ok, thanks
<mvo> cachio: not sure if it gives you a debug shell on the serial console though, gives you one on vt9 for sure
<cachio> mvo, I did what you said but it is getting stuck in the same line
<cachio> mvo, https://paste.ubuntu.com/p/S8gQq64WPq/
<mvo> cachio: oh no! maybe you just don't get a debug shell on the serial port :/ that's sad
<cachio> mvo, do you want to connect?
<mvo> cachio: not right now, I need to ponder a bit, I will probably need to try to run this locally in qemu to have the full vritual console access :/
<cachio> ok, just ping me in case you need the image
<mvo> mborzecki: I pushed https://github.com/snapcore/pi-gadget/pull/34
<mup> PR pi-gadget#34: gadget.yaml: move ubuntu-boot to VFAT <Created by mvo5> <https://github.com/snapcore/pi-gadget/pull/34>
<mup> PR snapd#8100 closed: httputil: add support for extra snapd certs <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8100>
<mup> PR snapd#8244 opened: [RFC] config: add system.certs.[a-zA-Z0-9] support <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8244>
<zyga> mvo: commented on the pi-gadget PR
 * pstolowski lunch
<mup> PR snapcraft#2963 closed: project: add fallbacks for os.sched_getaffinity <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2963>
<mvo> zyga: thanks
<cachio> mvo, hey
<cachio> I am trying from serial port and I get this
<cachio> https://paste.ubuntu.com/p/6RkcpYd4TV/
<cachio> mvo, the following run I did't see tha terror https://paste.ubuntu.com/p/Cfkv2w7mfT/
<mvo> cachio: this looks like a OVMF bug, I wonder what version is available in gce
<cachio> ovmf:
<cachio>   Installed: 0~20191122.bd85bf54-2
<cachio>   Candidate: 0~20191122.bd85bf54-2
<cachio>   Version table:
<cachio>  *** 0~20191122.bd85bf54-2 500
<cachio>         500 http://us-east1.gce.archive.ubuntu.com/ubuntu focal/main amd64 Packages
<cachio>         100 /var/lib/dpkg/status
<cachio> mvo, is it ok?
<pedronis> mvo: can we turn off arm tests again, they timeout: https://travis-ci.org/github/snapcore/snapd/jobs/661020356?utm_medium=notification&utm_source=github_status
<pedronis> sometimes
<zyga> pedronis: type Foo *Bar behaves in odd ways in go
<zyga> that hides the entire method set of Bar
<zyga> is there any way to "reach" it?
<pedronis> zyga: that's annoying, I missed this detail, or forgot it
<mup> PR snapcraft#2969 opened: snap: re-add xml development packages for non x86 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2969>
<pedronis> zyga: anyway the text here https://golang.org/ref/spec#Method_sets has that implication
<zyga> thanks
<pedronis> zyga: so embedding the OrderedMap seems the only solution
<zyga> yeah, I see that
<zyga> I think type a = b would be nicer
<zyga> but we cannot for now
<zyga> ok, I'm not blocked, thank you
<zyga> suspend resume on linux with fractional scaling in gnome resizes everything, clipping parts of windows
<zyga> oh well
<mvo> pedronis: sure, let me do that
<mup> PR snapd#8245 opened: travis: disable arm64 again <Created by mvo5> <https://github.com/snapcore/snapd/pull/8245>
<mup> PR snapd#8244 closed: [RFC] config: add system.certs.[a-zA-Z0-9] support <Needs Samuele review> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8244>
<mup> PR snapd#8246 opened: client, daemon, overlord/devicestate: structures and stubs for systems API <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8246>
<mborzecki> pedronis: ^^
<mup> PR snapd#8245 closed: travis: disable arm64 again <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8245>
 * cachio lunch
 * zyga lunch as well
<zyga> and small break to fix backup server
<mup> PR snapd#8247 opened: .travis.yml: enable arm64 again as unstable <Skip spread> <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8247>
<pedronis> mborzecki: I queued it
<pedronis> thx
 * zyga is back to finish work
<mvo> pstolowski: 8201 is green, do you want to squash merge it and edit the description? I will cherry pick to 2.44 then
<zyga> offtopic, firefox is really really fast
<pstolowski> mvo: yes, let's squash merge
<pstolowski> mvo: doing
<mvo> pstolowski: thank you!
<mup> PR snapd#8201 closed: tests: mock prune ticker in overlord tests to reduce wait times <Reviewed> <Squash-merge> <â  Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8201>
<mup> PR snapd#8248 opened: snap: introduce Container.RandomAccessFile <Created by pedronis> <https://github.com/snapcore/snapd/pull/8248>
<pedronis> zyga: I looked at the uio fix, one question, also I notice that one of jdstrand comment isn't addressed, it didn't sound just a nice to have from him, in one form or the other
<mup> PR snapd#8249 opened: interfaces: make gpio robust against not-existing gpios in /sys <Created by mvo5> <https://github.com/snapcore/snapd/pull/8249>
<zyga> pedronis: hmm, which comment was that?
<zyga> pedronis: the one about ordering?
 * zyga looks
<pedronis> yes
<zyga> pedronis: I would not do that in this PR, as I explained in my response that's not a new property and doing anything better (for auditing) would require a smaller dive into the apparmor backend. Doable but not for 2.44 IMO
<mup> PR snapd#8250 opened: tests: mock prune ticker in overlord tests to reduce wait times (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8250>
<pedronis> zyga: I understand, let's see what he says
<zyga> ok
<zyga> if needed I can probably implement that ordering tomorrow if I didn't take the swap day
<pedronis> is he around today?
<zyga> I haven't seen him yet, let me check mail
<zyga> no mail about absence (which he carefully sends each time) so I would assume he's around
<mup> PR snapd#8251 opened: overlord: remove unneeded overlord.MockPruneInterval() mocks <Created by mvo5> <https://github.com/snapcore/snapd/pull/8251>
<zyga> so
<zyga> pedronis: env question
<zyga> pedronis: snap run --shell foo
<zyga> I guess we should apply the environment then, right?
<zyga> I guess we should
<zyga> I didn't look there deeply, just realized we do that "late" in snap-exec
<zyga> and not in snap-confine
<jdstrand> zyga: fyi, https://github.com/snapcore/snapd/pull/8241#pullrequestreview-372983889
<mup> PR #8241: interfaces: work around apparmor_parser slowness affecting uio <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8241>
<zyga> jdstrand: checking
<jdstrand> zyga: conditional ack provided one small change. while doing that, you might do: s/clariry/clarity/
<zyga> jdstrand: sure
<zyga> jdstrand: I get it, that's sensible,
<jdstrand> thanks!
 * zyga needs to apologize to everyone, school is cancelled across the country and kids got crazy and are really bothering me all the time now
<pedronis> zyga: we should apply the enviroment yes, don't we atm ?
<zyga> pedronis: I _hope_ so :)
<zyga> I'll get there soon
<zyga> pedronis: just thinking about this
<zyga> there's some discrepancy between hook and app environment
<zyga> specifically we don't perform the save-restore across setuid-lost environment
<zyga> though _perhaps_ that's okay, but there's no comment to account for why
<pedronis> zyga: as I mentioned, we should move that logic to osutil I think, though it's a bit of an orthogonal problem
<pedronis> and not something I would try in this PR
<zyga> ok
<pedronis> zyga: basically ForExec and OSEnviroment should grow flags or variants to deal with that
<zyga> mmm
<zyga> I'll stash that as a follow up, close to finishing the changes for the comments in the PR so far
<pedronis> zyga: it's relates to this comment here: https://github.com/snapcore/snapd/pull/8242#discussion_r390880508
<mup> PR #8242: many: improve environment handling, fixing duplicate entries <Bug> <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
<zyga> pedronis: so env, all but Transform is now done
<zyga> I had to invent a method name EnvStack() so please look if you like it
<zyga> in any case it's just an implementation detail and doesn't change the big picture
<zyga> I'll go after Transform and try to wrap up for today
<zyga> mvo: I'll send the paperwork tomorrow
<zyga> it's late today
<mvo> zyga: sure, see you
<cachio> mvo, quick question, I am working tieh the snapd-failover16 test which fails randomly
<cachio> mvo, I see this line Mar 11 18:36:27 localhost.localdomain systemd[1]: Started Failure handling of the snapd snap.
<cachio> but the service cant fix the dydtem
<cachio> is any other source of information to take alook why?
<mvo> cachio: hm, journalctl -u snapd.failure  should have some info
<cachio> I got that info from there
<cachio> I just see that it tries to fix it but no mere info
<mvo> cachio: oh, so it tries to fix and fails :(
<mvo> cachio: snapd and snapd.failure are the relevant sources
<cachio> mvo, right
<mvo> cachio: can you pastebin those two when the failure happens?
<cachio> mvo, snapd https://paste.ubuntu.com/p/W67D9yf7PG/
<cachio> snapd-failure https://paste.ubuntu.com/p/SxGVRzn8YH/
<cachio> mvo, it happens right after it installs the snapd broken snap
<mvo> cachio: interessting, is it random, i.e. does it sometimes work? or always failing currently?
<cachio> first time worked, and 2nd failed
<cachio> iwht this vm
<cachio> I'll run again
<mvo> cachio: so it's essentially random?
<mvo> cachio: the logs are really not giving clues, that's a bit sad
<cachio> mvo, not happening 100% of the times for sure
<cachio> but can't say if it random or not
<mvo> cachio: aha, could be another test polluting it?
<cachio> mvo, yes, but still trying to figure out that
<mvo> cachio: thanks
<zyga> pedronis: done
<zyga> mvo: if you want to get https://github.com/snapcore/snapd/pull/8242 in to 2.44 please organize some review tomorrow
<mup> PR #8242: many: improve environment handling, fixing duplicate entries <Bug> <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
<mvo> zyga: is it blocking someone
<zyga> mvo: I think it's affecting micro k8s
<mvo> zyga: ok,, I need to find out how badly
<mvo> zyga: I'm a bit worried that we delay too much
<mvo> zyga: but I will look at it tomorrow with fresh eyes and an open mind :)
<pedronis> zyga: did you change SetExpandEnv to take multiple ExpandableEnvs ?
<zyga> no
<zyga> because it's not needed now, it's just applied in chain with the same result
<zyga> have a look
<zyga> it's also simple, really just a thin wrapper to os.Expand
<zyga> I did that briefly but it was just noisier
<pedronis> ok
<pedronis> I'll look, the diff is smaller, there might be some naming stuff to tweak
<zyga> yeah, please feel free to push name tweaks directly to the PR
<zyga> I believe everything essential is addressed
<zyga> if you want it to take a list or varadic list strongly I don't mind
<pedronis> also I thought you weren't going to move the last bit to env
<zyga> which last bit?
<pedronis> (transform), that might need some tweaks as well
<zyga> I killed transform
<pedronis> I know
<zyga> and made it into a simple pair of helpers to escape/unescape
<pedronis> I know
<zyga> do you mean that this was supposed to be in ForExec() ?
<pedronis> I'm just not sure that the standalone helpers are the best way to encapsulate that
<pedronis> but I'll see
<zyga> I see
<pedronis> they really matter at the process boundary
<zyga> it's interesting because look where we escape
<zyga> (in snap/snapenv)
<zyga> and where we use that (in cmd/snap/cmd_run)
<zyga> we'd have to move that logic
<pedronis> I know, I thought exactly about that
<zyga> that's okay but that's a bigger change than just shoving a function around
<pedronis> it's unclear that is placed right in the first place
<zyga> yeah
<zyga> I think I'm too tired to give useful advice at this time
<zyga> I tried to make both uio and exec env branches good today
<zyga> and I think exec env should be re-reviewed with fresh head
<pedronis> thank you, mostly saying that it might need some small tweaks
<zyga> ack
<zyga> ok, I'll EOD now
<pedronis> that we can do, I think most pieces are there, mostly a matter how to call them
<pedronis> where they fit
<zyga> this was a good day :)
<zyga> yeah
<zyga> I think it's also interesting that we are not giving snap-confine the environment that we set in snap-exec
<zyga> perhaps we should?
<zyga> and snap-exec would not need to read that part of yaml at all
<zyga> we could really move those few lines from snap-exec to snap-run with probably, no change at all
<zyga> but perhaps that's simplistic, there's some extra interaction with non-run modes of snap-exec
<zyga> like strace/gdb and the like
<pedronis> yes, I wouldn't do that
<zyga> anyway, something to ponder over
<zyga> I think it's better than before :)
<pedronis> I fear it would need jdstrand input
<pedronis> it's a bit unclear what the consequences are
<pedronis> also with linker related stuff
<pedronis> for example
<zyga> we escape those anyway
<zyga> so linker would not see it
<pedronis> that is true
<zyga> but it's indeed interesting
<zyga> because some things might affect snap-confine (perhaps) in ways we were not expecting
<zyga> e.g. SNAP_CONFINE_DEBUG: true
<zyga> so perhaps we should document why we are not setting them outright
<zyga> snap/snapexec has some silly copying because I kept the existing structure
<pedronis> anyway that's not  a change I want to try right now :)
<zyga> but nothing terrible, it's just a few keys anyway
<zyga> yes, agreed :)
<zyga> jdstrand: FYI I'm off till the end of the week
 * zyga waves
 * jdstrand is back from meetings and reads scrollback
<jdstrand> zyga: have a nice rest of the week!
<jdstrand> I don't see anything specifically required of me but I've read the context for if a PR comes though
<mup> PR snapd#8224 closed: many: clean separation of bootenv mocking vs mock bootloader kinds  <Reviewed> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8224>
<mup> PR snapd#8252 opened: tests: Update test to make snapd snap fixed twice <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8252>
<mup> PR snapcraft#2969 closed: snap: re-add xml development packages for non x86 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2969>
<pedronis> jdstrand: I marked a new PR for you to review, not related to the env stuff, I think there are some behavior changes in the env stuff, but nothing that effects the overall security design of what we had so far
<pedronis> we set the same king of env vars from the same places, and do the same kind of mangling/unmangling of some
<jdstrand> pedronis: ok, is this urgent for 2.44?
<pedronis> jdstrand: is this one https://github.com/snapcore/snapd/pull/8249
<mup> PR #8249: interfaces: make gpio robust against not-existing gpios in /sys <Security-High> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8249>
<jdstrand> pedronis: I see, it is small
<jdstrand> ok, let me look
<jdstrand> pe
<jdstrand> meh
<jdstrand> pedronis: done
<pedronis> thanks
<mup> PR snapd#8253 opened: snap-bootstrap: expand data partition on install <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8253>
#snappy 2020-03-12
<mup> PR snapd#8254 opened: add zoommtg url support <Created by troyready> <https://github.com/snapcore/snapd/pull/8254>
<mup> PR snapd#8255 opened: cmd/snap: make the portal-info command search for the network-status interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8255>
<zyga> o/
<zyga> I'm off today
<zyga> just came to do paperwork
<zyga> push a small test to a PR
<zyga> and then disappear in a puff of smoke
<zyga> trying to organize time for kids when school is cancelled
<pstolowski> morning
<mvo> pstolowski: good morning
<zyga> mvo: I pushed an extra test to https://github.com/snapcore/snapd/pull/8241/files
<zyga> and I'll file the HR stuff now
<mup> PR #8241: interfaces: work around apparmor_parser slowness affecting uio <Bug> <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/8241>
<zyga> mvo: done
<zyga> pedronis: thank you for reviewing env changes again
<mvo> can someone please give a +1 on 8250 ? it's a straight cherry pick with tiny
<mvo> conflict
<mvo> resolved
<mup> PR snapd#7977 closed: snap: add (hidden) `snap download --indirect` option to download via snapd <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7977>
<mup> PR snapd#8197 closed: snap: refactor code in `snap download` to prepare for snap downloads via snapd <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8197>
<mup> PR snapd#8250 closed: tests: mock prune ticker in overlord tests to reduce wait times (2.44) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8250>
<ppd> hi! Has anyone had a look at https://bugs.launchpad.net/snapd/+bug/1866855 ? Debian + nvidia is broken, unfortunately.
<mup> Bug #1866855: nvidia driver integration is incompatible with Debian <snapd:New> <https://launchpad.net/bugs/1866855>
<mup> PR snapd#8256 opened: tests: disable ubuntu-16.04-32:tests/main/lxd <Created by mvo5> <https://github.com/snapcore/snapd/pull/8256>
<zyga> ppd: I can look next week. Thank you for pointing this out
<ppd> zyga: Thanks a lot. I remember there were some vague plans to ship driver libs in snaps, which could simplify the nvidia case. Or am I remembering things incorrectly?
<mvo> stgraber: did anything change recently in lxd? we see failures in our GCE lxd 16.04-32 test, inside the containter a "apt update" hangs. it tries to connect to an ipv4 address. the host system is using ipv6 to connect to archive.u.c it seems. any hints for me?
<stgraber> What version of lxd is that?
<mvo> stgraber: 3.22 but actually it could be something else, it seems like inside the container it wants to connect to archive.u.c but outside it connects to the gce apt mirror
<stgraber> Can you check 'lxc info', and look for the key firewall in there, see if it says xtables or nftables
<stgraber> We added the right bits for nft to the snap last night so maybe there's something wrong going on with that somehow
<mvo> stgraber: says nftables
<stgraber> Okay, what's the Ubuntu version used for that instance?
<mvo> stgraber: 16.04-32
<mvo> stgraber: fwiw, no connectivity inside the container it seems
<mvo> stgraber: fwiw this is what we do https://github.com/snapcore/snapd/blob/master/tests/main/lxd/task.yaml#L51
<stgraber> Okay, should hopefully be easy to reproduce here
<stgraber> Works fine on other releases?
<mvo> stgraber: yeah, afaict, also fine on 16.04-64
<mvo> stgraber: I keep the gce instance open if you have any questions (but will soon have to leave for lunch)
<mvo> stgraber: available via tg for ugent cases though
<stgraber> Hmm, 32 falling but 64 working is very very weird in this case :)
<cachio> mvo, hey
<stgraber> mvo: can you install nftables and run 'nft list ruleset' on both. Also, the output of 'iptables -L' and 'iptables -t nat -L' would be useful
<cachio> I am trying to get the shell by using systemd.debug-shell=1 in run mode when using a vm in my machine and I can't get the shell
<cmatsuoka> cachio: are you using the version with tpm enabled?
<cmatsuoka> cachio: if so, the command line is measured and it won't work if you add extra parameters
<cachio> cmatsuoka, yes,  command line: console=ttyS0 console=tty1 panic=-1 systemd.gpt_auto=0 init=/sbin/init snapd_recovery_mode=run systemd.debug-shell=1
<cachio> cmatsuoka, ahh
<cmatsuoka> cachio: you can change this by adding the parameter to the command line used when sealing the keyfile, let me see where it is in the code...
<cmatsuoka> cachio: https://github.com/cmatsuoka/snapd/blob/frankfurt-preview-tpm/cmd/snap-bootstrap/bootstrap/tpm.go#L35
<cachio> cmatsuoka, thanks
<stgraber> mvo: oh and /var/snap/lxd/common/lxd/logs/lxd.log on both systems too
<stgraber> mvo: well for this one, just the failing one may be enough
<cmatsuoka> cachio: yaw, let me know if that doesn't work
<mvo> stgraber: sorry, was at lunch and then distracted, will try to get you logs as quickly as I can
<stgraber> mvo: I think I may have it reproduced on a system here, not 100% sure though
<mvo> stgraber: ok, it takes a bit of this test to timeout so just keep me updated if you don't need it anymore
<mvo> stgraber: http://paste.ubuntu.com/p/SkPXRyVYYP/
<ackk> hi, has anyone seen an error like this: update.go:85: cannot change mount namespace according to change unmount (tmpfs /snap/maas/4977 tmpfs x-snapd.synthetic,x-snapd.needed-by=/snap/maas/4977/maas-cli/lib,mode=0755,uid=0,gid=0,x-snapd.detach 0 0): device or resource busy
<ackk>  
<mvo> ackk: I haven't, it's probably a zyga question but he is not around today unfortunately
<ackk> mvo, oh ok. I've seen it happen a few times, always when refreshing the maas snap. it seems something to do with content interfaces from maas-cli
<mvo> ackk: ok
<ackk> mvo, I'll file a bug if it happens again with details
<ackk> thanks
<mvo> ta
<stgraber> mvo: https://github.com/lxc/lxd/pull/7014
<mup> PR lxc/lxd#7014: Fix nftables issues on older kernels <Created by stgraber> <https://github.com/lxc/lxd/pull/7014>
<zyga> ackk: hey
<ackk> zyga, hi
<zyga> ackk: it's a thing I understand, I just need reliable instructions to reproduce
<zyga> I know about the fact your workflow bumps into that often
<zyga> just not sure how to reproduce and help you
<zyga> I'm off today and tomorrow
<zyga> just visited the office because it's raining and I wanted to lock the window
<zyga> and it's +16C outside, what a weird weather
<ackk> zyga, well, currently I just had "snap install maas --channel=2.7/edge", then realized I got the wrong one, and "snap refresh --edge"
<ackk> *snap refresh --edge maas
<ackk> zyga, I've seen it multple times in development too with "snap try this/" then "snap try that/"
<ackk> zyga, "maas" has a content interface with "maas-cli" which gets installed/connected automatically
<zyga> ackk: if you discard can you reproduce that with the refresh sequence?
<ackk> zyga, discard?
<zyga> ackk: sudo /usr/lib/snapd/snap-discard-ns maas
<ackk> oh
<zyga> it's essentially a wipe of the mount namespace
<ackk> zyga, you mean discard then refresh?
<ackk> zyga, I'll try it next time it happens, let you know
<zyga> ackk: discard lets you 'start over'
<zyga> if you can get a reproducer from clean slate it effectively gives you
<zyga> that's golden
<zyga> and that might imply it gets fixed quickly
<ackk> zyga, I'll try
<zyga> ackk: if you reproduce it I can look, I have two days off of roadmap items :)
<zyga> ackk: and other priority bugfixes
<ackk> zyga, thanks. I've seen it happen realtively frequently, I should be able to repro if I hit it hard enough :)
<zyga> ackk: it's okay if it requires a loop over something
<zyga> but I doubt it's that because usually this kind of issue is not a race
<zyga> unless the app is racing with something but that's odd because we freeze apps for mount ops
<ackk> zyga, this was pretty much a clean container with already-installed core18 and snapd snaps
<ackk> zyga, installed maas snap, refreshed from different channel -> error
<ackk> it's just not something that happens all the times
<zyga> mvo: is master red today?
<mvo> zyga: very
<zyga> uh?
<zyga> what happened?
<mvo> zyga: there is a PR to fix this in 8256
<mvo> zyga: but it takes some iterations so far to get it out of the reds
<zyga> not MATCH
<mvo> zyga: yes
<zyga> oh well
<zyga> I hope it goes green
<zyga> and good luck, not a fun day
<mvo> zyga: yeah, I got the wrong team from my tea shop, can't get worse than that
<pedronis> #8242 is ready for further review, sadly some of the adjustments and extra tests I added made larger again
<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>
<pedronis> *made it
<ackk> zyga, https://paste.ubuntu.com/p/FjyMT3Jnkb/
<ackk> (at first attempt)
<ackk> zyga, this is a freshly created bionic container
<mup> PR snapcraft#2970 opened: providers: match build provider flag keys to envvar <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2970>
<mup> PR snapcraft#2968 closed: git: always fetch specified source-commit before using <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2968>
<ackk> zyga, FTR: https://bugs.launchpad.net/snapd/+bug/1867193
<mup> Bug #1867193: failure refreshing snap with content interface <snapd:New> <https://launchpad.net/bugs/1867193>
<zyga> ackk: thanks
<zyga> ackk: I'll look but tomorrow
<ackk> zyga, ty
<mup> PR snapd#8256 closed: tests: fix/improve failing spread tests <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8256>
<mvo> thanks cmatsuoka !
<mup> PR snapd#8257 opened: tests: backport master test fixes <Created by mvo5> <https://github.com/snapcore/snapd/pull/8257>
<cmatsuoka> mvo: so it was a race then
<mvo> cmatsuoka: I think so
 * cmatsuoka hates races
<mvo> cmatsuoka: looks like the systemd in sid/arch is a bit slower giving journal data
<mup> PR snapd#8258 opened: interfaces/kubernetes-support: allow autobind to journald socket <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8258>
<mup> PR snapd#8259 opened: interfaces/kubernetes-support: allow autobind to journald socket - 2.44 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8259>
<mup> PR snapcraft#2873 closed: candidate testing <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2873>
<mup> PR snapcraft#2971 opened: tests: use candidate for autopkgtests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2971>
#snappy 2020-03-13
<mup> PR snapd#8260 opened: tests: enable nested on core20 and test current branch <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8260>
<pstolowski> morning
<mup> PR snapd#8257 closed: tests: backport master test fixes <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8257>
<mup> PR snapd#8241 closed: interfaces: work around apparmor_parser slowness affecting uio <Bug> <Reviewed> <Squash-merge> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8241>
<mup> PR snapd#8261 opened: interfaces: work around apparmor_parser slowness affecting uio (2.44) <Created by pedronis> <https://github.com/snapcore/snapd/pull/8261>
<pedronis> pstolowski: hi, I asked a question in #8235
<mup> PR #8235: cmd/snap-preseed: handle --reset flag <Preseeding ð> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8235>
<pstolowski> pedronis: yes, i saw it, thanks, will get to it soon
<mup> PR snapd#8255 closed: cmd/snap: make the portal-info command search for the network-status interface <Reviewed> <Created by jhenstridge> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8255>
<pedronis> pstolowski: can you look at #8248 if you have a moment, is not super urgent, OTOH is small
<mup> PR #8248: snap: introduce Container.RandomAccessFile <Created by pedronis> <https://github.com/snapcore/snapd/pull/8248>
<pstolowski> ok
<pedronis> also it relates (indirectly) to UC20 needs
<mup> PR snapd#8003 closed: o/ifacestate, api: implementation of snap disconnect --forget <Needs Samuele review> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8003>
<pedronis> pstolowski: thanks for landing that ^
<pstolowski> i'm equally happy about landing it finnaly
<pedronis> pstolowski: thansk for checking, we might do something also about fonts, but maybe we don't see changes because there are not fonts in the image?
<pstolowski> pedronis: checking
<pedronis> pstolowski: ah, no, on ubuntu the cache for those is in var  (it's in usr for some other distros)
<pstolowski> yes, that's right
<pedronis> pstolowski: it's /var/cache/fontconfig  but I'm not even sure we need to undo if we do something there, or whether we can
<pedronis> it's a cache and it's not just touched by snapd
<pstolowski> pedronis: that's right. i don't think re-running fc-cache makes any sense
<pedronis> pstolowski: yea, agreed
<pstolowski> / so yeah, spread test picked change to /usr.../completions
<pedronis> yes, that we need to fix
<pedronis> thanks for checking as I said
<pstolowski> yep, on it
 * zyga waves
<zyga> everyone at home but me has a stomach bug
<zyga> I suspect I got "lucky" because first symptoms started before I returned from Fra
<zyga> so I may be off early next week as well, depending on how the situation develops
<pstolowski> zyga: ironic..\
<zyga> right?
<alvesadrian> Hi, squashfs is read only. We are trying to make gluu snap package. As our previous experience showed that we may change any file in the snap for security or bug fixes.
<alvesadrian> Currently we trying to figure out any file/directory that gluu services want to write.
<alvesadrian> But this won't be enough for us. We may need to edit/replace any file inside the snap
<alvesadrian> We are using containers and everything is writable, when we switch to snap it will be read only
<zyga> alvesadrian: that's pretty hard to do
<zyga> alvesadrian: can you just ship a new snap revision?
<zyga> alvesadrian: everyone will update anyway
<alvesadrian> snap reivsion?
<alvesadrian> wharts that?
<zyga> alvesadrian: if you make a snap you get a blob which is the squashfs filesystem
<zyga> alvesadrian: instead of making changes to the files at runtime (application files, not data) you can just make another blob
<zyga> alvesadrian: and put that to the store
<zyga> alvesadrian: delta downloads should be fast and efficient
<zyga> alvesadrian: so instead of shipping a snap with a self-update mechanism
<zyga> alvesadrian: just upload subsequent revisions of the snap
<alvesadrian> we still playing we dont have a full app ready
<alvesadrian> we found this squashfs issue
<alvesadrian> and we are not sure how to sort it
<alvesadrian> for writeable files
<zyga> alvesadrian: my advice: disable the self-update
<alvesadrian> we dont even finish to build the app
<zyga> alvesadrian: and let snapd handle that aspect
<zyga> alvesadrian: how are you building the app?
<alvesadrian> zyga snapcrft command
<zyga> alvesadrian: when you said "we dont even finish to build the app" does that mean you still are in progress of working on the packaging?
<alvesadrian> we are playing with parts of our big app
<alvesadrian> is a java app
<zyga> I see
<alvesadrian> we are using parts to packafe it and see how it works
<alvesadrian> just a war file
<alvesadrian> with jetty
<alvesadrian> @zyga one momment a coworker is comming online
<alvesadrian> with more details
<alvesadrian> zyga : ^^^^^
<zyga> alvesadrian: I'm off today, just helping while I'm in the office
<alvesadrian> one moment
<zyga> alvesadrian: I'm afraid I won't be around much longer
<alvesadrian> please
<zyga> sure,
<zyga> just saying I can respond more slowly
<alvesadrian> slvn_ mustafa is that u?
<alvesadrian> damn
<alvesadrian> zyga this is mbaser my co worker
<alvesadrian> zyga he has some concerns
<alvesadrian> zyga can u help us?
<alvesadrian> zyga can he ask u a few things?
<alvesadrian> zyga are you still around?
<alvesadrian> mbaser drop ur concern to zyga
<zyga> just ask the questions please
<alvesadrian> mbaser are u reding us?
<alvesadrian> reading us?
<zyga> perhaps forum.snapcraft.io might be easier?
<alvesadrian> zyga no worries we can back later
<alvesadrian> zyga he is having some connection issues
<zyga> sure
<alvesadrian> thanks
<zyga> I'm online 24/7 but not always reading
<zyga> so try asking your questions and just check for answers later
<zyga> the forum is easier to use
<zyga> and better for asynchronous conversations
<pedronis> pstolowski: I made a comment in #8217
<mup> PR #8217: o/devicestate: delay the creation of mark-seeded task until asserts are loaded <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8217>
<pstolowski> pedronis: ty. updated #8235
<mup> PR #8235: cmd/snap-preseed: handle --reset flag <Preseeding ð> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8235>
<pedronis> pstolowski: thx, made a comment about the helper you are using there, it's actually a bit odd
<pstolowski> pedronis: by that you mean to fix the helper to literally match on "snapd/complete.sh" right?
<pedronis> pstolowski: to match that the end of target is like that, yes
<pstolowski> ok, makes sense
<pedronis> I mean /snapd/complete.sh
<pedronis> really
<pstolowski> right
<pedronis> I don't know why the helper is like that
<pedronis> is used in a couple of places
<pedronis> but haven't closely at them
<pstolowski> indeed, it's a bit naive
<pedronis> but I looked at the helper in dirs that makes the targets
<pedronis> and afaict they will always have snapd in them
<mup> PR snapd#8248 closed: snap: introduce Container.RandomAccessFile <UC20> <Created by pedronis> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8248>
<pedronis> cmatsuoka: thank for merging that
<cmatsuoka> pedronis: thanks for the patch, that should help moving secboot ahead
<pedronis> we'll need it for our own cross checking bits as well I think
<mup> PR snapcraft#2972 opened: [rfc] catkin plugins: remove bash workaround for old catkin bug <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2972>
<mup> PR snapcraft#2970 closed: providers: match build provider flag keys to envvar <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2970>
<pedronis> cmatsuoka: I made a maybe annoying comment in #8159, I'm just a bit unsure why we need more passes on things
<mup> PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
<cmatsuoka> pedronis: thanks, I'll check that right after lunch
<pedronis> cmatsuoka: let me know if you have questions
<pstolowski> pedronis: search v2 is in production
<mup> PR snapcraft#2973 opened: specifications: add core20 plugin specification <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2973>
<mup> PR snapd#8262 opened: interfaces/udisks2: also allow Introspection on /org/freedesktop/UDisks/** <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8262>
<mup> PR snapd#8263 opened: interfaces/udisks2: also allow Introspection on /org/freedesktop/UDisks2/** - 2.44 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8263>
<thresh> when I do snapcraft snap, would environment variables I set in my shell propagate to override-build: section in the snapcraft.yaml ?
<ackk> thresh, well if you use override-build you can just export variables as part of that. otherwise you can use build-environment (see https://snapcraft.io/docs/parts-environment-variables)
<thresh> ackk, I probably need to add some more context.  I export some variables in the CI that I would like to check when I'm doing snapcraft snap (inside the yaml, so inside the override-build).
<thresh> I guess my question is "does snapcraft snap sanitize env(1) when doing the builds?"
<ackk> thresh, AFAIK it does
<thresh> there's only one way to check. (which I'm doing right now) :-)
<thresh> ok, I think it actually works and the variable is there
<thresh> as in I can see it in "env" output when doing the build
<sergiusens> thresh: if you are in --destructive-mode or not using bases, the env should make it through
<mup> PR snapcraft#2973 closed: specifications: add core20 plugin specification <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2973>
<mup> PR snapcraft#2960 closed: specification: base plugin and plugins for core20 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2960>
<thresh> sergiusens, I'm not using destructive mode, and my snapcraft.yaml has base: core18; env makes it through
<thresh> so, eh.  I'm on snapcraft 2.43.1+18.04 (from .deb)
<sergiusens> thresh: oh, so no real support for bases then, environment should just passthrough
<thresh> sergiusens, will it change when I upgrade?
<thresh> I'm building inside (a somewhat outdated) 18.04 non-privileged docker container.
<mup> PR snapcraft#2974 opened: project_loader: use -isystem instead of -I for system include paths <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2974>
<sergiusens> thresh: if you are not using a base (in snapcraft.yaml), then I would recommend 16.04 as the container
<sergiusens> thresh: this might help with what bases are https://snapcraft.io/docs/base-snaps (but you need snapcraft 3.x)
<sergiusens> thresh: and docs on snapcraft 3.x with docker https://snapcraft.io/docs/build-on-docker
#snappy 2020-03-14
<alkisg> Hi guys, I reported LP bug #1867415 and https://forum.snapcraft.io/t/var-lib-snapd-seed-snaps-needs-400-mb-tmpfs-ram-on-live-cds/15980
<alkisg> I will stick around for a couple of days in case some developer needs more feedback, thanks
<mup> Bug #1867415: Hardlinking snaps wastes 400 MB tmpfs RAM in live CDs <snapd:New> <https://launchpad.net/bugs/1867415>
#snappy 2020-03-15
<mup> PR snapcraft#2956 closed: Add gnome 3 34 extension <Created by hellsworth> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2956>
<mup> PR snapd#8264 opened: many: introduce snapdenv to present common snapd env options <Created by pedronis> <https://github.com/snapcore/snapd/pull/8264>
<sdhd-sascha> hey, zyga, did you know, that `juju` has the same forum as snapcraft ? ( i only ask, because ... ;-) )
<RingtailedFox> i was wondering... my distro doesn't have snapd/snapcraft in its repositories.. is there a way for me to compile them from source?
<RingtailedFox> my distro is Mageia Linux, a fork of the now-dead Mandrake/Mandriva linux line
<sergiusens> Eighth_Doctor: that would be your thing, right? ^
<Eighth_Doctor> woah
<Eighth_Doctor> someone is asking about this now?
<Eighth_Doctor> for Mageia?
<Eighth_Doctor> RingtailedFox: last time I tried a few years ago, the Fedora spec file would work for building for Mageia
<RingtailedFox> there's a spec file?  where?
<Eighth_Doctor> RingtailedFox: well, the canonical one (hyuk hyuk) is at https://src.fedoraproject.org/rpms/snapd/blob/master/f/snapd.spec
<Eighth_Doctor> RingtailedFox: there's a copy for CI purposes that is slightly different in https://github.com/snapcore/snapd/blob/master/packaging/fedora/snapd.spec
