#snappy 2015-11-02
<liuxg> if my app is running on a raspberry pi, how can I get the output message like fmt.Printlin in golang? thanks.
<stgraber> Chipaca: hey, so with the new random version stuff for sideloads, how am I supposed to test framework snaps which do require predictable paths (lxd)?
<stgraber> Chipaca: it's not an option for us to have everything check the environment due to some binaries being setuid which would then give the user a trivial root escalation
<stgraber> I guess we could just always use the current symlink, I think we didn't do so initially because of some apparmor interactions, though since we're unconfined nowadays that probably doesn't matter so much
<dholbach> good morning
<zyga> good morning
<sabdfl> hi folks, who can help with some mail system and mailman debugging?
<Chipaca> stgraber: for now, use the current symlink if you really need to
<Chipaca> stgraber: wrt root escalation, i don't follow the exploit, but i haven't had your coffee yet
<Chipaca> stgraber: i mean my coffee
<Chipaca> see what i mean
<Chipaca> stgraber: if current isn't good enough, you can airgap
<Chipaca> stgraber: but that's brittle
<Chipaca> stgraber: before eoy the random versions should go away, but maybe also the versions go away from the filesystem (replaced by revisions), I don't know
<longsleep> Good morning snappy
<JamesTait> Good morning all; happy Monday, and happy Deviled Egg Day! ð
<Chipaca> this coffee smells like strawberries and cream
<Chipaca> my senses are so confused
<Chipaca> ogra_: you around?
<ogra_> pretty much, yeah :)
<Chipaca> ogra_: what's the thing that does the thing?
<Chipaca> :D
<ogra_> we call it the thing
<Chipaca> ogra_: the handling of config files changed on upgrade
<ogra_> sabdfl, mailman -> barry, mail system -> probably lamont
<ogra_> Chipaca, how
<Chipaca> ogra_: i understood you to say last week, that for individual writable /etc files, we have special magic that handles upgrades
<ogra_> right, in the initrd
<ogra_> sync_dirs() and handle_writable_paths() in /usr/share/initramfs-tools/scripts/ubuntu-core-rootfs
 * Chipaca looks
<ogra_> the prob is that we can not use that setup with /etc/writable/ because these files are usually having local changes
<Chipaca> ogra_: ah, wait, so the problem is that we don't handle local changes at all?
<ogra_> if you would blindly upgrade they would always be replaced by the defaults
<Chipaca> eep
<ogra_> so we do never upgrade the files in /etc/writable
<Chipaca> so the problem isn't /etc/writable
<Chipaca> the problem is that we don't 3-way merge
<Chipaca> at all
<ogra_> the problem is the concept
<ogra_> right
<Chipaca> and for some things, that is entirely correct
<ogra_> there isnt really a proper way to do that since we dont really have one specific syntax in configs
<Chipaca> so our problem is that for some things it isn't
<ogra_> so you would need a handler with 100s of plugins or something to handle all 3 way cases
<ogra_> right
<Chipaca> or, not expose the raw config files
<Chipaca> (which is something we want to do)
<ogra_> up to now we only used files in /etc7writable that are definitely local only config files
<Chipaca> now === 4 releases ago
<ogra_> like hostname, localtime and timezone
<ogra_> well, it is the only dir where atomic changes are possible
<Chipaca> yes, but again, the problem isn't atomic changes or not, it's the 3-way merge
<ogra_> well, not the only one, but the only one in etc
<Chipaca> so even if we drop atomic writes, we still have the problem
<ogra_> Chipaca, on the phone we have upgrade handlers in upstart jobs, so you can handle the minimal and most important caees at least ... i dont think anyone ported that part to snappy ever
<Chipaca> ogra_: and the phone doesn't do rollbacks
<ogra_> right
<Chipaca> so
<ogra_> for rollbacks you would need duplication of the files
<Chipaca> how does this sound: first, we stop exposing raw config files through config, make config more semantic (already a bug for this). Then, we store that config somewhere, and regenerate the config files from there on new core version
<ogra_> (and a still three way merge boot handler i guess)
<ogra_> *still a
<Chipaca> does that sound right?
<ogra_> well, that means you will need one handler for each config file
<Chipaca> we already do have that
<ogra_> thesy will all differ in format
<ogra_> for system configs ?
<Chipaca> but they're just stupid :) -- we need to make them smarter
<Chipaca> oh, yes
<Chipaca> here, let me link ya
<Chipaca> ogra_: https://github.com/ubuntu-core/snappy/blob/master/coreconfig/config.go
<ogra_> oh, well
<Chipaca> most of them just call get/setPassthrough, which just writes it out
<ogra_> right
<ogra_> if you want to modify content you will need a function per config file
<Chipaca> but i'd rather fix those, than write a 3-way-merge handler for each case, which i deem harder-to-impossible
<ogra_> but even tthen you would need a config file per rootfs
<Chipaca> "a config file per rootfs"?
<ogra_> unless you want to re-write them on going back and forward all the time
<ogra_> yes, you need a writable/a and a writable/b
<Chipaca> yes
<Chipaca> or rewrite them every time, yes
<ogra_> well, rather not
<Chipaca> i'm fine with either
<ogra_> so if you have writable/a|b it means you need to copy the contents during upgrade ....
<ogra_> but you dont want to copy all the payload data
<ogra_> which means the upgrade mechanism needs to become more intelligent
<ogra_> Chipaca, for the three way merge we should probably look at ucf
<Chipaca> so, on rollback/upgrade, you'd call (say), snappy internal config-regen
<ogra_> it already handles exqactly that
<Chipaca> will do
<ogra_> (and it is preinstalled)
<Chipaca> wrt config-regen, whether that happens during the install process itself (ie before reboot), or after it (during boot), that's the thing i'm not worried about
<Chipaca> ogra_: but ucf drops back to being interactive
<Chipaca> doesn't it?
<ogra_> you can avoid that
<ogra_> (and force stuff, which can indeed be risky but i dont see a way around forcing if you want to exclude interaction)
<ogra_> i would actually like to have the handling before the reboot
<ogra_> if there is a lot to handle your first boot after upgrade might be painfully slow
<ogra_> better handle it when you actually expect the upgrade to take time anyway, because you ran the upgrade command
<Chipaca> true
<Chipaca> note it'd have to be the new snappy, but that's easily doable fwiw
<Chipaca> anyway. Lots of work.
<ogra_> yep
<Chipaca> ogra_: sounds like we move forward with using /etc/writable for everything, and handle merges "soon"
<Chipaca> ogra_: is that accurate?
<ogra_> well, i'D prefer if we wouldnt use /etc/writable
<Chipaca> tell me more
<ogra_> it means that the file needs to be maintained in a far more complex way at image build time
<ogra_> /etc/system-image/writable-paths is a single one liner
<ogra_> while the livecd-rootfa handling of /etc/writable means scripting for each file
<ogra_> it was never throught as a general solution
<ogra_> but as an exception for the few files that need atomic writing in a normal ubuntu system
<Chipaca> how hard is that to fix? ie replacing the scripting-for-each-file with a general solution? maybe i can help?
 * Chipaca fetches livecd-rootfs, prepares his stomach
<ogra_> well, the fact that we make ourselves 100% depending on livecd-rootfs hacks  bothers me here
<ogra_> a new image build system will need exactly the same hacks
<ogra_> i'd really like us to get away from that instead of adding more to it
<Chipaca> ah, i hadn't understood
<Chipaca> i thought the handling of /etc/s-i/w-p was in livecd-rootfs
<ogra_> no, thats in the initrd
<Chipaca> if it's in s-i, maybe the other can be addressed there too
<ogra_> in the script above
<Chipaca> ah
<Chipaca> forgot to look at the thing that was getting that
<ogra_> (which is technically s-i client side :) )
<ogra_> it parses writable-paths and creates the mounts and all
<ogra_> (and fstab entries for the dirs that systemd should handle (everythin but /etc))
<Chipaca> ah, the problem just hit me
<Chipaca> initrd can't fix the /etc/writable usage because it can't create the symlinks
<Chipaca> dumb me
<ogra_> Chipaca, technically everything in here is a hack and shouold go away for a future build system http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/files/head:/live-build/ubuntu-core/hooks/
<ogra_> and /etc/writable is currently handled in http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-core/hooks/08-etc-writable.chroot .... the handling of /etc/default/watchdog just doubled the size of the script
<ogra_> well, we could probably teach it to
<ogra_> i,e, add a function just for handling that dir and have another table (/etc/system-image/atomic-files ) that has the link targets and filenames
<Chipaca> ogra_: you mean, initrd mounts / rw, creates symlinks, remounts ro?
<ogra_> yeah, after the sync_dirs and handle_writable_paths functions have run so that your /etc bindmount farm is already up
<ogra_> (and /etc/writable is writable)
<ogra_> it will indeed chak, if links exist it doesnt need to create them
<ogra_> thats a one time think if a new file shows up
<ogra_> *thing
<ogra_> *check
<ogra_> my go, my typing today
<ogra_> *god
 * ogra_ needs new kbd soon
<Chipaca> ogra_: fwiw every mountpoint we remove drops boot time on the bbb by .1--.2s
<Chipaca> ogra_: http://people.canonical.com/~john/bbb.svg
<Chipaca> ogra_: ( systemd-analyze plot > bbb.svg )
<ogra_> err
<ogra_> what is it doing these 17s ?
<ogra_> (i wish we had kept bootchart around, it was able to show the initrd delays )
<Chipaca> pondering the meaning of life
<Chipaca> unpacking initrd?
<ogra_> the etc mount units need to be removed
<ogra_> for 17s ?!?
<ogra_> if that takes 2s thats much
<Chipaca> just booting the kernel, afaict
<ogra_> i would like to know how much of that is actually kernel time and how much initrd
<ogra_> and what exactly in the initrd makes it so super slow
<Chipaca> ah, of course, all that is hidden in there :-(
<Chipaca> maybe initrd needs to log events some how so they show up in this?
<ogra_> what do etc-machine\x2did.mount and etc-systemd-system.mount do ?
 * Chipaca suspects he should have shown this plot to ogra_ a lot earlier
<ogra_> heh, yeah
<ogra_> 17s *before* systemd is realyl awful
<Chipaca> etc-machine\x2did.mount is the mount for /etc/machine-id
<ogra_> underneath local-fs-pre.target everything that starts with etc must go
<Chipaca> $ systemd-escape -u 'etc-machine\x2did.mount'
<Chipaca> etc/machine-id.mount
<ogra_> we are handling these from initrd already
<ogra_> ah, k, thats legit then
<Chipaca> and etc-systemd-system.mount is the /etc/systemd/system mount unit
<ogra_> right, thats already mounted
<ogra_> andthing starting with /etc from /etc/system-image/writable-paths is handled first from the initrd now ... bypassing fstab so that we have it available immediately if we switch to systemd
<ogra_> *anything
<ogra_> so the systemd usnits need to go to not duplicate that
<Chipaca> ogra_: so that's why we're getting those warnings, i'd bet
<Chipaca> i mean things like âvar-lib-snappy.mount: Directory /var/lib/snappy to mount over is not empty, mounting anyway.â
<ogra_> soo  ... 100s boot time ... 50 s are clout-init hogging the hwarware
<ogra_> no
<ogra_> thats because the readonly dir isnt empty :)
<ogra_> var gets handled by fstab
<ogra_> and the readonly dir has the original content still
<ogra_> if you get them for any /etc dir, that would be wron though
<ogra_> because that should be handled before systemd starts
<Chipaca> ogra_: http://pastebin.ubuntu.com/13081516/
<ogra_> why the heck do we create 15 ram devices ?
<ogra_> nothing uses them
<ogra_> Chipaca, yeah, all the etc- ones need to go
<Chipaca> i don't know if i should be glad you now know how to create these plots, or concerned you now have something new to obsess over :-)
<ogra_> oh, i know how to call systemd --analyze :) i just dont do it often
<Chipaca> ah, ok
<Chipaca> ogra_: also: systemd-analyze blame
<ogra_> it should be part of your tests to run systemd --analyze once on a virgin image before the testing starts
<ogra_> *our
<ogra_> well, that chart shows how bad the cloud-init impact is ... half of the boot time is eaten by it
<ogra_> cloud-init-local.service (17.575s) ....cloud-init.service (13.563s) ....cloud-config.service (10.547s) ...cloud-final.service (9.292s)
<ogra_> sums up to ~50s
<ogra_> sigh
<ogra_> i wish we could drop it and have specific cloud rootfses
<Chipaca> ogra_: we can
<Chipaca> ogra_: it's just work :)
<ogra_> generating ssh keys should be part of the upgrade ... what else does it do ?
<Chipaca> isn't cloud-init the thing copying the public key so you can ssh in on first boot?
<ogra_> you mean in --developer-mode ?
<Chipaca> yes
<ogra_> i think u-d-f copies it in place, doesnt it ?
<ogra_> it definitely generates host keys ...
<ogra_> (which takes a while and shouldnt be part of the first boot but of the upgrade procesS)
<Chipaca> udf copies the public keys to a place cloud-init picks them up from
<ogra_> only on a real first boot we shoudl generate them, but thats still faster done without cloud-init
<Chipaca> why generate host keys on upgrade?
<ogra_> ah, well, so a simple [ -e $keypath ] || cp $keypath $keytarget
<ogra_> oh, right, we dont want to change them
<ogra_> well, still i bet you can do that in less than 50s :)
<ogra_> (and in parallel while the rest of the boot runs)
<Chipaca> i thought sshd already does generate its own keys on startup
<Chipaca> not sure why cloud init is doing that at all
<ogra_> the deb does :)
<Chipaca> ah, on install?
<ogra_> from its postinst
<Chipaca> right
<ogra_> right
<ogra_> so you would have the same key everywhere
<ogra_> looking at that chart i woder who said systemd boots faster than upstart :P
<ogra_> ubuntu-snappy.grub-migrate.service (2.174s)
<ogra_> heh
<ogra_> we should omit that on non grub systems :)
<Chipaca> person 1: âsystemd boots x% faster than sysv!â  person 2..N: âsystemd boots fasterâ
<Chipaca> person N then goes on to implement 'snappy init', and the rest is history
<ogra_> haha
<ogra_> well, i really liked upstart and bootchart :)
<Chipaca> i'd expect snappy init to have a suspiciously upstart-ish feel to it :-)
<ogra_> systemd-analyze only gets me half the info bootchart did (CPU and disk utilization were most important)
<ogra_> (i.e. the graphs at the top that bootchart generates)
<ogra_> i also dont think doing fine grained ordering o funits is possible like it was in upstart
<ogra_> systemd just tries to bluntly run everything in parallel ... thats probably fine if you have an SSD, lots of  ram and CPU power ... but definitely not on low end systems
<ogra_> ... where you actually need to trade your IO and move jobs into IO gaps etc
<Chipaca> ogra_: well, there is systemd-bootchart
<ogra_> yeah, i still have to try it, it needs to live in the initrd which makes it a bit awkward to use in snappy
<ogra_> Chipaca, so our executive summary of the above: i look into moving /etc/writable handling into initrd, you look into 3 way merge integration in snappy config ?
<Chipaca> ogra_: that sounds accurate. Although my "looking into" starts with "seek approval for"
<ogra_> heh
<davidcalle> ogra_, ping
<ogra_> Chipaca, bug 1512361 for /etc/writable
<ubottu> bug 1512361 in livecd-rootfs (Ubuntu) "/etc/writable should be handled by the initrd, not by rootfs builds" [Undecided,New] https://launchpad.net/bugs/1512361
<ogra_> davidcalle, shoot
<davidcalle> ogra_, will we see the raspi2 image in http://releases.ubuntu.com/15.04/ ? Or will it stay at "http://people.canonical.com/~platform/snappy/raspberrypi2/" ?
<ogra_> davidcalle, once it is build like the others it shoudl show up in the official download space
<ogra_> *built
<davidcalle> ogra_, any eta?
<ogra_> i was hoping next stable release ... no promises though
<ogra_> i'll take care to update the linking
<davidcalle> ogra_, actual question is... can we drop the "not official" bits on https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
<ogra_> yes
<ogra_> we should still have instructions how to create a rolling image though
<davidcalle> ogra_, cool, thanks :)
<ogra_> mvo, elopio, you guys invalidated all snappy bugs in LP, i dont think we can do that, they need an upstream task and point to the github issue instead, else we cant milestone them anymore and they will vanish from all the lists
<ogra_> (i.e. they should get downstream tasks in LP)
<elopio> ogra_: that was the proposed plan, they are now in milestones in github.
<mvo> ogra_: we did ? https://bugs.launchpad.net/snappy looks pretty normal here. what am I missing?
<ogra_> elopio, that doesnt work
<ogra_> we maintain the milestone lists in LP
<ogra_> and as i understood sabdfl he wants to keep bug maintenance in LP ... so we nee downstream bugs there
<elopio> ogra_: for snapcraft at least, the plan is to maintian the milestones in github.
<ogra_> hmm, k, was that approved ?
<ogra_> for snappy releases we cant move it over unless we move all the rest too
<sabdfl> it was a valid suggestion at the time, but i have asked that we keep bug management in LP for now
<sabdfl> we can sync git to LP for bug integration, i believe
<sabdfl> i.e. bug closure through commit messages
<ogra_> right, thats what i meant with upstream tasks
<elopio> and yeah, that message about maintaining bugs in launchpad came after gustavo told us to use github bugs. Which makes sense, because the code is for closing bugs, that we couldn't relate easily if they are kept in launchpad.
<sabdfl> gustavo has the right idea of course, and i hope he'll forgive my bdfl'ing ;)
<ogra_> elopio, sure, niemeyer's concept makes sense but if we do the master management for the project in LP they need to be linked up
<elopio> anything works for me. I would prefer to file bugs only once, and to have them closer to the code.
<ogra_> since snappy is onnly one component of the snappy project here
<ogra_> elopio, thats what i meant when i started the discussion ;)
<elopio> but if the plan changes, I can revert the bugs.
<ogra_> we force ourselves into more work/duplication here
<elopio> ogra_: btw, we just did the full bug migration for snapcraft.
<sabdfl> elopio, that's what caught me by surprise, i think we're being over-enthusiastic in adoption of github
<sabdfl> your colleagues colin watson and co are working hard to add git support to LP, for example
<sabdfl> and the bug tracking in LP is considered better than GH, at least for OpenStack purposes
<ogra_> well, it is upstream bugs vs project bugs ...
<elopio> as far as I understand, the plan is to do the same for snappy, the go package. For snappy the project, related to ubuntu-core-config and stuff like that, I think we'll keep bugs in launchpad.
<ogra_> i think it is fine to maintain the snappy (tool) upstream bugs in github if desired ... but project mgmt still happens in LP
<elopio> but again, I'm just following the plan from last week.
<sabdfl> let's not confuse things more than necessary, and thank you ogra but i'll decide what's fine by me ;)
<ogra_> heh, k :)
 * ogra_ just tries to please both sides :)
<elopio> sabdfl: it made me a little sad to move away from launchpad, because I like it, it's free software and all...
<elopio> but, with a week of being in github we are already starting to get nice things, like travis and coveralls integration.
<sabdfl> that's fine for the code, enjoy
<sabdfl> and please put your happy face on for the free software and all ... ;)
<elopio> also, I think I've heard three of our external contributors saying: "yay github!"
<sabdfl> yay github
<sabdfl> can we move on please? thank you
<elopio> http://ur1.ca/o84zl ;)
<sabdfl> bazinga
<ogra_> lol
<elopio> Chipaca: plars: I got ip4 in bbb.
<ogra_> yay
<elopio> the test is running in the lab.
<plars> elopio: awesome, was there a fix that went in to intentionally correct it?
<plars> elopio: oh, no it's not... see my email :(
<plars> elopio: MAJOR outage in taipei right now I'm afaid :(
<elopio> plars: yes, Chipaca worked on it last week.
<Chipaca> week before
<elopio> plars: ok, I'll wait.
<plars> Chipaca++
<plars> elopio: it will queue up in SPI and run if/when things come back to life
<Chipaca> last week we sat around waiting for it to land on the images, which got slowed down over the move to gh
<ogra_> Chipaca, we need to make a decision what to do with interface names in rolling
<Chipaca> ogra_: why?
<ogra_> for stable we force them into being "eth0"
<ogra_> or ethX
<ogra_> in rolling we dont yet
<ogra_> (via the net.ifnames=0 cmdline option)
<ogra_> if we allow non ethX names we need to take that into account in snappy config
<Chipaca> ogra_: where do we restrict to ethX names in snappy config?
<Chipaca> i know snappy firstboot doesn't
<Chipaca> (because i wrote it :) )
<ogra_> Chipaca, in the kernel commandline we set net.ifnames=0 ... in stable only
<ogra_> which forces the old device naming scheme
<ogra_> we dont do that in rolling yet ... which means we'll end up with the new names
<Chipaca> ogra_: yes, but that's been the case since the austin sprint at least
<ogra_> (worst case a full mac address as name)
<Chipaca> we've been getting ens3 in kvm since then
<ogra_> ah, and it is handled fine ?
<ogra_> i know on arm we dont get such a friendly name
<Chipaca> to the point you didn't know :)
<Chipaca> the bbb still gets eth0 for its ethernet port
<ogra_> (at least on rpi it will be the mac)
<Chipaca> speaking of which, have you set aside a bit of time to make the bbb oem for rolling bring up the options with the right args?
<Chipaca> (or should i do it)
<ogra_> yeah, the bbb has a native NIC ... rpi has a USB one
<Chipaca> bbb has both
<ogra_> which options exactly ?
<Chipaca> gah
<Chipaca> ogra_: what was the name of the module on the bbb that made the usb connection (the one you use to charge) also be a serial port and an ethernet device and on and on?
<ogra_> oh,, that stuff !
<ogra_> cdc_acm or cdc_composite
<Chipaca> hmm, i think that wasn't it
<ogra_> acm blocks the port and claims it exclusively for serial, composite allows multi usage (serial and usbnet for example)
<Chipaca> but with that i can find it in the channel log
<ogra_> they shoudl both be there as modules
<Chipaca> g_multi
<Chipaca> sudo modprobe g_multi bcdDevice=0 cdrom=N file=/dev/mmcblk0p1 host_addr=D0:5F:B8:A3:92:81 iManufacturer=Circuitco iProduct=BeagleBoneBlack iSerialNumber=C0-3614BBBK6053 idProduct=0 idVendor=0 luns=0 nofua=Y num_buffers=2 qmult=5 removable=Y stall=N
<ogra_> (RaspberryPi2)ubuntu@rpi2:~$ find /lib/modules/ -name '*cdc*'|grep usb
<ogra_> /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/cdc_ncm.ko
<ogra_> /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/cdc_ether.ko
<ogra_> /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/cdc_eem.ko
<ogra_> /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/cdc-phonet.ko
<ogra_> /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/cdc_mbim.ko
<ogra_> /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/cdc_subset.ko
<ogra_> /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/huawei_cdc_ncm.ko
<ogra_> /lib/modules/4.2.0-1008-raspi2/kernel/drivers/usb/class/cdc-wdm.ko
<ogra_> /lib/modules/4.2.0-1008-raspi2/kernel/drivers/usb/class/cdc-acm.ko
<ogra_> (sorry for the spam)
<Chipaca> right, but this is the beebeeb
<ogra_> should be the same kernel config
<Chipaca> you're going to make me take it out and plug it in, aren't you
<Chipaca> so evil
<ogra_> haha
<ogra_> hmm, no ppisati ... i'D love to know why composite isnt enabled
<ogra_> nor serial
<ogra_> and searching for "gadget2 doesnt reveal anything either
<ogra_> *gadget
<ogra_> neither g_serial is there
<ogra_> hmpf
<ogra_> doesnt look like gadget support is enabled at all in any of our kernels
<Chipaca> ogra_: it does have cdc_ether, but loading it does nothing (and no options)
<ogra_> Chipaca, i'm happy to implement it, but i need support from the kernel team first
<Chipaca> ogra_: OTOH, g_multi brings up usb0 no problem
<ogra_> yeah, cdc_ether is the PC side ... you want g_ether
<Chipaca> ogra_: and that is what the debian it ships with does
<ogra_> or g_multi or g_composite
<Chipaca> right, so we do have g_multi, and it works as above
<Chipaca> what is missing?
<ogra_> i would assume we want that enabled in general on all devices
<Chipaca> those parameters seem to be very device-dependent, to me
<ogra_> and a snappy config option to turn it on/off
<Chipaca> even skipping the i* ones
<ogra_> g_multi is definitely a generic kernel module
<ogra_> it shoudl work on anything that has a usb host port
<ogra_> including x86 hardware
<Chipaca> *shock*
<Chipaca> ogra_: nice to know :)
<ogra_> module options are indeed device specific and should come from the device tarball
<sergiusens> Chipaca, mvo so DST explains why we missed some US folk ;-)
<ogra_> oh yeah, can we please move that meeting :)
<Chipaca> if you move it, make it at least +2h, not just +1h
<Chipaca> please :)
<ogra_> yeah
 * ogra_ likes to have it at the start or the end of the day ... currently it is an interruption in the middle of my day
<ogra_> and we force USians to realyl get up early
<Chipaca> I'm +1 to doing it at 9:30z also
<Chipaca> agreed then \o/
<Chipaca> ogra_: why is there /etc/modprobe.d/modprobe.d ?
<Chipaca> ogra_: on purpose, or is that a double-mount-oopie?
<Chipaca> oopsie*
<ogra_> loks like a bug
<Chipaca> ogra_: but the nice kind of bug
<Chipaca> like a pretty butterfly
<Chipaca> that flies past
<ogra_> heh
<Chipaca> and lands on SOMEBODY ELSE'S PLATE
<Chipaca> \o/
 * elopio upgrades to wily with one hand, and to x with the other. Fearless.
<sergiusens> Chipaca, ogra_ +2 is just at my lunch time though and a no go for mvo
<ogra_> so we want 1h ?
<Chipaca> pindonga: i haven't tried that though :)
<pindonga> Chipaca, like have both read/write from that server/
<pindonga> ?
<Chipaca> like the transmission snap listens for torrent files on a certain port
<Chipaca> or dbus endpoint
<Chipaca> or sth
 * Chipaca 's handwaving intensifies
<sergiusens> pindonga, Chipaca the other solution is maybe just put it all in the same snap? Create a product instead of just sw packages ;-)
<Chipaca> yes
<pindonga> sergiusens, so much for reusability :/
<pindonga> but ok
<sergiusens> pindonga, you reuse the sources ;-)
<sergiusens> pindonga, this is no different from how you do it on a phone
<Chipaca> ogra_: shouldn't the bbb have writable /etc/modules-load.d/<something> already?
<pindonga> on the phone I could probably use the media hub to store the files, couldn't i?
<sergiusens> pindonga, right, and reusability, why does venv exist?
<sergiusens> :-)
<pindonga> what do you mean?
<Chipaca> pindonga: he's trying to be mean
<pindonga> I meant, someone already packaged transmission, fought apparmor, etc
<pindonga> now I need to do that all over again
<pindonga> and if I wanted to use deluge instead of transmission, all over again
<sergiusens> pindonga, oh, then you want to write a content sharing framework, maybe called, content-hub ;-)
<pindonga> aka fs?
<pindonga> :)
<sergiusens> pindonga, I defer to jdstrand
 * pindonga understands the underlying reasons
<pindonga> maybe we could introduce the concept of data volumes?
<pindonga> that snaps can bind-mount or something?
<pindonga> otherwise, you'd get the same issue with a music player
<pindonga> the player would have to implement nfs/smb/whatever to get access to the files to play
<pindonga> instead of just focusing on playing those files
<ogra_> Chipaca, in stable it surely should ...
<Chipaca> ogra_: ah, this is rolling. not in rolling then?
<ogra_> might be missing there, i have to check
<Chipaca> 'ppreciated
<ogra_> add /etc/modules-load.d to writable dirs (LP: #1496419)
<ubottu> Launchpad bug 1496419 in Snappy "iptable_filter and ip6table_filter do not auto load" [High,Fix committed] https://launchpad.net/bugs/1496419
<ogra_> hmm, thats in both, wily and xenial
<ogra_> http://launchpadlibrarian.net/221767581/ubuntu-core-config_0.6.29_0.6.30.diff.gz
<ogra_> Chipaca, so rolling shoudl be fine
* You're now known as ubuntulog2
<snappy_> any1 get mir running on snappy edge?
<elopio> snappy_: tedg is working on that. The snap is not ready.
<tedg> elopio: Not me, that's a kgunn thing.
<tedg> You've confused your Texans ;-)
<tedg> Okay, I've managed to confuse myself with git.
<tedg> I made a branch "aws-iot" the updated version got pushed to the snapcraft repo, which wasn't what I wanted.
<tedg> So I'd like to now merge it into my fork of snap craft.
<tedg> How do I merge from "ubuntu-core/snapcraft/aws-iot" to "ted-gould/snapcraft/aws-iot"
<tedg> I feel like Github is obfuscating Git who wasn't clear to begin with.
<ogra_> just bzr merge ... oh, wait ... :P
<tedg> I do find the "you've got the whole repo" thing confusing. Not sure why they did that.
<sergiusens> mvo, is there a way to know before hand what apt.Cache.fetch_archives will fetch?
<sergiusens> tedg, git push to the correct remote
<sergiusens> tedg, git remote add sergiusens git@github.com:sergiusens/snapcraft.git
<sergiusens> tedg, git remote add ted git@github.com:tedgould/snapcraft.git
<tedg> sergiusens: I don't want to push, I want to update my branch, I need to pull?
<sergiusens> tedg, git push ted
<sergiusens> tedg, with what is in the upstream repo?
<tedg> sergiusens: yes
<tedg> Specifically the aws-iot branch
<sergiusens> tedg, git fetch origin; git merge [origin/branch] (or something like that)
<sergiusens> tedg, I knew I gave you 'write' too early ;-)
<tedg> That's what I can't figure out :-) The syntax for branches on remotes.
<tedg> Heh, yes!
<sergiusens> tedg, all your branches are in ubuntu-core instead of 'ted'
<sergiusens> tedg, https://github.com/ubuntu-core/snapcraft/branches
<snappy_> Chipaca: do you have mir working w/ spice?
<mvo> sergiusens: sort of but not really as it depends on the server, in apt experiemtnal this is better. I need to leave for hockey, but we can talk later or tomorrow
<tedg> sergiusens: No, some are.
<Chipaca> snappy_: me, personally? i haven't checked in ages
<tedg> snappy_: Yeah, I do.
<snappy_> tedg: Chipaca: what changes do I need to make to get mir running w/ spice in kvm?
<snappy_> tedg: Chipaca: is there a tutorial anywhere?
<Chipaca> snappy_: use virt-manager, set video driver to "spice"
<snappy_> Chipaca: when i run clocks demo, I get an 'connection to Mir server failed' error
<Chipaca> snappy_: do you get a black screen and a pointer?
<snappy_> Chipaca: no.  nothing shows after i install mir
<Chipaca> snappy_: running with virt-manager, using the spice video driver thing?
<snappy_> Chipaca: hm.  I was starting using kvm command in terminal.  I'll try virt-manager. thx
<Chipaca> snappy_: all virt-manager does, supposedly, is set options on kvm. But I gave up trying to use kvm directly for this.
<tedg> Yeah, no tutorial I know of, but virt-manager usage.
<tedg> QXL as well.
<tedg> Okay, I got the branch, now I can't push :-(
<tedg> Git makes me sad
<ogra_> until you understand it ... then bzr makes you sad it seems
<ogra_> (at least thats what i see from others :) )
<tedg> Others make me sad
<ogra_> lol
<sergiusens> mvo, sure, go ahead; I was looking into using a common download location for each part, but I need to keep track of what go downloaded
<sergiusens> if context helps :-)
<snappy_> Chipaca: I dont see the black screen and pointer on virt-manager with spice server.  Any suggestions?
<Chipaca> snappy_: check the mir service log
<snappy_> Chipaca:  ubuntu-core-launcher mir_demo_server: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by mir_demo_server)
<Chipaca> snappy_: there ya go then
<snappy_> Chipaca: it works in older version of snappy.  Do I need to add lib to snap?
<Chipaca> tedg: wasn't there a lovely libc abi breakage in ~wily?
<snappy_> Chipaca: how to fix?
<tedg> Chipaca: Not libc, libstdc++
<tedg> snappy_: You probably want to build with either vivid or remove libstdc++ from the blocked list.
<tedg> We need to revise that in snapcraft
<tedg> In the end, you want to be carrying your own version of libstdc++
<snappy_> tedg: chipaca: ok thanks.  How do i remove from blocked list?  If i build in vivid, do I need to compile mir.snap ?
<Chipaca> snappy_: what're you building in vivid?
<snappy_> Chipaca: libstdc++
<Chipaca> snappy_: why would you do that?
<ogra_> to ship the binary in the snap
<ogra_> though i guess you could just use the deb one in LD_LIBRARY_PATH
<Chipaca> but then they'd have to ship libc also
<Chipaca> and libnss
<Chipaca> the whole thing
<ogra_> yep
<ogra_> we'll need that anyway :)
<ogra_> as snapcraft setup
<snappy_> Chipaca:  do u know an easier way?
<snappy_> Chipaca: to get mir?
<Chipaca> snappy_: you've got the mir snap, right?
<Chipaca> snappy_: and it's not working because the libc++ abi in your snappy system is different from the abi of the package
<Chipaca> snappy_: that's a problem you _shouldn't_ have, but you do; apologies
<davmor2> Chipaca: there were incompatible gcc in wily, between 4.7 in vivid and 5.x in wily if that is the abi break you are on about
<Chipaca> snappy_: have you tried a different version snappy system? I haven't looked into this at all, but maybe it'll work in 15.04?
<Chipaca> snappy_: or if you're in 15.04, maybe rolling works?
<Chipaca> i know tedg has been working with mir and hasn't mentioned this problem
<snappy_> Chipaca: hmm.... ill try and see if i can get a different result thx
<snappy_> Chipaca: I was able to get a different version of mir to work!
<Chipaca> snappy_: there are different versions?
<Chipaca> packaged i mean?
<snappy_> Chipaca: no... i compiled one
<Chipaca> ah!
<Chipaca> heh
<snappy_> Chipaca: how do I fix socket configuration for clocks example?
<snappy_> Chipaca: thx for help
<tedg> Vivd should be find as long as you're using the 15.04 snappy.
<kyrofa> Can ubuntu-device-flash be used to preload the image with snaps?
<kyrofa> (or is there another way to do that?)
<tedg> In theory that's what the gadget snap should do.
<tedg> It should define which are the preloaded ones.
<kyrofa> Ah, cool okay
<kyrofa> tedg, does that actually include the specified snaps, or install them after deployment?
<tedg> kyrofa: Not sure.
<snappy_> Chipaca: To get socket working w/ snap, how to fix?
#snappy 2015-11-03
<fgimenez> good morning
<Sam_> First time to be here, hello everyone.
<clobrano> good morning
<clobrano> is there any snap available for the network manager?
<JamesTait> Good morning all; happy Tuesday, and happy Sandwich Day! ð
<mvo> jdstrand: I started with the snappy policygen --compare branch, just a quick question about apparmor_profile - p - I understand that I need to take the old policy, write the new policy to a tempfile and then run both of them via apparmor_profile -p and compare if they are still identical?
<balloons> elopio, fgimenez all ready for http://summit.ubuntu.com/uos-1511/meeting/22623/testing-snappy/?
<elopio> balloons: all ready.
<fgimenez> balloons, elopio yep, ready :)
<balloons> elopio, fgimenez and you know how to setup the hangout and everything right
<elopio> balloons: yes, no problem with that.
<balloons> brillant
<mvo> jdstrand: I looked at apparmor_parser -p again and I think I need a hand. it seems in order for this to work I would have to store something (hash?) of the flattended profile at profile generation time. and then compare the stored hash with a hash of apparmor_profile -p tmp_new_profile (?)
<ogra_> http://summit.ubuntu.com/uos-1511/meeting/22623/testing-snappy/ will soon be  on air ....
<jdstrand> mvo: re apparmor_parser -p, yes you are right. I don't think we want to do anything expensive though-- perhaps just apparmor_parser -p after install and save that off somewhere, then we can do a diff /saved/off /tmp/new || updateStuff
<jdstrand> mvo: we should probably think about that a bit
<mvo> jdstrand: ok, easy enough to add later I assume
<jdstrand> mvo: well, yes and no. we have to deal with the apparmor package updates that have changes to the abstractions.
<jdstrand> we could just unconditionally invalidate everything
<jdstrand> which is basically what happens now, but that has always been a pain point
<mvo> jdstrand: I mean we can add it later this week :)
<jdstrand> ah
<jdstrand> yes
<jdstrand> mvo: fyi, I looked at your first patch yesterday and I thought it looked good. I didn't do more than read it yet
<mvo> jdstrand: or next week, I mean when you have time to guide me
<jdstrand> mvo: the main thing is I want it clean and it needs to be a cheap check
<jdstrand> mvo: on personal people easily have 100 profiles
<jdstrand> mvo: but, we do have a cheap check by storing off the version-- if the version didn't change, avoid everything
<jdstrand> if it did change, then we try the regenerated policy, then if that is the same, try the -p
<mvo> jdstrand: hm, what exactly is "version"?
<mvo> in this context
<mvo> jdstrand: tell me if you don't have time, we can talk later of course
<jdstrand> mvo: sorry, I got pulled away. in a meeting now, but will respond
<mvo> jdstrand: thanks
<jdstrand> mvo: cheap check for storing off the version> I was talking about in the card where I talk about saving the version of apparmor and ubuntu-core-security* that are installed
<jdstrand> mvo: if none of them change, do nothing
<mvo> jdstrand: I pushed a --regenerate-all branch now too, some feedbcak would be great, need to add some tests, then it should be good to know and I'm keen to hear what is missing before we can replace the current aa-clickhook
<mvo> jdstrand: aha, storing the package versions? that makes sense
<jdstrand> mvo: if they do change, do the --compare
<jdstrand> mvo: and then update the 'versions file'
<mvo> jdstrand: I thought we would do the --regenerate-all on each boot, no?
<jdstrand> mvo: well, it depends on what it does. these things can affect boot speed and we have a number of checks today to not affect boot speed unless we have to
<jdstrand> mvo: so I didn't want to regress on that
<jdstrand> mvo: without looking at your branch, if it were smart enough, '--regenerate-all --compare' could be done on every boot
<mvo> jdstrand: right, so it will create a temp profile for each snap, cmpare with the installed one and re-generate for real if they are different
<jdstrand> mvo: right
<mvo> not sure how slow that is though
<jdstrand> mvo: we need to be thinking about potentially hundreds of profiles
<jdstrand> mvo: which is why I wanted that cheap check too
<jdstrand> mvo: only run --regenerate-all --compare only if the system policy changed
<mvo> jdstrand: right, so i can add this and only call --regen is the versions of apparmor and ubuntu-core-security** change
<jdstrand> that sounds good
<mvo> jdstrand: that is what you mean I assume?
<mvo> jdstrand: cool, I will work on this next
<jdstrand> mvo: btw, thanks you so much for helping out with all this :)
<mvo> jdstrand: oh, thank you! and I can't wait to hear what else is missing before we can enter the brave-new-world
<jdstrand> mvo: I'm finding it difficult to review these in a timely fashion between the sprint and UOS, but know I will get to it :)
<jdstrand> mvo: (or put another way, the patches are coming in faster than I can review them atm, but I will get to them :)
<mvo> jdstrand: no worries, I know how it is
<mvo> jdstrand: even tiny reviews (like general direction looks valid) are useful. or your suggestion to use the version-compare to speed stuff up. and of course what else is missing :)
<mvo> jdstrand: I can ask other people like Chipaca (sorry!) to do the in-depth code review
<jdstrand> mvo: ok, cool. keep firing questions at me and I'll respond as quickly as I can :)
<mvo> jdstrand: anyway, I get dinner now, thanks for your help and keep me updated about your findings
<ricmm> mm
<jdstrand> mvo: unfortunately I had a meeting conflict with the frameworks UOS session
<tedg> mterry: we were talking a bit about manifest.txt and the packages in there, where is that list from? Just the ubuntu-core packages?
<tedg> We were thinking it made sense to reduce the set some.
<tedg> Specifically to drop libstdc++, but perhaps others as well.
<ogra_> tedg, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ ?
<tedg> ogra_: very close: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/manifest.txt
<ogra_> heh
<tedg> mterry: Not sure if you saw my ping (or were trying to avoid it ;-) )
<mterry> tedg, no I didn't see it!
<tedg> mterry: we were talking a bit about manifest.txt and the packages in there, where is that list from? Just the ubuntu-core packages?
<tedg> We were thinking it made sense to reduce the set some.
<tedg> Specifically to drop libstdc++, but perhaps others as well.
<mterry> tedg, you're talking in terms of deb2snap?
<tedg> mterry: Initially, but today snapcraft: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/manifest.txt
<mterry> tedg, my IRC connection is crap today.  "you're talking in terms of deb2snap?"
<tedg> mterry: Initially, but today snapcraft: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/manifest.txt
<mterry> tedg, oh yeah!  That was just a copy of ubuntu-core at the time.  It was a shortcut to a more dynamic solution
<tedg> mterry: Do you have a specific reason for particular packages?
<mterry> tedg, I don't *think* I edited the list
<tedg> mterry: Okay, we didn't know how much experience and pain was involved :-)
<mterry> tedg, no, and my intent was eventually to make it targetted (like if snapcraft can say "make me a snap for 15.04" we'd get the manifest for 15.04).  But yeah, short term I just copied the manifest.txt
<tedg> mterry: I think that long term it shouldn't matter, the only thing you pull in is bash and libc, eh?
<mterry> tedg, well if my snap uses libudev1 and snappy 16.10 uses libudev2, snapcraft needs to know that it can't depend on it from the system anymore and bundle it
<mterry> (or just build for libudev2)
<mterry> (or just always bundle it)
<tedg> mterry: I think we want it to bundle always
<tedg> Yeah
<mterry> tedg, OK then you want to probably modify manifest.txt to the actual promised "always-there" libraries that Snappy promises
<tedg> mterry: Okay, I don't think we've explicitly said which, but I think generally it's "not much"
<mterry> tedg, which is not something I was aware we had a list of -- what sort of promises we make to snaps
<tedg> The one that is killing today is the GCC migration.
<tedg> For C++
<mterry> tedg, well exactly -- even stuff we would have though would never change sometimes change  :)
<tedg> elopio: is there a way to build all the examples?
<tedg> (in snapcraft)
<asac> stgraber: i vaguely recall seeing a busybox image you put out when I tested lxd ... do you have pointer to that again? how is that build?
<stgraber> lxd-images import busybox --alias busybox
<stgraber> assuming that you do have the busybox binary on your system as it builds it from your local system
<ogra_> that will likely only get you the initramfs busybox
<ogra_> (which is cut down)
<stgraber> it's looking for /bin/busybox specifically so if it doesn't exist, it'll fail to create the busybox image
<stgraber> note that we only really have this for our own testsuite's use and it's going away in 16.04, so not something we really support (busybox hardly counts as a Linux distro) :)
<ogra_> oh, i know embedded people that would disagree with that statement :)
<stgraber> I guess you can turn it into some kind of distro with a fair amount of shell script added on top, but with just the busybox binary, you get a mostly broken init system (doesn't handle all signals properly) which doesn't even bring up network for you
<asac> stgraber: oh... thought you had an image for download
<stgraber> nah, busybox is specifically used in environments where we can't download stuff or where we shouldn't (our testsuite)
<asac> hmm. lxd wasnt SRUed to 14.04 yet it seems :)
<ogra_> yeah, i noticed that today too :(
<asac> hah ... so i am not alone running LTS :)
<ogra_> my desktop always runs lts ... my laptop always latest release
<stgraber> it's in backports
<stgraber> apt-get -t trusty-backports install lxd
<ogra_> who uses that !
<ogra_> :)
<asac> yeah thats kind of same as ppa
<asac> does it work on 3.13?
<stgraber> it does
<ogra_> sigh ... i wasted my whole day trying to get live-build to behave
<ogra_> another build failure and i'm out of ideas
<asac> ogra_: its not wasted... now you know what you tried did not work :)
<ogra_> asac, i'm poking in the dark here
<asac> ogra_: do you have a busybox image? :)
<ogra_> if i do exactly the same steps in a local chroot everything is fine ... if i run them under live-build the env is somehow so garbled up that the kernel package doesnt generate its initrd
<ogra_> asac, heh, no
<ogra_> stgraber, what do you use for these lxd images ?
<ogra_> to create them i mean
<stgraber> ogra_: "import ubuntu" uses cloud images. "import busybox" just takes your local busybox and dumps it into a tarball along with a few symlinks
<ogra_> and how are these cloud images created ?
 * ogra_ is desparately looking for a way away from live-build ... its such a pain
<ogra_> oh man !
 * ogra_ slaps forehead
<elopio> tedg: the examples plainbox suite is doing that. But in the end is a for calling snapcraft build on each dir.
<tedg> elopio: Oh, I just added a shell script
<tedg> https://github.com/ubuntu-core/snapcraft/pull/74/files
<elopio> tedg: that might be useful.
<elopio> tedg: Take a look at ./runtests.sh plainbox examples
<tedg> elopio: Ah, basically the same thing.
<tedg> I like to say mine thinks outside the box though ;-)
<elopio> tedg: of course, yours is unique and special ;)
#snappy 2015-11-04
<Sam_> Hi
 * Guest42341 such a beautiful day, today. great for science and such
<liuxg_> where can find the output messages from a running snappy app? thanks
<fgimenez> good morning
<kgunn> stgraber: ping
<mvo_> ogra_: you may need to rebase your livecd-rootfs ppa changes with my latest upload (should be trivial though)
<ogra_> mvo_, will do (i hope i get done today, implementing this is hell ... (our chroot is so messed up after build due to removing half the packaging system))
<JamesTait> Good morning all; happy Wednesday, and happy Stress Awareness Day! ð
<tedg> Oh man, I didn't send out stress awareness day cards. Now I'm stressed about it, but at least aware.
<mcphail> Hi. Do we have a target date for the phone to transition to snappy?
<mvo_> jdstrand: hey, just fyi - https://github.com/ubuntu-core/snappy/pull/55 is up mostly to get input from Chipaca but you are welcome to look/comment/reply of course
<jdstrand> mvo_: ack, thanks
<tedg> mcphail: No, there isn't a date set yet.
<elopio> fgimenez: do you think subunit Status should return the number of bytes written?
<fgimenez> elopio, doesn't feel quite well, maybe we could get rid of all the writer stuff
<fgimenez> elopio, i think that the only useful part now is the multiwriter
<elopio> fgimenez: I agree. Your pipes structure was cool, but now I don't find a use for it.
<elopio> but before I get rid of it, I want to make sure that we would be able to put this subunit module in gocheck.
<elopio> maybe I'll try that first before doing anything crazy on our branch.
<fgimenez> elopio, ok makes sense
<mcphail> tedg: thanks
<stgraber> kgunn: pong
<snappy_> getting a "UbuntuClientIntegration: connection to Mir server failed" error when trying to run mir app.
<snappy_> any1 else run into this issue?
<mvo_> jdstrand: I added the check for changes in "apparmor, ubuntu-core-security-*" around the snappy policygen --regenerate-all now, do you happen to remember if anything else is missing featurewise?
<sergiusens> mvo_, is there a way to setup APT::Install-Recommends false using python3-apt?
<mvo_> sergiusens: yes, apt.apt_pkg.config.set("apt::install-recommends", "false")
<sergiusens> mvo_, neat
<mvo_> python-apt is quite good :)
<sergiusens> mvo_, it is :-)
<sergiusens> mvo_, btw, did you figure out my question from the other day?
<mvo_> sergiusens: uh, what was the question? about apt update files? sorry, I forgot again, could you help me?
<sergiusens> mvo_, about having .fetch_archives tell me what it downloaded
<sergiusens> or what it is about to download
<sergiusens> mvo_, either is fine
<mvo_> sergiusens: aha, so there is definitely a list of the urls in the acquire system, I just need to have a look how to access it
<sergiusens> mvo_, great, this will allow me to download once per project if multiple parts require the same deb
<mvo_> sergiusens: ok, so the best way is to create a "fetcher" via apt_pkg.Acquire(progress) and with fetch.list you can iterate over the list of items that got downloaded
<mvo_> sergiusens: oh, if that is your use-case just use a common download dir
<mvo_> sergiusens: apt will re-use existing debs, i.e. not fetch them again
<sergiusens> mvo_, oh, but I need to unpack each to its own private location
<sergiusens> mvo_, unless I just download once and unpack into the stage area and forget about putting it in part.installdir
<mvo_> sergiusens: right, unpack them to any location, just keep the apt.Cache(rootdir=./something) to the same "something" for all parts
<sergiusens> also a possibility; then we get the same phantom dep bugs as in debian packaging when using multiple parts masking missed deps :-)
<mvo_> sergiusens: i.e. just keep the debs and the list in the same dir, unpack and handle in whatever way yu want
<mvo_> sergiusens: well, you can of course iterate over a fetcher.items, each item will have a uri and a description
<sergiusens> mvo_, ok, I'll look into it
<mvo_> sergiusens: I will be off a bit, but just mail me any questions
<mvo_> sergiusens: or telegram
<sergiusens> thanks
<jerryG> Chipaca: what changes need to be made to get sockets working with freerdp?
<Chipaca> jerryG: I don't know; what isn't working?
<jerryG> Chipaca: pastebin.com/ZvU8yFgL
<Chipaca> jerryG: oooh, nice :)
<Chipaca> jerryG: so, first, figure out what system call is being blocekd
<Chipaca> blocked*
<Chipaca> second, have your wrapper script set XKB_CONFIG_ROOT so it finds the xkb bits, if you need them
<Chipaca> jerryG: but your first problem is that system call, clearly
<Chipaca> jerryG: so. sc-logresolve is probably what you want. Or sudo journalctl | grep -i audit
<Chipaca> jerryG: where do sockets come into it?
<Chipaca> jerryG: also, do you need sudo?
<tedg> zyga: I'm trying to run a single plainbox test in Snapcraft, do you know how to do that?
<zyga> tedg: yes, one sec
<zyga> tedg: have you seen ...
<zyga> tedg: https://code.launchpad.net/~zyga/snapcraft/plainbox-app
<zyga> tedg: (I need to return to that soon)
<zyga> tedg: this allows you to do all of that
<tedg> zyga: So I can't do it today?
<zyga> tedg: with that example you can, with the current code it is also doable, just uglier
<zyga> one sec
<tedg> Why do we have all these custom wrappers? Feels weird this functionality isn't just provided as part of plainbox.
<tedg> We shouldn't have code to support running the tool :-/
<zyga> tedg: because it was written against old version that was in the archive
<sergiusens> zyga, since you are here, can we have 'silent mode unless errors' for plainbox commands spitting output?
<zyga> sergiusens: I believe exactly that is implemented in the branch above
<zyga> tedg: plainbox is primarily a library and now it's very easy to create all kinds of tailored tools on top
<zyga> tedg: like the one I wrote there
<zyga> sergiusens: it runs tests and shows the error for each failing test
<zyga> tedg: plainbox run -i regexp-matching-test-id
<zyga> tedg: that runs a single thing
<zyga> tedg: in integration_tests/runtests.sh you can see we call plainbox run -T $test_plan
<zyga> tedg: you can run plainbox run -i blah manually
<zyga> tedg: for quick testing that's actually pretty useful
<zyga> tedg: you can run manage.py develop
<zyga> tedg: then all of the snapcraft integration test cases are available directly
<zyga> tedg: plainbox run -i test_id
<tedg> zyga: Can you give me an example, that wasn't working for me.
<zyga> tedg: sure, let's see
<zyga> tedg: eh :)
<zyga> tedg:  SNAPCRAFT=snapcraft plainbox run -i 2015.com.canonical.snapcraft::snapcraft/normal/bzr-tag
<zyga> tedg: everything failed because $SNAPCRAFT was unset, it is set by the wrapper script
<zyga> tedg: I think scripts could just default to ${SNAPCRAFT:-snapcraft}
<zyga> tedg: or really make it always snapcraft and rely on PATH being set
<zyga> tedg: but that's just script design
<zyga> tedg: that worked for me _after_ I ran "./manage.py develop" to register the snapcraft integration testing tests with plainbox
<zyga> tedg: actually running a provider "from source" is one of the last snapcraft driven APIs that I haven't improved, I have a branch for that but I haven't worked on it since holidays (overloaded with other stuff)
<zyga> tedg: there's a branch that adds a provider unit so that manage.py becomes obsolete (apart from being a convenience for running stuff interactively)
<zyga> tedg: and then plainbox run could take a path to the provider as an argument, to let it just run without any extra setup
<tedg> Okay, I think that I was missing the ./manage.py develop step
<zyga> tedg: and anther, unrelated, branch that adds environment units so that a job can sensibly depend on an environment variable and things like unset SNAPCRAFT won't have bad UX
<tedg> I seem to get a test now.
<zyga> tedg: I will return to them after I settle down in the snappy core team and start feeling some free time on Fridays
<tedg> The test fails, but at least it runs :-)
<zyga> tedg: hehe :)
<zyga> stuff I've mentioned is in https://code.launchpad.net/~zyga/checkbox/config-units
<zyga> and in https://code.launchpad.net/~zyga/checkbox/provider-unit
<zyga> sergiusens: can you confirm my assertion
<zyga> sergiusens: if there is something to actually do there I'd love to know
<sergiusens> zyga, how far back do I have to read? I am all for not needing manage.py
<zyga> sergiusens: just about the interactive output on error thing you asked about
<sergiusens> zyga, if it is already there, that's fine; I recall it from Budapest now
<sergiusens> zyga, ideally it would live in trunk/master ;-)
<zyga> ::)
<zyga> sergiusens: yeah, belive me, I wish I had 34 hours, not 24
<zyga> sergiusens: catching up with family, checkbox, snappy and UOS now
<zyga> sergiusens: and $commercial_project
<zyga> sergiusens: fun
<jerryG> Chipaca: no.  I don't need sudo to reproduce error.  DO u want me to send you journalctl output?
<jerryG> Chipaca: sockets are used to connect w/ remote host
#snappy 2015-11-05
<Sam_> Hi
<Sam_> I am trying to build the Snappy Ubuntu Core amd64 image, does any of you have experience to this ?
<fgimenez> good morning
<longsleep> ogra_: Hey, can you point me to some infos how you folks build the raspi2_armhf system-image channel? Is that created by the system-image or is there a cdimage somewhere for rpi2?
<JamesTait> Good morning all; happy Gunpowder Day, and happy Men Make Dinner Day (totally unrelated)! ð
<woodrowshen> hi all, i just quickly ask a problem, snapcraft will happen errors when the snapcraft.yaml only set the field of seccomp for security policy.
<woodrowshen> is it a abnormal rule i used or limitation ?
<Chipaca> hah! http://dave.cheney.net/2015/11/05/lets-talk-about-logging
 * Chipaca points out snappy's logger.Logger interface has exactly two methods :-)
<mvo_> Chipaca: I saw that too and I much agree, want debug in standard logger and be happy
<Chipaca> one for things the user should see, one for debugging
<Chipaca> even documented as such :-)
<mvo_> yep
<Chipaca> so we went with Notice instead of Info, because we're awkward with names or something :-)
<Chipaca> anyway. need to take a break from sending hard emails.
<Chipaca> willpower running low :-)
<Chipaca> stgraber: ping
<Chipaca> stgraber: is there an lxd image manifest anywhere? (is that a thing?)
<mvo_> stgraber: and how is it (lxd image) build currently? is the script for that available somewhere
<Chipaca> I got to https://images.linuxcontainers.org:8443/images/ubuntu/wily/amd64/default/20151105_03:49/
<Chipaca> but no manifest nor nothing
<dholbach> Day 3 of UOS starting in about 20 minutes: http://summit.ubuntu.com/uos-1511/2015-11-05/
<clobrano> \0/
<ogra_> no way !
<ogra_> and tons of snappy topics today too !
<dholbach> yeppers :)
<stgraber> mvo_, Chipaca: the images on images.linuxcontainers.org are auto-generated images from the lxc-* template scripts we have in LXC, those are generated daily on https://jenkins.linuxcontainers.org using the scipts at github.com/lxc/lxc-ci, no manifest content is published (we could add that though)
<stgraber> mvo_, Chipaca: the recommended Ubuntu LXD images are those you get by doing "lxd-images import ubuntu --alias ubuntu" or "lxd-images import ubuntu wily --alias ubuntu-dev", ...
<stgraber> those are cloud images and their manifest is published at https://cloud-images.ubuntu.com
<stgraber> LXD uses the root.tar.xz images combined with the lxd.tar.xz metadata tarball
<Chipaca> stgraber: ah, then i think it's the latter i need for this
<stgraber> the lxd-images command will go away in 16.04 in favor of simplestream support directly in LXD, at which point you'll get things like "lxc launch ubuntu:lts my-container" and that will just work straight after installation, the image will be cached for you and kept up to date behind the scene
<ali1234> so what exactly does a snapcraft plugin do?
<ogra_> ali1234, everything to build a snap with a specific build tool ...
<ogra_> i.e. we have a cmake plugin that allows you to define the github tree for some cmake using source and then call snapcraft build to generate a snap for you
<tedg> elopio: Can we ask coveralls to only fail if the coverage goes down by like a half percent or something? There seems to be a lot of noise there.
<ali1234> i'm looking at my github right now and actually there is quite a few things on here that could be packaged with snappy i suspect
<ali1234> and also a few that just don't make any sense at all
<elopio> tedg: I will check. But I like the noise, it will make you add an autotools test when you get really tired of it.
<tedg> elopio: Sure, but I have an MR that gets an "x" because coveralls thinks it decreased by 0.03%
<elopio> tedg: yes, it's possible, but I'm not an owner of the repo.
<elopio> there's a notifications tab.
<tedg> Hmm, okay. I'll look.
<elopio> oh wait, I think it's possible, but the screenshot doesn't show the full controls.
<longsleep> ogra_: quick question, when building the raspi2 image with u-d-f how do you make it select the raspi2_armhf device channel, using the --device parameter?
<ogra_> longsleep, right
<longsleep> ogra_: ok, i was wondering if i should care that this option is listed as deprectated
<ogra_> longsleep, we need to drop this warning i guess ... even though sergiusens will cry :)
<longsleep> ogra_: ok cool, i finally had time to try out my own system image server and hat to use this parameter to make it use the odroidc channel
<longsleep> Another question, when you build ubuntu-core preinstalled images, does the stable line also build with ppa:snappy-dev/image ? Docs in the ppa say its only used in edge.
<ogra_> after 15.04 release we started using the PPA there too for fixes
<ogra_> (the SRU turnaround time is sometimes to slow so the PPA is used as staging area for this)
<longsleep> ogra_: ok, so the ppa is required currently to build 15.04 snappy images - correct?
<ogra_> right
<longsleep> ogra_: ok, thanks for confirming
<ogra_> but why would you do that at all
<ogra_> just make your s-i server import the one from the ubuntu s-i server
<ogra_> and only provide your own device tarball
<longsleep> ogra_: yeah i have that now, but now i need to change some things in the ubuntu-core rootfs
<longsleep> ogra_: can i do this with the system-image server?
<ogra_> eeek !
<ogra_> only if you set up your own build env
<longsleep> ogra_: i am trying to avoid it still - experimenting with it
<ogra_> which is rather very complex
<longsleep> ogra_: i got that as well, i mean i can build the rootfs with cdimage and all
<ogra_> yeah, but you really shouldnt
<longsleep> ogra_: but it tages ages and that cdimage scripting has soooo many features
<ogra_> especially in the light that system-image is going away soon
<ogra_> and you will have an OS snap that contains the rootfs
<longsleep> ogra_: yeah - but still, i need to be able to modify the rootfs - add own key ring for example
<longsleep> ogra_: i have not completely understood all aspects of the system-image server scripts - maybe that one can incorporate some overlay tarball on top of the pulled upstream rootfs
<ogra_> not sure thats supported in snappy, the overlay thing is for the vendor tarball on phones
<ogra_> in snappy you would have an additional snap in the store that your oem snap pulls in
<longsleep> ogra_: ok - but how can that overwrite stuff which is part of the rootfs?
<ogra_> it cant on snappy
<ogra_> and on the phone it doesnt do that either, it installs to rw space and gets linked/bind mounted
<longsleep> ogra_: well that would be fine with me too
<ogra_> (or the apps simply get changed to read fro the overlay location)
<ogra_> it isnt a concept to use in snappy
<ogra_> it wont work
<longsleep> understood, thats why i currently have to modify the rootfs / build my own rootfs
<ogra_> what do you change ?
<longsleep> update without internet connection from own url for example, replace openssl with libressl, change client.ini to use own system image server
<longsleep> i am pretty sure there is more to come
<longsleep> btw, the client.ini might actually be a bug, or might not be used at all by snappy tool - to sure but when installed from another system image server, only default.ini has the custom server and snappy update fetches stuff from system-image.ubuntu.com (configured in client.ini)
<longsleep> let me know if you think it is a bug and want me to add it
<ogra_> it might be a bug, but as i saidm system-image is completely going away soon
<ogra_> for snappy that is
<ogra_> your rootfs will be a snap from the store with a readonly img inside
<longsleep> yeah - we will change whatever needs to change then - no problem
<longsleep> ogra_: i will be one of the first to test if you have something i can test
<ogra_> :)
<ogra_> it will happen for 16.04
<longsleep> yeah i cannot wait until then
<longsleep> but, wouldnt there still be some bootstrapping system image which then mounds the readonly image?
<longsleep> ogra_: or do you want to put all this into the ramdisk?
<ogra_> i would love to actually use the initrd *as* the readonly rootfs (like android does) ... but i fear that wont happen (too much pr-mount stuff that we need to do)
<ogra_> i was pondering to bring that setup up on the mailing list though
<ogra_> s/pr/pre/
<longsleep> yeah probably a good idea, it would be nice to have it all inside initrd to avoid having some preloader gear on disk
<longsleep> ogra_: if there is something outside the ramdisk and something outside that rootfs from a snap then that something will need to be changed eventually by some and the situation is not so much different from today
<longsleep> ogra_: i read on the ml, that you work on building the device tarball outside of cdimage - while that would be awesome i would also be interested to create a much simpler rootfs build script - do you see any problems with a simple debootstrap approach, assuming all the hooks for ubuntu-core are run?
<ogra_> longsleep, no, i'm building it inside of cdimage
<longsleep> ogra_: oh - then i misread your mail sorry
<ogra_> longsleep, i'm just moving it to a later point in the build and try to get rid of all tools inside the rootfs that are related to it
<ogra_> so that i.e. something like initramfs-tools and all its deps are not in the readonly rootfs anymore
<longsleep> ogra_: i see - that would be nice yes
<longsleep> ogra_: so your goal is to reduce the rootfs from build dependencies for the device part - understood
<ogra_> i'm not yet sure how we'll create it in a "all snaps" world
<longsleep> thats pretty similar of what i want to have, i mean i have many debootstrap minbase scripts for various targets producing a minimal rootfs - i would like to create the snappy rootfs the same way if possible
<longsleep> and for my case, i never need that script to produce a device tarball as this comes in extra from another source
<ogra_> right
<longsleep> i mean i totally get why you folks create the images like you currently do, existing infrastructure and all - but for an outside the cdimage approach is really complicated
<longsleep> especially if you only want to build for a single target and version
<elopio> plars: ev: things are happening, finally: http://paste.ubuntu.com/13112950/
<ogra_> well, preferably you shouldnt modify the OS snap/readonly rootfs
<plars> elopio: indeed, we are back online :)
<ogra_> and preferably we'd prouce an OS snap that suits you to be able to put a framework snap on top to provide your differences
<elopio> plars: I will now replace the deb + unpack with installing it from the ppa, as we talked long ago. I'm sorry this is still taking so much time.
<plars> elopio: no problem, hard to iterate on it when things were down, plus there was that bug
<longsleep> ogra_: yeah - i am happy to provide feedback as things evolve - for now i am on the page to build that system no matter what and beeing as snappy-ish as possible without loosing possible customizations
<longsleep> ogra_: btw, cloud-init - we talked about this a long time ago - i want to have it gone :)
<ogra_> longsleep, me too, but i'm not sure it will actually happen
<longsleep> ogra_: same goes for systemd timesyncd as it is insecure
<ogra_> we might keep it and have it comppletely disabled or so
<longsleep> ogra_: and all that smartcard stuff - i am not even sure why that is there
<longsleep> ogra_: well i am listening if anyone wants to explain why snappy needs to run pkcsslotd by default
<elopio> plars: can you please add the tools-proposed ppa on the agent, in case you haven't already? https://launchpad.net/~snappy-dev/+archive/ubuntu/tools-proposed
<ogra_> longsleep, cant tell you ... i was asked to seed it, thats all i know
<plars> elopio: will do, but it will only get updated when we deploy or manually update it
<plars> elopio: that's ok?
<elopio> plars: can't you tell the agent to autoupdate? That's the idea, to make it easy to push a new version of the tests to the agents.
<longsleep> ogra_: well ok - but someone has to know :)
<plars> elopio: that's pretty risky I think... if it's infrastructure, we should be deploying a known-good, tested version
<plars> elopio: if it's for a test, it should get pushed in temporarily via the test, and abandoned at the end of the test
<plars> elopio: otherwise it could leave the test environment in an unstable condition for future tests
<plars> elopio: this if for things like ubuntu-device-flash I guess?
<Chipaca> where were the generic-amd64 snap sources?
 * Chipaca <- bad memory
<Chipaca> https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems
<Chipaca> got it
<ogra_> https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems
<ogra_> bah
<Chipaca> mbuahaha
<ogra_> :)
<ev> elopio: what am I looking at? :) I mean I see SPI data in there (test_opportunity.json), but itâs also a wall of text
<elopio> ev: you are looking at the output of the tests running in the bbb in the lab.
<ev> woohoo
<ev> running every day?
<elopio> they fail because the script is taking an outdated deb, but that's good, they should fail.
<ev> hah!
<elopio> ev: yes, they run every day, but for now deployed on my canonistack jenkins.
<elopio> plars: sorry, I was on a hangout.
<elopio> plars: let me try without a package. Just copying all the golang setup.
<elopio> plars: but on travis we have the option to install packages and ppas. We are taking advantage of that in many of our tests, it would be nice if we could do it here too, somehow.
<plars> elopio: thats on your test instance, which gets created/destroyed every time, in the spi case, that is equivilent to the system running snappy, which you can absolutely do whatever you want to it
<plars> creating a new host for it each time, would require another provisioned instance in the middle of the device host, and the device itself.. it's something we could explore but would be complicated and add some additional time to the process
<fgimenez> elopio, can you please take a look at https://github.com/fgimenez/snappy-github-plugin/pull/2 when you have time?
<elopio> plars: that's the problem with this model. We need to do stuff on the test bed, and on the controller.
<elopio> the way to avoid that was to package the stuff of the controller in this deb package that is on the ppa.
<fgimenez> elopio, jenkins job triggered from github, if you could propose a PR for testing it would be great
<plars> elopio: I think we can work with what you want to do pretty easily, we just need to separate what is required/stable infrastructure from what is being tested
<elopio> plars: let me first tackle the daily problem with what you have today.
<plars> elopio: and I think it might make things easier for your use case if you don't feel like you have to build everything on the test host
<elopio> then we will try to solve harder problems, like testing the branches and testing snapcraft.
<plars> elopio: for example, you can do whatever you want on your jenkins, build a new version of snappy tools, ubuntu-device-flash, etc... and ship those down to the job when it runs. It would also likely cut your execution time
<elopio> fgimenez: woohoo.
<fgimenez> elopio, your user is whitelisted, so the job should be triggered automatically. you can trigger a rebuild with a comment "retest this please"
<elopio> fgimenez: I need to walk with the dog because he's driving me crazy. I will try when I return.
<fgimenez> elopio, ok thx!
<elopio> fgimenez: so wait, if I propose a branch to ubuntu-core/snappy it will take it and run tests for it?
<fgimenez> elopio, no, its only for that repo, and the build is currently a couple of echo commands
<elopio> ahhh
<fgimenez> elopio, you should fork it and PR to it
<elopio> fgimenez: cool. bbs.
<ev> elopio: awesome!
<plars> sergiusens: would something like https://github.com/plars/snapcraft/tree/empty-plugin be welcome? I saw some discussion about possibly having something like this and/or modifying copy to make it not require files to copy... but I think that's a bit confusing (copy but don't *really* copy)
<sergiusens> plars, we wanted to call it the 'null' plugin :-)
<plars> sergiusens: as an added bonus, it enables things like https://github.com/plars/snapcraft/commit/9118f2bb67c10c868109cdc5d3ac5052bbe28121 - testing init with parts specified
<plars> sergiusens: yeah, I tried that, but it turns out null is a special word in yaml I think :)
<plars> sergiusens: it choked on that
<plars> it reads it as NoneType
<plars> on a related note, I don't see a way to actually use snapcraft init with the partname specified with the current set. All of them seem to have required args with no way to specify. Is that an issue with snapcraft, or an issue with me not seeing how to specify it? :)
<plars> I don't see any way at the moment to specify it, but perhaps I'm just missing it
<zyga> sergiusens, plars: joc_ implemented a null plugin earlier this week :)
<sergiusens> zyga, I don't see it! :-D
<sergiusens> plars, init with parts needs some love/refactor
<zyga> sergiusens: it was merged to plainbox-provider-p... as a local plugin
<zyga> sergiusens: I encouraged joc to propose it to snapcraft
<zyga> sergiusens: if you want I can dig it out and push
<zyga> sergiusens: no tests though
<zyga> sergiusens: (it's really trivial though)
<joc_> very trivial
<sergiusens> joc_, zyga we can use it in our unit tests instead of the mocked plugins though and then, yay, tests ;-)
<sergiusens> but deal with plars since he has one there too
<zyga> joc_: see if your plugins is any different from the one plars made and let's get one landed in snapcraft
<zyga> joc_: less x- the better
<plars> zyga: ah, I didn't even know that, I'm not subscribed to that I guess
<plars> joc_: you should propose then
<zyga> sergiusens: hey, leo reported something about scenarios for thest that have the same steps
<zyga> sergiusens: that sounds awfully like templates which we do support
<zyga> sergiusens: do you know more what he was thinking about?
<tedg> elopio: ^
<zyga> tedg: ah, thanks
<elopio> zyga: https://github.com/ubuntu-core/snapcraft/blob/master/integration-tests/units/examples.pxu
<elopio> all the tests in there are the same, changing the dir.
<elopio> zyga: tell me more about templates...
<zyga> elopio: perfect :)
<zyga> elopio: it's very easy, write one more job that does the equvalent of ls examples/*
<zyga> elopio: and prints something like this to stdout:
<zyga> elopio: name: godd\n\n
<zyga> elopio: name: gopaste\n\n
<zyga> elopio: etc
<zyga> elopio: make that a plugin: resource
<zyga> elopio: and run it to see that it works OK
<zyga> elopio: then step two
<zyga> elopio: take any of the example jobs
<zyga> elopio: replace the name of the example with {name}
<zyga> and stick this up front in the unit:
<zyga> unit: template
<zyga> template-unit: job
<zyga> template-resource: id-of-the-resource-you-made
<zyga> then last step is to stick the resource in front of the test plan
<zyga> and also add one more field to the test plan: boostrap_jobs: id-of-the-resource-you-made
<zyga> (you have to reference it twice for now)
<zyga> elopio: I'll give you the man page with everything
<elopio> zyga: I'll try when I get back and report how it went. Thanks.
<zyga> elopio: http://plainbox.readthedocs.org/en/latest/manpages/plainbox-template-units.html
<zyga> elopio: scroll to the example
<zyga> elopio: just one gotcha, { } are expanded with python format-like system
<zyga> elopio: so {{ }} are good for quoting
<zyga> elopio: that's not mentioned in the man page
<zyga> elopio: you will have to do quoting
<zyga> elopio: or drop ${foo} in favour of $foo
<zyga> elopio: try it and send me a link tomorrow, if anything needs tweaking I'll help you out
<zyga> elopio: the only weird thing with templates is that with the new world we're going to (all the new tools but _not_ plainbox CLI yet), resource jobs that instantiate jobs from templates need to be listed in boostrap_include in the test plan
<zyga> elopio: http://plainbox.readthedocs.org/en/latest/manpages/plainbox-test-plan-units.html
<zyga> elopio: but plainbox CLI is the last thing to go and for that you still have to just list it in the plain include section
<zyga> elopio: so list it twice and that will be okay
#snappy 2015-11-06
<liuxg> how to define the cap for services in snapcraft.yaml? I have not seen an example for this. I have seen something defined in a package.yaml at http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/head:/go-example-webserver/meta/package.yaml
<liuxg> has anyone done cross compile for snapy app using Docker? thanks
<woodrowshen> liuxg: using snapcraft ?
<liuxg> woodrowshen, yes, I wan to build my app in the docker container for my RaspBerry PI device.
<liuxg> woodrowshen, is that possible?
<woodrowshen> liuxg: according to maillist, the snappy team seems they're still working cross build with snapcraft.
<liuxg> woodrowshen, this is more like a native build. I use the arm container for the purpose.
<woodrowshen> liuxg: yes, just use snapcraft if you have arm container. why not
<liuxg> woodrowshen, the thing is that I got an error like "Pulling webserver
<liuxg> env GOPATH=/home/liuxg/snappy/examples/go-webserver/parts/webserver/build go get -t -d github.com/liu-xiao-guo/golang-http
<liuxg> fatal error: rt_sigaction failure"
<woodrowshen> liuxg: longsleep did the PR, https://github.com/ubuntu-core/snapcraft/pull/53, but it seems ubuntu-core branch didn't accept commits yet.
<woodrowshen> liuxg: did you find where does the message come from ?
<liuxg> woodrowshen, that looks easier without going through a container, right?
<woodrowshen> liuxg: acutally i also use snapcraft to build a snap in the docker (although it's amd64 arch), but i think it's different between container and native platform.
<liuxg> woodrowshen, the message came from the build inside the arm container http://paste.ubuntu.com/13122312/
<liuxg> woodrowshen, sorry, I built it from a container inside the docker.
<liuxg> woodrowshen, how did you set it up?
<woodrowshen> liuxg: ok. so you have a native arm platform ?
<liuxg> woodrowshen, I do not have it yet. I want to do it using one PI device in the near future. I want to get the ubuntu mate on it.
<liuxg> woodrowshen, the output is actually from the arm container
<liuxg> woodrowshen, it seems like "go get github.com/liu-xiao-guo/golang-http" command has problem.
<woodrowshen> liuxg: i'm not sure, but maybe it has some clues, https://github.com/golang/go/issues/13024
<woodrowshen> liuxg: or your go version is too old ?
<woodrowshen> liuxg: i think you can test a simple go program first to check go is workable or not.
<woodrowshen> liuxg: s/check/check if/
<liuxg> woodrowshen, I just updated it to the latest.
<liuxg> woodrowshen, you are right. "go" command simply gets the erro.
<liuxg> woodrowshen, I used  apt-get install golang-go to install the go. how did you get it installed.
<woodrowshen> liuxg: what's version of go in your env ?
<liuxg> woodrowshen, may I know how you installed the "go"? my "go version" command crashes
<liuxg> woodrowshen, http://paste.ubuntu.com/13122387/
<woodrowshen> liuxg: i used gvm, https://github.com/moovweb/gvm
<woodrowshen> liuxg: and also you can check my github, https://github.com/woodrow-shen/snapcraft-grafana
<woodrowshen> liuxg: fyi
<liuxg> woodrowshen, many thanks!
<woodrowshen> liuxg: np
<liuxg> woodrowshen, by the way, where did you get the armhf image for vivid. I get it from my colleague's  source like docker pull  alextucc/ubuntu:vivid-armhf-hybris.
<dholbach> good morning
<mvo> hey dholbach! good morning
<dholbach> hey mvo
<liuxg> woodrowshen, I just followed your steps to do "gvm install go1.4", during the installation, I got the error like http://paste.ubuntu.com/13122582/. so, it is basically the same thing. I doubt whether it is because of my armhf for vivid image issue.
<fgimenez> good morning
<soffokl> Hey, we are using OVA images for Snappy Ubuntu, and latest stable release. But there is a problem with installing snap packages. âsnappy internal-unpackâ spend a lot of time with high IOwait, it takes minutes. We are using SSD disks only and disks are not loaded, but snappy still shows high IOwait. Can someone help to solve it?
<zt> hi, I am new to snappy world,  can someone knows a good tutorial on how to create a snappy app (more than the hello world), I dont know how to create an app that need to add libraries to it, thank you!
<zt> if it helps I want to try to use the raspberry pi CLI to build a basic app
<Chipaca> zt: maybe https://developer.ubuntu.com/en/snappy/build-apps/ ?
<JamesTait> Good morning all; happy Friday, and happy Nachos Day! ð
<Chipaca> * totopos
<Guest42341> nope
<ogra_> soffokl, what hardware architecure ?
<soffokl> ogra_, amd64
<ogra_> hmm, that should definitely not have performance issues
<soffokl> ogra_, I will try to collect more information about problem, thanks
<longsleep> Is ppa:snappy-dev/image livecd-rootfs built from http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/files/head:/ or what is the best tree i could sync with?
<ogra_> longsleep,  bzr branch lp:livecd-rootfs
<ogra_> (for xenial ... for vivid just apt-get source from the PPA)
<longsleep> ogra_: ok thanks - is there no branch for vidid? I would prefer to have source control integration
<ogra_> nope
<ogra_> the branch gets locked down on release day
<longsleep> i see - so how are the fixed created then? Just in local source control?
<ogra_> package
<longsleep> without source control then?
<ogra_> well, with debdiffs and package versioning  :)
<longsleep> ok got it - i guess i can just git apply the debdiffs - i am doing that for other packages already
<clobrano> hello all, is there any news about the possibility to write udev rules? I mean, without re-mounting the filesystem RW :)
<longsleep> mvo: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/config#L394 has uses space indentation, while the rest of the file uses tabs
<ogra_> longsleep, yeah, the code is a mess since years
<ogra_> wrt indendation
<ogra_> not only there
<longsleep> ogra_: well the vivid version of that file is horrible, but someone cleaned up in trunk - so i thought i report it as that one is the only issue in this file
<mvo> longsleep: thanks, I will try to remember that
<plars> joc_: sergiusens: so I was thinking about the difficulty of naming the 'null' plugin, what do you think about just calling it 'basic'
<sergiusens> plars, what is wrong with null or nil?
<plars> sergiusens: nil may be ok also I think, but null seems to be a type in yaml, so when it's translated it becomes Nonetype
<plars> sergiusens: unless you wrap it in quotes... but then it would be different from every other plugin
<sergiusens> plars, ah, then nil :-)
<plars> sergiusens: ok, nil should be fine then... ^ joc_
<joc_> ok
<sergiusens> plars, I would go against basic, I'm happier with it being the anti-plugin :-)
<plars> sergiusens: heh, ok. I was thinking basic because it's 'no frills/nothing added' i.e. you just get the base plugin class
<sergiusens> plars, just add docstrings explaining the purpose of the plugin. """This plugin does nothing.\n\n [More about the plugin which is probably more of nothing or its purpose]"""
<plars> right
<plars> joc_: are you going to propose that? ^
<joc_> plars: can do, will just rename the stuff in my branch...
<joc_> plars: sergiusens: https://github.com/ubuntu-core/snapcraft/pull/85
<joc_> plars: dammit, defeated by plainbox!
<joc_> elopio: hey, could you help work out what tests i need to add to snapcraft to accompany a new plugin?
<sergiusens> joc_, fyi, trunk broke with the last commit so many tests are failing, wait for tedg to get the fix up
<joc_> k
<elopio> joc_: yes, I was looking at it ...
<elopio> the example is nice. I think it would be good to have an integration test that checks that when you do snapcraft pull, the parts/part-name dir is empty.
<elopio> joc_: the integration-tests use plainbox. So for that you would have to add the really simple snapcraft.yaml to integration-tests/data/nil
<elopio> and write a check in bash in integration-tests/units/jobx.pxu
<elopio> joc_: and in addition to that, it would be nice to have a unit test that instantiates the plugin. Those are in snapcraft/tests/
<joc_> elopio: makes sense, i was just adding a job for nil-plugin-pkgfiler testing if nmcli was in the snap/usr/bin/
<elopio> let me know if you need a hand.
<joc_> elopio: thanks, will try and get those ready soon
<elopio> joc_: We need that, but we still don't have a suite to check things in the examples. It only checks that the build succeeds.
<elopio> Chipaca: I don't understand this endpoint: /1.0/icons/[icon]
<elopio> what's an example of [icon] in there?
<Chipaca> elopio: generic-amd64_1.4.png
<Chipaca> elopio: but you're not supposed to guess these
<Chipaca> elopio: they're given in /1.0/packages output
<elopio> ahh, it's the file name. Makes sense.
<Chipaca> it's the filename in /var/lib/meta/icons
<Chipaca> which is preferred over the icon from the snap itself
<jerryG> Chipaca: where are mir logs kept?  Any documentation on mir w/ snappy?
<Chipaca> jerryG: sudo snappy service logs
<Chipaca> ogra_: it seems we've got a leftover eth0 in interfaces.d. I know we mount over it, but it'd be tidier if we removed it entirely. I don't know where it comes from though. Do you?
<ogra_> Chipaca, not really, but i'm just playing with debug prints in livecd-rootfs, i can add a check to my next image build
<Chipaca> ogra_: taw
<ogra_> i can tell you in ~30min
<longsleep> ogra_: How long does a livecd-rootfs build run for you? I am wondering what i could do to speed it up ..
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image
<ogra_> click on the "Successfully built" link for the arch you want to check
<ogra_> it has the time
<longsleep> 8 minutes
<longsleep> so launchpad builds faster than my workstation
<ogra_> (note though that i'm currently experimenting there, the time might be longer than usual due to some debug stuff i added)
<longsleep> ah am64 - lets checkar m
<longsleep> ah 21 minutes
<longsleep> thats more like the time i have here
<longsleep> (arm)
<longsleep> i wonder if it would build faster on native arm - or is that building on arm hardware on launchpad?
<ogra_> it builds on native arm :)
<longsleep> ah cool
<ogra_> what definitely speeds up if you do local builds is a package proxy
<longsleep> my qemu thing builds in 15 to 20 minutes
<ogra_> beyond that 90% of the build is disk IO depending
<ogra_> neither CPU nor RAM are used much
<longsleep> yeah i have to set this up
<ogra_> so a package proxy and an arm board with mSATA socket would help you :)
<longsleep> to me it seems it spends most time in configuring and unpacking though
<ogra_> right
<ogra_> disk ...
<ogra_> well
<ogra_> if you do it in a qemu chroot there is another thing you can try ... create the chroot in a tmpfs ;)
<ogra_> that will definitely speed up a lot
<longsleep> ah yeah thats a nice idea
<longsleep> i will try that next week for sure
<Chipaca> longsleep: the ubuntu schroot thing walks you through that, i think
<jerryG> Chipaca: new set of errors:  pastebin.com/Z70S0xiS
<Chipaca> jerryG: you're building mir with the wrong abi for the system. you need to either include these libs also, or build against the ones on the system
<jerryG> k thx ill try that
<longsleep> Chipaca: Ubuntu schroot, i have read that somewhere - what does it walk me through?
<Chipaca> longsleep: https://wiki.ubuntu.com/SimpleSbuild
<Chipaca> longsleep: that's oriented around rebuilding packages, but the setup is the same for other uses
<longsleep> Chipaca: cool thanks
<longsleep> ogra_: i want to try getting rid of opencryptoki, though i seem to be unable to find where it is actually seeded from - can you give me a hint?
<ogra_> depends on the release ... for vivid it should be in live-build/auto/config ... for xenial it is in the seeds
<longsleep> ogra_: mhm maybe i am blind - let me check auto/config again
<ogra_> (the latter means you cant hack it out ... you would have to provide a chroot hook that apt-get pzurges it)
<ogra_> hmm, or auto/build
<longsleep> ogra_: yeah i am doing that hack for python already
<longsleep> ogra_: mhm its neither in my auto/build nor in auto/config and i am based on (2.301~ppa43) vivid
<longsleep> ogra_: and built images have it inside, so it must come from somewhere
<longsleep> strange
<jerryG> Chipaca: is CXXABI_1.3.9 part of gcc ?
<Chipaca> jerryG: I *think* it's the c++ standard library abi
<ogra_> longsleep, tpm-tools is in the seeds ... opencryptoki is a dependency
<longsleep> aha! thanks
<ogra_> not sure how we solved that for vivid
<ogra_> but i think its hacked into livecd-rootfs there
<longsleep> well, it actually explains why you had to add it - if the tpm tools want it then its clear
<longsleep> ogra_: vivid has add_package install tpm-tools  in auto/config
<ogra_> yeah
<ogra_> what i thoguht
<ogra_> ricmm, your rootfs is done, now the system-image importer just needs to pick it up
<ricmm> mine
<ricmm> mineee
<ricmm> ogra_: working fine
<ricmm> thanks for the help
<ogra_> awesomeness
<ogra_> ricmm, let me know if you need anything else, i'm still around for a bit
<ricmm> dont think so, have a good weekend
<ricmm> sorry for the last minute req
<ogra_> np
<ogra_> not last minute ... still working ;)
<sergiusens> joc_, can you update with master for another travis test run to trigger?
<george_e> I'm attempting to build a snap package but receiving an error "'stop-timeout' is not an integer".
<george_e> http://askubuntu.com/questions/694844/stop-timeout-is-not-an-integer-when-generating-snap-package-why
<george_e> Any ideas what I'm doing wrong?
<ogra_> jdstrand, mdeslaur, i'm trying to get rid of initramfs-tools from the snappy rootfs tarball ... sadly apparmor keeps it in, do you see a way to split out an apparmor-initramfs package that would make it possible to remove all the initrd stuff we dont want on a snappy rootfs ?
<mdeslaur> jdstrand, ogra_: I don't know why we even have that dependency at all
<ogra_> heh
<mdeslaur> jdstrand, ogra_: pretty sure it's vestigial from a long time ago, and isn't necessary anymore
<jjohansen> jdstrand: ogra_: I can confirm we aren't putting policy in the initramfs atm, and it is not currently required
#snappy 2015-11-07
<george_e> \quit
<george_e> Argh... I keep using the wrong slash...
<george_e> Sorry.
<vthompson> Does anybody know when the snappy-dev/tools PPA will include Xenial? Or should I be using snappy-dev/tools-proposed to pull in the tools for Xenial on my dev machine?
<vthompson> It seems that even snappy-dev/tools-proposed doesn't have all the packages available for Xenial, actually.
#snappy 2015-11-08
<vthompson> I watching one of the UOS sessions (http://summit.ubuntu.com/uos-1511/meeting/22592/core-1511-snappy-developer-community-resources/) and was wondering if it'd be useful to have a snappy/core specific G+ community. The Ubuntu App Developers community has been very active at certain points in the past. Maybe that could be used to talk about snappy/core since they'll be one in the same in the future.
<vthompson> Nm the above question, dholbach brought up making a G+ community in the video.
<The_Letter_M> Hello.
<The_Letter_M> I have snappy installed on a RasPi2 and I'm trying to get an ssh to it. I run "sudo snappy se ssh" and I get no results. How can I get an ssh session to it
<The_Letter_M> NM
<The_Letter_M> just found it in the docs
<The_Letter_M> Is there a good reference for what commands are replaced with what in Snappy? Like I need to wget a file from the web and wget does not exist in snappy
<The_Letter_M> Anyone?
<The_Letter_M> Just curious, does anyone here use snappy outside of just what WebDM provides?
<liuxg> woodrowshen, ping
<liuxg> woodrowshen, would you please let me which armfh for ubuntu you are using for cross-building your snappy app. I just found that the image I was using golang installation got problem. thanks
<meebo> hello
<meebo> how can i help?
#snappy 2016-11-07
<ahoneybun> mm
<ahoneybun> mhall119: http://pastebin.ubuntu.com/23439646/
<ahoneybun> it says I have a too old intltool but I have have a new one
<ahoneybun> 0.51 over 0.51
<ahoneybun> *0.50
<ahoneybun> ohhh
<trusty> Are there any limitations to using snap within a chroot? I'm running xenial on a chromebook using crouton. Snapcraft with install-suggested seems to work fine but snap commands fail.
<trusty> snap list . returns error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd-snap.socket: connect: no such file or directory
<Son_Goku> trusty, yes
<Son_Goku> you cannot run snaps confined
<Son_Goku> or in a space where /dev, /proc, /sys, etc. are fake
<Son_Goku> err, snapd cannot be run confined
<Son_Goku> snaps can be run confined, obviously
<trusty> That was my suspicion.  Running the commands seemed to be dependent on /run/snapd-snap.socket but it doesn't exist when I try to find it.
<trusty> Thanks for the quick answer, I couldn't find anything mentioning that limitation!
<mup> PR snapcraft#889 opened: Enable snap revision caching on 'push' <Created by squidsoup> <https://github.com/snapcore/snapcraft/pull/889>
<foxmask> bonjello
<tsdgeos> qengho: on friday you mentioned "post-install runs have to be done at "stage" or "snap" time, when fabricating a snap package.", i've been finding info about how to run commands at "stage" or "snap" time and have failed :/
<tsdgeos> some pointer?
<tsdgeos> oh, bad time for him
<tsdgeos> anyone else? âââ
<didrocks> I don't know what he was referring to, but you can't have commands run at stage or snap time
<didrocks> however, in the install phase of any parts, you can have a custom plugin acting on the parts/part_name/install/ directory
<didrocks> tsdgeos: what's your use case to try to modify the stage/ or prime/ directory (and not install/ btw?)
<tsdgeos> didrocks: need to create the default cursor set
<tsdgeos> update-alternatives --install /usr/share/icons/default/index.theme \
<tsdgeos>         x-cursor-theme /usr/share/icons/DMZ-White/cursor.theme 100
<tsdgeos> need to run this, or create the symlink by hand
<tsdgeos> i guess i could have a fake cmake part-plugin that ran that command?
<tsdgeos> but looks kind of dirty
<didrocks> tsdgeos: I'm afraid, you don't have any other options
<didrocks> and this one can be after: []
<mup> Bug #1639746 opened: Snap launching other snaps <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1639746>
<tsdgeos> i deel dirty now
<tsdgeos> https://code.launchpad.net/~aacid/unity8-session-snap/install_cursor_symlink/+merge/310169
<spineau> didrocks: I'd add checkbox (our QA test runner) to the list (the one you reported in #1639746) as we do need to run other snap commands from within the test snap
<mup> Bug #1639746: Snap launching other snaps <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1639746>
<spineau> zyga is well aware of the issue
<didrocks> spineau: please do edit comment :)
<spineau> didrocks: ok, I will. thanks
<mup> Bug #1638502 opened: Can't cancel email registration step <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1638502>
<steve___> hello
<steve___> i am quite new to snap actually i just used it the first time. I installed a service which is listening on the public ip address and i connect to it. works fine etc. but i actually want to change it so it will listen on the machines local interface so i can define an apache forward to the service. I am just not sure how to change the interface in snap can anyone point me to the right direction
<renato__> Mirv, hey, what is the status of the launcher? Do you have something that you want me to try?
<kalikiana_> stgraber: Seems like the MR now has a weird CI failure where some Go API can't be pulled https://github.com/snapcore/snapd/pull/2225
<mup> PR snapd#2225: Implement lxd-client interface exposing the lxd snap <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2225>
<Mirv> renato__: I've a pull request (https://github.com/ubuntu/snapcraft-desktop-helpers/pull/18) not yet need for testing until it's actually really there. meanwhile update (if you did not yet) your references to ubuntu-app-platform, slot name to platform, and content: field to have version ("ubuntu-app-platform1")
<mup> PR ubuntu/snapcraft-desktop-helpers#18: Initial addition of ubuntu-app-platform shared snap use for Qt and other Ubuntu's libraries <Created by tjyrinki> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/18>
<renato__> Mirv, ok let me update that
<renato__> Mirv, did you test if gtk apps works with this launcher. I was having problems to run calendar app last week
<renato__> Mirv, I will try compile your snapcraft branch and test it with calendar app
<Mirv> renato__: not yet. it's not snapcraft branch but the cloud part branch.
<ogra_> steve___, i dont think that is something you can manage through the interface ... the interface is mainly an on/off switch for accessing or managing network at all from your snap ... your app would have to manage to only accept connections from 127.0.0.1
<cjwatson> qengho: "Do we have any way of knowing when snapcraft builder for launchpad-hosted snap building is updated?"  This suggests some confusion about how it works.  Launchpad doesn't have its own snapcraft version; it pulls snapcraft from the archive you point it to.  There's no separate "update Launchpad's version" step.
<Son_Goku> sergiusens: hey, can you look over https://github.com/snapcore/snapcraft/pull/870?
<mup> PR snapcraft#870: sources: Add RPM source <Created by Conan-Kudo> <https://github.com/snapcore/snapcraft/pull/870>
<FJKong_> hello, how can I set a snap have permission to write disk?
<FJKong_> plugs [home] not enough I think
<didrocks> FJKong_: where do you want to write? You can only write to some specific directories
<didrocks> (see the documentation covering this and env variable where you can write to)
<FJKong_> for example, the snap is a command line tool, it accept input from a file and output to another file,, maybe user want to save result to antwhere he wants
<FJKong_> antwhere/anywhere
<didrocks> FJKong_: that's not the snap concept, you can have the home plug to save to home, but otherwise, you need to save in $SNAP_USER_DATA
<FJKong_> didrocks: I see
<didrocks> ogra_: do you have/want a bug to expose the gpio interface in some boards like pi2/3?
<ogra_> want :)
<ogra_> (nobody filed one yet ... )
<didrocks> which project?
<didrocks> I never know for gadget snaps what to useâ¦
<ogra_> just snappy
<didrocks> ok, doing then!
<ogra_> (see topic)
<didrocks> yeah, but we do snapcraft for snapcraft ;)
<didrocks> and it's ubuntu core technically :p
<ogra_> well, the umbrella project is still "snappy" ... fgeel free to transition it to a new project name (and happy bug moving :P )
<didrocks> ogra_: we have the launchpad api for this! :-)
<mup> PR snapd#2268 opened: many: merge snap-confine into snapd <Created by zyga> <https://github.com/snapcore/snapd/pull/2268>
<qengho> cjwatson: Yes, I was confused. I guess the snapcraft version is the max of what's in the Source-archive Primary/PPA I pick, or the Pocket Updates/Release/Security/Proposed/Backports.
<didrocks> ogra_: if you want to grab it: https://bugs.launchpad.net/snappy/+bug/1639798
<mup> Bug #1639798: enable gpio interface for rpi2/3 (and other boards if suited) <Snappy:New> <https://launchpad.net/bugs/1639798>
<ogra_> joc_, i think you had some example gadget for that, could you paste something to that bug ? Ë^Ë^Ë^
<mup> Bug #1639798 opened: enable gpio interface for rpi2/3 (and other boards if suited) <Snappy:New> <https://launchpad.net/bugs/1639798>
<cjwatson> qengho: More or less, yes.
<cjwatson> qengho: Usual apt rules for the sources.list we write out, which you can pretty much infer from the build log.
<qengho> thx
<davmor2> ogra_: https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1639799 :) your welcome :)
<mup> Bug #1639799: No information provided on how to create an account if you don't have one <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1639799>
<kgunn> didrocks: hey, figure you might know...is there a recommended way of determining in a helper file if you're on ubuntu-core vs snaps-on-classic?
<didrocks> kgunn: oh, good question, I have some ideas (but hacks)
<Mirv> didrocks: isn't [ ! -d directoryname ] standard posix shell too, no need for command execution?
<didrocks> the host fs is in /var/lib/snapd/hostfs. I don't know if it's exported as well under ubuntu core, but if it is, you can use some files to """rely""" you are on classic or core
<didrocks> kgunn: this should help you ^ but I'm now curious and the obligatory question is what's your use-case?
<didrocks> Mirv: oh correct, way better :)
<Mirv> didrocks: right, pushed, thanks!
<kgunn> didrocks: Mirv ...so for instance, webbrowser could be on X11-classic, unity8/mir-classic & mir-kiosk-on-core
<kgunn> so can't just check for mir...
<kgunn> cause it could be either place
<didrocks> kgunn: one sec, testing something
<kgunn> didrocks: sure...
<didrocks> Mirv: merged, thanks! :)
<kgunn> kind surprised there's not a bespoke env var or something
<didrocks> kgunn: yeah, kind of same than not having ARCH_TRIPLET as well
<ogra_> kgunn, hmm ... theoretically /etc7os-release should tell you
<ogra_> */etc/os-release
<ogra_> but i just notice that mvo's patch isnt applied here so on a core image it doesnt say what it should
<didrocks> kgunn: ok, forget the /var/lib/snapd/hostfs idea, the security profile prevents you looking at it (I wonder why we do this bindmount thus)
<didrocks> maybe once mvo's pach is merged, ogra_'s suggestion will be the only one ^
<kgunn> sure
<ogra_> ARGH "
<ogra_> !
<ogra_> http://paste.ubuntu.com/23442090/
<kgunn> ogra_: where is that change? e.g. can i rebuild snapd trunk?
<ogra_> 18-set-os-release.chroot: ....
<didrocks> ogra_: : !!! :)
<ogra_> (niote the colon)
<ogra_> i'll fix that now, but the fix will only be in the edge channel
<didrocks> kgunn: seemsit's only on the livefs build ^ :)
<kgunn> right, figured it was part of the image build step
<didrocks> Mirv: keep me posted if you need help testing once you upload something to the store, I'm interesting to help you there!
<kalikiana_> kgunn: for the socket path? Sounds like it's the same problem users of the lxd snap will have. My solution so far was to just try and fallback
<ogra_> FYI http://paste.ubuntu.com/23442095/ this is how it should look like
<ogra_> kgunn, so checking the ID field should be a good way
<kgunn> kalikiana_: ta
<kgunn> ogra_: thanks
 * kgunn squirells away
<Mirv> didrocks: sure, thank you for the quick reviews
<didrocks> Mirv: was an easy task, you did all the hard stuff! :)
<kgunn> kalikiana_: and just to answer fully, there's a bunch of other env vars that you have to reset to include $SNAP like xdg and mir.... so it's more than just the socket
<jdstrand> mwhudson: hey-- I saw your email regarding console-conf network rewrite. curious if that will fix ipv6 configuration. over the weekend I tried to setup a static ipv6 address on a bbb and it just wouldn't let me get even down into the form to input the info
<jdstrand> mwhudson: it was like it did a check to see if it could do ipv6 and failed that and short-circuited. I updated /etc/netplan/00-* and did 'netplan apply' manually and it worked fine
<jdstrand> mwhudson: I can file a bug if needed. I didn't yet cause I'm not sure yet where that bug should be filed...
<mhall119> jdstrand: is there an interface currently available that would fix this: https://issues.apache.org/jira/browse/COUCHDB-3226 ?
<mhall119> Erlang's os_mon library seems to be calling df, and couchdb uses that library to check on disk space usage
<mup> PR snapd#2247 closed: interfaces/builtin/mir: allow client access to /dev/shm/ <Created by albaguirre> <Closed by albaguirre> <https://github.com/snapcore/snapd/pull/2247>
<MikeB_> Just wanted to close a loop from a couple weeks ago...
<MikeB_> I was having problems building a custom kernel snap then using ubuntu-core to build a custom image...
<ogra_> kgunn, didrocks, ah, i notice mvo already fixed the os-release file ... but only in the edge channel
<MikeB_> After installing hello-world snap and rebooting; snapd failed to start because snapd was "too old".
<ogra_> ogra@dragon:~$ grep ^ID /etc/os-release
<ogra_> ID=ubuntu-core
<MikeB_> So, with snapcraft kernel plugin modified to pull from stable and using ubuntu-image to build from stable, my custom image now works fine.  I can install hello-world snap and reboot successfully.
<ogra_> MikeB_, what channel did your image use ?
<mhall119> niemeyer: where are we with the configure hook documentation? I saw someone asking in the mailing list, and I also would like to start using it for a project I'm working on
<ogra_> ah, stable
<ogra_> that was in fact way to old until last thu.
<ogra_> (when a new stable core snap was released)
<ogra_> so when you built after thu your image should be fine
<MikeB_> ogra_, correct.  I waited for stable to get a more modern ubuntu-core and that did seem to solve my problem.
<ogra_> all builds before thu from the stable channel would have had a 3 months old snapd
<didrocks> ogra_: oh ok :)
<jdstrand> mhall119: if they shipped df themselves, they could use 'mount-observe'. I'll add df to that interface
<MikeB_> ogra_, also nice to see that ubuntu-image can now build from stable without the workaround where you have to download the gadgets from ~vorlon/snappy-hub/snappy-systems.  Looks like they are now included in stable.
<ogra_> yep
<ogra_> (they have been in edge and beta for months ... but we didnt have a stable release yet)
<slangasek> ogra_: right; I think we ought to have pushed them to stable well before now given that the stuff previously in "stable" wasn't of particular use, but it's done now :)
<mhall119> jdstrand: that would only work if os_mon called ${SNAP}/bin/df through wouldn't it?
<ogra_> yeah
<didrocks> mhall119: $SNAP/bin is in $PATH though via snapcraft or the wrapper script
<jdstrand> mhall119: or if they set their PATH in a wrapper so that  ${SNAP}/bin is before /bin
<mhall119> didrocks: I mean, if it's hard coded to look for /bin/df then simply including 'df' in the snap won't help
<renato__> didrocks, hey I am trying to use Mirv shared content, with calendar app and I am getting this message "No schema files found: doing nothing."
<didrocks> ah, hardcodedâ¦ yeah, it's hardcoded :)
<didrocks> renato__: sounds like it's gsettings related?
<jdstrand> oh if it is hard-coded, that is different
<renato__> didrocks, this is related with gsettings schema, any Idea how to fix that?
<mhall119> jdstrand: yeah, that's what I'm checking on
<didrocks> renato__: do you have/rely on any?
<jdstrand> that would also be a really weird thing to do-- they should not do that :)
<renato__> didrocks, this does not happen with gtk-launch
<ogra_> haha
<mhall119> jdstrand: well.....Erlang....
<ogra_> wishful thinking
<jdstrand> regardless, I added to my todo to add df to mount-observe
<renato__> didrocks, yes I am using eds libraries that rely on this
<mhall119> jdstrand: thanks
<wolflarson>  /j #rocketchat
<didrocks> renato__: I think you to stage it then. I doubt Mirv's platform runtime ships them
<didrocks> renato__: the launcher still handles them, if you have any
<mhall119> jdstrand: if 'df' is part of the ubuntu core image, and a snap has mount-observe, is there a risk in allowing it to execute /bin/df directly rather than including it?
<jdstrand> mhall119: that is what I'm saying. no, there is no risk to that and I will be adding /bin/df to mount-observe
<renato__> didrocks, I copied this from gtk-launch to my launcher: http://paste.ubuntu.com/23442214/
<mhall119> jdstrand: ah, perfect, thanks
<renato__> didrocks, I do not want to use gtk-launch this use a lot of space, we I am trying to avoid that
<jdstrand> mhall119: the PATH stuff and including df in the snap is just for in the meantime
<mhall119> jdstrand: do you want me to open a bug report for that?
<jdstrand> mhall119: you can if it helps you, but I don't need it (it is already in the policy updates card I will be working on soon)
<didrocks> renato__: ok, the gsettings schema compilation is harmless, I can add it to common
<didrocks> renato__: it will compile them if you have some .xml gsettings schema and $SNAP/usr/lib/$ARCH/glib-2.0/glib-compile-schemas installed
<didrocks> renato__: just be aware that until the gsettings interface is fixed, you need the home plug to access your changes from default
<renato__> didrocks, humm something still missing, since this still not working if I copy this code to my launcher
<renato__> but it work if I use gtk-launch
<didrocks> renato__: don't use the gtk-launch code though, it's quite ugly and not robust, but yeah, you might need a dep, do you have the glib-compile-schemas file?
<renato__> didrocks, not in my project. Probably this is installed by eds-client libraries that is already part of Mirv package
<didrocks> renato__: you need to stage libglib2.0-bin then
<didrocks> if you don't, already
<didrocks> I don't think it's part of Mirv's platform runner
<didrocks> (and TBH, it shouldn't)
<renato__> didrocks, I do not have any dep on my project anymore
<renato__> didrocks, yeah Mirv has added glib and gtk on his project. I think
<didrocks> did he add the -bin binaries?
<didrocks> just check if you snap ship that file ^
<renato__> didrocks,  I was hopping to replace gtk-launcher with his launcher
<renato__> didrocks, my snap just ship the application files
<didrocks> renato__: that's what I'm trying you to help with :)
<didrocks> so, can you look if you have that file staged or as part of Mirv's platform runtime? ^
<Mirv> renato__: not really, but I added the calendar deps to it (which might be too much if it brings too much in) - qtdeclarative5-ubuntu-syncmonitor0.1 qtcontact5-galera qtorganizer5-eds
<renato__> Mirv, yes this should work since 'qtorganizer5-eds' depens on ed libs that depend on gtk/glib
<renato__> but for some reason is not working
<didrocks> do you read what I'm writing?
<didrocks> again, do you have glib-compile-schemas in your snap?
<didrocks> either the platform one
<didrocks> or yours
<didrocks> without this, yeah, it will NOT work
<didrocks> and this isn't shipped in the glib lib packages
<didrocks> it's only shipped in the -bin package
<didrocks> as it's a tool
<renato__> didrocks, not in my snap for sure, let me check Mirv package
<renato__> didrocks, yes it is present on Mirv package: ./lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas
<didrocks> ok, so it's available in that special platform path
<didrocks> let me special case the qt launcher for it then
 * didrocks would like to avoid code duplication
<didrocks> renato__: can you edit your launcher for a test?
<renato__> didrocks, sure
<renato__> didrocks, this is the current code: http://bazaar.launchpad.net/~renatofilho/ubuntu-calendar-app/snappy-runtime/view/head:/snap/ubuntu-calendar-app.wrapper
<renato__> most of the code was copied from gtk-launcher
<didrocks> argh, pastebinit failsâ¦
<didrocks> renato__: remove the copy from gtk-launcher, you are using desktop-launch, right?
<renato__> didrocks, no. I was waiting Mirv launcher to land to use it
<didrocks> renato__: ah, I did the fix in it
<didrocks> it's this launcher
<didrocks> and it's pushed
<didrocks> I fixed this issue I guess
<didrocks> mind trying it?
<renato__> didrocks, sure how I can test it?
<didrocks> renato__: the cloud part is desktop-ubuntu-app-platform
<didrocks> so, just depend on that and prepend your binary with desktop-launch
<Mirv> renato__: fetch the newest build of the shared snap too while we don't have yet it in store: https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-app-platform/+build/9346/+files/ubuntu-app-platform_5.6.1_amd64.snap
<Mirv> fixed the content versioning to match what was merged to the cloud part
<renato__> didrocks, do you mean add: "after: [desktop-ubuntu-app-platform]" or just the "plug" entry is enough?
<didrocks> renato__: yeah, "after: [desktop-ubuntu-app-platform]"
<renato__> ok
<Mirv> renato__: should I update the parts wiki page to match?
<Mirv> didrocks: I mean you ^
<didrocks> renato__: then your apps: will have command: dekstop-launch <yourstuff>
<didrocks> desktop-launch*
<didrocks> Mirv: what did you change?
<renato__> Mirv, where is the wiki page?
<didrocks> oh, you didn't update it to pick it?
<Mirv> renato__: ignore
<Mirv> didrocks: it doesn't have the desktop-ubuntu-app-platform yet
<didrocks> Mirv: yeah, you need to update the wiki part
<Mirv> didrocks: ok, doing
<kgunn> didrocks: hey, we're using content interface to serve up mir libraries...that can be used for any mir-client....so ultimately, we'd want people to "know" this for them to use and put
<kgunn> into their yaml, but question is...is there any way to auto-promote this?
<kgunn> or does the existance of such a desire/convention rely on "people just have to know"
<renato__> kgunn, we will need a launcher for that too? :(
<didrocks> renato__: so, as it's not up to date yet, you need to copy https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/snapcraft.yaml#L299 (from this line to the end) as an additional part
<didrocks> kgunn: from what I know, we rely on people doing "snapcraft search" (that + blog post), but it seems it fails a little bit as renato__ didn't know about the cloud parts for desktop launcher and still using gtk-launcher
<didrocks> kgunn: that and future documentation
<didrocks> kgunn: I hope codelabs could help unblock people (like having a codelab on using mir in snaps)
<didrocks> same for qt apps
<zyga> o/
<kgunn> didrocks: but in a snap world....there are no "wrong answers"
<kgunn> e.g. you can bundle up anything/everything you want....
<kgunn> so i don't disagree we will have to promote
<kgunn> but it would be cool if there were some automagic way (like a "ubuntu-snapcraft-plugin") that scrubbed your yaml
<didrocks> kgunn: I would love having autocompletion on this with at least one IDE integration
<kgunn> and if it sees you including libs, it could warn...."hey these libs are in this snap via content interface"
<didrocks> (I guess that would be a great discovery patterns)
<Mirv> renato__: didrocks: ok added, there's some 30min delay I think before it's in use. I'll leave meanwhile but we can continue tomorrow.
<abeato> jdstrand, hi, have some small changes to the modemmanager interface: https://github.com/snapcore/snapd/pull/2252
<mup> PR snapd#2252: interfaces: add unconfined access to modem-manager <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2252>
<didrocks> Mirv: yeah, I gave what to copy for renato__ to not be blocked on that delay ^
<didrocks> Mirv: see you tomorrow :)
<Mirv> ah, ok
<abeato> jdstrand, note also ofono interface is pending for merge
<Mirv> renato__: see the beginning of that yaml file for updated usage instructions on the newest platform snap that I linked you to - changed plug name, "1" in content field.
<renato__> Mirv, didrocks, ok thanks, let me try that
<didrocks> Mirv: once we are all settled, it would be great to add a "demo/" in the corresponding directory from the desktop launcher
<mhall119> jdstrand: does ubuntu core provide openssl for snaps to use, or does each snap need to include it's own copy?
<jdstrand> mhall119: openssl is present and available via the default template
<mhall119> thanks jdstrand
<jdstrand> abeato: ack
<abeato> jdstrand, thanks
<renato__> didrocks, Mirv , I am getting this now: http://paste.ubuntu.com/23442314/
<didrocks> renato__: interesting, do you mind to pastebin bin/desktop-launcher ?
<renato__> sure
<didrocks> it's like if there was a syntax error in it, but I don't see whatâ¦
<renato__> didrocks, btw this is my project: https://code.launchpad.net/~renatofilho/ubuntu-calendar-app/snappy-runtime/+merge/310200
<didrocks> renato__: ah, up to date?
<renato__> didrocks, yes with the changes that you asked
<didrocks> you still need to do some QML2_IMPORT_PATH mangling?
<renato__> didrocks, this is the desktop-launcher present on my prime dir: http://paste.ubuntu.com/23442345/
<renato__> didrocks, yes my app install some qml components.
<didrocks> renato__: ah, we should handle that in the launcher then, right now Mirv's patch removed those
<didrocks> but yeah, they should be added as well unconditionnally IMHO
<renato__> didrocks, I agree
<didrocks> (my goal is for you to have no wrapper)
<renato__> didrocks, this will be great
<kalikiana_> Hrm
<kalikiana_> how do I fix this in my interface apparmor/seccomp?
<kalikiana_> operation="mknod" [...] denied_mask="c"
<jdstrand> kalikiana_: you need a 'w' rule
<kalikiana_> jdstrand: I added rw, no difference
<jdstrand> 'c'reat() maps to 'w'rite
<jdstrand> kalikiana_: what is the denial and what did you add?
<jdstrand> kalikiana_: note that mknod is blocked by the seccomp policy so if you added the apparmor rule, seccomp likely blocked it
<kalikiana_> /var/snap/lxd/common/lxd/client.crt rw, -> audit: type=1400 audit(1478531590.503:437): apparmor="DENIED" operation="mknod" profile="..." name="/var/snap/lxd/common/lxd/client.crt" pid=21756 comm="..." requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
<kalikiana_> I added mknod and open to apparmor as well
<kalikiana_> Somehow this worked before, but I never had any of those rules
<jdstrand> kalikiana_: what does 'snap interfaces' show?
<didrocks> renato__: interesting, you can't set variable names with -, this is the issue (in the launcher)
<didrocks> renato__: this needs a wider fix, as this is generated, will take me some time, but I have your code and will be able to try it this way
<didrocks> renato__: I'll probably work on this tomorrow morning if you don't mind
<kalikiana_> jdstrand: lxd:lxd                  ubuntu-sdk-target
<kalikiana_> :home                    ag-mcphail,dekko,handbrake-jz,libreoffice,lxd,neovim-kalikiana,nethack,spread,unity8-session,vlc
<kalikiana_> :lxd-support             lxd
<kalikiana_> :network                 dekko,handbrake-jz,libreoffice,lxd,neovim-kalikiana,snapweb,spread,ubuntu-sdk-target,vlc
<renato__> didrocks, no problem. Thanks a lot
<kalikiana_> jdstrand: ubuntu-sdk-target is my consumer of the lxd interface
<didrocks> renato__: no worry! sorry for the trouble, but as you are the first customer of that functionality, let's say you pay the price ;)
<renato__> didrocks, send me a e-mail if need need a test
<renato__> didrocks, yes I know. Thant. and I am here to help
<didrocks> renato__: will do! :)
<jdstrand> didrocks, renato__: note that environment variables may not contain a '-': http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html
<didrocks> jdstrand: yeah, and as it's generated from the make flavor parameters (and qt5-app-ubuntu-platform is the first one to use this)
<jdstrand> kalikiana_: can you paste the output of 'cat /var/lib/snapd/apaprmor/snap.lxd.lxd'?
<didrocks> I need to do some sedderie in the make paramater that Mirv used
<kalikiana_> jdstrand: http://paste.ubuntu.com/23442432/
<jdstrand> kalikiana_: ok, based on what I am seeing there and the denial, it seems that lxd creates a client cert upon connection with lxc
<jdstrand> kalikiana_: up above when you pasted the denial, you used an ellipse for the profile name. can you paste the full unredacted denial?
<kalikiana_> jdstrand: Ah, sure, was just trying to keep it concise. Full line: [32204.339899] audit: type=1400 audit(1478531590.503:437): apparmor="DENIED" operation="mknod" profile="snap.ubuntu-sdk-target.ubuntu-sdk-target" name="/var/snap/lxd/common/lxd/client.crt" pid=21756 comm="usdk-target" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
<kalikiana_> jdstrand: the cert file is being written from the api, and this from the client
<jdstrand> '/var/snap/lxd/common/lxd/client.crt rwk,' should match the above. Did you reload the profile correctly? sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.ubuntu-sdk-target.ubuntu-sdk-target
<jdstrand> kalikiana_: (note that any changes in /var/lib/snapd/... will get overwritten on refresh/remove/install/etc)
<kalikiana_> I rebuilt snapd and reinstalled the client snap every time
<kalikiana_> No manual editing of profiles
<jdstrand> kalikiana_: can you run that apparmor_parser command now and try again?
<kalikiana_> jdstrand: Did that. Same error.
<jdstrand> kalikiana_: just for my own sanity, can you paste the profile reload line and the new denial?
<jdstrand> kalikiana_: (both from syslog)
<didrocks> renato__: ok, so I fixed the launcher and enhanced it so that you can remove your wrapper
<didrocks> renato__: there is still error while loading shared libraries: libQt5Quick.so.5: cannot open shared object file: No such file or directory
<didrocks> renato__: which makes sense: find /snap/ubuntu-calendar-app/x1/ubuntu-app-platform/ -name 'libQt5Quick.so.5'
<didrocks> so it seems Mirv didn'tincludeit
<didrocks> didn't include it*
<renato__> didrocks, humm this is very strange. This is one of the main libraries. Are you sure that you have mirv content mounted? (It does not work well if you launch the app before connect the interface)
<renato__> let me try that
<didrocks> renato__: oh oh oh, you'reright, I didn't connect it :)
<didrocks> silly me
<didrocks> renato__: ah, and his test for the interface to be connected is wrong actually (my fault suggesting it), we need to check a subdirectory
<renato__> didrocks, yes I faced it a couple of times until I realise that I need to connect it before launch the app for the first time.
<didrocks> content-default-provider should really autoconnectâ¦
<renato__> didrocks, +1
<renato__> didrocks, if you do not connect it before launch the app. you need to remove the app and install it again
<jdstrand> kalikiana_: so I locally did this (I have the lxd snap installed): http://paste.ubuntu.com/23442569/
<didrocks> renato__: fixing the launcher at the same time to yell :)
<jdstrand> kalikiana_: I suspect you need to: remove the ubuntu-sdk snap, disable the lxd snap, enable the lxd snap, install the ubuntu-sdk snap to make sure that the profile caches are cleared each time
<jdstrand> kalikiana_: or something along those lines
<kalikiana_> jdstrand: dmesg doesn't show any denails after the apparmor_parser lines it would seem - which makes no sense to me right now
<kalikiana_> The client output still shows that it can't write
<kalikiana_> 2016/11/07 17:36:05 failed to open /var/snap/lxd/common/lxd/client.crt for writing: open /var/snap/lxd/common/lxd/client.crt: permission denied
<jdstrand> kalikiana_: make you you do this: sudo sysctl -w kernel.printk_ratelimit=0
<jdstrand> kalikiana_: it is possible you are hitting kernel rate limiting and seeing no denials
<jdstrand> kalikiana_: how are you calling lxc? I don't have client.crt with my local test
<kalikiana_> jdstrand: Go API. It creates the cert when getting the config. http://paste.ubuntu.com/23442591/
<jdstrand> kalikiana_: and why is the client.crt in the lxd common directory? shouldn't this be down in SNAP_USER_DATA of ubuntu-sdk?
<jdstrand> kalikiana_: you might be hitting simple unix permissions now. SNAP_COMMON is not writable be a normal user
<jdstrand> by*
<didrocks> zyga: hey! I'm seeing something weird with the content interface
<zyga> didrocks: hey
<zyga> didrocks: what's that?
<didrocks> zyga: it's mounted in a subfolder, but it's like only some directories are exported (which isn't possible via a bindmount, hence I'm puzzled)
<didrocks> ls /snap/ubuntu-app-platform/current
<didrocks> etc  lib  lib64  meta  ubuntu-app-platform  usr  var
<kalikiana_> jdstrand: Hmmm I didn't question that before, but now that you mention that.. the path is set by the client, and could well be owned by the client
<didrocks> now, the bindmount in the snap:
<didrocks> drwxr-xr-x 17 root root 258 Nov  7 14:03 etc
<didrocks> drwxr-xr-x  5 root root  74 Nov  7 14:03 usr
<jdstrand> kalikiana_: in fact, your denial says: fsuid=1000 ouid=1000. 'touch /var/snap/lxd/common/lxd/client.crt' fails: touch: cannot touch '/var/snap/lxd/common/lxd/client.crt': Permission denied
<didrocks> let me run "mount" to see the mounts the snap is seeing
<zyga> didrocks: can you show me the relevant plug and slot please?
<kalikiana_> jdstrand: I was thinking the cert might be shared with other clients. In which case it'd have to be there
<jdstrand> kalikiana_: (I ran the touch command as non-root obviously). also, I don't like this rule at all anyway: '/var/snap/lxd/common/lxd/client.crt rwk,'. that would mean that any connecting client could overwrite another connecting client's client cert
<jdstrand> kalikiana_: if that is the case, I think the lxd snap would create that and then you'd use an 'r' rule only
<didrocks> zyga: oh, got it
<didrocks> zyga: Mirv defined     read:
<didrocks>     - ubuntu-app-platform
<didrocks> so a subfolder
<didrocks> which only contains those 2 ^
<didrocks> I guess he has some nesting issues
<didrocks> zyga: sorry for bothering you, I should have looked the slot definition first :)
<kalikiana_> jdstrand: That's a good point. I'll read up on the API and find out if there's a recommendation
<zyga> didrocks: no worries :-)
<didrocks> renato__: so, we are blocked on Mirv fixing the plateform slot tomorrow
<jdstrand> kalikiana_: cool, thanks
<kalikiana_> jdstrand: Thank you for helping me debug this!
<jdstrand> kalikiana_: np. things can get tricky with multiple security mechanisms and kernel rate limiting
<renato__> didrocks, ok, thanks again. I will wait for him
<didrocks> renato__: let's continue tomorrow then :)
<hindle> I created a snappy package for a small development tool (mostly so I can learn whats involved with a view to creating snappy packages for a large application) - The package (monowinformsspy) is now in a published state. However when I run "snap refresh && snap find monowinformsspy" I get error: no snaps found for "monowinformsspy".
<hindle> I'm using "myapps.developer.ubuntu.com" to look at the state of the package.
<zyga> hindle: is the package published to the stable channel>
<zyga> ?
<zyga> hindle: (find only shows stable packages)
<zyga> hindle: you can snap install --{edge,beta,candidate} $anypackage
<zyga> hindle: but you have to know the snap name
<hindle> zyga: myapps.developer.ubuntu.com shows me that "Targeted channels" are all unchecked. so I guess its not in any channels. I will try checking some. Thanks.
<zyga> hindle: good luck :)
<hindle> zyga: thank you that seemed to fix things :)
<_markfeatherston> Could anyone point me in the right direction for using the gadget snap?  Does this generate a .snap file that goes to the store as well, or is this just used during image creation?  I'm working on adding new hardware support.
<zyga> _markfeatherston: yes
<zyga> _markfeatherston: it is in the store, it can be updated, it is on the device
<zyga> _markfeatherston: https://github.com/snapcore/snapd/wiki/Gadget-snap
<_markfeatherston> thanks, that is good to know.  Do you know how to generate the snap from the yaml?  I've been through that and other documents and i haven't found that yet
<zyga> _markfeatherston: snapcraft master now supports making gadget snaps
<zyga> _markfeatherston: or it may have been released lately
<_markfeatherston> I'll pull that down, thanks
<zyga> _markfeatherston: but really, look at what's in existing gadget snaps and look at the docs
<zyga> _markfeatherston: as long as you build what's needed to boot the device, you're good
<cachio> tedg, higgins
<smoser> hey.
<smoser> if i want to file a bug against snappy kernel, where would i file that ?
<smoser> https://code.launchpad.net/~snappy-dev/pc-kernel-snap/trunk is the source as fas as i can tell
<smoser> where should i file a bug there?
<smoser> ogra_, ^ ?
<mup> Bug #1639878 opened: pc-kernel.snap missing drivers necessary for Hyper-v <Snappy:New> <https://launchpad.net/bugs/1639878>
<smoser> filed ^. someone can re-direct ti
<smoser> it
<mwhudson> jdstrand: it doesn't fix that
<mwhudson> jdstrand: bugs on https://bugs.launchpad.net/ubuntu/+source/subiquity please
<mwhudson> jdstrand: with as much detail as possible please :)
<mwhudson> (i don't really have a sense of what people want with ipv6)
<izzno> mwhudson, cellphones IOT etc...
<mwhudson> izzno: in terms of ui expectations, i mean
<izzno> ah :)
<jdstrand> mwhudson: ack
<mwhudson> jdstrand: it should be easy ish for me to fix this now given that i've just crawled all over the code
<mwhudson> jdstrand: just a straight copy of the ipv4 interface would be easiest of course...
<jdstrand> mwhudson: it might just be that. I need to look at it more carefully so I'll do that in a bit
<mwhudson> jdstrand: thanks
<_markfeatherston> Is anyone here familiar with how snapd interacts with u-boot environments?  To start with I'm trying to find out if the 128KiB environment is a requirement.
<AlbertA> trying to run spread tests locally, but I'm getting this error: "Cannot allocate qemu:ubuntu-16.04-64: cannot launch qemu qemu:ubuntu-16.04-64: exec: "kvm": executable file not found in $PATH
<AlbertA> "
<AlbertA> any ideas? I do have kvm in /usr/bin/
<mup> Bug #1639948 opened: exec: /usr/bin/ubuntu-core-launcher: not found <Snappy:New> <https://launchpad.net/bugs/1639948>
<mup> Bug #1639967 opened: Add support to access to some Avahi methods from org.freedesktop.Avahi <Snappy:New> <https://launchpad.net/bugs/1639967>
<mcclaw> hi everyone.
#snappy 2016-11-08
<mcclaw> good evening
<mup> Bug #1639984 opened: Granting incorrect access in the shutdown interface in snapd <Snappy:New> <https://launchpad.net/bugs/1639984>
<mup> Bug #1639988 opened: Snaps using libappindicator and unity7 plug can't show app-indicators <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1639988>
<Trevinho> jdstrand: here it is ^
<elfgoh> I wish to install Ubuntu Core on Beaglebone black.
<elfgoh> I do see the beagleblack gadget snap but am unsure how to proceed
<elfgoh> Is there some documentation that I can refer to? I am looking at Ubuntu Core 16
<elfgoh> Most of my search results fished up earlier Ubuntu core versions, which I wasnt sure if they are relevant
<elfgoh> Hi there, I am trying to install Ubuntu Core 16 on the Beaglebone black. Is this the right place to seek help? I cant seem to find the documentation on how to utilise the beragleblack gadget snap
<elfgoh> Will be grateful if someone can point me to the relevant documentation
<Tungilik> Hi, where could I find a Ubuntu Music Player snap, or really a bunch of offical dev desktop snaps from Unity 8?
<elfgoh> test
<mwhudson> ogra_: when does http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ get updated? the current images seem to be ~48 hours old
<didrocks> Mirv: good morning! Did you get what I was asking about yesterday?
<foxmask> bonjello
<Mirv> didrocks: fix import path, fix test, but what's missing on the content side? so yes, ubuntu-app-platform/ is exported, and under it are the libraries
<didrocks> Mirv: the read: parameter is relative to your snap
<Mirv> and they are organized so that they include etc, usr/bin, usr/lib and three usr/share folders
<didrocks> so you want to export your snap directory
<didrocks> meaning .
<didrocks> Mirv: http://paste.ubuntu.com/23445443/
<didrocks> this is your snap directory
<didrocks> there are 2 things:
<didrocks> 1. you have an ubuntu-app-platform subdirectory containing etc/ and usr/
<didrocks> I don't think you wanted that
<Mirv> didrocks: well I didn't want, I might want :) I'm explicitly moving the certain staged files to be under ubuntu-app-platform/ (see bottom of https://git.launchpad.net/ubuntu-app-platform/tree/snapcraft.yaml )
<didrocks> 2. and in /snap/ubuntu-app-platform/current/meta/snap.yaml you have:
<didrocks>     read:
<didrocks>     - ubuntu-app-platform
<didrocks> so, you are only exporting ubnutu-app-platform subdir from your snap
<Mirv> yes, the idea was that they don't mix with the app snap
<Mirv> ubuntu-app-platform subdir has all the content needed
<didrocks> right, but here, read is the path that you are exporting
<didrocks> see, I'm only talking about your platform snap here
<didrocks> read: specify the path you are exporting
<didrocks> not where it's going to be mounted
<didrocks> this is independnat
<didrocks> what you want to export is the root of your platform snap
<didrocks> then, this root directory will be mounted inside ubuntu-app-platform of your destination snap (the app snap)
<didrocks> so, in a nutshell:
<Mirv> so, is that like "it'd be nice to export the root of your platform snap" or "it's required"? I mean, since the files are organized so that only the required files are moved to be under the ubuntu-app-platform subdir of the platform snap
<didrocks> - change read: ubuntu-app-platform to read: "."
<didrocks> well
<didrocks> what's the goal of your root ubuntu-app-platform directory then?
<Mirv> didrocks: it's not about that I'm trying to decide the mount place on the slot side, but I'm trying to organize only needed files to be exported
<didrocks> it will never be accessible to anything
<didrocks> in that case, remove the files you don't want to be exported
<Mirv> didrocks: it works for the test app and I can see the files in the correct places so that the launcher works
<didrocks> but stil export the whole content
<didrocks> I'm sure you didn't install the latest version your posted yesterday
<didrocks> ubuntu-app-platform/ subdir only have etc/ and usr/
<didrocks> no lib/ and such?
<Mirv> yes, that was intended, that was what works (before integration to the desktop-helpers)
<Mirv> lib/ doesn't seem to be needed, so I omitted it
<Mirv> I tried to slim down everything as long as the app run
<Mirv> (and when I'm talking about app running, I'm talking about my test app with custom launcher and not yet with the desktop helper)
<didrocks> Mirv: ok, so if you really want to slim that down, instead of moving the content, why don't remove those files?
<didrocks> Mirv: and export the root directory
<Mirv> didrocks: the most obvious newbie answer is I didn't know how to :)
<didrocks> otherwise, you are installing unused files for everyone one to install :)
<didrocks> Mirv: oh ok, let's try to do that then!
<didrocks> I'll dig further on why the current setup doesn't work then
<didrocks> Mirv: so, you can create a part
<didrocks> or even better
<didrocks> instead of using organize
<didrocks> use snap: []
<didrocks> this will only snap the content your are refering
<didrocks> http://snapcraft.io/docs/build-snaps/syntax
<didrocks> snap (list of strings) A list of files from a partâs installation to expose in snap. Rules applying to the list here are the same as those of filesets. Referencing of fileset keys is done with a $ prefixing the fileset key, which will expand with the value of such key.
<didrocks> Mirv: there is still an issue making it not accessing the right lib, I'm going to look at this then in 10 minutes
<Mirv> didrocks: ok, I'll change from organize to snap directly then!
<Mirv> thanks!
<didrocks> yw! (and then export .)
<Mirv> yes
<arnav> join /help
<arnav> help!
<arnav> I can't login on my ubuntu core OS
<arnav> I don't know what's the password
<arnav> either way I can't ssh
<arnav> I can't login on my ubuntu core OS
<arnav> I don't know what's the password
<arnav> either way I can't ssh
<arnav> Is anyone there?????
<arnav> I am panicking
<arnav> HELP!!!!!!!!!!!!!!!!!!!!!!
<arnav> Hello>
<arnav> is anyone there>?
<didrocks> arnav: insisting like that won't help people wanting to help you
<didrocks> 1. this is IRC, it's mostly async
<didrocks> so people answer when they are around
<didrocks> and if they can
<arnav> But I am panicking
<didrocks> 2. this is not a support channel, and when asking for help, please be respectful and quiet
<didrocks> why are you panicking? You are just testing it
<arnav> I am sorry
<didrocks> it's not a production machine
<didrocks> so, please avoid multiple ? and !
<didrocks> (and capital letters)
<didrocks> on your question, you should first read the documentation
<didrocks> you would have seen there that you need to create an account on the machine
<arnav> I just setup my ubuntu core 16 on my raspberry pi
<didrocks> did you plug a screen to it and a keyboard, then create an account?
<arnav> now I can't ssh even though I have the correct key
<arnav> yes
<didrocks> ok, with that screen/keyboard, can you log in?
<didrocks> (as it's just on the rpi2 directly, so user name and password)
<arnav> No, that's the problem I don't know the login
<didrocks> are you sure you are using the right login name associated with your ubuntu SSO account?
<arnav> I tried the default ubuntu login, all my passwords
<arnav> Yes
<didrocks> and you have your ssh private ssh key on the machine you run ssh from?
<arnav> Yes
<didrocks> you should try ssh -vvv <> and pastebin the result
<didrocks> we'll see if at least it's trying the ssh key
<arnav> Ok just a minute please
<arnav> so I should enter the ip address in the angular brackets?
<didrocks> your username@ip
<arnav> It's saying syntax error
<didrocks> what did you try to type?
<arnav> ssh -vvv <arnav.aghav@192.168.0.4>
<didrocks> you don't use the <>, it was to be replaced
<arnav> oh
<arnav> sorry
<didrocks> no worry
<arnav> it's still asking me password and too many lines of result
<didrocks> so, it means it couldn't match the ssh key
<arnav> I am pasting it on pastebin
<didrocks> yeah
<arnav> http://pastebin.com/TsS1cxqu
<didrocks> so, it did try 2 keys
<didrocks> (private ssh keys)
<didrocks> debug1: Offering RSA public key: /Users/aghav/.ssh/github_rsa
<arnav> hmm
<didrocks> debug1: Offering RSA public key: /Users/aghav/.ssh/id_rsa
<didrocks> those were rejected, not matchin the one on the machine
<arnav> so should re-setup it?
<didrocks> you also have 2 others on your machine, but removed the file:
<didrocks> debug3: no such identity: /Users/aghav/.ssh/id_ecdsa: No such file or directory
<didrocks> debug3: no such identity: /Users/aghav/.ssh/id_ed25519: No such file or directory
<didrocks> I would say, there are 2 cases:
<didrocks> - either you didn't associate a public ssh key with your ubuntu sso account (or not the correct one)
<didrocks> - either your username in ubuntu sso isn't arnav.aghav
<arnav> mostly the first one
<didrocks> that would be the 2 reasons it couldn't match them
<didrocks> yeah, so, ensure you associate a key there
<didrocks> and then, resetup the board
<arnav> ok, thanks for the help! Sorry for my behaviour
<didrocks> no worry! happy to help :)
<didrocks> Mirv: I wonder how to define correctly qmlscene so that apps don't have to define it
<Mirv> didrocks: meanwhile I noticed you fixed about two billion things in the desktop helpers... a humble thank you!
<didrocks> because your runtime is not only for qml apps, right, it could be used for QT/C++ one
<didrocks> Mirv: yw! :)
<didrocks> because defining something like that would be great:
<didrocks>         command: desktop-launch $SNAP_LAUNCHER_QMLSCENE --desktop_file_hint=unity8 $SNAP/usr/share/calendar-app/calendar.qml
<didrocks> but $SNAP_LAUNCHER_QMLSCENE would be defined in desktop-launch
<didrocks> oh I know, what about adding qmlscene to $PATH in desktop-launch?
<Mirv> right, the test app I had did have C++ plugin but was qml app in essence
<didrocks> then, people can set:
<didrocks> command: desktop-launch qmlscene --desktop â¦
<didrocks> no, same, that won't work, as $PATH will be resolved before calling desktop-launch
<Mirv> shouldn't the qtchooser be operational as it has the config pointing to the ubuntu-app-platform too?
<Mirv> if it would work like I thought it would, qmlscene would already be in path
<didrocks> it's notâ¦ we can maybe add ubuntu-app-platform/usr/bin/qmlscene to PATH?
<didrocks> Mirv: oh, it's a symlink?
<didrocks> my PATH:
<didrocks> /snap/ubuntu-calendar-app/x1/ubuntu-app-platform/usr/bin/:/snap/ubuntu-calendar-app/x1/usr/sbin:/snap/ubuntu-calendar-app/x1/usr/bin:/snap/ubuntu-calendar-app/x1/sbin:/snap/ubuntu-calendar-app/x1/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
<didrocks> + exec qmlscene --desktop_file_hint=unity8 /snap/ubuntu-calendar-app/x1/usr/share/calendar-app/calendar.qml
<didrocks> qmlscene: could not exec './ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/bin/qmlscene': No such file or directory
<didrocks> it seems that qmlscene tries to reach out ./ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/bin/qmlscene -> fails due to relative path?
<didrocks> I don't know why, but it seems it's due to the qtchooser (it did work though for qt5 itselfâ¦)
<Mirv> didrocks: ah.. the others were relative in the Makefile too, so I assumed it'd work
<didrocks> Mirv: any idea? (let me push latest changesmeanwhile)
<didrocks> yeah
<didrocks> unsure we did test with qml apps though. I think the SDK team did
<didrocks> Mirv: should I just bypass the qtchooser thing for now?
<didrocks> if I do so, I'm getting + exec qmlscene --desktop_file_hint=unity8 /snap/ubuntu-calendar-app/x1/usr/share/calendar-app/calendar.qml
<didrocks> qmlscene: error while loading shared libraries: libQt5Quick.so.5: cannot open shared object file: No such file or directory
<Mirv> I wonder if it's somehow because the ubuntu-app-platform also has qtchooser in it
<didrocks> so I guess it's because the other paths you set
<didrocks> ahâ¦
<didrocks> could be
<Mirv> I'll remove that from the next build
<didrocks> so wrong qtchooser taking wrong config?
<didrocks> what are you going to remove?
<Mirv> well that's first in PATH, it's the wrong qtchooser at least, even though it sounds it's taking right config
<Mirv> the qtchooser package from the staged packages in ubuntu-app-platform
<didrocks> Mirv: hum, I think it's because if you set it, no?
<Mirv> or well, hmm, maybe that's actually the right place to have it after all
<didrocks> I guess it is
<didrocks> I can add it to PATH
<didrocks> but that doesn't fix things (and I don't know enough how it works to fix it)
<didrocks> do you want me to push it so that you can debug?
<Mirv> didrocks: yes, thank you
<Mirv> ah, I see typos..
<didrocks> Mirv: pushed
<didrocks> oh?
<didrocks> Mirv: here are the changes I've done to ubuntu-calendar-app: http://paste.ubuntu.com/23445545/
<didrocks> (removing the wrapper and changed FLAVOR and such)
<arnav> hey, I just reinstalled the OS, deleted all my keys and set a new one still asking me password
<didrocks> arnav: maybe check with the SSO team (like nessita this afternoon) if you have a good user/password match?
<didrocks> I'm pretty sure the issue is either the username not being the correct one or the ssh key public/private match
<didrocks> she would be able to confirm you those
<arnav> how can I contact them?
<didrocks> just here
<didrocks> but this afternoon
<didrocks> (mid afternoon, I would say)
<didrocks> (european time)
<arnav> I live in India so I don't know the timezone
<arnav> oh
<didrocks> ah, yeah, so will be quite late for you :)
<didrocks> I don't know if there is any contact page on ubuntu SSO?
<Mirv> didrocks: there's no such thing as /usr/lib/$ARCH/qt5/libs - should I do pull request like http://paste.ubuntu.com/23445556/ or is the $SNAP/usr/lib/$ARCH/ already in default paths and not needed? but the Qt libraries in the shared snap are at $SNAP/ubuntu-app-platform/usr/lib/$ARCH/
<Mirv> didrocks: ok I haven't used the calendar-app but I'll do changes to the timostestapp3
<Mirv> didrocks: for launcher, what's known to work is https://github.com/tjyrinki/timostestapp3/blob/master/launcher
<didrocks> Mirv: oh good catch! let me try
<didrocks> Mirv: but you are hardcoding the qmlscene path for this
<didrocks> maybe I can thus add $SNAP/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/bin/ to PATH (with $ARCH)
<didrocks> and bypass thus qtchooser as you do
<didrocks> wdyt?
<didrocks> Mirv: hum, even with that, it doesn't want to open the shared lib
<didrocks> ah ok, it's in /snap/ubuntu-calendar-app/x1/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
<Mirv> yeah I didn't have qtchooser configuration for the test app
<didrocks> and you didn't add it to the qtappplatform chooser
<didrocks> ok, let me fix that
<didrocks> une sec
<didrocks> one*
<Mirv> the chooser's library path already is ./ubuntu-app-platform/usr/lib/$(arch_triplet) which should be correct
<didrocks> but not libgl1
<didrocks> there are more path when you need to add ubuntu-app-platform
<Mirv> right, that's needed
<Mirv> useful to compare those launchers side by side
<Mirv> I wonder if also the LIBGL_DRIVERS_PATH and XKB_CONFIG_ROOT should be likewise defined here like in my launcher
<didrocks> Mirv: I would going to add them, do you mind checking you are exporting them?
<didrocks> in your platform snap
<didrocks> (export -> having libs there)
<Mirv> didrocks: yes, they are (my test app doesn't have them in its snap at all, but it runs). ok adding those too to the pull request.
<didrocks> Mirv: I'm preparing one and iterating, don't worry
<Mirv> the test app is 10MB that mostly because of just one unneeded library that I don't know how it ended up still in there, but it doesn't have most libraries
<Mirv> didrocks: ok!
<didrocks> ok, and so, now core dump
<didrocks> but at least, the app tries to start :)
<didrocks> (process:13443): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
<didrocks> I wonder where the schemas are installed
<didrocks> Mirv: ok, pushed my changes
<didrocks> now, the only remaining issue is this core dump, let me check if gsettings compiled or not
<didrocks> ok, the schema compilation issue is that there is no xml gsettings schema shipped with the app
<didrocks> renato__: hey, this one will be for you ^
<didrocks> (or if you are using schemas that should be shipped with the base system, ping Mirv ;))
<didrocks> Mirv: oh, it seems as we did push similar fixes that there are some conflicts
<didrocks> Mirv: but you still have some good addition I don't have, do you mind rebasing?
<Mirv> didrocks: ok this diff now has the remaining things I was doing in my custom launcher https://github.com/ubuntu/snapcraft-desktop-helpers/pull/19/files
<mup> PR ubuntu/snapcraft-desktop-helpers#19: Fix various environment variables to point to the platform snap directories <Created by tjyrinki> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/19>
<didrocks> Mirv: already merged :)
<didrocks> Mirv: so, the remaining issue is gsettings schema error
<didrocks> it doesn't compile anything because there is no xml shipped
<Mirv> didrocks: wow, that was fast :D
<didrocks> heh ;)
<didrocks> and the app (or qt) is using them
<didrocks> (hence the segfault at runtime)
<didrocks> I guess it's up to renato__ to see what gsettings schema he's using and ship them with the files
<didrocks> or probably that's part of e-d-s
<Mirv> using the snap: to try to include /usr/bin (or /usr/bin/*), I get "[Errno 21] Is a directory: '/home/ubuntu/qt-ubuntu/prime/usr/bin/X11'", as if the * wouldn't like subdirectories.. hmm
<elfgoh> Hey has anyone tried the image by @ogra_? http://people.canonical.com/~ogra/snappy/all-snaps/stable/current/ubuntu-core-16-beaglebone.img.xz
<Mirv> doh, that X11 is a symlink to "."
<Mirv> might be a bug to error out on that? meanwhile I probably need more fine-grained usr/bin snap: directives
<Mirv> didrocks: the subdir idea might have actually come originally from bumping into that error, I'm not sure. at the sprint I just tried to get a demo working :)
<Mirv> but I also might simply have found about organize: before snap:
<didrocks> Mirv: could be :) but yeah, I really think you should have a platform snap only shipping what's needed
<didrocks> you can get to the same result with snap: than organize (or even combine both
<didrocks> )
<Son_Goku> sergiusens: ping
<mup> Bug #1640114 opened: configure hook output not accessible <Snappy:New> <https://launchpad.net/bugs/1640114>
<jdstrand> Trevinho: ack
<Mirv> organize didn't have problem with that symlink though
<Arnav> Hello, can someone help me?
<ogra_> mwhudson, there are timestamps (in UTC) on the files ;)
<ogra_> mwhudson, the cronjob kicks in at 7:30 UTC ... if you need it more often i can make it twice or three times per day
<renato__> Mirv, didrocks, good morning. Let me read the backlog
<Mirv> renato__: do that :) also fetch latest ubuntu-app-platform snap from https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-app-platform
<Mirv> I can confirm that still with my custom launcher test app the newest platform snap works (that has the changes didier requested). I'm still battling with changing my test app to use cloud part instead.
<Mirv> for one I can't figure out how the empty ubuntu-app-platform directory (to mount the shared snap to, since the mount point seems to be required to be created at this point) is not being included anymore while the _only_ changes are http://paste.ubuntu.com/23446194/ which do not touch the organize: part that has the ubuntu-app-platform/*
<Mirv> so with that modification I just get cannot mount /snap/ubuntu-app-platform/x1 at /snap/timostestapp3/x1/ubuntu-app-platform with options bind,ro. errmsg: No such file or directory
<Mirv> if I revert that diff and use the normal launcher, it works
<Mirv> anyway, the latest shared snap now has this https://git.launchpad.net/ubuntu-app-platform/commit/?id=cd5f400599c83241ba6d6913246d6dcc84c4bc40
<didrocks> Mirv: well, with my launcher, it's working as well, right?
<didrocks> please try using that one now :)
<didrocks> Mirv: maybe replace / instead of .
<Mirv> didrocks: the pastebin changes http://paste.ubuntu.com/23446194/ I try to switch to the cloud part launcher, but like I said the mount does not work
<didrocks> Mirv: well, the cloud part launcher isn't guilty for that part, those are orthogonal issues ;)
<didrocks> Mirv: look at my comment on / vs .
<Mirv> didrocks: the shared snap seems good (unless there is other reason to use / instead of .). it does get mounted if I use my test app without that diff that changes unrelated parts, that's the weird thing - the mount dir disappears.
<didrocks> Mirv: your pastebin refers twice qmlscene btw
<didrocks> command: desktop-launch qmlscene --desktop_file_hint=unity8 "$SNAP/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/bin/qmlscene" "$SNAP/qtapp2/Main.qml"
<didrocks> I guess you want:
<didrocks> command: desktop-launch qmlscene --desktop_file_hint=unity8 "$SNAP/qtapp2/Main.qml"
<Mirv> ah, yes, I'd have noticed it if it would try to start
<didrocks> Mirv: are you sure the shared snap is mounted properly?
<didrocks> "disappearing" sounds weird
<Mirv> didrocks: the error is the trying to mount "I just get cannot mount /snap/ubuntu-app-platform/x1 at  /snap/timostestapp3/x1/ubuntu-app-platform with options bind,ro. errmsg: No such file or directory" - and the reason is that after that pastebin diff, for some reason the ubuntu-app-platform I'm trying to include my app snap isn't anymore included, so the mount point is not there
<Mirv> didrocks: so what disappears is from the app side, even though nothing there is being changed
<didrocks> Mirv: why do you say then "the shared snap seems good"
<didrocks> it's apparently not
<didrocks> hence my suggestion to replace . by /
<didrocks> which I think is the expected syntax
<didrocks> (for exporting the "root" of the snap)
<Mirv> didrocks: because, like I said, it works with my test app if I just don't try to change it to use cloud part
<Mirv> and if I go into with --shell, the mount content also looks correct inside the app
<didrocks> Mirv: that's weird, it's definitively working well here, the mount point doesn't "disappear"
<Mirv> I don't say there's anything wrong with the cloud part, it's that the directory that would need to be created on the app side is not created anymore for some weird reason
<Mirv> didrocks: regardless, do you confirm that on the app side, the app should currently have the directory ubuntu-app-platform included in its snap so that the mount works?
<Mirv> just to get that detail right
<didrocks> Mirv: yeah, an empty directory to create a mountpoint
<Mirv> yep
<didrocks> (you need a target for the bindmount to work and $SNAP is ro, so you can't create one dynamically)
<Mirv> so I believe the shared snap works (since it does), I just have bad snap luck with my test app
<didrocks> could be
<Mirv> I should probably start over with new test app anyway
<didrocks> yeah, maybe some leftoverâ¦
<renato__> Mirv, hey could you send me the list of "deb" packages that are present on your content share snappy?
<renato__> Mirv, didrocks, what I need to update to test the calendar app? I tried create a new package and installed the Mirv package but I still getting:
<renato__> http://paste.ubuntu.com/23446392/
<Mirv> renato__: list of packages http://pastebin.ubuntu.com/23446399/ though note only if the files are on certain paths like usr/lib
<Mirv> renato__: sounds like you haven't pulled the latest snapcraft-desktop-helpers commits
<Mirv> renato__: plus you could now use the cloud part directly instead of locally
<renato__> Mirv, do you mean that I do not need this : http://paste.ubuntu.com/23446402/
<renato__> Mirv, since you are installing "evolution-data-server-common" could you add the schema files present in "/usr/share/glib-2.0/schemas/"
<stgraber> ogra_: ubuntu core question for you, is there some way to figure out what version of the core snap I'm running from looking at the filesystem? Looking at snap list shows me what was last downloaded but that isn't necessarily what I'm running?
<Mirv> renato__: right, just the after clause for your own part. or you could fix the FLAVOR, see the latest commits in the desktop-helpers git
<Mirv> renato__: ok, adding
<ogra_> stgraber, you could check the "current" link in /snap/core/
<ogra_> stgraber, and the kernel cmdline has the version in the snap_core variable ... if you want to look at a lower level
<didrocks> renato__: sorry, got disconnected, what are you getting?
<didrocks> did you apply the patch I pastebined above?
<didrocks> http://paste.ubuntu.com/23446423/
<stgraber> ogra_: cool, will look at the symlink
<stgraber> ogra_: kernel cmdline is meaningless since I'm running ubuntu core in a container :)
<ogra_> ah
<didrocks> renato__: then, you should get the gsetting schema core dump, and you have to include the schema files you are using
<renato__> didrocks, hye, Mirv told me to use the cloud part instead of local one.
<didrocks> yep
<renato__> didrocks, I talked with Mirv about that:
<didrocks> renato__: sorry, the pastebin is http://paste.ubuntu.com/23446429/
<didrocks> (I was pointing to my local launcher)
<Mirv> renato__: ah, ok, easier if you just use didier's diff
<renato__> didrocks, this is the log: http://paste.ubuntu.com/23446431/
<Mirv> renato__: updated .snap with the schema files included will be later at https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-app-platform/+build/9435
<renato__> didrocks, in resume Mirv will add "/usr/share/glib-2.0/schemas/" into the snappy package
<renato__> Mirv, thanks
<didrocks> renato__: sounds good, but maybe if you are using schemas yourself from your app, you should include the ones you are using
<didrocks> (not in platform, but in your app)
<renato__> didrocks, yes I agree but the the schemas that I am using is not from my app.
<didrocks> so yeah, makes sense for them to be in the platform snap
<renato__> didrocks, Can I keep my url here?
<renato__> -        source: https://github.com/ubuntu/snapcraft-desktop-helpers.git
<renato__> +        source: /home/didrocks/work/ubuntu-core/snapcraft-desktop-helpers
<didrocks> renato__: yeah, please do (that was the diff with the last pastebin I gave you)
<didrocks> it was a way for me to test without git push :)
<renato__> didrocks, Mirv, thanks, is launching the app now. Just wait for the schema to land to see if that fix the startup crash
<didrocks> great that we are on the same page! :)
<renato__> didrocks, still saying no schema files found. Do we need to build it? like the gtk-launcher does?
<didrocks> renato__: what did you do?
<didrocks> the launcher is building them at each upgrade
<didrocks> or install
<didrocks> (so only the first time)
<renato__> didrocks, I installed the new Mirv package, and tried to rum the app
<ogra_> there is a Mirv package ?
<didrocks> without reinstalling yours?
 * ogra_ wants that too !
<ogra_> a Mirv for everyone ... easily installable !
<didrocks> renato__: so yeah, you should remove/reainstall your app
<didrocks> first run is doing the compilation
<renato__> didrocks, I did a shell command, and I can confirm that schemas are there: /snap/ubuntu-calendar-app/x1/ubuntu-app-platform/usr/share/glib-2.0/schemas
<renato__> didrocks, I did that
<renato__> didrocks, let me try again
<renato__> didrocks, same.
<didrocks> hum, weird, definitively working on traditional apps for me
<didrocks> can you send me the additional packages that were stage?
<didrocks> staged
<renato__> didrocks, I do not have any package staged
<didrocks> for the schemas?
<didrocks> how can I reproduce your setup?
<didrocks> ah, it's only the the app platform
<renato__> didrocks, just use the latested mirv package. https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-app-platform/+build/9435
<didrocks> can I get the new snap?
<didrocks> good
<didrocks> renato__: trying on my side
<renato__> thanks
<didrocks> so, no schemas are compiled at all, you say?
<renato__> looks like that. How I can confirm it?
<didrocks> you should have xml schemas in ~/snap/ubuntu-calendar-app/x1/.local/share/glib-2.0/schemas
<didrocks> and you will have some .compiled there
<didrocks> (gschemas.compiled)
<didrocks> ah, got it
<didrocks> renato__: yeah, it doesn't look for the correct source file
<didrocks> let me fix it
<renato__> thanks
<Pharaoh_Atem> has anyone seen sergiusens around lately?
<josepht> Pharaoh_Atem: he was sprinting last week but should be around this week afaik
<ogra_> i saw him comment on bugs :)
<ogra_> (he cant hide ! :) )
<didrocks> renato__: ok, got if fixed, it's failing on something else but not related to the launche r:)
<didrocks> Fail to connect with sync monitor: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name com.canonical.SyncMonitor was not provided by any .service files")
<didrocks> renato__: let me push my change
<renato__> ok this should not crash the app
<renato__> is that crashing?
<didrocks> renato__: it does (a core dump)
<didrocks> one sec, will give you the link
<didrocks> Mirv: FYI, I didn't notice, but check last commit, you should have done that for the launcher to be as light as possible :)
<didrocks> renato__: pushed, you can try rebuilding your app
<renato__> didrocks, thanks
<renato__> didrocks, qmlscene: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
<didrocks> renato__: are you sure you pulled latest?
<renato__> didrocks, probably I need to update somethingelse
<didrocks> renato__: you need to snapcraft clean && snapcraft prime
<renato__> didrocks, let me try again. I did snapcraft clean; snapcraft
<didrocks> hum, weird
<didrocks> let me rebuild as well in case I did a typo
<didrocks> renato__: you're right
<didrocks> let me inspect (sorry)
<renato__> :D
<renato__> np
<didrocks> probably a typoâ¦
<didrocks> but I can't see it
<didrocks> oh, the merge with Mirv's work removed some part
<didrocks> (probably my fault)
 * didrocks rewrite history (shhhh)
<didrocks> renato__: after a rebuild, it works \o/
<didrocks> renato__: probably some other bugs, but at least, it's a start :)
<renato__> didrocks, nice, can I build?
<didrocks> renato__: yep!
<renato__> yeah, we have visuals :D
<renato__> didrocks, any hint about this one: GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.
<renato__> I am not familiar with gsettings
<didrocks> renato__: you are missing one package
<didrocks> this should be part of the platform snap as well I think
<renato__> which one?
<didrocks> dconf-gsettings-backend
<didrocks> then, with the symlink, it should work
<renato__> Mirv, do you agree? ^^^
<didrocks> renato__: for next step: once you remove devmode, you need at least the home and gsettings plugs for gsettings to work
<didrocks> (home is used to create a symlink with the user binary package, so that you can read your changes)
<renato__> didrocks, ok I will keep that in mind. Unfortunately we can not have it confined yet due the missing interfaces. ( I am working on the interfaces too)
<didrocks> ok, just add those 2 now to not forget about them!
<didrocks> (the home one can be puzzling)
<didrocks> or you will make changes in gsettings that you will never be able to read back
<renato__> gsettings is already there
<didrocks> (you will always read the default value)
<didrocks> ok, just add home then!
<renato__> doing now
<didrocks> at least, no more wrapper for you!
<didrocks> and just run "qmlscene"
<didrocks> good progress
<renato__> didrocks, yeah. Thanks a lot for that
<didrocks> yw! :)
<mup> PR snapcraft#890 opened: Implementing '[list-]snaps' command <Created by cprov> <https://github.com/snapcore/snapcraft/pull/890>
<Mirv> renato__:ok, making a note to add dconf-gsettings-backend + symlinks
<Mirv> FYI ubuntu-app-platform now in stote, beers owed to mvo who is off today
<Mirv> but store not ready for it, needs manual review
<Mirv> nessita: ETA for the deployment where store supports content: field for the content interface?
<Mirv> (will read messages later)
<didrocks> oh jdstrand, did you get a chance to update your filter? ^
<didrocks> seems it's still not supported
<didrocks> slot having content: field
<nessita> Mirv, hi! hum, this is the first time I hear about that. HAve you been following that with someone else?
<didrocks> nessita: I reported it to jdstrand some weeks ago (and repinged him at the sprint)
<didrocks> seems like nobody tested before the end to end creation of a content interface snap (before I did)
<nessita> didrocks, ah, so this is something to be fix in c-r-t?
<didrocks> yep
<didrocks> just an unknown field
<nessita> didrocks, if it's in c-r-t trunk, let us know and we'll try to push that to prod asap
<jdstrand> didrocks: it is committed to trunk. I mentioned that we could do a store sync to roadmr the other day, but today I will be requested another store sync
<jdstrand> requesting
<didrocks> great! :)
<didrocks> jdstrand: mind reviewing Mirv's interface meanwhile
<jdstrand> it's already fixed, just need to be pulled into the store
<jdstrand> yes
<roadmr> jdstrand: ok, I'll get on it right away
<didrocks> sweet! just timely deployed
<jdstrand> roadmr: well, hold on til I ping you for the final ping at this point
<roadmr> jdstrand: ok :D
<jdstrand> roadmr: I've got the full set of changes almost done
<jdstrand> (you could've merged what was there before, but no point now)
<roadmr> awesome! sure, just let me know which revno and we'll get that deployed
<jdstrand> didrocks: what snap?
<didrocks> jdstrand: should be ubuntu-app-platform
<jdstrand> didrocks, Mirv: approved. someone should press the 'publish' button when you are ready
<didrocks> jdstrand: excellent, thanks!
<didrocks> and good to know the fix is getting deployed as well
<mup> Bug #1640229 opened: error refreshing snap <Snappy:New> <https://launchpad.net/bugs/1640229>
<kalikiana_> jdstrand: FYI I changed the client side to place the cert/key in a different place than LXD_DIR and it seems to work fine, thus nothing special needed on the lxd/interface side of things
<jdstrand> kalikiana_: great!
<kalikiana_> jdstrand: With regard to the snapd branch, what are going to be the next steps?
<jdstrand> kalikiana_: I'm going to look at it again today
<jdstrand> then we can go from there
<ogra_> ppisati, yo ... you need to build the kernels against the ~snappy-dev/image PPA (the main archive is used anyway then) ... also to get the right initrd scripts and all
<kalikiana_> jdstrand: Cool. Thanks!
<roadmr> jdstrand: hello! hey, question/clarification. Should we deploy c-r-t to the store (which is currently at 761) or should I wait for your ping? (I think I should wait but we had some confusion so I thought it best to ask)
<jdstrand> roadmr: please what
<jdstrand> wait
<roadmr> jdstrand: will do. Yes, that clarifies things :) thanks
<renato__> Mirv, now we need to get it running on unity8 :D
<renato__> Mirv, I'm not sure if we should some how integrate with kgunn shared content or add it to the plataform snappy
<abeato> ogra_, maybe you know how local snaps are installed nowadays? --dangerous and --force-dangerous do not work anymore
<mup> PR snapcraft#891 opened: repo: apt-mark new build-packages as automatically installed <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/891>
<elfgoh> Hello!
<ogra_> abeato, --dangerous definitely works for me
<abeato> ogra_, was a silly error on my side, thanks :)
<elfgoh> Hi all, I intend to run Ubuntu core 16 on the beaglebone black
<elfgoh> Question: what is the difference between Ubuntu Core 16 and debian with the latest snaps installed?
<ogra_> one uses snaps the other uses debs ? ...
<ogra_> (compltely different approaches)
<ogra_> elfgoh, http://people.canonical.com/~ogra/snappy/all-snaps/stable/current/ try that one and see yourself i'd say :) (you need an ubuntu one account to create the ssh login on first boot and i'd recommend an FTDI serial cable)
<elfgoh> Sorry if this is a very basic question. Say i have a base minimal install of debian. And then I install snapd. And from then onwards, I install all packages using snap
<ogra_> then you have a classic install that runs snaps
<elfgoh> I see.
<ogra_> an ubuntu core system uses snaps for everything (kernel, bootloader rootfs are all packaged as snaps)
<elfgoh> I see. Thanks for the clarification. Then what would be technical reasons to use Ubuntu core, instead of a classical system running snaps?
<ogra_> that means you caan use the snap features for the packages ...
<ogra_> i.e. if you install a new kernel snap it will automatically roll back in case there is an issue with the new kernel on reboot
<ogra_> likewise you can roll back your rootfs
<ogra_> read: you cant really break such a system ... it will always fall back to the last working version in case something goes bad
<elfgoh> Got it
<elfgoh> Hmm so on a classical install running snaps, what happens if I try to install a new kernel snap?
<ogra_> it unpacks it to disk, tells teh bootloader there is a new kernel  and tells you to reboot ...
<ogra_> once you reboot there is a flag set by the bootloader that makes the system know that a new kernel upgrade is being verified this boot ...
<elfgoh> Ok. So the non snap kernel will get replaced the kernel snap with no issue?
<ogra_> if the verification succeeds,, the flag is unset again
<ogra_> if not, the system automatically rolls back to the former kernel
<elfgoh> *replaced by
<ogra_> non snap ?
<ogra_> (you asked what happens if you install a new kernel snap)
<elfgoh> Ok hang on... i think we aren't on the same page. Let me restart again
<ogra_> if you hack the system and inject a different vmlinuz then you are indeed on your own :)
<elfgoh> So say I have a fresh classic debian install, which I install snapd. Now I have what you called a classic install running snap, correct?
<ogra_> yes
<ogra_> (you could do that with an ubuntu-server install too ... iirc the nextcloud box uses such a setup (but will switch to an all-snap system in the next iteration))
<elfgoh> And in this type of install, after snaps is installed, there are various components such as kernel, bootloader, there are not snaps, since they came as part of the classic debian install. Correct?
<elfgoh> *that are not snaps
<ogra_> yes
<ogra_> and you will need apt to update them
<ogra_> (and wouldnt be able to manage them or configure them via the snapd REST api)
<elfgoh> Ah. So means that snap will complain or throw an error if I try to install a kernel snap?
<elfgoh> For this particular system?
<ogra_> no idea, i dont think anyone ever tried that :)
<elfgoh> LOL
<ogra_> it would just hog space on your disk in the end
<ogra_> i.e. it wouldnt be used in any case
<jdstrand> roadmr: hey, can you pull r794?
<ogra_> (weather it errors or not)
<elfgoh> ogra_: meaning that the new kernel snap just hogs space?
<jdstrand> roadmr: oh I forgot one teeny thing stgraber asked me to fixed (unrelated to snap declarations)
<jdstrand> fix*
<ogra_> elfgoh, right
<elfgoh> ogra_: I am slightly confused as to why your Beaglebone image isn't here http://releases.ubuntu.com/ubuntu-core/16/
<ogra_> because the bbb isnt "officially" upported
<ogra_> *supported
<ogra_> (we call that "community supported" ... )
<elfgoh> Ah I see. Thanks for building a community image!
<ogra_> heh
<elfgoh> Much appreciated
<ogra_> welcome :)
<elfgoh> I booted the BB image and unless I mistakenly use another image, this is a debian?
<elfgoh> *debian image
<ogra_> nope, it is ubuntu-core
<ogra_> did you hold the button of the bbb when booting off the SD ?
 * ogra_ always forgets that and i dont really want to trash the internal MMC to not make it do that ... 
<elfgoh> No I didn't. What does that button do?
<ogra_> switch the HW to boot from SD instead of internal MMC
<jdstrand> roadmr: ok, please pull r795 :)
<elfgoh> ogra_: that is very interesting. I am not most familiar with the BBB. But I have an existing card with debian on it and it boots fine without pressing the button
<elfgoh> But let me try what you suggested
<ogra_> are yu sure it boots the SD not the eMMC ?
<ogra_> you need to hold down S2, then apply power and if the LEDs are lit up release S2
<ogra_> (very fiddly if you dont have children hands if you ask me :) )
<barry> ubuntu-core_[0-9]+.snap got renamed to core_[0-9]+.snap recently?  i probably missed that on the mailing list
<ogra_> barry, not recently ... that was quite some time ago
<ogra_> images are all built using core now
<barry> ogra_: really?  interesting that my tests are only now failing.  but okay
<barry> thanks
<ogra_> while ubuntu-core is still supported for desktops that have it installed ... afaik snapd has no proper migration code yet
<ogra_> once thats there ubuntu-core will be deprecated
<elfgoh> ogra_: Ok. let me give that a go. I had always assumed that the BBB will boot off the card by default
<ogra_> (teh content is identical to core though)
<ogra_> elfgoh, nope ... only if you hold down S2 ... else it boots off the MMC (unless the MMC mbr is trashed)
<elfgoh> Btw is there a repo that I can send a PR to add a readme to your repo?
<ogra_> you mean to http://people.canonical.com/~ogra/snappy/all-snaps/stable/current/ ?
<ogra_> hmm, i guess having a readme would make sense, yeah ...
<elfgoh> Yes that is what I was thinking
<elfgoh> I will be happy to send a PR if that is helpful
<elfgoh> Once I figure things out at my end
<ogra_> ogra@ubuntu.com ... feel free to just mail it to me and i'll put it in place (perhaps with some adjustments)
<ogra_> but if you dont, i'll put one in place tomorrow, i think it makes sense
<mjbrender> Hey all - I'm running into a packaging issue on a project I maintain.
<elfgoh> Haha. It is 2:41 am here now
<elfgoh> I will see if I can get things figured out first
<mjbrender> It's called Snap (snapd/snapctl) and I know that that's unfortunate.. but curious what others might advise given 16.04.1 has a conflict. Example of the challenge: https://github.com/intelsdi-x/snap/issues/1294#issuecomment-254587076
<ogra_> 19:42 in germany ;)
<ogra_> mjbrender, the media player ?
<mjbrender> ogra_ nope, a telemetry framework for data centers.
<ogra_> (we had massive issues because there is a "snap deb" in the archive for it ... )
<ogra_> oh my
<ogra_> the snap name is really becoming a bit over-used :)
<mjbrender> yeah, it's no fun.
<mjbrender> too true :)
 * qengho files a bug to rename it to "snaaaaaaaap"
<elfgoh> Ok another question, did you build your BBB image using the beagle black snap listed here? https://developer.ubuntu.com/en/snappy/start/gadget-snaps/
<mjbrender> We're thinking through what to do since this took us by surprise. Major renaming is a no go, but thinking through absolute paths or similar.
<mjbrender> haha qengho. I would rather open an ticket to rename Snappy snapd to snappyd and snapctl to snappyctl
<mjbrender> but alas :)
<ogra_> elfgoh, https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems
<elfgoh> Thanks!
<mjbrender> ogra_ any advice come to mind? Curious what you learned from the media player issue and what you recommended
<elfgoh> Speaking of naming..... I can't say that the choice of names for Snap related stuff is the best.... e.g. Ubuntu Core https://launchpad.net/~ubuntu-core-dev
<ogra_> mjbrender, well, the mediaplayer issue was simply that there is a "snap" manpage shipped in the deb ... so snapd (who also ships a snap command and manpage) was clashing ...
<ogra_> elfgoh, well, it got a lot better ... there used to be like 20 meanings of the term ubuntu-core in the ubuntu world ... with snappy all of them have been deprecated now ... there is only one ubuntu-core lft
<ogra_> *left
<ogra_> but yeah, there is still the ubuntu-core-dev team which is for people with full upload rights to the ubuntu archive ... i doubt that name will change though
<ogra_> mjbrender, i dont really understand the issue ... why do you bother that the snapctl command exists ?
<ogra_> mjbrender, http://paste.ubuntu.com/23447708/
<mjbrender> snapctl, in this framework, is a utility to query the snapd server
<ogra_> right ... but if the env var is missing something is set up wrongly already ...
<mjbrender> before 16.04.1 we were installing in /usr/bin/snapctl and snapd
<_markfeatherston> Hello, I'm trying to build an image for new hardware.  I have a gadget and kernel snap to try, but ubuntu-image doesn't see my snaps (error: cannot find snap "tsimx6-gadget": snap not found).  I've uploaded them to the store marked as private, but they are listed as pending review which is why I assume ubuntu-image can't see them?  Is there a better way to go about testing these?
<mjbrender> now it conflicts and gives errors for Snappy snapctl
<ogra_> mjbrender, well, i'd start with filing a bug
<ogra_> i doubt anyone in the snappy core team is aware that there is another snapctl command that could clash
<mjbrender> ogra_ great point - I'll do that now and mention what's going on. I have very realistic expectations, but want to raise the concern and work together on a smart resolution.
<ogra_> you would normally solve that on the package level in the deb though
<elfgoh> Btw I also saw that your mailing lists had no activity since May 2016
<elfgoh> Is it still being used?
<ogra_> elfgoh, link ?
<ogra_> (there surely have been mails the last days)
<ogra_> https://lists.ubuntu.com/mailman/listinfo/snapcraft is the official list
<ogra_> and https://lists.snapcraft.io/mailman/listinfo/devices for porting to new hardware
<elfgoh> https://lists.ubuntu.com/mailman/listinfo/snappy-app-devel https://lists.ubuntu.com/mailman/listinfo/snappy-devel
<elfgoh> Ah
<ogra_> ah, if you had gone trough the posts there,, you would have found an announcement by niemeyer that the list is being renamed :)
<ogra_> people have been migrated automatically ... but archives havent
<ogra_> (i think ... at least :) )
<mjbrender> ogra_ excuse my ignorance here, but where should I file the bug? I don't see Issues available under any of the projects here: https://github.com/snapcore
<ogra_> mjbrender, see the channel topic ;)
<ogra_> we dont use githubs issue tracker (way to limited)
<mjbrender> ogra_ ;)
<elfgoh> ogra: glad to know that there is an active mailing list! I was under the impression that the project was dead xD
<ogra_> hah, nope
<ogra_> it is actually the future of ubuntu ;)
<elfgoh> Truthfully, I had a lot of issues finding updated info about ubuntu core
<elfgoh> and snappy
<elfgoh> The hits on google are mostly the news releases
<elfgoh> But I am glad to be proven wrong
<sergiusens> elfgoh there are twitter and g+ handles you can follow
<sergiusens> if that is your thing
<elfgoh> Ah twitter please
<ogra_> and an IRC channel ;)
<elfgoh> Well the thing is IRC is blocked in the office :(
<elfgoh> web.freenode.net disconnects after some time T.T
<ogra_> use a web client like http://kiwiirc.com/
<roadmr> jdstrand: gotcha, 795.
<elfgoh> Wow thanks I will give kiwi irc a try when i get to office
<elfgoh> What is the twitter handle?
<jdstrand> roadmr: fyi, you could do r796, but it has no effect on the tools (just a sync for consistency's sake)
<roadmr> jdstrand: sure, I can do that
<mup> Bug #1640281 opened: Conflict - Telemetry project, Snap, uses snapd and snapctl <Snappy:New> <https://launchpad.net/bugs/1640281>
<elfgoh> sergiusens: What is the twitter handle?
 * ogra_ calls it a day
<sergiusens> elfgoh snapcraftio
<mjbrender> Thanks again for the help ogra_ -- have a good day/night all.
<mup> PR snapd#2269 opened: update base declaration documentation and policy for on-classic and snap-type <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2269>
<mwhudson> time to find out if i killed my dragonboard when i spilt water on it
<mwhudson> apparently not, woo
<jdstrand> Chipaca: hi! I'm puzzled by the autopkgtest failure in https://github.com/snapcore/snapd/pull/2269
<mup> PR snapd#2269: update base declaration documentation and policy for on-classic and snap-type <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2269>
<jdstrand> Chipaca: it builds fine locally... is this a known issue?
<Chipaca> jdstrand, âjust fyi - please ignore the autopkg xenial-s390x failures, pitti and I are working to make the tests reliableâ
<Chipaca> jdstrand, via mvo
<jdstrand> Chipaca: it says 'xenial-amd64'
<Chipaca> mwhudson, of course water doesn't harm the dragonboard, it's chinese!
<jdstrand> I wonder if it is related...
<jdstrand> well, I'll ask mvo when he is around
<jdstrand> Chipaca: thanks
<Chipaca> mwhudson, (this is a joke about chinese dragons being rules of water)
<Chipaca> rulers*
<Chipaca> jdstrand, ah! hm. dunno then :-/
<Chipaca> jdstrand, I think it's part of the same thing
<jdstrand> Chipaca: ok, thanks
<Chipaca> jdstrand, note only the travis ones are required for merging
<Chipaca> jdstrand, if mvo is around and it isn't next week, hit im over the head
<jdstrand> hehe, ok :)
<mup> PR snapcraft#870 closed: sources: Add RPM source <Created by Conan-Kudo> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/870>
<qengho> RPM, ew.
<Son_Goku> :D
<Son_Goku> woohoo!
<Chipaca> Son_Goku, âµ!
<mwhudson> Chipaca: :)
<mwhudson> even better the new console-conf appears to work
<mwhudson> although the ssid scanning doesn't work for like 30s, wonder what is up with that
<mwhudson> oh right, need to up the interface first
<elfgoh> Out of curiosity, anyone tried soletta or motivity on Ubuntu Core?
<SuperJonotron> Been using snapcraft and snaps in this same configuration for a few weeks, just reinstalled an updated version and now the app can't write to the #SNAP_USER_DATA anymore
<SuperJonotron> did something break in an update for this function?
<SuperJonotron> Anybody know of any issues with the $SNAPPY_USER_DATA location?  having issues all of a sudden not having write access to
<mup> PR snapcraft#892 opened: Catch PermissionError when attempting to replace contents in a readonly file. (LP: #1640305) <Created by larryprice> <https://github.com/snapcore/snapcraft/pull/892>
<qengho> A snap with configure hooks requires some mention of it in the $SNAP/meta/snap.yaml , right?
<qengho> Hmm, no is "implicit". At least in source tree.
#snappy 2016-11-09
<mwhudson> slangasek: do you have any idea what is going on here? https://launchpad.net/~canonical-foundations/+snap/snappy-first-boot/+build/9495
<slangasek> mwhudson: not offhand.  Is the livecd-rootfs package in our ppa up-to-date?
<slangasek> (along with other packages there, generally)
<mwhudson> slangasek: i just deleted all the packages in our ppa :)
<mwhudson> well xenial ones anyway
<slangasek> so the only other 'manifest' ref I see in the log is: + cp assets/dpkg.list /build/snappy-first-boot/parts/livebuild/build/livecd.ubuntu-core.device.manifest
<mwhudson> ah i think it's getting livecd-rootfs from the primary archive now
<mwhudson> i guess i need to copy it over from ppa:snappy-dev/image
<mwhudson> slangasek: oh wait
<mwhudson> slangasek: so it's hard coding the snap name in lp in there?
<slangasek> is it?  I don't know
<mwhudson> yeah i think so
<mwhudson> look at the line before the failing line
<mwhudson> moving something to /build/snappy-first-boot/...
<overflyer> hello all
<overflyer> my raspi2 dont boot with ubuntu-core-16-pi2.img
<overflyer> only red led is on
<overflyer> any idea?
<overflyer> cmdline.txt:
<overflyer> dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty0 elevator=deadline
<overflyer> i think cmdline is wrong. can anyone help?
<overflyer> hello all my raspi2 dont boot with ubuntu-core-16-pi2.img  only red led is on  any idea? cmdline.txt:
<overflyer> dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty0 elevator=deadline i think cmdline is wrong. can anyone help?
<mwhudson> yeah, that was it
<mwhudson> overflyer: sorry, don't know, you could try emailing the devices list
<mup> PR snapcraft#893 opened: Add a script to retry autopktests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/893>
<mwhudson> slangasek: is http://people.canonical.com/~vorlon/official-models/ still the best place to get model assertions from?
<Ric> Possibly dumb question but is there a way put the core and a few snaps into an image that is easy to install on embedded devices.
<boadie> Is there a way put the core and a few snaps into an image that is easy to install on many embedded devices?
<mwhudson> hm my dragonboard image doesn't boot :(
<liuxg> has anyone successfully followed the blog at http://www.zygoon.pl/2016/06/making-your-first-contribution-to-snapd.html to build the snapd? I succeeded it once. now, I am having this error "can't load package: package snap.amd64: cannot find package "snap.amd64" in any of". the detailed info is at http://paste.ubuntu.com/23449276/
<liuxg> I removed "snap.amd64" in my "devtools" dir, and I cannot get it back any more. I thought it was a compiled file from building the snapd.
<elfgoh> ogra_: just to be sure, this what you meant by flashing? https://youtu.be/LDN7QQ1-2c0?t=1m22s
<elfgoh> Didnt seem to work for me. I am using Beaglebone black industrial Rev C
<mup> Bug #1640386 opened: $SNAP_DATA and $HOME are not the same <Snappy:New> <https://launchpad.net/bugs/1640386>
<Mirv> nessita: three weeks ago I heard it's something that is being fixed in store (or store checker tools, not sure) trunk, but not yet deployed. and later I got that you are a good one to ask about store topics.
<zyga> o/
<mup> Bug #1619258 changed: netplan should allow NICs to be disconnected and not stall the boot <Snappy:Invalid> <nplan (Ubuntu):Invalid> <https://launchpad.net/bugs/1619258>
<foxmask> bonjello
<dholbach> hey hey
<didrocks> hey dholbach!
<dholbach> salut didrocks
<liuxg> zyga, ping
<liuxg> zyga, I followed your instructions at http://www.zygoon.pl/2016/06/making-your-first-contribution-to-snapd.html to build the snapd at https://github.com/zyga/snapd/tree/hello-iface. The very first time, the build was succeessful. However, i did not see the "reboot" interface. Then I removed the "snap.amd64" file in the "devtools" directory. After that, I get the error like http://paste.ubuntu.com/23450405/. How can I get the "snap.amd64" file back? thanks
<Mirv> nessita: the problem we have with that is anyway that ubuntu-app-platform (now in store) needs manual review for each upload, because of the warning about the "content:" field in the content interface definition, which is however required for the snap to function
<renato__> Mirv,hey just tested the new package with unity8. Not running yet. Probably we need to export some env variables
<renato__> Mirv, probably we need didrocks help
<didrocks1> renato__: try tweaking the launcher and export MIR_CLIENT_PLATFORM_PATH=$SNAP/ubuntu-app-platform/usr/lib/$ARCH/mir/client-platform (if this is shipped by the new content snap)
<didrocks1> this was the only thing to add Mir support
<renato__> let me try
<renato__> didrocks1, Mirv, http://paste.ubuntu.com/23450827/, do you know where I can find Mir logs?
<didrocks1> I would say you don't access to the socket
<didrocks1> but kgunn would be the one to ping about it
<BjornT> hi. i'm getting (quite frequently) intermittent errors downloading the ubuntu-core snap while installing a local snap: http://pastebin.ubuntu.com/23450862/
<BjornT> any ideas on what's wrong here? sometimes it does work, but mostly it doesn't
<BjornT> actually, it seems like the CDN is broken. i'm trying in canonistack, and that host name maps to these ips: http://pastebin.ubuntu.com/23450880/
<BjornT> if i add an entry in /etc/hosts to map the host name to 95.172.71.38 it works
<BjornT> ev_: ^^^^
<Mirv> renato__: right, ok so the QPA is now there at least
<Mirv> the new snap is not yet in the store because each upload needs manual review at the moment, but it seems you got it from LP, which is good
<renato__> Mirv, yes. I am trying to understand what is causing the app to fail to launch on unity8. Are you test app working?
<ev_> BjornT: thank you, Iâve passed that on
<ev_> and pointed them here
<Mirv> renato__: I think we need to check with the U8 team indeed what are the expectations
<Mirv> renato__: are you testing Unity8 on zesty or xenial overlay?
<Mirv> I've that separate zesty machine I could try too
<renato__> Mirv, xenial
<renato__> Mirv, it was working with the old qt5/gtk-launcher. I am trying to find what is missing
<sergiusens> BjornT ev we are seeing this in our testing too fwiw, thanks for looking into it
<qengho> Do configure hooks need anything from snapcraft other than copying the hook/configure file and the optional YAML to expand the security permissions?
<Mirv> renato__: ah, ok, then it must be something relatively small (I hope)
<qengho> I have a configure hook I expect to run on "snap set". It doesn't.  """- Run configure hook for snapname (cannot snap-exec: cannot find hook "configure" in "snapname")"""
<qengho> I peeked with strace. snapd lstat()s the configure hook file (ret 0), but then exits (val 1).
<qengho> FWIW, is executable. 0755
<renato__> Mirv, yes, probably is one missing env var :D
<renato__> guys how I can solve this:
<renato__> - Download snap "ubuntu-core" (423) from channel "stable" (received an unexpected http response code (500) when trying to download https://068ed04f23.site.internapcdn.net/download-snap/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_423.snap?t=2016-11-10T14:59:42Z&h=f609260aa36b4327500712f9dfdeb8a059cb9b35)
<renato__> I removed my snapd and re-installed it, and now I can not install any app
<renato__> ok snap login did the trick
<didrocks> qengho: quite puzzled, it does work for me (on an ubuntu core machine)
<didrocks> qengho: did you try it there? it seems desktop ubuntu-core snapd doesn't have the same version, that could impact
<mup> PR snapcraft#894 opened: store: send snapcraft version in a header <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/894>
<qengho> didrocks: I have only tried on snapd-on-classic Z.
<didrocks> qengho: try in a vm, do you mind keeping me posted?
<didrocks> I definitively got the configure hook working here yesterday on it
<faenil> guys, it seems /snap/bin is not in $PATH (environment: Zesty) even though there's a script that does that in profile.d, it seems like it's not used
<faenil> known issue? or should I report a bug?
<qengho> didrocks: grep "hook" /snap/${snapname}/meta/snap.yaml ?
<qengho> faenil: what shell?
<faenil> both unity7 and unity8
<qengho> Maybe, echo $SHELL ?
<faenil> then snap run <app> works in unity7, but not in unity (returns QXcbConnection error, it's not using Mir)
<faenil> qengho: maybe?
<faenil> not in unity8*
<didrocks> qengho: wdym? no, there is nothing to refer in snap.yaml
<qengho> didrocks: Thanks.
<didrocks> qengho:  dropping the file as meta/hooks/configure is enough
<qengho> didrocks: I was wondering if your yaml had something else. Thanks.
<didrocks> no, just meta/hooks/configure, shebang (bash script), executable
<faenil> qengho: that was a statement, not a question :D both under u7 and u8 PATH does not contain /snap/bin
<sergiusens> didrocks if you need specific interfaces for your hook you need to define them in meta
<faenil> (some bad english there, sorry)
<didrocks> sergiusens: right, but here, I guess qengho just want first to have his configure script running :)
<didrocks> like basic 1o1
<sergiusens> ah, well I might take on this tomorrow or this evening as kyle is out this week
<didrocks> let's see first if qengho reproduces his issue on ubuntu core
<qengho> faenil: That profile.d part is the perview of ksh or bash or zsh or csh or tcsh or ipython ... I'm asking which shell you use.
<didrocks> let me try my snap on desktop 16.04 at the same time
<faenil> qengho: ah you mean terminal shell..zsh on unity7, vty on u8
<didrocks> sergiusens: qengho: doesn't work with snapd on 16.04 FYI (didn't try the version in -proposed yet)
<didrocks> unsure if the issue you have in Zesty is similar
<didrocks> as it's a newer snapd
<faenil> qengho: vty, still zsh it is
<qengho> faenil: Will you please check if zsh reads from /etc/profile under your circumstances?
<faenil> qengho: I will have a look. it's not my laptop and I don't use zsh myself, but let's see
<faenil> (it's the team laptop)
<faenil> although http://askubuntu.com/a/476435 suggests /etc/profile won't work with zsh
<faenil> also https://bugzilla.redhat.com/show_bug.cgi?id=88457
<qengho> faenil: that seems like a real bug. Pleasae advise in a bug report where snapd should also put its PATH alterationsfor ZSH users.
<faenil> qengho: I have no idea, I'm not a zsh user :D someone in the team is, I'll ask around
<faenil> .zshrc is a good bet, surely
<qengho> faenil: you are until you run "chsh"? :D
<faenil> zsh is not running on my laptop :D this is a shared laptop
<faenil> but sure, I'll report a bug ;)
<qengho> faenil: thank you.
<faenil> qengho: should it be filed against snapd?
<renato__> kgunn, hey, I am having problems to launch a snappy app on unity8:http://paste.ubuntu.com/23450827/, could you help me with that?
<faenil> qengho: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1640514
<mup> Bug #1640514: /snap/bin is not added to the PATH when using zsh <snapd (Ubuntu):New> <https://launchpad.net/bugs/1640514>
<didrocks> faenil: you should add the upstream "snappy" project for upstream to consider it
<faenil> didrocks: done
<didrocks> thx!
<mup> Bug #1640514 opened: /snap/bin is not added to the PATH when using zsh <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1640514>
<roadmr> jdstrand: are you around?
<jdstrand> roadmr: hi! I am
<mup> Bug #1640386 changed: $SNAP_DATA and $HOME are not the same <Snappy:Fix Released> <https://launchpad.net/bugs/1640386>
<roadmr> jdstrand: I'm testing r796 on staging, for the --plugs/--slots thing. I wanted your help figuring out an error...
<jdstrand> roadmr: ok
<roadmr> jdstrand: but I figured it out myself :) looks like our click-review invocation fumbles the order of parameters: https://pastebin.canonical.com/170282/
<roadmr> jdstrand: still I'd appreciate sanity-check on my theory
<jdstrand> roadmr: yes. overrides must be last after the snap with how argparse is configured
<roadmr> jdstrand: ok, no problem, we can easily accommodate that in our code. Thanks :D
<jdstrand> cool, np
<noise][> renato__: and anyone else that had a problem with ubuntu-core snap (r423 from stable for amd64), the problem is resolved and downloads should be working again. Sorry for the inconvenience.
<faenil> ogra_: have you read the bug report I linked?
<faenil> (the one on redhat portaL)
<faenil> bbl
<mup> PR snapcraft#888 closed: Always respect go-buildtags <Created by stgraber> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/888>
<faenil> ogra_: the zsh bug about "zsh does not source /etc/profile" was marked NOTABUG
<faenil> so I don't think that's going to happen ;)
<faenil> the feature was there, and was removed on purpose
<faenil> so if you want to support running snaps from zsh, it seems changing zsh behaviour is not an option :/
<ogra_> faenil, well, it points to other bugs that were closed with pointing to adding that change in ~/.zshrc
<faenil> yes
<ogra_> (or rather to /etc/skel/.zshrc )
<ogra_> did you check if our package ships that file and if it has these changes ?
<ogra_> if so, it is actually a matter of the user to update his config in the homedir accordingly
<ogra_> there is no way that is a snappy bug ... snappy uses the agreed shell standard of using /etc/profile.d ...
<faenil> ogra_: sure, I agree with you
<niemeyer> ogra_, faenil: We can easily patch the stock zsh profile in Ubuntu to make sure the proper path is included, I'd guess?
<ogra_> that was what i thought ...
<ogra_> but it would mean an ubuntu specific delta
<ogra_> (though perhaps we could get it into debian ... not sure if they'd accept that)
<faenil> niemeyer: that would be ubuntu specif though :/
<faenil> specific*
<niemeyer> faenil: Indeed, but it's not uncommon for tooling to have distribution-specific path handling
<niemeyer> faenil: The alternative would be to upstream into the zsh source code itself
<faenil> ogra_: we do not seem to ship .zshrc
<niemeyer> faenil: Might be worth attempting to push this upstream
<faenil> niemeyer: +1
<niemeyer> faenil: +1 as well.. who's going to work on that? :)
<faenil> not sure, someone whose job task include working on snapd? :) or someone who has enough spare time to add that on top
<niemeyer> faenil: We need help with that sort of thing, as we can't keep our eyes on every single software that might interact with snaps
<niemeyer> The right file to tweak is /etc/zsh/zshenv
<faenil> niemeyer: I know, I know..we're in the same company :P each busy on his own bits :D
<ogra_> sswell, whichever team maintains zsh should do it ...
<ogra_> :)
 * ogra_ glances in foundations direction ...
<faenil> haha :)
<SuperJonotron> how can you access the  user invoking a snappy binary, normal methods such as $SUDO_USER and whoami don't seem to work
<qengho> SuperJonotron: You can't. And you can't do anything with it anyway. Don't "sudo".
<n0c_> how do I use docker with snap?
<n0c_> I did `snap install docker`
<n0c_> but, how do I start the daemon?
<lazyPower> sudo service snap.docker.dockerd start
<lazyPower> n0c_ ^
<n0c_> thanks! where would I have learned about that?
<lazyPower> the confined docker snap is still pretty new. lool - any hints for n0c_ on where they can follow along at home?
<lool> n0c_m lazyPower: https://lists.ubuntu.com/archives/snapcraft/2016-October/001382.html is the best compilation, the gdoc might not be fully up-to-date but I could fix any issues there
<lool> n0c_: this should soon work out of the box, but a bug prevents it right now
<lazyPower> lool - does uapp explorer not have support for listing things like README's? I would think having a canonicalized wiki style place for this information would be better than a gdoc.
<lazyPower> just my 2 cents though
<lool> lazyPower: yeah good point, link frmo description would be good
<lazyPower> in terms of discoerability, a google doc is the equivalent of not having any information out there, as they dont get indexed by google.
<jdstrand> tyhicks: I decided to take a look at bug #1592022 and think I found the solution. Can you review my comments in trello for sanity? (you should have an email now)
<lazyPower> we ran into this ourselves when we were doing all of our annotation in gdocs, so we just moved to GH + MD and called it a day
<mup> Bug #1592022: 32 bit applications on 64 bit system fail due to seccomp <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1592022>
<lool> Sure, the point is I can update it to keep it up-to-date, it's not meant to be permanent, eventually it will go away
<jdstrand> tyhicks: it seems completely trivial to fix
 * lool => dinner &
<lazyPower> thanks lool, :)  <3
<mup> PR snapcraft#876 closed: repo: allow for architecture-specific stage-packages <Created by stgraber> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/876>
<jdstrand> oh interesting-- that ^ snapcraft PR would've helped in my seccomp investigation
<jdstrand> popey: do you still have the wine snap around?
<sergiusens> jdstrand there for next time I guess ;-)
<jdstrand> :)
 * jdstrand -> lunch
<noise][> FYI, we are still troubleshooting an issue with downloads of ubuntu-core r423 (stable, amd64)
<popey> jdstrand: I have _a_ wine snap, yes.
<popey> jdstrand: the one I currently have is built with --enable-win64.
<popey> jdstrand: http://people.canonical.com/~alan/wine_1.6-git_amd64.snap  snapcraft.yaml -> http://paste.ubuntu.com/23452189/  'wine' launcher -> http://paste.ubuntu.com/23452191/
<mup> PR snapcraft#894 closed: store: send snapcraft version in a header <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/894>
<mup> PR snapcraft#895 opened: Release changelog for 2.22 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/895>
<jdstrand> popey: I don't know what --enable-win64 does. does that mean you can't run win32 on amd64 or does that enable 64bit in addition to 32bit?
<jdstrand> I guess I can just build from the yaml
<jdstrand> ah "The problem is that by itself, that build will only run applications compiled for 64-bit Windows"
<popey> jdstrand: yeah
<noise][> Update: issue with downloads of ubuntu-core r423 (stable, amd64) has been resolved
<mup> Bug #1595813 changed: implement upower interface <snapd-interface> <verification-done> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1595813>
<mwhudson> hey
<mwhudson> snap create-user leaves a \r at the end of authorized_keys :)
<skillman> could anyone help me with first time setup for ubuntu core?
<jdstrand> sergiusens: hey, are there limitations to stage-packages? if I stage 'wine1.6' then it barfs. I have to edit _get() from repo.py to:
<jdstrand> except SystemError:
<jdstrand>     logger.debug("ERROR: could not mark '%s' to install")
<jdstrand> sergiusens: but it actually continues and marks it ok
<jdstrand> sergiusens: actually, it didn't seem to mark it ok. I staged wine1.6, wine1.6-amd64 and wine1.6-i386:i386 and it didn't pull wine1.6 (it did pull the other two
<jdstrand> popey: hey, can you build without --enable-win64? I can't get it to build here and can't get snapcraft to stage-packages what is in the archive so I'm stuck
#snappy 2016-11-10
<josharenson> If you have a snap installed from the stable channel, is there an easy way to get a newer channel without uninstalling/reinstalling?
<nacc> josharenson: snap refresh foo --<channel>
<nacc> josharenson: i think?
<nacc> josharenson: i mean, that will change what is installed, of course, not sure how you expect to avoid that?
<josharenson> nacc: its downloading... thanks
<nacc> josharenson: unless you just meant the two steps :)
<josharenson> nacc: yeah this is what I was looking for
<nacc> josharenson: great!
<sergiusens> jdstrand are you using master?
<mup> PR snapcraft#895 closed: Release changelog for 2.22 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/895>
<foxmask> bonjello
<dholbach> hey hey
<didrocks> good morning dholbach!
<abeato> $ sudo snap connect modem-manager:mmcli modem-manager:service
<abeato> error: cannot perform the following tasks:
<abeato> - Connect modem-manager:mmcli to modem-manager:service (connection denied by slot rule of interface "modem-manager")
<abeato> morphis_, zyga any idea on why this might be happening? ^^
<morphis_> abeato: did you sideload a modem-manager snap?
<abeato> moyes
<abeato> morphis_, yes
<morphis_> then I guess the base_declaration.go denies slot connection for unasserted snaps :-)
<morphis_> which doesn't sound right to me
<abeato> hmpf
<morphis_> abeato: need to check with jdstrand what the rational behind this is
<abeato> morphis_, agreed, will try to reach him later
<morphis_> thanks
<dholbach> salut didrocks
<tsdgeos> is there a way to tell snapcraft "reload the .deb files that may be old since the last run"?
<tsdgeos> or do i need to clean and run it again?
<didrocks> tsdgeos: you can clean a part if needed
<didrocks> to not clea all parts of your builds
<tsdgeos>  that doesn't help much
<tsdgeos> since all the debs are in the same part
<tsdgeos> given the big amount of debs in the unity8 snap
<didrocks> tsdgeos: not other way AFAIK than redownloading all of them
<tsdgeos> would be good not having to refetch several MB of data just because 1 .deb changed
<didrocks> please open a bug for this
<tsdgeos> otoh not sure if we can actaully know only 1 deb changed
<tsdgeos> i guess we can (since apt-get update knows)
<didrocks> could, from the checksum
<didrocks> or if we don't want to compute them, opening the ar, there is a checksum inside
<didrocks> tsdgeos: please refer here the opened bug
<tsdgeos> sure
<tsdgeos> didrocks: https://bugs.launchpad.net/snapcraft/+bug/1640721
<mup> Bug #1640721: Feature Request: Would be nice to have a way to refresh .deb files <Snapcraft:New> <https://launchpad.net/bugs/1640721>
<tsdgeos> not sure i worded it correctly
<didrocks> tsdgeos: just added a small precision, but yeah, looks good!
<ppisati> ogra_: i suspect you have a white list of modules that end up in the pc-kernel snap
<ppisati> ogra_: e.g. initramfs-tools-ubuntu-core
<ppisati> ogra_: that's where you select which kernel modules endup in the pc-kernel snap initrd
<didrocks> Mirv: I'm unsure to understand your PR
<didrocks> Mirv: I guess you didn't push the second commit with the override, correct?
<Mirv> didrocks: sorry, I was just thinking I might have explained it better. so the platform qt5 sets QTCOMPOSE, but if the "general" QTCOMPOSE is set after that block the platform qt5 setting is never taking effect
<didrocks> oh, you already overrde it
<didrocks> let me check :)
<Mirv> yes, but currently the override is before it's generally set, so the override never works
<didrocks> ah indeed :)
<didrocks> what is QTCOMPOSE for btw?
<didrocks> looking for locales? but the name doesn't helpâ¦
<didrocks> (I guess it's for input keyboardsâ¦)
<didrocks> (merged)
<Mirv> yeah the location of compose.dir
<didrocks> good, thanks!
<ogra_> ppisati, yup
<ogra_> ppisati, that is what we use today, correct ... i need a way to have a modules file per arch though, i dont want all the VM drivers in arm kernels for example
<tsdgeos> what was the command to get a shell inside the snap ?
<ogra_> snap run --shell $yourcommand
<tsdgeos> tx
<Elleo> jdstrand: ping?
<renato__> Mirv, hey, just tested the platform plugin from here: https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-app-platform/, but the app still not starting on unity8
<renato__> Mirv, if I add the "mir-graphics-drivers-desktop" it works. Probably some files still missing
<Mirv> renato__: or environment variable ;)
<Mirv> renato__: weird though, since you only added that same package that's being staged
<renato__> Mirv, no, I am not using any wrapper
<renato__> Mirv, could be some dir that you are not exporting?
<Mirv> renato__: yeah I just started looking at that actually, the same thing occurred to me
<renato__> Mirv, nice, let me know if you fix it.
<popey> jdstrand: http://people.canonical.com/~alan/wine/32bitbuild/wine_1.6-git_amd64.snap - 32 bit build for you
<Mirv> renato__: not finding anything not exported in the new packages which were libmirplatform13 mir-client-platform-mesa5 mir-platform-graphics-mesa-x10 mir-platform-graphics-mesa-kms10 mir-graphics-drivers-desktop
<Mirv> renato__: so it might be something that was already installed by previous staged packages, but not exported, which was not needed until now... or something completely different
<davmor2> pitti, mwhudson: In console conf, if you have ethernet and wifi you see options to configure the wifi but also on the main page there is what looks to be some global set ipv4/ipv6.  Are they actually global or are they only controlling ethernet?
<renato__> Mirv, cLet me try to make a list of all files intalled with my package
<Mirv> renato__: I'll make list of files that are staged by the platform snap but not exported
<renato__> Mirv, i will do a diff btw the version with ""mir-graphics-drivers-desktop"" and without it
<Mirv> doh, what's up with pastebin.ubuntu.com
<Mirv> renato__: ok here goes, I don't find anything suspicious "mir" http://pastebin.com/vfi0vPGf
<Mirv> also directly rm -rf :d usr/share/doc and usr/share/man from the list, in addition to move /lib, /lib64 and /usr/include to that canbeprobablysafelyignored
<Mirv> renato__: logically thinking if mir-graphics-driver-desktop was the only thing you have in staged-packages now, and I added it in platform snap, and it works with your included-in-app but not with included-in-platform, the missing file(s) should be in that pastebin.com output, am I thinking correctly?
<Mirv> there's surely bunch of /usr/bin that's not being exported, but nothing obvious
<renato__> Mirv, I am getting the diff now
<renato__> Mirv, page 2: https://docs.google.com/spreadsheets/d/1IKlbILX1S-k2w2Pba5-ZlBoYsBVcOIglmAEUjv8uOcY/edit#gid=144700900
<renato__> Mirv, is "$plataform/usr/lib/x86_64-linux-gnu/mir/" part of LD_LIBRARY_PATH?
<renato__> Mirv, and usr/lib/x86_64-linux-gnu/mir/client-platform
<Mirv> renato__: yeah, so missing env var indeed (you said "no, I am not using any wrapper" so I wasn't sure if you meant it can't be any env var), that's probably it. adding.
<renato__> Mirv, did you confirm that? Is the missing var?
<Mirv> renato__: well it's not set, I'm not sure if it's something that helps
<jdstrand> sergiusens: re master> no. I was using 2.21 with https://github.com/snapcore/snapcraft/pull/876/files
<mup> PR snapcraft#876: repo: allow for architecture-specific stage-packages <Created by stgraber> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/876>
<jdstrand> popey: thanks!
<Mirv> renato__: you could try it in your local snapcraft-desktop-helpers first of course
<jdstrand> Elleo: hey
<renato__> Mirv, ok let me try first I am not sure if it is necessary
<renato__> Mirv, are you able to check if that is exported for QT5 or gtk launcher?
<Mirv> renato__: it's not, but I'm wondering if Mir could confused that it's not under the standard path /usr/lib/.../mir but /ubuntu-app-platform/usr/lib/.../mir
<Mirv> renato__: oh, actually now I found it!
<Mirv> renato__: export MIR_CLIENT_PLATFORM_PATH=$SNAP/usr/lib/$ARCH/mir/client-platform in desktop-exports, not launcher-specific
<Mirv> so we need to override that common env
<renato__> Mirv, let me try
<Mirv> renato__: http://pastebin.com/mZNLx7j8 - the diff
<jdstrand> popey: fyi:
<jdstrand> $ /snap/bin/wine notepad.exe
<jdstrand> /snap/wine/x1/wine: 15: /snap/wine/x1/wine: /snap/wine/x1/bin/wine64: not found
<Mirv> renato__: if you're on up-to-date snapcraft-desktop-helpers locally
<Elleo> jdstrand: heya, got a couple of questions about app armor rules for snaps; is there any equivalent of @{APP_PKGNAME}? At the moment I'm faking it with "snap.@{SNAP_NAME}.@{SNAP_NAME}", but I'm not sure if that covers all cases correctly? and what about @{APP_ID_DBUS}? I saw in the old click stuff it uses libnih-dbus to get a dbus friendly name, but I couldn't find anything similar in snapd?
<Elleo> jdstrand: I had wondered whether I should write a bit of go code in my interface to make a dbus friendly ID instead?
<Elleo> jdstrand: like some of the ###TEMPLATE### style replace stuff done in other interfaces
<popey> jdstrand: balls
<popey> jdstrand: ok, will rebuild and actually test it this time
<popey> sorry
<jdstrand> Elleo: all of the variables are in interfaces/apparmor/template_vars.go
<jdstrand> Elleo: snap.@{SNAP_NAME}.@{SNAP_NAME} is only going to sometimes be correct
<renato__> Mirv, did not solve the problem, let me try more Vars
<Elleo> jdstrand: okay, neither of those are in template_vars.go, so what would be the correct way of forming an equivelant of APP_PKGNAME and should I rewrite it to be dbus friendly in my interface or add something to snapd to make it available for all snaps?
<jdstrand> Elleo: but snippets has different ways of creating the label. eg, plugAppLabelExpr(plug) and slotAppLabelExpr(slot)
<jdstrand> Elleo: see for example udisks2.go and how it expands ###PLUG_SECURITY_TAGS###
<jdstrand> popey: np. I'm not blocked on it atm since I have a simpler reproducer, but would like to test with wine before claiming to have fixed it
<jdstrand> popey: and yes, I think I will be able to make this work
<Elleo> jdstrand: ah, okay, looks like I can use that for the replacement of APP_PKGNAME and then I guess just write some go code to do what libnih-dbus does to make it dbus friendly for APP_ID_DBUS then?
<popey> jdstrand: that's awesome news, thanks.
<jdstrand> Elleo: there is already go code for that
<Elleo> jdstrand: oh?
<jdstrand> Elleo: that is what plugAppLabelExpr and slotAppLabelExpr do
<jdstrand> Elleo: they expand out the plugged commands into what you need. just copy the udisks2.go methodology and you'll get what you need
<Elleo> jdstrand: okay, thanks :)
<jdstrand> Elleo: (notice that ###PLUG_SECURITY_TAGS### in udisks2ConnectedSlotAppArmor expands to dbus labels)
<jdstrand> Elleo: it works pretty neat because it will expand to snap.<snap>.* if using a toplevel plugs, snap.<snap>.<command> if only one command is connected or 'snap.<snap>.<command1>,snap.<snap>.<command2>,snap.<snap>.<commandN>' if multiple commands are connected
<jdstrand> Elleo: so all you need to worry about is peer=(label=###PLUG_SECURITY_TAGS###)
<Elleo> jdstrand: okay, separate but related questions; where should I be allowing download manager and the apps to write data? currently it's: @{HOME}/.local/share/ubuntu-download-manager/@{APP_PKGNAME}/ (which is where the non-dbus version of PKGNAME was being used), should we be shifting that somewhere else for snaps? and should it be on a per snap basis or a per command basis (I'd guess per snap so all commands within a snap can access downloads from other 
<jdstrand> Elleo: (note, you use ###PLUG_SECURITY_TAGS### on the slot side policy and ###SLOT_SECURITY_TAGS### on the plug side policy (they are opposite since you are specifying the peer)
<jdstrand> Elleo: per snap. a tenant of snappy is that all commands can access each other's data
<jdstrand> Elleo: @{HOME}/.local/share/ubuntu-download-manager/ is trickier cause there are a couple of things to keep in mind
<renato__> Mirv, I can not find the problem :(. Do you know some Mir guy that could help us?
<jdstrand> Elleo: the @{HOME} apparmor variable (be default) expands to '/root/' and /home/*/'. the $HOME *environment* variable is set to $HOME/snap/$SNAP_NAME/$SNAP_REVISION
<renato__> Mirv, at least get more info about the problem
<jdstrand> s/be default/by default/
<jdstrand> Elleo: and the template policy allows writes to @{HOME}snap/$SNAP_NAME/$SNAP_REVISION/**
<Mirv> renato__: I think they are all more in your time zone, maybe ask Kevin to give a person to give ideas.
<Mirv> renato__: I can't also find any further variables to set at this point that could have an effect
<jdstrand> Elleo: so from a snap's perspective, you don't have to do anything if udm puts stuff in $HOME/snap/$SNAP_NAME/$SNAP_REVISION/.local/share/ubuntu-download-manager/
<renato__> Mirv, do you have a small app that they could easily test?
<jdstrand> Elleo: (note there is also $SNAP_USER_COMMON env variable, which is set to $HOME/snap/$SNAP_NAME/common
<jdstrand> )
<Elleo> jdstrand: is there a way in which the UDM service can find out the SNAP_REVISION of what it's talking to? or can I have it write to $HOME/snap/$SNAP_NAME/$SNAP_REVISION/current/<blah>?
<Elleo> jdstrand: ah, thought there was a current symlink there, but seems thats only for snap packages in /snap/ not user directories
<jdstrand> Elleo: so you have a choice-- you can adjust udm to figure out where to put the downloads or you can store them where you do now and make your clients figure out where it is (which is tricky cause they don't know the user's home)
<renato__> Mirv, this is printing on unity8 log while trying to run the app: http://paste.ubuntu.com/23456384/
<renato__> Mirv, check if you see anything that could cause the problem
<jdstrand> Elleo: SNAP_USER_DATA doesn't have the current symlink
<jdstrand> Elleo: but this is data that really isn't revision specific, I suspect SNAP_USER_COMMON is a better fit (and easier to implement for you)
<Elleo> jdstrand: udm sends the path to the client as part of the finished signal, can that be used unmodified if the interface provides access to the current location? then the apps don't need to do any work to find it
<jdstrand> Elleo: yes, that is possible from a policy perspective. it is a bit weird with the way snap data dirs are setup though. to me SNAP_USER_COMMON seems the way to go unless there is a compelling reason not to (this will come up in the PR review as well)
<Elleo> jdstrand: for udm to work in a snap it'll need write access to all other snap's common areas though; with the current mechanism it just has access to $HOME/.local/share/ubuntu-download-manager/** and apps get .local/share/ubuntu-download-manager/snap.@{SNAP_NAME}/ or similar
<Elleo> jdstrand: which would seem to keep things much more isolated
<jdstrand> Elleo: click had a different way of doing things-- it had data sprinkled throughout the HOME dir by having data in xdg data dirs. snappy consolidates when application data is and sets HOME for the snap so it can put it wherever. ngoi
<Elleo> jdstrand: is there a way I can find out SNAP_USER_COMMON's value for a snap I'm communicating with over dbus?
<jdstrand> Elleo: udm is a trusted slot though-- its the connecting snaps that are untrusted. you can still limit it to: '@{HOME}/snap/*/common/.local/share/ubuntu-download-manager/** rwk,'
<jdstrand> (or something-- point is, limited within the snap's dir)
<Elleo> jdstrand: okay, when udm decides where to write if I can't get the actual SNAP_USER_COMMON can I assume that @{HOME}/snap/@{SNAP_NAME}/common/... will be correct?
<jdstrand> Elleo: you can use libapparmor to figure out the connecting process' security label and then derive the $SNAP_NAME from that
<Elleo> jdstrand: okay, so SNAP_USER_COMMON will always be of that form then?
<jdstrand> Elleo: you can assume @{HOME}/snap/@{SNAP_NAME}/common/ is correct for series 16, yes. I doubt it will change for series 18, but it is conceivable
<jdstrand> Elleo: yes
<Elleo> jdstrand: okay, cool; thanks :)
<Elleo> jdstrand: will see about making those changes now, I expect I'll be back with more questions soon :P
<jdstrand> ok
<Mirv> renato__: please try / give them https://code.launchpad.net/~timo-jyrinki/+snap/uitk-gallery/+build/9673/+files/uitk-gallery_0.1_amd64.snap - anyway, I'm EOD now but just managed to create that snap
<Mirv> not tested under U8, starts under U7
<renato__> Mirv, yes my app starts on u7 too
<renato__> Mirv, the problem is only on unit8
<Mirv> renato__: yeah, I just mean that there's nothing fundamentally wrong with that snap (that I just created on LP for the first time), so it should be good for testing
<Mirv> uses the platform snap
<mup> PR snapcraft#896 opened: indicators: work with Content-Encoding set <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/896>
<renato__> Mirv, did you push the changes on the launcher? With the MIR client evn var?
<mup> PR snapcraft#897 opened: Don't organize in the install dir <Created by josepht> <https://github.com/snapcore/snapcraft/pull/897>
<mup> PR snapcraft#856 closed: Call organize() after building <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/856>
<kalikiana_> jdstrand: Would you have another look at https://github.com/snapcore/snapd/pull/2225 ?
<mup> PR snapd#2225: Implement lxd-client interface exposing the lxd snap <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2225>
<jdstrand> kalikiana_: yes
<kalikiana_> Thanks
<lewciie> hi there! trying to register a snap and getting registration failed but no reason is given
<didrocks> hey lewciie! What's your specific error message output?
<lewciie> 'Registration failed.'
<didrocks> hum, nothing more with --debug?
<lewciie> let me check
<didrocks> (just if it gets you more info by any chance)
<didrocks> also, have you tried with a different name? (the one you are using may be taken?)
<didrocks> lewciie: just pastebin the output please
<lewciie> I tried 3 different names, including my full name, lastname, and 'gangsta', none of them worked
<lewciie> http://pastebin.ubuntu.com/23456703/
<didrocks> yeah, no real clue there. "snapcraft login" worked, right?
<lewciie> yes, log in was successful
<didrocks> do you mind running snapcraft logout and snapcraft login again?
<lewciie> sure
<didrocks> (maybe pastebin the result of login as well)
<sergiusens> lewciie mind getting this branch https://github.com/snapcore/snapcraft/pull/866 run from source (./bin/snapcraft register) and while you are at it comment on the PR?
<mup> PR snapcraft#866: Login with option to agree to terms of service and human friendly errors <Created by psivaa> <https://github.com/snapcore/snapcraft/pull/866>
<sergiusens> didrocks ^
<sergiusens> it is most likely developer namespace or ToS signing missing
<sergiusens> using that branch should give you the correct hint
<didrocks> ah, graceful store message finally :)
<didrocks> that wil help, indeed
<didrocks> lewciie: mind trying what sergiusens did? (do oyu know how to run from a git branch?)
<lewciie> let me check :)
<didrocks> sergiusens: we don't have snapcraft CLI for ToS signing or such, correct?
<sergiusens> didrocks nope, link to webpage is returned
<didrocks> sergiusens: it's a start at least :)
<sergiusens> didrocks ToS will always be a webpage though
<didrocks> ah, you can't grab it, have people type "I accept" or so?
<cjwatson> There's an upcoming project to improve terms handling
<lewciie> alright I need further support
<cjwatson> (store-side)
<kgunn> ogra_: have you noticed on dragon board... it's like the terminal just goes for a walk sometimes....
<ogra_> for a walk ?
<kgunn> ogra_: like keyboard input into my ssh console just doesn't respond for many seconds
<ogra_> hmm, no, i dont have that
<ogra_> checked dmesg for possible wlan errors ?
<kgunn>  nothing there
<kgunn> just regular init stuff for wlan
<lewciie> sergiusens: not sure how to run that branch, can  get help? :D
<ogra_> well, thats the only thing i could imagine
<kgunn> ogra_: are you on dragonboard much?
<kgunn> just curious
<kgunn> wonder who's using it with ubuntu-core besides me
<ogra_> not really, but i tend to log in a few times a day and have constantly a ssh windo with htop running on it
<ogra_> but nothing where i would actually notice such delays
<lewciie> hello? can anyone help? :D
<lewciie> please?
<lewciie> :)
<ogra_> !ask | lewciie
<ubottu> lewciie: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<ogra_> :)
<lewciie> ahhaa
<lewciie> I asked the questions long ago but thanks, I'm not familiarised with this, will follow the rules
<ogra_> (all i see above is "i need further support" ... but no question after that)
<didrocks> ogra_: I guess there a ping on how to run that branch
<didrocks> ok, so lewciie, let's try
<lewciie> you're right, I was in private chat, I'm just impatient, apologies, dont want to spam anyone with this!
<didrocks> you need to git clone https://github.com/psivaa/snapcraft.git
<ogra_> lewciie, better spam ... the channel is logged and google will find the discussion when someone looks for the same issue in a year ;)
<didrocks> then, cd snapcraft
<lewciie> ogra_: thank :)
<lewciie> didrocks: let me do it
<didrocks> git checkout bug/1619193
<mup> Bug #1619193: Registering a snap without agreeing to terms and conditions fails opaquely <store> <Snapcraft:In Progress by psivaa> <Software Center Agent:Fix Released by fgallina> <https://launchpad.net/bugs/1619193>
<didrocks> and replace your snapcraft command with bin/snapcraft (retry doing the registration without --debug)
<lewciie> thanks didrocks!
<lewciie> it worked :)
<didrocks> lewciie: did it?
<didrocks> you didn't get an error detail?
<lewciie> no, not sure what happened... magic?
<didrocks> (without loging out/in again?)
<lewciie> I had done that bit already
<didrocks> humâ¦ sergiusens doesn't sound great, could that be another bug fixed in master? ^
<abeato> jdstrand, hey, thanks for the reviews, I've addressed all the issues
<abeato> jdstrand, there is something that I need to solve though: connection of interfaces, like mmcli connected to modemanager daemon, shows an error
<abeato> jdstrand, I changed basedeclaration to allow that, but probably the real solution is using snap-declaration. How can I do that?
<jdstrand> abeato: let me look at what you changed in the base declaration
<abeato> jdstrand, I had to remove "deny-connection: true"
<jdstrand> abeato: yes, you need to revert that change to for it to be acceptable to commit
<jdstrand> abeato: and then we would add a snap declaration
<abeato> jdstrand, I suspected that, but how can I do that?
<abeato> I want to connect mmcli to modemmanager daemon, which are in the same snap
<jdstrand> abeato: so, this is a rough edge for slot implementation interface developers since the base declaration may prevent install or connection for snaps that don't have a store signed snap declaration
<abeato> jdstrand, we need to be able to do this locally for testing
<jdstrand> abeato: (this includes installing snaps with --dangerous)
<jdstrand> abeato: I understand. today you simply fudge the base declaration like you did, then in the PR you revert that
<abeato> jdstrand, alright, will do that for the PR
<jdstrand> abeato: I brought this up with Gustavo. how to make this easier for developers needs to be discussed. maybe it will remain as fudging the base declaration but to document that
<abeato> jdstrand, that should not be the only way imho, this can get very painful
<jdstrand> abeato: so, today, modem-manager already has a snap declaration
<jdstrand> abeato: but it isn't used with a locally installed snap where you use --dangerous
<abeato> jdstrand, as you would need a hacked snapd for whatever small change you have to do to a snap
<jdstrand> abeato: again, I understand, that is why I brought it up with Gustavo
<abeato> jdstrand, noted, and thanks, just want to make sure you all know this is not a minor issue for snappers :)
<jdstrand> abeato: it probably makes sense to file a bug against snappy
<abeato> jdstrand, ack
<jdstrand> abeato: simply mentioning that the security of the base declaration requiring a snap declaration from the store is a pain point for local testing before you are ready to upload even to edge
<jdstrand> roadmr: https://myapps.developer.ubuntu.com/dev/click-apps/4874/rev/12/ is your test snap?
<jdstrand> roadmr: I ask cause choosing lxd-support as your plugs for the snap declaration test makes me twitchy (that is a super-powerful interface) ;)
<jdstrand> popey: you may want to subscribe to bug #1592022. I know what the fix is and am working on it
<mup> Bug #1592022: 32 bit applications on 64 bit system fail due to seccomp <snapd-interface> <Snappy:In Progress by jdstrand> <https://launchpad.net/bugs/1592022>
<roadmr> jdstrand: yes, it is. I'm happy to use another one (but it has to be one that would not normally pass automated review). Any suggestions?
<popey> jdstrand: yay
<roadmr> jdstrand: I'd prefer not deleting the package but I can if you feel it's safer. I updated the payloads to remove lxd-support, so at least the package will be uninstallable (as the just-updated snap-declaration doesn't allow it)
<jdstrand> roadmr: well, it is the correct one for testing 'installation'. 'mir' slot implementation would be good for 'connection'
<jdstrand> roadmr: no, it is fine. perhaps removing the snap declaration on prod after you are done would make sense (you could leave it in staging if snapd can point to staging)
<ogra_> cjwatson, hmm, shouldnt it be possible to pull stuff via wget from github during an LP snap build ? https://launchpadlibrarian.net/292935958/buildlog_snap_ubuntu_xenial_armhf_kodi-pi_BUILDING.txt.gz
<roadmr> jdstrand: it can, yes (SNAPPY_USE_STAGING_STORE=1)
<jdstrand> nice! :)
<roadmr> jdstrand: ok, I'll be extra careful when using lxd-support for testing
<abeato> jdstrand, https://bugs.launchpad.net/snappy/+bug/1640874
<mup> Bug #1640874: It is not possible to inter-connect locally installed snaps <Snappy:New> <https://launchpad.net/bugs/1640874>
<jdstrand> roadmr: I mean, you're fine. it is just that there is a snap in the store that if modified could be bad. I just like to reduce those kind of things :)
<mup> Bug #1640874 opened: It is not possible to inter-connect locally installed snaps <Snappy:New> <https://launchpad.net/bugs/1640874>
<roadmr> jdstrand: I made it private, so at least only I can get it
<cjwatson> ogra_: Currently only during the pull phase.  This will change in a bit
<ogra_> ah, k
<abeato> jdstrand, besides this issue, which is your opinion on whether the policy for plugs in classic should include just unconfined or unconfined+label? I answered your comment on the ofono PR, whatever you prefer should be the same for both mm and ofono interfaces I guess
<cjwatson> ogra_: Still good practice to fetch remote stuff in the pull phase though, I'd say
<jdstrand> abeato: thanks! I updated the description for some clarifying remarks and marked confirmed
<jdstrand> roadmr: ah, even better. thanks!
<abeato> awesome!
<ogra_> cjwatson, yeah, but then i cant get it to build
<roadmr> jdstrand: np, and do let me know if you think I should delete it alright. It's a test package so it'd be no big deal
<roadmr> s/alright/altogether/
<cjwatson> ogra_: https://code.launchpad.net/~cjwatson/launchpad-buildd/snap-proxy-allow-build/+merge/310050 anyway
<jdstrand> abeato: it should be the same. I have a todo to look at that pr today and will comment there
<ogra_> cjwatson, ah, perfect !
<abeato> jdstrand, great, thanks
<jdstrand> roadmr: if it is helpful to you, leaving it private seems fine
<roadmr> it is, I use it to test c-r-t updates :) I'll leave it there for now.
<mwhudson> davmor2: i don't understand, can you take screenshots (or photos, or something) and point out what you mean?
<ogra_> paintings !
<davmor2> mwhudson: I filed a bug https://bugs.launchpad.net/bugs/1640843
<mup> Bug #1640843: Networking fails if you touch the default route <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1640843>
<mwhudson> davmor2: are you testing stable?
<davmor2> mwhudson: yeap
<mwhudson> davmor2: i think that's fixed in edge by hiding that bit of the ui
<mwhudson> yeah
<mwhudson> in fact pitti and i realized last night that that we didn't understand what that ui was trying to achieve at all...
<davmor2> mwhudson: okay I'll have a look at edge after then, we are just writing the manual steps for everything currently
<mwhudson> davmor2: yeah, quite a bit has changed in edge, would definitely like your attention on that :)
<davmor2> mwhudson: yeah it threw me as well as it look like it was only specific to eth0 as it don't remember seeing it on wlan0 on db so was getting more and more confused with it
<davmor2> mwhudson: right I need to finish up the initial round of steps and then I can modify the cases as needs be.
<Guest56474> Hello, I was wondering if anyone would be able to help me. Running 16.04 64 bit, all up to date. Installed ubuntu-sdk and am running it as root. When I try to create a project (specifically creating a kit), I get the following error: error: Registering root is not possible. Any ideas would be greatly appreciated!
<ogra_> Guest56474, try the #ubuntu-app-devel channel instead ...
<Guest56474> Gah, apologies. Thank you!
 * davmor2 shakes his fist at mwhudson this loops on hitting enter on the second page back to the start again :(
<davmor2> mwhudson: you baypassed network config and user setup but hiding them all together ;)
<mwhudson> davmor2: eh?
<mwhudson> sounds like it might crashing, can you dig out the logs?
<davmor2> mwhudson: give me a minute
<davmor2> mwhudson: is it likely to be syslog or else where?
<davmor2> mwhudson: never mind found the subiquity log
<dpb1> hey, I was trying to use this gist to publish to edge from travis:  https://gist.github.com/evandandrea/c754964bfdfb176844f26f605ebbb8db
<dpb1> it uses a docker image 'snapcore/snapcraft', and I got this error when running it:
<dpb1> Status: Downloaded newer image for snapcore/snapcraft:latest
<dpb1> Issues while validating snapcraft.yaml: Additional properties are not allowed ('grade' was unexpected)
<dpb1> is it out of date?
<davmor2> mwhudson: see pm, I'm about to knock off for the night so if there is anything else let me know in an email and I can get it to you tomorrow
<sergiusens> dpb1 what does snapcraft --version give you?
<sergiusens> dpb1 can you pull again?
<dpb1> sergiusens: awesome, that fixed it
<dpb1> tyvm
<dpb1> is there a way to search for snaps in the edge channel?
<mup> Bug #1592022 changed: 32 bit applications on 64 bit system fail due to seccomp <snapd-interface> <Snappy Launcher:In Progress by jdstrand> <https://launchpad.net/bugs/1592022>
<bschaefer> hmm not sure why i keep getting this on yakkety? Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/g/gcc-6/gcc-6-base_6.2.0-5ubuntu11_amd64.deb 404  Not Found [IP: 91.189.91.23 80]
<bschaefer> checking... snapcraft is using the wrong version then the policy i have on the machine (not sure where its pulling the wrong path from)
<bschaefer> is my policy: 6.2.0-5ubuntu12 500
#snappy 2016-11-11
<josharenson> If I've pushed an amd64 snap to the store's stable channel, and later, push an armhf snap to the stable channel, it won't clobber the amd one I assume?
<enwei> davidcalle, ping
<om26er> Hello! How can I make available non-pypi packages to my name ? e.g. python3-gi is not available on pypi but its in Ubuntu, so how can I make that available to my snap ?
<DanChapman> om26er: you could possibly use the "nil" plugin to get python3-gi in the stage-packages
<DanChapman> there might be a better way. That's just what comes to mind
<om26er> DanChapman: I just added stage-packages to my python part and it seems to have progressed
<dholbach> good morning
<tsdgeos> $ sudo snap remove unity8-session
<tsdgeos> error: cannot remove "unity8-session": snap "unity8-session" has changes in progress
<tsdgeos> what do i do now?
<tsdgeos> ok snap changes + snap abort
<tsdgeos> and then i had to mount something in the folder it thought there was something supposde to be there
<tsdgeos> oh well
<davmor2> pitti: hey dude console-conf how do I get a login setting all the ethernet connections to none?
<davmor2> sorry network setting even
<pitti> davmor2: sorry, wrong guy for console-conf; you want mwhudson
<davmor2> pitti: ta
<morphis_> sergiusens: ping
<Mirv> yay, someone (tm) fixed the store for the content interface snaps, now ubuntu-app-platform is automatically up-to-date in the store
<Mirv> that means there's also now first arm64 version :)
<sergiusens> morphis pong
<renato__> Mirv, good morning.
<renato__> Mirv, any luck with the calculator?
<sergiusens> jdstrand hey, with stgraber we chose to use `:` (originally `/`) as a filter per architecture, not a request to install that package.
<sergiusens> jdstrand sidelined and fixable, this is another reason I don't want crt to fail on non matching architetures (although my case is arch all forced to arch specific)
<davmor2> pitti, mwhudson: https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1641110
<mup> Bug #1641110: Setting both ipv4 and ipv6 to none on a connection still gives you an ip setup <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1641110>
<davmor2> pitti: included you incase you need to be in the discussion on what to do
<ogra_> davmor2, i bet the connection is gone after a reboot ;)
<ogra_> (there is a bug about "netplan apply" on actually restarting the connection with the new setup)
<ogra_> s/on/not/
<davmor2> ogra_: nope you can ssh into the system on reboot
<ogra_> oh, really ?
<ogra_> then it is different
<davmor2> ogra_: yes set step 8
<davmor2> see even
<ogra_> step 8 is without reboot
<davmor2> ogra_: d'oh let me double check it then I thought I had rebooted with it but let me double check
<davmor2> ogra_: indeed \o/ was there another bug I can link this one too, it would explain the issue I was having with the default route too I guess right (but that is supposed to be gone in the new version)
<ogra_> davmor2, i know there is one but i cant seem to find it :(
<davmor2> ogra_: oh well I'll leave mine they can always link it
<ogra_> yeah
<ogra_> if i find my old one i'll merge them
<ogra_> just not the findings above in yours too
<ogra_> *note
<davmor2> ogra_: just did on step 9
<ogra_> :)
<Son_Goku> sergiusens, I threw a small update into LP#1602258
<Son_Goku> hmm
<Son_Goku> no lp bot thingy
 * sergiusens looks
<sergiusens> Son_Goku it is a matter of spacing LP: #1602258
<mup> Bug #1602258: Support other distributions as sources (Fedora, Mageia, openSUSE, Debian) instead of Ubuntu <centos> <debian> <fedora> <mageia> <opensuse> <rfe> <rpm> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1602258>
<Son_Goku> if there's anything I'm forgetting, let me know
<Son_Goku> ah
<sergiusens> or maybe bug  #1602258
<sergiusens> nope, just the former
<Son_Goku> :/
<sergiusens> Son_Goku some other forms work too, I am just too relaxed this week to think ;-)
<Son_Goku> I just wanted to make sure I got the highlights right
<Son_Goku> but we're not ready to start quibbling about it yet :P
<sergiusens> right, the general idea will change until it makes its form in code, even when playing with a potential PR it might feel wonky :-)
<Son_Goku> yep
<ogra_> sergiusens, hmm ... does snapcraft not take apps in the potential PATH into account at build time ? http://paste.ubuntu.com/23460983/
<ogra_> (the binary gets copied to bin/ in the target ... the check seems to only accept it if i give the full path for "command:", even though bin/ will be in $PATH)
<dholbach> hey... does anyone have an idea how I'd resolve something like this?
<dholbach> go get -t -d ./github.com/containous/traefik/...
<dholbach> github.com/containous/traefik/web.go:13:2: no buildable Go source files in /home/daniel/traefik/parts/traefik/go/src/github.com/containous/traefik/autogen
<dholbach> ok, looks like something running another command is required before running the build
<sergiusens> ogra_ can you add more details to your statement?
<ogra_> sergiusens, dunno, what more details do you need ? the dump plugin copies the script to bin/ ... then something seems to check the "command:" content if the script exists and is executable
<ogra_> (and fails because it does not seem to look in bin/ by default)
<sergiusens> ogra_ this should work, give me a snapcraft.yaml and I'll check
<ogra_> sergiusens, https://code.launchpad.net/~ogra/+junk/kodi-pi
<ogra_> (beware, the tree is huge)
<ogra_> if you want a full build log (huge as well :) ) https://code.launchpad.net/~ogra/+snap/kodi-pi
<ogra_> i'm probably totally wrong about that message though ... the above is what i interpret from the message it gave me
<ogra_> (i just changed "command: runner_kodi" to "command: bin/runner_kodi" in the last commit in that bzr tree)
<ogra_> (the build for that change is still running)
<sergiusens> ogra_ huge trees should go to git! ;-)
<ogra_> yeah yeah ...
<sergiusens> ogra_ if you dump `.` you get everything
<sergiusens> ogra_ do something like this instead https://github.com/morphis/plexmediaserver-snap/pull/3/files
<mup> PR morphis/plexmediaserver-snap#3: Update to use latest snapcraft features <Created by sergiusens> <https://github.com/morphis/plexmediaserver-snap/pull/3>
<ogra_> sergiusens, but that means the script needs to live in bin/ in the source, right =
<ogra_> ?
<sergiusens> ogra_ yeah, is that a problem?
<ogra_> nah, just wanted to make sure ... a test build takes 1.5h :)
<ogra_> i still dont get why we couldnt keep the copy plugin around ...
<ogra_> it was easy to understand ... for dump i need to ask someone nearly every time i use it ... way to complex
<sergiusens> ogra_ soon these wrapper scrips will be a thing of the past ;-)
<sergiusens> oh that's a big one though :-P
<ogra_> i think thats an upstream one
<ogra_> that isnt originally my tree ... i'm just trying to make it build in LP currently
<ogra_> (with plenty of awful hacks (as usual :P ))
 * ogra_ fires off another build
<dholbach> I was just chatting to somebody who has build artifacts for four architectures which they would probably just dump into a snap - what would be the best way to snap and publish them?
<dholbach> Or rather... dump into four different snaps.
<ogra_> dholbach, one way is to wrap it into a Makefile that checks the build arch ... but i guess sergiusens would call that cheating ;)
<ogra_> (checks and acts arch specific then)
<sergiusens> I was working on an idea of per architecture parts but we are scaling down on features as people are starting to get lost in a sea of options
<sergiusens> dholbach you can just create for parts and dump it into the snap
<ogra_> dholbach, https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial/tree/Makefile?id=ed92e3a0272c85c2640ca42322e799fcf69a9034 is an example
<sergiusens> set architectures in snapcraft.yaml to the corresponding ones
<ogra_> yeah, that would be helpful
<sergiusens> ogra_ well not going to happen for the time being, Makefiles or build systems is the way
<abeato> sergiusens, hey, noticed this: bug #1641123
<mup> Bug #1641123: snapcraft does not properly detect the architecture when kernel is 64 bits but userspace is 32 <Snapcraft:New> <https://launchpad.net/bugs/1641123>
<ogra_> but a good thing to have on the TODO
<sergiusens> ogra_ it is labeled NO in the inbox of tasks ;-)
<ogra_> :(
<sergiusens> NOs can be YES in the future, albeit distant
<sergiusens> abeato force the architecture as I mentioned just above
<abeato> sergiusens, hmm do not see that
<ogra_> just "architecture: i386" in your snapcraft.yaml
<abeato> oh, I see, thanks
<sergiusens> ogra_ abeato architectures: [armhf]
<Mirv> renato__: no, getting qml: [LOG]: Unable to calculate formula : "98+66", math.js: SyntaxError: Parse error
<renato__> Mirv, ok I am trying to discovery which file is missing
<abeato> sergiusens, ack
<ogra_> oops, indeed
<Mirv> renato__: actually, I think it might be that you're testing it (when not using platform snap) without xenial overlay, would I be right?
<dholbach> sergiusens, do we have an example of that?
<Mirv> renato__: in that case it wouldn't be platform snap issue, but the fact that calculator doesn't work properly with Qt 5.6. I've existing bug about it.
<Mirv> renato__: if you're using stock xenial, you have Qt 5.5
<renato__> Mirv, could be, let me try to pack it with overlay
<renato__> I have a vm with that
<dholbach> sergiusens, ogra_, just so I understand it correctly: one architectures: [armhf, ...] entry and then a specific  architecture: armhf  entry in the relevant part?
<renato__> Mirv, yes you are right the problem is related with qt version
<ogra_> dholbach, no, that was what sergiusens mentioned as possible future plans
<sergiusens> dholbach yeah, you are just dumping binaries, right?
<dholbach> sergiusens, that's how I understood them, yes
<renato__> popey, ^^
<popey> ah
<renato__> popey, who can help us on that? Looks like the mathjs does not work with qt5.7
<popey> is it an upstream bug with math.js? if so, I'd file a bug on their github page
<popey> they're pretty responsive
<renato__> popey, https://bugs.launchpad.net/ubuntu-calculator-app/+bug/1620333
<mup> Bug #1620333: calculator doesn't calculate: parse error in math.js <Canonical System Image:Confirmed for popey> <Ubuntu Calculator App:Incomplete> <https://launchpad.net/bugs/1620333>
<popey> I mean, is it a bug in the upstream math.js library we're using?
<renato__> popey, I can try create a small test if that helps
<popey> or is it a bug in qt?
<popey> it probably would, yes
<renato__> popey, I think this is a qt bug. But honestly I do not even know where to start :D
<popey> would file upstream at https://github.com/josdejong/mathjs/issues
<popey> heh, me neither!
<popey> need a qt person
<renato__> popey, we can try report a bug on mathjs project to see if they give us any hint
<Mirv> renato__: ok, so practically calculator "works", it's just it has problems with Qt version. great!
<renato__> Mirv, looks like that
<popey> yeah
<ogra_> YAY !
<ogra_> Priming kodi
<ogra_> Snapping 'kodi-mir' ...
<mup> Bug #1641132 opened: no way to include devmode snaps in snap prepare-image? <Snappy:New> <https://launchpad.net/bugs/1641132>
<mup> PR snapcraft#898 opened: Revert "Allow for architecture-specific packages (#876)" <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/898>
<Suraj311> Plz help me
<Suraj311> my pi 3 keep asking about connection
<Suraj311> How to configure wlan at first time boot with ubuntu core
<ogra_> you can not (as noted in the release notes)
<Suraj311> is there any windowX environment for configuring the network
<Suraj311> ?
<ogra_> configure it with cable attached ... then log in and run "sudo console-conf" to re-configure it for wifi (adn turn off ethernet)
<Suraj311> i don't have LAN
<Suraj311> i only have mobile internet
<Suraj311> i am using internet by hotspot
<ogra_> well, there is currently no way to configure wlan on first boot on a pi3 ...
<ogra_> (there is a bug with the driver)
<Suraj311> is there any way by tethering?
<Suraj311> usb tethring?
<ogra_> nope
<Suraj311> :(
<ogra_> you need ethernet ... the next image releasse will hopefully fix this
<Suraj311> then is ubuntu mate will be good for IOT development?
<ogra_> why not :)
<Suraj311> Ok thanx Ogra_
<Suraj311> will go for mate
<ogra_> (i dont think it matters what you use on your desktop for IoT development ...)
<mup> PR snapd#2270 opened: store: check payment method before TOS for a better UX <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2270>
<mup> Bug #1641150 opened: snap hooks are not run with environment similar to apps: PATH, LD_LIBRARY_PATH <Snappy:New> <https://launchpad.net/bugs/1641150>
<Bits4Bytes> Can you package closed source programs into snaps?
<ogra_> why woldnt you
<ogra_> snaps are binary packages, they dont really care ...
<qengho> Bits4Bytes: Yes! That's one of the goals!
<ogra_> if you create an account in the store you need to sign that you have the distribution rights for the software you upload though ...
<qengho> Bits4Bytes: It used to be that to be safe, someone had to review code put into Ubuntu and others. The isolation of snaps lets Ubuntu+ get out of the way and let people publish without hurting users.
<ogra_> (so just grabbing random closed source binaries off the internet will likely not work if they are not distributable legally)
<Bits4Bytes> Not going to publish it. I have a java program that I'd like to run on a Snappy Ubuntu Core on a Rasberry Pi.
<dholbach> have a great weekend everyone!
<popey> https://www.gl-inet.com/mt300a/ is a neat thing (which would probably be nice with snappy)
<popey> ooh, they sell them on amazon
<popey> https://www.amazon.co.uk/GL-MT300A-Ext-MicroSD-pre-installed-Repeater-Tethering/dp/B01EWCO7CS
<mup> PR snapcraft#898 closed: Revert "Allow for architecture-specific packages (#876)" <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/898>
<mup> PR snapcraft#899 opened: Release changelog for 2.22.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/899>
<mup> PR snapcraft#899 closed: Release changelog for 2.22.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/899>
<mhall119> zyga: can you tell me what I'm doing wrong with my configure hook? http://paste.ubuntu.com/23462794/
<qengho> mhall119: I just fought this. I think your snapd is not new enough.
<qengho> mhall119: and that you're on snappy on classic, amirite?
<mhall119> right, on 16.04
<qengho> mhall119: You just gotta wait. :(
<qengho> ...I think.
<mhall119> that's not my forte :)
<qengho> mhall119: You just gotta compile it on your own. :)
<mhall119> that's also not my forte :)
<qengho> mhall119: You just gotta complain to zyga until he cracks.
<qengho> mhall119: I have two packages that use it. Fine on a snappy core box.
<qengho> mhall119: "sshesame" and "tor-middle-relay" in candidate channels.
<qengho> mhall119: http://bazaar.launchpad.net/~privacy-squad/+junk/sshesame-snap/view/head:/snapcraft.yaml#L18
<mhall119> not complaining to zyga, that's something I'm good at
<mhall119> s/not/now/
<CountryfiedLinux> howdy
<CountryfiedLinux> Will there be a time when an Ubuntu install is all snappy packages by default?
<CountryfiedLinux> Right now it's up to the user to figure out which packages have snaps. It would be nice for there to at least be a snappy edition.
<qengho> CountryfiedLinux: Not in foreseeable future. Some things may transition to snapps altogether, like maybe libreoffice. But there will be deb for a long long time.
<qengho> Some deb could be transitional empty packages that install snaps, but others will be deb "forever".
<CountryfiedLinux> qengho, Perhaps someone will take the initiative of making a Snappy edition with a graphical Snappy Store. Maybe :)
#snappy 2016-11-12
<mup> Bug #1602323 changed: Add FTP support for remote files <Snapcraft:In Progress by 3v1n0> <Snappy:Invalid> <https://launchpad.net/bugs/1602323>
<mup> PR snapcraft#900 opened: ftp source support <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/900>
<andywork> what may be the reason for some libs to be discarded from "stage-packages", and never make it into the final snap?
<andywork> and how am I supposed to use the "dump" plugin exactly (which is supposed to replace "copy"), when I cannot specify *what* files to put into the snap
<andywork> now with the dump plugin, it does just that, dump *everything* regardless what I put in the "organize" property
<andywork> this is pretty awful, because there seems to be no clean way to copy a single file into the snap
<v2> hi friends....
<v2> sorry....i might be asking the wrong question here...
<v2> can ubuntu core be installed on my laptop?
<sergiusens> andyrock organize organizes whatever you told it to dump; what files to put in the snap are filtered with stage and snap keywords
<popey> andyrock: the dump plugin hasn't replaced the copy plugin (yet) so I continue to use copy for now
<popey> I think the deprecated message was put into snapcraft too early
<andyrock> andywork: ^^^
<gpnt> hello
<gpnt> I have a problem/question: Today I was trying out ubuntu core on raspi 2. Installation, login an everything was no problem. So I created on my host-pc a cross-compiled snap for arm devices. But when I upload this snap to the store I can only install it on my host pc via 'snap install myapp'. On the raspberry pi it tells me, the snap was not found. How can I publish the app to work on my raspberry pi?
<gpnt> Okay, found out that you have to put an 'architecture: [armhf]' to the snapcraft.yaml. Why is this information not in the official documentation?
<john__> hi - i just tired installing ubuntu core kvm on my ubuntu machine
<john__> something went wrong
<john__> how do i kill this instance
<john__> so that i can create a new one
<john__> i followed the instructions on the home page
<john__> any help will be highly appreciated
<john__> is anyone in this chat room besides me?
<andywork> sergiusens: hi, can you show me how?
<andywork> or better yet can ANYONE show me how to do that?
<Elleo> what's the situations with the home interface? are snaps that use it allowed in the store and if so does it have to be manually connected?
<qengho> Elleo: We refuse to surprise users. If an app could irreversably harm, then the user has to give it permission. Hey, want to install my  rm_-rf_~  snap?
<OsakaFoo> could someone point me to some docs which can convince me that my 'snapped' application is okay to be running under root
<Elleo> qengho: so they are allowed in the store then? but with manual connection?
<qengho> Elleo: I don't know much about the store, but I think if it's well-known and open-source then it has a good chance of passing store review. But that's a guess.
<qengho> OsakaFoo: A normal app, run by the user is running as that user. A daemon will run as root. In both cases, AppArmor and seccomp filters prevent it from accessing very much. You can verify in  /var/lib/snapd/{apparmor,seccomp} .
<qengho> OsakaFoo: We can't prove a negative, so we can only invite you to try to break out and see how it fails.
<OsakaFoo> qengho: :)
<OsakaFoo> I shall heck out the profiles
<OsakaFoo> whats the best way to keep a snap package uptodate?
<andywork> hey can I get some help getting my .yaml right
<andywork> look here: http://pastebin.com/9ASLvD3b
<andywork> if I uncomment the "#"-lines, some libs from stage-packages never makes it into the final snap
<qengho> OsakaFoo: Do nothing. You get updates automatically.
<qengho> andywork: Those lines add a filter of things you want to install. You stage things and then don't install them, and that's weird.
<Son_Goku> so I wasn't nuts about LP<->rhbz, it really is disabled: https://bugs.launchpad.net/bugs/bugtrackers/redhat-bugs
<andywork> qengho: what should it look like then?
<OsakaFoo> whats the best way to pass a SSL cert to a snapped deamon?>
<OsakaFoo> qengho: thanks - I like that plan
<qengho> OsakaFoo: $ sudo snappedthing.import <cert.txt
<qengho> OsakaFoo: $ sudo cp cert.txt $(snappedthing.print-cert-location)
<OsakaFoo> hmm
<OsakaFoo> I can't seem to find that
<qengho> OsakaFoo: Did you invent "snappedthing" yet?
<OsakaFoo> yes, its ejabberd in a snap
<qengho> OsakaFoo: Did you make an app in your yaml called "print-cert-location"?
<qengho> OsakaFoo:     command: bin/echo $SNAP_DATA/osakafoochoiceforcertname
<qengho> OsakaFoo:     command: bin/echo $SNAP_DATA/orWhateverOFsDaemonExpectsHere
<andywork> qengho: do you have a minute to help me out?
<OsakaFoo> qengho: I think I might have missunderstoon the term invent
<OsakaFoo> I am not writting a snap package, simply using one
<OsakaFoo> the ejabberd, snap
#snappy 2016-11-13
<isimorgh> Hi all.
<isimorgh> You have probably been asked this question so many times before.
<isimorgh> I have set up my system as per https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ but everytime I enter my password, it is wrong.
<isimorgh> I can't even login on the local machine.
<isimorgh> and every time I ssh into the device it asks me for password. but according to the website it shouldn't ask for for password
<isimorgh> I don't understand how I should login.
<isimorgh> anybody?
<isimorgh> appreciate any help.
<isimorgh> isimorgh@10.0.1.124's password:
<isimorgh> Access denied
<isimorgh> isimorgh is the same username that I have on Ubuntu SSO
<isimorgh> i really don't get it/
<isimorgh> kind of frustrating
<peetamber> hii
<peetamber> hiii
<peetamber> hii
<dkessel> hey there.  i am trying to find information on whether it is possible to install traditional apt/deb-based packages on ubuntu core 16. is that still possible? if so, will it create conflicts of problems with other (snap) packages, or with the update-ability of the core system?
<dkessel> i need deb-based packages for my printer attached to the home server...
<Son_Goku> dkessel, you cannot
<Son_Goku> the whole point of ubuntu core is to not support any other mechanism for software installation
<dkessel> i thought maybe those parts could be placed in some isolated container or something
<zyga> dkessel: you can use the classic snap for a regular apt-get environment but it has some intrisic limitations
<zyga> dkessel: you may be able to work with a few people working on packaging cups as a snap
<zyga> Son_Goku: hey
<zyga> Son_Goku: how are you
<Son_Goku> alright, you?
<zyga> Son_Goku: looking forward for Monday
<zyga> Son_Goku: I had a week off and I badly needed it
<zyga> Son_Goku: I'm running F25 now, trying to wrap my head around various selinux bits
<zyga> Son_Goku: there are more and more and more bits that end up broken when enforcing mode is on :/
<zyga> Son_Goku: is there any software in fedora that works with selinux in permissive mode but is in the archive?
<zyga> Son_Goku: I found a few more issues in snap-confine, the capabilitiy bits don't suffice, some mounts fail
<Son_Goku> generally no
<zyga> Son_Goku: but I'll trace that back to what is needed, I suspect that we may need full root
<zyga> Son_Goku: (so setuid bit)
<Son_Goku> either the policy is supplied as a module package, or it is part of fedora-selinux policy
<zyga> Son_Goku: ok
<Son_Goku> flatpak, luckily, doesn't need a special policy because of how restrictive its scope is
<Son_Goku> and snappy, unfortunately, cannot speak selinux yet
<zyga> Son_Goku: it's all doable, we just need more experience
<Son_Goku> yes
<newbie_> does anyone knows where I can find more information on parts? I read the documentation, but wasn't enough :/
<mup> PR snapcraft#901 opened: Basic 'enable-travis' implementation <Created by cprov> <https://github.com/snapcore/snapcraft/pull/901>
#snappy 2017-11-06
<Son_Goku> yay...
<Son_Goku> somebody broke the packaging for snapd in Fedora in snapd git
<Son_Goku> I think I'm going to have to resync from Dist-Git asap
<Son_Goku> it's also broken for 2.29
<mborzecki> morning
<mborzecki> mvo: morning
<kalikiana> moin moin
<mborzecki> guys, what's with the nested functions in libsnap-confine-private?
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mvo> mborzecki: good morning! what in particular? this is mostly the baby of zyga, however review/cleanup is always good
<mvo> mborzecki: it might have gotten less reviews than the average other code we have
<mborzecki> yeah, i was a bit tired with arch fixes so i went on and tried checking the lower level C bits with sparse and now build it with clang
<mvo> mborzecki: well, thats not true, it got a different kind of reviews, very security focused mostly
<mvo> mborzecki: cool, what are your findings so far?
<mborzecki> a bunch of signed/usigned comparisons
<mvo> mborzecki: we ran it through coverity a while ago
<mvo> mborzecki: aha, neat, lets fix those
<mborzecki> sprinkled some statics here and there, added voids in function arguments where possible
<mborzecki> clang chokes on nested functions though, I don't think it's actually supported outside of gcc
<mborzecki> btw. that's actually weird that coverity did not pick up signed/unsigned stuff, i remember it to be very picky
<mvo> mborzecki: indeed, not sure what happend, maybe it was too long ago, I would have to check my mail history. having some static analyizing that happens regularly as part of each build ideally would be way better
<mborzecki> yeah, i'll tune CFLAGS there to something more useful, it's -Wall -Werror right now, there should albo be -Wextra at least
<mvo> mborzecki: +1
<mvo> mborzecki: great to have a fresh new set of eyes looking at this
<mup> PR snapd#4150 opened: ifacestate: make interfaces.Repository available via state cache <Created by mvo5> <https://github.com/snapcore/snapd/pull/4150>
<zyga-ubuntu> o/
<zyga-ubuntu> good morning
<mvo> hey zyga-ubuntu
<zyga-ubuntu> hey, sorry for starting late today
<zyga-ubuntu> how are things?
<mborzecki> zyga-ubuntu: hey
<zyga-ubuntu> hey :)
<mvo> zyga-ubuntu: things are mostly good, a test failure for 2.29.2 on pi3 which is annyoing but mostly test breakage not real issues it seems
<mvo> zyga-ubuntu: i.e. arm seems to return EPERM for cgroup access denials and x86 EACCESS
<zyga-ubuntu> oh
<zyga-ubuntu> that's intereting
<zyga-ubuntu> just last week I recall jdstrand and tyhicks discuss EPERM vs EACCSS on various syscalls
<zyga-ubuntu> it seems that it varies from one syscall to another
<mvo> and annoying because it means 2.29.2 is not in candidate yet :/
<zyga-ubuntu> and thus, perhaps, varies from arch to arch
<mvo> yeah, the pattern isnot consistent
<sergiusens> mvo are you guys paying attention to the adt results?
<mvo> sergiusens: generally speaking yes, things were very slow with the opening of bionic so we may have missed some data because of this in the most recent few days. why?
<mvo> sergiusens: all releases go through the regular autopkgtest distro testing so yes, we are generally autopkgtest clean
<sergiusens> mvo oh, because of the slowness, was wondering if you where interested in our approach of launching them on demand (after a review) so resources don't starve
<sergiusens> there are many tests for the same branch of a snapd PR enqueued, which I guess comes after minor review fixes and such
<zyga-ubuntu> I think adt could use the concept of travis automatic job cancellation
<zyga-ubuntu> so only one such instance exists for the same branch (the latest one)
<mvo> sergiusens: we are definitely interessted, cachio was working on this, but because of other work this is a bit slow going crrently
<sergiusens> zyga-ubuntu yeah, it is nice to think of ideals others can do, and there is a bug for that; I am talking about things we can do ;-)
<zyga-ubuntu> sergiusens: no disagreement there
<mvo> sergiusens: yeah, we definitely want to stop starving the distro
<mvo> sergiusens: and there is work, its just slow right now because of other duties
<mvo> sergiusens: I will connect you with cachio, sounds like you guys have figured it out already
<mvo> sergiusens: or is it trivial? if so I can have a look in a bit myself
<sergiusens> mvo zyga-ubuntu we have a telegram and irc bot if interested. We've been using this approach for a while now
<sergiusens> mvo for hooking up; elopio and cachio could hook up and discuss
<zyga-ubuntu> sergiusens: I saw you use this multiple times and I was indeed intrigued
<zyga-ubuntu> sergiusens: it seems like a better way to use our resources, last-phase test after review and travis say it's oK
<sergiusens> most of it is based out of this https://github.com/snapcore/snapcraft/blob/master/tools/retry_autopkgtest.sh
<sergiusens> zyga-ubuntu that is what we do; we also run a nightly with travis' cron for sanity checks
<sergiusens> I don't know if you suffer this, but we get dns/proxy errors all the time on non-x86 so running on every PR just became noise
<zyga-ubuntu> no, we don't suffer those
<sergiusens> yeah, I guess we hammer the system a bit more given we build stuff for like 3 hours min for every run :-P
<mvo> sergiusens: cool, thanks. do you know where the result of the runs are stored? or is retry-github-test synchronous ?
<sergiusens> mvo it adds the entry to the PR (just as if it were triggered by the webhook)
<mvo> sergiusens: sweet
<sergiusens> mvo if you want more automation that having to trigger, you cold run something like that script as the last step of your travis run (keeping the secret as an encrypted var on travis)
<mvo> sergiusens: btw, are you up early or traveling (if I may ask :)
<mup> PR snapd#4151 opened: tests: fix security-device-cgroup* tests on devices with framebuffer <Created by mvo5> <https://github.com/snapcore/snapd/pull/4151>
<zyga-ubuntu> wow, nice!
<zyga-ubuntu> approved, thank you mvo!
<sergiusens> mvo I woke up at 4am; just early ;-)
 * mvo hugs sergiusens 
<sergiusens> there's just so much to do and so little time
<mborzecki> where can I get spread images?
<zyga-ubuntu> mborzecki: you can build them youself or get them from spread.zygoon.pl
<zyga-ubuntu> spread images are just images with well known user/password
<zyga-ubuntu> nothing maic
<zyga-ubuntu> *magic
<zyga-ubuntu> if you have a way please contribute a build command for arch linux
<zyga-ubuntu> I can refresh my images periodically (just was too lazy to set it up before)
<mborzecki> ok
<mborzecki> my first time using spread :) i'll probably have a lot of questions, so bear with me
<zyga-ubuntu> gladly :)
<mup> PR snapd#4152 opened: snapd: fix snap cookie bugs <Created by stolowski> <https://github.com/snapcore/snapd/pull/4152>
 * zyga-ubuntu reads 4152
<mup> PR snapd#4153 opened: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup lowe level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153>
<mup> Issue snapcraft#1658 opened: Map of supported bases to containers <design-required> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1658>
<mup> Issue snapcraft#1659 opened: Schema support for supported bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1659>
<mup> Issue snapcraft#1660 opened: Container passthrough for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1660>
<zyga-ubuntu> mborzecki: are you trying to build snap-confine with clang?
<mborzecki> yeh, it builds now
<mup> Issue snapcraft#1661 opened: Walk the prime directory for elf files (in lifecycle) <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1661>
<mup> Issue snapcraft#1662 opened: patchelf with ld-linux <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1662>
<mup> Issue snapcraft#1663 opened: patchelf with common rpath (not runpath) <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1663>
<zyga-ubuntu> mborzecki: is clang becoming a default in arch?
<mborzecki> not that I know of
<zyga-ubuntu> so why?
<mup> Issue # opened: snapcraft#1664, snapcraft#1665, snapcraft#1666, snapcraft#1667, snapcraft#1668
<mborzecki> to start with, clang is usually better with finding errors, but the best outcome is to usually build the code with both gcc and clang
<mborzecki> and then you have initiatives like debian clang, that try to rebuild the whole archive using clang
<zyga-ubuntu> I think that unless we can test build this with clang it will quickly bitrot
<zyga-ubuntu> I don't mind the initiative just hoping it can stay something we really support (or not) but explicitly
<mborzecki> well, i left a note about this in the PR, 'We should aim to integrate at least clang builds into the CI pipeline.'
<mborzecki> and basically that's why i asked about spread images
<mup> Issue snapcraft#1669 opened: patchelf with ld-linux from the future <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1669>
<mup> Issue snapcraft#1670 opened: Change file migrations such that files move from stage to prime rather than coming from the part each time <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1670>
<mup> Issue snapcraft#1671 opened: Rename prepare/build/install to pre-build/build/post-build, and deprecate prepare/build/install <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1671>
<mborzecki> if this does not make sense, feel free to point that out and I'll stop with the PR that's already opened
<mup> Issue # opened: snapcraft#1672, snapcraft#1673, snapcraft#1674, snapcraft#1675, snapcraft#1676, snapcraft#1677
<mup> Issue snapcraft#1678 opened: Support for set-summary <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1678>
<mup> Issue snapcraft#1679 opened: Support for set-name <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1679>
<mup> Issue snapcraft#1680 opened: Documentation overhaul for pre/post and setters <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1680>
<zyga-ubuntu> mborzecki: I think it's fine, just trying to understand your motivation better
<pstolowski> pedronis, hey! i've proposed the PR for cookies problem. re your questions from Friday about why cookie is not removed in UnlinkCurrentSnap for example - it's deliberate. we're interested in having a single cookie for given snap regardless of revisions or whether the snap is enabled or disabled. we create the cookie when we install the snap for the first time, and we remove the cookie when the last revision is discarded
<pedronis> pstolowski: ok, I'll look at it with that in mind
<pstolowski> thanks
<Chipaca> i thought we weren't adding more patches until we got epochs working?
<zyga-ubuntu> Chipaca: I think this patch is "special"
<zyga-ubuntu> Chipaca: it's not really a patch
<zyga-ubuntu> we could even do it in one of the managers at startup
<Chipaca> it still breaks reverts
<Chipaca> so the reason we're not doing patches is still there
<zyga-ubuntu> just by virtue of incrementing the patch level?
<Chipaca> yes
<zyga-ubuntu> ah
<zyga-ubuntu> then yes, it cannot be a patch
<pedronis> as not a patch it will need a flag, that we can remove when we have patches I suppose
<pedronis> mvo: I cannot make the standup, but we need to talk with Gustavo about moving  snapctl start/stop/... etc from 2.29 to 2.30 in the roadmap topic
<mup> Issue snapcraft#1681 opened: Make architectures grammar-powered <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1681>
<mvo> pedronis: sure, I will raise that
<mup> Issue # opened: snapcraft#1682, snapcraft#1683, snapcraft#1684, snapcraft#1685
<mvo> pedronis: 4150 is something I would appreciate your review, should be (hopefully) easy as its closely copied^Wmodelled after how the assertdb is handled
<ackk> Chipaca, hi, I added some comments/replies on https://github.com/snapcore/snapd/pull/3916
<mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
<Chipaca> ackk: yep, it's in my queue
<pedronis> mvo: I'll look at it today
<ackk> Chipaca, thanks. I addressed some of the comments, fwiw
<mvo> pedronis: thank you
<mborzecki> zyga-ubuntu: do you think splitting tests/unit/c-unit-tests into c-unit-tests-gcc & c-unit-tests-clang will be enough?
<zyga-ubuntu> mborzecki: yes
<zyga-ubuntu> mborzecki: that's fine and it will clearly show what's what
 * pedronis lunch+dentist appt
<mborzecki> testing this locally now
<mborzecki> also made me go through how spread testing is setup, looks like adding arch will not be that complicated
<zyga-ubuntu> most of the complexity is concentrated in "prepare.sh" where we build snapd and prepare the system for testing
<mborzecki> while i'm waiting for spread to finish, did anyone get a chance to look at https://github.com/snapcore/snapd/pull/4135#issuecomment-342002622 ?
<mup> PR #4135: cmd/{snap-seccomp,snap-confine-ns},osutil,interfaces/account_control: workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135>
<mborzecki> i'm leaning towards removing tests/main/static and i'm not sure this would be acceptable, but the packaging (fedora, suse) do not build snapd statically, so I don't know what exactly this tests is supposed to check
<Chipaca> mborzecki: if it's the CGO_ENABLED check, it was because we'd had problems with cgo stuff sneaking in through depends that was impacting memory consumption at one point
<zyga-ubuntu> mborzecki: commented on your questions
<Chipaca> and that was an easy way to block it
<mborzecki> ok, so one alternative way to fix this is to drop CGO_ENABLED=0 and set -extldflags, we can keep the test this way
<Chipaca> mborzecki: how would that alert us of new cgo bits we didn't know about?
<Chipaca> (that's basically what we need)
<mborzecki> i won't, but it doesn't build now either, it did build before because no cgo built pieces were called yet
<Chipaca> mborzecki: well, that's the whole purpose of the test, if it's not working why have it?
<mborzecki> i could probably rework the group stuff to not call the c library, but instead parse /etc/groups directly, but this is half solution only, and probably 100% correct on musl systems only as glibc is happy to use nss instead
<zyga-ubuntu> pstolowski: reviewed
<niemeyer> Hello hello!
<niemeyer> mborzecki: Welcome!
<mborzecki> niemeyer: hey
<mvo> hey niemeyer - welcome back
<niemeyer> mvo: Thank you
<niemeyer> Glad to be back
<zyga-ubuntu> hey
<mborzecki> zyga-ubuntu: pushed clang test as well
<pstolowski> thanks zyga-ubuntu
<pstolowski> hey niemeyer !
<Chipaca> mborzecki: what if we just have panic'ing stubs for the no-cgo build? just for this check?
<niemeyer> Heyos!
<mborzecki> Chipaca: yeah, this might work
<zyga-ubuntu> mborzecki: I just sent my review, let me read the new parts
<kalikiana> hrm, failing to see the forest for the trees, time for a break
<zyga-ubuntu> mborzecki: added two more comments
<zyga-ubuntu> mvo: what shall I do with https://github.com/snapcore/snapd/pull/4146 ?
<mup> PR #4146:  interfaces: fix udev tagging for hooks (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4146>
<mup> Issue snapcraft#1686 opened: Support strings in grammar <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1686>
<mup> Issue snapcraft#1687 opened: Make source grammar-powered <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1687>
<mup> Issue snapcraft#1688 opened: Documentation for advanced grammar for sources <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1688>
<mup> Issue snapcraft#1689 opened: Implement "on" and "from" selectors (statements) in project_loader <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1689>
<mvo> zyga-ubuntu: lets leave it for now if we need a .3 I think we can consider it
<mvo> zyga-ubuntu: I did not had the mental capacity last friday to include it
<mup> Issue snapcraft#1690 opened: Design quilt support <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1690>
<mup> Issue snapcraft#1691 opened: Implement quilt design <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1691>
<mup> Issue snapcraft#1692 opened: snapcraft quilt tutorial <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1692>
<mvo> zyga-ubuntu: what would happen if we build snap-cofnine with g++ (i.e. using c++ rules for the C part)? would it explode in size?
<zyga-ubuntu> mvo: not sure, why would you want that?
<mvo> zyga-ubuntu: to avoid having to write "foo(void)" when I mean "foo()"
<mup> Issue snapcraft#1693 opened: Develop metadata handler system <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1693>
<mup> Issue snapcraft#1694 opened: Develop appstream handler <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1694>
<zyga-ubuntu> mvo: I don't think that's a very strong reason honestly
<zyga-ubuntu> mvo: it's not C vs C++, just particular -W flag
<zyga-ubuntu> perhaps we need to default to C99 or more recent
<mvo> zyga-ubuntu: I checked and it seems C99 is also considering f() as unknown vs f() as empty (which is what we want)
<zyga-ubuntu> f() as unknown?
<mvo> zyga-ubuntu: well, maybe not, it just annoys me that backward compatiblity to 1877 requires us to write a clunky f(void) when e.g. c++ gets this right
<mvo> zyga-ubuntu: yes, it means "don't assume anything about arguments"
<mup> Issue snapcraft#1695 opened: Refactor meta into package <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1695>
<mup> Issue snapcraft#1696 opened: Add schema checking for snap.yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1696>
<mup> Issue snapcraft#1697 opened: Documentation for sources of information extraction <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1697>
<mvo> zyga-ubuntu: f() means that
<mvo> zyga-ubuntu: and apparently its for compatibility with older C programs (i.e. before K&R C). which makes me even more sad
<mup> Issue # opened: snapcraft#1698, snapcraft#1699, snapcraft#1700, snapcraft#1701, snapcraft#1702, snapcraft#1703
<mup> Issue snapcraft#1704 opened: Add unit tests for error classes <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1704>
<mup> Issue snapcraft#1705 opened: Remove the current tests that assert exact error messages and only assert on the error class <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1705>
<cachio> mvo, hey
<niemeyer> mvo: Hey, did you start on monthly refresh scheduling already?
<mvo> niemeyer: I have not started on this yet, I have started on the refresh-control things we talked about before (via snapd-control)
<mvo> hey cachio
<cachio> mvo, waiting for the confirmation of the cert team
 * zyga-ubuntu ->coffee
<niemeyer> mvo: Cool, I'm talking to mborzecki and will suggest he pick up that plus timer services shortly after it, if you're okay with that
<cachio> mvo, other thing, did you take a look to the gsettings app?
<cachio> snap
<mvo> cachio: still not, sorry :/
<mvo> cachio: is there an open PR for this?
<mvo> niemeyer: sure, thats fine
<cachio> mvo, no yet, waiting for the snap in the store
<mvo> cachio: aha, ok. is it blocking on me uploading it?
<cachio> mvo, I sent the branch, do you need it?
<cachio> mvo, yes
<mvo> cachio: if you could mail me the PR again, that would be great
<cachio> mvo, there is a branch
<cachio> mvo, should I create a PR?
<cachio> mvo, it is gonna fail
<mvo> cachio: branch is enough, just pass me the link and I have a look
<mvo> cachio: but after lunch, gtg now :)
<cachio> mvo, sure, thanks
 * Chipaca dances
 * Chipaca stops for lunch
<mup> PR snapd#4154 opened: overlord/snapstate: support completion for command aliases <Created by chipaca> <https://github.com/snapcore/snapd/pull/4154>
<Son_Goku> mvo, you guys somehow broke snapd packaging for Fedora
<Son_Goku> it doesn't compile anymore
<Son_Goku> gobuild: invalid option -- '-'
<Son_Goku> error: Unknown option - in gobuild(o:)
<Son_Goku> error: line 370: %gobuild -o bin/snap-update-ns  --ldflags '-extldflags "-static"' $GOFLAGS %{import_path}/cmd/snap-update-ns
<zyga-ubuntu> Son_Goku: there's some tricky quoting there
<Son_Goku> I already fixed this in my spec in Dist-Git
<zyga-ubuntu> ah wait
<zyga-ubuntu> no
<zyga-ubuntu> s/bin/cmd/
<Son_Goku> yeah you just can't do what you did
<zyga-ubuntu> this is fixed in mater
<Son_Goku> nope, master is broken too
<Son_Goku> I tried
<zyga-ubuntu> ??
<zyga-ubuntu> what cannot you do?
<Son_Goku> %gobuild does not let you pass --ldflags
<zyga-ubuntu> the problem there is "bin => cmd"
<Son_Goku> -o is the *output file*
<zyga-ubuntu> ah
<zyga-ubuntu> sorry, I must confused this with similar opensuse issue
<Son_Goku> yeah, openSUSE issue is different
<Son_Goku> their %gobuild macro works differently
<Son_Goku> much more complicated
<zyga-ubuntu> Son_Goku: hmm, but we do build s-u-n statically
 * zyga-ubuntu wonders
<mup> Issue snapcraft#1706 opened: Summary of errors at the end of build <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1706>
<mup> Issue snapcraft#1707 opened: New UX for travis CI enablement <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1707>
<mup> Issue snapcraft#1708 opened: Implement new design for travis CI UX <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1708>
<mborzecki> it's -ldflags not --
<mborzecki> Son_Goku: ^^
<Son_Goku> ah
<jdstrand> mvo: thank you for doing 4151
<zyga-ubuntu> jdstrand: hello
<jdstrand> hey zyga-ubuntu :)
<jdstrand> mvo: I wonder if we should load a framebuffer module if /dev/fb0 doesn't exist instead of mocking it
<ogra_> jdstrand, that might be tricky ... some of the framebuffer modules clash with kms
<ogra_> (if we ever get armhf added to the tests)
<jdstrand> I'm surprised that none of the VMs have an actual device. my Ubuntu Core 16 vm has one
<jdstrand> I guess cause I chose qxl as the driver
<ogra_> x86 should be okay with that though
<jdstrand> ogra_: interesting
<jdstrand> mvo: maybe instead of loading it, perhaps we should configure (at least some of) the VMs to have a framebuffer (eg, qxl or similar)
<jdstrand> mvo: and then it would autoload. I was obviously thinking that the vms would have a framebuffer (all of mine do locally), but if nothing in the test infrastructure does, it means the test is rather pointless
<mvo> Son_Goku: what is the build error?
<Son_Goku> mvo: invalid invocation to the macro
<mvo> Son_Goku: aha, nevermind
<Son_Goku> I'm merging my changes into the git master spec now
<Son_Goku> so I'll have a PR in a few minutes
<mvo> jdstrand: in the standup right now, but you make import points
<mvo> Son_Goku: \o/
<jdstrand> mvo: if you could ping me to discuss whenever is convenient, that would be great
<Son_Goku> mvo: also, why did snap-confine.1 become snap-confine.5?
<mvo> Son_Goku: uh, that is a question for zyga-ubuntu
<Son_Goku> or rather the other way around
<Son_Goku> it went from 5 to 1
<Son_Goku> ah, Debian bug
<Son_Goku> meh
<zyga-ubuntu> re
<zyga-ubuntu> Son_Goku: thank you :-)
<zyga-ubuntu> Son_Goku: there was a bug about the man page number from debian
<zyga-ubuntu> Son_Goku: I changed that so the bug could be fixed
<Son_Goku> yeah, I saw after git blame
<Son_Goku> I'm surprised no one complained yet about snap being in the wrong section
<zyga-ubuntu> ah, great, sorry for laggy response, I was on HO
<Son_Goku> so... I have the beginnings of EL7 support now
<zyga-ubuntu> Son_Goku: something I can look into this week,
<zyga-ubuntu> oh, exciting
<zyga-ubuntu> any issues so far?
<Son_Goku> it was a pain to get it to compile :/
<Son_Goku> https://copr.fedorainfracloud.org/coprs/ngompa/snapcore-el7/
<Son_Goku> I think I'm going to have to do more enhancements to the SELinux policy again
<Son_Goku> since it's completely untested, I don't think I should create the distro target symlink just yet
<Son_Goku> also, unlike the fedora build, the centos build is vendorized
<Son_Goku> so a litany of weirdness showed up during the build
<mborzecki> zyga-ubuntu: do you think we should run c-unit-test-{gcc,clang} with -Werror so that it fails when on warnings?
<zyga-ubuntu> ok
<zyga-ubuntu> mborzecki: yes, that's sensible
<Son_Goku> zyga-ubuntu: this is why I really need those multi-tarball releases as I asked mvo last year
<mvo> Son_Goku: I was planning to do for the 2.29, do you need one for 2.28.5?
<mup> PR snapd#4155 opened: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/4155>
<Son_Goku> mvo: nah, I don't care for 2.28
<Son_Goku> I'm okay with jank preview crappiness for my copr build for 2.28
<Son_Goku> but once I am more comfortable with the snapd build on CentOS, I don't want that anymore
<Son_Goku> mvo, zyga-ubuntu: PR proposed
<Son_Goku> this will need to be merged back into 2.29 as well
<mvo> Son_Goku: thanks!
<mvo> Son_Goku: https://github.com/snapcore/snapd/releases/tag/2.28.5 now has the "no-vendor" tarball that contains no vendor/ dir - so now we have one tar with vendor and one without. do you need more?
<Son_Goku> mvo: basically, I just want a no-vendor tarball and a tarball containing *only* the snapd-<version>/vendor/ tree
<Son_Goku> that way I can include both tarballs in dist-git unconditionally
<mvo> Son_Goku: aha, only vendor - sure, let me add this too
<Son_Goku> and only use the latter when I'm doing CentOS builds
<Son_Goku> because I'm *really* not going to be having zyga-ubuntu do a bunch of go library packages for EL7
<Son_Goku> it's not worth it when go is rebased every year
<Son_Goku> mvo: this multi-tarball configuration will also help you deal with the delta between debian and ubuntu
<Son_Goku> since debian purges the vendor/ tree
<mvo> Son_Goku: ok, please check if https://github.com/snapcore/snapd/releases/tag/2.28.5 looks reasonable
<Son_Goku> mvo: LGTM
<mvo> Son_Goku: great, thats my updated script now, so things should hpefully be better from now on
<Son_Goku> :D
<Son_Goku> zyga-ubuntu: feel free to give this a go: https://copr.fedorainfracloud.org/coprs/ngompa/snapcore-el7/
<Son_Goku> let me know how well it works (or doesn't work!)
<zyga-ubuntu> I'll install centos
<mborzecki> i'm out for today, leaving to pick up my kids, maybe I'll push another patch for #4153
<mup> PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153>
<zyga-ubuntu> see you mborzecki
<kalikiana> meh. was hunting what I thought was a syntax error. until I realized confinement was what prevented parsing from working at all.
<pedronis> mvo: #4150 looks reasonable but IÂ don't understand the need of the changes in overlord.New
<mup> PR #4150: ifacestate: make interfaces.Repository available via state cache <Created by mvo5> <https://github.com/snapcore/snapd/pull/4150>
<mvo> pedronis: yeah, I revert that one
<mvo> pedronis: thank you!
<pedronis> mvo: do you plan do add helpers?  (a bit like assertstate has) to ifacerepo? or just use the repo directly ?
<pedronis> I suppose it also depends how far is the repo interface to what you actually need
<mvo> pedronis: no helpers planned so far, the repo is rich enough for my use case
<mvo> pedronis: but my use case is really simple
<mvo> :)
<zyga-ubuntu> the time of day when I change my vim color scheme :/
<pedronis> mvo: it's fine,   assertstate has helpers, but there's also code that gets DB and does just Find, it depends
<zyga-ubuntu> aha sunset
<pedronis> mvo: I'm mostly asked because of the name of the package
<mvo> pedronis: aha, ok
<mvo> pedronis: I'm fine using something more generic, no strong opinion but for now that package is all I need
<mup> Issue snapcraft#1709 opened: Extract macaroon retrieval into more generic place <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1709>
<mup> Issue snapcraft#1710 opened: Research circle-ci <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1710>
<pedronis> pstolowski: added a couple of high-level comments to the cookie PRÂ 
<pstolowski> pedronis, thanks
<mup> Issue snapcraft#1711 opened: Develop enable-ci circle-ci <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1711>
<mup> Issue snapcraft#1712 opened: Tutorial for circle-ci <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1712>
<mup> Issue snapcraft#1713 opened: catkin plugin: support for building all packages in a given workspace <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1713>
<mup> Issue snapcraft#1714 opened: catkin plugin: recursively merge rosinstall files <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1714>
<mup> Issue snapcraft#1715 opened: catkin plugin: detect and gracefully handle rosinstall clashes <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1715>
<elopio> sergiusens: meeting?
<Chipaca> hmm, looks like i need to take a bunch of days off
<Chipaca> pedronis: mvo: niemeyer: any preference as to when i do this?
<Chipaca> taking the last two weeks of the year off i still have 11 days
<mvo> Chipaca: nothing in particular, but I have the same issue, I will probably take some days off in early Dec
<Chipaca> i mean, i could take all of december off
<Chipaca> but that's probably bad :-)
<pedronis> I will take the last two weeks of december off
<Chipaca> pedronis: as well as the shutdown, or including that?
<pedronis> including shutdown
<pedronis> I mean off from Dec 18
<Chipaca> pedronis: right, even doing that i have 11 left
<pedronis> you should have taken holidays before :)
<Chipaca> yes.
<pedronis> Chipaca: anyway you can keep some for the next year as well,  not sure that's a fix though
<Chipaca> pedronis: i might do something like taking mondays off, and keep what's left for next year
<Chipaca> or lose 'em, i mean i just took a week off less than a month ago
<Chipaca> oh, no, i took two days off
<Chipaca> it _felt_ like a week :-)
<pedronis> heh
<Chipaca> see that's the problem :-)
<zyga-ubuntu> Chipaca: take all holidays on January
<zyga-ubuntu> problem solved
<zyga-ubuntu> I need to pick up my daughter as my wife is stuck in traffic, ttyl
<elopio> sergiusens: the only explanation I see for the timeout is that the plugins suite is taking 100 minutes on autopkgtest. This suite takes 40 minutes in travis, and has worked on autopkgtests until last week, so my guess is that the system is overloaded making everything twice as slow.
<sergiusens> elopio ok, that could explain it
<sergiusens> cjwatson any idea how adt hosts are setup ^ ?
<elopio> we can split the tests in autopkg like we do on travis. But that will be slower because for every test the deb is prepared, but it will give us a bigger margin on the timeout for when the system is overloaded. I'm not sure how often this will be.
<sergiusens> elopio but these timeouts, are they present on amd64?
<elopio> I'm looking at arm64. Let me check the amd64
<niemeyer> Chipaca: You can roll one of the weeks on to next year, if you want
<sergiusens> Chipaca taking days off without traveling away from $HOME always makes it feel like it is longer that it should be for me
<elopio> sergiusens: the result we have available for amd64 shows that suite finishing in 3091s
<sergiusens> so less than an hour
<zyga-ubuntu> re
<elopio> yes. I think splitting makes sense, at least until all our hello world builds take less than 1 minute. It will at least let us worry about real errors and not time outs.
<cjwatson> sergiusens: none, ask Laney
<cjwatson> sergiusens: (autopkgtest isn't LP, even though we share cloud regions)
<sergiusens> cjwatson yeah, thanks; just got a hold of him on my random question about queuing on #ubuntu-release
<sergiusens> apparently a cloud region died and things got bad
<sergiusens> and the snapd queue which we already discussed on how to make it easier going
<kalikiana> elopio: do test snapcraft.yaml files versus modifying them on the fly impact this? I was looking into build packages/ snaps tests which are all fixed, but you were suggesting we prefer creating them on the fly
<kalikiana> kinda wondering if one or the other is faster
<elopio> kalikiana: I don't think so. We can create a file in a lot less than a second.
<jdstrand> roadmr: hi! re goby> I think I forget to rerun the review-- I didn't add the comment for granting classic to the snap, so I think I may have granted then got pulled away
<roadmr> jdstrand: right, it's what I speculated in the bug
<jdstrand> roadmr: I didn't see the bug. is there anything else I should do?
<roadmr> jdstrand: I don't think so, the bug was about things being "stuck" but I explained the sequence of events which seems sensible. Let me find it for you
<roadmr> jdstrand: https://bugs.launchpad.net/snapstore/+bug/1729826
<mup> Bug #1729826: "Waiting for previous upload" when none in review queue <Snap Store:New> <https://launchpad.net/bugs/1729826>
<elopio> sergiusens: do you know why our ppa is not building for armhf and arm64?
<jdstrand> roadmr: thanks
<mup> PR snapd#4156 opened: overlord/devicestate: switch to the new endpoints for registration <Created by pedronis> <https://github.com/snapcore/snapd/pull/4156>
<sergiusens> elopio our ppa? snapcraft is architecture all
<elopio> sergiusens: ahhh, of course, that is why it builds only once.
<elopio> so, we won't have the unittests running in different architectures every day, but that's probably fine.
<sergiusens> elopio what is this about building a deb everyday?
 * sergiusens steps away for a bit
<elopio> sergiusens: just trying to get rid of the make_beta_pr. It runs nightly, just as the PPA. So instead of making a branch, it would be better to run the autopkgtests on the PPA every night.
<mup> PR snapcraft#1716 opened: tests: split the integration autopkgtests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1716>
 * Chipaca EODs
<cachio> zyga-ubuntu, do you see he network-status interface when you list the interfaces?
<jdstrand> cachio: I don't have context, but note that network-status is not an implicit slot. you need a slot implementation
<cachio> jdstrand, ah, ok
<cachio> jdstrand, tx, thats make sense now
<jdstrand> cool
<cachio> jdstrand, any idea why is it implemented in that way?
<jdstrand> cachio: because the core snap and the classic system doesn't ship connectivity-api by default
<jdstrand> implicit slots are for things that are expeccted to always be provided by the host OS
<cachio> jdstrand, but the network-control is pretty similar and it is implicit
<jdstrand> cachio: network-control allows using various tools that are avaialble inn the core snap or the classic distro
<jdstrand> cachio: network-status allows using a dbus api provided by the connectivity-api deb from Touch
<cachio> jdstrand, ah, ok
<cachio> jdstrand, thanks for the explanation
<jdstrand> cachio: ie, the core snap provides the things that are made avaialble via the interface. that is what makes it implicit. if it does not, then a slot implementation must provide it
<zyga-ubuntu> cachio: looking
<jdstrand> zyga-ubuntu: you don't have to
<zyga-ubuntu> cachio: ah, I see jdstrand already answered
<jdstrand> zyga-ubuntu: I answered the question
<zyga-ubuntu> thank you :)
<jdstrand> np
<cachio> thanks guys
<zyga-ubuntu> thank you for working on tests :)
<zyga-ubuntu> jdstrand: FYI, tmpfs is in final stages of polish, expect a swarm of small PRs that make everything work nicely, spread and unit tests
<jdstrand> ok
<zyga-ubuntu> jdstrand: I'm adding support for files and symlinks which will also be handy for layouts (implementing this gives us all the designed building block of layouts now)
<jdstrand> zyga-ubuntu: note I'm still in the throes of investigating various issues
<zyga-ubuntu> throes?
<jdstrand> sorry
<jdstrand> I'm very busy lately investigatin the fallout of the udev tagging PR
<zyga-ubuntu> ah, I see
<zyga-ubuntu> thank you for doing that
<zyga-ubuntu> let me know if I can help
<jdstrand> getting through things, but still getting different reports
<zyga-ubuntu> I pushed a PR related to udev tagging of hooks
<jdstrand> I also have some spread tests I'm working on to fill some testing gaps I noticed
<zyga-ubuntu> anything worrying from the reports you are getting?
<jdstrand> nothing that seems terribly widespread
<jdstrand> but things that are affecting people
<jdstrand> (corner rcase type things I think is what's left)
 * zyga-ubuntu nods
<kyrofa> elopio, whatever happened to re-using the cache in integration tests?
<elopio> kyrofa: we didn't notice any improvements on travis. I started measuring the tests, and decided first to remove the duplicates which reduced 10 minutes.
<elopio> after 2.35 we can reopen it and measure again
<kyrofa> elopio, ah yes, okay. I'm adding another ROS test, FYI
<elopio> kyrofa: ok. And any reason for putting it in the integration suite instead of the snapcraft-de-noche like we did with the lunar one?
<kyrofa> elopio, those run too late, man. And they're so easy to forget about
<kyrofa> All these ROS tests pull the same thing. If we had caching it wouldn't be the time suck that it is
<elopio> kyrofa: ok. Lets try sharing the cache again :)
<kyrofa> Lunar is a little different. That test ensures support, but that's all it needs to do. We have various other kinetic tests that all do the same, but slightly different things
<kyrofa> Caching would make one test take a while, and all others take two minutes
<kyrofa> Although if we're _already_ running into disk space issues that may be a problem
<elopio> maybe we can remove the slow tag. But while we have that, remember that the ros tests will run once a day, just as late as snapcraft-de-noche.
<kyrofa> elopio, not all of them are marked slow, just the snapd ones
<kyrofa> elopio, also, triggering autopkgtest runs is easy, triggering de-noche tests... ?
<kyrofa> (note that I'm not adding another snapd test, just a good old integration test)
<elopio> we will have to see if it's because of tmpfs. But if it's not, we need a solution, so ask for more space on the runnners.
<kyrofa> Indeed
<elopio> kyrofa: a good old *slow* integration test :) I have no problem with this, if the test is needed, and we need to run it on each PR, we have to deal with the delay. I'm just making the questions, because the past two weeks have been sad because of slow tests.
<kyrofa> elopio, hahaha
<kyrofa> elopio, of course, you're doing your job ;)
<kyrofa> elopio, but yeah, I need to make sure this behavior doesn't regress
<elopio> it seems that our plugins will always be slow, so our suite will always be slow. Lets parallelize through splits and explore other options like the cache.
<kyrofa> elopio, how is Travis looking today? Think it could handle a little experimentation?
<kyrofa> I want to propose my ROS PR, and also propose that same PR with your caching rebased on top, and compare the two
<elopio> kyrofa: the integration_tests/plugins suite is already big, so we might be forced to do it, not just for fun.
<kyrofa> elopio, yeah that probably needs to be done
<kyrofa> elopio, though note that this test is actually going into integration_tests/ itself. Are you trying to migrate those elsewhere?
<elopio> kyrofa: why on integration_tests if it's for a plugin? souldn't it go in itnegration_tests/plugins?
<kyrofa> elopio, also, you're trying to toast the snaps_tests, right?
<kyrofa> elopio, because it was already there, I was just adding to it
<elopio> kyrofa: yeah, no more snaps_tests please.
<kyrofa> elopio, this PR will actually _remove_ one then, ;)
<elopio> kyrofa: that sounds wrong, but lucky wrong because the integration_tests suite has a little more room than the plugins one.
<elopio> kyrofa: you can experiment locally with the shared cache, just adding a timer like https://stackoverflow.com/a/9502897/2665322
<kyrofa> elopio, oh yes of course, good call
<kyrofa> elopio, well, if I move these both into plugins I guarantee it'll run over. Shall we split first
<kyrofa> ?
<elopio> kyrofa: yes, I think we first refactor to have everything in snapcraft/tests/integration
<kyrofa> elopio, agreed
<elopio> then we can split snapcraft/test/integration/plugins/ros and snapcraft/tests/integration/plugins/others
<kyrofa> elopio, I'll rebase to build on that branch
<kyrofa> elopio, haha, great idea
<kyrofa> Okay, got it
<kyrofa> I'll do that, then experiment with caching with that single suite
<elopio> not great, but well, we don't have many options. My experiment running cleanbuilds in parallels was a lot slower than one thread of normal builds :(
<kyrofa> Yeah, not surprising :(
<kyrofa> Oh wait, I can't build on that test refactor, this needs to land for this release
<kyrofa> I'll just propose in the integration_tests suite for now
<zyga-ubuntu> pedronis: around?
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4141 what happened here?
<mup> PR #4141: snap-update-ns: add missing unit test for desired/current profile handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/4141>
<pedronis> zyga-ubuntu: no, clue  I didn't push to that branch, IÂ don't even have it around
<pedronis> also the commit are marked as mvo too
<zyga-ubuntu> pedronis: ah, mvo must have rebased something oddly
<zyga-ubuntu> no worries, I'll check it out tomorrow
 * zyga-ubuntu -> EOD
<mup> PR snapcraft#1717 opened: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717>
<sergiusens> pedronis cachio I've been looking at your PRs that have been merged and noticed that almost none waited for adt to finish running; given the queue for adt is being starving due to so many snapd requests on the upstream queue, mind disabling the adt hooks you guys have (temporarily at least).
<sergiusens> I did tell mvo earlier today about our process and mentioned elopio mind be able to help cachio
<kyrofa> snappy-m-o, autopkgtest 1717 zesty:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<kyrofa> sergiusens, the shebang fix in post-build won't work. Not even post-pull will work, as we need to make sure shebangs are fixed for stage-packages that are used as part of pulling
<mup> PR snapcraft#1653 closed: internal: don't reuse variable in OsRelease <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1653>
<sergiusens> kyrofa oh right; pre-build then?
<kyrofa> sergiusens, it needs to happen in the repo
<sergiusens> kyrofa as part of unpacking? Like all other things?
<kyrofa> sergiusens, yeah, which is where it is right now
<kyrofa> sergiusens, but then we also need it post-build
<kyrofa> And pre-build
<kyrofa> Heh
<sergiusens> kyrofa I still think that `unpack` should eventually be something triggered by pre-pull and pre-build
<sergiusens> kyrofa as in the directive to do something should be something a user could override
<sergiusens> that is the gist of it
<kyrofa> So: repo for stage-packages that might be used for pulling. pre-build for source that needs to be fixed before building, and pre-stage for fixups in order to be useful in staging (and the snap in general)
<kyrofa> Yeah you're probably right there
<sergiusens> kyrofa doing it in unpack right now is fine as we do a bunch of other things that should be overrideable there
<kyrofa> sergiusens, it really comes down to this: we currently don't have pre/post. But we currently are doing the shebang fix in unpack as well as pip, python plugin, and catkin plugin
<kyrofa> sergiusens, in the interest of not needing to play whackamole with this shebang bug, I'd like to make those all go through the same codepath
<kyrofa> Where should that be with the view of having pre/post?
<mup> PR snapd#4157 opened: add spread test for connecting all interfaces (excepting gadget slots) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4157>
<kyrofa> I can just throw in in internal/common for now, then we can refactor it when we use pre/post
<kyrofa> That's better than file_utils because that's public
<sergiusens> kyrofa internal.mangling ?
<kyrofa> Hey, not bad
<sergiusens> it is settled then
<kyrofa> Done
<mwhudson> heh i now have the 4th oldest snapcraft and the oldest snapd pr
<mwhudson> the snapd one still being open is definitely my fault though
<mup> PR snapcraft#1718 opened: lxd: let lxd choose the architecture <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1718>
<sergiusens> mwhudson it is marked 2.36, as soon as adt is freed up and we can release 2.35 we will focus on those
<mwhudson> sergiusens: it also has conflicts i haven't resolved so i'm not too bitter :)
<mwhudson> sergiusens: and it would make sense to do #1718 first in any case
<mup> PR #1718: daemon,overlord: add subcommand handling to snapctl <Reviewed> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1718>
<mwhudson> mup: bad bot
<mup> mwhudson: Roses are red, violets are blue, and I don't understand what you just said.
<kyrofa> mwhudson, looks like that PR _definitely_ happened first
<mwhudson> snapcraft#1718
<mup> PR snapcraft#1718: lxd: let lxd choose the architecture <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1718>
<mwhudson> eh
<mwhudson> *heh
<mwhudson> (can't type today)
<sergiusens> ah, kalikiana or kyrofa mind looking at that ^? I am going to be signing off soonish, it has been a very long Monday in front of my computer.
<kyrofa> Sweet, I'll check it out
<mwhudson> i haven't managed to run the tests yet so we should let travis do it's thing i guess...
<kyrofa> Alright, I'll take a look in a few then
<elopio> Alright, trying something  new here. Weechat relay+SSL to sync with the android app
<elopio> IRC fun never ends.
<kyrofa> elopio, haha, welcome back!
<cachio> cwayne, hey, can't access to the bug that is in the email
<cachio> https://bugs.launchpad.net/plano/+bug/1727783
<sergiusens> elopio, snap install thelounge
<elopio> sergiusens: I tried that, hated it.
<elopio> And anyway, it's almost as complicated as this one. I would also need letsencrypt for the lounge.
<sergiusens> Yup
 * elopio goes to exercise. I'll be back in 1 hour.
 * sergiusens goes into airplane mode
 * mwhudson finds FakeLxd
<mup> PR snapcraft#1719 opened: many: account for python shebang ars in rewrite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1719>
#snappy 2017-11-07
<mwhudson> kyrofa: is there a snapcraft policy on rebasing / squashing commits?
<mwhudson> kalikiana: is there a snapcraft policy on rebasing / squashing commits?
<elopio> mwhudson: we try to keep one commit per pull request. But for external contributors, we can always click the squash button.
<mwhudson> elopio: oh ok
 * mwhudson squashes away then
<elopio> thanks.
<mborzecki> morning guys
<mborzecki> pushed 2 extra patches to #4153, think it's good to go
<mup> PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153>
<zyga-ubuntu> o/
<mborzecki> zyga-ubuntu: hi there
<zyga-ubuntu> hi
<mvo> hey zyga-ubuntu  and mborzecki
<mborzecki> another cold and rainy day, damn i hate atumn
<zyga-ubuntu> mborzecki: I was thinking "man, what a gloomy morning"
<mborzecki> at least it's not below 0 yet :/
<zyga-ubuntu> mborzecki: did you see what's in zakopane this week?
<mborzecki> nope, is it 2-3m of snow?
<zyga-ubuntu> mborzecki: looks like sub-zero temps during daytime
<zyga-ubuntu> so, some good progress on tests yesterday
<zyga-ubuntu> I have some more to go but I think I can carve out a chunk now and send a PR
<zyga-ubuntu> mborzecki: interesting failure in https://github.com/snapcore/snapd/pull/4153 - there's a missing break in a switch statement
<mup> PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153>
<mborzecki> yup
<mborzecki> is that intentional?
<zyga-ubuntu> no, except for the one that is explicitly commented as such
<mborzecki> ok
<zyga-ubuntu> school run
<mborzecki> any idea where I can get debian-9-64 image that was used in this test?
<mborzecki> yeah, no wonder the error wasn't picked up on my arch laptop, I don't have apparmor, but it's weird that gcc test passed on debian-9 image that I pulled from zyga-ubuntu's site :/
<zyga-ubuntu> re
<zyga-ubuntu> mborzecki: debian-9 is confusing
<zyga-ubuntu> mborzecki: we have a "bug" so that debian refers to either sid or stretch in spread, depending on the backend linode vs qemu
<zyga-ubuntu> mborzecki: images can be made with adt-buildvm-.. family of scripts but not sure if those would work on arch
<zyga-ubuntu> mborzecki: I can build a pair of fresh images and upload
<mborzecki> that'd be great, thanks
<mborzecki> btw. and what do you use for builiding fedora/opensuse images? packer?
<zyga-ubuntu> I don't
<zyga-ubuntu> I don't have opensuse images and fedora image was made by someone who's no longer here
<zyga-ubuntu> note that debian image is a tweaked cloud image
<zyga-ubuntu> same with ubuntu
<zyga-ubuntu> so it's "just" a matter of scripting something around a given distribution's cloud image
<mborzecki> afaik arch has none :)
<zyga-ubuntu> builds are in progress
<mborzecki> great
<zyga-ubuntu> note that they are not quite reliable and sometimes the "magic" hangs and needs to be retried
<zyga-ubuntu> I haven't investigated that, it's a can of worms
<zyga-ubuntu> but I should be able to upload some soon
<mborzecki> i pushed a patch that should fix that failure, the 'case EPERM:' is in theory covered by a comment, there's some magic in both gcc and clang that will happily accept a fallthrough case if there's a comment that matches a predefined regex
<zyga-ubuntu> oh, wow
<mborzecki> yay, travis passing now
<zyga-ubuntu> refreshed ubuntu images are uploading, I'll make debian images now
<zyga-ubuntu> I also fixed the SSL cert
<zyga-ubuntu> man, I should have paid for more than 10GB of disk
<mborzecki> thanks
<pedronis> mvo: IÂ just noticed that becaused configstate.Manager was strange when you turned into a manger Overlord code wasn't completely adjusted
<pedronis> and hi
<pedronis> mvo: I added a comment about that to #4122
<mup> PR #4122: configstate: add support for configure-snapd for snapstate.IgnoreHookError <Created by mvo5> <https://github.com/snapcore/snapd/pull/4122>
<mborzecki> any idea how to convince go that file tagged with `+build !cgo` should not be built when building with cgo enabled?
<zyga-ubuntu> hmm, nope
<zyga-ubuntu> we have some custom tags
<zyga-ubuntu> maybe we could use that as a way to solve the issue?
<zyga-ubuntu> like we can build the store with either production or test keys
<mborzecki> Chipaca suggested adding stubs for group calls when doing a static build, that's what I'm trying to do, but the no-cgo is picked up when building with cgo anyway :/
<mvo> pedronis: good morning! thank you, I have a look
<mborzecki> and i'd really like to avoid using function pointers and registering those in init()
<pedronis> mvo: let me know if it's not clear
<mvo> pedronis: makes sense so far, I get right to it. thanks again!
<pedronis> mborzecki: are you disabling it with CGO_ENABLED=0
<pedronis> ?
<mborzecki> yes, so I have 3 files, group.go (no build tags), group_stubs.go (+build !go) and cgo_group.go (+build cgo)
<mborzecki> CGO_ENABLED=0 builds group.go and group_stubs.go (as expected)
<mborzecki> CGO_ENABLED=1 builds group.go, cgo_group.go and group_stubs.go (and this is where i get symbol redeclaration)
<mborzecki> s/!go/!cgo/
<pedronis> that seems odd?  are you sure +build is put in the correct in that file?
<pedronis> *correct place
<pedronis> go is failry picky where +build should go or it will ignore it
<mborzecki> yup, it's right below the license header
<pedronis> IÂ never put it there
<pedronis> it's eay to get it wrong
<pedronis> mborzecki: see for example  asserts/sysdb/testkeys.go  for where we tend to put it
<mborzecki> pedronis: damn it, you're right
<mborzecki> it was right below /* ... */ license header, apparently go doesn't like that
<mborzecki> pedronis: thanks, fixed now, works like charm
<pedronis> they need a empty line after (and only blank lines/comments before)
<mborzecki> i really really hate go tooling sometimes
<pedronis> in general though it's better to put far from keywords, otherwise it's easy for somebody later to break that rule
 * kalikiana coffee
<pedronis> mvo: thanks
<Chipaca> pedronis: good morning
<Chipaca> pedronis: you know how alan a little while ago had an issue where a snap somehow got corrupted over a reboot? and that made people think maybe snapd should check the signature of installed snaps on startup as well as on install?
<pedronis> Chipaca: yes
<pedronis> bit unclear what to do with that until we have warnings though
<Chipaca> yes, but
<Chipaca> pedronis: on armhf that would be rather prohibitive
<pedronis> also expensive
<Chipaca> pedronis: the io is bad enough, but our signature makes things worse
<Chipaca> pedronis: we're also still doing the double signature check on download+install, which is also not optimal
<pedronis> Chipaca: is there a part of this that gets to something we *should* do soon?
<Chipaca> pedronis: so this had me revisiting the idea of using two signatures, a cheaper "is the file sane" and a more expensive "is this what we signed"
<Chipaca> pedronis: we used to have two signatures (sha256 was the other i think), and i wanted to check with you before chasing people to see if we still had that
<Chipaca> to not lose it
<Chipaca> before we want it again
<pedronis> we still have sha256 from the store afaik
<pedronis> don't think it was killed
<Chipaca> it seems it might be sha512
<Chipaca> still, ok
<pedronis> Chipaca: yes, is sha512
<pedronis> not sha256
<Chipaca> pedronis: if the above sounds sane to you, could you (or can i) mention it to store people lest we forget it?
<Chipaca> the other alternative would be to calculate a cheaper checksum on install and use that
<Chipaca> anyway, that's enough future-pondering for me. back to the trench!
<mvo> Chipaca: I was also wondering about this recently. I'm kind of afraid about the io overhead if we do this but maybe we can make it an optional feature, for some systems we really need it. one really cool alternative would be to use something like a hash-tree so instead of having one global hash for the entire file, have a hash for each block (size to be determined) and on each read we could verify the block only - we would need a trusted hash of
<mvo> this block/hash thing but that should be ok. but tradeoffs of course, i.e. each snap would grow or the store would have to send the data oob. anyway just idle thoughts for now
<mvo> (huii, that was long)
<Chipaca> mvo: does squashfs have anything like this?
<mvo> (not a hash-tree more like a hash-flatmap)
<mvo> Chipaca: I don't think so, its major work
<Chipaca> yeah
<mvo> Chipaca: also because it involves the kernel which will have to know about this and do the checking :/
<Chipaca> yep
<mvo> Chipaca: I think its cool but not short term
<Chipaca> ah, no
<Chipaca> mvo: short term i just wanted to check we weren't going to throw away the second signature, if we then were going to want to use it :-)
<mvo> Chipaca: :) yes
<mvo> zyga-ubuntu: a second review for 4150 would be great, hopefully easy
<zyga-ubuntu> ak
<zyga-ubuntu> done :)
<pedronis> Chipaca: IÂ haven't heard discussions about dropping it (sha512) tbh
<mup> PR snapd#4158 opened: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/4158>
<mup> PR snapd#4150 closed: ifacestate: make interfaces.Repository available via state cache <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4150>
<pedronis> mvo: got again one of those  /var/lib/snapd changes while tar-ing in 14.04: https://travis-ci.org/snapcore/snapd/builds/298088866?utm_source=github_status&utm_medium=notification
<Chipaca> ackk: reviewed (made it all the way through!). This is so close!
<mvo> pedronis: interessting. always 14.04, right?
<pedronis> possibly yes, not 100% sure
<mvo> pstolowski: hm, what happend to PlugInfo.Connections ? iirc we had that some days ago and in master it appears to be gone. what is the replacement to see if a plug is connected?
<pstolowski> mvo, you mean Plug.Connections?
<mvo> pstolowski: maybe, that, did that change?
<mvo> pstolowski: I used to have code like "repo.Plug(snapName, plugName).Connection > 0" to figure out if the plug is connected
<pedronis> mvo: well repo is quite in flux
<mvo> pstolowski: aha, I see, repo is now handing out PlugInfo instead of Plug, hmm
<pstolowski> mvo, indeed
<mvo> pstolowski: ok, what I need is to answer the question: "is this (snapName, plugName) pair connected"? I am happy to dig into this myself, was mostly wondering if you have suggestions/plans
<pstolowski> mvo, let me see
<Chipaca> mborzecki: your pr is very close to a +1; normally i would've +1'ed it leaving you to tidy up the things i point out
<mborzecki> Chipaca: thanks for reviewing
<Chipaca> mborzecki: give me a shout when you have it, so that i can give it a last once-over
<mvo> pstolowski: aha! I think I found it
<mborzecki> ack
<Chipaca> mborzecki: github hate a comment i made on an commit, i think -- i made the same point in the pr itself just in case
 * zyga-ubuntu feels so so
<pstolowski> mvo, are you thinking about repo.Connected(..)?
<mvo> pstolowski: yes
<pstolowski> mvo, i
<mvo> pstolowski: or is this misleading?
<pstolowski> mvo, i'm wondering if it's good, it takes plugOrSlot
<pstolowski> mvo, we could have a "precise" helpe
<pstolowski> r
<mvo> pstolowski: thanks, its ok for now, I will dig a bit more but this unblocks me. thanks for your help
<pstolowski> mvo, I think Connected(..) is not very effective, a simpler helper could just look at slotPlugs or plugSlots maps and return true without all that logic
<pstolowski> s/true/bool/
<Chipaca> mvo: in your review of #4153, did you forget to +1?
<mup> PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153>
<Chipaca> mvo: i see a lot of \o/'s and no /o\ and no +1
<mvo> Chipaca: I'm slightly unhappy about the need to write f(void) instead of f() - I understand the reason but I could not bring myself over it yesterday, if I'm the only one who does not like it I'm +1
<Chipaca> mvo: I don't like it, but C is C -- if i liked it i'd write more of the stuff
<mvo> pstolowski: thanks, I think its fine for now, but if I need something more targeted I will keep it in mind
<mvo> Chipaca: heh, fair point
<cjwatson> oh I could tell you stories about weird stuff caused by omitting void there
<Chipaca> cjwatson: part of me wants you to
<Chipaca> cjwatson: the other part is already a block away, screaming
<mvo> cjwatson, Chipaca: heh :)
<cjwatson> actually thinking about it my best such story was from generated code that said (void) when it actually wasn't, coupled with varargs
<mvo> mborzecki: silly question, I am looking at 4135 again and there is a new "break" in apparmor-support.c. I wonder why this is added here, it looks correct but how was it discovered?
<mborzecki> mvo: c-unit-tests-gcc failed on debian unstable
<mborzecki> as a result of enabling -Wextra warnings
<mvo> mborzecki: aha, nice. so it noticed that this was probably unintentional? thats smart
<mborzecki> and the CI builds will fail on warnings now :)
<mvo> mborzecki: and if there is a "fall-though" comment that is the magic to make it pass?
<mvo> mborzecki: (i.e. the line below)?
<mborzecki> yes, gcc/clang will match that agains some built-in regexes that cover different variations of 'fall through'
<mvo> mborzecki: neat
<mup> PR snapd#4141 closed: snap-update-ns: add missing unit test for desired/current profile handling <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4141>
<mup> PR snapd#4153 closed: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4153>
 * zyga-ubuntu takes a longer break to check if he can work today, 
<zyga-ubuntu> I don't feel good
 * sergiusens is going to be on and off today; off according to the records
<mborzecki> i'm looking at packaging, and it's a bit weird, debian/ubuntu has just one 'snapd' package, fedora has it split into snapd and snap-confine, opensuse has a single package again, arch, depending on which files you look at, is either one package (packaging/arch) or 2 packages (one in the repos) or one pacake again (when using PKGBUILD from releases page)
<mborzecki> i would assume the idea is to converge all distros to having a single package?
<zyga-ubuntu> yes
<cjwatson> hmm, what changed recently that would have caused the core snap to be uninstallable in launchpad-buildd's containers?  did we start doing more security setup on the core snap maybe?
<zyga-ubuntu> cjwatson: no, I don't think we did
<zyga-ubuntu> cjwatson: unless it's udev tagging, we use device cgroups more than before
<cjwatson> I can get apparmor working by granting the mac_admin and mac_override capabilities (but I think I remember there being some reason we didn't do that before - will need to dig), and then I run into it wanting udevadm to exist.  I'm sure I managed to avoid all this before
<cjwatson> it seems like a surprising category of problems to be new, though
<zyga-ubuntu> cjwatson: since we use udev tagging more than before now it is possible that the core snap's configure hook is trying to set something up that was not happening before
<cjwatson> if udev is now mandatory then I think snapd is missing a dependency on it
<cjwatson> yeah, that's believeable
<cjwatson> where does that configure hook live?
 * cjwatson installs udev and tries again
<zyga-ubuntu> cjwatson: for core it's a bit special, I honestly don't know
<ogra_> zyga-ubuntu, cjwatson the source is at https://github.com/snapcore/core/blob/master/hooks/configure ... though mvo is just re-working the world, not sure it stays like that
<cjwatson> ta
<niemeyer> Hellos
<niemeyer> mborzecki: Just sent the invite into the GH org
<ogra_> Hellos like greece ? :)
<mborzecki> niemeyer: thx
<cjwatson> OK, grant mac_admin and mac_override caps and install udev, and all seems to be well again.  Will need to test all the things though ...
<niemeyer> mborzecki: There was a third thing I promised you yesterday during our meeting but my notes on it were unfortunate to say the least
<niemeyer> mborzecki: I wrote down "forum key", but I'm thinking that this is about the monthly scheduling.. that's what I get for writing down while speaking :)
<niemeyer> mborzecki: Are you missing anything else infra-wise?
 * zyga-ubuntu -> school, I need to help my daughter 
<zyga-ubuntu> I'm not much of help today anyway
<Chipaca> i just threw my back out doing physio :-(
<Chipaca> on the upside, we now know a bit more about what makes it go out
<Chipaca> on the downside, FUCKIN' OUCH
<mvo> niemeyer: maybe your wrote down linode key?
<mvo> Chipaca: /o\ get well!
<Chipaca> mvo: that's what i go to phisio for!
<Chipaca> physio*
<niemeyer> mvo: I had both in the notes.. I think it was really about the monthly scheduling, and I mixed up my writing as we spoke over the linode keys
<niemeyer> Chipaca: What was it?
<Chipaca> niemeyer: a when my hips go to about 90 degrees pushing, something twangs
<Chipaca> but only with my knees at a particular angle
<niemeyer> Chipaca: Wow, that must have been pretty hard to "debug", so to speak
<Chipaca> niemeyer: some days i wish i had a debugger
<Chipaca> of preference one more like smalltalk's
<Chipaca> ie that i didn't need to die for it to work
<niemeyer> LOL
<niemeyer> Chipaca: corpse would be a much better name for those core dumps
<cachio> cwayne, hey, any news?
<cwayne> cachio: havent heard from QA yet, waiting on Alex to start so I can get you access to that bug
<mup> PR snapd#4156 closed: overlord/devicestate: switch to the new endpoints for registration <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4156>
<pedronis> I need 2nd reviews for #4121 and #4125
<mup> PR #4121: overlord/snapstate: toggle ignore-validation as needed as we do for channel <Created by pedronis> <https://github.com/snapcore/snapd/pull/4121>
<mup> PR #4125: corecfg:  support setting proxy.store if there's a matching store assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/4125>
<popey> jdstrand: do you know of any snap which successfully uses the mpris plug?
<popey> jdstrand: specifically an audio player which can be controlled via the buttons in the sound menu on ubuntu
<diddledan> I think gradio hooks it, whether successful or not I'm unaware
<popey> not successful, i have it playing here and see no reference in the sound menu
<diddledan> :-(
<diddledan> booo
<popey> i made a snap of auryo (a soundcloud client) and it doesn't work here either. But I don't know if I got the config in the yaml right or not
<zyga-ubuntu> pedronis: done
<popey> I guess I should post on the forum. The problem is the documentation doesn't really cover it from a developer pov
<davidcalle> popey gradio
<popey> does it work for you davidcalle ?
<davidcalle> popey: I did a fresh install last week, so I can't re-check right away, but it worked fine afair
<popey> on 17.10?
<davidcalle> popey: that's what I'm giving a try now
<popey> ok, works on 17.10
<davidcalle> popey: works fine on 17.10
<popey> not on 16.04 unity
<mborzecki> i'm done for today, till tomorrow
<mup> PR snapd#4159 opened: cmd/snap-confine: add slave PTYs and let devpts newinstance perform mediation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4159>
<mup> PR snapd#4160 opened: cmd/snap-confine: add slave PTYs and let devpts newinstance perform mediation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4160>
<jdstrand> mvo: hi! fyi, those are for a similar udev tagging issue. this wasn't reported by a customer but from the field via the forum. I suggest that it be included in 2.29 so I created a branch, but that is up to you
<jdstrand> s/those/those ^/
<mvo> thank you jdstrand
<mvo> jdstrand: i have a look and see what we can do, probably 2.29.3 as 2.30 is still some time away
<jdstrand> mvo: cool (that is what i was thinking)
<jdstrand> mvo: for that framebuffer issue, I think I'll try to use a different interface that will be available in more places (eg, time-control, for /dev/rtc)
<jdstrand> mvo: I think it is fine to commit the PR you did if you haven't already. I'll just send a followup
<mvo> jdstrand: it got only a single +1 so far, but I think its useful becaue it validates the code on devices with a framebuffer
<jdstrand> mvo: I also wanted you to be aware of https://github.com/snapcore/snapd/pull/4157
<mup> PR #4157: add spread test for connecting all interfaces (excepting gadget slots) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4157>
<jdstrand> mvo: it isn't ready to commit yet (it found a bug in firewall-control :)
<Chipaca> popey: I don't know about successful, but: google-play-music-desktop-player, vlc, gradio (from a quick search)
<mvo> jdstrand: yeah, thats really nice, I looked at it this morning briefly
<popey> i tried copying the gradio mpris config but it barfs when i install the snap
<mvo> jdstrand: thanks for that!
<popey> https://www.irccloud.com/pastebin/vhbIilEC/
<jdstrand> mvo: but the idea is to have a spread test that connects every interface. this will catch things like apparmor syntax issues, the udev_enumerate issue, seccomp policy issues, modules not loading, etc. just a high level test that connects the interface like a user would
<jdstrand> mvo: ah cool
<mvo> yes
<jdstrand> mvo: this technique is what helped me find the uhid issue and the kmod back issues (where the interface fails to connect if the module can't be loaded-- I'll be sending a pr for that)
<jdstrand> not uhid. the network-control one
<jdstrand> anyway, it is finding things :)
<jdstrand> s/back/backend/
<jdstrand> mvo: fyi, there may be one more cgroup fixup PR (something I need to investigate for ondra)
<mvo> jdstrand: ok, so I will wait a bit before jumping to any 2.29.3
<jdstrand> mvo: fyi I was just passing through 4040 and it may be ready
<jdstrand> (I didn't look at it, just saw the comments from the submitter)
<mvo> jdstrand: looking at it now
<popey> \o/ mpris success
<jdstrand> popey: oh, I missed your comment, but glad you got it working :)
<popey> works on 17.10 but not on 16.04 :(
<popey> (is that expected?)
<mup> PR snapd#4040 closed: interfaces: add USB interface number attribute in udev rule for serial-port interface <Created by musicguitar> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4040>
<popey> jdstrand: do i have to request mpris access on the forum? I have just uploaded auryo. https://dashboard.snapcraft.io/dev/snaps/8645/rev/1/
<jdstrand> popey: no. dbus and mpris access I can just handle, unless it is weird and I'd request discussion in the forum
<popey> ok
<jdstrand> popey: actually, why are you using both?
<jdstrand> popey: cause there are two names it is known by?
<popey> hm
<popey> good question!
<popey> lemme fix it
<Odd_Bloke> I want to dump the top-level of my repo in to a snap, but using "source: ." means that my .tox and .git directories are included; how can I stop that from happening?
<popey> source: ./*  ?
<jdstrand> mvo: I am seeing this:
<jdstrand> Running vet
<jdstrand> overlord/ifacestate/helpers.go:358: arg plug for printf verb %s of wrong type: *github.com/snapcore/snapd/interfaces.Plug
<jdstrand> overlord/ifacestate/helpers.go:398: arg slot for printf verb %s of wrong type: *github.com/snapcore/snapd/interfaces.Slot
<jdstrand> mvo: I'm up to date on master and looked at upcoming PRs, but don't see fixes
<Odd_Bloke> popey: "ValueError: local source (./*) is not a directory"
<popey> :(
<Odd_Bloke> .tox in particular is a problem because something breaks when snapcraft tries to copy from it.
<zyga-ubuntu> jdstrand: I saw that too, I think it's a vet bug honestly
<zyga-ubuntu> jdstrand: unless not the same thing
<Chipaca> jdstrand: it's a pluginfo, so it has a String(), so %s works
<jdstrand> that's all fine. what I'm hearing is everyone is currently just ignoring the vet error?
<jdstrand> or do I need to redo godeps or something?
<zyga-ubuntu> jdstrand: I just ignore it
<mvo> jdstrand: let me check
<mvo> jdstrand: I have not seen it, it seems like the go vet on linode is less strict
<jdstrand> huh
<mup> PR snapd#4113 closed: tests: test for desktop interface <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4113>
<Chipaca> why does it think it's a Plug and not a PlugInfo?
<popey> jdstrand: looks like it needs both, yes
<jdstrand> popey: do you have snappy-debug output I can see?
<popey> sure, one moment
<popey> oh, when it fails, or when it succeeds?
<mvo> Chipaca, jdstrand might be a recent merge that broke it, I'm looking now
<jdstrand> popey: because the dbus one is doing what the mpris interface is supposed to do, but with a different name
<jdstrand> popey: does mpris with 'name: auryo' and another mpris with 'name: auryo-player' work?
<popey> the one that's in the store works on 17.10
<jdstrand> popey: (ie, you create two slots and slots both)
<popey> sorry, can you gimmie a pastebin? I don't fully understand
<ogra_> jdstrand, quick question ... if i added a content interface bit to my wine snap, could i start snapping random windows exe's that use that content interface as backend to run them via wine (or is execution of binaries blocked ?)
<popey> http://paste.ubuntu.com/25911480/ is what it looks like currently
<ogra_> jdstrand, (yes/no is enough as answer)
<popey> (I had to play around a lot to get this working, only got that working by copy/pasting and fiddling the gradio one)
<popey> so mine is based on the gradio snap which is in the store
<jdstrand> popey: http://paste.ubuntu.com/25911484/
<popey> lemme try that
<mvo> jdstrand: hm, could you please check if the go vet thing is something local? I just checked out upstream/master and my 17.10 go vet seems to be happy. or are you on bionic already?
<jdstrand> ogra_: execution of binaries is allowed. the trick is getting all the libs to work, etc
<ogra_> jdstrand, ok, thanks ...
<jdstrand> ogra_: but the security policy allows it
<Chipaca> mvo: my 16.04 vet on master throws that error
<jdstrand> ogra_: (mrwklix used for write and mrkix for read)
<ogra_> ok
<mvo> Chipaca: how strange, let me look harder
<ogra_> Mr. Kix and Mr. Wklix :)
<jdstrand> mvo: fyi, I'm seeing this with run-checks in a 16.04 lxd container
<jdstrand> ogra_: hehe :)
<jdstrand> mvo: (host is 17.10, logged into 16.04 container, running go vet)
<jdstrand> mvo: do you need more info than that?
<mvo> jdstrand: no, must be something on my side then, checking
<mvo> checking why I don't see the error
<Chipaca> waait
<Chipaca> jdstrand: can you remove pkg and try again?
<jdstrand> Chipaca: remove pkg? (sorry if I'm dense)
<jdstrand> oh in gopath
<Chipaca> jdstrand: rm "${GOPATH%%:*}/pkg"
<Chipaca> -r
<jdstrand> that worked
<jdstrand> mvo: ^
<mvo> aha!
<mvo> thanks Chipaca
<Chipaca> np
<popey> jdstrand: that worked, thanks. uploaded a new auryo
<jdstrand> popey: cool :)
<jdstrand> Chipaca, mvo: I need to keep a list of things to try. removing pkg, govendor, ...
<diddledan> what should I try snapping next?
<popey> diddledan: want suggestions? :)
<diddledan> please :-)
<popey> was gonna suggest nba-go but you already fixed it ;)
<diddledan> lol
<diddledan> I've got supertuxkart working. I need to get it in the store
<popey> diddledan: how about https://forum.snapcraft.io/t/audacity-2-2-0-snap-issues/2719 ? :)
 * diddledan goes looksee
<Chipaca> diddledan: simcity :-)
<jdstrand> popey: ok, done. please snap install it from the store and verify it does what you want
<popey> doing now
<kyrofa> kalikiana, did you hear about the BlockingIOError discoveries?
<kyrofa> I know you were hitting those as well
<popey> jdstrand: works as expected (on 17.10), thank you!
<popey> will start a thread about 16.04 on the forum
<jdstrand> popey (cc flexiondotorg): also, not sure if you saw, but I recommend snappy-debug be used now instead of raw logs. I fixed a bunch of issues with it based on sprint feedback
<popey> awesome, will do that
<jdstrand> most notably, it doesn't skip dbus any more
<popey> i noticed it gave some (more) helpful output when I ran it earlier, good job, thanks!
<jdstrand> awesome :)
<jdstrand> yw
<jdstrand> popey: note that auryo has an executable stack:
<jdstrand>  - functional-snap-v2:execstack
<jdstrand> 	Found files with executable stack. This adds PROT_EXEC to mmap(2) during mediation which may cause security denials. Either adjust your program to not require an executable stack, strip it with 'execstack --clear-execstack ...' or remove the affected file from your snap. Affected files: opt/Auryo/auryo
<jdstrand> 	https://forum.snapcraft.io/t/snap-and-executable-stacks/1812
<jdstrand> ./auryo_2.snap: FAIL
<jdstrand> why didn't the store notice that...
 * jdstrand will look into it
 * popey shrugs
<popey> it's an electron app
<popey> I imagine this is not the only app which has this issue - maybe look at discord and yakyak as other examples
<popey> (they're snapped identically)
<jdstrand> popey: I mentioned it to the discord guys
<jdstrand> popey: I haven't to yakyak (didn't know about it)
<jdstrand> popey: is this using electron builder? if so, perhaps it can be made to clear the execstack
<popey> no
<popey> all three are just dumping their pre-built stuff into a snap
<popey> two are proprietary, so we don't have visibility of the source to build
<jdstrand> ok, then them clearing it as part of their process is the way to go
<jdstrand> I'll see why the store isn't detecting it. it might be a 16.04 vs 17.10 thing
 * zyga-ubuntu feels better and starts coding again
<zyga-ubuntu> feeling better is still better than feeling worse
<mup> PR snapd#4161 opened: snapstate: add support for refresh.schedule=managed <Created by mvo5> <https://github.com/snapcore/snapd/pull/4161>
<kyrofa> elopio, the autopkgtest I spun up yesterday morning still hasn't run :(
<elopio> kyrofa: no, I'm waiting since saturday :(
<kyrofa> elopio, no way
<kyrofa> Really?
<kyrofa> Gosh
<popey> there was a big queue last week but it cleared
<popey> (I saw leo complain about the builders queue previously I think) ?
<nacc> a bunch of things are going through today, it seems like
<nacc> (from uploads i did last week, as well)
<popey> still only 40 min queue
<nacc> one of my snap LP builds took 48 hours to run :)
<kalikiana> kyrofa: discoveries?
<kyrofa> kalikiana, still don't know why Travis is tossing the BlockingIOError, but it's masking actual test failures-- run the test that's failing locally, and you'll see them
<mup> PR snapd#4162 opened: interfaces/kmod: treat failure to load module as non-fatal <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4162>
<elopio> cachio: most of the queue is snapd. Do you really need to run autopkgtests on every pr?
<popey> diddledan: how about calibre? They rev frequently. Something which builds a calibre snap which updates frequently would be nice. Popular app too
<kalikiana> kyrofa: last time I double checked one of those locally it was passing - are you talking about a particular one?
<diddledan> ok, so on my todo then: audacity, simcity/lincity, and calibre
<kyrofa> kalikiana, all the ones where it has happened to me :)
<diddledan> hah someone said the word calibre in the ubuntu podcast telegram. jinx!
<ogra_> calibre totally doesnt fit in that list ! ... the the others are cities !
<kalikiana> kyrofa: right. Just wondering if it's the same from your description
<diddledan> lol
<diddledan> calibrecity?
<Odd_Bloke> Hey folks, just posted about a problem with creating a snap I'm having: https://forum.snapcraft.io/t/creating-a-snap-with-a-bunch-of-python-scripts/2735
<ogra_> approved !
<Odd_Bloke> Input appreciated. :)
<nacc> Odd_Bloke: for classic snaps (at least), you're goign to want to build python in your snnap
<nacc> Odd_Bloke: fyi, otherwise you'll almost certainly get segfaults
<nacc> (well, ont almost certainly, but you might :)
<Odd_Bloke> nacc: The scripts don't even end up pointing at the Python in the snap.
<nacc> Odd_Bloke: even with the shebang rewriting?
<Odd_Bloke> nacc: Well, I think the problem is that I can't get snapcraft to get the scripts in there using the python plugin.
<kyrofa> shebang rewrites don't happen with the dump plugin
<Odd_Bloke> So I'm not getting the shebang rewrites.
<kyrofa> Odd_Bloke, your shebangs wouldn't need to be rewritten if they used /usr/bin/env
<nacc> Odd_Bloke: i thinkn you'd need to either use env, or have wrappers
<Odd_Bloke> Uh, they are using /usr/bin/env.
<Odd_Bloke> Let me double-check what's going on.
<Odd_Bloke> Oh, this may be a Python 2 vs 3 issue.
<elopio> kyrofa: do you know of a snaps that builds python? I need python3.6.
<nacc> elopio: https://git.launchpad.net/usd-importer/tree/snap/snapcraft.yaml
<nacc> elopio: we build python2 and 3
<elopio> thanks nacc. I had something similar but was getting  "libpython3.6m.so.1.0: cannot open shared object file: No such file or directory"
<elopio> I'll try copying some parts from yours
<nacc> elopio: that is a classic snap, but i don't thinkn it should matter for building
<elopio> nacc: no, I think my problem was the missing --prefix.
<nacc> elopio: ah sure
<diddledan> popey: regarding audacity, I've sent a tempdir patch upstream: https://github.com/audacity/audacity/pull/211
<mup> PR audacity/audacity#211: Update defaultTempDir path in AudacityApp.cpp <Created by diddledan> <https://github.com/audacity/audacity/pull/211>
<diddledan> still getting problems with it beyond those issues tho
<popey> nice
<diddledan> in jailmode audacity gets nuked by seccomp: Log: auid=1000 uid=1000 gid=1000 ses=5 pid=24254 comm="audacity" exe="/snap/audacity/x3/usr/bin/audacity" sig=31 arch=c000003e 50(listen) compat=0 ip=0x7f2d2ad911d7 code=0x0
<diddledan> I'm wondering what it's listening on
<diddledan> in devmode we're getting a different segfault: audacity: src/hostapi/alsa/pa_linux_alsa.c:1454: BuildDeviceList: Assertion `devIdx < numDeviceNames' failed.
<kalikiana> lool: You mentioned in you had a snap that snapcore/snapcraft#1654 was making work, that didn't build before?
<mup> PR snapcraft#1654: autotools: cross-compile using --host instead of env <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1654>
<lool> kalikiana: Yes
<lool> kalikiana: just do a simple autotools snap with e.g. gnu hello
<lool> when trying to cross-build for e.g. armhf, it will pass --host=armhf instead of --host=arm-linux-gnueabihf and it will fail to find compilers and bail out at configure
<elopio> nacc: it works! Thank you :)
<popey> diddledan: yeah, i had same, dunno what it's doing.
<popey> diddledan: used snappy-debug.security scanlog?
<diddledan> yup
<diddledan> in devmode the only denials are for xdg-user-dirs
<diddledan> Log: apparmor="ALLOWED" operation="open" profile="snap.audacity.audacity" name="/etc/xdg/user-dirs.conf" pid=25382 comm="xdg-user-dirs-u" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<diddledan> and Log: apparmor="ALLOWED" operation="open" profile="snap.audacity.audacity" name="/etc/default/nss" pid=25382 comm="xdg-user-dirs-u" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<diddledan> those are the only two messages in devmode with my tmpdir patch
<kalikiana> lool: Okay, will try that. I noticed it made no difference in our autotools hello world so I'm looking to fix that
<kalikiana> Thanks
<jdstrand> diddledan: the first should be fixed in 2.29
<kalikiana> ha, doesn't even configure, nice
<nacc> elopio: yw
<popey> jdstrand: diddledan i don't believe it is fixed in 2.29 - I'm on 2.29 here and I still see it
<kalikiana> kyrofa: seems like our autotools-hello sucks as a test case, if you agree I'll replace it in your --host PR so it actually passes only with your fix
<kyrofa> kalikiana, agreed
<kyrofa> Sorry, lost power here, didn't realize my modem was plugged into one of the "surge only" outlets of the UPS
<kyrofa> Hopefully that lasts for a while
<kyrofa> Coding by Candlelight baby
<ogra_> romantic !
<kalikiana> kyrofa: ouch. hope nothing got lost
<kyrofa> Nah
<cjwatson> popey: builders and autopkgtests are very separate queues FWIW, even though they share clouds
<popey> ah okay :)
<jdstrand> popey: https://github.com/snapcore/snapd/commit/acc3eadfb5fb1e6c7553104646cb128646ac2d50 (2.29.2)
<popey> k
<kalikiana> kyrofa: Hrmmm how do your strange "subfolders" in git work? `git push kyrofa autotools_cross_host` doesn't work... I don't know how to specify the "bugfix" component
<kalikiana> need to change location, getting kicked out of the coffee shop, back in a bit
<kyrofa> kalikiana, it's part of the branch name. bugfix/<bugref>/description
<mup> PR snapd#4163 opened: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <https://github.com/snapcore/snapd/pull/4163>
<zyga-ubuntu> jdstrand: hey
<zyga-ubuntu> jdstrand: not sure if you have energy for reviews today
<zyga-ubuntu> Pharaoh_Atem: hey
<zyga-ubuntu> guess which OS I'm running?
<jdstrand> zyga-ubuntu: I need to look into an issue for ondra first, but feel free to give me the list on irc
<zyga-ubuntu> jdstrand: I'm chopping new features into PRs, adding tests as needed, I just one have 4163
<zyga-ubuntu> jdstrand: I'm not well today
<jdstrand> zyga-ubuntu: sorry to hear that. hope you feel better
<zyga-ubuntu> jdstrand: thank you, I'm slightly better now
<popey> jdstrand: just noticed a minor typo in snappy-debug... "If have dropped messages, use:"
 * diddledan have dropped message
<Pharaoh_Atem> zyga-ubuntu: Ubuntu?
<zyga-ubuntu> Pharaoh_Atem: MINIX 3 :D
 * zyga-ubuntu has some humor back
<kalikiana> kyrofa: Whatever I try I get doesn't exist or permission denied... how is it supposed to work?
<kyrofa> kalikiana, well, what exactly are you trying?
<kalikiana> kyrofa: Trying to push, like I said, doesn't work...
<kalikiana> `git push kyrofa bugfix/autotools_cross_host` gives me "src refspec [...] does not match any.."
<kyrofa> kalikiana, what is the `kyrofa` remote?
<kalikiana> kyrofa: Â»   url = https://github.com/kyrofa/snapcraft.git
<kalikiana> Â»   pushurl = git@github.com:kyrofa/snapcraft.git
<kalikiana> Â»   fetch = +refs/heads/*:refs/remotes/kyrofa/*
<kalikiana> This pattern normally works for any branch from another user or project
<kyrofa> kalikiana, and the branch is checked out locally as `bugfix/autotools_cross_host` ?
<kalikiana> kyrofa: it's called autotools_cross_host - so bugfix should be part of the name?
<kyrofa> kalikiana, it means you're trying to push a branch you don't have
<kyrofa> kalikiana, try `git push kyrofa autotools_cross_host:bugfix/autotools_cross_host`
<kalikiana> oh
<kalikiana> that worked
<kalikiana> kyrofa: Thanks!
<kalikiana> clearly a dwim version without twice redundant arguments would be boring
 * kalikiana wipes a tear for bzr
<mup> PR snapd#4164 opened: interfaces/raw-usb: match on SUBSYSTEM, not SUBSYSTEMS <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4164>
<mup> PR snapd#4165 opened: interfaces/raw-usb: match on SUBSYSTEM, not SUBSYSTEMS <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4165>
<jdstrand> mvo: those are the last of the known udev tagging fallout fixes ^. That is the fix for ondra I mentioned. I milestoned the second for 2.29
<zyga-ubuntu> jdstrand: do you think we should parse udev rules?
<zyga-ubuntu> jdstrand: and have you seen https://github.com/snapcore/snapd/pull/4144
<mup> PR #4144: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144>
<jdstrand> zyga-ubuntu: I have a spread test up for review that would catch stuff like this
<jdstrand> jeez, no I did not see that
<kalikiana> kyrofa: btw mind having another look at snapcraft#1412 which you reviewed before?
<mup> PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412>
<zyga-ubuntu> jdstrand: I'll merge master to fix the conflicts
<zyga-ubuntu> jdstrand: but review is very much welcome
<mup> PR snapd#4166 opened: cmd/snap-update-ns: detect and report read-only filesystems <Created by zyga> <https://github.com/snapcore/snapd/pull/4166>
<cachio> elopio, there is a plan to remove that to nightly
<cachio> elopio, it is comming soon
<cachio> I need some confirmation before removing this
<cachio> jdstrand, https://paste.ubuntu.com/25912364/
<cachio> jdstrand, any idea what I need to plug to avoid this error
<jdstrand> cachio: the security policy does't like that you are connecting from unconfined. if you have a snap that plugs network-status, I think it would work
<jdstrand> that said, that would be a bug in network-status
<jdstrand> I'll take a look at that (added to todo for next batch of policy updates, but not for today)
<cachio> jdstrand, sure, thanks
<elopio> thanks cachio
<elopio> cachio: also, you could run the tests for amd64 in travis with adt-lxd. We are close to get that working.
<cachio> elopio, well, we are using linode to do that, do you how much you pay for test machines in travis? does it provide any 32 bits machines?
<zyga-ubuntu> jdstrand: I merged master into https://github.com/snapcore/snapd/pull/4144
<mup> PR #4144: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144>
<zyga-ubuntu> if you have udev energy in you left please have a look
<zyga-ubuntu> I can polish that based on your and pawel's feedback
<zyga-ubuntu> and it can go into .3 (I suspect we have to)
<jdstrand> ack
<zyga-ubuntu> jdstrand: thank you, I guess you can ignore the non-udev PRs for now
<zyga-ubuntu> (bigger fire)
<mup> PR snapd#4167 opened: cmd/snap-update-ns: fix golint and some stale comments <Created by zyga> <https://github.com/snapcore/snapd/pull/4167>
<mup> PR snapd#4168 opened: cmd/snap-update-ns: add new helpers for mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/4168>
<ikey> zyga-ubuntu, i saw you on here as zyga-solus a few times, were you doing anythings there that i could be tripping over?
<ikey> wanna get solus snapd rebased and integrated
 * elopio goes to the bank before the rain
<elopio> cachio: we are using the travis free account, and it doesn't provide 32 machines.
<zyga-ubuntu> ikey: no, I didn't do anything more I'm afraid
<zyga-ubuntu> ikey: go ahead and rebase, note that we'll have 2.29.3 soon
<zyga-ubuntu> (with more fixes)
<ikey> is 29 stable or unstable?
<zyga-ubuntu> but those should be clean for solus
<zyga-ubuntu> unstable still with udev fixes incoming
<zyga-ubuntu> but if you rebase for .2 you should be ready for .3 soon
<ikey> right
<ikey> so it makes sense to get us on the unstable branch
<ikey> gonna be a massive pita working out the pending status of existing fixes otherwise
<ikey> ok ill make a tarball of snapd 2.29.2
 * ikey has a magic script somewhere
<ikey> snapd-2.29.2.tar.xz ready, heh
<ikey> https://dev.solus-project.com/source/common/browse/master/Scripts/goget.sh <- abomination
<mup> PR snapd#4169 opened: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <https://github.com/snapcore/snapd/pull/4169>
<ikey> but "works"
 * zyga-ubuntu pushed a few PRs for upcoming layouts
<zyga-ubuntu> I _guess_ I'm done for today
<zyga-ubuntu> painkillers and other "meds" made 2nd half of my day useful but I'm far from being good
<ikey> :/
<ikey> "get well soon" ?
<zyga-ubuntu> thanks :)
<zyga-ubuntu> just bad luck with my back and the weather sucks :/
<zyga-ubuntu> I want back to Spain :(
<ikey> ah
<zyga-ubuntu> I have a few more bits of code I could share but I think this is more than enough for now
<zyga-ubuntu> well...
<zyga-ubuntu> well
<zyga-ubuntu> I could share one more function
<ikey> lol
<zyga-ubuntu> but we have 43 PRs already
<zyga-ubuntu> damn it... :D
<ikey> damn
<zyga-ubuntu> and I have steam open just now
 * ikey too
<zyga-ubuntu> btw, does steam work on solus with amd GPus?
<ikey> yeah
<zyga-ubuntu> I have a pair of ...
 * zyga-ubuntu checks
<ikey> testing a regression with hitman here
 * ikey also has steam open lol
<ikey> just put out LSI 0.6
<ikey> im hoping the next major will be the snap
<ikey> and we can start ripping steam out of solus itself
<zyga-ubuntu> AMD R9 280X (AFAIK)
<ikey> should be good after full updates
<ikey> so that amdgpu kicks in properly
<ikey> (on 4.13)
<zyga-ubuntu> I'll install solus on a 2nd HDD and see what works
<zyga-ubuntu> I'm kind of curious
<ikey> we're a few weeks out yet from a release and im getting my headline features together
<ikey> can't just do refreshed ISOs anymore
<zyga-ubuntu> it's a budget gaming box, with amd x4 845 and a pair of old used GPus
<ikey> LSI will make sure the open source drivers at the very least
<ikey> and the steam package depends on LSI and a buttload of libs
<ikey> to make sure all the games work
<zyga-ubuntu> yeah, I was curious about how that works
<zyga-ubuntu> that's why I want to try
<ikey> *open source drivers work
<ikey> so for that we blacklist libstdc++ vendoring in LSI
<ikey> which is how it magically works
<ikey> https://github.com/solus-project/linux-steam-integration/blob/master/src/intercept/main.c#L108
<ikey> ^^
<ikey> can't have our users doing obscure `find | xargs rm -rf` commands..
<zyga-ubuntu> :D
<ikey> todays change was slightly terrifying
<ikey> new games are shipping with vendored libressl..
<ikey> very, very old libressl
<ikey> so i had to teach the intercept module to redirect versioned libssl/libcrypto to a lib{ssl,crypto}-libressl.so on the fly..
<ikey> cuz security. -_-
<ikey> (some of them are shipping 5+ year old openssls, old curls, etc.)
<zyga-ubuntu> that's pretty interesting
<zyga-ubuntu> we have one problem with libc and shm_open
<ikey> o?
<zyga-ubuntu> I wonder if we coudl capture and redirect that function to something snap-aware (but context aware too)
<zyga-ubuntu> some calls need to be left as-is
<ikey> you could but only for non-setuid binaries
<ikey> lsi is using LD_AUDIT for this
<ikey> and LD_PRELOAD for the other portion
<zyga-ubuntu> some should be tweaked so that the created /dev/shm thing is scoped to the snap
<ikey> basically we hijack c lib
<zyga-ubuntu> yeah,
<ikey> and linker..
<zyga-ubuntu> I think we may need to as well
<zyga-ubuntu> I'll need to read your code :)
<ikey> please do - i tried to keep it simple enough and functional
<zyga-ubuntu> but first...
<ikey> lol ya
<zyga-ubuntu> some gameing :)
<ikey> enjoy!
<zyga-ubuntu> I'm re-playing wolf games before looking at new colossus
<ikey> :D
<ikey> "/home/ufee1dead/.local/share/Steam/steamapps/common/Hitmanâ¢/bin/libffmpegsumo.so"
 * ikey dies inside
<ikey> TM in a path
<zyga-ubuntu> oh wow
<zyga-ubuntu> someone was NACKed by legal :D
<kalikiana> clobrano: hey
<kalikiana> clemensv:  can you respond to my comment here snapcraft#1648 ?
<mup> PR snapcraft#1648: sources: get svn revision with --show-item flag <Created by clobrano> <https://github.com/snapcore/snapcraft/pull/1648>
 * kalikiana going to wrap up in a bit... long day
<c-lobrano> kalikiana: hey, sure, just give me a minute
<kalikiana> no rush
<cachio> elopio, and how many machines does it provide within the free account?
<cachio> elopio, I'll take a look to travis infra
<cachio> that could be a good alternative
<kyrofa> cachio, Travis? 5, I think
<Pharaoh_Atem> ikey: I'm impressed something didn't explode over that
<ikey> lol
<cachio> kyrofa, good, thanks
<zyga-ubuntu> darn
<zyga-ubuntu> drat
<zyga-ubuntu> I was supposed not to do this
<zyga-ubuntu> jdstrand: one PR to look at
<mup> PR snapd#4170 opened: cmd/snap-update-ns: add designWritableMimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4170>
<zyga-ubuntu> this is the tmpfs designer
<zyga-ubuntu> I have a good number of prerequisite branches
<zyga-ubuntu> but this PR just adds one function for conceptually doing things and contains the most important logic
<zyga-ubuntu> I requested you as a reviewer
 * zyga-ubuntu really EODs now
<cachio> zyga-ubuntu, hey
<cachio> enjoy your EOD :)
<zyga-ubuntu> o/
<mwhudson> github reviews still suck for stacked PRs right
<mup> PR snapd#4171 opened: tests: adding test to test physical memory observe interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4171>
<dwbrite> Hello, just wanted to pop in and mention that GogLand has been renamed to GoLand, so should be updated in the Featured Snaps section of snapcraft.io
<kyrofa> jdstrand, am I correct that a snap using the kernel-module-control plug will not be denied installation?
<kyrofa> *sigh* WILL be denied installation
<jdstrand> kyrofa: without a snap decl, yes
<kyrofa> jdstrand, how do we expect people to experiment with such interfaces?
<kyrofa> jdstrand, I've suggested people look into it instead of rolling their own kernel, but then they can't
<jdstrand> kyrofa: if you install with --dangerous it works fine
<kyrofa> Oh, really? Did that change recently?
<jdstrand> no. long time ago for the reason you mentioned
<kyrofa> Oh, whew, excellent
<kyrofa> It's been a while then
<jdstrand> kyrofa: if it doesn'
<jdstrand> t work the way I described, it's a bug
<jdstrand> but it should. people do this all the time :)
#snappy 2017-11-08
<ikey> crazy question here
<ikey> lets say i wanted to control the cpu governor from inside a snap...
<ikey> to switch between powersave/ondemand + performance...
<ikey> would this be something i could ever do?
<mborzecki> morning everyone
<mup> PR snapd#4164 closed: interfaces/raw-usb: match on SUBSYSTEM, not SUBSYSTEMS <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4164>
<zyga-ubuntu> o/
<zyga-ubuntu> mborzecki: you start early :)
<mborzecki> zyga-ubuntu: hey, yeah i plan to keep a regular 7-15 schedule, otherwise my day goes to hell quickly
<mborzecki> besides, my wife drives kids to school at ~7 so I'm already up at ~5:45-6
<mborzecki> zyga-ubuntu: no rush about the review :) suppose you have things to do in the morning
<mup> PR snapd#4151 closed: tests: fix security-device-cgroup* tests on devices with framebuffer <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4151>
<zyga-ubuntu> mborzecki: yeah, I feel broken-ish still
<zyga-ubuntu> my yesterday was a disaster, I started my day in the late afternoon after meds helped, then stayed way too long (as usual)
<mvo> mborzecki: uh, still not feeling well? take it easy then
<mborzecki> caught a cold?
<zyga-ubuntu> I need to adopt the morning / early afternoon cycle
<zyga-ubuntu> both that and still recovering from back pain (over a week now) :/
<zyga-ubuntu> mvo: I'll prep kids and I'll focus on udev branches for 2.29 / master
<zyga-ubuntu> mvo: I got a review from jamie on udev tagging on hooks and I need to tweak it to format the output differently (sorting)
<mvo> zyga-ubuntu: more to come? meh
<mvo> zyga-ubuntu: or the hooks one?
<zyga-ubuntu> the hooks one
<mvo> zyga-ubuntu: aha, ok. thank you!
<zyga-ubuntu> it will conflict after some other bits land so I'll focus on that first
<mvo> pedronis: for later (not urgent at all) - 3992 needs some love, unit test failure currently
<zyga-ubuntu> I guess today is final 2.29.3 attempt, right?
<mvo> zyga-ubuntu: well, I would like to do 2.29.2 and then 2.29.3 a week later, unless we have regression in 2.29 that were not in 2.28 already
<mvo> zyga-ubuntu: but depends a bit on QA feedback, we wanted to release today but that seems unlikely given that we need CE results
<zyga-ubuntu> mvo: I see, ok
<zyga-ubuntu> I'll do my best to help as soon kids are sorted
<mup> PR snapd#4121 closed: overlord/snapstate: toggle ignore-validation as needed as we do for channel <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4121>
<mup> PR snapd#4125 closed: corecfg:  support setting proxy.store if there's a matching store assertion <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4125>
<mborzecki> is /var/lib/snapd/apparmor/snap-confine needed if snap-confine was configured with --disable-apparmor?
<zyga-ubuntu> mborzecki: no
<zyga-ubuntu> but
<zyga-ubuntu> snapd will do runtime detection and will create and may populate that directory anyway
<mborzecki> oh, ok
<zyga-ubuntu> I think in general it is better to enable apparmor
<zyga-ubuntu> even if the kernel is not apparmor aware
<zyga-ubuntu> (as long as there is userspace)
<mborzecki> yeah, arch is so manly that we don't use apparmor...
<zyga-ubuntu> my point is that the configure time options are partial, they don't affect snapd
<zyga-ubuntu> so I'd, if you can, enable apparmor to the extent possible
<mborzecki> i'm getting close with arch packaging, at least the blender snap works just fine (though it's classinc, but it didn't work before anyway)
<elopio> snappy-m-o autopkgtest 1716 xenial:amd64
<snappy-m-o> elopio: I've just triggered your test.
<elopio> snappy-m-o autopkgtest 1657 xenial:amd64
<snappy-m-o> elopio: I've just triggered your test.
<zyga-ubuntu> classic is actually harder :)
<mborzecki> btw. hello-world.evil 'If you see this line the confinement is not working correctly, please file a bug' will not show only if using apparmor?
<zyga-ubuntu> yes
<zyga-ubuntu> it's a _very_ old and simplistic test btw
<mborzecki> ok, i saw the message and wasn't sure whether I've screwed sth up or the system is missing some piece of infra
<mborzecki> oh, and cleaned up environment file, now you can properly set SNAPD_DEBUG=1 for the daemon :P
<mvo> mborzecki: 4135 has some simple nitpick things then it can go in from my POV
<mborzecki> mvo: thanks for the review
<mvo> mborzecki: felt slightly bad as it is really just nitpicks but then consistency in the codebase++ and all that :)
<mborzecki> sure thing
<mvo> (I mean, I felt slightly bad about nitpicking so much)
<zyga-ubuntu> nitpick: nitpick less
<zyga-ubuntu> :)
 * zyga-ubuntu looks at sorting udev rules better
<mborzecki> is there something like a smoke test i could use to verify that local snapd installation works as expected?
<zyga-ubuntu> mborzecki: spread tests, but that's one big leap to do
<zyga-ubuntu> mborzecki: if you run spread you will find all the interesting details that are broken
<mborzecki> i was hoping for something i can run in 5 minutes locally to verify that the arch package works ok
<zyga-ubuntu> you can run something for 5 minutes or you can run spread to find out if it works well, in my experience it's almost always something unexpected that fails mysteriously due to bugs or missing packaging
<zyga-ubuntu> mborzecki: but don't get me wrong, just use it daily and we'll know over time
<zyga-ubuntu> mborzecki: but there are some many features that only a spread run is a really good measure of what is broken
<mborzecki> hmm DirsTestSuite.TestClassicConfinementSupportOnSpecificDistributions() started failing out of the blue
<mborzecki> SupportsClassicConfinement() found /snap in my system
<zyga-ubuntu> perhaps missing mocking
<mborzecki> there's something weird about that test, its outcome may be altered by having the package installed in the system
<mborzecki> the whole check-SnapMountDir-symlink should probably be mocked
<mvo> mborzecki: yeah, sounds very much like an oversight from our patrt
<mvo> part
 * zyga-ubuntu goes to change 26 unit tests after rendering of udev rules got changed 
<kalikiana> good morning
<mvo> hey kalikiana - good morning
<mup> PR snapd#4172 opened:  interfaces/kmod: simplify loadModules now that errors are ignored  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4172>
<zyga-ubuntu> mvo: reviewed
<mborzecki> that feeling when you spend time mocking something just to come to a relization that a simpler fix is only a couple of lines
 * mvo hugs mborzecki - we have all been there
 * mvo tries to reproduce the lxd/juju bug from the forum
<mborzecki> pushed fixes for #4135
<mup> PR #4135: cmd/{snap-seccomp,snap-confine-ns},osutil,interfaces/account_control: workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135>
<zyga-ubuntu> mvo: can you look at https://github.com/snapcore/snapd/pull/4144 please
<mup> PR #4144: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144>
<zyga-ubuntu> I adjusted as jdstrand requested,
<zyga-ubuntu> the diff is slighltly larger because of how formatting and sorting is done but this should help in readability of actual udev rules
<pedronis> mvo: about #3992, after some recent discussions is not so clear anymore that is exactly what we need, IÂ will close until that area is been worked on concretely again
<mup> PR #3992: asserts: add cross-checking for snap-build <Created by pedronis> <https://github.com/snapcore/snapd/pull/3992>
<mup> PR snapd#3992 closed: asserts: add cross-checking for snap-build <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3992>
<mup> PR snapd#4165 closed: interfaces/raw-usb: match on SUBSYSTEM, not SUBSYSTEMS (2.29) <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4165>
<zyga-ubuntu> I need a review for https://github.com/snapcore/snapd/pull/4163
<mup> PR #4163: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <https://github.com/snapcore/snapd/pull/4163>
<zyga-ubuntu> jamesh: failing tests on 4140
<mup> PR snapd#4167 closed: cmd/snap-update-ns: fix golint and some stale comments <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4167>
<zyga-ubuntu> mborzecki: conflict on 4135
<mborzecki> zyga-ubuntu: s/update.XSnapdGid/update.XSnapdGID/ right?
<mborzecki> when merging a branch, do you leave the list of files with conflicts in the commit message?
<zyga-ubuntu> mborzecki: hmm?
<zyga-ubuntu> mborzecki: about the conflicts, not really, I think those are stripped out
<mcphail> Good morning all. Will the patches needed for snaps be included in the mainline 4.14 kernel? I'm thinking of switching graphics cards to AMD, and that might push me into upstream kernel territory for best performance
<zyga-ubuntu> mcphail: this is a question for jjohansen; AFAIK one patch was still discussed and that was blocking the merge so perhaps the answer is no
<mcphail> aah. thanks zyga-ubuntu
<mborzecki> zyga-ubuntu: conflicts are resolved now
 * zyga-ubuntu -> coffee, brb
<zyga-ubuntu> mborzecki: thank you
<mcphail> mborzecki: great :)
<mup> PR snapd#4173 opened: corecfg: validate refresh.schedule when it is applied <Created by mvo5> <https://github.com/snapcore/snapd/pull/4173>
<zyga-ubuntu> mvo: removed where? ^^
<zyga-ubuntu> mvo: you said that we did this in the test suite
<zyga-ubuntu> and that you removed that now
<mborzecki> zyga-ubuntu: added some comments to #4163
<mup> PR #4163: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <https://github.com/snapcore/snapd/pull/4163>
<zyga-ubuntu> mborzecki: thank you
<mvo> zyga-ubuntu: ups, sorry, forgot to push that commit, will do so in a sec
<mborzecki> zyga-ubuntu: i'm not entirely sure about that "/", i may be worth double checking cause it looks like you'll do `segment := segments[-1]` in secureMkDir
<mvo> zyga-ubuntu: force pushed, sorry but I also forgot to add the header to corecfg.go
<pedronis> mvo: what's the schedule for edge builds atm ?
<mvo> pedronis: its broken right now, its supposed to happen after merges to master that have a green test
<pedronis> heh
<pedronis> is that spread-cron, or something else?
<mvo> pedronis: yes, spread cron
<pedronis> :(
<mvo> pedronis: I triggered it manually this morning so we should have a proper edge soon
<mvo> but that is not a soluation of course
<mvo> solution even
<pedronis> mvo: after or before the proxy.store= merge ?
<mvo> pedronis: I think after, this merged happend last night, right?
<pedronis> mvo: no, you merged it this morning I think
 * kalikiana coffee
<zyga-ubuntu> mborzecki: yeah, I'm adding tests
<zyga-ubuntu> mvo: thanks :)
<mvo> pedronis: hm, let me double check then
<mvo> zyga-ubuntu: thank you!
<mvo> pedronis: according to launchpad it is in
<pedronis> ok
<zyga-ubuntu> mborzecki: pushed with some updates, thank you for spotting that
<mborzecki> zyga-ubuntu: similar thing with secureMkFile
<mborzecki> but I think you can bail out there early by checking if the path does not end with /
<zyga-ubuntu> mborzecki: or just is "/", yeah
<zyga-ubuntu> mborzecki: I decided not to bail but instead check length around critical places
<mborzecki> just checking / will not cover a path like /foo/bar/
<zyga-ubuntu> mborzecki: this works just as fine and has lower coverage impact
<zyga-ubuntu> mborzecki: I mean check if the actual full path is exactly "/"
<pedronis> mvo: I don't understand the refresh.schedule change in the tests? isn't the idea that we don't want refreshes during the tests? shouldn't we put something correct back?
<mborzecki> zyga-ubuntu: uhh, yeah, i meant for secureMkFile you'll probably need to check if the path does not end with /
<zyga-ubuntu> mborzecki: we do filepath.Clean on that
<zyga-ubuntu> it will chop off the final /
<zyga-ubuntu> it's a bit tricky, I agree
<zyga-ubuntu> mborzecki: I'll look at mkfile now
<zyga-ubuntu> mborzecki: I think for mkfile we should error if name ends with "/"
<mborzecki> yup
<mvo> pedronis: I can look into this, right now the settings have no effect (they will be rejected by snapd when it reads them internally) so things are not worse than before. but I agree this is a good opportunity to ensure things are properly done
<mvo> pedronis: I fix it
<zyga-ubuntu> mvo: and perhaps this can explain random failures (some of them)
<zyga-ubuntu> where we just refresh
<mvo> zyga-ubuntu: definitely
<zyga-ubuntu> mborzecki: updated and pushed https://github.com/snapcore/snapd/pull/4169
<mup> PR #4169: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <https://github.com/snapcore/snapd/pull/4169>
<zyga-ubuntu> mborzecki: In the end I rebased because somehow the merge was messy
<mborzecki> ok
<zyga-ubuntu> mborzecki: so please look at https://github.com/snapcore/snapd/pull/4169/commits/08d3ed6f54de26a7e671b58453044baebf591e1d
<mborzecki> zyga-ubuntu: sorry for poking your reviews :) it's just that you have so many of them
<zyga-ubuntu> mborzecki: thank you :-D I cannot be happier really
<zyga-ubuntu> usually we beg for reviews
<mup> PR snapd#4162 closed: interfaces/kmod: treat failure to load module as non-fatal <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4162>
<zyga-ubuntu> mborzecki: https://github.com/snapcore/snapd/pull/4166 is trivial
<mup> PR #4166: cmd/snap-update-ns: detect and report read-only filesystems <Created by zyga> <https://github.com/snapcore/snapd/pull/4166>
<zyga-ubuntu> just https://github.com/snapcore/snapd/pull/4166/commits/c21a85a15c923a5935d5374fe76c29463030c588 on top of other PRs
<mborzecki> i'm look at it right now
<zyga-ubuntu> (I have a similar one, unpushed, for mkfile)
<zyga-ubuntu> mborzecki: once some of those land I'll rebase my working branch and start push one more trivial branch and two more interesting branches for the "tmpfs bind mount farm"
<zyga-ubuntu> and with some luck, it will all fall into place and "just work"
<zyga-ubuntu> I still need to implement symlink creation and generalize actions for create/destroy (so that we don't "mount" symlinks which is just confusing)
<mborzecki> 4170 is part of this work too?
<zyga-ubuntu> yes
<zyga-ubuntu> that's the "main" element in many ways
<zyga-ubuntu> everything else is to make that part work
<niemeyer> o/
<mborzecki> so high level view is that once you hit a read only path, you'll bind tmpfs over this and recreate all the things from that original location inside tmpfs?
<zyga-ubuntu> mborzecki: exactly
<mborzecki> niemeyer: hi
<zyga-ubuntu> hey niemeyer
<pstolowski> hi niemeyer
<zyga-ubuntu> Pharaoh_Atem: hey, did you see https://bugzilla.redhat.com/show_bug.cgi?id=1509586
<zyga-ubuntu> I don't have F27 around
<niemeyer> Hey there
 * zyga-ubuntu -> break
<pstolowski> pedronis, do you have a moment for HO?
<mborzecki> https://travis-ci.org/snapcore/snapd/builds/299009217 hit travis timeout, should i restart?
<zyga-ubuntu> yes
<zyga-ubuntu> ok, I really want to break now
<zyga-ubuntu> see you at the call
<mvo> pedronis: fwiw, core in edge should be up-to-date now
<mvo> jdstrand: the /dev/mem test that cachio did in PR 4171 is interesting - it fails with EPERM and no apparmor denial, this is strange, usually we get EPERM (instead of EACCESS) when the device cgroup access fails, but poking around in a spread VM with the failed test things look ok there. do you know if /dev/mem is handled specially (beside the strict_devmem kernel mode which should still allow us to read the first 1mb). fwiw, its correctly tagged
<mvo> in udev afaict
<mup> PR #4171: tests: adding test to test physical memory observe interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4171>
<mup> PR snapd#4174 opened: packaging/arch: packaging update <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4174>
<mup> PR snapcraft#1648 closed: sources: get svn revision with --show-item flag <bug> <Created by clobrano> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1648>
<pedronis> Chipaca: hi, IÂ do plan to look at your aliases PR today or tomorrow
<niemeyer> jdstrand: Related to our conversation around user ids and daemon:
<niemeyer> https://github.com/snapcore/snapd/pull/4135/files#diff-be7cfe1e5aff69d70d80b1c2cabcaaccL749
<mup> PR #4135: cmd/{snap-seccomp,snap-confine-ns},osutil,interfaces/account_control: workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135>
<sergiusens> kalikiana mind looking into my comment on snapcraft#1633 ?
<mup> PR snapcraft#1633:  recording: record information from the image in container builds  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1633>
<jdstrand> niemeyer: hey, yeah I saw that and thought the same thing
<jdstrand> mvo: there are kernel controls for /dev/mem
<jdstrand> mvo, cachio: our kernels are configured with STRICT_DEVMEM. see interfaces/builtin/physical_memory_control.go for details
 * zyga-ubuntu just read a PR title as "add support for soviet activation"
<jdstrand> zyga-ubuntu: I don't know if I should laugh or give you a hug :)
<zyga-ubuntu> jdstrand: SOVIETS TRIGGERED!
<jdstrand> heh
<zyga-ubuntu> jdstrand: I pushed updates to udev tagging for hooks
<zyga-ubuntu> jdstrand: I'm running spread locally now to see if I broke something
<zyga-ubuntu> jdstrand: sorting by tag is actually a pretty nice idea
<zyga-ubuntu> jdstrand: I also added a comment that says # iface so that we know which interface added the rule
<zyga-ubuntu> jdstrand: have a look if you have time
<popey> Can someone please review my alias request? https://forum.snapcraft.io/t/alias-request-for-mgba/2710
<mvo> jdstrand: my understanding is that STRICT_DEVMEM allows access to the first 1mb of mem - it is also failig in open() already, so how is this supposed to work, does it just support mmap()?
<mvo> jdstrand: if you need to look it up, no worries, I can do this too :) just wondering if you know without research
<jdstrand> zyga-ubuntu: awesome, thanks!
<zyga-ubuntu> jdstrand: I think some spread tests fail but they are probably (probably) just too picky and grep for detailed strings
<zyga-ubuntu> I'll fix those soon
<zyga-ubuntu> (well, fixing now)
<jdstrand> popey: I planned to today (note, 1 week hasn't gone by yet)
<popey> ok :)
<mup> PR snapcraft#1720 opened: kernel plugin: introduce kernel-channel to select from which channel â¦ <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1720>
<zyga-ubuntu> Son_Goku: I'm installing gnome desktop on centos now, I can try your EPEL package soon
<Son_Goku> zyga-ubuntu: okay, cool
<zyga-ubuntu> Son_Goku: I forgot how to use yum :)
<Son_Goku> heh
<zyga-ubuntu> Son_Goku: is there a nice way to meta-install the desktop
<Son_Goku> there's a DNF for CentOS 7
<zyga-ubuntu> oh? it's not installed by default
<zyga-ubuntu> I'm on centos 7 for sure
<Son_Goku> https://seven.centos.org/2017/10/yum-4-is-available-for-testing/
<zyga-ubuntu> yum or dnf?
<Son_Goku> yum 4 == dnf
<zyga-ubuntu> ah
<zyga-ubuntu> but is the CLI the same?
<Son_Goku> Yep
<Son_Goku> yum4 is a symlink to /usr/bin/dnf
<Son_Goku> in Fedora, this is the "dnf-yum" package
<Son_Goku> zyga-ubuntu: so once that's installed, you can use dnf as normal
<mup> PR snapcraft#1655 closed: lxd: distinguish argless clean from clean -s pull <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1655>
<diddledan> the build service is refusing to let me login again
<diddledan> refusing my launchpad oauth token
<diddledan> "Error:Invalid association handle"
<diddledan> hmm, maybe it's specific to firefox (I have ublock origin installed, which might be conflicting)
<zyga-ubuntu> jdstrand: oh, drat
<zyga-ubuntu> jdstrand: my bad
<zyga-ubuntu> jdstrand: KERNEL=="foo", TAG+="bar" # this is a comment
<zyga-ubuntu> this is not valid
<zyga-ubuntu> udev, man... really?
<zyga-ubuntu> I need to change that to
<zyga-ubuntu> # this is a comment
<jdstrand> heh, yeah. it seems pretty finicky
<kalikiana> sergiusens: now that you asked me to change the test... I'm pondering to change "image-info: {architecture: test-architecture, created_at: test-created-at, fingerprint: test-fingerprint}" to use line-broken syntax without the {} for consistency
<kalikiana> need to check, though, how to change that. yaml has this behavior where the syntax depends on what types you use, not sure you can choose manually
<diddledan> flexiondotorg: or popey: the build service has lost the store-name references for inadyn, opentyrian, and warzone2100 from the snapcrafters repositories
<popey> que?
<diddledan> https://usercontent.irccloud-cdn.com/file/sJAYGe5k/Screenshot%20from%202017-11-08%2014-14-40.png
<popey> huh
<popey> thats odd
<zyga-ubuntu> jdstrand: I'm considering dropping the # iface comment
<popey> fixed warzone2100
<zyga-ubuntu> jdstrand: unless you think strongly we should keep it
<diddledan> I think it's because I had duplicates building from my own repo that should have been nuked. I nuked them, and it appears they've also disassociated the snapcrafters repos.
<zyga-ubuntu> it's just a hassle, I really hoped udev would suck less at parsing
<jdstrand> zyga-ubuntu: it would be nice, but I don't think it is strictly required
<popey> thats plausible
<popey> diddledan: fixed all three, they're all building now
<diddledan> thankyou :-)
<popey> np
<popey> in other news. diddledan would you like to be a collaborator on these snaps?
<diddledan> I was trying to force a build so they get i386 versions when I spotted it :-)
<popey> so you can help manage them in the store?
<jdstrand> zyga-ubuntu: I wonder if you could do # comment\nKERNEL==... for the first string...
<mvo> jdstrand: sorry, I had various laptop problems
<jdstrand> not super pretty
<diddledan> sure :D
<mvo> jdstrand: did you write anything after I asked about STRICT_DEVMEM?
<jdstrand> mvo: no. I don't know of anything else otoh
<popey> ok, what email address should I add you as?
<diddledan> my launchpad is diddledan, I think that's pointing at daniel@bowlhat.net
<mvo> jdstrand: ok, thank you, I poke a bit more, maybe the 1mb limit is on 32bit systems only, i.e. maybe this is arch dependent or something
<diddledan> alternatively diddledan@gmail will work
<mvo> jdstrand: eh, I mean the limit that you can access the first 1mb on dev/mem
 * diddledan fires up the forum to catch-up on todays posts
<jdstrand> mvo: yeah, I don't know otoh
<popey> which one do you sso with?
<mvo> jdstrand: ta
<diddledan> I try to sso with daniel@bowlhat.net
<popey> ok
<popey> will add you a bit later.
<diddledan> ta
<zyga-ubuntu> ok, soup time, I'll get back to udev shortly
<jdstrand> mvo: did you come up with a kmod test? I thought of one that we could use on core
<mvo> jdstrand: I just wrote a unit test, I was not thinking about a kmod spread test so far
<jdstrand> mvo: ok. I'll try a spread test soonish
<mvo> thanks
<mup> PR snapd#4135 closed: cmd/{snap-seccomp,snap-confine-ns},osutil,interfaces/account_control: workaround unit test failures on Arch <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4135>
<mup> PR snapd#4175 opened: dirs: use alt root when checking classic confinement support without â¦ <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4175>
<cachio_> niemeyer, partially fixed the issue on spread-cron
<cachio_> niemeyer, I'll add a PR to fix the problem
<cachio_> basically, it is failing when there are conflicts on the branches, and that be caused because a change we do and push
<sergiusens> kalikiana well the json in a yaml thing is just not nice; pseudo json I even.
<kalikiana> sergiusens: right. I'm trying to figure out if we can force the style
<elopio> hey popey, how can I enable build.snapcraft.io for vault?
<sergiusens> kalikiana if you just add the dict, the right thing will happen on unmarshalling
<popey> elopio: just did it, building now
<kalikiana> sergiusens: no it doesn't
<kalikiana> It's already a dict
<kalikiana> This is YAML
<elopio> popey: thanks. Do you have in mind any solution to keep the snapcrafters branches up-to-date with upstream? Latest vault stable is 8.3, and the latest we have released is 8.0.
<popey> elopio: pull requests against the yaml is the simplest thing
<popey> preferable to push it upstream of course
<zyga-ubuntu> re
<elopio> popey: yeah, but for the ones that upstream doesn't want. Would you mind if I experiment with vault to do it automatically?
<cachio_> elopio, could you share the setup you have done for the autopcktests exec on snapcraft?
<cachio_> elopio, you are running agains a ppa right?
<popey> elopio: sure
<popey> elopio: flexiondotorg has some scripts to automate this too
<sergiusens> kalikiana one comment on snapcraft#1412
<mup> PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412>
<elopio> cachio_: https://github.com/snapcore/snapcraft/pull/1643
<mup> PR snapcraft#1643: [WIP] tests: run daily autopkgtest in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1643>
<sergiusens> kalikiana also, not sure you noticed, but it would be nice to use a temfile context to copy the snap into the lxd accessible area when copying the snaps over
<cachio_> elopio, tx
<diddledan> I'm looking at gimp. Trying to get internationalization working. I can't figure out how to tell gimp that it's translations are in $SNAP/usr/share/locale
<diddledan> is there an environment variable to tell libc where to look for the locale folder?
<Chipaca> diddledan: LOCALEDIR?
<Chipaca> 'parently not
<Chipaca> diddledan: dunno
<zyga-ubuntu> WHYISITALLSODIFFICULT
<zyga-ubuntu> I'm hoping that with layouts it's not going to be that hard
<diddledan> when do we get layouts? :-p
 * diddledan ducks
<Chipaca> diddledan: tomorrow, but only if you use layouts to override glibc's date functions
<sergiusens> Chipaca careful, if someone makes glibc return dates after tomorrow you will be N days late ;-)
<Chipaca> sergiusens: or early!
<Chipaca> sergiusens: in fact, given that we're closer to 2038 than to 1970, on average i'll be early _anyway_!
 * zyga-ubuntu does the right thing wrt udev
<zyga-ubuntu> even if painful
 * Chipaca does the wrong things wrt everything else because he can blame pain meds
<zyga-ubuntu> ha
<zyga-ubuntu> I need some :(
<zyga-ubuntu> I forgot about that
<sergiusens> kalikiana wrt to that yaml thing; a dict that is yaml dumped should produce proper yaml, unless the thing that is json loaded is interpreted as a string in itself
<zyga-ubuntu> I almost never take painkillers as they make me numb :(
<kalikiana> sergiusens: it is YAML :-)
<sergiusens> Chipaca that is kind of like blaming bad behavior on alcohol :-)
<Chipaca> sergiusens: darn
<kalikiana> sergiusens: I'm trying to find a way to switch the syntax to multi-line in any case
<sergiusens> kalikiana oh, I thought we had code for that in the loader thing already
<sergiusens> kalikiana try http://paste.ubuntu.com/25918524/
<zyga-ubuntu> jdstrand: about that
<zyga-ubuntu> jdstrand: gpio has a new /dev based API
<zyga-ubuntu> jdstrand: we need to tweak the interface for that
<zyga-ubuntu> there are ioctls and /dev/gpiochip entries for each controller
<zyga-ubuntu> and the sysfs interface gets depracated (slowly)
<jdstrand> happy to review that PR (I don't have hardware to implement that so would be best if someone who could test with real hardware could implement it)
<zyga-ubuntu> gladly :)
<kalikiana> sergiusens: Oh nice! Thanks! Was staring at why this didn't seem to work at first, turns out it also makes architectures a list. But actually it makes everything consistent.
<kalikiana> pushed
<kalikiana> need to get some food into my stomach, back in a bit
<zyga-ubuntu> jdstrand: there, I retained all the comments
<zyga-ubuntu> spread is running now, fingers croessed
<zyga-ubuntu> jdstrand: man I wish we had https://github.com/snapcore/snapd/pull/4157 merged already
<mup> PR #4157: add spread test for connecting all interfaces (excepting gadget slots) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4157>
<zyga-ubuntu> niemeyer, jdstrand: interesting stuff here on lwn: https://lwn.net/Articles/738306/ - we could use the same idea for persistent identifiers of hot-plug usb devices
<zyga-ubuntu> I'll break now, kids home, I'll check back and garden my PRs
<zyga-ubuntu> I plan to send one more feature PR today, with changes-needed patch that enables tmpfs to work (and associated tests)
<zyga-ubuntu> that will be two feature patches short of all the major bits, then enabling this and integration and final spread test (that already exists and just has a path disabled) to show it works
<zyga-ubuntu> then reality will show where I was wrong :)
<zyga-ubuntu> but that's what I'm here for
<popey> elopio: i dont understand your nba-go - did you patch it? I absolutely can't get it to build. you using new snapcraft or something?
<popey> elopio: i am on 2.34 from candidate
<cachio_> elopio, so, you run from a container in travis the autopkgtests
<cachio_> elopio, you are running against all the ubuntu releases right?
<elopio> cachio_: no, that branch is only xenial. We will move it to nightly travis, so maybe we add more releases.
<elopio> popey: I'm using snapcraft from source, but what gets installed in the container is the latest snapcraft deb.
<popey> i dont understand, your branch builds, but if i just copy your yaml to an empty dir and source upstream it fails
<elopio> popey: ah, maybe submodules?
<elopio> no, doesn't look like it.
<elopio> let me try that way.
<mup> PR snapd#4176 opened: cmd: fix re-exec bug with classic confinement for host snapd < 2.28 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4176>
<Chipaca> niemeyer: 15pm -> 3pm in https://forum.snapcraft.io/t/1239/6
<niemeyer> Chipaca: Oops, thanks
<kyrofa> kalikiana, do you have an rpi handy?
<kyrofa> (or any other arch, really)
<kyrofa> We need to make sure cleanbuilding with a remote still works in snapcraft#1718
<mup> PR snapcraft#1718: lxd: let lxd choose the architecture <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1718>
<kyrofa> Remote of another arch, specifically
<elopio> popey: yeah, you are not crazy. This only works from a fork, no idea why.
<kalikiana> kyrofa: I have only amd64 and i386 servers
<kyrofa> i386 will do
<popey> hah
<kalikiana> kyrofa: I didn't stress test it yet since I wanted to know that we agree on the code. I'm still finding the string splitting rather ugly...
<kyrofa> kalikiana, well, before we were doing the same thing, but pretending it was YAML, right?
<elopio> popey: would you mind reporting a snapcraft bug? It could be that we are not installing the devDependencies for some reason. Or I don't know, this is weird, it needs debugging.
<kyrofa> It's not, so I'm not sure there's a better solution
<popey> elopio: where should i file that?
<mup> PR snapd#4177 opened: state: add change.LaneTasks helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/4177>
<kalikiana> kyrofa: well, it parsed as YAML... are you saying it might stop working?
<kyrofa> kalikiana, it could very well. It's definitely not dumped as YAML
<kyrofa> Seems dangerous to parse something as YAML that we know for a fact is not YAML
<kalikiana> kyrofa: Maybe stgraber should weigh in here actually
<pstolowski> pedronis, ^ can you take a look at #4177? I found your suggestion cleaner than an alternative I mentioned in the standup
<mup> PR #4177: state: add change.LaneTasks helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/4177>
<kyrofa> Yeah stgraber, why u no yaml?
<nacc> kyrofa: funny that you typed out why but not you
<kyrofa> Dangit
<nacc> just wasting bits!
<kyrofa> nacc, I'll admit, even typing 'u' was hard
<nacc> heh
<popey> elopio: https://bugs.launchpad.net/snapcraft/+bug/1731003
<mup> Bug #1731003: node app builds forked, but not referencing upstream source <Snapcraft:New> <https://launchpad.net/bugs/1731003>
<pedronis> pstolowski: yes, that looks like what IÂ had in mind
<zyga-ubuntu> mvo: wow
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4176/files
<mup> PR #4176: cmd: fix re-exec bug with classic confinement for host snapd < 2.28 <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4176>
<cachio_> elopio, you trigger the execution and where do you see the results?
<pedronis> pstolowski: that's probably a useful helper anyway but what was the problem with your other approach?
<cachio_> elopio, in the build history?
<pstolowski> pedronis, I stored ID of last task to wait in context (initially it was hook's task ID, then if you queued another command, it would be that command's task ID and so on. problem was servicestate.Control (and cmdstate.Exec) gives taskset
<pedronis> pstolowski: there's also a problem though that we should be waited by what was waiting for the tasks
<pedronis> sorry,
<pedronis> s/tasks/the configure hook task/
<elopio> cachio_: travis sends an email when the nightly fails.
<pedronis> pstolowski: there's also WaitTasks and HaltTasks on tasks to follow that btw, not sure if you knew those already
<elopio> popey: flexiondotorg: what do you think about this? https://github.com/snapcrafters/vault/pull/3/files
<mup> PR snapcrafters/vault#3: Build the latest unreleased tag <Created by elopio> <https://github.com/snapcrafters/vault/pull/3>
<elopio> (I'm kind of proud of it, so be nice :)
<pstolowski> pedronis, hmm, yeah I knew of them, but it didn't occur to me, WaitTasks can be useful indeed
<pstolowski> elopio, I like how you motivate reviewers, and hi btw :)
<pedronis> pstolowski: tbh I'm not quite sure how important it is to serialize the restarts vs what comes after the configure
<pstolowski> pedronis, what's the question/concern?
<elopio> pstolowski: hello :)
<pedronis> pstolowski: should we wait  the stop/start/restart  before doing anything that was waiting on configure itself
<pedronis> that's the question
<kyrofa> Hey niemeyer, any progress on the LXC issues? https://forum.snapcraft.io/t/lxc-error-when-updating-snap-and-cleaning-old-revisions/786/34
<zyga-ubuntu> jdstrand: hey, udev tagging for hooks works :)
<pstolowski> pedronis, configure is the last task, there is nothing strictly waiting for it
<kyrofa> elopio, any idea what's happening here? https://travis-ci.org/snapcore/snapcraft/jobs/299061202
<pedronis> pstolowski: that is not true in some complex refresh cases
<pedronis> if I remember correctly
<zyga-ubuntu> kyrofa: hey, no progress from me yet :-( I only reproduced it and didn't try to fix it
<zyga-ubuntu> kyrofa: sorry, too many things burning/working on at the same time
<pedronis> pstolowski: at the moment IÂ think is probably fine not to worry, but it's a question
<kyrofa> zyga-ubuntu, right, niemeyer mentioned someone else would work on it
<pedronis> pstolowski: if you look at doUpdate, you'll see that sometimes if attach more tasks after the doInstall ones
<pedronis> s/if attach/we attach/
 * zyga-ubuntu installs a new home router
<zyga-ubuntu> well, helper router
<zyga-ubuntu> and new as in "junk people threw out"
<kyrofa> I sorta feel like the lxc issue falls into the "make things work before working on new features" but I guess that's just me
<zyga-ubuntu> kyrofa: yes, I agree; we had some of that recently
 * zyga-ubuntu looks at udev
<zyga-ubuntu> kyrofa: I honestly think that we don't use lxc enough in the team to be burned by this; but I agree we should fix it as lxc is an important use-case
<kyrofa> zyga-ubuntu, yeah I keep hearing that :)
<pedronis> kyrofa: is it lxc or lxd ?
<kyrofa> pedronis, lxd
<kyrofa> pedronis, snaps only update three times before they never update again
<mup> PR snapd#4178 opened: asserts/assertstest:  fix use of hardcoded value when the passed  or default keys should be used <Created by pedronis> <https://github.com/snapcore/snapd/pull/4178>
<pstolowski> pedronis, ah, I see what you mean. when waiting for configure's hook task, the remaining tasks that may potentially be waiting for configure will not be waiting on us, we essentially insert new tasks in the middle
<pedronis> pstolowski: as I said, IÂ don't think is a problem atm, but IÂ don't know if that will stay true
<pstolowski> pedronis, if that ever becomes true, we will need a proper "run-queued-services" task that sits in the sequence i guess
 * zyga-ubuntu EODs, goes to tweak home networking to merge two networks into one
<mvo> zyga-ubuntu: yes :(
<mvo> zyga-ubuntu: sorry for the delay, had dinner
<mup> PR snapd#4179 opened: tests:  add a spread test for proxy.store setting together with store assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/4179>
<kalikiana> sergiusens: updated snapcraft#1412 as per your suggestion
<mup> PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412>
<kalikiana> going to wrap up shortly
<zyga-ubuntu> mvo: no worries, thank you for finding and fixing that
<zyga-ubuntu> mvo: I'm mentally drained now so I'll refrain from complex work
<zyga-ubuntu> mvo: any releases today/
<mvo> zyga-ubuntu: no release, I will push 2.29.3 tomorrow in my morning
<zyga-ubuntu> mvo: which of those do you plan to merge: https://github.com/snapcore/snapd/milestone/14
<mup> PR snapd#4180 opened: interfaces/many: misc policy updates for browser-support, cups-control and network-status <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4180>
<mup> PR snapd#4181 opened: interfaces/many: misc policy updates for browser-support, cups-control and network-status (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4181>
<mvo> zyga-ubuntu: I need to look at them with a fresh mind, maybe/probably all
<jdstrand> mvo: hey, for your consideration, PR #4181. it is not a regression. it would help mailspring and some other high profile electron snaps
<mup> PR #4181: interfaces/many: misc policy updates for browser-support, cups-control and network-status (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4181>
<mvo> jdstrand: looking
<jdstrand> a regression fix*
<jdstrand> mvo: the two other denial are not important for 2.29, but cachio__afk I think would appreciate one, and ogra_ the other
<jdstrand> s/denial/denial fixes/
<mvo> jdstrand: thanks, looks fine
<mvo> cachio__afk: some more validation work tomorrow for 2.29.3 :/
<zyga-ubuntu> man, we have 46PRs
<jdstrand> mvo: thanks. from mailspring upstream: "How long will it take for the policy change to reach the stable channel? Iâd love to ship the Mailspring snap (Iâm actually getting a couple emails / tweets a day about it because I said it was coming soon on the website ï¿¼) but I should probably wait until a fix for this is in the wild."
<jdstrand> mvo (cachio__afk): in other words, they will appreciate the effort
<Chipaca> ttfn
<mvo> jdstrand: we aim for Monday
<mvo> jdstrand: and yeah, looks like a no-brainer, will pull it in
<pedronis> zyga-ubuntu: close to needing us to declare a review sprint
<zyga-ubuntu> yes
<zyga-ubuntu> I was just thinking about that
<jdstrand> mvo: there is one more mpris denial I need to look at for popey. I don't know if that will turn into a PR but will try to get it in place (if needed) today
<jdstrand> mvo: the forum has been keeping my (and us!) busy!
<jdstrand> s/my/me/
<mvo> jdstrand: yeah, if you can get it done in (your) day, I can look at it in (my) tomorrow monring :)
<mvo> jdstrand: in ~12h
 * jdstrand nods
<jdstrand> yep
<mvo> jdstrand: $everything is keeping me busy :(
<jdstrand> that one shouldn't take too long to chase down
<jdstrand> mvo: heh, yeah, I bet
<pedronis> zyga-ubuntu: IÂ don't have immediate new feature coding to do, I need to go explore/analyze some things, I can also do reviews over the next few days
<mvo> jdstrand: but lots of good stuff!
<mvo> I will also do more reviews!
<zyga-ubuntu> pedronis: thank you!
<zyga-ubuntu> mvo: I think we need to really fix the lxc issue
 * mvo does the pinkey swear
<mvo> zyga-ubuntu: which one? the one in the forum?
<zyga-ubuntu> mvo: I'll break feature coding while I wait for reviews and I'll focus on that tomorrow
<zyga-ubuntu> kyrofa: all of my tomorrow I'll look at LX[cd]
<kyrofa> Thank you zyga-ubuntu, I appreciate that
<mvo> zyga-ubuntu: what lxc issue is that? sorry for being a bit slow
<pedronis> mvo: https://forum.snapcraft.io/t/lxc-snaps-dont-update/786 IÂ think
<zyga-ubuntu> mvo: refreshes inside containers break due to mount event ordering and special /snap sharing change
<pedronis> it's a long topic, been around since a while
<zyga-ubuntu> mvo: somewhat related to 14.04
<zyga-ubuntu> mvo: where simiar special sharing applies
<pedronis> didn't we fix something about order in 14.04 recently though?
<pedronis> rewriting units?
<zyga-ubuntu> pedronis: yes but that is different
<zyga-ubuntu> pedronis: we didn't rewrite on-disk units so that's still a todo
<pedronis> ah
<pedronis> do we have it somewhere?
<pedronis> on the forum?
<zyga-ubuntu> pedronis: here the lxd issue is really the mount events are in wrong order and this needs some love
<pedronis> in a bug?
<zyga-ubuntu> https://forum.snapcraft.io/t/lxc-snaps-dont-update/786/36
<mvo> zyga-ubuntu: thats not a regression, right?
<pedronis> no, the other issue, the rewrite units
<pedronis> mvo: no, it's been terrible for a long while ;)
<zyga-ubuntu> mvo: "doctor help, the patient is dying", "is it a regression?"  ;D
<zyga-ubuntu> mvo: technically no
<mvo> zyga-ubuntu: *pfff*
<mvo> zyga-ubuntu: ;)
<zyga-ubuntu> mvo: but I love your release-manager approach :)
<zyga-ubuntu> being very focused on making the release work more and not less
 * zyga-ubuntu hugs mvo for being so fantastic 
<mvo> zyga-ubuntu, pedronis well, you guys know where the term "triage" comes from, right?
<jdstrand> zyga-ubuntu: re udev tagging for hooks> \o/
<pedronis> mvo: do we do it?
<zyga-ubuntu> mvo: actually, I don't know
<mvo> pedronis: *cough*
<pedronis> anyway me needs to eod/have dinner
<zyga-ubuntu> jdstrand: 2.29 variant is the one without sorting changes
<mvo> zyga-ubuntu: worth looking it up, it comes from the medical triage of patients, i.e. treat the ones that need urgent attention first
 * zyga-ubuntu looks that up
<mvo> zyga-ubuntu: but conversely (in the worst case) don't spend time on something where there is no hope
<zyga-ubuntu> mvo: oh, that's an interesting concept
<zyga-ubuntu> do we tell the patient when that happens?
<mvo> zyga-ubuntu: *cough*
<mvo> zyga-ubuntu: or better *shhhh* ;)
<zyga-ubuntu> https://commons.wikimedia.org/wiki/File:Deconference-2002-triage-tag.jpg
<jdstrand> zyga-ubuntu (cc niemeyer): re https://lwn.net/Articles/738306/ (usbguard), this is actually on the security team's radar. It isn't bug free though. note that it isn't actually useful for snappy since the usb authorization system in the kernel is boolean, not application specific
<jdstrand> zyga-ubuntu (cc niemeyer): however, the idea of hooking into the kernel's uevent stream like usbguard does is absolutely something we'll want to do
<zyga-ubuntu> jdstrand: I was merely thinking about the "fingerprinting" logic where we could have stable-ish (more than now) identifiers for hotplug devices
<zyga-ubuntu> jdstrand: yeah
<zyga-ubuntu> jdstrand: I'd love to do implement that
<jdstrand> zyga-ubuntu: if only the usbgurad fingerprinting worked well :\
<zyga-ubuntu> mvo: I like how the "minor: walking wounded" category is green
<jdstrand> zyga-ubuntu: we can certainly look at it
<mvo> zyga-ubuntu: but seriously, if you have a fix and if its easy enough that even I can understand it I'm happy to take it
<mvo> zyga-ubuntu: lol
<zyga-ubuntu> mvo: I don't have a fix but I was thinking about one that may be very simple
<zyga-ubuntu> mvo: one-line simple, I'll try tomorrow
<mvo> zyga-ubuntu: oh? woah
<mvo> zyga-ubuntu: that would be lovely
<jdstrand> zyga-ubuntu: eg, if I plug my mouse into different buses, it shows up differently to usbguard
<zyga-ubuntu> jdstrand: yeah, it's not a trivial problem in any way
<zyga-ubuntu> jdstrand: but trivial problems are solved by dpkg
<jdstrand> anyway, let me get to mpris then back to look at pr #4144
<mup> PR #4144: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144>
<zyga-ubuntu> jdstrand: we are fixing interesting problems -
<zyga-ubuntu> ;-)
<jdstrand> :)
<zyga-ubuntu> thanks :)
<kyrofa> Yikes, github
<zyga-ubuntu> ?
<kyrofa> They're having javascript issues it seems
<zyga-ubuntu> Son_Goku: I have centos 7 but too exhausted to play
<zyga-ubuntu> Son_Goku: do some code reviews if you feel like jumping into layouts :)
<kyrofa> Looks like he doesn't want to jump into layouts
<zyga-ubuntu> kyrofa: or he jumped into layouts and is stuck in a namespace
<kyrofa> Oooo, good one
<Pharaoh_Atem> zyga-ubuntu: I hadn't seen the bug
<Pharaoh_Atem> and HALP, stuck in namespace!
<Pharaoh_Atem> :D
<zyga-ubuntu> :-)
<kyrofa> elopio, FYI, I'm looking at the Artful ruby errors. Want to make sure we aren't stepping on each other's toes
<kyrofa> I'm also assuming we're not starting our nightly autopkgtest idea given that we're stilling waiting for stuff from the weekend
<mvo> zyga-ubuntu: does 4146 (the 2.29 version) need cherry-picks from the changes that you did on the master version of this PR
<sergiusens> kyrofa what do you feel about my comment on snapcraft#1633
<mup> PR snapcraft#1633:  recording: record information from the image in container builds  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1633>
<kyrofa> sergiusens, raise a warning i.e. parse the output anyway?
<kyrofa> sergiusens, I totally agree that something we know is not YAML should not be parsed as YAML
<kyrofa> So yeah, I like the idea of trying to use --json, warning if it doesn't work, then falling back to processing the CLI output, but not with a YAML processor
<sergiusens> kyrofa no, if you do --format=json and it is not supported you would get an errno from the command
<sergiusens> kyrofa I'd say, just not support it, period
<kyrofa> Oh oh, this is recording
<sergiusens> yes, this is recording
<kyrofa> sergiusens, sorry, we're having this exact same discussion on another PR :P
<kyrofa> Well, almost
<kyrofa> sergiusens, yes, I agree
<elopio> kyrofa: I am debugging the autopkgtest on travis error. Not yet ready to land.
<sergiusens> kyrofa I know about the other PR, I just want to wrap up this recording thing; elopio want to close that one up with the latest comments?
<elopio> thanks for looking into ruby. This is the segfault, right?
<kyrofa> elopio, indeed
<sergiusens> kyrofa elopio decided to just continue landing things if they made sense and thoroughly tested
<kyrofa> sergiusens, fair enough. It's either that or kinda sit on our hands
<kyrofa> I need to refresh my memory for how to run our adt suite in lxc
<kyrofa> We can start doing that
<elopio> sergiusens: I agree with the --json thing. I will revert the change after lunch, and make sure that we don't crash if it fails.
<elopio> sergiusens: ack. I'll update my branches so they are ready to land. Most of them require an autopkgtest run though :(
<elopio> kyrofa: about that failed travis execution, the CLA fails because the email is private. Rebase with master, to no longer carry that commit.
<kyrofa> elopio, what's confusing is that there are only two commits on that PR, mine and kalikiana's
<kyrofa> I merged with master, we'll see what Travis says. I'll rebase if necessary
<sergiusens> kyrofa running the suite and unit tests in lxd should be our default :-)
<zyga-ubuntu> mvo: looking
<kyrofa> sergiusens, think so? It's a bit more of a barrier to proposing something
<zyga-ubuntu> mvo: the 2.29 version is older, subsequent changes to master version are cosmetic though
<sergiusens> kyrofa for us, not others
<zyga-ubuntu> mvo: so I'd say no, no changes needed
<kyrofa> sergiusens elopio, alright, I'll start running the autopkgtests for some of the PRs up now. I'll comment on the ones I've tested
<kyrofa> Although... elopio will it install squashfuse by any chance for the snapd tests?
<kyrofa> Otherwise it'll just fail partway through
<matiasb_> sergiusens, elopio, o/ hey, when you get a few, any chance you can take another look at facundo's MP on metadata handling? https://github.com/snapcore/snapcraft/pull/1634
<mup> PR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634>
<elopio> kyrofa yes, squashfuse should be installed for the suites that install snaps
<kyrofa> Whew, good
<elopio> matiasb: sorry for the delay. We have been stuck on autopktest for too long. I'll take another look today
<matiasb> elopio, np, just wanted to check it is in your radar, thx
<cachio> jdstrand, nice, thanks, so the denials that I shared yesterday should be fixed with this PR, right?
<jdstrand> cachio: yes
<jdstrand> cachio: I mean, I didn't test it beyond the policy compile (I just took the connected slot rule and used the unconfined label), but yeah, it should work
<cachio> jdstrand, great, tx
<zyga-ubuntu> jdstrand: still fighting the mpris bug/
<mup> PR snapd#4175 closed: dirs: use alt root when checking classic confinement support without â¦ <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4175>
<mwhudson> kyrofa, kalikiana: "lxc info remote:" is real yaml, "lxc info container" is not
<mwhudson> unfortunately it's the latter that is really needed
<mwhudson> heh heh "curl --silent --unix-socket /var/lib/lxd/unix.socket http://a/1.0/containers/complete-amoeba | jq .metadata.architecture" works for the local remote...
<jdstrand> zyga-ubuntu: I just finished
<jdstrand> cachio: fyi, I mentioned to mvo that I might have a PR for mpris. I will not. no bug in snapd (afaics)
<jdstrand> cachio: mentioning it to you since he is offline and this was potentially something extra for 2.29.3, which I know you are helping validate
 * zyga-ubuntu had fun watching https://www.youtube.com/watch?v=M6xZZiaLOV4
<kyrofa> elopio, can you explain why snapcraft seems to be running units in debug mode in adt, but not normally?
<kyrofa> (getting a failure in master due to this)
<cachio> jdstrand, perfect
<cachio> jdstrand, about the read access to /dev/mem
<cachio> how should I make to run to read in the allowed spaces
<jdstrand> cachio: otoh, I'm not sure, but I think mvo was looking into it
<elopio> kyrofa, do you mean with --debug?
<kyrofa> elopio, yeah
<jdstrand> cachio: there is something called CONFIG_STRICT_DEVMEM that is getting in the way
<jdstrand> there are ways to use it, but otoh idk
<elopio> kyrofa: sounds weird that unit tests are using debug, because they don't call the snapcraft command.
<kyrofa> elopio, I don't even now why units are run, haha
<kyrofa> Yeah something weird is happening
<kyrofa> All I see in debian/tests are integration and snaps tests
<jdstrand> mvo: hey, fyi, I won't be submitting anything for mpris. I'm done (for now)
<jdstrand> heh
<cachio> jdstrand, so, is it any way to use that interface?
<elopio> kyrofa: adt starts building the deb, and for that the unit tests are run
<kyrofa> Ah right, of course
<kyrofa> I'll look that way
<cachio> should I disable the CONFIG_STRICT_DEVMEM?
<jdstrand> cachio: that's a kernel config option
<cachio> jdstrand, so the only way is rebooting the machine
<jdstrand> cachio: there should be a way to do it (X uses it afaik), but I personally don't know the incantation required
<kyrofa> elopio, huh, is it automatically determining how to run the units?
<kyrofa> It's probably wrong, then
<kyrofa> And sets the logger level wrong
<elopio> kyrofa: setup.py defines the tests to run
<jdstrand> cachio: the kernel-module-control interface needed it for read access. that interface was written for livepatch. maybe something in there that could give a clue
<kyrofa> Oh! I've never run tests that way before
<elopio> tests that depend on logger levele should set it up. But as far as I know, nothing on adt touches that
<jdstrand> cachio: I suspect you can read it, but need to access it in a specific way. we have in the interfacec: "allow reading /dev/mem for read-only access to architecture-specific subset of the physical address (eg, PCI, space, BIOS code and data regions on x86, etc)."
<jdstrand> cachio: all Ubuntu kernels use STRICT_DEVMEM=y so you wont' be able to test write access (physical-memory-control) on Ubuntu kernels
<pedronis> mmh, I'm seeing this tests fail  linode:ubuntu-16.04-32:tests/main/xdg-open-compat:Â with apt download snapd-xdg-open=0.0.0~16.04 => E: Version '0.0.0~16.04' for 'snapd-xdg-open' was not found
<jdstrand> cachio: there might be a kernel snap somewhere that uses STRICT_DEVMEM=n, but I don't know which one. I would guess perhaps an armhf kernel, but that is only a guess
<cachio> jdstrand, ok, I'll research about it
<pedronis> mmh, it works here, strange fluke
<kyrofa> elopio, why is the ruby integration test using such an old version of ruby?
<cachio> jdstrand, I'll take a look to the armhf ones
<cachio> thanks
<jdstrand> cachio: oh, I forgot we have a test for this. here is some more context: https://wiki.ubuntu.com/Security/Features#A.2Fdev.2Fmem_protection
<jdstrand> cachio: let me get the link for the test
<cachio> jdstrand, nice
<kyrofa> elopio, well, it's not ancient I suppose. But versions < 2.4 don't seem to build with GCC7
<kyrofa> I'm gonna propose changing it unless there was a good reason we were using the old one
<elopio> kyrofa: no good reason that I can think of. But should we raise an early exception if we see gcc7 and ruby < 2.4?
<jdstrand> cachio: oh boo. the test for STRICT_DEVMEM only verifies /boot/config... is set
<kyrofa> elopio, I don't think so, might be fixed at some point
<jdstrand> cachio: so nothing to verify the kernel protection is working
<cachio> jdstrand, well the the that I did :)
<elopio> kyrofa: updating the tests works for me.
<jdstrand> cachio: Xorg might be something to look at if research doesn't help much
<kyrofa> elopio, alright. Testing once more, then I'll propose
<kyrofa> elopio, back to the autopkgtests: note that `python3 setup.py test` fails with the same error
<kyrofa> So it's using a weird logging level
 * elopio runs that
<zyga-solus> jdstrand: hmm
<zyga-solus> jdstrand: it _is_ sorted by command now :)
<zyga-solus> jdstrand: unless I missed something
<jdstrand> oh, hmm. I checked the new commits and I must've missed something
 * zyga-solus tries to pull the diff
<zyga-solus> https://github.com/snapcore/snapd/pull/4144/files#diff-641ccdace7a269ed745615226d7f4cffR111
<mup> PR #4144: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144>
<zyga-solus> here
<zyga-solus> is that what you expected?
<jdstrand> zyga-solus: I see it now
<zyga-solus> jdstrand: it's not super pretty because of that comment
<zyga-solus> and we could be smarter about how to lay out stuff
<zyga-solus> but it's a start
<zyga-solus> also because of those comments it's ordered by TAG, interface, snippet
<zyga-solus> which is at least, consistent :)
<jdstrand> that sounds great
<g4l> Hello guys! I'm try to connect to my vpn server, on a snappy ubuntu core os. using easy-openvpn.connect-server, I face this error: "ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)"
<g4l> I'm thinking about some network permissions?
<elopio> kyrofa: snapcraft.tests.test_lifecycle.ExecutionTestCase.test_dependency_recursed_correctly ?
<kyrofa> Yep
<kyrofa> g4l, if you run `snap interfaces`, are all of them connected?
<ikey> zyga-solus, got 2.29.2 built
<ikey> gonna try installing it and seeing how much i broke it
<kyrofa> Can't remember if network management is granted by default
<g4l> :firewall-control          docker,easy-openvpn
<ikey> also yay for mkversion.sh taking an argument
<kyrofa> elopio, see the ""GET /v2/snaps HTTP/1.1" 200 None" there throwing it off?
<ikey> and not causing one
<g4l> :network-control           easy-openvpn
<g4l> :home                      easy-openvpn
<g4l> I think that these 3 are enough
<kyrofa> g4l, huh, yeah those are the ones I was thinking
<kyrofa> g4l, although, did you use sudo?
<cachio> jdstrand, the good part is that the test is working in debian, fedora and opensuse
<elopio> kyrofa: seems to be affected by another test. ugh, that's hard to reproduce.
<kyrofa> elopio, argh, I hate those
<g4l> I did try. some other problems show up: "Options error: In [CMD-LINE]:1: Error opening configuration file: "
<cachio> jdstrand, it is weird, why I can ready /dev/mem from the console
<kyrofa> g4l, because adding tun/tap interfaces definitely requires sudo. For anything more snap-specific, you'll need to talk to the maintainer
<ikey>  snap run ohmygiraffe
<ikey> cannot perform operation: mount --rbind /lib/modules /tmp/snap.rootfs_qF4Snx//lib/modules: Permission denied
<ikey> pfft.
<kyrofa> elopio, it happens every time for me, three times in a row
<zyga-solus> ikey: any denials?
<zyga-solus> ikey: on which snapd?
<zyga-solus> ikey: I have _that_ snap installed and it works
<ikey> AVC apparmor="DENIED" operation="open" profile="/usr/lib64/snapd/snap-confine" name="/etc/os-release" pid=2163 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<zyga-solus> right here on solus
<zyga-solus> that's so weird, /etc/os-release is allowed by the profile
<ikey> Nov 08 21:30:37 ironhide kernel: audit: type=1400 audit(1510176637.423:37): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="/usr/lib64/snapd/snap-confine" name="/tmp/snap.rootfs_qF4Snx/lib/modules/" pid=2163 comm="snap-confine" srcname="/lib64/modules/" flags="rw, rbind"
<zyga-solus> hm
<zyga-solus> actually, it's not
<ikey> ok well that one is fairly trivial
<ikey> needs lib+lib64
<ikey> stupid solus with its weirdisms
<zyga-solus> but that's an old copy of snap-confine probably
<ikey> ?
<g4l> kyrofa, even as root, I can't make it. has no one ever try to configure this on a rpi3 ?
<ikey> im on snapd 2.29.2
<ikey> and id rebooted
<zyga-solus> ikey: you will find that /lib/modules is baked into snap-confine itself
<ikey> aye
<zyga-solus> ikey: ah, I'm still on 2.27
<ikey> oh yeah 2.27 is gloriously fine
<ikey> 2.29.2 is choking on cookies
<ikey> ima fix
<kyrofa> g4l, please file a bug, I'm afraid I don't know anything about that snap
<zyga-solus> ironically that's one of the things we could get into the new profiles now
<zyga-solus> where it could be distro-based easily from snapd side
<zyga-solus> ikey: tomorrow we do 2.29.3
<kyrofa> g4l, https://bugs.launchpad.net/snappy-hwe-snaps/+filebug from the look of it
<zyga-solus> there are a few PRs tagged for 2.29
<ikey> ok
<zyga-solus> milestoned
<zyga-solus> not tagged in git sense
<ikey>     mount options=(rw rbind) {,/usr}/lib{,32,64,x32}/modules/ -> /tmp/snap.rootfs_*{,/usr}/lib/modules/,
<ikey> surely that already covers it?
<ikey> or im being thick altogether
<ikey> why it even needs my kernel modules ive no idea
<zyga-solus> it looks good
<zyga-solus> "failed flags match"
<ikey> right
<zyga-solus> I'm too tired
<ikey> maybe somehow rw, rbind != rw rbind ?
<zyga-solus> sorry, I need to stop typing
<zyga-solus> tomorrow :)
<ikey> kk
<mup> PR snapcraft#1721 opened: integration tests: use ruby v2.4.2 <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1721>
<ikey> oo the patch isnt in 2.29.2..
<ikey> k well that makes sense then
<mup> PR snapd#4182 opened: cmd/snap-confine: Ensure snap-confine is allowed to access os-release <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4182>
<elopio> kyrofa: can you please try this patch with your autopkgtest runs? http://paste.ubuntu.com/25920819/
<mup> PR snapd#4183 opened: cmd/snap-confine: Respect biarch nature of libdirs <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4183>
<kyrofa> elopio, it's the parser test
<kyrofa> I'm not sure how yet, but it is
<ikey> turns out you guys were serious about snap-update-ns being static. :p
<ikey> tada https://plus.google.com/+Solus-Project/posts/hG14dctjrfg
<elopio> can somebody open build.snapcraft.io? I think I broke it :(
<nacc> elopio: or is it affected by the canonical maintenance?
<elopio> nacc: phew, so it wasn't me :)
<nacc> elopio: it's nnot explicitly metioed, but the store and "Ubuntu web sites" are
<nacc> *Canonical and Ubuntu
<diddledan> aha, I was just about to ask whether I broked it
<kyrofa> IRC is back, test again
<mcphail> ikey: I love that ohmygiraffe has become the de facto test of snapd :)
<ikey> lol yea
<ikey> its nice because GL + sound + xdg
#snappy 2017-11-09
<kyrofa> Man... I've spent all day commenting out tests trying to find which one is actually interfering with another. I need a drink
<ikey> built: solus-runtime-gaming_0.0.0_all.snap
<ikey> heh
<mcphail> kyrofa: https://ovh.themcphails.uk/index.php/s/LbKIquTSxMernmM
<kyrofa> mcphail, you're too kind
<mcphail> ikey: so is this the "core" snap side of things?
<ikey> right
<ikey> just gonna be cheap and dirty and use 'snap pack'
<ikey> but i think im gonna need to force some stuff like 'architectures' field, etc
<ikey> built: solus-runtime-gaming_0.0.0_amd64.snap
<ikey> bit better :p
<mcphail> This is very exciting
<ikey> certainly a learning experience for me
<ikey> i imagine the initial 0.0.0 is gonna be nasty a.f.
<ikey> but then i can start optimising it and cleaning it up
<ikey> and allow us to do builds with local overlay layers onto the image
<ikey> i.e. so we can stage mesa properly, etc
<ikey> and part of this is gonna be a cleanup process to unjank the image
<ikey> as long as i got `snap pack` command now i'm golden
<mcphail> yes, I like that way of doing things
<ikey> i strongly suspect we're gonna just rename linux-steam-integration to `LSI` and add an `lsi-exec` command, because I can think of a few games where this will help even outside steam..
<ikey> but one thing at a time :D
<mup> PR snapd#4184 opened: tests: adding new test for uhid interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4184>
<kyrofa> What does `snap pack` do that `snapcraft snap <dir>` doesn't?
<ikey> doesn't use dpkg/apt/etc
<ikey> :P
<ikey> i'm creating a base snap
<ikey> i.e. not ubuntu
<ikey> snapcraft is bricked for solus
<ikey> because its basically ubuntu specific last we looked
<kyrofa> ikey, yeah `snapcraft snap <dir>` just runs `mksquashfs` with all the magical flags. It doesn't actually do anything with the dir
<kyrofa> Although actually getting snapcraft ON there might be hard, unless classic snaps work
<ikey> classic snaps work
<ikey> classic "i think im ubuntu" not so much
<ikey> this saves me a bit of work just having the command directly there
<ikey> and yeah i saw its basically cleanup + meta + mksquashfs
<ikey> basically im just tryna be hella lazy
<mborzecki> morning everyone
<zyga-ubuntu> o/
<zyga-ubuntu> hmm
<zyga-ubuntu>     - linode:ubuntu-16.04-32:tests/main/xdg-open-compat
<zyga-ubuntu>     - linode:ubuntu-16.04-64:tests/main/xdg-open-compat
<zyga-ubuntu> I'm seeing those fail in 2.29 branches
<zyga-ubuntu> ...
<mborzecki> zyga-ubuntu: hey
<zyga-ubuntu> ho
<zyga-ubuntu> eating breakfast
<mup> PR snapd#4185 opened: interfaces/builtin/account_control: drop group filter from seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
<zyga-ubuntu> neetd to look into those failing tests
<mborzecki> yeah, noticed that sergiusens spread tests were failing because of those
<zyga-ubuntu> commented
<zyga-ubuntu> look at 4185
<mborzecki> ha, good catch, do you know if I could feed this rule to snap-seccomp locally to see if it compiles?
<zyga-ubuntu> yes
<zyga-ubuntu> I think it will compile
<zyga-ubuntu> it just needs to run to see what happens
<zyga-ubuntu> compile vs run
<mborzecki> hm there's tests/main/interfaces-account-control i'll run it to see what will happen
<zyga-ubuntu> ok
<zyga-ubuntu> morning mvo
<mvo> hey zyga-ubuntu
<zyga-ubuntu> mvo: we have a problem with one spread test, it fails very very often across many PRs (including 2.29)
<zyga-ubuntu> tests/main/xdg-open-compat
<mvo> zyga-ubuntu: ok, I have a look. do you happen to have the error at hand?
<zyga-ubuntu> no, sorry, running it now to see
<mborzecki> mvo: https://s3.amazonaws.com/archive.travis-ci.org/jobs/299323286/log.txt there's some error log here
<mvo> mborzecki: hm, <Message>Access Denied</Message> - anyway I will find one if its common :)
<mvo> 49 PRs, woah
<zyga-ubuntu> I think it's review sprint time
<zyga-ubuntu> mvo: many are approved and need 2nd review
<zyga-ubuntu> https://s3.amazonaws.com/archive.travis-ci.org/jobs/299180299/log.txt?X-Amz-Expires=30&X-Amz-Date=20171109T065333Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20171109/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=b2c9efa5b8cf4fe1b35132841d988eeaa70be47b26b4d84a68d849221c1b553d
<zyga-ubuntu> mvo: ^ failure
<zyga-ubuntu> + apt download snapd-xdg-open=0.0.0~16.04
<zyga-ubuntu> WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
<zyga-ubuntu> E: Version '0.0.0~16.04' for 'snapd-xdg-open' was not found
<zyga-ubuntu> that's it
<zyga-ubuntu> aha
<zyga-ubuntu> seems simple
<mvo> zyga-ubuntu: aha, I think that happens because snapd 2.28.5 is now in xenail-updates and we have the older version not available anymore
<mvo> zyga-ubuntu: it should fail consistently though
<zyga-ubuntu> https://packages.ubuntu.com/search?keywords=snapd-xdg-open&searchon=names&suite=all&section=all
<zyga-ubuntu> yes
<zyga-ubuntu> magic, right?
<zyga-ubuntu> maybe the non-xenial-updates version is cached on some images?
<zyga-ubuntu> (just pulling ideas out ..)
<mvo> zyga-ubuntu: thats how mborzecki name is pronounced ;)
<mvo> zyga-ubuntu: a good question, or maybe not all mirrors are up-to-date or something
<zyga-ubuntu> haha :)
<mvo> zyga-ubuntu: definitely strange
<mborzecki> close enough :)
<mvo> mborzecki: I will learn it eventually :)
<zyga-ubuntu> m-a-ch-e-y
<zyga-ubuntu> mvo: curiously I didn't hit this locally yesterday, after running spread extensively
<zyga-ubuntu> let's see if today's any different
<zyga-ubuntu> offtopic: I found this very funny to read: http://www.sciencemag.org/careers/2016/01/how-read-scientific-paper :)
<zyga-ubuntu> while I make some tea
<mvo> zyga-ubuntu: yeah, but we need to fix it for 2.29 or autopkgtest in the distro will be unahppy :(
<zyga-ubuntu> yes
<zyga-ubuntu> ha, failed now
<zyga-ubuntu> so maybe old package was garbage collected
<mvo> zyga-ubuntu: heh, this how-to-read- article reminds me of https://www.youtube.com/watch?v=ILysMhm8lXs which is about taxes but otherwise similar
<mvo> zyga-ubuntu: yes
<zyga-ubuntu> only 2.28.5 is in the archive now
 * zyga-ubuntu tries a simple fix
<mvo> zyga-ubuntu: we need to thing what to do, maybe the only thing we can do is to kill the test :(
<mvo> zyga-ubuntu: aha, cool. simple++
<zyga-ubuntu> running now
 * zyga-ubuntu looks at tea
<mborzecki> is there a way to mark it as expected failure (provided it fails consistently), like pytest.xfail or sth?
<zyga-ubuntu> nope
<zyga-ubuntu> mborzecki: sorry about my last answer, it was a mental shortcut
<mborzecki> hm?
<zyga-ubuntu> mborzecki: there's no direct way, we can echo "blah blah"; exit 0, or switch a test to manual: true to skip it
<zyga-ubuntu> mborzecki: we can also patch spread, it's github.com/snapcore/spread after all
<zyga-ubuntu> mborzecki: it's just that we traditinally tried to fix tests rather than improve the infra
<mvo> zyga-ubuntu: I wonder why we did not notice 4182 ourselfs
<zyga-ubuntu> mvo: it's curious
<zyga-ubuntu> mvo: I ran snap-confine counltess times recently
<mvo> zyga-ubuntu: does your fix for the download thing works?
<zyga-ubuntu> and it did work
<zyga-ubuntu> mvo: I made two tweaks to the policy that I haven't upstreamed yet but they are not for os-release
<mvo> zyga-ubuntu: yeah, looking at the code we should check for os-release often and yet
<zyga-ubuntu> maybe the real issue is more subtle and we're missing something?
<zyga-ubuntu>         # Allow reading the os-release file (possibly a symlink to /usr/lib).
<zyga-ubuntu>         /{etc/,usr/lib/}os-release r,
<zyga-ubuntu> this is in the profile, but for snap-update-ns
<zyga-ubuntu> not for snap-confine
<mup> PR snapd#4181 closed: interfaces/many: misc policy updates for browser-support, cups-control and network-status (2.29) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4181>
<mborzecki> i'm trying to run linode:ubuntu-core-16-64:tests/main/interfaces-account-control and got `cp: error writing '/mnt/user-data/gopath/bin/fakestore': No space left on device` :/
<zyga-ubuntu> ha
<zyga-ubuntu> mvo: it's silly
<zyga-ubuntu>  mvo: this why http://pastebin.ubuntu.com/25923441/
<zyga-ubuntu> fopen fails, no worries, return true
<zyga-ubuntu> we don't even log it
<zyga-ubuntu> it would only show up on core
<mvo> autsch
<mvo> ok
<zyga-ubuntu> and when we run on core and we treat it as classic we do the normal thing
<zyga-ubuntu> and because it's actually meant to work
<zyga-ubuntu> nothing failed
<zyga-ubuntu> we did "base snaps" on core since this code was introduced
<zyga-ubuntu> if you know what I mean by this shortcut
<zyga-ubuntu> we were treating core as classic systems, setting up separate namespaces, constricting them out of base snaps
<zyga-ubuntu> mvo: as for your earlier question, no it's still running
<zyga-ubuntu> not sure if stuck
<zyga-ubuntu> http://pastebin.ubuntu.com/25923446/
<zyga-ubuntu> (feels broken)
<mvo> zyga-ubuntu: yeah, what did you do to fix it?
<zyga-ubuntu> mvo: I just pushed fix/xdg-open-compat
<zyga-ubuntu> but it's not a real fix I think (it's not working)
<zyga-ubuntu> I just changed the version
<zyga-ubuntu> --dest=com.canonical.SafeLauncher
<zyga-ubuntu> I wonder if we are missing a service file for the legacy object path
<zyga-ubuntu> (not the one at io.snapcraft....)
<zyga-ubuntu> aha
<zyga-ubuntu> yeah, no such launcher in data/dbus
<mvo> zyga-ubuntu: yeah, that will just pull in the empty transitional package
<mup> PR snapd#4186 opened: tests: disable xdg-open-compat test <Created by mvo5> <https://github.com/snapcore/snapd/pull/4186>
<zyga-ubuntu> mvo: yeah, let's kill this test for now
<mup> PR snapd#4187 opened: tests: fix xdg-open-compat <Created by mvo5> <https://github.com/snapcore/snapd/pull/4187>
<mvo> zyga-ubuntu: I pushed also a followup which just downloads the right deb from LP - I pushed both so that we have at least one working, we need to unblock 2.29, I fear we will be starved by travis not doing tests for us
<mborzecki> i can also kill cgo'ed user lookup while fixing the groups
<mvo> zyga-ubuntu: so when we push the fix into the open PRs we need to make sure we push only to the important ones we want for 2.29
<mvo> mborzecki: \o/
<mvo> mborzecki: +1 for that
<zyga-ubuntu> mvo: +1
<zyga-ubuntu> ok, I'll re-focus on lxd issues now
<pedronis> mvo: hi, IÂ got that error (apt snap-xdg-open) also on my last PRs, it seems consistent afaict
 * pedronis breakfast
<mvo> pedronis: yes, we are fixing it as we speak
<mup> PR snapd#4160 closed: cmd/snap-confine: add slave PTYs and let devpts newinstance perform mediation (2.29) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4160>
<mvo> zyga-ubuntu: does 4146 needs further changes ? it looks like there are commits for 4144 which are not part of 4146?
<mup> PR snapd#4188 opened: osutil: replace cgo bits with non-cgo, vendered os/user  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4188>
<pedronis> mvo: what's the status of #4049, seems old but nobody ever looked at it?
<mup> PR #4049: debian,vendor: import github.com/snapcore/squashfs and use <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049>
<mvo> pedronis: its in a sad state, its not fully working and its unclear if the vendor approach is powerful enough, go get/govendor make some assumptions that are hard to workaround
<mvo> pedronis: I need to get back to it but have not managed it yet, we may need to do something simpler and abandon this (simpler as in not using govendoring but copy code/git submodule or smilar
<pedronis> mvo: #4046  has two +1  but mentions spread-cron, so not sure what to do with it
<mup> PR #4046: release: snapd 2.28.5 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4046>
<pedronis> heh sorry
<pedronis> mvo: #4043  has two +1  but mentions spread-cron, so not sure what to do with it
<mup> PR #4043: cmd/snap-confine: update valid security tag regexp <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4043>
<pedronis> oops
 * pedronis is not sure to be actually awake
<mvo> lol
 * mvo hugs pedronis 
 * mvo hands pedronis a cup of coffee as well
<pedronis> mvo: Â I meant  #4063
<mup> PR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>
<pedronis> mvo: also unsure what needs to happen with #4059
<mup> PR #4059: tests: add test that checks core reverts on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/4059>
<mvo> pedronis: I think this one can go in and needs the coresponding spread cron branch to get merged. let me do this now
<mup> PR snapd#4059 closed: tests: add test that checks core reverts on core devices <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4059>
<mvo> pedronis: uh, it did not actually have two +1 :/
<mvo> pedronis: sorry, I mixed this up with the previous one. its manual: true so no harm
<zyga-ubuntu> mvo: no, 4146 can go in as-is
<pedronis> mvo: #4129 has also two +1 , made a small comment there though
<mup> PR #4129: wrappers: do not error on incorrect Exec= lines <Created by mvo5> <https://github.com/snapcore/snapd/pull/4129>
<zyga-ubuntu> mvo: 4146 has the same fix without the extra pretty printing
<mvo> zyga-ubuntu: ok
<pedronis> mvo: #4173 has also two +1 , but not sure where you want to redo the disabling of auto-refreshes in tests
<mup> PR #4173: corecfg: validate refresh.schedule when it is applied <Created by mvo5> <https://github.com/snapcore/snapd/pull/4173>
<mvo> pedronis: I can fix that there (in a bit, need to go over the 2.29 PRs as we need a new 2.29.3 :(
<pedronis> sorry, I'm distracting you
<pedronis> mvo: otoh you should garden your old PRs a bit more (friendly nag)
<mvo> pedronis: no worries about distracting. and yes, agreed sorry for this
<pedronis> mvo: should we close #4049 for now then?
<mup> PR #4049: debian,vendor: import github.com/snapcore/squashfs and use <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049>
<mvo> pedronis: if we close we need another reminder that we need to do this work soon, it felt off the agenda once before. but yeah, in its current form it is not close to be mergable
<pedronis> mvo: I can mark it blocked if you prefer that way
<pedronis> is there no matching topic?
<mvo> pedronis: please mark it as blocked
<mvo> pedronis: no topic it seems, thats sad
<mvo> zyga-ubuntu: I have some questions for 4146, how confident are you in the changes?
<mvo> zyga-ubuntu: there are actual review questions in there too :)
<mvo> pedronis: a second review for 4146 would be great
<mvo> (or someone else, maybe pstolowski ?)
<pedronis> mvo: marked as blocked, but yes best would be to have an upcoming topic and close it if the approach is non-viable
<pedronis> mvo: #4063  has two +1 but it is failing afaict
<mup> PR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>
<mvo> pedronis: agreed, I updated the bug
<mvo> pedronis: I will look into the failure
<pstolowski> mvo, sure, gladly
<pedronis> zyga-ubuntu: IÂ looked at #4146 , seems alright, I have an unrelated (in the sense it was like that before)Â there though
<mup> PR #4146:  interfaces: fix udev tagging for hooks (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4146>
<pedronis> unrelated question
<Tribaal> Hey so whoever snapped Electrum: thanks a lot!
<Tribaal> beer++
<zyga-ubuntu> pedronis: yes?
<pedronis> zyga-ubuntu: sorry, see PR
<pedronis> now
<zyga-ubuntu> ah, ok
<zyga-ubuntu> ah, great question, let me check
<mvo> thanks for your review pedronis
<mvo> zyga-ubuntu: please don't get me wrong, I want to merge it (and like a lot of it). I'm just worried about the churn
<zyga-ubuntu> pedronis: so looking at 61a4a0e442ab329f10773098448eb931fe6c355b I'm not sure
<zyga-ubuntu> jamie patched one specific instance, not any of the generic helpers
<zyga-ubuntu> I think we need jdstrand to answer that; I don't quite know how that works
<pedronis> zyga-ubuntu: maybe something to chat with him about, anyway the code was like that before
<zyga-ubuntu> jdstrand: (and I'd love to know)
<zyga-ubuntu> yes, definitely
<pedronis> so it's not a blocker for the PR
<mvo> yay
<pedronis> #4122 needs a 2nd review
<mup> PR #4122: configstate: add support for configure-snapd for snapstate.IgnoreHookError <Created by mvo5> <https://github.com/snapcore/snapd/pull/4122>
<zyga-ubuntu> mvo, pedronis: I agree about finding a better way to work on spec objects;
<zyga-ubuntu> to explain it quickly, I wanted to stay consistent and not introduce a huge argument change patch
<mup> PR snapd#4186 closed: tests: disable xdg-open-compat test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4186>
<mvo> zyga-ubuntu: yeah, thats ok, thank you. I was not aware it was a common pattern
<mvo> zyga-ubuntu: (I still dislike it but not something for the PR in question :)
<zyga-ubuntu> mvo: yes, no disagreement there
<pedronis> zyga-ubuntu: in #4062 seems you promised a couple more comment tweaks ... also probably then mvo and pstolowski should look at it again
<mup> PR #4062: cmd/snap: warn when a snap is not from the tracking channel <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4062>
<pedronis> wrong PR
<pedronis> sorry
<pedronis> zyga-ubuntu: IÂ meant #4068
<mup> PR #4068: interfaces/builtin: add support for content "source" section <Created by zyga> <https://github.com/snapcore/snapd/pull/4068>
<zyga-ubuntu> pedronis: 4068 is not ready for landing, I'll add a "blocked" tag there, it's meant to land after most of the layout patches are ready
<pedronis> heh ok
<pedronis> #4100 needs niemeyer
<mup> PR #4100: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4100>
<pstolowski> pedronis, zyga-ubuntu I think my general comment about cleanSubPath still needs addressing, would be good to fix it with 4068
<pstolowski> unless I miss something
 * zyga-ubuntu looks
<zyga-ubuntu> interesting
<zyga-ubuntu> anyway, I'll return to that after bulk of layout code is in
<mvo> zyga-ubuntu: sorry for being annoying - did you idea about the lxd fix work out?
<zyga-ubuntu> mvo: no, not yet :/
<zyga-ubuntu> mvo: I'm writing a test that reproduces it
<zyga-ubuntu> at least will be a start for another look
<mvo> zyga-ubuntu: cool, still keen to have it for .3 if its small and targeted
<pedronis> pstolowski: there are still open questions how the APIÂ should work in #4108
<mup> PR #4108: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108>
<pstolowski> pedronis, I know, i'm getting to it, got sidetracked by the snapctl and cookie issues
<pstolowski> pedronis, can you take a look at lanes helper PR?
<pedronis> pstolowski: yes, I'm going through PRs cronologically (mostly)
<pstolowski> thanks
<pedronis> doing only reviews this morning
<zyga-ubuntu> hmm
<zyga-ubuntu> [ 1280.959106] audit: type=1400 audit(1510219691.912:133): apparmor="DENIED" operation="open" profile="snap.lxd.lxc" name="/var/lib/snapd/hostfs/usr/lib/os-release" pid=29008 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<zyga-ubuntu> (unrelated but something we probably want to fix)
<zyga-ubuntu> if anyone wants to make a quick PR for lxd interface
<mborzecki> i can take a look at it
<mborzecki> i'm going through review anyway, so might as well take a look at something else :)
<pstolowski> zyga-ubuntu, commented on #4146
<mup> PR #4146:  interfaces: fix udev tagging for hooks (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4146>
<zyga-ubuntu> pstolowski: ack on one, not sure about other
<zyga-ubuntu> I'm deep in lxd if you wnat to push small tweak there please do
<pedronis> zyga-ubuntu: do all snap-update-ns PRs need a jdstrand review ?
<zyga-ubuntu> pedronis: not all but some surely do
<zyga-ubuntu> pedronis: the one about designing the "writable mimic" is the one I need a review on
<zyga-ubuntu> pedronis: the ones about secure-mk{dir,file} do as well
<pedronis> ok, IÂ have a bunch of older/big ones to go through first though
<mup> PR snapd#4172 closed:  interfaces/kmod: simplify loadModules now that errors are ignored  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4172>
<mvo> pedronis: 4122 is good from your POV, right? just needs a second review?
<pedronis> mvo: yes, needs 2nd review
<mvo> ta
<pedronis> pstolowski: #4152 has my +1, needs a re-review by zyga-ubuntu
<mup> PR #4152: snapd: fix snap cookie bugs <Created by stolowski> <https://github.com/snapcore/snapd/pull/4152>
<Chipaca> so... we're moving exclusively to /etc/{passwd,group} for lookups?
<Chipaca> mborzecki: or were we already there and I hadn't noticed?
<pstolowski> pedronis, thanks!
<Chipaca> because if this is what we want to do, we need to refactor some code
<Chipaca> in particular the code that looks up user dirs
<Chipaca> this is relevant to my current work, so i can whip up the refactor right now
<mborzecki> Chipaca: something we discussed yesterday with niemeyer, the idea is to kill cgo code (or most of it at least)
<mborzecki> i've pulled in non-cgo pieces of os/user as osutil/user for now and put it up for the review
<Chipaca> right, but this could lead to inconsistencies, which is why i'm checking -- if this is what we want to do i need to refactor a bit of code
<Chipaca> i can do it after we merge the osutil/user pr
<mborzecki> as i understand that's the direction we want to go, zyga-ubuntu mvo ?
<zyga-ubuntu> Chipaca: I think we wanted to be cgo free and decided to kill the c-goat on the altar to attain that
<zyga-ubuntu> Chipaca: whatever you need / do I think we're not adding more cgo
<Chipaca> zyga-ubuntu: my question is: is /etc/passwd and /etc/group going to be the canonical (heh) source of users and groups on all snappy systems
<Chipaca> because that's the impact in practice
<Chipaca> we're not even looking at extrausers/groups
<zyga-ubuntu> Chipaca: no, (see extrausers)
<zyga-ubuntu> Chipaca: it's more subtle
<zyga-ubuntu> Chipaca: we're killing reasons to know
<zyga-ubuntu> Chipaca: not picking means to know
<Chipaca> zyga-ubuntu: sorry, i don't understand
<Chipaca> the code in #4188 looks up things only in /etc, no extra
<mup> PR #4188: osutil: replace cgo bits with non-cgo, vendored os/user  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4188>
<pedronis> pstolowski: about LaneTasks, IÂ said something wrong I think about lane 0 and then corrected myself but it got missed, I think lane 0 behavior is wrong, probably easy to find out with a different test
<Chipaca> from this conversation i suspect the lack of extra is oversight
<Chipaca> easily fixable
<zyga-ubuntu> Chipaca: I mean, as far as I understand it, is that we haven't said we'll use /etc/passwd exclusively (yet), more like we said for each of the reasons to lookup users/groups _so far_ we want to avoid that reason
<Chipaca> but the approach of making files the only source of users, that's policy now? (fine by me) (still needs a refactor from me)
 * zyga-ubuntu killed qemu to "refresh" kernel state
<zyga-ubuntu> man this mount business
<pedronis> zyga-ubuntu: did we discuss this changes with jdstrand btw ? he added that stuff I think
<zyga-ubuntu> fishy stuff
<Chipaca> zyga-ubuntu: in core we will be creating users and groups we will then fail to find
<zyga-ubuntu> pedronis: no,
<zyga-ubuntu> pedronis: we plan to today
<zyga-ubuntu> that was just yesterday
<pedronis> ok
<Chipaca> so I maintain that that aspect at least is a bug
<pstolowski> pedronis, ah, thanks, will fix
<Chipaca> zyga-ubuntu: your sentence about avoiding looking up things clashes with the pr we have which has a bunch of code for looking up things
<zyga-ubuntu> Chipaca: yeah, I probably miss something then
<Chipaca> you might be thinking about us not wanting to list all users
<mborzecki> Chipaca: there's a related PR #4185 where we remove group from seccom rules, if that does not fly because of security concerns, we'll probably need to look into #4188
<mup> PR #4185: interfaces/builtin/account_control: drop group filter from seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
<mup> PR #4188: osutil: replace cgo bits with non-cgo, vendored os/user  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4188>
<Chipaca> which is valid, unless we limit our users/groups to files -- then we can list them all no problem
<mborzecki> at least that that's how i undestood the discussion from yday
<Chipaca> mborzecki: doesn't 4188 make 4185 pointless?
<Chipaca> feels like we're trying to solve problems breadth-first
<mborzecki> yes, it does, but I guess we'll see where 4185 takes us
<mvo> Chipaca: sorry for coming in late, was distracted. so I think its worth checking with niemeyer if we really want to go as far as to kill off the cgo user lookup bits. we certainly do not want to add more cgo code (this is the first part of the work that mborzecki is doing). we need to check that we really do not need anything from nss on classic systems, i.e. that we don't accidentally break snapd there
<mvo> meh, all four pending 2.29 PRs have not even started yet in travis :/
<pedronis> mvo: we should not push anything to other PRs IÂ suppose :/
 * zyga-ubuntu scratches head
<Chipaca> mborzecki, mvo, niemeyer, pedronis, zyga-ubuntu: https://forum.snapcraft.io/t/system-user-lookup/2753
<mvo> pedronis: yeah
<mvo> Chipaca: thank you, reading
<zyga-ubuntu> aha
<Chipaca> gah, mis-edit
 * Chipaca fixes
<mvo> Chipaca: silly question, from looking at the code we use user.Current().HomeDir a bunch of time, if the user is on ldap (or whatnot) will this still work in the new world? if not I think we will break a bunch of users
<Chipaca> mvo: it won't work for arbitrary users, but in general you can count on the local users to also being in passwd
<Chipaca> *not always*
<Chipaca> so, no in the general case
<mup> PR snapd#4189 opened: interfaces/builtin/lxd_support: allow discovering of host's os-release <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4189>
<mvo> Chipaca: thats my concerns, in large deploys with ldap-nss or similar suddenly snaps might stop working because our env setup code fails
<Chipaca> mvo: but â¦ the general case, looking at /home is horrible also
<mvo> Chipaca: yes, I mean, I am not sure we can get around nss for those systems
<Chipaca> mvo: i agree. do we care?
<mvo> Chipaca: unless we do stuff like blindly trusting the HOME env or something
<Chipaca> that's basically the question :-)
<greyback> zyga-ubuntu: hey, would you mind having a look and see if you have anyting to suggest: https://forum.snapcraft.io/t/mir-snap-not-detecting-new-input-devices/2742
<mvo> Chipaca: right, thats the question we need to answer: is not having cgo worth breaking users on ldap-nss and similar
<Chipaca> mvo: yes. i'll add this.
<mvo> thank you
<zyga-ubuntu> greyback: I'm debugging something else now but quick question:
<greyback> zyga-ubuntu: no hurry, whatsoever, but thanks
<zyga-ubuntu> greyback: go to /sys/fs/cgroup/devices/_the_one_for_mir/ and look at devices.list
<zyga-ubuntu> please add that to the post
<zyga-ubuntu> that will help understand things a lot
<greyback> zyga-ubuntu: ack
 * zyga-ubuntu is back into insanity land 
<zyga-ubuntu> but now has a working reproducer for the bug
<zyga-ubuntu> and I think I can now test my idea
<zyga-ubuntu> greyback: I can look at this issue as soon as I'm done with lxd/14.04 issue
<zyga-ubuntu> mvo: I have a test that breaks now, I can share that and I am testing theories
<zyga-ubuntu> greyback: great,
<greyback> zyga-ubuntu: appreciated. I've learned a lot while debugging, but I expect you'll make progress much faster
<zyga-ubuntu> greyback: what is the major/minor of the input device that gets added?
<mvo> zyga-ubuntu: cool, curious to know what the test looks like
<zyga-ubuntu> mvo: ha, it's an iteration of your lxd test (thank you very very much for that)
<zyga-ubuntu> mvo: though a simpler 14.04 test will do the same
<zyga-ubuntu> still, I kept it lxd since it may be something lxd specific in the end
<mvo> zyga-ubuntu: cool, thanks
<zyga-ubuntu>  SPREAD_DEBUG_EACH=0 spread -reuse -shell-after -v qemu:ubuntu-16.04-64:tests/main/lxd-refresh-cycle
<zyga-ubuntu> code is in rfc/lxd-issue-test in my remote
<zyga-ubuntu> I'm not 100% sure qemu can survive too many -reuse cycles with this one,
<zyga-ubuntu> just FYI
<greyback> zyga-ubuntu: udevadm info -rq name /sys/dev/shar/13:69 return the correct thing: /dev/input/event5, so 13:69? Sound right?
<zyga-ubuntu> greyback: (not sure, but it's not present in that file)
<zyga-ubuntu> greyback: so this is why it doesn't work
<zyga-ubuntu> now the question that's really interesting: why :)
<greyback> zyga-ubuntu: ok. What should be updating that?
<zyga-ubuntu> greyback: it's updated by snappy-app-dev
<zyga-ubuntu> and udev rules
<zyga-ubuntu> what is the profile generated for mir ?
<zyga-ubuntu> (/etc/udev/rules.d/)
<greyback> zyga-ubuntu: http://pastebin.ubuntu.com/25924450/
<zyga-ubuntu> so KERNEL=="event[0-9]*", TAG+="snap_mir-kiosk_mir-kiosk" looks like something that ought to make this work
<zyga-ubuntu> greyback: TBH, now I don't know more
<zyga-ubuntu> greyback: look at udev events when you plug this in
<zyga-ubuntu> is it matchin?
<greyback> zyga-ubuntu: tbh I'm not sure how to tell. http://pastebin.ubuntu.com/25924507/ ??
<zyga-ubuntu> greyback: good, just add the options to show kernel and other things
<zyga-ubuntu> and annotate the log with like "idle", "inserted", "removed"
<zyga-ubuntu> so we know where's happening
<zyga-ubuntu> greyback: if you add that to the post it will help a lot
<greyback> zyga-ubuntu: just about to
<greyback> done, added to last post
<zyga-ubuntu> thank you
<zyga-ubuntu> greyback: does it work if you run the app after plugging the mouse?
<greyback> zyga-ubuntu: yes
<greyback> and after that, removal and re-insertion is working fine
<zyga-ubuntu> ok
<zyga-ubuntu> can you please edit /lib/udev/snappy-app-dev
<zyga-ubuntu> comment out the debug section
<zyga-ubuntu> and see what happens when you plug it in
<zyga-ubuntu> also add that to the post when ready
<greyback> ack
<zyga-ubuntu> http://pastebin.ubuntu.com/25924595/
<zyga-ubuntu> ha
<zyga-ubuntu> really interesting
<mup> PR snapd#4176 closed: cmd: fix re-exec bug with classic confinement for host snapd < 2.28 <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4176>
<zyga-ubuntu> mvo: I think (is) I understand it now
<zyga-ubuntu> mvo: but not ready with patch yet
<zyga-ubuntu> mvo: I'll keep you posted
<mvo> thanks for the heads up
<zyga-ubuntu> mvo: not a trivial one liner but something I may have a fix for for evaluation (kyrofa, et all)
 * zyga-ubuntu -> coffee && power
<mvo> zyga-ubuntu: if you could quickly jump into the HO channel, I want to see if the external cam I organized works well enough
<zyga-ubuntu> sure
<zyga-ubuntu> one moment
<pstolowski> do we have any (expected) travis/store hiccups today?
<zyga-ubuntu> mvo: joining
<zyga-ubuntu> pstolowski: nobody expects the unexpected issues
<pstolowski> :)
<zyga-ubuntu> ok, so I confirmed what is hanging inside lxd now (just ran a patched version), let me explore this further with some C code
<mup> PR snapd#4190 opened: cmd/snap-seccomp: do not use group 'shadow' in tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4190>
<pstolowski> mvo, +1 on 4122 with little nitpick
<mup> PR snapd#4146 closed:  interfaces: fix udev tagging for hooks (2.29) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4146>
<mup> PR snapd#4182 closed: cmd/snap-confine: Ensure snap-confine is allowed to access os-release <Created by ikeydoherty> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4182>
<mup> PR snapd#4183 closed: cmd/snap-confine: Respect biarch nature of libdirs <Created by ikeydoherty> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4183>
<zyga-ubuntu> gah, darn it
<zyga-ubuntu> in linux it's impossible to know what's really mounted :P
 * zyga-ubuntu -> thinking
<mvo> pstolowski: thanks for your review
<mup> PR snapd#4191 opened: cmd/snap-update-ns: do not assume 'nogroup' exists <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4191>
 * kalikiana croissant&coffee break
<greyback> zyga-ubuntu: I've done as you suggested, but I see no debug log file being created at all, suggesting /lib/udev/snappy-app-dev isn't ever being called
<mup> Issue snapcraft#1462 closed: update story <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1462>
<mup> PR snapcraft#1412 closed: lxd: snapcraft refresh in containers <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1412>
<kalikiana> sergiusens: thanks for merging!
<zyga-ubuntu> greyback: interesting, I'll investigate myself later
<zyga-ubuntu> mvo: I have a much much simpler solution in my head now, trying it out
<greyback> zyga-ubuntu: thank you.
<mup> PR snapcraft#1721 closed: integration tests: use ruby v2.4.2 <Created by kyrofa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1721>
<zyga-ubuntu> running now, fingers crossed
<jdstrand> mborzecki: I gave some other options, but before you change anything, please let's get consensus on the direction
<mborzecki> jdstrand: thanks for the review
<zyga-ubuntu> jdstrand: o/
<jdstrand> hey zyga-ubuntu :)
<zyga-ubuntu> jdstrand: maybe we want to have a call about that?
<zyga-ubuntu> jdstrand: btw, I found a (hopefully) super simple solution for the bane of systems without rshared /
<jdstrand> I don't think it needs a call. there is a very simple path that can be taken
<mvo> zyga-ubuntu: whats your timeline? I have a local 2.29.3 here that I would like to make push to beta
<zyga-ubuntu> jdstrand: I'll ask you to look at the diff today (fits on my screen)
<mborzecki> agreed, vwe've been there before, although I unnecessarily used group name to setup g:<name>, should have used just group ID at that point
<zyga-ubuntu> mvo: it's testing now
<zyga-ubuntu> mvo: I'll run the full suite in LXD (external) if that works
<zyga-ubuntu> mvo: let's chat in HO
<mup> PR snapd#4192 opened: osutil: add helper for obtaining group ID of given file path <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4192>
<mvo> zyga-ubuntu: sure
<zyga-ubuntu> mvo: it works :)
<zyga-ubuntu> mvo: I'll run all of main now
<zyga-ubuntu> mvo: and while that runs I'll look at running all of main in lxd
<zyga-ubuntu> mvo: do you know if we have any helpers for that?
<mvo> zyga-ubuntu: I think we don't have helpers for that :/
<mvo> zyga-ubuntu: keen to see your fix, great work!
<pstolowski> mvo, one more comment to your change ;)
<mvo> pstolowski: ta
<sergiusens> kalikiana no problem
<zyga-ubuntu> kyrofa: hey
<jdstrand> mvo: hey, not sure you got the message, but no mpris PR from me for 2.29
<zyga-ubuntu> jdstrand: https://github.com/snapcore/snapd/compare/master...zyga:rfc/lxd-issue-test?expand=1 (not fully spread-tested yet)
<mvo> jdstrand: aha, I did not get this message. thank you, one less worry
<jdstrand> yep
<Son_Goku> mvo: I'm updating the build in Fedora Rawhide to 2.29.2
<Son_Goku> so I should have an updated Provides list matching the subsystems exposed in snapd-devel
<mvo> Son_Goku: thank you, if you could merge master into your fedora PR I will pull it in
<mvo> Son_Goku: I will do a 2.29.3 today
<Son_Goku> give me a few minutes and I will have that
<mvo> Son_Goku: small issue related to classic snaps, nothing terrible but want to fix it
<Son_Goku> sure
<mvo> Son_Goku: no worries, all the time you need
<Son_Goku> and it's a nice time to fix the Fedora build
<mvo> Son_Goku: and *thank you*
<jdstrand> zyga-ubuntu: interesting. can you add a comment above sc_ensure_shared_snap_mount() describing why it needs to be shared and why mounting all the snaps as shared addresses things?
<zyga-ubuntu> jdstrand: yes, sure
<Son_Goku> mvo: https://github.com/snapcore/snapd/pull/4193
<mup> PR #4193: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/4193>
<mup> PR snapd#4155 closed: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <Closed by Conan-Kudo> <https://github.com/snapcore/snapd/pull/4155>
<mup> PR snapd#4193 opened: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/4193>
<cachio> mvo, where did you uploaded the snaps?
 * zyga-ubuntu is silly and ran 14.04 tests on 3.14 kernel
<zyga-ubuntu> I need to fix my image
<Son_Goku> mvo, do you plan to make 2.29.3 right after merging my spec changes in?
 * Son_Goku is trying to weigh whether to submit a build for 2.29.2 at all
<Son_Goku> I'm thinking I shouldn't if you're going to make a 2.29.3 release before I have to leave for work
<mvo> Son_Goku: 2.29.3 will go out today, waiting for one more branch still
<mvo> cachio: I pushed them to the store you should have mail from the store. i only build locally so far
<Son_Goku> mvo: anyway, you should pull those spec changes in and merge it back into 2.29
<popey> jdstrand:  Whats the process if an upstream wants a snap name and it's the same name as the same app in the deb archive? They get it, right?
<Son_Goku> this is also now adjusted for the new tarball scheme
<mvo> cachio: one easy way to get it build for everything is to push just the snaps to a LP branch and setup snap building for that branch and auto-store upload. that should work as you are the "owner" of the snaps now
<mvo> Son_Goku: yeah, once tests are green I will merge
<popey> jdstrand: i.e. they ask on the forum, we grant it, they upload, and the path means users get the snap in preference to the deb?
<Son_Goku> mvo: the tests seem to be red for unrelated reasons :/
<jdstrand> popey: iirc, there needs to be a store override. noise][ could comment (I don't typically handle name registration questions)
<Son_Goku> that happened with the other spec change
<popey> oh, sorry.
<cachio> mvo, I don't see those snaps in the store
<mvo> greyback, zyga-ubuntu if its a cgroup problem, could you uncomment the debug lines in /lib/udev/snappy-app-dev ? maybe that gives us a hint
<cachio> I mvo I just got the email
<mvo> cachio: hm, could you /msg me your primary SSO address? maybe that is the problem, in the past the store only send the invite to that
<jdstrand> popey: as for snap in preference to the deb: no. /snap/bin is after /usr/bin in PATH
<mvo> cachio: aha, ok. woah, I added the snaps hours ago :)
<greyback> mvo: zyga-ubuntu suggests I do that, but I saw no log file being created at all
<greyback> -s+ed
<mvo> Son_Goku: yeah, tests are red, please merge master
<diddledan> popey: I believe the store has marked all the names of debs in the ubuntu repo as reserved so you need to file a claim using the request name form when you try to register the snap
<mvo> greyback: autsch, thats bad
<popey> yeah, thats the problem
<jdstrand> those don't work
<popey> someone tried to register and never got a reply
<mvo> Son_Goku: I wanted to do that and push to your branch but it looks like you disabled that I can push to your PRs ;)
<cachio> mvo, a rule remove that email from my inbox
<popey> I'm trying to smooth it out.
<mvo> cachio: aha, ok.
<cachio> mvo, sorry
<jdstrand> mvo, greyback: those debug lines don't work iirc
<Son_Goku> mvo: gimme a sec to rebase
<mvo> cachio: no problem
<Son_Goku> I thought I had already done it this morning
<mvo> jdstrand: they worked at some point, if they no longer do we should remove them :(
<mvo> Son_Goku: thank you
<Son_Goku> mvo: done
<jdstrand> mvo: yes and yes
<mvo> jdstrand: and YES :)
<jdstrand> mvo: YES!!
<jdstrand> :)
 * mvo hugs jdstrand 
<noise][> popey: i don't see any outstanding name dispute requests
<noise][> what name?
<popey> htmldoc
<popey> I'm mailing the dev and will cc you
<jdstrand> mvo, greyback: istr an issue with reexec or it being in the readonly squashfs and not being able to have the system recognize the overlay
<popey> they added numbers to the name to get it, but say they got no response, but I don't know when / where they asked
 * jdstrand will sometimes use overlayfs to test things on a core image
<noise][> i see an htmldoc19 approved
<noise][> that's the only one
<popey> yeah, he did that because he said he got no reply for htmldoc
<noise][> hmm
<popey> will get clarification over email
<popey> You Have Mail! </aol>
<mvo> popey: lol
<jdstrand> mvo, greyback: I think(?) it might be possible to cp it somewhere, adjust that to output to a file (eg 'echo $@ > /var/tmp/foo'), then overlayfs that (maybe a bind mount would do?), then stop and start udev
<jdstrand> zyga-ubuntu: I guess you are looking at this. fyi ^
<greyback> jdstrand: yeah I thought it best to let an expert have a go :)
<greyback> though I'd still exect those debug lines to create the log file on a Classic system
<pedronis> Chipaca: did a pass over #4154
<mup> PR #4154: overlord/snapstate: support completion for command aliases <Created by chipaca> <https://github.com/snapcore/snapd/pull/4154>
<zyga-ubuntu> jdstrand: I plan to next
<zyga-ubuntu> jdstrand: still looking at the rshare issue, some initial enthusiasm is receeding
<jdstrand> zyga-ubuntu: why don't you let me look at greyback's issue
<jdstrand> I was planning on reaching out today anyway
<zyga-ubuntu> jdstrand: go ahead, I don't block you
<jdstrand> greyback, mvo: ^
<jdstrand> I'll be looking at this
<greyback> jdstrand: if I can help at all, let me know
<mvo> jdstrand: ta
<jdstrand> greyback: is it possible to reproduce in a vm? eg, sub hotplug a moue via virsh or something?
<jdstrand> man
<jdstrand> that was some mighty poor typing
<jdstrand> usb hotplug a mouse via virsh*
<zyga-ubuntu> jdstrand: at some point the acronyms take over english and it's all ok
<jdstrand> haha
<mup> PR snapd#4194 opened: daemon: for /v2/logs, 404 when no services are found <Created by chipaca> <https://github.com/snapcore/snapd/pull/4194>
<Chipaca> mvo: ^
<greyback> jdstrand: mir should work fine inside a vms yes
<greyback> jdstrand: I don't know how to simulate mouse plug/unplug to a vm though
<jdstrand> greyback: I'll play with it a little. I have a physical device I can try too though
<greyback> jdstrand: yeah I tend to use a separate machine when working on mir
 * jdstrand has wanted to document debugging this part of snapd anyway
<jdstrand> (the udev hotplug)
 * mvo hugs Chipaca 
<zyga-ubuntu> jdstrand: there's a way to do that
<mvo> Chipaca: thank you!
<zyga-ubuntu> jdstrand: using the qemu monitor
<jdstrand> zyga-ubuntu: yeah. I just need to recall how to do it :)
<zyga-ubuntu> jdstrand: I wrote some python that could help but not something you can spread test easily (AFAIK) without nested spread
<jdstrand> that's fine
<zyga-ubuntu> https://en.wikibooks.org/wiki/QEMU/Monitor#usb_add
<jdstrand> oh bummer, my core vm is hosed
 * jdstrand creates a new one
<mvo> Chipaca: lets hope travis builds it reasonable soon
<zyga-ubuntu> jdstrand: -snapshot to the rescue
<elopio> snappy-m-o echo test
<Chipaca> mvo: dumb fix for dumb bug :-)
<jdstrand> zyga-ubuntu: well, that is the problem. I did -snapshot and it was broken
<zyga-ubuntu> that's interesting, so it wrote back?
<jdstrand> no idea. I've already destroyed it and will have a new one in a moment
<Chipaca> mborzecki: what was your usecase of group lookup? was it "who is the owner of /etc/shadow"?
<jdstrand> Chipaca: it was to know what to use with 'g:<group>'. but we already have the gid with stat so no point finding the group name to then lookup the gid
<Chipaca> heh
<Chipaca> jdstrand: nice
<Chipaca> so that's all going away?
 * ikey had no idea that snaps were held together with silly string and environmental variables..
<jdstrand> Chipaca: his PR doesn't get rid of lookupGroup, no. lookupGroup *could* go away if the template.go was similarly updated, but I would argue to keep it for when we need it, but use my alternative suggestion of shelling out
<jdstrand> (see my comments in the PR)
<Chipaca> will do
<Chipaca> this is relevant to some work coming out of the standup
<Chipaca> but right now, i need to go regruntle a chid
<jdstrand> Chipaca: a faster alternative since we don't have it today would be to update template.go as I mentioned in the PR, remove all cgo code related to this, keep FindGid() but have it return an err that points to my PR comment. that way whoever needs it next would know how to proceed. since that would likely be me, I'm ok with implementing my design
<Son_Goku> ikey: you finally figured it out
<jdstrand> s/don't have it today/don't need it today/
<zyga-ubuntu> ikey: environment variables and tongue at the right angle
<ikey> so, amusing fact
<ikey> my solus based snap refuses to accept the nvidia GL libraries in /var/lib/snapd/gl
<ikey> or w/e the path is
<ikey> because it sets secure execution mode as the binaries + libs are mostly all full relro and ignores LD_LIBRARY_PATH
<ikey> ergo, solus snap binaries are more secure in nature than ubuntu ones :p
<elopio> snappy-m-o echo test
<snappy-m-o> test
<ikey> im gonna need to work around it with ld.so.conf
 * zyga-ubuntu is sleepy now
<zyga-ubuntu> damn it
<zyga-ubuntu> I hate that sun is over at 16:00
<zyga-ubuntu> :/
<zyga-ubuntu> ok, you win
<zyga-ubuntu> I'll get some coffee
<zyga-ubuntu> darn sun
<kalikiana> ikey: what do you mean by "solus based" here? built on solus or running on solus?
<ikey> both
<ikey> the snap has `base: solus-runtime-gaming`
<ikey> and solus-runtime-gaming has `type: base`
<zyga-ubuntu> kalikiana: the rootfs is solus
<zyga-ubuntu> kalikiana: (at runtime)
<zyga-ubuntu> kalikiana: base snaps :)
<ikey> i found some assumptions that i had to cater for in the rootfs
<ikey> and it really doesn't like lib64
<ikey> i think the most surprising one was the expectation for /lib/udev/snappy-app-dev to be present
<zyga-ubuntu> ikey: that's correct, we need to make more things configurable in base snap's layout section
<zyga-ubuntu> ikey: we can correct those as we go, thank you for pushing the boundaries
<ikey> ah my pleasure :D
<zyga-ubuntu> ikey: much of what I do now relates to that
<ikey> right now my script is an abomination
<zyga-ubuntu> ikey: but you are ahead of the curve :)
<ikey> https://github.com/solus-project/runtime-snaps/blob/master/round1.sh
<ikey> but you can kinda get a feel for whats going on easily enough
<kalikiana> ikey: oooohhhh sweet
<ikey> i mean its kinda nasty but it does the job, right?
<ikey> and the main yaml is here https://github.com/solus-project/runtime-snaps/blob/master/runtimes/gaming/meta/snap.yaml
<ikey> i added a debug apps: part to it to let me poke it
<ikey> so now my next test is to see if i can prefix ld.so.conf so that the SNAP_LIBRARY_PATH portions would be respected
<ikey> as right now my poor snap is using mesa
<jdstrand> greyback (cc zyga-ubuntu): fyi, virsh qemu-monitor-command snappy-16-amd64 '{"execute":"device_add","arguments":{"driver":"virtio-mouse-pci","id":"input1","bus":"pci.0","addr":"0xa"}}'
<jdstrand> greyback (cc zyga-ubuntu): virsh qemu-monitor-command snappy-16-amd64 '{"execute":"device_del","arguments":{"id":"input1"}}'
<zyga-ubuntu> jdstrand: oh, you are using the qemu qpi interface
<zyga-ubuntu> jdstrand: nice, does it work?
<jdstrand> yep
<greyback> jdstrand: sweet
<zyga-ubuntu> i mean, does snapd part work?
<jdstrand> udevadm monitor shows them coming and going
<jdstrand> the udev tagging works too (it is getting assigned to mir-kiosk)
<jdstrand> the adding to the cgroup is not working
<jdstrand> I'm looking into that
<jdstrand> E: TAGS=:snap_mir-kiosk_mir-kiosk:
<zyga-ubuntu> jdstrand: ha
<zyga-ubuntu> jdstrand: same result as what the reporter found
<jdstrand> yes. that's a good thing :)
<jdstrand> I have reproduced it
 * greyback sighs with relief
<zyga-ubuntu> jdstrand: as a side note
<zyga-ubuntu> jdstrand: that script is -e, right?
<jdstrand> it is
<zyga-ubuntu> jdstrand: just sayin :)
<zyga-ubuntu> jdstrand: we should burn that script with fire
<zyga-ubuntu> jdstrand: and write it in C
<jdstrand> it is on our trello board
<jdstrand> we hate the shell script
<zyga-ubuntu> that sounds like a line from a song
<ikey> We didn't start the shell script....
<ikey> It was always churning from before snapd was turning..
 * ikey sees himself out
<jdstrand> hehe
 * popey shuts the door
<zyga-ubuntu> ah
<zyga-ubuntu> it was "we love the pain"
<zyga-ubuntu> but I somehow translated that to "we have the shell script"
<ikey> popey, just turn around now
<kalikiana> ikey: kinda wonder if that couldn't be baked into --shell... so you don't have to add those awkward "apps"
<ikey> >_>
<ikey> kalikiana, *prolly* but the apps shouldn't really be in the runtime
<ikey> it was there for le debugging
<ikey> once i have the higher layer working properly ill remove it
<kalikiana> ikey: right, it's more that you need to add something solely for debugging
<kalikiana> that strikes me as awkward
<ikey> yeah spose
<kalikiana> just thinking out loud
<ikey> tbh it was mostly "can i chroot"
<ikey> then later i had fun due to not using dash in the image
 * zyga-ubuntu now wants to listen to "we love the pain"
<ikey> turns out readline + ncurses, pretty important.. lol
<ikey> confinement wouldn't let em load ^^
<ikey> oh, le Q
<zyga-ubuntu> https://www.youtube.com/watch?v=jkXP-aqKmPQ ^_^
<ikey> my snap can't seem to execute stuff from /usr/bin
<ikey> despite the runtime having zenity there
<ikey> i mean sure its janky to have zenity there
<ikey> but still
<ikey> curious why it can't execute stuff
<zyga-ubuntu> ikey: what's the error?
<ikey> ehm it was permission denied
<zyga-ubuntu> ikey: typically you get the answer from audit log
<ikey> ill need to rebuild me whatchacallits
<ikey> my snaps and install and find out what their issue is
<zyga-ubuntu> jdstrand: not sure if you were trying to tell me politely "explain how it works so that you will see it doesn't" or was that just an accident but I think I need another (much more annoying) solution
<zyga-ubuntu> annoying as in complex
 * mvo is unhappy because the travis run for 4194 has not even started yet
<zyga-ubuntu> mvo: :/
 * zyga-ubuntu has a very crazy idea on how to fix the problem affecting lxd
<mvo> zyga-ubuntu: tell me more
<zyga-ubuntu> mvo: it goes away if we move snap mounts to /var/lib/snapd/snap and then have an unconditional mount unit that bind mounts /var/lib/snapd/snap to /snap
<zyga-ubuntu> mvo: then /snap is a real mount unit with correct options
<zyga-ubuntu> mvo: and the hack goes away
<zyga-ubuntu> mvo: as for fixing this in snap-confine: we could keep the hack we had but we need to unmount everything first
<zyga-ubuntu> mvo: then create the bind mount (/snap -> /snap)
<zyga-ubuntu> mvo: and then re-mount all the mount units
<zyga-ubuntu> mvo: (re-start them, we cannot mount ourselves as we don't know what was there)
<zyga-ubuntu> mvo: (then there's confinement that will make this more complex)
<ikey> im seeeing lots of spam for NSS modules in my snap: https://hastebin.com/cumofisodi.sql
<ikey> but nothing that could explain why this is still refusing to use my NVIDIA libraries
<ikey> for zenity execution:
<ikey> Nov 09 16:01:48 ironhide audit[11528]: AVC apparmor="DENIED" operation="exec" profile="snap.linux-steam-integration.settings" name="/usr/bin/zenity" pid=11528 comm="sh" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
<ikey> is there some kind of plug i need to add so i can actually execute stuff from my runtime?
<ikey> otherwise it gets a bit pointless having a runtime..
<mvo> zyga-ubuntu: hm, interessting
<pedronis> interesting is the word
<nacc> ikey: it *might* help to run `snap run --shell <app>` and try to run it by hand?
<mvo> zyga-ubuntu: and funny in some way as this would be fhs compliant by "accident"
<mvo> pedronis: lol
<nacc> ikey: dunno if you'd get more logging, or be able to see what precisely is failing
<ikey> can't see /usr/bin
<nacc> ikey: confined snap?
<ikey> yeah
<ikey> ok i can see some of /usr/bin..
<ikey> bash: /usr/bin/file: Permission denied
<nacc> ikey: well ... it should't be able to see /usr/bin; not sure if hte apparmor logging is showing you the confined view or not (i'm not deep enough into snappy to know)
<ikey> basically i cannot execute anything from /usr/bin
<nacc> ikey:  a confined snap should be able to use the core snap it's running on and the snap's contents only, I think?
<pedronis> zyga-ubuntu: will that not confuse snapd vs snap-confine? are all the relevant ops done with the snap-confine lock?
<ikey> right, and zenity is in my core snap
<ikey> but /bin works..
<ikey> /usr/bin doesn't
<ikey> curious.
<nacc> ikey: that's weird :/
<ikey> i.e /bin/ls is fine
<nacc> ikey: sounds like you need an actual snap developer, sorry :)
<ikey> heh
<ikey> but i can't ls /bin
<zyga-ubuntu> pedronis: this would be done at system level, before we get to run;; but honestly this is lala land for now;
<ikey> -_-
<ikey> this is jank of the highest order lol
<zyga-ubuntu> pedronis: I'd like to find easier solution
<pedronis> zyga-ubuntu: hope so, both of those don't sound very appealing
<nacc> ikey: so you can read but not execute?
<pedronis> at first sight
<ikey> i can read /usr/bin, not execute, execute /bin, not read dir
<ikey> ok so symlinks seem to work ok if its symlinked into /bin
<ikey> workarounds intensify
<nacc> ikey: to be clear it's possible `ls /bin` and `/bin/ls /bin` are different
<nacc> ikey: but this sounds like AA madness :)
<ikey> yeah
<ikey> ima test a theory.
<ikey> symlink the runtime
<ikey> at this point i really wish snaps were implemented using overlayfs
<ikey> and not having mangled /snap/* trees and LD_LIBRARY_PATH hacks
<kyrofa> zyga-ubuntu, hey there! I'm around now
<ikey> could have a core snap mounted as a lowerdir, a tmpfs mounted as an intermediary with snapd requirements on top (such as gl overrides), and then a new overlayfs using that tmpfs as a bottom dir
<ikey> and the compounded Thingy would have a natural filesystem layout
<ikey> and no need for the butchered scripts anymore
<zyga-ubuntu> kyrofa: I had a up/down cycle today
<zyga-ubuntu> kyrofa: fixing that bug all day
<kyrofa> zyga-ubuntu, hahaha
<kyrofa> zyga-ubuntu, did it end with success?
<mup> PR snapd#4195 opened: daemon: for /v2/logs, 404 when no services are found (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4195>
<zyga-ubuntu> kyrofa: yes, I didn't jump off a cliff ;)
<mvo> can someone review 4195 please? it's 4194 for 2.29
<zyga-ubuntu> kyrofa: no, not fixed yet, mostly understood now but still trying to fix it
<zyga-ubuntu> mvo: I cna
<ikey> bash: /bin/zenity: Permission denied
<ikey> *gah*
<mvo> zyga-ubuntu: ta!
<zyga-ubuntu> mvo: man, â, I always find that confusing "All or Every it was?"
<zyga-ubuntu> mvo: :)
<ikey> apparmor is a pain in the ass. just sayin.
<zyga-ubuntu> ikey: you should try selinux
<zyga-ubuntu> ikey: then you'll say "man, remember that pain in the ass, haha, that was just tingling"
<ikey> at that point id fork smack and bring it up to scratch again
<ikey> for the love of christ why can it still not run stuff
<zyga-ubuntu> ikey: you can recompile the policy
<zyga-ubuntu> ikey: and make it permissive
<zyga-ubuntu> ikey: then you can just do stuff until you get proper logging to see the denials
<ikey> ugh
<ikey> i found out why
<ikey> interfaces/apparmor/template.go
<nacc> ikey: i wonder if it's acustom core snap (iirc?) then maybe you need to do apparmor modifications?
<ikey> hard-coded permitted commands?
<ikey> cmon guys
<niemeyer> Chipaca: ping
<zyga-ubuntu> ikey: yes, because then we cannot change the base snaps otherwise
<zyga-ubuntu> ikey: if we allow anything then everything is backwards compatible stone that is by your leg
<ikey> i cant even ldconfig -_-
<ikey> this also means i cant do an update to an icon theme asset in the secondary snap
<ikey> because the gtk-update-icon-cache is inside the core runtime
<ikey> and i cant execute commands there
<zyga-ubuntu> ikey: I think base snaps should have a base apparmor template
<zyga-ubuntu> ikey: it's just something we haven't done yet
<Chipaca> niemeyer: pong
<niemeyer> Chipaca: Yo
<Chipaca> niemeyer: 'sup
<niemeyer> Chipaca: Looking at the fixes for /v2/logs
<niemeyer> Chipaca: Got me thinking about our old issues with 404s on valid endpoints
<niemeyer> Chipaca: Do we have a pattern already established of returning 404s in similar cases?
<Chipaca> niemeyer: /v2/logs?names=rubbish 404s
<ikey> can i have all the magical chroot esque functionality of strict snaps **without** the apparmor denials?
<ikey> like some magic "i dont want this" flag? :P
<kyrofa> zyga-ubuntu, glad to hear it :)
<jdstrand> ikey: what specifically are you trying to do. launch zenity from your snap?
<ikey> ya, but have zenity in my base snap
<ikey> and apparmor denials make it impossible to have my useful executables there
<ikey> sorta defeating the point of "runtime" :p
 * jdstrand notes that base snaps are a very new thing and the security policy needs to be designed for it
<nacc> ikey: i think that's what i was tryign to say earlier --^
<Chipaca> niemeyer: /v2/snaps/rubbish 404s
<Chipaca> etc
<Chipaca> niemeyer: 404 isn't "this is not a valid endpoint"
<jdstrand> like, should each base snap have it's own policy? should base snaps extend existing policy?
 * ikey will make magic workarounds
<ikey> and stick zenity into the secondary snap
<nacc> jdstrand: really good questions :)
<niemeyer> Chipaca: I guess it's a bit late to be changing that in this case, but we should at least try to consider further similar cases
<jdstrand> ikey: now, for zenity in particular, perhaps it makes sense to add it to the desktop or desktop-legacy interface
<ikey> also gotta wonder what the SDK/debug story is for base runtimes
<niemeyer> Chipaca: I guess in our case it's a bit less of a problem as we are indeed returning a richer value despite the status code
<ikey> jdstrand, tbf i shouldn't be copping out and using zenity in the first place
<ikey> but there it is ^^
<ikey> i should have been less lazy and used a real GtkDialog
<niemeyer> Chipaca: But I've learned to be afraid of that exact behavior after recurring bugs
<ikey> ** (zenity:26283): WARNING **: Could not load ui file /usr/share/zenity/zenity.ui: Failed to open file ?/usr/share/zenity/zenity.ui?: No such file or directory
<ikey> ah for feck sake
<Chipaca> niemeyer: nice json 404 in appserver resulting in nasty plain text 404 from load balancer?
 * ikey punches a baby donkey
<jdstrand> ikey: that's a good question. I don't know tbh. I think the idea is get the concept out there and see how people are using them and design the next steps
 * jdstrand hasn't been part of most base snap discussions
<niemeyer> Chipaca: Problem is that there's little difference between a real response, and a broken configuration with a wrong path, or a broken configuration with a wrong endpoint altogether, or even a broken configuration talking to a proxy that is getting in the way
<ikey> jdstrand, it'd be a whole lot easier if we could rely on real usable system paths
<ikey> and not mangle every single package..
<ikey> wonder if i can cheat here and install zenity twice.
<Chipaca> ikey: https://i.imgur.com/5jysoQE.jpg
<ikey> ls: cannot open directory '/usr/share/locale': Permission denied
<ikey> *gah!!*
<niemeyer> Chipaca: Also, clients getting 404s for different reasons out of the same endpoint (missing snap, or missing service, or missing ...)
<niemeyer> Chipaca: We even got one of those cases in our buying endpoint ("Please login" when really it was "This stuff is free dude!")
<Chipaca> niemeyer: yeah; in our case it's an error response, so it's not _just_ a 404, but yes, agreed
<ikey> ok new objective, make snap work, then make strict confinement work later.
<ikey> less stress
<mup> PR snapd#4168 closed: cmd/snap-update-ns: add new helpers for mount entries <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4168>
<ikey> heh now i can run zenity xD
<mup> PR snapd#4196 opened: daemon: cherry-picked /v2/logs fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/4196>
<Chipaca> ^ cherry-picking the v2/logs fixes for 2.29, plz
 * ikey still has that one cute donkey jpeg open
<ikey> i couldn't punch that
<ikey> https://ibin.co/3gibO7Bha09C.png :D
<Chipaca> ikey: https://i.imgur.com/6G3FTUC.jpg
<popey> diddledan: apologies for the mail store spam
<ikey> ok that one looks like it already took a slap
<ikey> libGL error: unable to load driver: swrast_dri.so
<ikey> libGL error: failed to load driver: swrast
<diddledan> :-)
<ikey> ok so the last thing to work out now is how to expose the NVIDIA
 * diddledan clicks on ALL the links! :-p
<ikey> but yeah i have steam trying to install itself now
<ikey> from within the solus runtime
<ikey> i think jdstrand is right about custom apparmor profiles <in future>
<ikey> because the solus base is gonna be wildly different (lib32s and such)
<ikey> but - ignoring confinement for now, the concept is working.
<Chipaca> diddledan: https://gfycat.com/QuickWaterloggedAmurminnow
<popey> awwwwww
<popey> if i filmed that my cat would run up and devour the little birdie
<diddledan> tasty
<ikey> nomnom :p
<pedronis> Chipaca: mvo: do IÂ see it correctly that #4196 supersedes #4195
<mup> PR #4196: daemon: cherry-picked /v2/logs fixes (2.29) <Created by chipaca> <https://github.com/snapcore/snapd/pull/4196>
<mup> PR #4195: daemon: for /v2/logs, 404 when no services are found (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4195>
<ikey> so how do you guys make the magical /var/lib/snapd/lib/gl thingy work?
<ikey> if anyone knows the innards on it
 * ikey is curious if the fact libGL already exists in the root is the issue
<ikey> wait maybe thats it
<ikey> its in the place its meant to be!
<ikey> *duh*
<ikey> (if i had brains id be dangerous.)
 * zyga-ubuntu does one more try
<zyga-ubuntu> (proably won't work but due to typos or others, let's see)
<zyga-ubuntu> mvo: mount based solution
<zyga-ubuntu> mvo: not as crazy
<zyga-ubuntu> mvo: as in mount unit based
 * ikey is suddenly more fond of mad environmental variables and sillystring
<zyga-ubuntu> ikey: what happened?
<ikey> zyga-ubuntu, well i figured i can *abuse* the linker
<ikey> its looking for /usr/lib/libGL* and finds them
<ikey> so why not nuke them
<ikey> and abuse LD_LIBRARY_PATH to *force* it to lookup even for mesa
<ikey> and i think thats more similar to what your snaps do already actually..
<ikey> mesa/mesa-default
<diddledan> ikey: abuse is never the right solution. Please seek counciling for your abbarant behaviour :-p
<ikey> xD
<ikey> 7fd36217d000-7fd36218e000 r-xp 00000000 103:03 8133128                   /var/lib/snapd/hostfs/usr/lib64/glx-provider/nvidia/libEGL.so.384.98
<ikey> omg
<ikey> :3
<ikey> its using the nvidias
<diddledan> oops
<ikey> no thats good
<ikey> im on nvidia
<ikey> before it was stuck on mesa drivers
<zyga-ubuntu> AEVA - anonymous environment variable abusers
<ikey> XD
<diddledan> sounds like a political movement
<ikey> omg so close
<ikey> i need to teach snapd about 32-bit drivers
<ikey> https://ibin.co/3gijqdorLIW2.png
<ikey> ^_^
<zyga-ubuntu>  mmm
<zyga-ubuntu> just install those them drivers
<ikey> i have them host side
<ikey> i need to teach snapd to expose them
<ikey> needs 32-bit *and* 64-bit exposed
<zyga-ubuntu> them verygenuinedriversforeverything.ru/themdrivers.exe
 * zyga-ubuntu is in funky mode
<ikey> lol
<zyga-ubuntu> .txt.exe (or something)
<diddledan> that url doesn't work
<diddledan> (yes I clicked it :-p)
<mup> PR snapd#4197 opened: cmd/snap-confine: Support bash as base runtime entry <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4197>
<ikey> ah crap we'd need a secondary directory
<ikey> maybe /var/lib/snapd/lib/gl/32 ?
<zyga-ubuntu> why for snap-confine?
<zyga-ubuntu> I don't get it
<ikey> ?
<ikey> mount-support-nvidia.c
<zyga-ubuntu> huh
<ikey> it only copies 64-bit drivers
<zyga-ubuntu> I mean
<zyga-ubuntu> why did you change the apparmor profile for snap-confine
<zyga-ubuntu> it doesn't run bash, does it?
<ikey> it does if you run --shell
<ikey> and both of my entry points are bash based
<ikey> we don't use dash in solus
<ikey> so our /bin/sh == /bin/bash
<ikey> and any "system" style calls will also use /bin/sh
<zyga-ubuntu> no, wait, it doesn't
<zyga-ubuntu> it runs snap-exec which does that
<Chipaca> has travis had a breakfast of snails today?
<zyga-ubuntu> Chipaca: travis is on holidays
<zyga-ubuntu> trying to tell us stuff
<ikey> well i had apparmor denials for it yesterday anyway
<ikey> and bash was broken
<zyga-ubuntu> ikey: --shell runs under the confinement of the app
<zyga-ubuntu> ikey: were they for snap-confine profile?
<zyga-ubuntu> ikey: ah, maybe it is (jdstrand: maybe) snappy-app-dev
<ikey> i cant remember this was yesterday, but without that patch stuff wouldn't work
<zyga-ubuntu> which is written in shell
<zyga-ubuntu> sadly I think you are right
<ikey> this was before i'd even gotten my LSI snap made
<zyga-ubuntu> jdstrand: if I rewrite that into C will you review it?
<ikey> just the core stuff
<ikey> i can't see where we create /var/lib/snapd/lib/gl
<zyga-ubuntu> it's baked into packaging
<zyga-ubuntu> I need a break
<zyga-ubuntu> I just have to leave this place
<zyga-ubuntu> (tests are running)
<Chipaca> mvo: i suspect we both cherry-picked for 2.29 Â¯\_(ã)_/Â¯
<zyga-ubuntu> I'll go for a walk now
<zyga-ubuntu> I'll be back later to see if the tests pass
<Chipaca> EOD is nigh
<Chipaca> o/
<cachio> mvo, hey, is it comming 2.29.3 today?
<diddledan> I heard 2.29.3 was for Monday, but that might be the stable release rather than candidate or such
<mvo> cachio: it is coming, it a bit slow though, we had one more PR that needs to go in
<mvo> cachio: I'm looking at the status right now
 * kalikiana edo'ing as well now
<cachio> mvo, good, tx
<mup> PR snapd#4195 closed: daemon: for /v2/logs, 404 when no services are found (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4195>
<mup> PR snapd#4196 closed: daemon: cherry-picked /v2/logs fixes (2.29) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4196>
<mvo> cachio: 2.29.3 is now uploaded to the image ppa, build there is running so should be build in ~10min and then I trigger a core snap build
<mvo> cachio: so total turnaround hopefully ~1h and we have a new beta
<cachio> mvo, nice
<cachio> mvo, tx
<pedronis> niemeyer: btw, IÂ don't know if you noticed among all the things but there are 2 or 3 open PRs that have you specifically requested as reviewer
<mvo> cachio: i386/amd64 ready in beta
<cachio> mvo, nice, starting now :)
<diddledan> that was quick
<mvo> cachio: armhf ready now too
<mup> PR snapd#4198 opened: release: 2.29.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4198>
 * elopio <- lunch + nap. I'll be back in 2 hours.
<mvo> cachio: and arm64 as well, go wild!
<cachio> mvo, great, thanks, I'll have results by tomorrow
<mvo> cachio: could you also please notify CE about this so that they can run their tests? iirc the automatic tests are run by a US timezone team, right?
<cachio> mvo, sure, doing that
<mvo> cachio: so with a bit of luck we might get results tonight
<mvo> cachio: thank you!
<mvo> cachio: eh, I mean results today(ish)
<cachio> mvo, yes, in few hours I'll see the first set of results
<cachio> and complete the suites during the night
<cachio> mvo, tomorrow morning you should see 80% of the results updated
<Pharaoh_Atem> mvo: you didn't merge the spec changes into 2.29.3?
<Pharaoh_Atem> mvo: :'(
<Pharaoh_Atem> I had it ready this morning so that you could do it
<Pharaoh_Atem> it's even got the green checkmarks :/
<mvo> cachio: thanks
<mvo> Pharaoh_Atem: so sorry! I can do a special .4 just for you with this in
<mvo> Pharaoh_Atem: there was a bit of turmoil because of two other last minute PRs, apologies again
<Pharaoh_Atem> mvo: please do, thanks
<Pharaoh_Atem> I'd like to get everything properly in sync
<mup> PR snapd#4193 closed: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4193>
<Pharaoh_Atem> especially since there were build changes this time around
<mvo> Pharaoh_Atem: its in the release/2.29 branch now, I will do the formal GH release in my morning that includes your updates
<Pharaoh_Atem> excellent
<Pharaoh_Atem> but 2.29.4 was tagged now?
<Pharaoh_Atem> I just need the regular tag for Fedora builds ;)
<mup> PR snapd#4194 closed: daemon: for /v2/logs, 404 when no services are found <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4194>
<Pharaoh_Atem> the special tarballs are needed only for my prototype EL7 builds
<mvo> Pharaoh_Atem: oh, I can give you 2.29.3.1 as a tag
<Pharaoh_Atem> that works too
<Pharaoh_Atem> I just need a release to work from
<Pharaoh_Atem> though I suppose I can work from 2.29.3 as-is
<Pharaoh_Atem> I just wanted to make sure that it was in the branch and in master
<mvo> Pharaoh_Atem: ok, its there now
<Pharaoh_Atem> excellent
<mvo> Pharaoh_Atem: gtg, but I will read scrollback
 * mvo waves
<Pharaoh_Atem> bye
<mup> PR snapcraft#1722 opened: unit tests: reset log level after test <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1722>
 * zyga-ubuntu fights the mount issue a little more
<sergiusens> snappy-m-o autopkgtest 1657 xenial:amd64
<snappy-m-o> sergiusens: I've just triggered your test.
<sergiusens> elopio mind addressing the comment in snapcraft#1633 ?
<mup> PR snapcraft#1633:  recording: record information from the image in container builds  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1633>
<sergiusens> at least the one about the use of `format` in the unit test?
<mariogrip> jdstrand: ping
<jdstrand> mariogrip: hey
<elopio> sergiusens on it
<mariogrip> how do i make a file executable with snapcraft, now the the apps command does not seem to get +x
<mariogrip> using the plugin sump
<mariogrip> dump*
<sergiusens> kyrofa were you manually running snapcraft#1717 ?
<mup> PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717>
<sergiusens> adt for it that is
<kyrofa> sergiusens, wanted to, ran into breakage :D
<kyrofa> sergiusens, fixed in snapcraft#1722 which is running now
<mup> PR snapcraft#1722: unit tests: reset log level after test <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1722>
<sergiusens> mariogrip is the tar not tarred up correctly? You can tell it too with the `install` script in the part
<jdstrand> mariogrip: I'm not a snapcraft expert, which is why I mentioned you come here (so others could help). the dump plugin should keep the exec bit set. I've certainly used it
<sergiusens> jdstrand unless it isn't exec at all in the first place
<sergiusens> or a strange umask is in place
<mariogrip> It is +x in the zip file
<elopio> sergiusens: didn't we agree on squashing our own pull requests? I like more the squash and merge button, but I thought I was following the new rules.
<sergiusens> kyrofa are you running them merged together locally?
<kyrofa> sergiusens, no, heck I'm just making sure master passes at this point
<kyrofa> sergiusens, it doesn't, I already see more errors
<sergiusens> elopio at one point, but then over a month ago we said we wouldn't do that anymore as there was little point as the hash was rewritten anyways
<kyrofa> sergiusens, elopio is there a reason our tests keep going even though we know they're errored out?
<sergiusens> kyrofa maybe a PEBKAC ?
<kyrofa> Should we fail fast?
<kyrofa> sergiusens, never!
<sergiusens> kyrofa we want all the errors, to fix them all (we assume tests are independent for this to work)
<sergiusens> kyrofa what errors do you see now?
<kyrofa> sergiusens, no idea, just ERROR and I assume I'll see a summary at the end
<kyrofa> sergiusens, I know if I cancel I won't see them
<kyrofa> Which seems like a waste of time
<mariogrip> ok if i extract it first to a folder and told snapcraft to use that it worked (without modifying any chmod's)
<kyrofa> sergiusens, errors look like build-snap related, I wonder if it's a squashfuse issue
<sergiusens> kyrofa how long do they tak locally?
<kyrofa> sergiusens, unknown, I haven't had a success yet
<sergiusens> mariogrip are you up for a bug fixing opportunity ? :-)
<sergiusens> kyrofa you can tell the system to error out quickly before running
<kyrofa> Yeah I'm changing it now
<sergiusens> elopio also snapcraft#1530 ... given the use of ros more aggressively now, we could take advantage of the caching as kyrofa mentions, but let's limit it to the ros class
<mup> PR snapcraft#1530: tests: share the cache dir in the integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1530>
<kyrofa> sergiusens, worried about side-effects?
<kyrofa> Seems like a sensible first step
<mariogrip> jdstrand: think i found my adb problem, no cluse what has changed, but now i get symbol __mmap error, also since we haven't updated the snap in a while, not sure what has changed to make this error
<sergiusens> kyrofa worried about doing it for no benefits and then yes, missing out on catching a bug just because we were lazy to think about what we are trying to solve :-)
<kyrofa> Makes sense
<mariogrip> sergiusens: sure
<kyrofa> So maybe a "SaveCacheTest" base class of some sort
<sergiusens> kyrofa it should be a mixin if that is the case, but it also doesn't need to much thinking, just applied to the test class defined for ROS and done
<sergiusens> I will be back later tonight and save my phone from tethering for a bit (isp blackout for the past 6 hours)
<kyrofa> Well there isn't a common base class for ROS right now, so something will need to be written one way or another. But yeah
<elopio> kyrofa: I feel that we wait a long time for the runners to be assigned, so running as much as possible when we have it sounded good. But that has obvious down sides, I wouldn't mind trying failfast.
<mariogrip> jdstrand: I can try switching to a the adb version that comes with ubuntu (right now we use never directly from google)
<kyrofa> elopio, I think that's probably the right call for the real deal. It's a pain running locally, but adding -f everywhere isn't hard
<kyrofa> Maybe we can bake a nicer solution in the script, but nothing to worry about now
<jdstrand> mariogrip: huh, interesting. maybe that is the difference between devmode (which would use libc, etc from the core snap) and classic which would use whatever is on your system
<mariogrip> base snap is xenial right?
<jdstrand> mariogrip: if it helps, the core snap is built from 16.04, so if you are building/etc, build on 16.04 so everything matches up
<mariogrip> yeah, using xenial and classic works there
<jdstrand> fyi, we still are using the core snap as the implied base snap. that will soon change (just clarifying our different terminology)
<jdstrand> mariogrip: could be a missing stage package. note, I'm kinda guessing here-- sergiusens, kyrofa, et al will be able to help more if you get stuck getting it to work in devmode
<jdstrand> mariogrip: once we get to tryingto get it to work in strict mode, I will be able to help more :)
<mariogrip> tried with this (older adb version) that seems to work https://github.com/ubports/android-tools
<ikey> what would you guys say to supporting /var/lib/snapd/lib/gl/32 for biarch nvidia driver support?
<jdstrand> mariogrip: I'm going to eod, but feel free to post questions here or in the forum (we all read backscroll and forum posts)
<mariogrip> jdstrand: Ok, Thanks for you help :)
<jdstrand> mariogrip: glad https://github.com/ubports/android-tools works for you, that'll be a good start. good luck! :)
<mariogrip> sergiusens: found a fix for the zip not preserving permission problem, pr coming up
<sergiusens> mariogrip thanks
 * ikey has a local patch for the 32 thing fwiw
<sergiusens> ikey is there a reason not to support it?
<ikey> i dont think so
<sergiusens> great :-)
<sergiusens> mariogrip jdstrand about the missing symbol, smells like building on 17.04 or greater
<sergiusens> as you suggest jdstrand
<sergiusens> mariogrip you want to wait for our "building with libraries from the future" task to get completed
<mariogrip> the binaries are from google, no clue what they are built on
<sergiusens> where building, is not really building but dumping
<sergiusens> if you build all your deps, it should work
<sergiusens> which is really the only supported way we have for classic until we finish of the daunting task of elf patching ;-)
<mariogrip> can do that :) but this is an crossplatform application so we wanted to use same adb for all the os
<sergiusens> mariogrip it would be the same adb once it is in the snap
<mariogrip> for linux yes
<sergiusens> mariogrip wait, google has a cross-os build of adb?
<mariogrip> but i wont get started on even building windows adb
<mariogrip> well they provide for all the os, but it's the same adb version
<sergiusens> oh, they certainly provide sources, right?
<sergiusens> anyways, you can also wait for that other work
<sergiusens> unless you go strict/devmode, then you do not need to wait
<mariogrip> i guess it's easier to just use the version https://github.com/ubports/android-tools then start importing the android source to get hold of the adb source
<sergiusens> kyrofa I've been thinking, no need to really run adt; just create a container of a different release to 16.04 and run the snap as we do on travis
<sergiusens> or are you doing another arch?
<kyrofa> sergiusens, right now I'm just doing xenial:amd64 so I can make sure it actually works, then I can start running other releases. Even if I did the snaps tests, we need adt to pass, right?
<mariogrip> sergiusens: https://github.com/snapcore/snapcraft/pull/1723
<mup> PR snapcraft#1723: Workaround for ZipFile.extractall not preserving permission <Created by mariogrip> <https://github.com/snapcore/snapcraft/pull/1723>
<mup> PR snapcraft#1723 opened: Workaround for ZipFile.extractall not preserving permission <Created by mariogrip> <https://github.com/snapcore/snapcraft/pull/1723>
<elopio> kyrofa: so, my patch didn't solve your adt log errors?
<kyrofa> elopio, wait, which patch?
<kyrofa> Huh, -f isn't failing fast, either
<kyrofa> This definitely has something to do with build-snaps, though
<elopio> kyrofa: http://paste.ubuntu.com/25920819/
<elopio> sorry, I misunderstood your next ping as an ack.
<kyrofa> elopio, wait, what is this? I'm so lost now :P
<kyrofa> Oh, we don't use runtests.sh in adt, nice
<elopio> kyrofa: we are sooo out of sync :)
<kyrofa> elopio, no kidding :D
<elopio> kyrofa: is your test failing because it prints some extra v2/snaps GET ?
<kyrofa> elopio, no, I fixed that in snapcraft#1722
<mup> PR snapcraft#1722: unit tests: reset log level after test <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1722>
<kyrofa> elopio, you fixed it another way, eh? Hahaha
<elopio> kyrofa: yes, I'm reviewing that PR and not liking your solution.
<elopio> :)
<kyrofa> elopio, meanie. Well YOUR solution doesn't make any sense!
<kyrofa> elopio, why would that only cause issues occasionally?
<elopio> kyrofa: about that, I'm not sure. There's a nuke option on the fake logger, that maybe is combining with a few other things that are wrong on the way we use the log.
<kyrofa> Hahaha
<elopio> so, my fix makes the fake snapd server to not print to stdout. All the other fakes print to debug, but it wasn't using the common base class.
<elopio> my guess is that sometimes it prints to stdout, and that is collected by the following test.
<elopio> no wait, it always prints to stdout and that sometimes is collected by the following test.
<kyrofa> elopio, hmm.... that ALSO sounds like a problem
<kyrofa> But a different one
<elopio> that's why I was wondering if the patch fixed the problem for you. Because I no longer get those spurious GETs printed, and my adt unit tests are all green.
<kyrofa> elopio, I didn't even see the patch, I must have missed your ping
<elopio> now the real problem to me is that most of our tests shouldn't be checking the log. But that will take a long time to fix.
<kyrofa> Yeah
<elopio> I'm not -1 on your branch. It's just that it's not a reset. If it works, I'm ok landing it. Anyway we'll need to improve that soon.
<kyrofa> It's not a reset?
<kyrofa> How is it not a reset?
<kyrofa> It always sets it to whatever is default at the end of each test
<elopio> kyrofa: most of our tests never call log.configure. Only the ones that excercise the cli module.
<kyrofa> elopio, right, the issue seems to be that the logging level sticks around and effects other tests
<elopio> so for the tests that have nothing to do with that configure, you are calling it at the end of the test, which is weird.
<elopio> kyrofa: and that about the logging level sticking is what I don't understand. The fixture does this: https://github.com/testing-cabal/fixtures/blob/master/fixtures/_fixtures/logger.py#L54
<elopio> so, summary, there are many things wrong. I will propose my patch, because I think all the fake servers should do the same. I think that will have the side effect of fixing the issue for you too.
<elopio> I could +1 your branch if you still like it, because calling log.configure always will not affect anything. Or at least, it's clearly not more wrong than all the wrong things that are happening around :)
<kyrofa> elopio, yeah fair enough, propose your branch, I'll +1 if it fixes it, and we can close mine
<elopio> kyrofa: I would also like to see if the nuke option solves the problem, it could be a good safeguard.
<kyrofa> Yeah that's an interesting-sounding option
<mup> PR snapcraft#1724 opened: tests: use the common base handler on the fake snapd server <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1724>
 * ikey is uploading a video..
<ikey> https://plus.google.com/+Solus-Project/posts/cTzfduUHht8
<kyrofa> Atta boy ikey!
<ikey> :D
<mup> PR snapcraft#1725 opened: tests: share the cache in ros tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1725>
#snappy 2017-11-10
<mup> PR snapd#4199 opened: cmd/snap-confine: Add support for 32-bit NVIDIA on biarch <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4199>
<kyrofa> elopio,  are you suuuuure that adt installs squashfuse?
<kyrofa> Because it doesn't look like it is. Can you point me to where it should be doing that?
<kyrofa> elopio, it's not in debian/tests/control, for example
<sergiusens> kyrofa that's done on run_lxd_container.sh
<mup> PR snapcraft#1726 opened: schema: sources should not have defaults <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1726>
<ikey> got my .snap files uploaded to my server for testing, buuuut
<ikey> it does require the snapd patches ive put in today
<ikey> and also requires --devmode --dangerous..
<elopio> kyrofa: you are right, it is not installed, I see it failing on my WIP branch.
<elopio> you can add --setup-commands
<mup> PR snapd#4200 opened: Return snap-not-installed error in more cases <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4200>
<mup> Bug #1659106 changed: snap refresh/enable/disable doesn't return snap-not-installed error, returns generic 400 instead <snapd:Fix Committed> <https://launchpad.net/bugs/1659106>
<mup> PR snapcraft#1724 closed: tests: use the common base handler on the fake snapd server <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1724>
<mborzecki> morning guys
<mvo> hey mborzecki, good morning
<mborzecki> mvo: o/
<mborzecki> did you hear back from lenovo?
<mvo> mborzecki: my machine needs to be send in, will take ~5-7 days or so
<mvo> mborzecki: until then I'm with my crufty old t400
<mvo> (and my desktop which is decently powerful)
<mvo> mborzecki: but funny (or not) enough my desktop does not boot this morning, just hangs in the bios which is rather unfortunate. the physical world is a pain :/
<mborzecki> hahah
<mborzecki> is your desktop one of the ryzen builds?
<mborzecki> hmm,2017-11-09 15:44:32 Failed project prepare: 1
<mborzecki>     - linode:fedora-25-64:project
<mvo> mborzecki: the desktop is a whitebox that I built from custom parts, but its not very fancy
<mvo> mborzecki: meh, fedora failed? what in particular? its often a bit unstable in itself, or maybe -25 is eol finally and we need to bump it
<mborzecki> /home/gopath/src/github.com/snapcore/snapd/tests/lib/boot.sh: line 14: fw_printenv: command not found
<mborzecki> this sounds like a u-boot command
<mvo> mborzecki: yes, that is strange that it would use that on a regular machine
<mborzecki> hm found nother one that failed like this
<mborzecki> `if command -v grub-editenv >/dev/null; then` this line failed on fedora
<mborzecki> maybe we're missing some bit in fedora cloud image
<ikey> is there any reason why inside my snap a .so file might appear to be a directory when shared from home..?
<ikey> this seems .. slightly bizarre.
<mborzecki> ikey: probably a question for zyga-solus, my bet is on some bind mount logic that got it wrong
<ikey> ty
<ikey> ok this time its not a directory..
<ikey> last time it was
<ikey> o_O
<mborzecki> heisenbug
<ikey> lol
<mborzecki> mvo: hm there's no grub-editenv in fedora, it's named grub2-editenv there
<niemeyer> Early hellos
<mborzecki> niemeyer: hi, isn't that like a midnight at your place?
<niemeyer> mborzecki: Almost 5am.. crashed a bit earlier yesterday
<niemeyer> pedronis: About the open PRs, yeah, I really need to get into reviews.. will send up the board shortly
<mvo> niemeyer: woah, good morning
<ikey> ok it wasnt a snap issue incidentally
<ikey> its a weird feral thing
<mvo> mborzecki: hm, wonder why the fedora machine suddenly starts failing, but maybe just an update
<niemeyer> mvo: Moin!
<zyga-solus> ikey: what did you do?
<ikey> oh i didnt
<ikey> so the game has "bin/libpdf.so" and "lib/libpdf.so"
<ikey> and "bin/libpdf.so" is actually a directory
<ikey> confused the hell out of me
<ikey> and the linker was like "nope i dont even"
<mborzecki> mvo: so there's a commit from Simon Fels done in may, that adds a workaround for grub2-editenv for fedora/suse in lib/prepare.sh
<mborzecki> then, the offending lines in boot.sh were last touched in 2016
<mborzecki> i'll try to fix this
<mup> PR snapd#4201 opened: tests/lib: handle distro specific grub-editenv naming <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4201>
<mborzecki> mvo: l got to take care of something so I'll be afk for ~2h, opened an early PR ^^ to see if this will fix the problem
<mvo> mborzecki: thank you
<mborzecki> ok, talk to you later
 * zyga-solus -> quick late breakfast
<zyga-solus> sorry, kids were very stubborn today and were late for school
<ikey> oh, breakfast
<ikey> not a bad idea
 * zyga-solus eats what kids left behind ^_^
<ikey> :D
 * mvo shakes fist at nvidia driver, its in a gdm3 restart loop rightnow
<niemeyer> https://forum.snapcraft.io/t/review-sprint-4/2765
<zyga-solus> mvo: wrong driver
<zyga-solus> mvo: did you install it just now or update?
<zyga-solus> niemeyer: thank you!
<niemeyer> zyga-solus: np, that part was easy :P
<mvo> zyga-solus: happend out of the blue which is very strange
<mvo> zyga-solus: when I started this morning
<zyga-solus> mvo: woah
<zyga-solus> can you ssh into the machine?
<zyga-solus> syslog has the details of why x cannot start
<zyga-solus> for me it had something like "bla bla bla, use legacy driver, bla bla bla"
<mvo> zyga-solus: yeah, it just says "nvidai: cannot load module", no worries, I will figure it out, its just super annoying
<zyga-solus> I haven't seen that one
<mvo> zyga-solus: google is very light on it as well
<mvo> zyga-solus: going back to nvidia-340 "fixed" it
<zyga-solus> mvo: from 37x?
<mvo> from 384
<zyga-solus> mvo: woah, 2.29.3 has plenty of things that are not in master
<mvo> zyga-solus: yes
<mvo> zyga-solus: its very annoying, we need to fix this
<zyga-solus> I see I will have some merges to do in the full udev hooks branch
<mvo> zyga-solus: should apply cleanly, no?
<zyga-solus> mvo: not really, I did extra changes after jdstrand's desire to change formatting of udev rules
<zyga-solus> mvo: mostly just annoying stuff in tests (extra comments and order changes)
<mvo> zyga-solus: but all on top of the exiting commits?
<zyga-solus> but that's ok
<zyga-solus> ay
<zyga-solus> yes
<zyga-solus> that should merge cleanly!
<zyga-solus> I didn't think about that
<mvo> yeah, fingers crossed :)
<zyga-solus> I wonder why is travis so red today
<mvo> 50 open PRs, sounds like work today
<zyga-solus> mvo: hmmm
<zyga-solus> mvo: 2.29.3 has failing unit tests
<mvo> zyga-solus: there was a grub-editenv issue on fedora that ma looked into earlier
<mvo> zyga-solus: wuut?
<zyga-solus> mvo: looks real :/
<zyga-solus> mvo: https://s3.amazonaws.com/archive.travis-ci.org/jobs/299817751/log.txt?X-Amz-Expires=30&X-Amz-Date=20171110T075518Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20171110/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=7dd8a954e140304cfb8fce57b546497414a8a6a4488ec760644b075ff5e54d23
<zyga-solus> mvo: no idea how
<mvo> zyga-solus: hm, that build in the ppa so it can't be universal
<zyga-solus> mvo: maybe ungreen PR was merged into 2.29
 * mvo looks
<mvo> zyga-solus: https://travis-ci.org/snapcore/snapd/branches show 2.29.3.1 is green and beside fedora packaging its identical
 * mvo looks deeper
<zyga-solus> very confusing then
<zyga-solus> mvo: let's see if I can reproduce
<zyga-solus> mvo: yep
<zyga-solus> real failure
<zyga-solus> looking at which part is right
<mvo> zyga-solus: can you pastebin it please?
<zyga-solus> sure
<zyga-solus> http://pastebin.ubuntu.com/25930345/
<mvo> zyga-solus: strange, just trying to reproduce (via git checkout upstream/release/2.29) it is ok for me, let me dig deeper
<zyga-solus> yep
<zyga-solus> looks genuinely buggy
<zyga-solus> test is right, code is wrong
 * zyga-solus wonders
<zyga-solus> maybe misaligned something
<zyga-solus> I didn't do that
<zyga-solus> I did mvo/release-2.29.3
<zyga-solus> I recall those usb interface number PRs were recent
<zyga-solus> maybe cross-merged badly
<mvo> zyga-solus: oh, indeed
<mvo> zyga-solus: that is probably it
<zyga-solus> gah
<mvo> there I see it as well
<zyga-solus> ikey: I plugged a 2nd monitor to my solus box and now the "dock" at the bottom overlaps windows
 * mvo recovers from a brief heart attack
<zyga-solus> ikey: is this a feature I'm not aware of
<zyga-solus> mvo: wait, so what is in 2.29.3?
<zyga-solus> mvo: because this is _pre_ merge
<zyga-solus> mvo: (heart attack may need to come back)
<zyga-solus> mvo: and this is not right for sure
<ikey> zyga-solus, mutter borkified all sane notions of reserved struts :(
<zyga-solus> mvo: I pushed a patch to that PR
<zyga-solus> mvo: please look
<mvo> zyga-solus: I just looked at https://github.com/snapcore/snapd/blob/release/2.29/interfaces/builtin/serial_port_test.go and the snippet4 is missing there, i.e. we don't test this condition
<zyga-solus> mvo: but I'm worried how is this possible
<zyga-solus> mvo: aha
 * ikey agrees with the C udev thingy fwiw
<zyga-solus> mvo: can you look if the 2.29 release has the other usb-interface-num patches?
<zyga-solus> is that a feature in this release?
<mvo> zyga-solus: so it looks like this was added in your PR for master later and not backported to 2.29 - does that mean that theere is also a fix missing?
<zyga-solus> mvo: I don't recall adding that, it may have come from master
<mvo> zyga-solus: aha, it looks like 2.29 does not have the usb-interface-num, at least I can't find it in there
<zyga-solus> mvo: let me look at the history to find this patch
<zyga-solus> mvo: I see it in b2991126738db2e9bf041a5da014cadc436e5ae2
<zyga-solus> mvo: which is not in release/2.29
<mvo> zyga-solus: I did a "git grep usb-interface-n" in the release/2.29 tree and nothing there so it looks like we are good
<mvo> zyga-solus: all good then :)
<zyga-solus> mvo: but how is it in 2.29.3 PR?
<zyga-solus> mvo: if you released from that branch it's going to be bogus and will fail adt
<mvo> zyga-solus: its 2.29.3 plus master (to fix the conflicts, i.e. to make it mergable into master)
<zyga-solus> ahhh
<mvo> zyga-solus: the release/2.29 branch does not contain this snippet, its a new test that was added in master but now fails with the udev snippet work for 2.29
<zyga-solus> ok
<zyga-solus> all good
<mvo> yes
<zyga-solus> uff
<mvo> exactly
 * ikey ponders how he'd go about stracing a process inside of a snap..
<zyga-solus> ha
<zyga-solus> we need to add snap run --strace
<zyga-solus> it's a common request
<zyga-solus> it's not super easy unfortunately
<ikey> didn't you have some magical super invocation?
 * ikey searches forum
<zyga-solus> no, because it requires doing a few steps
<zyga-solus> the profile of the app has to change to allow that
<ikey> ah yep ive pissed it off
<ikey> ok yeah need to exclude pselect6 too
<zyga-solus> oh, nice, autopkgtests are gone now
<zyga-solus> mvo: do we have a way to trigger them manually?
<mvo> zyga-solus: sort of, cachio is looking into it
<zyga-solus> great
<mup> PR snapd#4187 closed: tests: fix xdg-open-compat <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4187>
<mup> PR snapd#4180 closed: interfaces/many: misc policy updates for browser-support, cups-control and network-status <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4180>
<ikey> anyone got experience with running chrome/cef stuff under snap?
<ikey> if i install with --classic - cef works (i.e. feral games like Hitman)
<ikey> yet if i use --devmode, it doesn't
<ikey> get execvp errors with empty argv[0]
<zyga-solus> ikey: no, sorry
<zyga-solus> what is cef?
<ikey> like chrome-based apps
<zyga-solus> aha
<ikey> spotify and such
<ikey> all have a libcef.so
<ikey> relevant strace portion https://hastebin.com/raw/refijimafu
 * mborzecki is back
 * ikey can't help but notice the EPERM
<mup> PR snapd#4157 closed: add spread test for connecting all interfaces (excepting gadget slots) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4157>
<zyga-ubuntu> mvo: thank you for merging that test, I will merge master into the big udev branch now
 * ikey checks 4180 on the magical off chance it fixes the issue
<Chipaca> mborzecki: morning sir. What is, in your view, the plan for group lookup?
<pedronis> niemeyer: hi and ack
<pedronis> hellp
<pedronis> *hello
<mvo> hey pedronis and Chipaca - good morning
<mvo> zyga-ubuntu: your udev PR looks fine, once tests are green it can go in I think
<niemeyer> pedronis: yo
<pedronis> mvo: IÂ though pstolowski requested some test tweaks for it in the 2.29 variant
<pedronis> *I thought
<pstolowski> for which PR?
<mup> PR snapd#3994 closed: tests: fix revert test when a new core image is pushed <Created by sergiocazzolato> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3994>
<mborzecki> Chipaca: i'm not strongly biased against cgo (I suppose that's the real root of the problem), and with #4185 we have a fine chance of avoiding group lookups in the code that ends up in `snapd` binary
<mup> PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
<Chipaca> mvo: good morning sir
<mborzecki> at this point what's left with cgo is snap-seccomp, and probably some tests, though I have some PRs open that try to workaround this
<pstolowski> ah, udev pr
<Chipaca> mborzecki: i think cgo is only a potential problem in snapd, which is long-lived; the others shouldn't be as concerned
<Chipaca> mborzecki: so 4188 goes away?
<Chipaca> #4188
<mup> PR #4188: osutil: replace cgo bits with non-cgo, vendored os/user  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4188>
<mborzecki> i'd leave it open for now, and once the bits i needed are merged i'll close it
<mborzecki> Chipaca: does that sound ok to you?
<Chipaca> mborzecki: i'm not sure what the purpose of leaving it open is if we're not going to merge it, but i don't mind too much
<pedronis> pstolowski: yes, I put a link to them in the non-2.29 one
<Chipaca> beyond being in review sprint mode (ie reviews before code)
<Chipaca> mvo: what's up with #4122? two +1's and not merged. Just waiting for green?
<mup> PR #4122: configstate: add support for configure-snapd for snapstate.IgnoreHookError <Created by mvo5> <https://github.com/snapcore/snapd/pull/4122>
<mborzecki> Chipaca: fair point, let's close it for now then, we can always reopen it if needed
<pstolowski> pedronis, thanks
<Chipaca> mborzecki: if i were to remove all uses of os/user and SnapDataHomeGlob in favour of a new thing, what would you need from the new thing?
<niemeyer> Chipaca, mborzecki: Avoiding cgo in snap-seccomp is probably impossible with the current design
<niemeyer> Ah, sorry, not seccomp
<niemeyer> snap-update-ns
<mup> PR snapd#4188 closed: osutil: replace cgo bits with non-cgo, vendored os/user  <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4188>
<niemeyer> Chipaca, mborzecki: Ah, and snap-seccomp too, for different reasons (libseccomp)
<Chipaca> niemeyer: good morning to you too :-) have you even slept?
<niemeyer> Chipaca: Sorry, good morning :)
<Chipaca> niemeyer: ah, i didn't mean it in that way, but it works :-D
<niemeyer> Chipaca: Yeah, I have.. went to bed earlier than usual yesterday, so started earlier today still, and will probably stop earlier too :)
<mborzecki> Chipaca: i only needed looking up a group name using its gid, but we have a workaround for this now
<Chipaca> niemeyer: fair enough
<niemeyer> Chipaca: Still wondering about the cgo issue..
<Chipaca> niemeyer: pedronis has flagged you for some reviews i see, so you've got your work cut out :-)
<niemeyer> Chipaca: Yeah, we've got the review board too, not sure if you've seen the message earlier today
<niemeyer> Chipaca, mborzecki: As for cgo, I'm on the fence between suggesting dropping and making that interaction more awkward vs. the benefits
<niemeyer> We cannot drop glibc completely from the snapd environment due to the external tools we need
<niemeyer> So the sole benefit would be a more bullet proof snapd
<zyga-ubuntu> niemeyer: yet :)
<zyga-ubuntu> niemeyer: the apparmor_parser thing could run in a tiny tiny tiny base snap
<niemeyer> zyga-ubuntu: Without further information that's a bit of wishful thinking
<Chipaca> niemeyer: going down the review board is how i saw you flagged in some
<zyga-ubuntu> niemeyer: yeah, just saying it's not ultimately impossible
<niemeyer> zyga-ubuntu: Yeah, but we're not able to do that any time soon
<zyga-ubuntu> agreed
<Chipaca> we need glibc in the core snap anyway because otherwise we'd have to link systemd against musl or something equally undersupported by upstream systemd
<Chipaca> so from that pov i don't see the benefit
<niemeyer> Chipaca: That's a bit of a different thing
<Chipaca> ok :-)
<niemeyer> Chipaca: systemd will be in the base
<Chipaca> niemeyer: uh, no?
<Chipaca> how?
<niemeyer> Chipaca: uh, hopefully yes? :)
<Chipaca> niemeyer: so you can't have more than one base?
<Chipaca> or there is a base that's special and different?
<niemeyer> Chipaca: Consider this: which systemd is used when the host system is Ubuntu 16.04
<Chipaca> niemeyer: not the one in the base
<niemeyer> Chipaca: Not the one in any snap
<Chipaca> quite
<niemeyer> Chipaca: Right.. so this is not actually a fundamental dependency of the snapd-carrying nsap
<niemeyer> snap
<Chipaca> niemeyer: consider this: what systemd starts snapd in core?
<niemeyer> Chipaca: The one in the base ;)
<Chipaca> niemeyer: which base?
<Chipaca> in a special base that's baser than the rest?
<mvo> the base of the snapd snap
<niemeyer> Chipaca: Exactly.. I'm describing the goal
<Chipaca> the snapd snap will have a base?
<Chipaca> so we force solus to have a ubuntu 16 base even if none of their snaps use ubuntu 16?
<niemeyer> Chipaca, mvo: We can have a specific base snap that is the one mounted as the root filesystem on core devices
<Chipaca> ah
<Chipaca> no i got it
<Chipaca> ok
<mvo> Chipaca: yeah, maybe not, probably more something implicit
<Chipaca> so snapd doesn't have a base, but ubuntu core is a special base
<Chipaca> fedora core would be a different special base
<Chipaca> solus core would just be ikey, punching donkeys
<niemeyer> Chipaca: It might have a base, but it might not be the one that Ubuntu Core requires
<niemeyer> Chipaca: Not having a base might make the model simpler, though.. so this particular bit is one we still need to decide on
<niemeyer> The status quo of base snaps is that we did not yet do the split of core
 * mvo nods
<Chipaca> yep
<niemeyer> This is the second part, and it's independent of support for bases in app snaps
<Chipaca> 's fine, i think we've discussed this "some bases can be root of core some can't" before and i forgot it
<niemeyer> So we haven't yet firmly made such decisions, and we also haven't closed any of those doors yet
<niemeyer> Chipaca: Yeah, and np, the conversation is healthy
<zyga-ubuntu> mvo: hmm
<zyga-ubuntu> â snap-repair.timer not-found failed failed snap-repair.timer
<zyga-ubuntu> mvo: this is from vanilla 16.04 install
<zyga-ubuntu> we're shipping the repair timer?
<zyga-ubuntu> ah, sorry, zesty
<zyga-ubuntu> /lib/systemd/system/snapd.snap-repair.service
<zyga-ubuntu> /lib/systemd/system/snapd.snap-repair.timer
<zyga-ubuntu> it seems we are
<zyga-ubuntu> mvo: is this really desirable?
<mvo> zyga-ubuntu: it is disabled, no?
<zyga-ubuntu> it's failed
<zyga-ubuntu> not disabled
<mvo> zyga-ubuntu: it makes packaging simpler, it has a condition
<Chipaca> zyga-ubuntu: systemctl status snap-repair.timer ?
<Chipaca> mvo: if you make it an assertion instead of a condition it works the same, but logs the reason
<zyga-ubuntu> zyga@gracik:/etc/systemd/network$ systemctl status snapd.snap-repair.service
<zyga-ubuntu> â snapd.snap-repair.service - Automatically fetch and run repair assertions
<zyga-ubuntu>    Loaded: loaded (/lib/systemd/system/snapd.snap-repair.service; static; vendor preset: enabled)
<zyga-ubuntu>    Active: inactive (dead)
<mvo> zyga-ubuntu: it should be in "condition failed" state which is not an error (even if it sounds like one)
<zyga-ubuntu>      Docs: man:snap(1)
<zyga-ubuntu> zyga@gracik:/etc/systemd/network$ systemctl status snapd.snap-repair.timer
<zyga-ubuntu> â snapd.snap-repair.timer - Timer to automatically fetch and run repair assertions
<zyga-ubuntu>    Loaded: loaded (/lib/systemd/system/snapd.snap-repair.timer; enabled; vendor preset: enabled)
<zyga-ubuntu>    Active: inactive (dead)
<zyga-ubuntu> mvo: it's showing the machine as in degraded status
<mvo> Chipaca: aha, interessting
<mvo> zyga-ubuntu: could you please pastebin it? my irc client garbled it
<zyga-ubuntu> sure
<Chipaca> zyga-ubuntu: it's snap-repair.timer, not snapd.snap-repair.timer i think?
<mvo> zyga-ubuntu: it should not make the machine degraded
<zyga-ubuntu> http://pastebin.ubuntu.com/25930918/
<Chipaca> at least here it is -- which might mean my local install is messed up :-) dunno
<zyga-ubuntu> http://pastebin.ubuntu.com/25930922/
<mvo> zyga-ubuntu: and systemctl --failed please
<Chipaca> zyga-ubuntu: systemctl list-timers
<mvo> zyga-ubuntu: aha, sorry you did that already
<mvo> zyga-ubuntu: it looks like you might have leftover files from an old deb?
<mvo> zyga-ubuntu: or maybe everyone has these (which would be bad)
<zyga-ubuntu> mvo: no, they are part of the package
<zyga-ubuntu> mvo: note: zesty
<zyga-ubuntu> mvo: this is my router, not devbox
<zyga-ubuntu> so no locally built magic files
<zyga-ubuntu> I just noticed because I'm about to shut it down
<mvo> zyga-ubuntu: interessting, let me try in a fresh vm. fwiw, I see the "expected" condition failed and nothing in systemctl --failed on my box (but its artful)
<mvo> zyga-ubuntu: or is this 2.27.6 still?
<Chipaca> strange i seem to have a mix of snapd.snap-repair.timer and snap-repair.timer. Probably need a restart sometime soon?
<zyga-ubuntu> mvo: checking
<mvo> zyga-ubuntu: apt list snapd
<zyga-ubuntu> 2.28.5+17.04
<zyga-ubuntu> curious
<mvo> yeah, let me try in my VM
<zyga-ubuntu> snapd/zesty-updates,now 2.28.5+17.04 amd64 [zainstalowany]
<zyga-ubuntu> zainstalowany is installed
 * zyga-ubuntu moves the final network part now, I'll be offline briefl
<zyga-ubu1tu> actually not much
<mvo> zyga-ubuntu: fresh 17.04 does not have the issue, let me try if I upgrade from 2.27 to 2.28
<mvo> zyga-ubuntu: no luck with 2.27 -> 2.28 either on zesty. hmmm
<mup> PR snapd#4202 opened: cmd: use a preinit_array function rather than parsing /proc/self/cmdline <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4202>
<Chipaca> jamesh: ouch! brand new pr with conflicts
<jamesh> Chipaca: gar.  I thought I'd pulled master.  Let me rebase it
<Chipaca> jamesh: ta
<Chipaca> jdstrand: did i understand you right yesterday, that in #4185 we don't actually need the group name? ie g:<gid> works just as well as g:<group name>?
<mup> PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
<mborzecki> Chipaca: afaik it's g:<group-name> or <gid>
<jamesh> Chipaca: fixed.
<Chipaca> mborzecki: ah. any reason not to do it that way?
<Chipaca> it doesn't buy us much, beyond not having to look up the name (i assume apparmor has to then look up the gid from the name again)
<Chipaca> or seccomp
<Chipaca> jamesh: thanks
<Chipaca> jamesh: and good night :-)
<pedronis> Chipaca: we are the one compiling seccomp, IÂ don't think it can do runtime group lookup I suspect (not sure)
<mvo> yeah, seccomp bpf is not very smart at all :)
<mborzecki> Chipaca: #4185 does that, the rule is sent as fchown u:root <gid>
<mup> PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
<mborzecki> we could push a little bit and use 'fchown 0 <gid>` as root user supposedly has uid 0 always
<Chipaca> mborzecki: gah, i got confused then, sorry
<mborzecki> damn, got an 'hr introduction' call in 10
<mup> PR snapd#4178 closed: asserts/assertstest:  fix use of hardcoded value when the passed  or default keys should be used <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4178>
<mup> PR snapd#4190 closed: cmd/snap-seccomp: do not use group 'shadow' in tests <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4190>
<mup> PR snapd#4179 closed: tests:  add a spread test for proxy.store setting together with store assertion <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4179>
<mup> PR snapd#4203 opened: tests/set-proxy-store: exclude ubuntu-core-16 via systems: key <Created by mvo5> <https://github.com/snapcore/snapd/pull/4203>
<pedronis> mvo: I was about to do the change requests by cachio to #4179
<mup> PR #4179: tests:  add a spread test for proxy.store setting together with store assertion <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4179>
<mup> PR snapd#4198 closed: release: 2.29.3 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4198>
<pedronis> mvo: ah, you made a PR but there is more tor remove
<mvo> pedronis: uh, sorry
<mvo> pedronis: too trigger happy. shall I close my followup then?
<pedronis> mvo: no, let me try to push the proper fix into it
<mvo> pedronis: thank you!
<pedronis> mvo: done
<mvo> pedronis: thanks again
<mvo> pstolowski: 4152 has two (optional) comments from me, I'm inclined to merge it as it is as its really nice but please check and either merge yourself or update
<pstolowski> mvo, thanks for the review, if there is no pressure i'll address them later today. currently debugging some other issue
<mvo> pstolowski: no pressure at all
<zyga-ubuntu> mvo: hey
<zyga-ubuntu> mvo: I'm back, sorry, was fighting systemd
<mup> PR snapd#4122 closed: configstate: add support for configure-snapd for snapstate.IgnoreHookError <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4122>
<zyga-ubuntu> mvo: I just noticed you worked on that huge conflict
<zyga-ubuntu> mvo: and pushed earlier than I did
<zyga-ubuntu> mvo: I just reslved the same conflicts
<mvo> zyga-ubuntu: hey, meh, I wanted to talk about it first but you not being on irc made me assume you are at lunch
<mvo> zyga-ubuntu: sorry for that
<zyga-ubuntu> mvo: no worries, sorry for dragging you into this
<zyga-ubuntu> mvo: I painfully found out which features are not enabled in systemd in xenial
<zyga-ubuntu> :/
<mvo> zyga-ubuntu: uh, what is missing?
<zyga-ubuntu> mvo: lunch sounds like a good idea but I have to go out to eat something
<zyga-ubuntu> mvo: iptables
<zyga-ubuntu> mvo: I'm building a local version that supports that
<zyga-ubuntu> mvo: I moved my router from old PC to smaller old PC and decided to stick to LTS
<zyga-ubuntu> mvo: and network routing broke
<zyga-ubuntu> in the end I found a thread where debian disabled this to save 3500KB
<mvo> oh, woah
<zyga-ubuntu> it was fixed later and that's why it worked on zesty
<zyga-ubuntu> (this lets me remove a cable that runs across the house)
<zyga-ubuntu> well, hopefulyl
<zyga-ubuntu> it's building
<mup> PR snapd#4189 closed: interfaces/builtin/lxd_support: allow discovering of host's os-release <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4189>
<mup> PR snapd#4159 closed: cmd/snap-confine: add slave PTYs and let devpts newinstance perform mediation <Created by jdstrand> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4159>
<mup> PR snapd#4200 closed: daemon,overlord/snapstate: return snap-not-installed error in more cases <Created by robert-ancell> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4200>
<pstolowski> mvo, pedronis can you take another look at #4177?
<mup> PR #4177: state: add change.LaneTasks helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/4177>
<zyga-ubuntu> mborzecki: https://github.com/snapcore/snapd/pull/4201 ?
<mup> PR #4201: tests/lib: handle distro specific grub-editenv naming <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4201>
<mborzecki> looking
<cachio> mvo, hey
<cachio> did you see the email I sent yesterday?
<mborzecki> zyga-ubuntu: can you take a look at https://github.com/bboozzoo/snapd/commits/bboozzoo/tests-grub-editenv-wip ? i haven't pushed the last 3 commits for review yet though
<mborzecki> basically replaces `$GRUB_EDITENV list` with `bootenv` as the latter is supposed to dump bootloader env
<zyga-ubuntu> mborzecki: aha, thanks
 * Chipaca ~> lunch
<pstolowski> zyga-ubuntu, can you take another look at #4152 ?
<mup> PR #4152: snapd: fix snap cookie bugs <Created by stolowski> <https://github.com/snapcore/snapd/pull/4152>
<zyga-ubuntu> pstolowski: I merged and de-conflicted https://github.com/snapcore/snapd/pull/4120
<mup> PR #4120: repo: use PlugInfo and SlotInfo for permanent plugs/slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/4120>
<zyga-ubuntu> pstolowski: I'll merge udev hook fixes as well but won't push until that lands in master
<zyga-ubuntu> pstolowski: then I'll look at cookies
<pstolowski> zyga-ubuntu, thanks for pushing 4120!
<zyga-ubuntu> pstolowski: let's land fix/udev-hooks first, I already merged the de-conflicted version locally so that it will let your PR land without conflicts soon thereafter
<mborzecki> pstolowski: https://github.com/snapcore/snapd/pull/4191#pullrequestreview-75471258 not sure I follow, there is no quick return path in XSnapdGID in this case
<mup> PR #4191: cmd/snap-update-ns: do not assume 'nogroup' exists <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4191>
<pstolowski> mborzecki, yeah, co my concern is if you change XSnapGID function to match on some other x-snapd string by mistake, you will hit the quick return path instead and test will be happy
<pstolowski> root is just kinda special
<mborzecki> ok, i see what you mean
<pstolowski> in other words, we don't know if we hit the right code path if we ask for roo
<pstolowski> *root
<pstolowski> zyga-ubuntu, do you need anything from me re udev? I think i approved your PRs
<zyga-ubuntu> pstolowski: I think we are waiting for tests now
<zyga-ubuntu> pstolowski: today is a review day, I'll do as little coding as I can :)
<pstolowski> mborzecki, any other common user we could rely on in this test?
<mborzecki> no, don't think so
<mborzecki> we need a well known gid
<mborzecki> otoh, it's just a test, there should be no harm in calling osutil.FindGid()
<mborzecki> so if we'd rather not use 'root' there, we'll just have to try nogroup and nobody and fine which one exists
<mborzecki> s/fine/find/
<zyga-ubuntu> darn
<zyga-ubuntu> my daughter forgot her towel at the swimming pool at school
<zyga-ubuntu> AFK
<pstolowski> zyga-ubuntu, my daughter is notorius for forgetting stuff at school ;). happy seeking
<pstolowski> mborzecki, commented on xsnapgid PR
<mborzecki> pstolowski: thanks, right, i've cherry picked 2 commits, missed a 3rd one :/
<pstolowski> good ;)
<Chipaca> niemeyer: stand up
<Chipaca> pedronis: you too
<niemeyer> Chipaca: Trying to join
<niemeyer> (and not working)
<mborzecki> pstolowski: pushed a fix, hopefully a last one :)
<mborzecki> pstolowski: thanks for the review
<zyga-ubuntu> [   30.633917] audit: type=1400 audit(1489520905.019:12): apparmor="DENIED" operation="open" profile="/usr/lib/snapd/snap-confine//snap_update_ns" name="/dev/urandom" pid=1508 comm="5" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<pstolowski> mborzecki, yw
<diddledan> ooh ooh ooh. I got gimp beta compiled
<mup> PR snapd#4192 closed: osutil: add helper for obtaining group ID of given file path <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4192>
<mup> PR snapd#4149 closed: tests: new tests for network setup control and observe interfaces <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4149>
<zyga-ubuntu> niemeyer: https://forum.snapcraft.io/t/systemd-in-ubuntu-16-04-core-snap-doesnt-support-iptables/2768
<jdstrand> Chipaca: what I said yesterday is one can use '<gid>' (note, no 'g;') can be used instead of 'g:<group>'
<Chipaca> jdstrand: yeah, mborzecki cleared me up on that, thank you
<jdstrand> np
<mup> PR snapd#4203 closed: tests/set-proxy-store: exclude ubuntu-core-16 via systems: key <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4203>
<pedronis> mvo: do we have stuff that can be untagged in your upcoming,  or it's all still in progress for 2.29?
<pedronis> *do you
<mvo> pedronis: let me check
<Chipaca> niemeyer: could you re-run the review sprint generating script magic thing?
<Chipaca> niemeyer: (assuming it's cheap for you to do so)
 * Chipaca <- lazy
<niemeyer> Chipaca: Of course, churning right now
<Chipaca> ta
<niemeyer> Chipaca: Done
<mup> PR snapd#4144 closed: interfaces: fix udev tagging for hooks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4144>
<zyga-ubuntu> pstolowski: pushed, can you look at https://github.com/snapcore/snapd/pull/4120/files to ensure it's sane
<mup> PR #4120: repo: use PlugInfo and SlotInfo for permanent plugs/slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/4120>
<zyga-ubuntu> jdstrand: I need 2nd review for https://github.com/snapcore/snapd/pull/4163
<mup> PR #4163: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <https://github.com/snapcore/snapd/pull/4163>
<pstolowski> zyga-ubuntu, will do
<zyga-ubuntu> pstolowski: and some comments on https://github.com/snapcore/snapd/pull/4108
<mup> PR #4108: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108>
<mup> PR snapd#4129 closed: wrappers: do not error on incorrect Exec= lines <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4129>
<pstolowski> zyga-ubuntu, thank you for both
<pedronis> mvo: did you remove some mvo tags but not the upcoming tag ?  or I'm just confused
<Chipaca> siiiigh
<zyga-ubuntu> mvo: some failures to address here https://github.com/snapcore/snapd/pull/4063
<mup> PR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>
<zyga-ubuntu> Chipaca: it's Frida
<Chipaca> yaml's support for sexagesimal numbers is awesome
<mvo> pedronis: meh, sorry, wrong way around, I need a cup of tea I think
<zyga-ubuntu> Chipaca: cannot be that bad
<pedronis> mvo: seems so :)
<pedronis> it's probably me but IÂ feel we have realistically too many things marked as upcoming
<pedronis> or upcoming means in the next 6 month, which maybe is ok, but then we need one more tag or something
<zyga-ubuntu> building systemd on atom is ... painful
<mborzecki> anythin on atom is painful
<mborzecki> it's a broken CPU to begin with
<Chipaca> mborzecki: how so?
<zyga-ubuntu> mborzecki: it's not very superscalar AFAIR, like old ARMs
<Chipaca> mvo: is #4049 on your plate, or should i pester somebody else?
<mup> PR #4049: debian,vendor: import github.com/snapcore/squashfs and use <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049>
<mvo> Chipaca: me but I'm currently busy and can only look at it next week again
<Chipaca> mvo: Â¯\_(ã)_/Â¯
<Chipaca> mvo: for the record, i'm fine with that :-)
<pedronis> pstolowski: are install/remove hooks in 2.29 or 2.28 ?
<mborzecki> zyga-ubuntu: never lived up to the hype, the only advantage bing a familiar instruction set, but performance and power consumption wise it's not very appealing
<zyga-ubuntu> mborzecki: no disagreements there :)
<mborzecki> could have been worse though, recall quarks :P
<zyga-ubuntu> mborzecki: quarks aka, that thing running inside ME
<mborzecki> this was a nice addition to the gallery of SoC oddities: https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug
<mborzecki> iirc that's why they were stuck with some ancient kernels too
<pstolowski> pedronis, yes, they landed in 2.27
<zyga-ubuntu> mborzecki: not cute embedded nonsense hacks (aka intel)
<mborzecki> this is new 'Cannot allocate linode:opensuse-42.2-64: no powered off servers in Linode account exceed halt-timeout'
<zyga-ubuntu> mborzecki: EAGAIN
<mborzecki> ok
<zyga-ubuntu> too many things in flihg
<sergiusens> hello everyone! Just getting started here, rough night last night
<zyga-ubuntu> *flight
<zyga-ubuntu> sergiusens: he
<zyga-ubuntu> sergiusens: what's happened?
<sergiusens> zyga-ubuntu food sickness...
<zyga-ubuntu> sergiusens: ouch, I'm sorry
<sergiusens> stlll dealing with it, but I now have the energy to get up
<sergiusens> yeah, me too :-P
<cachio> mvo, https://paste.ubuntu.com/25932196/
<cachio> this is what I see after refresh on db
<cachio> the dmesg is the same I sent before
<mvo> cachio: this is very strange "Mar 14 19:48:44 localhost.localdomain systemd[1]: Stopping Snappy daemon...". it almost looks like something outside is stopping snapd on purpose
<cachio> mvo, I ran the test suite to reproduce it
<cachio> I could make it manual
<pedronis> pstolowski: we don't have pre-refresh, right?
<cachio> the suite is the not stopping it
<pedronis> pstolowski: is it planned?
<cachio> an it is the same suite we run for pi2 and 3
<cachio> mvo, perhaps it is a problem in the this old stable image
<pstolowski> pedronis, correct, we don't have it. i've it implemented but got stuck on that issue we discussed on the last sprint where I'm getting tasks in wrong order in the test
<pedronis> ah
<jdstrand> zyga-ubuntu: ack
<pstolowski> i've spent a good chunk of time looking at it during the sprint but didn't get to the bottom
<zyga-ubuntu> jdstrand: thank you :)
<zyga-ubuntu> jdstrand: that's just a refactor but I wanted to make sure you see it
<jdstrand> zyga-ubuntu: this isn't for 2.29, right?
<zyga-ubuntu> jdstrand: no, for master
<zyga-ubuntu> jdstrand: 2.29.x is closed I think (yay)
<zyga-ubuntu> jdstrand: there's also a PR on top that explains why this refactor is needed
<zyga-ubuntu> (or useful)
<pedronis> pstolowski: is something you will look at again at some point?
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4169
<mup> PR #4169: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <https://github.com/snapcore/snapd/pull/4169>
<pstolowski> pedronis, yes
<jdstrand> zyga-ubuntu: ok. fyi, I have a couple things ahead of it to clear my desk for these reviews. possible I won't review til monday, but I'll try for today
<jdstrand> zyga-ubuntu: I've been collecting your requests. 4163, 4166, 4169 and 4170
<zyga-ubuntu> jdstrand: thank you, we are trying to close the review sprint (well, eventually, not today) and getting those refactors merged would unblock me on more features :)
<jdstrand> zyga-ubuntu: are there others I should add to the list for next week or just wait for you to ping me?
 * kalikiana hopping on a train, back in a bit
<zyga-ubuntu> jdstrand: no, that's the only one, next week is fine
<zyga-ubuntu> kalikiana: stay safe :)
<kalikiana> zyga-ubuntu: Always. I sit on the roof of the car so nothing inside can harm me :-P
<zyga-ubuntu> hahaha
<zyga-ubuntu> well
 * zyga-ubuntu would not be surprised
<zyga-ubuntu> mborzecki: https://forum.snapcraft.io/t/brave-and-other-apps-dont-launch-on-arch/2770/2
<zyga-ubuntu> mborzecki: something for you :)
<mup> PR core#63 opened: 25-create-generic-initrd.chroot: use symlink instead of copy <Created by mvo5> <https://github.com/snapcore/core/pull/63>
<zyga-ubuntu> mborzecki: one more review on https://github.com/snapcore/snapd/pull/4185
<mup> PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
<elopio> jdstrand: thanks a lot for your comments in the classic request. I have a question, if I run the yarn snap as classic, is it the same as if I download a yarn binary and run it with sudo?
<mvo> cachio: sorry for the delay. maybe, what is confusing to me is is that it looks like something stoped snapd via systemctl stop. there is no setup magic somewhere in our scripts that does that and just forgot to start it again?
<zyga-ubuntu> mvo: review for yuor core pr
<zyga-ubuntu> conflict on https://github.com/snapcore/core/pull/58
<mup> PR core#58: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58>
<sergiusens> mariogrip added a testing bit to your PR snapcraft#1723
<mup> PR snapcraft#1723: sources: workaround for ZipFile.extractall not preserving permissions <Created by mariogrip> <https://github.com/snapcore/snapcraft/pull/1723>
<sergiusens> elopio care to take a look? ^
<cachio> mvo, I just executed manually and made the reboot manually and snapd service was running after that the
<cachio> now I am leaving that to autoreboot to see
<cachio> mvo, I'll have results in 10 minutes
<cachio> if it works I'll make the promotion
<mvo> cachio: thank you
<mvo> zyga-ubuntu: heh
<mvo> zyga-ubuntu: so the snapctl internal configure-core
<mvo> zyga-ubuntu: will be changed to "rm -f"
<mvo> zyga-ubuntu: because we now really do the configure internally
<zyga-ubuntu> mvo: good :)
<zyga-ubuntu> rm -rf on snap set harakiri
<zyga-ubuntu> ;-)
<mup> PR snapd#4197 closed: cmd/snap-confine: Support bash as base runtime entry <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4197>
<Chipaca> niemeyer: in spread, is SPREAD_REBOOT reset when entering the debug shell?
<cachio> mvo, core 2.29.3 promoted to candidate
<mvo> cachio: yay, thank you
<cachio> mvo, now we just need confirmation from qa
<cachio> hopefully on monday we willl be ready
<cachio> to go to stable
<cachio> :)
<niemeyer> Chipaca: Yes, the reboot loop happens entirely inside the client abstraction, which means any snippet at all can reboot, and it also means we can't hook into intermediate state
<zyga-ubuntu> I cannot believe my machine is _still_ building systemd
<zyga-ubuntu> mborzecki: +1, thanks :)
<zyga-ubuntu> mborzecki: not sure which snaps you have installed but the more you have the better testing we get
<Chipaca> mvo: question for you about #4063: was there anything you expected of pc-kernel storeside for it to pass?
<mup> PR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>
<zyga-ubuntu> mborzecki: I'm always using telegram as my 1st snap on any system
<Chipaca> mvo: i mean: seems like it'd need different kernels in edge and stable, and that's not the case
<zyga-ubuntu> mborzecki: I'm also using ohmygiraffe for casual GL-works tests
<Chipaca> zyga-ubuntu: strange, for most people it's 'core'
<mborzecki> node-red and brave seem to work :) (where work means starts and either a window shows up or i can connect to some web ui)
<Chipaca> :-P
<zyga-ubuntu> Chipaca: nah, you just have to be very quick
<zyga-ubuntu> Chipaca: or have autofire on your keyboard
<mvo> Chipaca: yes, it needs that (the test) and it was the case sme days ago :/
<mvo> Chipaca: thanks for this feedback
<Chipaca> mvo: yeah, now they're all the same :-/
<mborzecki> zyga-ubuntu: ohmygiraffe looks like fun
<mborzecki> no warnings/erorrs popup with LIBGL_DEBUG
<zyga-ubuntu> mborzecki: nice :)
<elopio> popey or flexiondotorg: can you please fork this into snapcrafters? https://github.com/elopio/yarn
<mvo> pedronis: the new configure-snapd task has an interessting twist (regarding backwards compat): https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774/1
<mvo> Chipaca: its something I will contemplate on monday I think
<pedronis> mvo: ok
<mvo> pedronis: looks like we need to think a bit about a fix before doing 2.30
<mvo> pedronis: I will make a cup of tea and ponder a bit
<pedronis> it's a bit of a general problem, I mean we need to solve it here but I think we never thought true what unknown tasks means vs revert
<pedronis> *thought through
<mvo> pedronis: yeah, very good point
<zyga-ubuntu> mborzecki: more posts about arch from popey
<popey> :D
<pedronis> mvo: anyway is the last thing the revert needs to do, no?
<popey> elopio: doing now
<zyga-ubuntu> popey: thank you for reporting those!
<popey> np
<zyga-ubuntu> popey: I think we need to be really loud about the new package
<pedronis> mvo: after a week the change will go away, but you cannot do anything with core in that week
<zyga-ubuntu> popey: and if we cannot update the community package, burn it with fire
<popey> zyga-ubuntu: totally, assuming it works :D
<popey> are you saying it's _impossible_ to update the existing snapd package?
<popey> That seems like Arch is designed for Awesome.
<mborzecki> popey: did you manage to build the package?
<zyga-ubuntu> popey: last time I looked the package was abandoned
<popey> mborzecki: i haven't tried yet.
<mborzecki> ack
<zyga-ubuntu> popey: and to even remark that we need a monthly process initiated by a trusted user
<popey> also had to fix my suse install which broke when I updated it :(
<zyga-ubuntu> popey: and then more time to maybe replace the package
<mborzecki> fwiw, trying to install nextcloud now
<zyga-ubuntu> popey: flexiondotorg knows more
<popey> ya
<zyga-ubuntu> popey: yeah, I noticed
<zyga-ubuntu> popey: I killed that snapper tool (whatever it does) as I ran out of space myself
<popey> elopio: https://github.com/snapcrafters/yarn
<popey> elopio: do we need to get the name moved over in the store? If so, can you request it>
<popey> >
<popey> gah, ?
<niemeyer> pstolowski: #4108 reviewed
<mup> PR #4108: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108>
<mborzecki> uhh nextcloud, php-fpm, redis, mysql, apache, omg
<niemeyer> pstolowski: Let me know if you want to talk about it so you're unblocked
<elopio> popey: yes, I will request the transfer. But wanted to wait on the classic assignment first.
<elopio> there's a bit of discussion there.
<popey> ok, great
<mvo> pedronis: its revert and refresh. yeah, things will heal after a week which is great
<pstolowski> niemeyer, thanks for the review!
<pedronis> mvo: mmh, it will be aborted first which will undo the revert, that's not great
<niemeyer> pstolowski: np
<pedronis> mvo: why are we getting a revert btw?
<mvo> pedronis: we are not getting a revert, sorry, my post is not clear about this. it just hangs forever on refresh/revert when the configure-snapd task is there
<pedronis> mvo: it hanges on refresh?
<pedronis> why does it hang on refresh?
<mvo> pedronis: when going from a snapd that add the configure-snapd task to a snapd that does not understand this task after the reboot (second phase of security setup) the task will be in "Do" state but never run by the "old" snapd because it does not know what to do with it (c.f.  https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting )
<mvo> pedronis: so what happend was that edge had a core with configure-snapd support, the snapd 2.29.3 got built which does not know about configure-snapd but landed in edge
<mvo> pedronis: so people refreshing during the time that 2.29.3 was in edge and had a 2.29+git version with configure core strange things happend
<pedronis> mvo: ah, it's a strange case
<mvo> pedronis: does that vaguely make sense?
<niemeyer> It does :(
<mvo> pedronis: but its also happening when doing "sudo snap refresh --edge; sudo snap refresh --candiate" for core
<pedronis> yes, IÂ understand
<mvo> pedronis: just wanted to share it with you, its not omg-criticial as so far only edge is affected but but :)
<pedronis> as I said we have a concrete problem but also a general question here
<mvo> indeed
<pedronis> it's also an internal design thing, because we have many taskrunners, nothing really takes care of tasks that aren't registered by anything
<zyga-ubuntu> pedronis: maybe we need a sanity check "manager" that aborts unclaimed tasks in some way?
<mborzecki> zyga-ubuntu: https://github.com/snapcore/snapd/pull/4185#discussion_r150254354 'internal' as in do it in init(), keep the error around and return it in SecCompConnectedPlut or just panic() in init()?
<mup> PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
<zyga-ubuntu> mborzecki: returning the error feels better
<zyga-ubuntu> mborzecki: panic can bring down snapd in cases we may not want to
<ppisati> sergiusens: any ETA for 2.35?
<zyga-ubuntu> sergiusens: we should plan to sync numbers :)
<zyga-ubuntu> sergiusens: it'd be awesome if snapd and snapcraft were in sync
<zyga-ubu1tu> man
<zyga-ubu1tu> systemd built :D
 * zyga-ubu1tu EODs for now, I'll push one more PR for layouts but I need to eat something first :)
<niemeyer> pedronis, mvo: And that's a bit by design.. there are three things we can do: ignore, fail, or wait
<niemeyer> Ignore feels like a non-starter
<pedronis> yea, it's not clear what we should do
<pedronis> at the moment basically we chose fail (just slowly)
<niemeyer> Fail is probably the best option
<niemeyer> pedronis: We choose wait..
<niemeyer> pedronis: Fail after a week
<pedronis> well the task will be aborted
<niemeyer> Yeah, but after a week, which for human purposes is really waiting
<pedronis> no, abort is 24h
<pedronis> I think
<pedronis> prune is a week
<niemeyer> It's the opposite.. pruning is faster than aborting
<niemeyer> IIRC at least
<pedronis> ah, yes, sorry
 * pedronis is doing too many things at the same time
<niemeyer> We'll require some more info to change this, though..
<niemeyer> As task runners are really an independent thing today
<niemeyer> IOW, there's no global knowledge of all handlers available
<pedronis> yea
<pedronis> there's no global registry of all known task kinds
<niemeyer> We might cheat and track at a package level every known handler
<niemeyer> and only abort those
<niemeyer> That might be cheap
<niemeyer> only abort those not known at all, obviously
<niemeyer> There is a bit of danger in doing even that, though, as it becomes racy
<niemeyer> Another option that might be cheap and saner is timing out based on how long the task is waiting to run without an available handler
<niemeyer> IOW, try to run it, if there's no handler right now, abort it right away or after N minutes/hours
<niemeyer> Again, a bit of care needs to be taken as we've never been worrying about delays between the main loop running and the handler being available
<niemeyer> Since we wait..
<niemeyer> mvo, pedronis: So.. do we need to do something right now?
<mvo> niemeyer: I think we need something for 2.30, I think it would be unfortunate if "snap revert core" would basilcy force a 24h wait until the task times out (and then it would undo the revert)
<mvo> (or am I missing something?)
<niemeyer> mvo: You are missing that it's actually a week.. :D
<mvo> niemeyer: *cough* thats not making it better ;)
<mvo> niemeyer: the other thing is that 2.29 cannot be retro-fitted with whatever we come up with
<niemeyer> mvo: Exactly what I was thinking..
<mvo> niemeyer: I mean, ideally whatever we do would work on a previous snapd :/
<niemeyer> mvo: Even if we change the behavior of 2.30, that won't be fixed unless we get away with the new task altogether
<mvo> niemeyer: indeed
<niemeyer> mvo: Oh, kind of
 * mvo listens
<niemeyer> mvo: Where is the new task being introduced? 2.30?
<mvo> niemeyer: correct
<mvo> niemeyer: 2.29.3+git to be pedantic
<niemeyer> mvo: So only tasks generated in 2.30 would present the issue
<mvo> niemeyer: yes
<niemeyer> mvo: That means an explicit revert of the update itself would not present the issue, at least
<mvo> niemeyer: yes, from 2.30 we could revert/refresh and generate appropriate tasks, i.e. if we know we go backwards we could DTRT
<niemeyer> mvo: Right.. we might actually change the behavior of snapd so that we never generate configure-snapd on operations of core itself
<niemeyer> mvo: As it's a bit silly anyway
<niemeyer> mvo: We can always reconfigure the core because.. well.. the code is running in the first place :)
<mvo> niemeyer: heh, I see (I think)
<mvo> niemeyer: so refresh/revert etc does not generate configure-core tasks. but when snapd starts it does the configure automatically every time? and of course snap set core would trigger the task, did I get this right?
<mborzecki> ok guys, i need to wrap it up for today
<mborzecki> enjoy your weekend everyone
<niemeyer> mvo: We may not even trigger the configure automatically for now
<niemeyer> mvo: We literally have the actual code running.. we can always fix data or do whatever else live in the appropriate places
<niemeyer> mvo: Instead of expecting ourselves to call ourselves to reconfigure
<niemeyer> mvo: Sounds like a win in terms of stability, overall, given our experience in core to core updates
<mvo> niemeyer: I was thinking pushing it into a task is nice as its observable from the outside and it may take some seconds to run potentially at least
<mvo> niemeyer: but yeah, happy to go taskless :)
<niemeyer> mvo: But what exactly is observable? :)
<pedronis> well  snap set needs a task because of the API
<niemeyer> pedronis: Yeah, no changes there
<niemeyer> pedronis: This is specifically about snap operations on snapd
<niemeyer> Or core, for now
<mvo> niemeyer: I think you are right, we don't really do anything in corecfg.Run() that takes time. I was thinking it might be nice to be able to see that configure core is hanging
<mvo> niemeyer: but it should never do that and we can internally add safety for that
<mvo> niemeyer: I like the outcome! will you followup in the forum or shall I try to summarize?
<niemeyer> mvo: Yeah, and if there's no configure core, we won't ever see it hanging :P
<mvo> lol
<niemeyer> mvo: I mean unless you really want it.. we can always add a sleep like the old days..
 * niemeyer still remembers of a previous life where folks added a sleep to slow down rsync, on customer request
<niemeyer> *inside* rsync
<niemeyer> mvo: Do we have a topic for this already?
<mvo> niemeyer: yes https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774
<mvo> niemeyer: we found it because ondra actually hit the issue
<niemeyer> mvo: I'm summarizing the preliminary discussion and agreements
<pedronis> mvo: IÂ thought we were requesting "base"Â to the store, is that not the case yet?
<mvo> niemeyer: brilliant,thank you
<mvo> pedronis: I thought so as well, I even downloaded some bases
<mvo> pedronis: eh, uploaded
<pedronis> mvo: IÂ don't see it in the code
<mvo> pedronis: in our code?
<pedronis> yes
<pedronis> mvo: sorry, IÂ mean the field, not the type
<pedronis> mvo: did you implement the bits needing it, but didn't add the store/ parts yet?
<mvo> pedronis: it looks like it, let me look at the details
<niemeyer> mvo, pedronis: Hopefully I captured it well
<pedronis> we need to be a bit careful with firstboot code
<pedronis> I added a note in the topic
<ikey> so ehm
<ikey> how would i go about publishing snaps and controlling channels
<ikey> without snapcraft?
 * ikey would like to get his snaps out for edge testing this weekend
<Chipaca> ikey: you should be able to do most of it via the web as well i think
<niemeyer> ikey: snapcraft is just calling the store APIs, but we have no docs for that.. and those APIs are also a bit ancient so please don't expect a polished API at this time
<ikey> sure
<Chipaca> ikey: you used to, but i haven't checked if that's changed
<ikey> but snapcraft is unusable for me
<ikey> and i aint switching to ubuntu just to use it
<niemeyer> ikey: You can build the snap without snapcraft, and use snapcraft just to push it
<ikey> i built it without snapcraft
<ikey> https://bugs.launchpad.net/snapcraft/+bug/1731478
<mup> Bug #1731478: Snap of snapcraft fails to run on Solus and openSUSE <Snapcraft:New> <https://launchpad.net/bugs/1731478>
<niemeyer> ikey: Yeah, so you can just snapcraft push
<ikey> ain't that easy
<ikey> its hardwired to debuntu
<Chipaca> niemeyer: snapcraft won't start for him (see bug)
<Chipaca> ikey: i expect that to get fixed soonish, but, have you tried the web?
<niemeyer> Wat?
<ikey> i haven't
<ikey> niemeyer, solus != ubuntu
<Chipaca> ikey: dashboard.snapcraft.io
<niemeyer> ikey: I know, I just didn't expect snapcraft to be unable to work at all
<ikey> oh lol
<ikey> "This should be a snap for Ubuntu Core; upload will begin as soon as a valid file is selected."
<ikey> eh.
<niemeyer> nessita: ^
<ikey> oh thats another thing btw
<ikey> snapd absolutely mandates the presence of core
<ikey> even if you don't need it
<ikey> so if you install solus-runtime-gaming you have to install core
<Chipaca> ikey: with bases, we're going to split core into actual core and an ubuntu base, and then things will be happier
<Chipaca> ikey: still on our TODO though
<ikey> right but i mean - it still won't need any kind of core
<niemeyer> ikey: That traceback seem related to snapcraft being run in packaging mode
<niemeyer> ikey: Is snapcraft push --help working for you?
<Chipaca> ikey: at that point you still need core, to have snapd inside snaps, but you dont need the rest
<ikey> we dont support reexec on solus
<ikey> so we don't actually need core
<Chipaca> ikey: ah
<ikey> its a subtle nuance but i figured id bring it up :)
<ikey> niemeyer, https://hastebin.com/vaparusuha.sql
<Chipaca> ikey: well, it'll get at least a little better when we split core, even if we continue to pretend everybody reexecs
<ikey> even --help doesn't work
<ikey> Chipaca, sure
<Chipaca> but, fair point
<ikey> on the plus side:
<ikey> 2.7M	linux-steam-integration_0.6_amd64.snap
<ikey> 287M	solus-runtime-gaming_0.0.0_amd64.snap
<niemeyer> ikey: Have you tried to just comment out apt_pkg.init()?
<ikey> its in a ready only snap
<ikey> think about it :p
<niemeyer> ikey: mount --bind?
 * ikey blinks
<ikey> its a .snap file
<ikey> read only squashfs
<niemeyer> ikey: You can bind mount a file into a read-only file
<sergiusens> ikey your bug should be fixed in 2.36
<ikey> niemeyer, im not sure you're following here
<ikey> the snap is already read-only
<ikey> i can't edit the files inside it
<ikey> the only way for me to "fix" this is to manually install snapcraft
<niemeyer> ikey: You can literally bind mount a file into a mounted read-only filesystem
<niemeyer> ikey: It doesn't matter if it's zfs or squashfs
<ikey> still not getting it
<ikey> k
<niemeyer> ikey: Okay, nm.. 2.36 sounds like an easier target.. :)
<ikey> i dont have any of the debian support
<ikey> so apt_pkg.init is just one call im gonna have to fart with
<niemeyer> ikey: snapcraft should not need any debian support at all to push a snap
<ikey> thats deep in debian/debian_support.py
<ikey> i know :P
<niemeyer> ikey: It sounds like a silly leftover initialization that shouldn't be running until obviously necessary
<ikey> yea
<niemeyer> (and which is already fixed)
<ikey> is there an edge snap i can move to? :P
<ikey> ah crap
<ikey> im on edge
<niemeyer> snap info snapcraft says 2.34
<ikey> 2.34+git97.af78689
<ikey> hmph
<niemeyer> sergiusens: How come?
<ikey> lol
<sergiusens> niemeyer changing that legacy choice is a refactor away
<niemeyer> sergiusens: No snapcraft edge?
<sergiusens> wait, what?
<sergiusens> https://pastebin.ubuntu.com/25933068/
<niemeyer> sergiusens: Yeah?
<sergiusens> ikey wth, we are delayed with the release on the wait of the 40 4 hour each snapd tests on adt; I'll just fix it now
<niemeyer> sergiusens: None of those 2.34 look like 2.36..? :)
<ikey> xD
<niemeyer> sergiusens: Any reason why edge releases aren't happening daily automatically?
<sergiusens> niemeyer they happen daily
<sergiusens> https://pastebin.ubuntu.com/25933087/
<niemeyer> sergiusens: That's not 2.36..
<sergiusens> no, no code for 2.36 exists in a merged state
<sergiusens> we don't branch out like you guys do
<niemeyer> sergiusens: I'm clearly missing something.. what do you release daily on edge then?
<sergiusens> niemeyer master
<niemeyer> sergiusens: Sure.. but clearly master doesn't contain the new things that are being merged..?
<sergiusens> niemeyer it exactly contains that
<niemeyer> sergiusens: Okay, I misunderstood what you meant all along then
<niemeyer> sergiusens: There's no 2.36 release, and there's no fix yet
<sergiusens> oh, I said I would fix it for 2.36, not that it is fixed in 2.36 :-)
<niemeyer> sergiusens: You actually said it should be fixed in 2.36, and both me and ikey went looking for that
 * ikey grins at confuzzlement
<ikey> while reading up on opengl apis -_-
<niemeyer> Anyway, we understand it now..
<sergiusens> ah, should is a vague word I used; should (pun) have said shall
<ikey> xD
<ikey> friday, right.
<niemeyer> sergiusens: "will" is the one you're looking for :)
<sergiusens> will also works
<cjwatson> ikey: it would work if apt_pkg were entirely absent, just not when present but broken
 * ikey blinks
<ikey> i don't have any kind of apt_pkg
<cjwatson> I guess it must be in the snapcraft snap
<ikey> yea
<cjwatson> I'm mostly just vocalising my "hmm, I was sure apt_pkg was optional in python-debian" train of thought
<ikey> yea
<ikey> in theory apt_pkg is present in a broken state
<ikey> because of "missing /etc/apt.d"
<ikey> or apt/something.d i dk
<ikey> i haven't deb'd in a long time :p
<niemeyer> ikey: One possibility is grabbing the snapcraft source code and yanking half of its logic until push works.. in theory push should really not care about anything about the host system at all.. only the snap file is relevant
<ikey> that certainly is one possibility
<ikey> one id rather avoid
<ikey> getting python out of all the nooks on your system again after is like tryna get bird cack out of your hair
<ikey> you just know its still there somewhere
<ikey> and id rather follow the snap package in future, without host conflicts
<niemeyer> ikey: If the web works, that's the easiest.. otherwise spending 5-10 minutes on this might be fruitful.. even more considering you know the upstream will fix the issue for you soon
<ikey> (y'all can keep that mental image for free)
<niemeyer> ikey: Haha, yeah
<ikey> what does series 16 mean on the dashboard..?
<sergiusens> ikey you shouldn't need apt at all; this is related to an if 'linux' as a whole
<Chipaca> ikey: how about this: grab the snapcraft .snap, unsquashfs, enter, and use 'snap try' to have a rw snap
<mup> PR snapcraft#1654 closed: autotools: cross-compile using --host instead of env <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1654>
<ikey> sergiusens, eehhhhhhh
<ikey> don't get me started on that one mate :P
<ikey> "linux == ubuntu"
<ikey> nope.
<ikey> not while im around :P
 * Chipaca hugs ikey 
<niemeyer> or me
<ikey> lolz
<sergiusens> ikey it was from way way way before we started trying to get snapcraft work on different distros; also, there is no if linux, we have "if win" and "if osx"
<ikey> *snort*
<Chipaca> ikey: did the web work?
<niemeyer> sergiusens: You're not making it any better
<niemeyer> sergiusens: saying apt_pkg == linux support is waaaaay too much of a stretch
<ikey> Chipaca, oh im not gonna upload it immediately immediately, was gonna do it in a few hours once i apply some basic polish to it
<sergiusens> niemeyer for linux we check os release, but went into a whitelist mode
<sergiusens> for apt we check os release
<ikey> my problem is nobody can really *use* the snap without having minimum 2.29.2 + my last 2 patches
<ikey> is there a way for a snap to say "oi i need this many versions"
<ikey> like minimum snapd version
<Chipaca> there is, but no idea how to use it. niemeyer?
<sergiusens> assumes
<Chipaca> yah
<sergiusens> but I don't know what the keywords are
<Chipaca> assumes: more-magic
<ikey> lol?
<ikey> oh jdstrand re: dynamic hotplugging..
<cjwatson> if the web works> AIUI the web upload option is due to be removed soon in favour of snapcraft, so perhaps best not to get used to relying on it ...
<niemeyer> assumes: snapdX.Y
<niemeyer> Sorry
<niemeyer> It's a list
<ikey> do we have plans for allowing udev rules within snaps ?
<niemeyer> assumes: [snapdX.Y]
<ikey> cjwatson, ah i wondered as much, the dashboard looks a bit uhm
<ikey> well. tired.
<ikey> niemeyer, so assumes: [ snapd2.29.4 ] for example?
<cjwatson> it's a codebase with a storied history.  there's some UI rerefresh work going on
<cjwatson> *refresh
<niemeyer> ikey: I don't think it supports micros.. need to double check
<ikey> ah k
<niemeyer> Double checking
<ikey> cjwatson, well it seems to look/talk about core a lot so i assumed it was from the Old Period
<ikey> and snapcraft being the new snapd specific sexy
<ikey> vs.. "core"
<cjwatson> that wouldn't be very surprising, indeed
<ikey> still i do *like* me some some CLI sexy
<sergiusens> is there a solus image fox lxd?
<ikey> so i can wait
<niemeyer> ikey: It does support micros
<ikey> niemeyer, oo shiny
<ikey> so i can have a built-in please-dont-even-no-stop
<niemeyer> Yeah, that was the idea all along
<ikey> i like
<ikey> i just dont wanna put up with the flood of bugs about the runtime
<Chipaca> i think it's a late warning, but it's better than nothing
<ikey> OMG DOESNT WORK ON MY ARCH LOONEXISES
<Chipaca> ie it's at validation time, once the download is done
<ikey> sergiusens, ive never made an lxd image
<ikey> but like, if one is wanted, i could figure out how to cook one
 * ikey doesn't use lxd 
<ikey> i just have a "make boot" command for all my ISOs in qemu and thats the extent of my virtualisation work
<sergiusens> ikey I wouldn't mind one :-) if you don't mind, I guess stgraber wouldn't mind adding it to the image repo
<niemeyer> Alright.. I'll go out for some exercising while the sun still shines
<niemeyer> See you soon
<Chipaca> I'm going to EOW now
<ikey> you have sun?
<Chipaca> niemeyer: o/
<niemeyer> Chipaca: Have a good one
<ikey> 17:56 here and black as a pint of the good stuff
<Chipaca> ikey: he's in brazil; if he doesn't have sun, we dead
<ikey> oh lol
<niemeyer> ROTFL
 * ikey likes that way of putting it :P
<cjwatson> ikey: eh, they call it the emerald isle for a reason, right?  never stops raining
<ikey> pretty much
<ikey> other countries have rumours of ghosts, girls hit by cars and such
<ikey> we have rumours of dry children walking the streets
<ikey> horrific stuff
<sergiusens> elopio have time for a quick hangout?
<elopio> sergiusens: I was finishing your review to go out and find lunch. I can delay that, but I'm a little hungry. Is it urgent? or can we talk by chat?
<sergiusens> elopio after your lunch
<elopio> sergiusens: I'll ping you.
<sergiusens> k
<jdstrand> ikey: re udev rules in snaps> there aren't plans (currently) to ship udev rules in app snaps. the udev interfaces backend is meant to be used for that (eg, the modem-manager interface creates the udev rules for modems when a snap implementing the slot is installed)
<ikey> hm ok
<ikey> so the "issue" that i have is steam ships udev rules
<ikey> and thats mostly for the steam controller
<ikey> and htc vive
<ikey> so right now with the steam snap they'd be bork
<jdstrand> ikey: we could think that through, but the joystick interface could be updated and the steam snap could slot it, or we can create a steam slot
<ikey> ah thats a good point
<ikey> fwiw i do realise this is a fairly specialist case and i dont wanna be unfair on you guys
<ikey> but i do suspect the steam snap will be ... somewhat popular
<jdstrand> or we create a game-controller interface that ships all the different controller udev rules, or something
<ikey> yeah
<jdstrand> this wouldn't be difficult at at all. the hard part would be to decide the name and how to organize the controllers. that would be a great forum topic
<ikey> ok
<ikey> for me i just wanna finally *solve* steam, and i think snap is the best way to accomplish this..
<ikey> and i think its some brownie points for snapd too :P
<jdstrand> that would be awesome
<jdstrand> :)
<ikey> we've been doing this stuff for like 2 years now, its actually remarkable seeing it all (literally) squashed down into these two snap files
<jdstrand> once the design is in place, I could whip something up for 2.30
<jdstrand> (for the controller)
<ikey> yeah
<jdstrand> controllers*
<ikey> it'd also allow feral to have their udev rules in snapd too
<ikey> for the wheels and such
<ikey> centralising it would be nice
 * jdstrand nods
<ikey> i used to be annoyed with the game porters because of the state of linux gaming, but honestly these days i get it and i feel sorry for them. they didn't ask for the state of the runtime..
<ikey> whats the right way to go about doing a call for testing for a snap?
<ikey> given that mine requires patches to snapd
<jdstrand> yeah. 'linux' is a thousand different things to a thousand different people
<ikey> mm
<ikey> the "actual" steam runtime is painful to look at, ubuntu 12.04 libs and such
<jdstrand> but like you said, snaps has the very real potential to fix that
<ikey> pre C++ ABI breaks
<ikey> yeah
<ikey> its why i ran away from appimage and such
<ikey> they don't solve ABI problems
<ikey> (plus the appimage code leaves much to be desired to be frank)
<jdstrand> I always wondered why the steam ppa was still on an old release
<ikey> i get the distinct impression valve trapped themselves
<ikey> with their own runtime
<ikey> which, tbf, back in the day it worked
<jdstrand> huh
<ikey> and then everything changed
<ikey> and they never *designed* the runtime
<ikey> nowadays if you designed it, you'd design ABI profiles
<ikey> in this version we have blahblah
<ikey> and you'd avoid host contamination
<ikey> it doesn't have any of that
<jdstrand> eww
<ikey> so we're left with the only conclusion
<ikey> replace the runtime *and* the host
<ikey> make them one
<ikey> much of LSI is 2 libraries which use LD_AUDIT to hijack the dynamic linker to make things point at system libs all the time, and LD_PRELOAD to unbreak game breaking bugs
<ikey> but it still needs the distro work
<ikey> like all the libs + emul32 cruft
<ikey> its really hard to integrate LSI :)
<ikey> case in point, look at all these deps: https://dev.solus-project.com/source/steam/browse/master/package.yml
<ikey> they were all enabled just for steam, and their chains..
<jdstrand> what, no wayland?
 * jdstrand ducks
<ikey> XD
<ikey> actually we did try
<ikey> but the SDL client has X11 specific calls
<ikey> we use Steam with our own SDL to alleviate client issues (broken videos etc)
<ikey> if you use SDL_VIDEO_DRIVER=wayland it craps out :p
<jdstrand> heh
<ikey> we now have specialist snapd support in LSI btw
<ikey> https://github.com/solus-project/linux-steam-integration/blob/master/src/intercept/snapd.c
<jdstrand> not surprised. some day. I mean, I'm using wayland, but it is far from perfect even for my limited use
<ikey> you can get an idea of what the rest of LSI does just looking at that
<ikey> yeah wayland has a ways to go
<mup> PR snapd#4174 closed: packaging/arch: packaging update <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4174>
<mup> PR snapd#4204 opened: store: enable "base" field from the store <Created by mvo5> <https://github.com/snapcore/snapd/pull/4204>
<sslb> I'm having an issue with all snaps on my system - rocketchat-server.rocketchat-mongo[1086]: cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied
<sslb> When trying to run the "hello-world" snap it is giving me the same error
<sslb> Running everything as root
<mup> PR snapcraft#1723 closed: sources: workaround for ZipFile.extractall not preserving permissions <Created by mariogrip> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1723>
<zyga-ubuntu> re
<zyga-ubuntu> mvo: I noticed you are still working, how can I help?
<ikey> jdstrand, i decided to be "responsible" (ew) and create a forum topic about the controller thing per your suggest
<ikey> (obviously doesn't demand immediate attn, EOW and all that)
 * ikey leaves the channel with a tune to start the weekend to
<ikey> https://www.youtube.com/watch?v=YR5ApYxkU-U
<elopio> sergiusens: back
<sergiusens> elopio going for a walk now, in an hour?
<elopio> sergiusens: I'll be here.
<sergiusens> elopio let's do it now; my family gets home soon at it is a lot louder
<sergiusens> walk canceled
<mup> PR snapcraft#1645 closed: ruby plugin: new stable release 2.4.2 <enhancement> <Created by nathanhaines> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1645>
<ikey> ok this is mighty interesting
<ikey> i can "sorta" get steam client working with strict confinement
<zyga-ubuntu> ikey: yeah?
<ikey> https://hastebin.com/gofometume.vbs
<zyga-ubuntu> ikey: (disclaimer) I'm a bit drained and I plan to debug 14.04 issues early next week but I can look at steam and definitely mvo and me can help with base snaps
<mup> Bug #14: There is no link to the bugtrackers config page <iso-testing> <lp-bugs> <Launchpad itself:Fix Released> <https://launchpad.net/bugs/14>
<zyga-ubuntu> what is that sysfs resource thing?
<zyga-ubuntu> pcilib: Cannot open /sys/bus/pci/devices/0000:00:1f.3/resource: Permission denied
<mup> PR snapcraft#1530 closed: tests: share the cache dir in the integration suite <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1530>
<ikey> this is steam tryna find pci devices
<ikey> i.e. GPUs
<zyga-ubuntu> aah
<zyga-ubuntu> I see
<zyga-ubuntu> that should be ok, it should get access to gpus but not to random stuff
<zyga-ubuntu> unless it breaks it :)
<ikey> yea
<ikey> we'll find out
<ikey> but
<ikey> but
<ikey> its only breaking parts of the client
<ikey> so the web portion is bork obviously
<ikey> but ill need to consult other cef/chromium snaps to see how they do it
<ikey> games *work*
<zyga-ubuntu> :)
<zyga-ubuntu> I think chromium sandbox is the thing
<ikey> yea
<jdstrand> ikey: thanks!
<zyga-ubuntu> it requires privilege to setup
<ikey> and i think im missing XDG crap
<zyga-ubuntu> hey jdstrand :)
<ikey> but looky https://ibin.co/3gqknFqXOwQo.png
<zyga-ubuntu> xdg crap?
<ikey> yeah XDG vars
<ikey> because "/u1000-" path
<zyga-ubuntu> aha
<ikey> but hey i mean this is mahusive progress
<ikey> we know we *can* have strict confinement steam
<ikey> which makes me vury happy because outdated libs that LSI mightn't catch
<zyga-ubuntu> ikey: I think it's very very desirable
<zyga-ubuntu> especially for for-profit random binary outdated libs
<ikey> yeah
<ikey> well LSI actually does some utter voodoo to alleviate that
<ikey> we ban vendored ssl, curl, curl-gnutls, etc
<ikey> games just can't use them
<ikey> and even for games now using libressl, we have a special shim package and LSI redirects linking to libssl-libressl.so, libcrypto-libressl.so, etc
<ikey> so if they're using libs we don't yet handle, we actually forcibly break them
<zyga-ubuntu> yeah but "mr spongebob and adventures in lalaland can spy on $HOME
<ikey> until we have a rule to handle their security libs
<ikey> true
<ikey> or a game could capture credentials
<ikey> etc
<zyga-ubuntu> it's a process but getting steam inside the sandbox is a big step in the right direction
<ikey> yeah
<ikey> this way we dont need to convince valve to sandbox games or use snaps for games
<ikey> we snap the entire execution environment and all children
<ikey> so they don't do anything but everyone profits
<ikey> (except me. this shit costs a lot of money)
 * zyga-ubuntu hugs ikey :)
<zyga-ubuntu> I wish gog were a bit more serious about their dosbox games on linux
<zyga-ubuntu> but I guess ENOMARKET
<ikey> yea
<zyga-ubuntu> well, little by little
<ikey> well, im quite happy with the progress made on this whole steam thing in the last few days
<ikey> my apologies for being stressy about the whole zenity thing :p
<ikey> ive got some minor startup bugs to alleviate too like its reliance on zenity + lsb_release
<ikey> but i can have modified versions of both in the snap
<ikey> so that they don't try to access /etc/lsb_release
<zyga-ubuntu> ikey: no apologies necessary
<zyga-ubuntu> ikey: thank you for trusting us with snaps and pushing forward :)
<ikey> well i figured it was high time i stopped talking about it and actually did it :D
<ikey> btw posted to https://plus.google.com/+Solus-Project/posts/NUChGnTk29M if you wanna social medias it or anything
<ikey> re the confinement
<jdstrand> roadmr: hi! can you sync r939 of the review tools?
<zyga-ubuntu> ikey: oh :)
<zyga-ubuntu> ikey: shared :)
<mup> PR snapd#4205 opened: add spread test for allocating TUN/TAP devices with network-control <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4205>
<ikey> ta :D
<zyga-ubuntu> ikey: also on twitter
<zyga-ubuntu> jdstrand: reviewing
<zyga-ubuntu> done
<zyga-ubuntu> jdstrand: sorry for the nits, I can address those if you want me to
<jdstrand> I can do it
<zyga-ubuntu> jdstrand: this is not super important in small scripts but I try to encourage everything to pass mypy strict validation
 * zyga-ubuntu reads https://lwn.net/Articles/738694/
<jdstrand> mypy? I do use pyflakes3 and pep8
<zyga-ubuntu> jdstrand: I find them orthogonal in many ways
<zyga-ubuntu> jdstrand: mypy is great at giving python a static language feeling
<zyga-ubuntu> with that rarely running else statement also being type checked
<ikey> zyga-ubuntu, ta :)
<ikey> oh clever tweet too
<zyga-ubuntu> (especially for things that are small and not tested other than the hard way :)
<zyga-ubuntu> ikey: clickbait at its best
<ikey> love it
 * jdstrand doesn't usually like tracecbacks for error output, but rolls with SystemExit
<zyga-ubuntu> jdstrand: oh, system exit doesnt traceback
<zyga-ubuntu> AFAIR
 * zyga-ubuntu checks
<zyga-ubuntu> yep
<zyga-ubuntu> no TB
<nacc> https://docs.python.org/3.6/library/exceptions.html#SystemExit
<nacc> specifically mentioned in the docs :)
<zyga-ubuntu> nice
<jdstrand> it did here with:
<jdstrand> except PermissionError as e:
<jdstrand>     raise SystemExit(e)
<jdstrand> you recommended 'raise SystemExit(...)'
 * zyga-ubuntu looks
<nacc> jdstrand: in the docs
<nacc> if it has another type (such as a string), the objectâs value is printed and the exit status is one.
<nacc> so i thikn it's printing hte exception object
<zyga-ubuntu> jdstrand: do you see a traceback?
<nacc> imo, you want 'raise SystemExit from e'
<jdstrand> yes
<jdstrand> http://paste.ubuntu.com/25934287/
<zyga-ubuntu> I hmm
<zyga-ubuntu> zyga@fyke:~$ cat foo.py
<zyga-ubuntu> raise SystemExit(ValueError("omg"))
<zyga-ubuntu> zyga@fyke:~$ python3 foo.py
<zyga-ubuntu> omg
<nacc> that's not from the raise, though
<nacc> (afaict)
 * nacc doens't know the code he's looking at, admittedly :)
<jdstrand> you're right. I didn't catch this one
<jdstrand> nm
<zyga-ubuntu> could that be contextlib.contextmanager
<jdstrand> no
<nacc> jdstrand: ah ok
<jdstrand> it is fcntl.ioctl
<nacc> jdstrand: yeah it just looks like an unhandled PermissionError
<zyga-ubuntu> funky :)
<zyga-ubuntu> jdstrand: in my spare time I used to love adding bindings go glibc
<jdstrand> what I am saying is that I thought that the raise SystemExit() caused it. it did not. it was actually an unhandled PermissionError
<zyga-ubuntu> to expose each interesting bit in python
<zyga-ubuntu> jdstrand: except Exception: raise ?
<zyga-ubuntu> jdstrand: isn't that a no-op really?
<zyga-ubuntu> jdstrand: valid_device_name is not annotated
<jdstrand> well, it isn't a no-op, but it isn't strictly required, sure
<zyga-ubuntu> jdstrand: I mean, in absence of this code we raise anyway
<zyga-ubuntu> jdstrand: so it seems there's no way to observe that this code is or isn't there
<zyga-ubuntu> (am I missing something?)
<jdstrand> zyga-ubuntu: that's what I meant. I'll just remove it
<jdstrand> zyga-ubuntu: if a function returns bool, what should I use in the annotation?
<zyga-ubuntu> (nitpick) closing_fd could be annotated as (closing_fd(fd: int) -> Iterable[int]
<zyga-ubuntu> -> bool
<jdstrand> you are nitpicking your nitpick now :P
<zyga-ubuntu> jdstrand: I just realized that :)
<zyga-ubuntu> hehe
<zyga-ubuntu> must be Friday
<jdstrand> ameError: name 'Iterable' is not defined
<zyga-ubuntu> from typing import Iterable
<zyga-ubuntu> it's a part of stdlib now
<jdstrand> what do I need to import for that?
<jdstrand> ok
<zyga-ubuntu> https://twitter.com/michaelklishin/status/929096325056081920
<jdstrand> heh
<roadmr> jdstrand: hi! sure, I'll put that in the pipeline
<gps1539> Maybe hard to ask for help over irc, but here goes.
<gps1539> I have a topic on https://forum.snapcraft.io/t/how-to-call-dependencies-in-snapcraft-yaml/2726/9
<sergiusens> zyga-ubuntu I started using mypy last week myself; best next thing to not being able to compile
<zyga-ubuntu> sergiusens: I agree :)
<gps1539> but it got flagged when I posted my yaml file and setup.py
<zyga-ubuntu> sergiusens: it's worth tracking upstream releases
<gps1539> where can I go for help>
<zyga-ubuntu> sergiusens: follow jukka on twitter
<sergiusens> gps1539 look in the prime directory; most likely it is in bin/treepass
<gps1539> grep -r trespass come up blank, nothing under prime
<ikey> heh figured out my ugly zenity issue
<ikey> convert the build to gresource..
<gps1539> can folks see the topic on the forum? I can not so not sure if it got pulled
<gps1539> pip install trespass works fine although it installs to /usr/local/bin/trespass and not /usr/bin/trespass (which is does on Arch)
<gps1539> Any clues to what I'm missing in my yaml
<sergiusens> that was a short stay, oh well
<elopio> snappy-m-o autopkgtest 1657 xenial:armhf
<snappy-m-o> elopio: I've just triggered your test.
<elopio> snappy-m-o autopkgtest 1716 xenial:armhf
<snappy-m-o> elopio: I've just triggered your test.
#snappy 2017-11-11
<elopio> snappy-m-o autopkgtest 1717 xenial:armhf
<snappy-m-o> elopio: I've just triggered your test.
<elopio> snappy-m-o autopkgtest 1719 xenial:armhf
<snappy-m-o> elopio: I've just triggered your test.
<ikey> so i can't actually upload a snap.
<ikey> snap store rejects base snaps
<ikey> kinda cranky.
<pedronis> ikey: afaik  it doesn't reject them, but they need a manual review (mostly because it's an in-progress, experimental feature)
<ikey> pedronis, oh it sent an automated rejection
<ikey> but i get the whole manual review thing fwiw
<ikey> ill go this route once i have vulkan fixed
<mup> PR snapcraft#1716 closed: tests: split the integration autopkgtests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1716>
<elopio> snappy-m-o autopkgtest 1657 xenial:armhf
<snappy-m-o> elopio: I've just triggered your test.
<ikey> https://media.giphy.com/media/vk7VesvyZEwuI/giphy.gif
 * ikey ducks
<mup> PR snapcraft#1727 opened: integration tests: remove ruby version <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1727>
<elopio> snappy-m-o autopkgtest 1727 xenial:armhf
<snappy-m-o> elopio: I've just triggered your test.
<elopio> ikey: this bot would have been sooo much better on telegram with gifs :)
<ikey> lol yea
<ikey> how do i get snapd to stop nuking my Exec lines in a .desktop file?
<ikey> nvm figured it out..
<ikey> soooo i had an idea about vulkan
<ikey> basically i wanna modify the mount-nvidia support to just populate "10_nvidia*.json"
<ikey> and then LSI can pick those guys up
<ikey> like so: https://github.com/solus-project/linux-steam-integration/commit/393d335af4fa275b5e87c570e64562eb019ddf6c
<ikey> testing my theory now :))
<mup> PR snapd#4206 opened: cmd/snap-confine: Make the vulkan ICD definition available <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4206>
<mup> PR snapcraft#1657 closed: tests: in autopkgtests, use a tempdir in home, not in the tmpfs <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1657>
#snappy 2017-11-12
<sergiusens> snappy-m-o autopkgtest 1727 artful:amd64
<snappy-m-o> sergiusens: I've just triggered your test.
<elopio> snappy-m-o autopkgtest 1727 xenial:armhf
<snappy-m-o> elopio: I've just triggered your test.
<sergiusens> elopio that will fail anyways, why trigger it?
<sergiusens> ikey niemeyer so the apt thing is only a problem with the snapcraft snap, works fine when running form source (tested on fedora) (cannot get solus running on boxes after the installation takes place but the symptoms should be the same)
<ikey> interesting, ty
<CoderEurope> Good evening - I would like halp creating a snap on my xubuntu 17.10 lenovo ... 1st try really.
<sergiusens> ikey funny how we can use libarchive which allows rpm sources on ubuntu/debian but cannot "import debian" to extract debs on fedora :/
<CoderEurope> wait ikey is here ?
<ikey> ya
<CoderEurope> from Solus ?
<ikey> ya
<CoderEurope> ikey - how much should your 2nd bounty be (under $20) ?
<ikey> what now
<ikey> gonna need some context
<CoderEurope> doesn't matter.
<ikey> otherwise im gonna think you want me to kill someone
<ikey> lol
<CoderEurope> Ha!
<CoderEurope> wats up with Riddell ?
<Riddell> do I keep disconnecting?
<ikey> yeah your tinterwebz are on the blink
<ikey> more likely the fault of freenode tbh though
<CoderEurope> Riddell: sup ?
<Riddell> paddleboard!
<Riddell> (this is a pune or play on words for the canoeists here)
<CoderEurope> Ha ! - only on macos my friend - back in the 1990's !
<CoderEurope> I had the same machine at school - very B&White thou.
<CoderEurope> so quassel snap ....
<CoderEurope> is this lady about ? https://phabricator.kde.org/p/scarlettclark/
<Riddell> CoderEurope: she's sgclark
<Riddell> it's a sunday though so may be away, she's usually around european work hours (despite living in the US)
<mup> PR snapd#3734 closed: packaging: add debian-unstable <Decaying> <Created by mwhudson> <Closed by mwhudson> <https://github.com/snapcore/snapd/pull/3734>
<CoderEurope> ok - lets see if she available on sundays , otherwise we'll have to do that on our own.
<Riddell> CoderEurope: we build snaps on KDE neon, and while we don't build quassel on neon (it's not a KDE project) the .deb packaging is in pkg-kde and you'd be welcome to build a Snap on Neon for it
<Riddell> snaps we build https://build.neon.kde.org/view/snap%20(build)/
<CoderEurope> Riddell: ok cool, I shall just put it in the snap store though.
<Riddell> as you wish
<CoderEurope> how do I describe the name of the snap ?
<Riddell> CoderEurope: Quassel Client ?
<Riddell> IRC frontend which connects to a Quassel Core for persistent connection
<CoderEurope> yeah, but how do I actually describe the snap in the yaml ?
<Riddell> (no laughing at whatever is up with my connection today)
<Riddell> you can see an example .yaml file here if that's what you're asking https://packaging.neon.kde.org/applications/kanagram.git/tree/?h=Neon/unstable
<CoderEurope> I am saying I dont know how to describe a yaml on the command line.
<CoderEurope> hiya robert_ancell hows the zealand ?
<CoderEurope> whao only 210-ish ppl have a first like.
<CoderEurope> https://forum.snapcraft.io/badges/11/first-like
<robert_ancell> CoderEurope: good morning!
<CoderEurope> robert_ancell: Hiya - heard the new gov. is doing well - what is she called in Nz ?
<robert_ancell> Jacina Adern is the new PM
<robert_ancell> Jacinda rather
<robert_ancell> It's easy to do well when you've just started, time will tell :)
<robert_ancell> CoderEurope: what country are you in?
<CoderEurope> ireland
<CoderEurope> looks like she doing well - I shall PM you something I found on reddit.
<robert_ancell> codereurope: didn't get any PM...
<Son_Goku> hey robert_ancell
<robert_ancell> Son_Goku: hi!
<Son_Goku> [02:44:03 PM]  <sergiusens>	ikey funny how we can use libarchive which allows rpm sources on ubuntu/debian but cannot "import debian" to extract debs on fedora :/
<Son_Goku> sergiusens: this is not true
<Son_Goku> python-debian is available in Fedora
<Son_Goku> in python2 and python3 flavors
<Son_Goku> the main problem is that python-apt is unavailable
<Son_Goku> robert_ancell: so I see you've made a couple of releases with snapd-glib?
<Son_Goku> what's up with the massive API changes?
<robert_ancell> Son_Goku: the new API?
<Son_Goku> 1.24 and 1.25 introduce a bunch of new APIs
<Son_Goku> and started deprecating some
<robert_ancell> just keeping up with snapd :)
<robert_ancell> And I did a big internal refactor as snapd-glib had grown much larger than I expected
<robert_ancell> But all the old API is still there (except for the alias API, because I'm sure no-one had ever used it)
<robert_ancell> The functions are there, but they just bail out.
<Son_Goku> also, gnome-software is now being CI'd in GNOME GitLab
<Son_Goku> and because snapd-glib is in Fedora, it's being built and tested in it :)
<CoderEurope> CI'd ? IDK what that means ?
<Son_Goku> continuously integrated
<robert_ancell> Son_Goku: awesome!
<robert_ancell> I need to enable some CI for snapd-glib
<Son_Goku> robert_ancell: now you just need to provide some tests for gnome-software to use for the snap plugin :)
<Son_Goku> no one is ever really sure when that plugin works or not
<robert_ancell> Son_Goku: there's some, but they're not great
<Son_Goku> and speaking of which, I got a weird bug forwarded to me: https://bugzilla.redhat.com/show_bug.cgi?id=1509586
<robert_ancell> Son_Goku, jibel is working on getting a student to work on some autopilot tests I hear.
<robert_ancell> Son_Goku: weird bug, I will be very happy when snapd-login-service is dead and buried...
<Son_Goku> yeah, it's super-bizarre, as I've never seen this before
<Son_Goku> I'm setting up a fresh Fedora 27 VM to test it now
<Son_Goku> robert_ancell: as an aside, I also did this: https://copr.fedorainfracloud.org/coprs/ngompa/snapcore-el7/
<Son_Goku> not quite sure how well it works, as it's a first attempt at offering snap-enabled gnome-software for CentOS 7
<robert_ancell> Son_Goku: I like the installation instructions
<Son_Goku> :D
<robert_ancell> Son_Goku: was there anything special required for CentOS?
<Son_Goku> for a while, it was basically not working
<Son_Goku> then CentOS 7 rebased to GNOME 3.22
<Son_Goku> the main problem was getting snapd built
<Son_Goku> I did decide to take a look at the commits in gnome-3-22 branch and backport all the snap-plugin related ones
<robert_ancell> I do try and backport all the snap plugin stuff to 3.22
<Son_Goku> :/
<Son_Goku> so for me, trying to install snaps through gnome-software hangs on Fedora 27
<Son_Goku> it's stuck at 0% installing
<Son_Goku> robert_ancell: I don't suppose you have an rhbz account, do you?
<robert_ancell> Son_Goku:  I think I do
<mwhudson> i wonder if snapd 2.29 works with godbus 3
<Son_Goku> mwhudson: just assume no and your life is easier
<robert_ancell> Son_Goku: yep, I do, using my gmail address
<Son_Goku> okay, cool, so that *is* you
<Son_Goku> I wasn't sure since I don't usually see things from you with an @gmail.com address
<mwhudson> um maybe i shouldn't run sbuild on 3g
<mwhudson> src/github.com/snapcore/snapd/userd/launcher.go:76:11: undefined: dbus.ErrMsgInvalidArg
<mwhudson> src/github.com/snapcore/snapd/userd/launcher.go:84:10: undefined: dbus.MakeFailedError
<mwhudson> ah well
<robert_ancell> Son_Goku: I'll download F27 and try in a VM...
<Son_Goku> robert_ancell: cool, thanks
<robert_ancell> Fedora website fail - has a banner for F27 beta but doesn't link to anything...
<robert_ancell> Son_Goku: and the download section doesn't seem to have any links to F27 - where do I find the ISO?
<Son_Goku> https://dl.fedoraproject.org/pub/alt/stage/27_RC-1.6/Workstation/x86_64/iso/
<Son_Goku> this is the build that will be released as Fedora 27 on Tuesday
<CoderEurope> ikey: liked your #48 snap post :D
<mup> PR #48: s/autopilot/autoupdate/ mostly (leave the unit files alone). Also update the documentation <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/48>
<ikey> :D
<ikey> oh should post here
<ikey> https://solus-project.com/2017/11/12/this-week-in-solus-install-48/
<ikey> Tada
<CoderEurope> ikey: Where is the github for the website at ?
<ikey> website? private
<CoderEurope> ah - cs
<ikey> its considered a branding asset and not a public thing
<CoderEurope> k
<ikey> the help-center is public though
<ikey> as it required hoomans to contribute
<CoderEurope> can I buy a solus cdvd on ebay ?
<ikey> uhm
<CoderEurope> A dvd
<ikey> probably not?
 * CoderEurope only installs from duvd
<ikey> o
 * ikey didn't know they still made those
<ikey> xD
<CoderEurope> oh exactly
<CoderEurope> you need an ebay shop, eally - to operate over here :)
 * CoderEurope wondes if ikey is on ebay ?
<ikey> i mean im not saying i wouldnt sell myself
<ikey> yknow, friday nights n all
<ikey> but im not on ebay
<CoderEurope> troo https://www.ebay.co.uk/usr/ikey?_trksid=p2047675.l2559
<CoderEurope> I'd set up a shop for ya ?!!
<CoderEurope> if you give us the Â£5.
<ikey> eh yeah no you're grand
<ikey> lol
<CoderEurope> okay - missed oppourtunity though - its 10 o'clock !
<ikey> might have a â¬5 sat here somewhere but you may come get it yourself
<ikey> im not going anywhere now, its cold
<ikey> lol
 * CoderEurope loooks at the studio door .. its not movin` :D
<CoderEurope> 7.2 raqqi earthquake - where do I go for discussion on ubuntu ?
<Son_Goku> ikey: super-cold here too
 * Son_Goku is bundled up in his bed
<ikey> yea i should probably close the window
<Son_Goku> nuuuuu...
 * ikey blinks at his PM
#snappy 2018-11-05
<amurray> so am sure I am doing something daft but am trying to add autostart support to my snap and snapcraft is complaining that 'autostart' is not a valid property
<amurray> (using snapcraft 2.43.1+18.04)
<amurray> Issues while validating snapcraft.yaml: The 'apps/indicator-sensors' property does not match the required schema: Additional properties are not allowed ('autostart' was unexpected)
<amurray> ok so I guess this is some distinction between snapcraft.yaml and snap.yaml - how do I add autostart support to my snapcraft.yaml ?
<mborzecki> morning
<mvo> hey mborzecki - good morning
<mborzecki> mvo: hey, aything interesting happened on thu/fri?
<mvo> mborzecki: I took those days off so I don't really know. a bit of debugging on vscode and why it was relatively slow to start, turned out to be a fontconfig issue
<mvo> i.e. incompatible cache formats
<mvo> between library versions
<mborzecki> mvo: mhm, saw that, i recall this being discussed before 18.04 as a potential issue, but it was never in the context of performance
<amurray> fyi - I figured it out - need to use passthrough to be able to specify autostart in snapcraft.yaml
<zyga> good morning
<mvo> zyga: hey, good morning
<mborzecki> zyga: hey
<zyga> hey :)
<zyga> one other interesting thing that happened yesterday
<zyga> systemd maintainer produced base snaps for fedora29 :)
<zyga> using parts of systemd
<zyga> :-)
<mborzecki> mkosi?
<zyga> yes
<zyga> it works, I will try to upload it to the store
<zyga> last time I tried the store chocked on it
<zyga> we also found three bugs:
<zyga> I'll file them now
<mborzecki> mvo: can you look at the latest changes in https://github.com/snapcore/snapd/pull/6039 ?
<mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<zyga> hmm, no mup for launchpad bugs?
<zyga> I filed: https://bugs.launchpad.net/snapd/+bug/1801663 https://bugs.launchpad.net/snapd/+bug/1801664 https://bugs.launchpad.net/snapd/+bug/1801665
<mvo> mborzecki: sure, let me do this now
<mup> Bug #1801663: Cannot find snap-exec when fedora29 is the only installed base <snapd:Confirmed> <https://launchpad.net/bugs/1801663>
<mup> Bug #1801664: Snapd fails to work in pure v2 cgroup system <snapd:Confirmed> <https://launchpad.net/bugs/1801664>
<mup> Bug #1801665: Base snaps are not validated to be devoid of apps <snapd:Confirmed> <https://launchpad.net/bugs/1801665>
<mup> PR snapd#6078 closed: ifacestate/ifacemgr: don't reload hotplug-gone connections on startup <Hotplug ð> <Simple ð> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6078>
<mup> PR snapd#6081 closed: overlord/ifacestate: mark connections disconnected by hotplug with hotplug-gone <Hotplug ð> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6081>
<mup> PR snapd#6092 opened:  tests,store,daemon: ensure proxy settings are honored in auth/userinfo too (2.36) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6092>
<mborzecki> looks like #5897 is almost ripe for landing, i'll push some updates there and it should be good to go
<mup> PR #5897: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
<mwhudson> zyga: do you know if anyone still uses / cares for plainbox?
<zyga> no, it's been fused back into checkbox
<zyga> (+1 to kill)
<mwhudson> zyga: would you be able to file a bug asking for removal?
<mwhudson> (obviously i can too but it might look better coming from you!)
<zyga> I can try, what is the three-letter-acronym for that?
<mwhudson> zyga: https://bugs.launchpad.net/ubuntu/+source/plainbox/+filebug
<mwhudson> zyga: there is no three letter acronym for ubuntu :)
<mwhudson> (it would be RoM == request of maintainer in debian i think)
<zyga> oh, just on launchpad?
<zyga> I was thinking in debian
<mvo> 6070 needs a secnd review (should be simple)
<mwhudson> zyga: in that case https://wiki.debian.org/ftpmaster_Removals#How_to_request_removal
<mwhudson> zyga: but a launchpad bug would be great in addition
<mwhudson> zyga: (it fails tests with python 3.7)
<zyga> mborzecki: I'm double checking with CE but I suspect they don't need it anymore
<zyga> they moved on to snaps now
<mwhudson> zyga: hmm there are some reverse-depends
<mwhudson> zyga: checkbox-ng, plainbox-provider-checkbox, plainbox-provider-resource-generic
<zyga> yeah
<zyga> but all of those are equally dead as debian packages
<mvo> mborzecki: 6039 looks good, thanks for all the updates you did to this one!
<mborzecki> mvo: np, heppy to move things forwards
<mup> PR snapd#5996 closed: [RFC] daemon: support `snap logs snapd` to get snapd logs <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5996>
<pstolowski> morning
<mvo> hey pstolowski - good morning
<mvo> fwiw, I really love the new distro name
<pstolowski> indeed :)
<mborzecki> disco dingo?
<mvo> yeah
<mborzecki> zyga: i've updated #5897, we can either close it or land it, i still think the interface is useful, defining gpios as keys is super convenient and imo people use it (i used it for a couple of custom devices)
<mup> PR #5897: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
<zyga> mborzecki: yeah, I think we want jdstrand to review it and kola to ack that it still works on their hardware
<zyga> thank you for refreshing it
<kyrofa> zyga, I just a got a bug report from someone who's snap stopped working. Logs are filled with "cannot perform operation: mount --bind /snap/core/current//etc/alternatives /tmp/snap.rootfs_PA4OiD/etc/alternatives: No such file or directory"
<kyrofa> Any ideas?
<zyga> kyrofa: yes, apparently there are no /etc/alternatives on the filesystem
<zyga> unless we yanked them from core itself
<zyga> and we indeed did just that
<zyga> hmmm
<zyga> kyrofa: what is the snap version?
<kyrofa> zyga, I'm checking. Stable hasn't updated though, right?
<kyrofa> Wonder if they're following a different channel
<zyga> stable is 2.35.5 which looks slightly updated
<zyga> but not 2.36
<kyrofa> When you say you did indeed just do that, what were you referring to?
<zyga> I mean that on my system /etc/alternatives is no longer in core
<zyga> it looks like old snap-confine that is not matching the current core
<kyrofa> Doesn't that get re-exec'd?
<zyga> in a way, we run the right snap-confine directly
<mup> PR snapd#6067 closed: tests/main/snap-service-after-before-install: verify after/before in snap install <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6067>
<mborzecki> what shall we do about #5946 ?
<mup> PR #5946: cmd/snap: unhide --name parameter to snap install, tweak help message <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5946>
<mup> PR snapd#6093 opened: daemon: spool sideloaded snap into blob dir <Created by chipaca> <https://github.com/snapcore/snapd/pull/6093>
<Chipaca> good morning peeps
<pstolowski> mornings Chipaca !
<Chipaca> i woke up early and got caught up in some snapd work instead of having breakfast
<Chipaca> so now i'm going to go fix that, brb :-)
<mvo> hey Chipaca !
<Chipaca> mvo: o/ !
<Chipaca> mvo: how've you been?
<mvo> Chipaca: very well, thank you! nice and relaxing long weekend, just some debugging around fontconfig issues with snaps mixed in but beside this all great
<mvo> Chipaca: and you?
<Chipaca> mvo: no fontconfig debugging here
<Chipaca> mvo: but, wondering if we can't expose a "this snap uses fontconfig x.y.z" flag somewhere
<Chipaca> mvo: also wondering about per-user hooks
<mvo> Chipaca: yeah, I think there are some things we don't fully understand yet. for example on 18.04 I get a ~/.cache/fontconfig dir populated when I run with an older fontconfig. but that does not happen with the same snap on 18.10
<mvo> Chipaca: yeah, per-user cache with per-user hook would solve this
<kyrofa> zyga, look at that `snap version`: https://github.com/nextcloud/nextcloud-snap/issues/776#issuecomment-435803559
<kyrofa> How is that possible?
<mvo> Chipaca: but some work ahead, also versionizing the font-config cache files
<Chipaca> kyrofa: no re-exec
<mvo> Chipaca: if they are not already, the trouble is we don't really know (yet). but maybe james hensdrige knows more or someone from the desktop team
<Chipaca> here's hoping the solution or workaround isn't  ubuntu-centric
<Chipaca> zyga: btw you semi-reviewed #6065, before I went and split it as you requested. Could use another semi review :-D
<mup> PR #6065: cmd: make coreSupportsReExec faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6065>
<kyrofa> Chipaca, how would that get disabled in xenial?
<kyrofa> Doesn't that require setting an environment variable in the systemd unit?
<Chipaca> kyrofa: pseudo-user on a pseudo-terminal
<kyrofa> Chipaca, that shouldn't effect which snapd is actually running then, right?
<zyga> kyrofa: looking
<Chipaca> kyrofa: that was a joke :-) AFAIK 2.20 already re-exec'ed, on ubuntu, so having it not do so requires user (sysadmin) action
<zyga> Chipaca: enqueued
<Chipaca> 2.10ish was when we flipped that particular switch iirc
<Chipaca> zyga: enthanked
<kyrofa> Chipaca, oh thank goodness. I respect you too much, I thought this was technology with which I was very much unfamiliar :P
<Chipaca> i should shave my beard and start a youtube channel, to get the respect dialed back a bit
<kyrofa> Agreed
<mborzecki> Chipaca: do you have any suggestions about https://github.com/snapcore/snapd/pull/5946 ?
<mup> PR #5946: cmd/snap: unhide --name parameter to snap install, tweak help message <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5946>
<Chipaca> mborzecki: what about?
<Chipaca> mborzecki: degville suggested things there already :-)
<Chipaca> mborzecki: and you have two +1's
<mborzecki> Chipaca: thought you meant that we should add more changes
<mborzecki> Chipaca: which in fact i'll do just now, the last paragraph is a bit off
<Chipaca> heh
<mborzecki> last paragraph of the help message
<Chipaca> mborzecki: ok
<Chipaca> mborzecki: _the_ instance name?
<mborzecki> heh, let me force push that
<Chipaca> mborzecki: did you implement graham's suggestion? i can't see it but then i'm sleepy
<mborzecki> Chipaca: yup, both of them
<Chipaca> k
<kyrofa> zyga, any thoughts on that?
<zyga> kyrofa: on the version?
<kyrofa> Yeah
<zyga> no, no idea, logs would confirm why snapd doesn't reexec
<zyga> if you can collect logs from snapd.service it would tell us
<Chipaca> brb, reboot
<kyrofa> zyga, alright, requested
 * cachio afk
<ackk> hi, I'm having an issue with bash completion in a (classic) snap. it doesn't seem to work, but if I snap run --shell and source the completion file, it does work there. is there perhaps something different in how snapd handles that?
<Chipaca> ackk: https://forum.snapcraft.io/t/debugging-tab-completion/4198
<ackk> Chipaca, thanks
<sparkiegeek> ackk: can you share your snapcraft.yaml, and `snap version`?
<sparkiegeek> well, Chipaca's link is better :)
<Chipaca> :-D
<ackk> sparkiegeek, https://git.launchpad.net/~sshoot/sshoot/+git/packaging/tree/snap/snapcraft.yaml
<Chipaca> ackk: please let me know how the debugging goes (specifically: at which step of the debugging things break down)
<sparkiegeek> ackk: sshoot-completion != shell-completion
<sparkiegeek> ackk: you have the former defined in the app, and the latter in your part
<ackk> sparkiegeek, shell-completion is a dir, in which sits sshoot which is copied as sshoot-completion
<ackk> Chipaca, should I run the "complete -p" inside the snap run or from my system?
<Chipaca> ackk: no
<Chipaca> ackk: in my defence it does tell you to exit the snap run --shell :-)
<ackk> Chipaca, sorry, missed it :)
<ackk> Chipaca, so, the -x shows something different: https://paste.ubuntu.com/p/h2TkVGxprm/
<Chipaca> ackk: that looks almost exactly the same
<ackk> Chipaca, yeah but see it fails?
<Chipaca> ah, yes
<ackk> Chipaca, there seems to be an error mesage like "cannot..." being parsed
<Chipaca> ackk: so go on to the next step :-)
<Chipaca> i'm starting to guess where the issue is
<Chipaca> but go ahead
<ackk> Chipaca, so if I snap run and source the bash completion it doesn't work
<ackk> Chipaca, what do you think the issue is?
<Chipaca> ackk: looking at the completer, I guessed wrong
<Chipaca> :-)
<ackk> Chipaca, fwiw the snap run --command=complete returns "default"
<Chipaca> ackk: when you say that sourcing the bash completion doesn't work, what do you mean?
<ackk> Chipaca, oh, wait
<ackk> Chipaca, n/m, so step 5 works
<ackk> Chipaca, so everything works, except it doesn't :)
<Chipaca> ackk: ok, let's rewind a bit
<Chipaca> ackk: what should it do, that it isn't doing?
<Chipaca> what should it complete with?
<ackk> Chipaca, the command options
<Chipaca> ackk: but it completes with filenames, here
<Chipaca> also
<Chipaca> also
<ackk> right, because it's falling back to the default completer I guess
<Chipaca> bah, maybe i'm looking at an old version :-)
<Chipaca> yes probably
<Chipaca> ackk: what do you get when you do the 'snap run --command=complete yadda yadda' step?
<ackk> Chipaca, https://paste.ubuntu.com/p/NS3m5St8mz/
<Chipaca> ackk: that's the non-snapped one I presume
<ackk> Chipaca, no, it's the snap, from inside a snap run, as per step 5
<Chipaca> ackk: what's the output on step 4?
<ackk> Chipaca, https://paste.ubuntu.com/p/7gbVwVM7Sv/
<ackk> (I used the number from the bash -x from the step before
<ackk> Chipaca, I wonder if something in my bash setup is messing the compelter up
<Chipaca> hm, I don't get that
<ackk> although that has never happened for any other completion
<Chipaca> but I've installed the one in stable
<ackk> oh?
<Chipaca> which might be different
<ackk> Chipaca, they're the same
<ackk> Chipaca, 72?
<Chipaca> ackk: https://pastebin.ubuntu.com/p/gFD7KsRVpR/
<Chipaca> ackk: and then all the files
<ackk> Chipaca, which version of the snap do you have?
<Chipaca> ackk: revision 72
<Chipaca> ackk: also, also:
<Chipaca> ~$ sshoot
<popey> cjwatson: is there a timeline on when the "('Connection aborted.', gaierror(-3, 'Temporary failure in name resolution')) " store upload fails might be fixed?
<Chipaca> /snap/sshoot/72/command-sshoot.wrapper: 2: exec: /snap/sshoot/72/usr/bin/python3: not found
<popey> https://launchpad.net/~build.snapcraft.io/+snap/b2218f767981315ff64384e4f403d972-xenial/+build/370290 for example
<ackk> Chipaca, https://paste.ubuntu.com/p/bVfBTFdVDW/
<Chipaca> ackk: I'm not sure what you're showing me :-)
<Chipaca> ackk: this is a classic snap, yes?
<ackk> Chipaca, yes
<ackk> this is really weird
<Chipaca> no not that weird
<Chipaca> just classic weird
<mborzecki> opened a topic with cross-snap service ordering proposal https://forum.snapcraft.io/t/cross-snap-service-ordering/8319 feel free to comment
<Chipaca> ackk: do this
<ackk> Chipaca, does "sshoot list" work for you?
<Chipaca> ackk: get into 'snap run --shell'
<Chipaca> ackk: i mean 'snap run --shell sshoot'
<ackk> Chipaca, and then?
<Chipaca> ackk: /usr/bin/python3
<Chipaca> ackk: and then
<Chipaca> ackk: import argcomplete
<Chipaca> ackk: and them
<ackk> not found
<ackk> but why is it trying /usr/bin/python3
<Chipaca> ackk: /usr/bin/env python3
<Chipaca> ackk: unless your wrapper is rewriting PATH?
<ackk> Chipaca, so I need to put $SNAP/usr/bin in path first
 * Chipaca looks
<ackk> no it doesn't
<Chipaca> ackk: also, the python3 you're shipping doesn't work here
<ackk> what?
<Chipaca> ackk: bah, agian let me look at the wrapper
<Chipaca> ackk: so, the wrapper should be fine on the path front (it execs $SNAP/yadda), but the completion script needs the same treatment
<Chipaca> ackk: or tweaking the path
<Chipaca> ackk: but
<ackk> Chipaca, ok, I'll just include a copy of that script in the snap, it's one line anyway :)
<Chipaca> /snap/sshoot/72$ ./usr/bin/python3
<Chipaca> bash: ./usr/bin/python3: No such file or directory
<ackk> Chipaca, yeah it's just "python" I think
<Chipaca> ackk: nope, it's python3, a symlink to python3.6
<Chipaca> ackk: but the libraries are messed up
<ackk> $ ./usr/bin/python3 -c "print('hello')"
<ackk> hello
<ackk> Chipaca, ^
<ackk> Chipaca, are you running it inside the snap run?
<Chipaca> ackk: you're on 18.04, running a core18 snap, i presume
<ackk> Chipaca, yeah
<Chipaca> ackk: yeah
<Chipaca> ackk: that doesn't exactly test the libraries are being picked up from where you expect them to be ;-)
<ackk> I see
<ackk> sigh
<ackk> ok, I'll take a look, thanks for the help Chipaca
<Chipaca> ackk: fun
<mup> PR snapd#6091 closed: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6091>
<ackk> yeah...
<mborzecki> mvo: can you cherry-pick that PR to 2.36? ^^
<Chipaca> ackk: classic is tricky this way (and others, but this way)
<Chipaca> ackk: good luck
<ackk> Chipaca, thanks :)
<popey> Hm, is there some way to re-run console conf by removing some file on the sd card?
<mvo> mborzecki: sure, doing now
<mborzecki> mvo: ta
<popey> (I have moved my pi from home to office, and need to re-run console conf to connect to wifi)
<ogra> popey, yes, there is a file ... one sec
 * Chipaca afk
<mvo> mborzecki: thank you! its in :)
<popey> ogra: thanks
<ogra> popey, /writable/system-data/var/lib/console-conf/complete
<popey> $ sudo mount /dev/mmcblk0p2 /mnt/writable/
<popey> mount: /mnt/writable: cannot mount /dev/mmcblk0p2 read-only.
<popey> :(
<ogra> weird ... anything in dmesg ?
<popey> [10917.675750] EXT4-fs (mmcblk0p2): write access unavailable, cannot proceed (try mounting with noload)
<popey> huh, not sen that before
<popey> ahh, [10917.675746] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
<ogra> wants an fsck it seems
<popey> Disk write-protected; use the -n option to do a read-only
<popey> stupid sd card adapter :)
<ogra> yeah
<cjwatson> popey: Not at this point
<cjwatson> It's very very weird and has resisted understanding so far
<popey> cjwatson: ok, so just keep re-triggering builds until it works?
<cjwatson> I don't have a better offer at the moment
<popey> ogra: /writable/system-data/var/lib/console-conf/complete doesn't exist
<cjwatson> But do tell us when it happens because it generally means we need to restart a thing
<popey> ok
<cjwatson> Once it's in that state there's a 1/3 chance of any given upload failing that way, until we restart it
<ogra> popey, hmm, then console-conf should run ... unless something changed ... in which case mwhudson is your man i think
<popey> cjwatson: i re-triggered the one above
<popey> ogra: ok
<popey> ogra: might start a thread on the forum, because this is something undocumented afaict
<cjwatson> I've requested that the cursed worker be killed
<popey> cjwatson: thanks
<popey> file:///home/alan/Pictures/Screenshot_20181105_113742.png https://usercontent.irccloud-cdn.com/file/1JYDSny9/aargh%20%3A)
<popey> ogra: ^
<popey> using an hdmi capture card as I don't have a monitor
<ogra> popey, modern art ?
<popey> thats - i assume - some message about a lack of ip address
<popey> I guess I need an ethernet cable
<cjwatson> popey: Should be happier now, at least for the time being
<popey> Ubuntu Core 16 on <no ip address> (ttyS0)
<popey> You cannot log in until the system has an IP address.
<popey> (Is there supposed to be a DHCP server running on your network?)
<popey> (is what it says)
<ogra> popey, well, console-conf should override this if the completion file is missing, not sure why you dont have it
<popey> I'll start a thread
<mup> PR snapd#6092 closed:  tests,store,daemon: ensure proxy settings are honored in auth/userinfo too (2.36) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6092>
<zyga> [   52s] snapd-2.33.1/gopath/src/github.com/snapcore/snapd/overlord/snapstate/autorefresh.go:182: Noticef format %s has arg int(maxPostponement.Hours() / 24) of wrong type int
<mborzecki> zyga: wasn't that fixed in master already?
<zyga> this is 2.33.1 :)
<mborzecki> oh
<zyga> one more failiure https://www.irccloud.com/pastebin/np5xC9Mc/
<zyga> perhaps test keys?
<zyga> but on the upsdie
<ogra> stop playing with that old cruft :P
<zyga> no more golang-packaging macros
<zyga> logs are short
<zyga> code is simple
<mborzecki> zyga: opensuse?
<zyga> errors make sense
<zyga> yes, wrapping up that work
<mborzecki> that looks like a piece from rpmbuild log
<zyga> yes
<zyga> I rewrote parts of the packaging to drop the golang-packaging macros
<zyga> to unbreak our builds
<zyga> on the upside master is green on suse now
<mborzecki> hmm might have found a bug in generated service wrappers with Before=
<zyga> oh?
<mborzecki> something for .1 i belive
<mborzecki> damn, go templatles are both fun to use and really frustrating
<Chipaca> mborzecki: funstration is best stration
<Chipaca> I mean, it beats defenestration at least
<mborzecki> need to look that up :)
<mborzecki> 'Defenestration is the act of throwing someone or something out of a window'
<mborzecki> wonder why 'someone' comes first
<zyga> mborzecki: wow really?
<zyga> I mean, school has burned that word into my head
<Chipaca> mborzecki: because it's not usually used literally
<zyga> I have 2.36 packaged for suse, if you want to review mborzecki
<zyga> I'll figure out how to create a diff in osc
<mborzecki> isn't there osc diff? :)
<zyga> I mean I want to push this
<zyga> but I started in system:snappy
<zyga> osc just sucks for workflow
<zyga> and I already have "a branch" so I cannot branch again
<mborzecki> just imaging it's svn
<mborzecki> right, so when there's more than one serivce in before: ..., we generate Before=.. without whitespace separating service names
<zyga>  oops
<mborzecki> mvo: ^^ i'll push a PR for this and we'll need to cherry pick it to 2.36
<zyga> Chipaca: hmm
<zyga> around?
<Chipaca> zyga: yes
<Chipaca> zyga: standup
<zyga> oh
<zyga> sure
<Son_Goku> mborzecki, unfortunately, obs vcs is derived from svn
<Son_Goku> zyga, you can branch again as much as you want, you just need a different branch project to use
<Son_Goku> zyga, you can also use copr to build for opensuse if you'd prefer git-ish workflows :)
<zyga> nah, that's fine - I'll just release it on OBS now
<Son_Goku> JamieBennett, can we get RHEL 7 to wire up into spread?
<mborzecki> Son_Goku: centos is wip in my branch, but we hit some problems with MNT_DETACH and an old-ish kernel
<Son_Goku> mborzecki, if you have a Fedora system, you can trivially boot RHEL 7 using RHEL Developer licenses on your computer in a VM
<Son_Goku> using gnome boxes
<mborzecki> Son_Goku: do you know if there's any timeline for centos 7.6?
<Son_Goku> current expectation is sometime in the next 2-3 weeks
<Son_Goku> they've already started chewing through a good chunk of it since the code drop last week: https://twitter.com/JohnnyCentOS/status/1058359691628216320
<mborzecki> Son_Goku: thx
<amunizp> Hi all, any chance there are any IoT developers here?
<zyga> amunizp: probably, what do you need?
<ogra> amunizp, how about you just ask a question ? :)
<mvo> mborzecki: uh, thanks, yeah, thats a show-stopper
<amunizp> Well, the question might not be appropriate for the channel but here goes. I am looking for hands on mentors for a hackathon like event probably spring or summer 2019. The idea is to help develop IoT crowd system (size of about 4 million). The work will be paid for around 4 people managing a group of about 4 people. So my question is: what it the day rate for such a dev/hardware hacker? knowledge needed would be: is this a job for a beag
<amunizp> le bone or an FPGA device? what kind of encryption should be needed on the hardware? would it be best on the server? Can these devices consume low battery?
<amunizp> *lower battery?
<amunizp> Does that answer your question zyga and ogra ?
<ogra> amunizp, sounds like the #beagle channel might be a good fit for you (at least for the beaglebone part of the question)
<zyga> amunizp: I'll answer after a meeting I'm in
<mup> PR snapd#6094 opened: wrappers: fix generating of service units with multiple `before` dependencies <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6094>
<mborzecki> mvo: ^^
<amunizp> hi ogra, sorry my question is: Does the person I want to contract know about the different IoT hardware tech available? beagle bone vs fpga is an example.
<zyga> amunizp: I think this is not the best question for things like that
<zyga> amunizp: your question is very much dependent on the location and other parameters of the employer
<zyga> er, I mean, not the best channel for questions like that
<ogra> amunizp, the moore knowledgeable people in #bagle are definitely capable of answering that ... though you need to likely be a bit more detailed about your use case "IoT" is just a marketing buzzword ans doesnt explain what your implementation really needs
<ogra> *more ... #beagle
<ogra> (geez my typing)
<amunizp> Thanks! Location is London. I'll pop by #beagle
<mvo> mborzecki: ta!
<popey> thresh: https://github.com/snapcore/snap-store-badges :)
<kyrofa> zyga, these logs don't seem very helpful: https://github.com/nextcloud/nextcloud-snap/issues/776#issuecomment-435884175
<zyga> kyrofa: I'll check soon
<Chipaca> mborzecki: https://play.golang.org/p/Fv2i0k78LNK ?
<zyga> I need to grab some food
<Chipaca> mborzecki: is the second one not what you want?
<mborzecki> Chipaca: i want Before=one two\n
<Chipaca> mborzecki: y tho
<Chipaca> i mean i get it looks neater :-)
<mborzecki> off to pick up the kids
 * pstolowski lunches
 * cachio afk
<mup> Bug #1801735 opened: Typo in model assertions <Snappy:New> <https://launchpad.net/bugs/1801735>
<zyga> kyrofa: not much detali :/
<zyga> Do you know more about that system? Is it a core device?
<Chipaca> zyga: kyrofa: added a comment there
<kyrofa> zyga, it's 16.04, but not much more detail than that
<kyrofa> Chipaca, thanks, although now I'm worried we'll never know how the machine got into that state
<kyrofa> But I suppose unblocking is really what they want
<Chipaca> kyrofa: I'm downloading 16.04.1 to see if i can reproduce it
<Chipaca> ok so 16.04.1 shipped 2.0.10
 * Chipaca tries .2
<zyga> Thank you chipaca!
<Chipaca> we've come so far since 2.0.10
<Chipaca> it had, like, 10 commands
<Chipaca> :-)
<zyga> 10 commandments ;-)
<Chipaca> $ snap
<Chipaca> error: Please specify one command of: abort, ack, change, changes, connect, create-user, disconnect, find, help, install, interfaces, known, list, login, logout, refresh, remove, run or try
<Chipaca> zyga: kyrofa: and 16.04.2 ships 2.21
<Chipaca> zyga: kyrofa: and I can confirm it re-execs into core just fine
<zyga> So manually disabled probably
<zyga> I think there are two lessons
<zyga> One: core should âassumes: snapd2.35â
<zyga> And another, we need snap debug reexec
<kyrofa> I wonder why it would be manually disabled
<Chipaca> kyrofa: they've tinkered with the environment, obviously
<zyga> Doesnât have to be
<zyga> But probably is
<Chipaca> um
<Chipaca> those are DEBUG logs
<Chipaca> so they _have_ tinkered with the environment
<Chipaca> what i was about to say was that it wasn't too much of a stretch to think that they'd done more than just set debug :-)
<Chipaca> we can ask
<Chipaca> but see rule #1 about users
<zyga> back at the office
<ogra> seb128, yo ! ... there is a thing i noticed about the font handling in the dektop launchers ... wehn i build kiodk apps to run on ubuntu-core where there is no dekto i always have to patch the fonts.conf file to make fontconfig work at all ... (it has a hardcoded /usr/share a fonts search path), i noticed your fontconfig discussion and was wondering if that could be a hint ... afaik the desktop launcher codde ddoes not modify the in-snap fonts.conf at
<ogra> all (so shipped fonts are never in the search path)
<ogra> oh man ...
<ogra> my broken kbd really showss
<seb128> ogra, it's not the issue, but thx for pointing it out
<seb128> the cache is by dir
<seb128> if some dirs are missing it means some fonts would be missing
<seb128> but not impact the start time
<ogra> seb128, well, if you set FONTCONFIG_FILE to $SNAP/etc/fonts/fonts.conf and that only has /usr/share/fonts, it will never consider the font files in $SNAP
<ogra> but alway use the system dirs ... which go through an interface ...
<seb128> most fonts are not bundled in the snap anyway
<ogra> k
<seb128> ogra, also https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L240
<seb128>  for ((i = 0; i < ${#data_dirs_array[@]}; i++)); do
<ogra> ah, k on desktop you re-generate it anyway
<seb128> right
<ogra> yeah, then you are likely fine ... (i cant do that on core ... well i could but for no benefit since there are no fonts ...) ... anyway, was just an observation
<jdstrand> roadmr: hi! can you pull r1150?
<roadmr> jdstrand: sure thing! coming up
<jdstrand> roadmr: thanks!
<zyga> jdstrand: hello, welcome back
<jdstrand> zyga: thanks! I was actually back since last Wed :)
<zyga> I was off since Thursday
<jdstrand> heh
<jdstrand> hope you had nice time off :)
<mup> PR snapd#6095 opened: packaging/opensuse: stop using golang-packaging <Created by zyga> <https://github.com/snapcore/snapd/pull/6095>
<zyga> jdstrand: thanks, it was nice to spend more time with the family
<roadmr> jdstrand: hey a question: if I want to exempt 3 specific gadget snaps from being red-flagged/manually reviewed, they'd have to be added to redflagged_snap_types_overrides['gadget'], right? Is it OK to do so with gadget snaps that live in a brand store/
<roadmr> ?
<zyga> roadmr: hey, do you remember that bug with fedora29?
<zyga> roadmr: is there any update on that, I tried submitting it lately and it still fails on __all__
 * roadmr hides behind a bush
<jdstrand> roadmr: yes and yes. I'm right there if you want to privmsg me
<roadmr> zyga: the latest I heard, it was fixed :/ the store can remove the evil fedora 555 files, the review tools can as well, and those updates are in production
<zyga> roadmr: let me try
<roadmr> zyga: I assumed you were satisfied with it because I saw some published f29 snaps already :(
<zyga> roadmr: those were done earlier with the hack
<zyga> hey, no worries though :-)
<roadmr> zyga: oh I remember - I was supposed to push the f29 evil snap as root so snapcraft is also happy, and check what else the store says
<roadmr> fwiw the hack should only be setting squashfs-root to 755, which doesn't sound horrible, does it? I mean, in fedora, is the mode for / 555? not writable by root? who are they fooling? :)
<zyga> roadmr: yes
<zyga> [zyga@faroe ~]$ ls -ld /
<zyga> dr-xr-xr-x. 18 root root 4096 10-19 11:58 /
<roadmr> zyga: right... ok, that's probably why squashfs-root itself has that weird mode
<zyga> yeah
<roadmr> zyga: I'll have another look in a bit
<zyga> roadmr: thanks!
<zyga> there's going to be a new build soon
<zyga> now based on mkosi
<zyga> but that should not change this
<zyga> Wimpress: FYI, I'm prepping for a 2.36 across opensuse
<zyga> it fixes many known issues
<zyga> including unbreaking all of tumbleweed snap support
<Chipaca> pstolowski: do we have 'snapctl status'?
<zyga> cachio: hey
<zyga> error: cannot pack "/home/gopath/src/github.com/snapcore/snapd/tests/lib/snaps/basic-desktop": write /tmp/.snap-pack-exclude-116402540: no space left on device
<zyga> have you seen any issues with insufficient space on amazon instances?
<pstolowski> Chipaca: nope
<zyga> mvo: when do you anticipate 2.36.1
<pstolowski> Chipaca: interesting... did we have 'snap services' from the beginning, or was it added later? i remember snapctl was modelled after snap start/stop/restart
<Chipaca> pstolowski: services and logs were part of the same piece of work
<cachio> zyga, hey
<Chipaca> pstolowski: any reason not to add the missing two?
<cachio> zyga, yes, this is the one I mentioned today
<cachio> in the standup
<zyga> oh, sorry I missed that
<cachio> I'll push a PR today
<zyga> thanks!
<Chipaca> um
<Chipaca> um
<Chipaca> hold on
<Chipaca> what's that doing?
<cachio> zyga, I am still working on the spread issue but I'll back to that one later, thanks
<zyga> thank :)
 * Chipaca greps
<zyga> Chipaca: ?
<Chipaca> is it always that file?
<Chipaca> cachio: zyga:?
<zyga> ok, it's almost 18;00 and my head is dizzy from ABS fume
<Chipaca> zyga: dude
<zyga> Chipaca: first time I saw this
<zyga> Chipaca: not sure
<zyga> I'll head upstairs until I can vent this room
<Chipaca> zyga: go smoke something healthy to give yourself a break
<Chipaca> like, i dunno, bacon
<zyga> abs shrinks and warps when cooled
<mvo> zyga: there is the open question about "snapd 2.36 API "system" vs "core" slot name" - I sent a mail about this last week, you are on the CC i have no reply yet
<pstolowski> Chipaca: no, we should have status at least i think, not sure about logs. and they should be narrowed to services of current snap of course
<mvo> zyga: once we know what to do here we can continue
<zyga> mvo: the one for our customers?
<zyga> mvo: ok
<zyga> mvo: thanks!
<mvo> zyga: yeah, I ping htem now
<zyga> thanks!
<Chipaca> pstolowski: yeah not sure what purpose logs would serve
<zyga> I'm asking because the base snap refresh bug fix is important for desktops
<zyga> so perhaps I should cherry pick it
<Chipaca> cachio: dunno if you saw my question, is the out-of-space error always about .snap-pack-exclude?
<pstolowski> Chipaca: i can only think of having 'logs' for consistency, but that's probably not enough
<mvo> zyga: cherry pick to 2.36? absolutely if its important
<cachio> Chipaca, no
<Chipaca> cachio: ah, phew
<zyga> yeah, I'll do that
<cachio> I have seen it about other stuff too
<zyga> Chipaca: tomorrow: I'd like to shrink packaging and grow a makefile
<zyga> it's very annoying that we have so many things done in a build script that is distro specific
<zyga> I'll bug you for reviews :)
<cachio> Chipaca, i.e. https://travis-ci.org/snapcore/spread-cron/builds/450694163#L2503
<Chipaca> cachio: i was worried because .snap-pack-exclude could very easily be a static file somewhere (it was just a faff to get it right on darwin)
<roadmr> zyga: hm, I updated https://bugs.launchpad.net/snapstore/+bug/1786071 with the traceback I got with the fedora snap - looks like the click reviewer tools are still unhappy, we fixed the case where files/dirs inside squashfs-root have funny perms but may have obviated the "squashfs-root itself has funny perms" case :(
<roadmr> jdstrand: ^^ the above sounds similar to https://bugs.launchpad.net/click-reviewers-tools/+bug/1712476 , which was about files inside squashfs-root having funny perms but it may have obviated funny perms on squashfs-root itself :/
<zyga> roadmr: that's great, thank you for checking
<roadmr> np, sorry we keep finding funny cleanup cases
<jdstrand> roadmr: what revision of the snap? if seems the latest ones passed review
<zyga> jdstrand: when I pushed myself it was not even registered by the store
<zyga> prior revisions were hacked to pass
<jdstrand> zyga: is it the fedora29.2018.10.09.x86_64.snap you wormholed to me?
<zyga> I honestly don't recall now, I can quickly build a daily to test
<zyga> but it was simply chmod ugo-w / that broke things AFAIK
<jdstrand> dr-xr-xr-x root/root               269 2018-10-09 11:27 squashfs-root
<jdstrand> that passes here
<jdstrand> roadmr: what are you looking at? ^
<jdstrand> roadmr: it should be fixed in r1132
<jdstrand> roadmr: I commented in the bug
<cachio> niemeyer, the reboot issue on spread I mentioned today is happening on some systems when the reboot command is executed
<cachio> niemeyer, it is happening that the ssh hangs and then it finishes when the warn timeout hist
<cachio> hits
<cachio> I see this can be reproduced on systems which are rebooting so fast
<cachio> i-e- debian 9 is rebotting in about 8 seconds
<cachio> or less
<cachio> I could fix it by running reboot on background
<cachio> niemeyer, I'll create a PR with this
<cachio> niemeyer, https://github.com/snapcore/spread/pull/70
<mup> PR spread#70: Reboot on backgraound to avoid spread wait for long time <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/70>
<zyga> jdstrand: offtopic: https://github.com/snapcore/snapd/pull/5644#discussion_r228444370
<roadmr> jdstrand: I'll check your comment now. Yes, I recall that was supposed to be fixed :/ and the store is on >1132 anyway... checking
<mup> PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
<zyga> jdstrand: I wrote some POC code for that
<zyga> jdstrand: where snapd is a trust store itself that apps could query
<jdstrand> zyga: I responded. I think that is interesting and possibly something for the future, but the patches already exist and are working their way in via SRU for pulseaudio (but see comment)
<jdstrand> roadmr: if you have a specific snap where it is failing, I'm happy to look at it. I was going by a snap zyga wormholed me a while ago that had a 555 /, but maybe you have a different snap that causes trouble
<roadmr> jdstrand: it's the same snap from zyga :/ I did have to unpack it and tweak it a bit so I could upload it to the store myself
<roadmr> changed the name and type mainly
<jdstrand> roadmr: $ sha256sum ./fedora29.2018.10.09.x86_64.snap
<jdstrand> 15169bf33d889746a31828213ecf1adcd442ba82b13ad30d5b7c68eb164faf47  ./fedora29.2018.10.09.x86_64.snap
<roadmr> jdstrand: yep, that's the one I based mine on
<jdstrand> roadmr: it is working find here both as the review-tools snap and out of my bzr checkout of crt
<jdstrand> fine*
<jdstrand> roadmr: is it something in the store and not the review tools that is having trouble?
<jdstrand> roadmr: can you give me your snap?
<roadmr> jdstrand: sure! wormhole?
<jdstrand> that's fine
<roadmr> jdstrand: also, what's barfing is the review-tools themselves, but I notice this is when doing unpack-package. Is that what you're testing?
<jdstrand> roadmr: I am simply running click-review/snap-review
<jdstrand> roadmr: let me try unpack-package
<jdstrand> roadmr: worked fine
<roadmr> interesting!
<jdstrand> $ PYTHONPATH=./ ./bin/unpack-package ~/Desktop/fedora29.2018.10.09.x86_64.snap /tmp/foo
<jdstrand> Successfully unpacked to '/tmp/foo'
<jdstrand> roadmr: is something wrong with your checkout?
<roadmr> hm I don't think so :)
<jdstrand> roadmr: $ PYTHONPATH=./ ./bin/unpack-package ~/Desktop/evil-roadmr-fedora-2018.11.05.01_amd64.snap /tmp/bar
<jdstrand> Successfully unpacked to '/tmp/bar'
<roadmr> jdstrand: ACTUALLY - I can try it on the very same store unit that had the error
 * roadmr does so
<jdstrand> roadmr: $ PYTHONPATH=./ ./bin/click-review ~/Desktop/evil-roadmr-fedora-2018.11.05.01_amd64.snap
<jdstrand> Errors
<jdstrand> ------
<jdstrand>  - lint-snap-v2:external_symlinks
<jdstrand> 	package contains external symlinks: usr/lib64/libnssckbi.so, usr/lib64/p11-kit-trust.so
<jdstrand> /home/jamie/Desktop/evil-roadmr-fedora-2018.11.05.01_amd64.snap: FAIL
<jdstrand> roadmr: it not tracing back here
<jdstrand> it's*
<roadmr> interesting... yes, if it were able to upload and then run the checks, I'd see something different
<jdstrand> roadmr: maybe smething somewhere has an old crt?
<jdstrand> roadmr: I need to step into a meeting but will watch backscroll
<roadmr> jdstrand: sure! I'll triple-check everything. It's unlikely it's outdated but I'll leave no stone unturned
<roadmr> BEHOOLD!
<roadmr> jdstrand: instead of PYTHONPATH=./ ./bin/unpack-package ~/Desktop/evil-roadmr-fedora-2018.11.05.01_amd64.snap /tmp/bar try this
<roadmr> jdstrand: 1- mkdir /tmp/baz
<roadmr> 2- PYTHONPATH=./ ./bin/unpack-package ~/Desktop/evil-roadmr-fedora-2018.11.05.01_amd64.snap /tmp/baz/quux
<roadmr> that will repro the crash. No rush, finish your meeting, I'll keep poking and maybe file a bug with a minimal reproducer snap
<robert_ancell> cprov, did you expect /v2/find?section=gamesq=mmapper to return info on the mmapper snap (it doesn't)
<robert_ancell> cprov, whoops, was missing the '&'. It does show.
<cprov> robert_ancell: it does, right ?
<robert_ancell> cprov, yes, it was my mistake.
<cprov> robert_ancell: np
<jdstrand> roadmr: ok, I can reproduce that
<roadmr> jdstrand: the key is the extra directory level; this is what the store does, it creates a NamedTemporaryDir in /tmp to hold each snap and then e.g. says $THE_TEMP_DIR/unpacked for the unpack operation and so on. So that extra level is what's making things funky
<roadmr> jdstrand: https://bugs.launchpad.net/click-reviewers-tools/+bug/1801788  with mini-snap exposing the problem
<mup> Bug #1801788: Unpacking a snap with mode-555 top-level squashfs-root in a subdirectory of a subdirectory of /tmp fails <Canonical Click Reviewers tools:New> <https://launchpad.net/bugs/1801788>
<zyga> roadmr, jdstrand: woot, nice!
<jdstrand> roadmr: can you pull r1152 of the review-tools? it has a fix for ^
<roadmr> jdstrand: thanks for the quick fix! sure thing
<jdstrand> roadmr: np. thanks for the reproducer
#snappy 2018-11-06
<zyga> o/
<zyga> good morning
<mvo> hey zyga
<zyga> hey :)
<mborzecki> zyga: mvo: morning guys
<zyga> good morning
<mvo> hey mborzecki
<zyga> mborzecki: please wait on the opens use review, I found some things to change last night that I didn't address yet
<mborzecki> zyga: ok
<mvo> zyga: your opensuse build update shows "+ echo 'Package build incorrect, '\''snap --version'\'' mentions '\''unknown'\'''"
<mvo> zyga: in the spread tests
<zyga> yeah, I saw that
<zyga> that's what I meant :)
<mvo> ok
<mvo> zyga: oh, sorry, missed that I guess
<zyga> it works fine in casual testing but I wanted to see spread run before releasing this
<zyga> no worries, thank you for looking
<mborzecki> https://github.com/snapcore/snapd/pull/6094 could use another review
<mup> PR #6094: wrappers: fix generating of service units with multiple `before` dependencies <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6094>
<mborzecki> then we can land it and pick it for 2.36
<zyga> yep
<zyga> mborzecki: interesting, in my local build I see the correct version on "snap version"
<pstolowski> good morning!
<zyga> --debug session shows unknown
<zyga> so odd, let's see why
<zyga> ah
<zyga> because of how we build in spread
<zyga> normal builds are fine
<mborzecki> hm i'm debugging why #5896 spread test for device keys seeminglly doesn't work
<mup> PR #5896: snapcraft.yaml: set grade to stable <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5896>
<mborzecki> the test snap finds a device /dev/input/by-path/platform-i8042-serio-0-event-kbd which as it turns out has all the attributes that make it match with device-buttons interface :/
<mborzecki> hm no it doesn't match, but the snap can still access it
<mborzecki> zyga: any clues, there's a device /dev/input/event2 maj:min is 13:66, it's not listed in devices.list for that snap, but when running under --shell i can still open it
<zyga> mborzecki: _hmm_
<zyga> mborzecki: when you open shell can you see the process listed in the control group?
<mborzecki> zyga: heh, no cgroup.procs is empty
<zyga> what system is that?
<zyga> is that devmode system?
<mborzecki> zyga: 18.04
<zyga> that's interesting
<zyga> ah
<zyga> well
<zyga> there's this one old odd behavior
<zyga> if you have no device tags for a given security tag
<zyga> then we don't use cgroups
<zyga> no tagging == no device cgroup
<mborzecki> zyga: sounds like a problem, with this interface you could get access to all /dev/input/*
<zyga> yes, it feels like we should make it unconditional
<zyga> can you check if that's still the case
<zyga> the code is in snap-confine/ in udev-support AFAIR
<mborzecki> zyga: feels like this is going to be fun, i need some coffee first
<zyga> uh, I forgot about dentist appointment
<zyga> need to go
<mvo> pstolowski: quick question: we only run the post-refresh hook on refreshes, right? not on a fresh install? so if I want something that run on a fresh install and a refresh I need to install two hook hanlders?
<pstolowski> mvo: correct, pre- and post-refresh hooks run only on refreshes. and install hook is run only on fresh install
<doko> mvo, zyga: the snapd autopkg tests are not happy with python 3.7 in disco. please fix
<mvo> pstolowski: ta
<mvo> doko: sure, looking
<zyga> Thank you doko
 * zyga is at the dentist
<doko> is snapd such a pain?
<mwhudson> zyga: thanks for https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1801687
<mup> Bug #1801687: Please remove the plainbox package <plainbox (Ubuntu):New> <https://launchpad.net/bugs/1801687>
<Chipaca> morning from the summit
<mborzecki> Chipaca: hey, what's the turnout?
<Chipaca> mborzecki: ~100,000 people
<mborzecki> Chipaca: over 9000 ;)
<Chipaca> mborzecki: :-)
<mvo> Chipaca: good morning! how are things there? anything exciting happening already?
<diddledan> mvo: popey is playing with his nipple already
<popey> !
<ogra> in public ?!?!
<diddledan> INORITE
<mvo> diddledan: *cough*
<mup> PR snapd#6096 opened: spread.yaml: add more systems to the autopkgtest and qemu backends <Created by mvo5> <https://github.com/snapcore/snapd/pull/6096>
<mup> PR snapd#6097 opened: interfaces/tests: MockHotplugSlot test helper <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6097>
<mvo> doko: I uploaded a new snapd into disco that should now run the adt tests, will be interessting to see if they fail or pass so maybe there is more work needed but this should at least unblock things
<zyga> Dentist over, heading home
<mvo> zyga: welcome back
<zyga> What was the issue with python 3.7?
<mvo> zyga: pr is 6096
<mvo> zyga: its an internal issue might be worth reworking how we drive adt
<doko> I love it when you have to do things like that for every release ... maybe just do the reverse, where it's *not* supported?
<mvo> doko: sure, let me look what we can do to make this simpler
<mvo> doko: thanks for approving it though
 * mvo looks into reworking that code
<popey> degville: https://snapcraft.io/docs/reference/env is referenced in a few places and redirects to a 410 page https://docs.snapcraft.io/reference/env
<degville> ooh, thanks popey.
<pedronis> mvo: what's the status of 2.36?  is there anything immediately blocked on me?
<mvo> pedronis: we need confirmation about the 2.36 API of "system" vs "core"
<mvo> pedronis: I sent a mail about this but no reply yet
<mup> PR snapd#6098 opened: interfaces/builtin: support hotplug for camera interface <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6098>
<mborzecki> zyga: about that cgroup & apparmor, i think now with the process ending up in devices cgroup always, accessing /dev/input/event2 is blocked before lsm gets to have a say on this
<zyga> and back home now
<zyga> mborzecki: that's correct
<mborzecki> zyga: ok, i'll push the change for s-c as separate PR, some tests may need to be updated, especially the ones where we check between EPERM and EACCESS
<zyga> aha, that makes sense
<zyga> thank you
<ogra> mvo, i'm recently working a lot with x86 images ... was there any actual reason that we show the grub menu there ?
<ogra> i mean ... you normally dont select anything there anyway ...
<mvo> ogra: no real reason, it may become more interessting once we provide recovery via this mechanism but even then its not a huge reason
<mvo> ogra: also kind of nice to show people what system they use but *shrug* really no strong reason :)
<ogra> it feel like wasted boot time
<ogra> *feels
<zyga> I built the package locally out of a release tarball and the version is correct
<zyga> the issue must be related to how we build the tarball inside spread
<mup> PR snapd#6099 opened: cmd/snap-confine: always put the snap process under a device cgroup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6099>
<zyga> mborzecki: interesting, let's see what we get
<zyga> (from tests)
<mborzecki> zyga: yeah, much fun
<Chipaca> hmm
<Chipaca> mborzecki: https://forum.snapcraft.io/t/parallel-installs/7679
<Chipaca> mborzecki: says 1. parallel installs are experimental and you need to 'snap set hose-my-system=very-yes'
<Chipaca> mborzecki: but also, 2. you need 2.36
<mborzecki> Chipaca: yes
<mborzecki> Chipaca: 2*yes
<Chipaca> mborzecki: I thought 2.36 marked them non-experimental?
<mborzecki> Chipaca: no, we delayed that to 2.37
<Chipaca> ah, missed that
<Chipaca> ok
<Chipaca> mborzecki: are the store-side limitations still true?
<mborzecki> Chipaca: no, there's a note from wgrant, i should probably update the first message
<Chipaca> mborzecki: yes please :-)
<mborzecki> Chipaca: aand done
<mborzecki> Chipaca: are you guys actively trying to break it? :)
<Chipaca> mborzecki: ð
<Chipaca> mborzecki: people are being told it works /o\
<mborzecki> Chipaca: good, good, ping me if there are any questions
<Chipaca> will do :-)
<mborzecki> zyga: that device cgroup change, i think it's more of a 2.37 material, wdyt?
<zyga> mborzecki: not for 2.36 for sure
<zyga> we need to discuss with jdstrand and pedronis
<mup> PR snapd#5946 closed: cmd/snap: unhide --name parameter to snap install, tweak help message <Parallel installs â> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5946>
<pedronis> zyga: I'm going a bit through my email etc backlog and some travel admin stuff, but I should be available later in the week to discuss things
<Chipaca> mvo: https://pastebin.ubuntu.com/p/4hpHK8MRHq/
<Chipaca> niemeyer: ^ i really wish we could do smarter formatting of tables on the terminal :-(
<mvo> Chipaca: woah
<Chipaca> (granted that message is longer than it needs to be :) )
<zyga> pedronis: thank you
<zyga> Chipaca: use case for those ultra crazy wide monitors ;)
<ogra> 80 chars are enough for everyone !
<mup> PR snapd#5916 closed: data: run snapd.autoimport.service only after seeding <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5916>
<mborzecki> zyga: a bunch of tests failed in 6099
<Chipaca> zyga: I see your wide monitor use case, and I raise you a use case for in-snap sub-mount namespaces
<zyga> Chipaca: whaaat?
<Chipaca> zyga: also in-snap network namespaces
<Chipaca> zyga: you started! this is all your fault
<zyga> that I actually want
<zyga> app firewall
<zyga> looking at logs there maciej
<zyga> eh
<zyga> log too long
<zyga> mborzecki: Ensure we can run a statically linked binary from an empty base <- this failed, interesting
<mborzecki> zyga: yeah, the log hit travis limits
<zyga> mborzecki: I think at this point you need to see what happens until you can run the statically linked echo test
<mborzecki> zyga: anyways, Operation not permitted popping up quite frequently, must have been blocked by device cgroups then
<zyga> yeah
<Chipaca> pedronis: o/
<mborzecki> Chipaca: error: invalid argument for flag `--id' (expected main.snapshotID): strconv.ParseUint: parsing "": invalid syntax, is this something you were looking for?
<Chipaca> mborzecki: you should have logs
<Chipaca> mborzecki: if it's amazon telling you about id -2, take its vodka away
<Chipaca> mborzecki: uid -2 that is
<mborzecki> Chipaca: yes, it is https://paste.ubuntu.com/p/Ms9jXqvH6V/
<Chipaca> bah
<Chipaca> bahÂ²
<Chipaca> bahÂ³
<Chipaca> bahâ¹â¹
<Chipaca> mborzecki: i'm not sure i can handle it better than just failing
<Chipaca> mborzecki: but also i don't know why i'm getting that -2
<Chipaca> mborzecki: I do know why it's a -2 :-)
<Chipaca> mborzecki: amazon linux 2, yes?
<mborzecki> Chipaca: yes
<mborzecki> hm we could dump /etc/passwd in debug
<Chipaca> mborzecki: AIUI it's a manifestation of https://github.com/golang/go/issues/22739
<Chipaca> mborzecki: the -2, i mean
<zyga> Chipaca: it is an off-by-one issue :)
<Chipaca> nope, it's golang's syscall return value munging
<Chipaca> so
<Chipaca> that -2 comes from os.Getuid() returning something too big
<Chipaca> for go
<pedronis> Chipaca: hi
<Chipaca> which doesn't make sense on itself
<Chipaca> but Â¯\_(ã)_/Â¯
<mborzecki> Chipaca: although it's globbed, the path i mean
<Chipaca> pedronis: hi! welcome back. Random question about aliases  (from a user at the summit): are multiple snaps having the same alias supported ok store-side?
<mborzecki> Chipaca: some stat maybe? uid/gid handled incorrectly
<Chipaca> pedronis: i assume yes but dunno how tested it is :-)
<Chipaca> mborzecki: i literally just remembered where the -2 comes from today, so i need to comb it
<pedronis> Chipaca: yes, you'll need to use snap prefer  and --unaliased in case you want them both on the same system
<Chipaca> pedronis: yep
<niemeyer> Chipaca: Yeah, that looks pretty bad
<niemeyer> Chipaca: We need something significantly more polished
<Chipaca> niemeyer: I can make it shorter, but I can't make it short enough without giving the user context about why they're being warned
<Chipaca> i mean, short,  or with context
<Chipaca> just saying "this app is devmode" isn't enough imo
<niemeyer> Chipaca: The date formating is also breaking our old rule about having no spaces before the last item
<cachio> niemeyer, hey, when you have some time, could you please take a look to this PR? https://github.com/snapcore/spread/pull/70
<mup> PR spread#70: Reboot on backgraound to avoid spread wait for long time <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/70>
<niemeyer> Making it even harder to read
<niemeyer> cachio: Sure
<niemeyer> I have some time now, but it'll be hard to review it while in line at the border :)
<niemeyer> Chipaca: We might have a short description and a link
<Chipaca> niemeyer: i was thinking of "snap help devmode"
<Chipaca> ie having topics
<Chipaca> as well as commands
<niemeyer> That sounds nice!
<niemeyer> Chipaca: Perhaps just some twist on it so it doesn't look like a command?
<niemeyer> Do we support that today?
<niemeyer> snap help <cmd>?
<Chipaca> niemeyer: yes
<niemeyer> Yeah, so we need to disambiguate
<Chipaca> niemeyer: and snap help --all  is how you get the long list of everything
<Chipaca> so 'snap' on its own tells you to 'snap help --all' for ex
<cachio> niemeyer, great, thanks
<niemeyer> snap about devmode
<Chipaca> niemeyer: wrt the timestamp, i'll change it to use the shorter format we discussed for 'snap saved'
<niemeyer> Chipaca: Sounds good
<Chipaca> that one doesn't have spaces
<niemeyer> Chipaca: Or we could really use the link for the detailing of an issue
<niemeyer> Chipaca: Or alternatively, transform the output of warnings into yaml
<niemeyer> So we can actually read it
<mup> PR snapd#6100 opened: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100>
<mup> PR snapd#6101 opened: switch travis unit tests to xenial <Created by chipaca> <https://github.com/snapcore/snapd/pull/6101>
<zyga> sigh
 * zyga tries again
<pedronis> Chipaca: I remember we do line wrapping for some errors, either way the super informative warning is good if it's are, but will get annoying if the warning is very common
<mup> PR snapd#5963 closed: tests/hotplug: spread test for hotplug based on dummy interface <Hotplug ð> <â Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5963>
<pedronis> s/it's are/it's rare/
<Chipaca> pedronis: agreed about that
<zyga> https://www.irccloud.com/pastebin/mEgjLBWg/
<zyga> mborzecki: ^ weird, right?
<zyga> info file is correct too
<mborzecki> zyga: 1337 version is better than none :)
<mborzecki> 31337
<mborzecki> zyga: the one i have here locally is ok
<zyga> yeah
<mborzecki> zyga: from what i see we change it in prepare when bulding rpms
<zyga> I think I know what's wrong now
<zyga> copy
<mborzecki> zyga: are you calling go generate as part of the build?
<zyga> I call mkversion.sh in prepare
<zyga> google:opensuse-42.3-64 /# find -name version_generated.go
<zyga> ./usr/src/packages/BUILD/snapd-1337.2.36/gopath/src/github.com/snapcore/snapd/cmd/version_generated.go
<zyga> so this file is good
<Chipaca> niemeyer: some cool people from travis-ci are here
<Chipaca> niemeyer: it turns out we can throw money at them and get more concurrent runs
<mborzecki> zyga: then why it's unknown in snap version output?
<Chipaca> niemeyer: it's just a bit messy and requires a human, because we're using .org
<zyga> ./usr/src/packages/BUILD/snapd-1337.2.36/gopath/src/github.com/snapcore/snapd/cmd/VERSION
<Chipaca> niemeyer: let's chat
<zyga> there's also this which is equally correct
<zyga> mborzecki: now I'm confused :/
 * zyga looks
<Chipaca> grr, unit tests are 8 minutes again :-(
<mborzecki> zyga: in arch i'm calling ./mkversion.sh $pkgver-$pkgrel
<mborzecki> zyga: so it's not guessing the version
<pedronis> mborzecki: hi, was https://forum.snapcraft.io/t/cross-snap-service-ordering/8319 discussed with niemeyer, it doesn't seem to match the brief discussion we had in SLC
<zyga> the version is fine in VERSION and in go so it's not that
<mborzecki> pedronis: hi, no hence the forum topic, could you leave a comment with what you discussed in slc there?
<zyga> must be something I'm missing :/
<zyga> I was thinking it must be a copy
<zyga> C and Go are built differently
<zyga> C picks up the version okay
<zyga> go uses import paths to build stuff
<zyga> so I was thinking there must be a bit of copy that was not changed with mkversion somewhere
<pedronis> mborzecki: I'll try to put something there today or tomorrow, we just sketched some ideas
<pedronis> it will need further discussion
<zyga> google:opensuse-42.3-64 /root# GOPATH=/usr/src/packages/BUILD/snapd-1337.2.36/gopath go build -buildmode=pie github.com/snapcore/snapd/cmd/snap
<zyga> https://www.irccloud.com/pastebin/szuxkg0r/
<zyga> so this worked okay
<mborzecki> pedronis: fair enough, i'm out to conference on wed and thu so no rush
<niemeyer> Chipaca: Ack
<zyga> I'll add a sanity check in %build to see what version we se
<zyga> mborzecki: ah, there _is_ a copy
<zyga> wtf?
<zyga> we have /home/gopath
<zyga> and /usr/src/
 * zyga looks
<zyga> but this is why this happened
<mborzecki> src.rpm got installed?
<zyga> no, I think that's our spread hacking magic
<zyga> aka mess
<zyga> hmm
<zyga> mborzecki: what is GOHOME?
<mborzecki> GOHOME?
<zyga> it's set in spread.yaml
<zyga> git grep GOHOME
<zyga> looks like our invention
<mborzecki> zyga: right, but we set GOPATH using that
<zyga> that's fine though
<zyga> I wonder where /usr/src came from
<zyga> specifically usr/src/packages/BUILD
<zyga> doesn't feel like something out of srcrpm
 * zyga looks
<zyga> quick coffee while spread starts up
<Chipaca> zyga: /usr/src is GOROOT
<Chipaca> I'm guessing
<zyga> Chipaca: nope, suse sets GOROOT in the environment to something like /usr/lib64/go/1.11
<zyga> there is no match for /usr/src in our tree so I'm puzzled
<pedronis> mvo: I pinged you from a couple of unanswered forum topics
<mborzecki> off to pick up the kids
<zyga> I see what's going on now
<zyga> just not sure how /usr/share/packages is defined
<zyga> but that's fine
<zyga> got it!
<zyga> # rpm -E '%{_topdir}'
<zyga> /usr/src/packages
<zyga> so
<zyga> we have a copy there in BUILD
<zyga> and we have a copy in /home/gopath
<zyga> now just to untangle that
<Son_Goku> zyga, it's /usr/lib/rpm/macros
<Son_Goku> SUSE patches rpm to force that
<zyga> yeah, I know now :)
<Son_Goku> what it does is that if ~/rpmbuild doesn't exist, it will use that directory instead
<Son_Goku> (IMO, that's broken, but whatever...)
<Son_Goku> also... zyga: https://twitter.com/fedora/status/1059728342666989568
<Son_Goku> looky, you're in the picture :D
<zyga> Niiiice :)
<Son_Goku> as am I! weee! :D
<ogra> seems he surrenders
<ogra> :)
<Son_Goku> yep, he's now a Fedora man
<Son_Goku> no more Ubuntu for him :D
<ogra> go IBM !
<ogra> :P
<Son_Goku> :S
<jdstrand> mborzecki: fyi, the fuse-support test in your cgroup PR is failing cause you're checking for Permission Denied (as you said above)
<Son_Goku> zyga, mborzecki, you guys will want to look into this: https://bugzilla.redhat.com/show_bug.cgi?id=1438079#c4
<Son_Goku> I have a feeling we're switching the unified hierarchy for cgroups (aka cgroups v2) very soon
<mvo> pedronis: thanks for the pings, I'm replying now
<zyga> Son_Goku: I know about it, I talked to zbyszek
<zyga> I think that v2 is not ready yet
<zyga> it doesn't have the controllers we need
<Son_Goku> ok
<mborzecki> jdstrand: a couple of tests fail the same way, and i have some issues with devmode, we do not generate udev rules in that case but with the PR s-c will still put the snap under a cgroup
<mborzecki> Son_Goku: thanks for the heads up
<mborzecki> zyga: iirc we're only missing freezer at this point, aren't we?
<zyga> mborzecki: haha, not sure if only but the freezer is the first one I noticed
<Son_Goku> zyga, need karma for this: https://bodhi.fedoraproject.org/updates/FEDORA-2018-48cc10ba1d
<zyga> ack, I'll test it today
<mborzecki> zyga: maybe it'd be a good idea to check what's in there already and what we're missing
<mborzecki> zyga: switching will be proobably held for as long as docker dones not support v2
<zyga> mborzecki: based on my discussion with zbyszek there is really no rush for this, it will likely take years
<ogra> ppisati, did you take a look at the pi3 b+ NIC-LED isues described in https://forum.snapcraft.io/t/support-for-raspberry-pi-3-model-b/4509 ?
<ogra> (i think the patchset i pointed to initially had fixes for that too)
<jdstrand> mborzecki: I understand the PR and the motivation. Please see my comments in both PR 5897 and PR 6099. 5897 can land if we force the use of the cgroup, like we did with joystick (see comment)
<mup> PR #5897: interfaces/builtin: add device-buttons interface for accessing events <â Blocked> <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
<mup> PR #6099: cmd/snap-confine: always put the snap process under a device cgroup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6099>
<mborzecki> jdstrand: thanks! will do
<zyga> mborzecki: fixed, I think
<zyga> just quick local spread run before pushing
<mborzecki> zyga: what was it?
<zyga> mborzecki: GOPATH takes priority over what we want to build
<mup> PR snapd#6094 closed: wrappers: fix generating of service units with multiple `before` dependencies <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6094>
<zyga> I swapped GOPATH with indigo_gopath
<zyga> https://www.irccloud.com/pastebin/wYHe3zeU/
<zyga> mborzecki: ^ my notes from this session
<ppisati> ogra: i'm looking into it - the led patches are already there, but one of the function (lan78xx_otp_read()) is buggy, or to better - if i apply the correct fix, then leds are working but the entire chip stops working (we don't get any phy interrupt when packate arrives at the interface)
<ppisati> *packets
<ogra> ok ...
 * ogra comments in the forum thread
<ppisati> ogra: IOW, the lan78xx driver in 4.4 relies on the buggy behaviour of that function
<zyga> mborzecki: in distro builds this doesn't happen because osc uses a chroot and controls GOPATH
<Chipaca> zyga: pstolowski: using a serial port on classic, does it need hotplug or is it alredy there?
<zyga> Chipaca: you need hotplug
<pedronis> mvo: thanks for answering those topics
<mborzecki> mvo: can you cherry pic https://github.com/snapcore/snapd/pull/6094 to 2.36?
<jdstrand> mborzecki: ok, and now you have my code review for 6099. thanks again for picking that up
<mup> PR #6094: wrappers: fix generating of service units with multiple `before` dependencies <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6094>
<zyga> (new old standup time)
<mborzecki> jdstrand: thanks, it was fun to look into this :)
<zyga> Chipaca mvo pstolowski pedronis  ^
<ogra> mvo, couldnt you just remove the state.json to get back into console-conf (effectively doing a fake "factory reset") ?
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/6095 after the call please
<zyga> I think it should pass now
<mup> PR #6095: packaging/opensuse: stop using golang-packaging <Created by zyga> <https://github.com/snapcore/snapd/pull/6095>
<Chipaca> pedronis: another question
<pedronis> Chipaca: in the standup, but do ask, I will come back later
<mvo> ogra: yeah, that should work as well, I didn't suggest it in the forum because I wasn't sure if there were any "precious" things on the system, maybe he has some snaps he does not want to lose, but yeah, if not its a solution too
<Chipaca> pedronis: ok
<mvo> mborzecki: 6094 is cherry-picked
<mborzecki> mvo: thanks!
<Chipaca> pedronis: if somebody wanted to use snaps in a cloudy context where they want the image to boot and have a number of snaps already installed
<Chipaca> pedronis: they feel they could just install them, snapshot the disk, and then just run with it
<Chipaca> pedronis: seeding is too slow, installing from zero is too slow
<mvo> I wonder if we could put things on disk in the prepare image state and just run the hooks at "seeding" time. probably needs careful thinking but my gut feeling is that everyone wants faster seeding
<Chipaca> ye
<Chipaca> mborzecki: also also
<Chipaca> mborzecki: you lied to me: the " Due to the current limitations in the store, multiple instances of a snap need to be installed from the same single command, as shown above." thing is still on https://forum.snapcraft.io/t/parallel-installs/7679
<cachio> Chipaca, https://paste.ubuntu.com/p/XjP3hcFr4P/
<cachio> I saw this one today
<Chipaca> cachio: yes
<Chipaca> cachio: thank you
<Chipaca> cachio: it's the -2 user id, i need to look into it
<Chipaca> not today
<cachio> sure
<Chipaca> cachio: restart, but thank you for the paste (is it set to expire?)
<cachio> no
<cachio> Chipaca,
<Chipaca> cachio: tks
<Chipaca> mborzecki: i edited
<mborzecki> Chipaca: thanks
<mborzecki> Chipaca: does it work so far for you guys? :)
<Chipaca> mborzecki: i have not been lynched yet
<Chipaca> mborzecki: and i get to keep _most_ of my fingers!
<mborzecki> Chipaca: maybe they're still building the pyre
<Chipaca> mborzecki: they're still drunk from guy fawkes last night
<zyga> Pharaoh_Atem: what's the difference between %{!?... and %{?!...} ?
<Pharaoh_Atem> preference, mainly
<Pharaoh_Atem> some broken spec parsers handle them differently
<Pharaoh_Atem> both otherwise they should behave the same
<zyga> why do we use both?
<zyga> should we use the same syntax or is there a good reason to keep the difference
<zyga> I just noticed because of a bug that affected leap
<Pharaoh_Atem> I just switched everything in the fedora spec to %{!?...}
<zyga> thanks
<zyga> I'll do the same
<Pharaoh_Atem> it makes more sense in my head anyway
<Pharaoh_Atem> "does not exist" vs "exists, not?"
<mup> PR snapcraft#2392 opened: ci: update travis.yaml to use xenial <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2392>
<Chipaca> chesty: https://bugs.libssh.org/T118
<pedronis> Chipaca: if they use a prebooted image the serial number would be wrong,  we don't have an answer at the moment except you do need to do seeding, but is an open question, we discussed about it a bit with mvo etc in SLC
<Chipaca> pedronis: yeah, seeding is going to be too slow
<Chipaca> pedronis: we're talking about a 14 seconds boot being omg slow
<Chipaca> pedronis: not a blocker but we really need to address this soonish
<chesty> Chipaca, nice. why struct passwd *pwdbuf = NULL; ? is extra precaution in case  of a bug in getpwuid_r ?
<Chipaca> chesty: i guess so yes
<jdstrand> roadmr: fyi, finally got all the revisions before r79 of pivx and now I was able to run the automated tools again on 79
<roadmr> \o/
<roadmr> thanks for checking.
<Chipaca> hmmmmmmmmmmmmââââââââââ
<mvo> Chipaca: well, I think we should thing about putting things on disk in prepare image and just running the hooks but its a bigger change and needs careful investigation
<Chipaca> mvo: ââââââ
<Chipaca> mvo: :-)
<Chipaca> mvo: why run the hooks?
<mvo> Chipaca: running the hooks in prepare image is going to be a challenge - we may create an arm image with a amd64 host
<Chipaca> mvo: we could also not support doing the whole fast boot set up on an mÃn arch grid
<Chipaca> anyway i figured out where the snapshot -2 uid error comes from, probablyâ¢
<pedronis> Chipaca: we can add some constraints, but we cannot be fully arbitrary or hackish either
<pedronis> it needs some toughts
<Chipaca> pedronis: yes
<ogra> zyga, are layouts on by default in 2.36 ?
<zyga> yes
<ogra> so i can drop the passthrough in my snapcraft.yaml ?
<roadmr> ogra: try dropping it; if snapcraft complains, then you'll still need it :)
<pedronis> the passthrough is about snapcraft, not snapd
<roadmr> ^^ this
<ogra> hahaha
<zyga> ogra: that's a question for kyrofa and sergiusens
<zyga> roadmr: processing...
<roadmr> zyga: yay!
<zyga> it worked!
<roadmr> of course ;) thanks to the work jdstrand did yesterday
<zyga> and released!
<zyga> (to beta)
<kyrofa> zyga, ogra layouts are supported in 3.0 as long as you specify a base
<zyga> woot
<kyrofa> Otherwise passthrough is still required
<ogra> urgh
<roadmr> zyga: yay \o/
<ogra> kyrofa, how does that work for all my exiting snaps ... is a default base picked when i do a rebuild ?
<ogra> *existing (even though some are exciting :P )
<zyga> ogra: you need to pick base: core
<zyga> ogra: or core18
<ogra> zyga, so i need to update all exiting snapcraft.yamls ?!?!
<zyga> yes
<zyga> that's intentional
<ogra> sigh ...
<zyga> to opt into the new build semantics
<kyrofa> zyga, no, "core" is not a valid base, "core16" is. But that isn't really a thing yet
<ogra> you mean build.s.io will fall back to snapcraft 2.x if i dont ?
<kyrofa> Bingo
<ogra> phew
<ogra> k
<zyga> kyrofa: why core is not a valid base?
<kyrofa> ogra, we really didn't want to break folks
<zyga> (core is a valid base in snapd)
<kyrofa> zyga, isn't core going to only contain snapd?
<zyga> no
<kyrofa> Eh?
<zyga> kyrofa: you are talking about the snapd snap
<ogra> kyrofa, yeah, i would have been surprised if you did ... i trust you and sergio blindly normally ;)
<zyga> kyrofa: core will contain snapd and core16
<zyga> (and does so today)
<zyga> kyrofa: core16 is just core sans snapd
<kyrofa> zyga, core isn't being renamed to core16, then?
<zyga> kyrofa: no
<zyga> kyrofa: core16, core and core18 are separate snaps
<ogra> they dropped that renaming idea
<zyga> kyrofa: core16 and core18 don't have snapd anymore
<kyrofa> Yikes. All three will need to be maintained?
<zyga> kyrofa: snapd snap is a separate required snap in that case
<zyga> kyrofa: for now yes
<zyga> kyrofa: we will transition people from core to core16
<zyga> (that is core to core16 + snapd)
<kyrofa> Okay, I wasn't clued into the dropping of the rename. Still though, I think "core" shouldn't be used as a base
<zyga> pedronis: ^ in case I'm mistaken
<kyrofa> We should steer people toward core16
<zyga> pedronis: core, core16 and core18 will be maintained until we complete the transition
<zyga> kyrofa: sync with pedronis and mvo on timing please
<zyga> kyrofa: core16 can be used as a base AFAIK (correctly)
<zyga> kyrofa: as can core18
<kyrofa> Which means the only supported bases for now (at least in snapcraft, given that it's a new feature) should be core16 and core18
<kyrofa> zyga, it's not stable yet though, no?
<zyga> the transition is moving people away from core as the holder of snapd
<kyrofa> (core16, I mean)
<zyga> kyrofa: I think it is equally stable
<zyga> kyrofa: we just don't have the migration code in place
<zyga> but operationally it is just like core
<kyrofa> zyga, I mean it literally isn't in the stable channel
<kyrofa> It's edge only
<pedronis> kyrofa: I don't think core can be used as a base explicitly
<zyga> kyrofa: note that core16 and core18 are AFAIK maintained by foundations
<zyga> kyrofa: I see
<kyrofa> pedronis, agreed
<kyrofa> As it should be
<kyrofa> Any ETA for when core16 will be stable?
<zyga> kyrofa: I honestly don't know
<zyga> it probably should be now
<zyga> but it depends on the transition process
<zyga> (perhaps)
<ogra> so if i want to use layouts in my snaps that are built specifically for Ubuntu Core 16, what would i do (and note in no casse ever i want core18 to end up on a core16 install)
<pedronis> ogra: the decision to connect layouts to 3.0 and base is a bit strange, not sure what was the rationale there
<ogra> yeah
<ogra> we'll definitely want to use it for existing customer ... and many of them will never go to 18 ... (and wont want an additional core18 base nasp installed either)
<ogra> *cusstomerss
<ogra> (GRRR ... broken kbd)
<sparkiegeek> sergiusens: https://paste.ubuntu.com/p/ZFKJXbVMSj/
<sparkiegeek> sergiusens: 95% sure that's not related to my change
<sergiusens> pedronis: we did not have anyone request it, it can be done
<sergiusens> pedronis: that said, folks can still use passthrough and should be fine for the time being
<pedronis> sergiusens: I understand but given it might take a bit fore core16 to go stable, first class support might make sense
 * cachio lunch
<zyga> ogra: for ubuntu core 16 - can you use core18 base?
<ogra> zyga, i personally might ... 90% of our customers wont want to yet
<mup> PR snapd#6102 opened: overlord/snapshots: survive an unknown user <Created by chipaca> <https://github.com/snapcore/snapd/pull/6102>
<zyga> ogra: note that it doesn't imply booting core18
<Chipaca> ^ that should fix the weird amazon issue
<zyga> ogra: but sure, I'm just curious
<Chipaca> I still don't know _why_ amazon would trigger it, nor why with -2, but, there ya go
<zyga> Chipaca: do you know why the uid is unknown?
<ogra> zyga, it talke disk space on a already size limited device
<Chipaca> zyga: so there's a /home/foo/snap directory owned by uid -2
<Chipaca> zyga: that bit, i have no idea why
<zyga> aha...
<zyga> hmm
<Chipaca> zyga: espeially because the uid comes from stat
<zyga> that's indeed curious
<Chipaca> zyga: so it's not the syscall.Getuid bug
<zyga> I mean, if you stat it in a shell you see -2?
<zyga> !
<Chipaca> zyga: I haven't been able to reproduce it wiht -debug,  but if I could, I'd see the big uid
<bashfulrobot> niemeyer:
<Chipaca> bashfulrobot: ssh
<Chipaca> :-)
<ogra> Chipaca, he should ssh into gustavo ?!
<ogra> is there a pub-key available for that ?
<Chipaca> bashfulrobot: g.ustavo is presenting and has irc on
<Chipaca> bashfulrobot: what could go wrong
<bashfulrobot> Chipaca: sorry accidental. Apologies.
 * zyga dinner 
<mup> PR snapcraft#2393 opened: lifecycle: make snapcraft init template use > not | <Created by sparkiegeek> <https://github.com/snapcore/snapcraft/pull/2393>
<mup> PR snapcraft#2388 closed: project: early snapcraft.yaml validation <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2388>
<mup> PR snapcraft#2391 closed: runtests: run black with --diff <Created by abitrolly> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2391>
<zyga> re
<pedronis> mvo: https://github.com/snapcore/snapd/pull/6093 , is this really for 2.36 ?
<mup> PR #6093: daemon: spool sideloaded snap into blob dir <Created by chipaca> <https://github.com/snapcore/snapd/pull/6093>
<mvo> pedronis: yeah, we got a message from field (CE) that it affected a customer
<pedronis> ah, ok
<mvo> pedronis: if you feel uneasy about this please let me know
<mvo> pedronis: it seems relatively harmless (famous last words)
<pedronis> mvo: I haven't actually looked at it yet, just wondered to see something still under 2.36
<mvo> pedronis: ok
<pedronis> mvo: I can look at it in the morning
<mvo> pedronis: as you wish - I will leave it until then
<zyga> urgh
<zyga> rpm -q --whatprovides /usr/share/pkgconfig/systemd.pc
<zyga> and now all three suse releases have working snapd
<zyga> cachio: hey, do we have opensuse leap 15?
<zyga> cachio: and opensuse tumbleweed
<zyga> leap 42.3 is a bit dated now
<sunesito> hi all
<sunesito> i have installed snapd on ubuntu and when i try to run an app i have that error:Gtk-Message: Failed to load module "gail" Gtk-Message: Failed to load module "atk-bridge" Gtk-Message: Failed to load module "unity-gtk-module"  (acestreamplayer:5130): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
<sunesito> what am i missing?
<zyga> sunesito: hey
<zyga> I assume the app doesn't start at all
<zyga> what is the name of that app?
<sunesito> no
<sunesito> acestreamplayer
<ogra> you should be using a desktop launcher part for snapcraft
<zyga> ogra: I'm not sure if sunesito is the developer of that app
<ogra> oh
<ogra> yeah, ignore me then (giving developer tips :) )
<sunesito> Â¿? ill try it
<ogra> well, are you the developer of that snap ?
<ogra> (i was refrerring to code changes in the snap package)
<sunesito> ahhh...no...im not the developer...only a user
<ogra> https://snapcraft.io/acestreamplayer ...
<ogra> Last updated	Feb 21 2017
<ogra> hmm
<sunesito> sorry...is this a developers chanel?
<ogra> hasnt been touched in nearly two years
<ogra> sunesito, no, not at all
<ogra> (well ... too ... but as well for user questions/support)
<sunesito> thanks...i will investigate under ubuntu problem...because i have running it on debian os
<ogra> the snap ?
<sunesito> no....the error
<ogra> do you have the snap running on debian ?
<sunesito> @ogra sorry....yes, the snap with acestreamplayer
<ogra> aha
<ogra> thats an interesting datapoint
<ogra> whats the output of: snap version
<ogra> on your ubuntu
<sunesito> 2.35.5
<ogra> the full output please
<sunesito> ok
<sunesito> ubuntu_1604:~$ snap version snap    2.35.5 snapd   2.35.5 series  16 ubuntu  16.04 kernel  4.2.8
<ogra> where does that kernel come from ?
<ogra> thats not an ubuntu kernel
<ogra> (and likely the reason for your issue)
<ogra> zyga, wasnt there a fix in snapd that warns you if you use an unsupported kernel ? or is that not in stable yet ?? (see above)
<sunesito> this is an qnap
<sunesito> NAS
<zyga> ogra: not exactly, there's only one specific version we warn about
<ogra> ah
<zyga> on 14.04 that is still on 3.14
<sunesito> but i have running snap correctly in this system
<zyga> sunesito: interesting, did you install snapd yourself or did it come with it?
<zyga> and wait, didn't you say this is a desktop app?
<sunesito> i install via apt-get
<zyga> is this a NAS with a screen?
<sunesito> yes...
<sunesito> hdmi port
<zyga> :D
<zyga> nice, so a nas / desktop :)
<sunesito> yes
<sunesito> i need to reinstall the ubuntu....and now i have this problem...but i think the problem is in the ubuntu packages
<mup> PR snapd#6103 opened: tests: split nested vm suite on core and classic and new snapshots test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6103>
#snappy 2018-11-07
<zyga> good morning
<mvo> doko: fyi - all adt tests on snapd are green except s390x, I take care of this one today
<mvo> hey zyga, good morning
<zyga> :)
<pstolowski> morning
<Chipaca> mo'in
<Chipaca> mvo: EHLO
<mup> PR snapcraft#2394 opened: build providers: fix osx non base and injection <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2394>
<Chipaca> mvo: I haven't merged #6093 because I hear it's wanted in 2.36 and don't  know if we still need to squash-merge things that need that
<mup> PR #6093: daemon: spool sideloaded snap into blob dir <Created by chipaca> <https://github.com/snapcore/snapd/pull/6093>
<Chipaca> mvo: or should I write a separate PR and target it at the release branch?
<mvo> Chipaca: thats fine, pedronis wanted to have a quick look at 6093 before it is merged
<mvo> Chipaca: and once its in (ideally via squash merge) we can cherry pick
<Chipaca> ok
<pstolowski> Chipaca: hey! one question to your userid&snapshots fix, ready to re-approve once clarified
<pedronis> mvo: Chipaca: looking at it now
<mup> PR snapcraft#2393 closed: lifecycle: make snapcraft init template use > not | <Created by sparkiegeek> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2393>
<mup> PR snapd#6102 closed: overlord/snapshots: survive an unknown user <Created by chipaca> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6102>
<pedronis> mvo: Chipaca: commented. mostly nitpicks that could go in a follow up but a bit worried at the cost vs frequency of cleanupOldTemps
<Chipaca> pedronis: ah, I'll add a time check thing
<Chipaca> pedronis: i got confused because i have a different pr that has this already :-)
<Chipaca> not pr, a commit
<Chipaca> a stash even
<Chipaca> the one with warnings for devmode things :-)
<mborzecki> morning
<pstolowski> hey mborzecki
<zyga> hey mborzecki
<mborzecki> stuck in a slightly boring talk, doing reviews :)
<zyga> haha
<pedronis> mvo: Chipaca:  https://github.com/snapcore/snapd/pull/6101 is green but doesn't have a description/motivation
<mup> PR #6101: switch travis unit tests to xenial <Created by chipaca> <https://github.com/snapcore/snapd/pull/6101>
<mborzecki> btw. there should be some video streams at http://codedive.pl/ in case anyone is interested
<diddledan> desktop helpers part for the post-remote-parts world https://www.irccloud.com/pastebin/fwLMLqKc/
<mup> PR snapcraft#2395 opened: Fixed Errors of macOS environment <Created by hsbt> <https://github.com/snapcore/snapcraft/pull/2395>
<Chipaca> pedronis: i'll add motivation
<Chipaca> pedronis: it's not a strong one right now :-) but will be someday
<Chipaca> soon i hope
<pedronis> Chipaca: thx
<pedronis> Chipaca: ah, dist: xenial wasn't a thing until now
<pedronis> ?
<Chipaca> pedronis: it's not a thing until tomorrow, officially
<pedronis> heh
<pedronis> ok
<pedronis> Chipaca: so we should not merge it until tomorrow?
<Chipaca> pedronis: up to us :-)
<Chipaca> pedronis: it's no big secret, tomorrow is when it's supported officially but we're sitting next to them today and tomorrow :-)
<Chipaca> pedronis: we can also say "nah not worth it" and close the pr
<pedronis> Chipaca: no, it's fine, just trying to understand
<mup> PR snapcraft#2394 closed: build providers: fix osx non base and injection <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2394>
<zyga> mvo: https://forum.snapcraft.io/t/lack-of-compiled-locales-breaks-gettext-based-localisation/3758/16
<zyga> locale strikes back
<zyga> I would love for us to include locale in core instead of having layers of hacks like that
<zyga> br
<zyga> brb
<mup> PR snapcraft#2395 closed: Fixed Errors of macOS environment <Created by hsbt> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2395>
<pedronis> Chipaca: I'm going to review your epochs PR, but if I understand correctly is not the full story, we should chat about epochs next week
<cachio> mvo, hey, I see this often on core 18
<cachio> https://paste.ubuntu.com/p/G6GFxSphzs/
<Chipaca> pedronis: +1
<Chipaca> pedronis: AIUI the bit missing is the refresh revving, but I might've missed something else
<mup> PR snapd#6104 opened: snapctl: add "services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6104>
<Chipaca> pstolowski: ^^^ might be of interest to you.
<Chipaca> also, hm, wut, missing services in -h
 * Chipaca investigates
<Chipaca> oh d'oh
<Chipaca> also, also, d'ohÂ² broke unit tests
<pstolowski> Chipaca: thanks, will take a look
<mvo> cachio: when you see this, what is the status of "systemctl status snapd"?
<mvo> cachio: did you managed to reproduce it?
<cachio> mvo, no
<cachio> I cant reproduce it
<mvo> :/
<mvo> ok
<cachio> I just see the error on travis
<cachio> I can create a PR to force it
<mvo> I need to look at this then and try to understand how it can happen, if its frequent it might be worthwhile to add debug: | for that
<cachio> mvo, which debug info do yo uneed
<cachio> just status for snapdÂ¡
<mvo> cachio: systemctl status snapd would be good for a start
<mvo> cachio: maybe journalctl -u snapd as well just to be on the safe side
<mvo> cachio: it might be that its just running too early and no snapd is around at all yet
<mvo> cachio: in which case its probably harmless but let me look at the test again after lunch with fresh eyes
<cachio> ok, I'll create a PR to for that
<cachio> sure
<mup> PR snapd#6105 opened: NOT REVIEW: New task to force error on degraded test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6105>
<oSoMoN> zyga, on fedora with core18, xdg-open doesn't work, is that a known issue?
<oSoMoN> "/usr/bin/xdg-open: 2: exec: snapctl: not found"
<zyga> oSoMoN: no, I don't believe this is know
<zyga> which snapd version?
<zyga> there is an update: https://bodhi.fedoraproject.org/updates/FEDORA-2018-48cc10ba1d
<zyga> could you please test it
<zyga> and report on the update page
<oSoMoN> zyga, ack, will do just after lunch and will keep you posted
<zyga> thank you
<pedronis> mvo: I added some comments to the originally dotfiles PR, about the name and the base declaration bits
<mup> PR snapd#6106 opened: overlord/ifacestate: Handler for hotplug-update-slot tasks <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6106>
<oSoMoN> zyga, the update fixes my issue with xdg-open \o/
<oSoMoN> I'll report on the test page
<zyga> whee, that's great
<zyga> thank you
<mvo> pedronis: thank you!
<zyga> flock unit test randomly failing  https://www.irccloud.com/pastebin/eL5WynJ7/
<andyrock> do snaps have access to /run ?
<zyga> andyrock: to some parts of run, yes
<zyga> it depends on specific path
<andyrock> zyga: e.g. if there is a snap called "random-snap" can I access /run/random-snap ?
<andyrock> otherwise how does it work?
<zyga> andyrock: are you asking if some snap can access /run/random-snap?
<zyga> in general the answer is no
<zyga> in specific case the answer may be yes
<zyga> it is defined by the snap interface system
<zyga> by the set of plugs, slots and the connections between them
<seb128> zyga, the real question is "what would it take to let the livepatch snap write it's status file in /run (so it's auto-cleaned on reboot)" I think
<seb128> andyrock, ^ right?
<seb128> jdstrand, ^
<andyrock> zyga: yes, livepatch snap write a status file to communicate with update-notifier
<zyga> seb128, andyrock a trivial tweak to the interface I suspect
 * zyga looks
<jdstrand> andyrock: the snap already has access to XDG_RUNTIME_DIR, if that is helpful:
<jdstrand> $ sudo hello-world.env |grep XDG_RUNTIME_DIR
<jdstrand> XDG_RUNTIME_DIR=/run/user/0/snap.hello-world
<andyrock> right now that file is in /var/snapd/canonical-livepatch/current/status
<zyga> ah, there's no live patch interface
 * jdstrand is assuming it is the daemon that needs write access to it
<andyrock> but considering that files applies to a boot session would be nice to have it under a "run" directory
<jdstrand> XDG_RUNTIME_DIR still isn't created by anything, byt you can mkdir it and write it there
<andyrock> *considering that the status file
<jdstrand> andyrock: I suggest looking at XDG_RUNTIME_DIR. you don't need any changes to snapd for that
<andyrock> jdstrand: is that directory accessible by the system?
<jdstrand> andyrock: yes
<andyrock> jdstrand: kk. It looks like it's what we need
<andyrock> thx
<jdstrand> oh hrmm, /run/user/0 doesn't exist and the snap can't create it. zyga, that really needs to be fixed somewhere
<jdstrand> andyrock: ^
<mup> PR snapd#6107 opened: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107>
<zyga> (standup)
<jdstrand> zyga: I've always argued that the session manager (ie, systemd) should do it, but it isn't
<zyga> jdstrand: I think we can do it now
<jdstrand> for non-root it all works. we should probably have snapd just create it
<jdstrand> or snap-confine, which is where I think you are going
<zyga> yes
<zyga> snap-update-ns specifically
<jdstrand> andyrock: you will need some snapd support after all
<zyga> anyway, I will think about it
<zyga> andyrock, seb128: can you please file a bug on this
<zyga> OR find one that exists
<zyga> about XDG_RUNTIME_DIR for root
<zyga> I'll assign that to myself
<jdstrand> zyga: note, it needs to preserve the property that the host can see it
<zyga> right
<jdstrand> zyga: thanks!
<seb128> jdstrand, zyga, those are created/destroyed with the corresponding user session, if root has no login/session that's why it doesn't exist
<seb128> it would make more sense to have a /run/livepatch-status
<seb128> but that might require a custom interface for livepath then...
<seb128> unless there is a new rule to allow using "/run/<snap_name>"
<zyga> seb128: I think we could do a custom interface as well
<zyga> jdstrand: ^
<zyga> seb128: there is no such rule today
<seb128> right
<zyga> seb128: perhaps we could add /run/snap.$SNAP_NAME
<seb128> well either way it seems it needs changes in snapd
<zyga> that might be a nice default
<seb128> right
<zyga> seb128: yes, for sure
<seb128> I think it would be useful
<seb128> for others snaps as well
<zyga> I agree
<zyga> and would be easier than a new interface
<seb128> indeed
<zyga> something for 2.36.1 perhaps
<seb128> I like it
<seb128> where should that wishlist be reported? github? forum?
<zyga> seb128: I actually prefer a bug report but it can also be a forum
<zyga> seb128: bug is something I can assign to myself
<zyga> seb128: forum is nicer for discussion
<seb128> k, so basically you want both :)
<seb128> andyrock, want me to open those?
<andyrock> seb128: as you prefer, otherwise I'll do that once I finish what I'm currently working on
<seb128> andyrock, I'm doing it
<zyga> thank you!
<seb128> zyga, https://forum.snapcraft.io/t/snaps-can-not-write-to-run-by-default/8367 and https://bugs.launchpad.net/snapd/+bug/1802112
<mup> Bug #1802112: Snaps can't write to /run by default <snapd:New> <https://launchpad.net/bugs/1802112>
<zyga> thank you
<zyga> pedronis: ^ can you look at this please - if there's agreement to allow snaps to write to /run/snap.$SNAP_NAME then it could be a trivial one liner change for 2.36.1 - the use case is live patch dropping a status file that some part of classic world can look at
<pedronis> zyga: it does sound reasonable and aligned to other things we do, we do need jdstrand input on it tough
<popey> jdstrand: is there a way in which a snap can set network configuration? Specifically setting a static IP address? On core?
<pedronis> zyga: I answered in the bug
<zyga> thank you
 * pedronis break
<zyga> jdstrand: can you please look at https://bugs.launchpad.net/snapd/+bug/1802112
<mup> Bug #1802112: Snaps can't write to /run by default <snapd:New for zyga> <https://launchpad.net/bugs/1802112>
<jdstrand> popey: network-control gives all the raw lowlevel stuff (eg, use of 'ip')
<popey> jdstrand: even on core?
<jdstrand> popey: yes
<popey> awesome
<jdstrand> popey: if you want netplan configuration, then look at network-setup-control
<jdstrand> popey: or if they have network-manager installed, plugs network-manager
<popey> jdstrand: thanks, this is a 'legacy'
<jdstrand> popey: there may be some interplay with netplan that they'll need to work through when using network-control, but network-control will definitely allow them to do stuff. ogra might have tips
<popey> ok, ta
<ogra> popey, https://github.com/ogra1/dashkiosk-image-config netplan-import might be interesting
<popey> the problem is this snap needs to run on core and non-core
<popey> and could run on non-ubuntu
<popey> so needs to special case all the random nonsense ways people set IP addresses etc
<ogra> (copies any "netplan.yaml" file from a USB device you plug into the device and reboots with new network config)
<ogra> oh, ok
<ogra> popey, in any case network-setup-control is enough to replace the config in /etc/netplan ... you want the shutdown interface too and trigger a reboot for it to take effect (netplan generate/apply are not allowed atm)
<pedronis> Chipaca: is #6107 something that was discussed at the summit?
<ogra> to check for core just look for snap_core= in /proc/cmdline (shouldnt be restricted)
<mup> PR #6107: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107>
<Chipaca> pedronis: yes
<Chipaca> pedronis: gustavo's suggestion actually
<Chipaca> pedronis: reasoning  being that the table output isn't too script-friendly
<pedronis> Chipaca: I see, that's a bit true of a lot of our commands tough
<pedronis> Chipaca: is this one particurly egregious?
<pedronis> Chipaca: I mean, do we need a choose your column general strategy instead?
<Chipaca> pedronis: this one is the only one in snapctl afaik
<Chipaca> pedronis: I asked the same thing though,  --column=foo
<Chipaca> pedronis: but, translations
<pedronis> Chipaca: the only one, doesn't sound a statement that will be true forever
 * Chipaca nods
<pedronis> Chipaca: I understand that we tried something for snap list and it was a quagmire
<Chipaca> pedronis: with --format you mean? yes
<pedronis> yes
<pedronis> Chipaca: I understand I'm not being super constructive, but I'm trying to understand if it's the start of a slippery slope
<Chipaca> pedronis: I understand :-)
<Chipaca> zyga: ping
<zyga> yes sir
<Chipaca> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1802124
<mup> Bug #1802124: Error installing chromium-mir-kiosk on RPi3/edge <snapd (Ubuntu):New> <https://launchpad.net/bugs/1802124>
<Chipaca> zyga: does this mean we need to move those to per-arch code?
<zyga> yes
<Chipaca> zyga: note the lookup table thing is already per-arch
<zyga> I though that was exactly what you did
<zyga> aaah
<Chipaca> zyga: ah indeed
<zyga> I thought it was all per-arch
<zyga> yes, I'm afraid that's needed
<zyga> Chipaca: while I have you
 * Chipaca is had by very few people
<Croepha> does the snap environment use the core system's ld-linux-x86-64.so.2 or can you ship your own? having glibc version issues
<zyga> quick question about this particular piece of code https://github.com/snapcore/snapd/blob/master/run-checks#L180
<Chipaca> zyga: shoot
<Chipaca> Croepha: why are you having glibc version issues
<zyga> Chipaca: is it legitimately complaining about this usage: https://github.com/snapcore/snapd/pull/6095/files#diff-36a23153f5bbd7bffd11c24597ac50fdR238
<mup> PR #6095: packaging/opensuse: stop using golang-packaging <Created by zyga> <https://github.com/snapcore/snapd/pull/6095>
<Chipaca> Croepha: is your snap classic, or strict?
<Croepha> Chipaca: im shipping a newer version of libpython and it requires a newer version of glibc than what is in core, I wasn't using strict, I was using try, right now im just using a chroot directory in my home while I do some development iterations
<Chipaca> Croepha: you get glibc mismatches because you build against a different glibc than the one in the core you specify
<Chipaca> Croepha: I seriously doubt libpython requires a  particular glibc version, although it's quite likely that a particular version of libpython is only available in a distribution with a newer glibc
<Chipaca> Croepha: you can probably build the newer libpython against the older glibc
<Chipaca> Croepha: or you can use a newer base
<Chipaca> Croepha: or you can tell snapcraft to ship your own libc in the snap
<Chipaca> Croepha: in general the last one is not a good idea
<Chipaca> but, it's there if you need it
<pedronis> mvo: question, do we check when installing if bases have actually type: base,  I looked around and didn't find such a check
<Chipaca> (you probably don't need it)
<Croepha> ok, thanks Chipaca
<Chipaca> zyga: thinking about it
<zyga> yes?
<Chipaca> zyga: i mean, the usage is ok, although I don't know what an empty entry in GOPATH does
<zyga> in this specific case it's never empty
<zyga> suse is a bit looney that it sets GO{ARCH,OS,PATH,ROOT} for all users
<zyga> there's a /etc/profile.d/go.sh
<zyga> that contains values matching some compiler (via alternatives)
<pedronis> zyga: are these layout docs:  https://forum.snapcraft.io/t/snap-layouts/7207 ? does it need to mention that the experimental flag is no more now
<mvo> pedronis: not sure, I need to look. will do so after the meeting
<pedronis> mvo: thank you
<zyga> pedronis: that's correct,
<zyga> pedronis: I will amend it to say that since snapcraft 3.0 that uses bases and since snapd 2.36 it is not experimental anymore
<pedronis> thanks
<Chipaca> zyga: so, i've got a fix for you
<zyga> pedronis, degville: I edited https://forum.snapcraft.io/t/snap-layouts/7207 to account for the new reality (enabled since 2.36 and since snapcraft 3.0 with bases)
<Chipaca> zyga: http://paste.ubuntu.com/p/zJPFQnRgX8/
<Chipaca> zyga: bundle that in if you can
<zyga> thank you!
<zyga> yep, I will
<degville> zyga: thanks for the heads-up!
<pedronis> zyga: degville: should layout be a top level topic in the docs? either way I think snap format doc should mention them and link to this
<pedronis> I'm talking about  https://docs.snapcraft.io/the-snap-format/698 -> layout docs
<Chipaca> zyga: the hint was in what exactly was getting highlighted in the output :-)
<zyga> pedronis: I think it should be referenced from the format spec
<zyga> not otherwise top-level IMO
<pedronis> ok
<degville> pedronis, zyga : yep, I agree.
<pedronis> zyga: degville: I left a note for you in the forum topic about this
<degville> thanks!
<pedronis> thank you
<roadmr> Hello folks; we're currently investigating a snap store outage, snap requests may be slow or fail intermittently.
<zyga> oh, thank you for the note roadmr
 * zyga needs coffee
<cachio> roadmr, thanks
<roadmr> snap store should be back to normal now, folks. Thanks for your patience
<pstolowski> Chipaca: re 6104, making it 2 separate PRs (1 PR to just move the old code around) would make review easier
<cachio> mvo, https://travis-ci.org/snapcore/snapd/jobs/451975712#L1234
<cachio> this is the error on degraded with extended debug info
<cachio> mvo, I see some retries to get the catalod
<doko> mvo: snapd failed to build on amd64
<cachio> mvo, but nothins weird apart fo that
<zyga> re
<zyga> roadmr: thank you!
 * zyga got involved in some homework
<mvo> doko: looking
<mvo> cachio: if you are on the system, can you please paste the output of "journalctl -u snapd.seeded.service" and "systemctl status snapd.seeded" ?
<Chipaca> pstolowski|afk: noted
<cachio> cachio, I am not but I'll trigger it again
<cachio> zyga, updating scripts to create tumbleweed image
<Chipaca> pstolowski|afk: not sure i'll be able to do it tonight though but i'll try
<cachio> zyga, it should be ready soon
<Chipaca> yesterday i fell asleep on the train and stuff
 * Chipaca really tired by all this weird "human" interaction
<mup> PR snapd#6108 opened: many: apparmor support for rpm distros <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6108>
<Chipaca> :)
<zyga> cachio: super, thanks
<mup> PR snapd#6108 closed: many: apparmor support for non-AA rpm distros <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/6108>
<zyga> jdstrand: FYI https://github.com/snapcore/snapd/pull/6108#issuecomment-436750366
<mup> PR #6108: many: apparmor support for non-AA rpm distros <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/6108>
<zyga> jdstrand: sorry,  if I knew you were interested in packaging I would have said something
<zyga> I'm working on packaging for a few days now
<zyga> jdstrand: I will propose the stuff I have as soon as https://github.com/snapcore/snapd/pull/6095 lands
<mup> PR #6095: packaging/opensuse: stop using golang-packaging <Created by zyga> <https://github.com/snapcore/snapd/pull/6095>
<mup> PR snapd#6095 closed: packaging/opensuse: stop using golang-packaging <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6095>
<mup> PR snapd#6108 opened: many: apparmor support for non-AA rpm distros <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6108>
<cachio> zyga, finally the image ready
<cachio> zyga, and I could create a script to automate the process
<zyga> cachio: super
<zyga> I can run a tumbleweed test quickly
<cachio> yes
<cachio> just use image: opensuse-tumbleweed-64
<zyga> thank you, I will report back
<cachio> zyga, great, thanks
<rogpeppe> what's the story about running external executables inside a snap? I'd like to publish a couple of snaps that work on Go source code, and these days the only way to do that is by invoking the go command. Should I package up the go compiler into my snaps too?
#snappy 2018-11-08
<mup> PR snapd#6109 opened: interfaces/apparmor: allow access to /run/snap.$SNAP_INSTANCE_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6109>
<mup> PR snapd#6110 opened: spread.yaml: add openSUSE Tumbleweed <Created by zyga> <https://github.com/snapcore/snapd/pull/6110>
<mup> PR snapd#6111 opened: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> jdstrand: FYI https://github.com/snapcore/snapd/pull/6111 is the thing I was talking about
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<erio> how do I say "rain is coming", because you saw on the forecast, in a normal conversation?
<zyga> Good morning
<mup> PR snapd#6093 closed: daemon: spool sideloaded snap into blob dir <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6093>
<mvo> hey zyga
<mvo> zyga: 6110 has two test failures in the new tumbleweed tests
<mvo> zyga: and 6109 has some new comments
<mup> PR snapd#6101 closed: switch travis unit tests to xenial <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6101>
<zyga> Thank you
<zyga> Tumbleweed failed for me locally but I wanted to share this with Sergio
<zyga> Iâll get a shower and be back soon
<zyga> I posted 6111, curious to know what you think
<mvo> zyga: sure, thanks
<zyga> Man, I can barely see where Iâm going in this fog
<pstolowski> morning
<mvo> hey pstolowski - good morning
<zyga> re
<zyga> good morning pawel
<zyga> mvo: can I push https://github.com/snapcore/snapd/pull/6109 for 2.36.1 as well?
<mup> PR #6109: interfaces/apparmor: allow access to /run/snap.$SNAP_INSTANCE_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6109>
<mvo> zyga: yeah, please tag it
<mvo> zyga: 6096 needs a second review
<zyga> looking
<mvo> zyga: I will release 2.36.1 once this is green
<zyga> done
<mvo> ta
<doko> mvo: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/s/snapcraft/20181030_213532_e6942@/log.gz  this is in bionic-proposed. could you have a look? that's the python3.6 3.6.7 update
<mvo> doko: snapcraft is sergiusens baby - I assume this happens all the time and is not a one-off race or something in their suite?
<mvo> doko: hm, hm, "{{{The package python3-dev has unmet dependencies:}}}"
<mvo> doko: is/was there some inconsistency in the archive when this ran maybe?
<doko> I'll run it again
<mvo> ta
<zyga> mvo: shall I squash https://github.com/snapcore/snapd/pull/6096
<mup> PR #6096: spread.yaml: add more systems to the autopkgtest and qemu backends <Created by mvo5> <https://github.com/snapcore/snapd/pull/6096>
<sergiusens> mvo: adopted baby, its your original baby formed with another Michael, you have commit number 3 after all ð
<mvo> sergiusens: haha
<mvo> sergiusens: true
<mup> PR snapd#6096 closed: spread.yaml: add more systems to the autopkgtest and qemu backends <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6096>
<mup> PR snapd#6112 opened: correct localInstallCleanup doc comment <Created by pedronis> <https://github.com/snapcore/snapd/pull/6112>
<ackk> hi, I'm having a hard time getting a python-based core18 classic snap to work. if I install it on xenial, I get this: https://paste.ubuntu.com/p/PbPq2bp5md/
<ackk> Chipaca, hi, so I've been trying to fix that snap of mine wrt python3, but I see this issue on xenial: https://paste.ubuntu.com/p/PbPq2bp5md/
<ackk> Chipaca, is snapcraft doing something wrong with python3?
<zyga> ackk: looking at your log
<ackk> thanks zyga
<pedronis> Chipaca: hi, #6112
<mup> PR #6112: correct localInstallCleanup doc comment <Created by pedronis> <https://github.com/snapcore/snapd/pull/6112>
<zyga> The x3 vs x5 aspect is curious
<zyga> Is the python interpreter present in x5 as well?
<Chipaca> ackk: classic snap?
<ackk> zyga, ah sorry, that was because I run from history, x5 is the last attempt
<ackk> Chipaca, yes, classis, python, core18
<ackk> *classic
<zyga> Classic as in classic confinement?
<Chipaca> ackk: snap list --all sshoot ?
<Chipaca> pedronis: ah good catch and thanks
<ackk> Chipaca, https://paste.ubuntu.com/p/RvDdMMzW2g/
<ackk> zyga, yes
<ackk> is there another type of classic? :)
<zyga> Well classic system
<Chipaca> ackk: a snap can be classic, a system can be classic, and there is a devmode snap that's called "classic"
<ackk> ah I see
<zyga> It is the classic problem of name overloading ;)
<ackk> (I'm testing in a xenial lxd if that matters)
<ackk> zyga, classic joke, classic :)
<Chipaca> ackk: you built this on 18.04?
<ackk> Chipaca, yes
<Chipaca> ackk: on 18.04, what happens when you run python from the snap like that?
<Chipaca> ackk: that is
<Chipaca> ackk: please, snap run --shell sshoot, start python3 in there, let me know how it goes (i'll have more things for you to do in the python)
<Chipaca> pstolowski: didn't we have a way to disable a service froma hook?
<ackk> Chipaca, it starts (and "sshoot" also works)
<pstolowski> Chipaca: well, not really, the only way to do something with services from hook is via snapctl
<Chipaca> ackk: import _crypt
<Chipaca> ackk: print(_crypt)
<Chipaca> pstolowski: grmbl
<Chipaca> pstolowski: i'll see if i can fix this :-)
<ackk> Chipaca, <module '_crypt' from '/snap/sshoot/x1/usr/lib/python3.6/lib-dynload/_crypt.cpython-36m-x86_64-linux-gnu.so'>
<zyga> x1!
<ackk> zyga, different container, this is bionic
<zyga> Ah
<Chipaca> pstolowski: where are hooks documented, for snap developers?
<Chipaca> ackk: can you ldd the python binary in the snap?
<Chipaca> ackk: from inside the snap
<sparkiegeek> Chipaca: oh you...
<Chipaca> sparkiegeek: i have a developer wanting to use them
<pstolowski> Chipaca: https://forum.snapcraft.io/t/supported-snap-hooks/3795 and https://forum.snapcraft.io/t/interface-hooks/8214
<Chipaca> pstolowski: thanks
<Chipaca> pstolowski: I'm also going to look into disabling :-)
<pstolowski> nice
<Chipaca> sparkiegeek: or wait, have I continued to break the store
<sparkiegeek> Chipaca: nah, not today
<ackk> Chipaca, https://paste.ubuntu.com/p/kjFbQccfQV/ (bionic and xenial)
<ackk> Chipaca, isn't the last entry problematic? it points to the system library
<Chipaca> ackk: yes
<Chipaca> ackk: i think so at least :-)
<Chipaca> ackk: there's this other little-known classic python snap we could look at for inspiration
<Chipaca> ackk: schnappcraft, or something like that, probably about getting drunk
<ackk> lol
<ackk> Chipaca, isn't snapcraft also classic? :)
<Chipaca> ackk: but not core18 which might be the extra quirk here
<ackk> right
<ackk> Chipaca, so, is that a core18 bug? 'cause the library isn't there in core18
<pstolowski> degville: hey, just noticed in https://forum.snapcraft.io/t/interface-hooks/8214 - is the colon at the end of "Interface hooks can read the attributes of the affected plug and slot by using the snapctl command, as defined by the snapâs snap.yaml:" sentence intended?
<mup> PR snapd#6109 closed: interfaces/apparmor: allow access to /run/snap.$SNAP_INSTANCE_NAME <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6109>
<ackk> Chipaca, indeed on xenial that's a broken link
<degville> pstolowski: no - good spot, thanks.
<ackk> Chipaca, https://paste.ubuntu.com/p/h7MmBYgjjp/
<ackk> mvo, ^ maybe you have insight
<mvo> ackk: I lack context, is the problem that the symlink is absolute?
<ackk> mvo, no, the problem is that it's broken on xenial, as the ld.so version is different
<ackk> mvo, should core18 perhaps include ld.so as well?
<ackk> mvo, it's 2.23 not 2.27 on xenial
<mvo> ackk: I think the problem is actually that this link needs to be relative, i.e. /lib64/ld-linux-x86-64.so.2 must point to ../lib...
<mvo> ackk: let me look into this
<ackk> mvo, ah, so it should point to the snap
<mvo> ackk: yeah, the file is there
<mvo> ackk: there in the snap
<ackk> mvo, ah so it's just a symlink issue
<Chipaca> ackk: sorry i'm at the summit and only have half an ear for this right now ;-)
<mvo> ackk: yeah, looking at the fix now
<ackk> Chipaca, np it seems mvo has found the culprit
<Chipaca> nice
 * Chipaca hugs mvo 
<ackk> Chipaca, mvo, thanks
<mup> PR snapd#6113 opened: overlord/ifacestate: handler for hotplug-connect task <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6113>
<Chipaca> mvo: sudo find /snap/core18/current/ -type l -printf "%l from %p\n" | grep  ^/
<mup> PR core18#88 opened: hooks: make ld-so symlink in /lib64 relative <Created by mvo5> <https://github.com/snapcore/core18/pull/88>
<mvo> Chipaca: hrm, that are many
<mvo> ackk: the above PR should fix the issue
<Chipaca> mvo: I don't know if they're all bad though, but yes there are :-)
<Chipaca> pstolowski: "snapctl stop --disable theservice" from within the snap works
<Chipaca> pstolowski: from the install hook i  mean
<mvo> Chipaca: *sigh* thanks :)
<pstolowski> Chipaca: ah, of course, i forgot stop had the flag /o\... sorry about that
<ackk> mvo, cool, thanks
<mup> PR snapd#6112 closed: correct localInstallCleanup doc comment <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6112>
<zyga> mvo: thank you for cherry picking into 2.36
<pedronis> Chipaca: I did a first pass on the epochs PR, I understad your focus is elsewhere this week, either way let me know if you disagree when you can look at it
<mvo> zyga: my pleasure - we are complete now, I wait for travis and once its green will do 2.36.1 (maybe after lunch, depending on travis)
<zyga> super
<mvo> zyga: in the meantime I'm packaging/patching fontconfg like its 1998
<zyga> mvo: does current fontconifg support older cache formats/
<zyga> as in, can it write all formats from one binary
<mvo> zyga: not afaict
<zyga> mvo: tumbleweed fails on gpg key management from snap keys and all
<zyga> I wonder if this is a sign of trouble to come in disco with new package sync
<zyga> but I won't look more today
<zyga> back to user mounts
<zyga> I'll do a brief packaging update with 2.36.1 but other than that I'm happy with current state
<pedronis> zyga: what gnupg does it have?
<zyga> https://www.irccloud.com/pastebin/rUQqGjEg/
<zyga> 2.2.10
<pedronis> we'll need to dig
<Chipaca> pedronis: thank you. I'll get to it tomorrow, i expect
<Chipaca> tomorrow i'll be staying home
 * zyga is on the road today but trying to focus 
 * zyga is in a car dealer shop, on headphones listening to music, writing C on opensuse
<zyga> I wonder if people think I'm some kind of evil nasty hacker
<zyga> oh, I also have a dog with me
<zyga> so maybe they are scared to check :D
<pstolowski> zyga: is you screen flooded with wall of text in a matrix-style all the time? ;)
<ahasenack> is there still no way to remove a snap config option once set?
<ahasenack> snap never forgets?
<pedronis> ahasenack: correct,  best approximation is setting to empty string or emptying a larger context
<ahasenack> what does "emptying a larger context" mean?
<pedronis> if you have foo.bar and foo.baz setting foo to {}, not saying it's useful in general
<ahasenack> ah, by larger you meant something like parent
<pedronis> yes
<ahasenack> ok, thx
<pedronis> we do plan to allow some resetting, still haven't happened yet
<mup> PR snapd#6052 closed: snap, store, overlod/snapstate: always send epochs <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6052>
<zyga> pstolowski: hollywood has a purpose ;-)
 * zyga is back home
<mup> PR snapd#6114 opened: Handler for hotplug-disconnect task <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>
<Chipaca> zyga: got a weird snap-exec error about not finding a profile that went away with removing and reinstalling a snap, is this something you'd be interested in?
<cachio> mvo, hey
<cachio> mvo, did you see the log I sent you yesterday?
<cachio> does it help?
<zyga> Chipaca: indeed
<zyga> Chipaca: can you tell me more
<pedronis> zyga: pstolowski: did we end up reusing/abusing addImplicitSlots for hot plug slots as well?
<Chipaca> zyga: i'm waiting for a copy of the problem
<pstolowski> pedronis: yes
<zyga> pedronis: I believe so
<pedronis> :/
<pstolowski> pedronis: addImplicitSlots now looks also into the state ("hotplug-slots" map)
<zyga> what do you think should happen there?
<pedronis> we should really find a different way to factor that
<pedronis> it's not the hot plug part I'm not keen on
<pedronis> it's as usual the addImplicitSlot sprinkled around part
<pedronis> mixing the two doesn't make things better tough
<zyga> I had one idea with keeping well-know snap.Info for core/snapd and only ever handling implicit slots in one single spot at one time
<zyga> this is what I did in one of the exploratory branches long ago when core18 was being prepared
<zyga> the advantage was that we traded complexity all around snap info
<Chipaca> zyga: http://paste.ubuntu.com/p/KzM4NGdRQs/
<zyga> for special casing one snap
<mup> PR snapcraft#2396 opened: Partial Revert "build providers: fix osx non base and injection" <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2396>
<pedronis> pstolowski: zyga: anyway things are as they are, we really need to clean this up at some point
<pedronis> tough
<zyga> I agree, we just need to write down what we are willing to accept
<zyga> Chipaca: 1411 was setup-profiles
<zyga>         "ready-time": "2018-11-08T12:41:47.570494396Z"
<zyga> this is when it was ready
<pstolowski> pedronis: yes i agree, i just didn't want to get into rabbit of refactoring before hotplug, similiar to what happened with various refactorings before interface hooks
<pstolowski> *rabbit hole
<zyga> pre-refresh hook was 1406
<zyga> it was ready on         "ready-time": "2018-11-08T12:41:47.570530073Z"
<zyga> so it was after
<zyga> do you have kernel logs from the system?
<zyga> can you extract the range a second before 12:41:47
<Chipaca> zyga: person's now in a meeting, but i'll ask
<zyga> woa,
<zyga> actually
<Chipaca> zyga: probably yes
<zyga> its not !
<zyga> I misread
<Chipaca> not ! <- not not
<zyga> the sub-second parts show that setup-profiles was after the hook?
 * zyga double checks that
<Chipaca> zyga: do vs undo?
<zyga> eh, perhaps
<zyga> this sucks, I wish we had better data there
<Chipaca> yes
<zyga> kenrel logs will have useful facts but probably not that resolution (though I may be wrong)
<Chipaca> zyga: easiest would be to ask them to 'dmesg -H | pastebinit', would that be enough?
<zyga> yes
<Chipaca> asked
<Chipaca> but, they're in a meeting
<Chipaca> so i'll let you know :-)
<Chipaca> zyga: http://paste.ubuntu.com/p/MfKnvp8bD7/
<zyga> [  +0.000004] audit: type=1400 audit(1541680843.472:176): apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 profile="/snap/core/5742/usr/lib/snapd/snap-confine" name="snap.code-oss.hook.pre-refresh" pid=15781 comm="snap-confine"
<zyga> [  +0.005188] audit: type=1400 audit(1541681530.284:182): apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.code-oss.hook.pre-refresh" pid=17895 comm="apparmor_parser"
<zyga> so we certainly tried to run the hook before we loaded profiles
<zyga> pstolowski: ^ can you tell me from the top of your head, the pre-refresh hook, when is it ran in the sequence of snap refresh?
<zyga> pstolowski: and if I have a snap with no revisions and install it, would that hook run?
<zyga> Chipaca: can someone report a bug about this
<zyga> for tracking
<zyga> I'll assign it to myself
<pstolowski> zyga: from top of my head not, but let me take a quick look. first off, it only runs if refreshing
<zyga> Chipaca: if you can you please at least collect the basic info about the snap (confinement, hooks) and if this can be reproduced (snap remove foo; ... snap install foo # KABOOM)
<zyga> pstolowski: I wonder if we can ever do this:
<zyga> pstolowski: run pre-refresh hook on fresh install
<zyga> pstolowski: when there's no prior revision
<pedronis> pstolowski: for context, I'm trying to read the already landed hot plug code and also looking at recent hot plug PR that have landed
<zyga> pstolowski: and it somehow ends up in a sequence where we haven't installed the snap yet so it doesn't have security setup done
<pstolowski> zyga: it runs after mount-snap, before stop-snap-services, remove-aliases, unlink-current-snap and before switching to the new revision
<pstolowski> pedronis: ok. the biggest chunk that landed was udevmonitor stuff, after that only very small bits to set the stage
<pedronis> zyga: how can it be not installed if it's a refresh
<zyga> pstolowski, pedronis: about implicit slots, I have a feeling it would be good for snapd to track the implicit system slots and hot plug slots explicitly in ifacestate
<zyga> as a first step towards refactoring
<pedronis> isn't that what the current code does?
<zyga> pedronis: I don't know yet
<zyga> pedronis: but the hook profile was not replaced
<zyga> it was _loaded_
<zyga> so it seems like it was loaded for the first time at that stage
<zyga> and that can only happen if the snap was never installed (even before because of a bug in profile removal code)
<pedronis> zyga: btw relatedly remember that you have an open task about merging setup/remove-profiles into *link* tasks
<zyga> pedronis: yes, that's true
<zyga> pedronis: though awe need to write down TODOs and schedule them
<zyga> *we
<pedronis> zyga: yes, we do need to do that
<pedronis> this is an long standing open one though, not saying it's a priority now
<zyga> pedronis: I have a hunch that we ran the hook from this snap, the one being installed
<pedronis> just reminding it because it's related to this area
 * zyga nods
<pstolowski> this would be pretty unexpected given that we run it before current link changes and before setup profiles
<zyga> right
<zyga> but that's how it looks like
<zyga> before setup profiles for sure
<pedronis> pstolowski: I'm seeing some small typoes etc going over the code, if I don't see anything major I will do a small PR with tweaks if it's ok with you
<Chipaca> any idea why 'snap run --strace snap.app args' would just print "exit status 1"
<Chipaca> ?
<pstolowski> pedronis: sure, np, thanks
<zyga> Chipaca: hmmm, strace it ;)
<zyga> jokes aside, probably no strace?
<pedronis> pstolowski: I'm confused by ensureUniqureName,  it seems to remove "-" when clearing the suffix, but is not adding "-" when attaching the suffix
<mup> PR snapd#6115 opened: cmd: update autogen.sh for opensuse <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6115>
<Chipaca> zyga: they have strace
<pedronis> pstolowski: it seems to be by design, it's tested behavior, but is not documented/explained in the comment
<zyga> pedronis: https://github.com/snapcore/snapd/pull/6116 is the simplified feature flag storage for snap-confine
<mup> PR snapd#6116 opened: cmd/libsnap: add simplified feature flag checker <Created by zyga> <https://github.com/snapcore/snapd/pull/6116>
<mup> PR #6116: cmd/libsnap: add simplified feature flag checker <Created by zyga> <https://github.com/snapcore/snapd/pull/6116>
<Chipaca> zyga: https://dpaste.de/FNWL/raw
<zyga> Chipaca: lookking
<Chipaca> zyga: not helping :-)
<zyga> Chipaca: denials
<zyga> ?
<zyga> Chipaca: if you want I can jump into standup HO and you can walk me through this in the next 15 minutes
<pedronis> zyga: what's the context for that
<pstolowski> pedronis: indeed, just found the PR https://github.com/snapcore/snapd/pull/5782 ; it was requested in the review - see https://github.com/snapcore/snapd/pull/5782#discussion_r217018767
<zyga> pedronis: we need to learn about enabled experimental features from snap-confine and snap-update-ns
<mup> PR #5782: ifacestate: helpers for generating slot names for hotplug <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5782>
<zyga> pedronis: this is the idea that Gustavo presented (just stat a file) in response to the facts PR
<pedronis> pstolowski: is not super clear from the discussion tough that it needs to be removed, if it's then not added
<Chipaca> zyga: http://paste.ubuntu.com/p/XVVzYWNHR7/
<pedronis> pstolowski: the test for sure look weird
<ogra> jdstrand, did you see https://bugs.launchpad.net/bugs/1802124 yet ?
<mup> Bug #1802124: Error installing chromium-mir-kiosk on RPi3/edge <snapd (Ubuntu):New> <https://launchpad.net/bugs/1802124>
<zyga> Chipaca: this is a snap in a container?
<zyga> Chipaca: I suspect that may not work fully
<zyga> Chipaca: ah, parallels VM
<zyga> bug report: on a mac, running parallels, running ubuntu, running lxd as a snap, running another version of ubuntu, running a snap with --strace is not supported
<pedronis> pstolowski: also I would it work if the base name ends with digits?
<jdstrand> ogra: uhh, there is extra code in this section
<ackk> mvo, is "core" needed even if a snap depends on "core18" ?
<pedronis> pstolowski: we trim only one digit?
<pedronis> how do we know it's enough
<ogra> jdstrand, yeah, sseems to be https://github.com/snapcore/snapd/commit/093b3662047123fe684a0d1dae27775593f1dc1f
<jdstrand> Chipaca: hey, seems you fiddled with ptrace_* for PTRACE_GETFPXREGS? (see https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1802124). looks like there is an armhf case
<mup> Bug #1802124: Error installing chromium-mir-kiosk on RPi3/edge <snapd (Ubuntu):New> <https://launchpad.net/bugs/1802124>
<pedronis> pstolowski: this line is very weird: https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/hotplug_test.go#L243
<jdstrand> ogra: there is a commit after that which is meant to address archs without fp
<ogra> ah
<jdstrand> and with fp
<mvo> ackk: you shouldn't need core if you just depend on core18
<ackk> mvo, that's weird, we have a (strict) snap that doesn't work if you don't have core
<mvo> ackk: oh, please tell me more
<mvo> ackk: how can I reproduce this?
<pedronis> pstolowski: to be clear wasn't my intention to rehash already landed code, but this bit looks weird coming fresh to it
<jdstrand> Chipaca: it looks like the policy isn't conditionally adding/removing the fp variants
<ackk> mvo, https://pastebin.canonical.com/p/kTv7H5Q65Q/
<ackk> mvo, i have core18 installed only
<ackk> if I install core, it works
<pedronis> pstolowski: also that function is not used yet, is that right?
<pstolowski> pedronis: no, we take entire numeric suffix with strconv.Atoi(proposedName[len(prefix):]); then increment it until we have unique name as a whole. the point is to generate unique name and the example slot3-5 -> slot36 may look weird but is guaranteed to be unique
<ackk> mvo, this is a proprietary snap unfortunately, lemme see if I can get you something that you can try
<mvo> ackk: aha, interessting, I think you hit a bug, let me look at this
<mvo> ackk: its ok, I can probably trigger it somehow, I suspect its a bug with snap-confine that it does not use the right base when it runs the hooks
<pstolowski> pedronis: it is used in the huge hotplug PR, but not in master yet, no
<ackk> mvo, ah I see
<zyga> ackk: interesting
<zyga> we need to be told of the base explicitly
<zyga> another thing we could fix with facts alone :/
 * zyga looks
<zyga> we pass --base every time there's a base defined in the snap
<zyga> this is the code path used both by hooks and by apps
<pedronis> pstolowski: why do we remove the "-" ?
<pedronis> pstolowski: it just seems a mix of two version of the code, I don't understand how it relates to uniqueness
<mvo> zyga: hm, apparently something is not quite wired up in the code path :/
<mvo> zyga: I do remember work on this
<mvo> zyga: anyway, will look after the meeting
<zyga> k
<ackk> mvo zyga thanks
<pedronis> pstolowski: it also means slot3-5 and slot35 will both produce slot36, I don't know if thats a feature or a bug
<zyga> mvo: what is odd is that for hooks we parse the revision
<zyga> and use that
<zyga> from snap.Revision
<pstolowski> pedronis: that's not going to be a problem
<zyga> for apps we just use R(0)
<Chipaca> jdstrand: i thought zyga was looking into fixing the PTRACE thing, but yes
<pstolowski> pedronis: at any given point the function is guaranteed to generate a unique name
<pedronis> pstolowski: again, can base name end in numbers?
<Chipaca> jdstrand: I fiddled with them because they failed to build
<jdstrand> Chipaca: I don't know-- ogra pinged me about it
<Chipaca> jdstrand: so now we have a runtime failure
<Chipaca> because that's life
<pedronis> pstolowski: to create, what, slot names?
<pedronis> pstolowski: those also need not to too confusing
<pstolowski> pedronis: do you mean "slot1234" ?
<zyga> mvo: I'm sorry, hooks use --revision from snap run
<zyga> not from snap info
<pstolowski> pedronis: sorry, im confused by what do you mean by base?
<kjackal> Hi snappy people, I am trying core18 because of the layouts and I get this error: "cannot update snap namespace: cannot create writable mimic over "/snap/microk8s/x1/": permission denie"
<pedronis> pstolowski: you start from a name that might not be unique, I suppose the output of suggestedSlotName ?
<pedronis> and then you make it unique
<pstolowski> pedronis: yes that's right. btw, standup
<jdstrand> zyga: so, we perhaps probably shouldn't be failing with error here. we ignore unknown syscalls. perhaps we should ignore these unknown PTRACE args. *or* we mock them up like with AF_IB, AF_MLPS, etc
<jdstrand> zyga: honestly, I was surprised we didn't do the latter, but I wasn't involved in that build pr
<zyga> (standup)
<jdstrand> that's the extent of my thoughts
<jdstrand> actually that's not true
<jdstrand> zyga: readNumber could return something to signify skipping and continue the loop (silently ignore the rule)
<zyga> not sure if this is what we should do, but I'll reply after the call
<kjackal> jdstrand: I am following the your steps on for a strict microk8s. Got snapcraft 3.0 that has layouts, updated the snapctaft.yaml with base: core18, applied your patch. It seems to compile but failes in the install hook with https://pastebin.ubuntu.com/p/mcXnz52NkQ/
<jdstrand> kinda 6 of 1. AF_IB we use a #define. we could #define here, but is that #define the same across archs? if not, skip seems reasonable. I don't think I care for browser_support.go having to understand arch-specific details about fp/fpx
<jdstrand> kjackal: sounds like there is an apparmor denial in the snap-update-ns profile. can you check you log?
<jdstrand> zyga: ^ (6 of 1 comment; but also fyi kjackal's)
<roadmr> jdstrand: hy there! Hey a question - for the purpose of e.g. snap track approval, who other than Gustavo and Mark qualifies as an architect? the post detailing this just says "etc"
<kjackal> jdstrand: zyga: indeed there is this "audit[22699]: AVC apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-upda
<kjackal> te-ns.microk8s" name="/tmp/.snap/snap/microk8s/x1/" pid=22699 comm="3" srcname="/snap/microk8s/x1/" flags="rw, rbind"
<kjackal> N" that does not tell me much
<jdstrand> roadmr: no one. perhaps pedronis now? if we add pedronis, we should update the docs
<roadmr> \o/
<roadmr> we should add him, he rocks :)
<kjackal> This looks similar https://forum.snapcraft.io/t/core18-issues/5216
<jdstrand> kjackal: that is a different issue. I didn't test with core18. this might be a change relevant to that or new PRs in this area. actually, zyga did land some stuff to make it no longer experimental... need his input
<zyga> I'm out of touch with this issue now
<zyga> still in a call
<zyga> is there a report about it anywhere or should I scan the backlog on irc?
<jdstrand> zyga: there are two unrelated issues now. the fp/fpx that we discussed and a sun denial with microk8s using layouts with core18
<jdstrand> that kjackal brought up
<zyga> jdstrand: aha, can we get a paste of the mount profile and of the apparmor profile for sun?
<jdstrand> zyga: afaik, it is all backscroll
<jdstrand> kjackal: ^
<zyga> kjackal: ^ if you know how to collect the two please do
<zyga> kjackal: otherwise ask
<zyga> kjackal: essentially /var/lib/snapd/apparmor/snap-update-ns.$foo
<zyga> and /var/lib/snapd/mount/snap.$foo.fstab
<zyga> jdstrand: I wrote a branch where I keep a log of all the ops done by snap-update-ns
<zyga> I need to clean it up and propose
<zyga> it is very useful for debugging
<zyga> kjackal: you can also set SNAPD_DEBUG=1 and run the app to see more debug
<jdstrand> zyga: sounds handy
<zyga> mvo: so the issue
<kjackal> wait up zyga. My guess is you want something from /var/lib/snapd/apparmor/profiles/ . This is where the snap-update-ns-* is . However I do not see snap-update-ns.microk8s. What is $foo?
<mup> PR snapcraft#2397 opened: cmake plugin: use native primitives <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2397>
<mup> PR snapcraft#2398 opened: gnome extension <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/2398>
<zyga> cachio: please just remind me how that was invoked,
<kjackal> same for  /var/lib/snapd/mount/snap.$foo.fstab
<zyga> kjackal: $foo is snap name
<zyga> kjackal: did this snap have a hook that exploded on install?
<zyga> if so the installation would be reverted
<zyga> kjackal: and the corresponding files removed
<zyga> kjackal: if so my suggestion would be to remove all hooks to debug this (^ no way to install a snap without hooks or keep it broken)
<zyga> mvo: so the issue
<zyga> mvo: snap-confine runs snap-device-helper
<zyga> mvo: with hardcoded locations
<kjackal> ok, trying this now
<zyga> mvo: that match core and ubuntu
<zyga> mvo: this is done after pivot root, so in the mount namespace of the snap already
<mvo> zyga: right, don't we bind mount things from the host (/usr/lib/snapd) into the base ?
<zyga> mvo: yes that's right
 * ogra hugs kyrofa 
 * kyrofa hugs ogra back
<kyrofa> Seriously
<ogra> yeah :)
<zyga> DEBUG: performing operation: (disabled) use debug build to see details
 * zyga _hates_ that part of snap-confine
<zyga> security in the way of usability
<zyga> mvo: we don't bind mount it in this case, the base is "core"
<zyga> mvo: so the fact that we cannot find it is surprising
<mvo> zyga: yeah, that is surprising
<zyga> DEBUG: snap-update-ns executable: /usr/libexec/snapd/snap-update-ns
<zyga> perhaps we infer the wrong location?
<mvo> zyga: yeah, that seems to be it - this runs on a libexec idstro?
<zyga> useful debug logs from the fedora29 issue https://www.irccloud.com/pastebin/TTN36845/
<zyga> please have a look, I'm still reading as well
<zyga> yes, fedora 29
<cachio> zyga, test-snapd-udev-input-subsystem.slot
<roadmr> zyga: wow that fedora29 snap is like stitch, destroys everything it touches?
<roadmr> :D
<zyga> roadmr: destroys all bugs
<roadmr> zyga: true that :)
<zyga> https://www.youtube.com/watch?v=JTTwlAT_AwU
<zyga> ha
<zyga> mvo: I understand now
<zyga> ar, wait, no :/
<zyga> hmmm
<zyga> so
<zyga> google:fedora-29-64 /# /usr/lib/snapd/snap-device-helper
<zyga> -bash: /usr/lib/snapd/snap-device-helper: /usr/bin/sh: bad interpreter: No such file or directory
<zyga> initially I thought this is PATH
<zyga> but
<zyga> the file has a wrong shbang
<zyga> it says /usr/bin/sh!
<zyga> not /bin/sh
<zyga> google:fedora-29-64 /root# nsenter -m/run/snapd/ns/test-snapd-udev-input-subsystem.mnt
<zyga> -bash: ls: command not found
<zyga> -bash: /usr/libexec/grepconf.sh: No such file or directory
<zyga> -bash: /usr/libexec/grepconf.sh: No such file or directory
<zyga> -bash: sed: command not found
<zyga> google:fedora-29-64 /# /bin/ls -l /usr/bin/sh
<zyga> /bin/ls: cannot access '/usr/bin/sh': No such file or directory
<zyga> google:fedora-29-64 /# /bin/ls -l /bin/sh
<zyga> lrwxrwxrwx. 1 root root 4 Nov  8 14:18 /bin/sh -> dash
<zyga> mvo: let me propose a quick PR
<ogra> fancy
<mvo> zyga: gar
<zyga> oaoaaah?
<zyga> what
<zyga> the file has /bin/sh in the tree
<roadmr> aioueee
<mvo> zyga: yeah, I just did a git grep
<mvo> zyga: this is strange
<roadmr> (as long as we're resorting to guttural sounds)
<zyga> mvo:
<zyga> mvo: sorry, the file is from the host distro
<zyga> fedora rewrites the shebang (apparently!)
<zyga> but why would it be bind mounted there?
<zyga> so we run with fedora29 version of snap-device-helper
<zyga> so we must have did the bind mount for /usr/libexec/snapd /usr/lib/snapd
 * zyga confirms
<zyga> mountinfo in the app mount ns https://www.irccloud.com/pastebin/qSQmhrPV/
<mup> PR snapd#6117 opened: overlord/ifacestate: don't remove the dash when generating unique slot name <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6117>
<pstolowski> pedronis: ^
<zyga> mvo: there is no such mount
<pedronis> thx
 * zyga wonders 
<cachio> zyga, mvo I need to go to take my son
<mvo> zyga: hm, what snaps is that?
<mvo> cachio: ok
<zyga> mvo: so it's not mounted
<zyga> the core snap is busted
<zyga> https://www.irccloud.com/pastebin/3uE4g7eh/
<cachio> if you need a new machine just add fedora-29-64 to the spread.yaml
<zyga> theory: in CI when we repackage core and inject snapd
<zyga> the locally built snapd.rpm has replaced shebang
 * zyga looks
 * cachio afk
<zyga> mvo: this would only break in CI
<zyga> mvo: not in real world
<zyga> real world doesn't inject snapd from RPM into core snap
<mvo> zyga: aha, because we rewrite the core in ci
<zyga> actually, I wonder what that was supposed to do
<mvo> zyga: indeed
<zyga> I sure hope we don't have both /usr/lib/snapd and /usr/libexec/snapd
 * zyga checks that first
<zyga> mvo: confirmed, prepare.sh has
<zyga>     cp -a "$LIBEXECDIR"/snapd/* squashfs-root/usr/lib/snapd/
<zyga> so we take the host's rpm that was mangled
<zyga> and inject that into the built package
<zyga> this is broken
<zyga> not only in the sense that this path is rewritten
<zyga> snap-confine compiled on fedora is incompatible with core
<zyga> I think we need to take a step back
<zyga> without making snap-confine and other C programs compatible with every distribution
<zyga> we cannot just insert them into the core snap during testing
<zyga> they will expect different paths
<zyga> it just happened to work because a path was hard-coded there
<zyga> not using @libexecdir@
<zyga> but other parts will not be so useful
<zyga> the binary is linked with fedora locations
<zyga> it makes no sense to just inject it into a core snap with ubuntu chroot
<zyga> mvo: let's have a call about this if you don't mind
<zyga> I think our fedora testing story was super lucky so far :)
<zyga> snap-confine ldd inside and out https://www.irccloud.com/pastebin/OkT431Pi/
<zyga> mvo: and even if we make it 100% unaware of the distribution configuration
<zyga> things like libc version will be at play
<zyga> as we move to fedora30 and beyond
<zyga> snap-confine linked in fedora30 might not run on ubuntu 16.04
<zyga> I think the extent of testing fedora29 by repackaging core is a bit broken
<zyga> we need to repackage core as if it was built on ubuntu
<zyga> and test that
<zyga> that's the realistic test IMO
<zyga> mvo: I'll make coffee and let's have a call, ok?
<mvo> zyga: let me finish some things here first, then yes
<pstolowski> zyga: re hook issue & pre-refresh, can I help? what do we know so far (logs, a reproducer?)
<zyga> pstolowski: I don't have a reproducer, didn't try
<zyga> what we know is:
<zyga> http://paste.ubuntu.com/p/MfKnvp8bD7/
<zyga> at the bottom
<zyga> lines 865-
<zyga> 865 says we didn't have the apparmor profile but we tried to execute a pre-refresh hook
<zyga> then line 871 tells us we loaded (not replaced, loaded) the apparmor profile for the pre-refresh hook
<zyga> that's all I know
<kjackal> zyga: Just got the logs you asked https://pastebin.ubuntu.com/p/cRW8jX2XGM/ . Would you prefer a forum topic?
<zyga> kjackal: something tracable, yes, may be a bug report or a forum post
<zyga> kjackal: too many topics now :)
<zyga> kjackal: can you also get the /var/lib/snapd/mount/snap.$foo.fstab please
<kjackal> zyga: it is on the pastebin line 7, right?
<zyga> ah
<zyga> perfect
<zyga> kjackal: let's have a bug report
<zyga> bugs can be assigned
<zyga> forum topics are swaaaamped
<zyga> kjackal: I'm sorry, the issue with fedora is fundamental to our testing and development story
<kjackal> where do you keep bug reports?
<zyga> we need to tackle it
<zyga> kjackal: launchpad.net/snapd please
<kjackal> yes no worries
<kjackal> thanks
<zyga> mvo: ready when you are
<zyga> mvo: https://meet.google.com/mcs-qqzz-idp?authuser=0
<pstolowski> zyga: thanks, i'll see if i can find anything
<zyga> mvo: I wrote a quick summary
<pstolowski> zyga: can we have state.json for the hook issue?
<zyga> https://www.irccloud.com/pastebin/QhF9iWhq/
<zyga> pstolowski: yes
<zyga> https://www.irccloud.com/pastebin/nYonNbqH/
<zyga> pstolowski: we analysed that and determined that task timestamps are not super useful because of undo
<zyga> we should store undo timestamps separately
<zyga> pedronis: ^ for debugging we should probably store undo timestamps in the state
<pstolowski> zyga: this state is missing waittasks/halttask and is generally stipped down; do we have a complete state?
<mup> PR snapcraft#2399 opened: Cmake find root build snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2399>
<mvo> ackk: hm, I may need access to your snap afterall, I wrote a testcase with a configure hook and core18 only and it works for me
<ackk> mvo, ok, hold on
<mvo> ackk: also please pastebin "snap version"
<Chipaca> mvo: silly question that i could probably answer with grep: where's the snapd sanity check?
<mvo> Chipaca: sanity/check.go iirc
<Chipaca> mvo: thanks
<diddledan> zyga or jdstrand, can you help with dbus ownership? on ubuntu transmission-gtk doesn't need a slot but on kubuntu it seems to require a defined slot. also transmission-qt and transmission-gtk both use the same dbus name, so we're wondering if the store allows two snaps to have the same dbus slot definition?
<thresh> A tool snapcraft depends on could not be found: 'execstack'.
<thresh> is that something I miss from the docker image I build?
<thresh> I see that package is in debian, but not in ubuntu
<thresh> hm, it's actually in universe, but not shown on packages.ubuntu.com
<thresh> and it's actually installed
<sparkiegeek> packages.ubuntu.com is broken atm
<sparkiegeek> https://bugs.launchpad.net/pkg-website/+bug/1801518
<mup> Bug #1801518: Search is broken <pkg-website:Confirmed> <https://launchpad.net/bugs/1801518>
<thresh> oic
<kjackal> zyga: Here is the bug on microk8s https://bugs.launchpad.net/snapd/+bug/1802332
<mup> Bug #1802332: Apparmor complains in strict confinement with base: core18  <snapd:New> <https://launchpad.net/bugs/1802332>
<thresh> here's the snapcraft output on execstack: https://code.videolan.org/snippets/871
<zyga> kjackal: thank you
<thresh> I don't have /usr/sbin in $PATH, too
<kjackal> jdstrand: I noticed that "kernel-module-observe" is not available but your patch had it there. Should I know anything about it? Merged with something else? Renamed? Not needed?
<kjackal> I am not in the position yet to see what breaks and what works, just asking because I had to comment it out
<mup> PR snapd#6118 opened: tests: add core18 only hooks test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6118>
<Chipaca> pstolowski: where does the stdout/stderr of hooks go?
<zyga> mvo: actually
<zyga> mvo: on fedora29 running core18 test the same bug will happen; we need to switch the bind mount to use core's or snap's version of /usr/lib/snapd
<zyga> the bind mount used for bases
<ogra> Chipaca, the journal (at lest i find the output of mine there regulary)
<zyga> I realised while cleaning up the notes
<mvo> zyga: indeed
<sparkiegeek> ogra: clue for where abouts?
<mvo> zyga: we need the snapd snap
<ogra> sparkiegeek, journalctl -f ... then install/rmove7configure the snap in another terminal
<ogra> *install/remove/configure
<pedronis> zyga: we need a bug or forum post on that or it will get lost
<pedronis> I mean storing undo timestamps
<zyga> I'm doing that now
<zyga> ah
<sparkiegeek> ogra: doesn't seem to help :(
<zyga> I'm not doing that now
<zyga> I will file a bug yes
<zyga> I'm writing a post about the issue Sergio found and we just debugged with mvo
 * pedronis was in a longish meeting
<pedronis> zyga: anyway if undo is involved, then might well be the issue that would be solved by merging *-profiles with *link*
<zyga> pedronis: I don't think the issue is related to undo
<pedronis> ah ok
<zyga> it's just that we have fewer bits of data about it to debug clearly from timestamps alone
<zyga> we know for sure from kernel logs that we ran a hook before we setup security
<zyga> pstolowski: ^ actually this makes sense :D
<pedronis> yes, but not having security when we should and undo
<zyga> that hook should run before we setup security
<zyga> because security setup will switch the world for the NEXT revision of the snap
<pedronis> are the a possible of form of the bug
<pstolowski> Chipaca: to task's log i believe, however there is a catch afair, it only goes there if hook fails
<zyga> pedronis: yes, in this particular case we didn't have security because that snap was not installed yet, the bug is that we ran the hook at all, not that we didn't have security
<ogra> sparkiegeek, weird, i always see mine ... though i'm typically watching on UC ... not sure if thats any different (i wouldnt expect so though)
<pedronis> ah, interesting
<pedronis> ok
<zyga> (we had nil security because that's the first install, we ran the pre-refresh hook of the installed snap in this nil security before we proceeded to setup security for the revision being installed)
<zyga> I'll add this to the reporty
<pstolowski> zyga: this is super weird, it could only happen if we had a snap in snapstate but it wasn't actually installed (?), in which case IsInstalled() would lie
<zyga> but we do
<zyga> we are installing it
<zyga> do we have a test for this situation
<zyga> snap install snap-with-pre-refresh-hook
<zyga> perhaps it ends up in snap state too early
<pstolowski> zyga: that would mean we have other serious issues
<pstolowski> zyga: we have a bunch of checks around isInstalled
<zyga> pstolowski: it would be good to try this. case
<zyga> make a simple snap with pre-refresh hook
<zyga> and install it
<pstolowski> zyga: ok, i'll do this
<mup> PR snapd#6119 opened: sanity: refuse to try to do things on WSL <Created by chipaca> <https://github.com/snapcore/snapd/pull/6119>
<Chipaca> mvo: ^ my sanity question was about this
<pstolowski> zyga: wait, we do have spread test already
<zyga> mvo: https://forum.snapcraft.io/t/issue-with-repackaged-core-and-testing/8394
<zyga> mvo: please sign off that you agree with what it says
<zyga> you can edit it I believe
<zyga> pstolowski: then I don't know
<zyga> pstolowski: chase this with chipaca tomorrow please
<zyga> we need to reproduce it really
<pstolowski> zyga: install-refresh-remove-hooks
<zyga> pstolowski: maybe interplay with other hooks is important
<zyga> try making a quick test with just one hook
<pstolowski> ok
<zyga> and base (not sure if relevant)
<pstolowski> zyga: just one hook - pre-refresh - worked. does the hook need to do anything to trigger profile issue?
<zyga> no
<zyga> it would not be able to execute at all
<pstolowski> right, it's snap-confine erroring early
<pstolowski> zyga: just pre-refresh hook, without base, and with base:core18, both worked
<Chipaca> zyga: chase what? (scrollback from where?)
<pstolowski> zyga: do you have full state.json?
<zyga> pstolowski: I don't have anything else, it's all from backlog in this channel
<zyga> Chipaca: that bug with pre-refresh-hook
<zyga> pedronis, Chipaca: related to this bug I filed https://bugs.launchpad.net/snapd/+bug/1802339
<mup> Bug #1802339: Tasks should carry separate timestamps for undo paths <snapd:New> <https://launchpad.net/bugs/1802339>
<pstolowski> zyga: who reported it originally?
<zyga> pstolowski: someone from the sprint Chipaca is at
<zyga> Chipaca: wanna see something terrible
<pstolowski> aha
<zyga> https://forum.snapcraft.io/t/issue-with-repackaged-core-and-testing/8394
<zyga> kaboom
<pedronis> we already  discussed that ^ in the past
<pedronis> we also said it was going to bite us at some point
<mvo> Chipaca: \o/
 * zyga needs to break for a while to vent 
<pedronis> zyga: also that post doesn't list snap-exec, doesn't it always come from the base?
<pedronis> or is that the bind mount bit?
<pstolowski> Chipaca: can you find who that was reporting pre-refresh issue, and get more info? state.json for starters
<Chipaca> pstolowski: which pre-refresh issue?
<Chipaca> gah
 * Chipaca reads backlog again
<Chipaca> ah
<pstolowski> Chipaca: somebody hit an issue where pre-refresh hook was run without security profile (=failed with denials), as if snap wasn't installed. in theory (and according to the code) this hook should run of old revision of the snap, before switching to new revision on refresh
<pstolowski> s/run of/run for/
<Chipaca> was this related to the dmesg -H pastebin?
<pstolowski> Chipaca: the lof is http://paste.ubuntu.com/p/MfKnvp8bD7/
<pstolowski> *log
<Chipaca> ah yes
<pstolowski> Chipaca: pastebin from "joao"
<Chipaca> yes
<Chipaca> pstolowski: i'll get the state.json
<Chipaca> pstolowski: zyga: for extra fun, they got the same thing again in the post-refresh hook, afterwards
<Chipaca> pstolowski: zyga: i've send you guys the state json
<Chipaca> niemeyer: github is rate-limiting us which is why sometimes travis statuses don't make it back
<Chipaca> niemeyer: e.g. https://github.com/snapcore/snapd/pull/6107
<mup> PR #6107: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107>
<Chipaca> niemeyer: i have logs to prove it
<pstolowski> Chipaca: very curious. can you look around if their installations is sane? we use IsInstalled() check for this hooks, i cannot think of a case where this would lie, except for some inconsistency?
<Chipaca> niemeyer: can youchat  with them and ask them to bump our limits a bit?
<Chipaca> niemeyer: i'll fwd the email
<Chipaca> with the logs
<pstolowski> thanks for the state, lookiing
<pedronis> if it's that, yes IsInstalled returning true for non installed snap would be very weird
<niemeyer> Chipaca: Huh.. curious
<sparkiegeek> is it possible to delete a configuration key for a snap? i.e. 'snap set mysnap foo=bar; snap set mysnap foo=; snap get mysnap | grep foo' returning no hits
<niemeyer> Chipaca: Thanks, will follow up
<pedronis> sparkiegeek: not at the moment
<pstolowski> Chipaca, pedronis, zyga from quick glance at the state, they seem to be using try mode quite a bit, which i hinted could be a factor, i think this is the first suspect
<Chipaca> try mode + hooks = bad news?
<Chipaca> that's a big bummer
<Chipaca> what's the situations in which it'd fail?
<Chipaca> pstolowski: ^
<pstolowski> Chipaca: they should work obviously; is IsInstalled check correct for try mode?
<pedronis> Chipaca: try on top of a try, is really a refresh
<Chipaca> pedronis: yes
<pedronis> but if the two use the same dir
<Chipaca> ah
<pedronis> not sure what it means
<Chipaca> ok, i'll see if this helps
<pedronis> Chipaca: one thing to try,  snap try something without a prerefresh hook
<pedronis> now you try the same dir but you added a prerefresh hook
<pedronis> I suppose: boom
<pedronis> I feel their pain, but is not quite trivial to solve either
<pedronis> we would need to remember things that atm we don't care to
<Chipaca> where's our CoW support a t
<Chipaca> at*
<Chipaca> the dev isn't blocked on this, fwiw, so there's not that much urgency
<Chipaca> but it does seem to match what we were seeing
<pedronis> Chipaca: or yes, take a snapshot somehow , unclear when or how
<Chipaca> pedronis: they were doing try+try to test the pre- and post-refresh hooks :-)
<pedronis> doesn't quite work
<pedronis> they need a 2nd checkout
<pedronis> atm
<pedronis> I fear
<pedronis> I suppose it can of works
<pedronis> if there are no interfaces involved
<pedronis> anyway is not a well supported/understood case by our code
<pedronis> try is really a best effort big hammer
<pedronis> I suppose we should at least document this kind of sharp edges somewhere
<mup> PR snapcraft#2400 opened: tests: fix maven spread test <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2400>
<pedronis> Chipaca: can we get a bug or forum post on this now that is better understood?
<pedronis> otherwise it will wash away
<Chipaca> pedronis: i'll give it a try
 * Chipaca would giggle but is too tired
<pstolowski> it's interesting, i've just tested this scenario (snap try without pre-refresh, then snap-try with pre-refresh, same dir), it fails but differently
<pstolowski>  Run pre-refresh hook of "snap-hooks" snap if present (run hook "pre-refresh": cannot stat /var/lib/snapd/seccomp/bpf/snap.snap-hooks.hook.pre-refresh.bin: No such file or directory
<pstolowski> and after a few minutes, after timeout
<pstolowski> no denials
<mup> PR snapcraft#2401 opened: ci: reduce spread system declarations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2401>
<Chipaca> hmm
<pedronis> pstolowski: does it have an interface that hook?
<pedronis> I mean needs to need an interface to get a denial
<popey> ondra: your avahi-client snap - should I be able to see avahi advertised services in the office?
<pstolowski> pedronis: no hook, only home interface
<pedronis> anyway  it's similar but different
<pedronis> maybe they did enough to have a bf
<pedronis> bpf
<pedronis> in their case
<pedronis> but not the right apparmor profile
<pedronis> yet
<mup> PR snapcraft#2402 opened: packaging: update requests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2402>
<pstolowski> right. anyway, good that we know it's snap try
 * pedronis eoding
<pstolowski> eod as well
<pstolowski> cu
<ondra> popey yep
<ondra> popey that is exactly it's purpose :)
<Chipaca> pstolowski|afk: pedronis: zyga: https://forum.snapcraft.io/t/snap-try-snap-try-hooks-fun/8400
<popey> ondra: how do you operate it?
<ondra> popey but easier to use snappy-discover
<popey> ooh
<pstolowski|afk> Chipaca: thanks! s/-remove/-refresh/
<ondra> popey then no need to use params
<ondra> popey mind, UC device needs to run avahi in first place :)
<Chipaca> d'oh
<popey> not on core
 * Chipaca should've EOWed after lunch
<ondra> popey ok then avahi-client
<ondra> popey what is device's name>
<ondra> ?
<popey> ondra: Volumio
<popey> ah, avahi-client has a bunch of not-automatically-connected interfaces
<ondra> popey yeah you need to connect manually
<ondra> popey 10.20.65.140, 10.20.65.210
<popey> what did you do?
<ondra> popey on macOS lanscan
<popey> wrong answer :)
<ondra> popey it does whole scan
<popey> I'm trying to prove avahi on snap
<popey> we have a broken snap and trying to prove avahi in snap works
<ondra> popey OK let me get you right command
<hackedhead> are there instructions for installing the snap system from source? (my distro doesn't ship with a package: Slackware)
<popey> hackedhead: great question. I'd love to see a doc for bootstrapping snapd from sauce
<popey> Chipaca: ^ :D
<Chipaca> 1. get systemd
<popey> 2. ???
<Chipaca> 3. profit
 * Chipaca wins
<ondra> popey avahi-client.browse -a | grep Volumino
<cachio> Chipaca, hey, any idea about what could be causing this on rpi 3: https://paste.ubuntu.com/p/B9RsstFFwj/
<Chipaca> cachio: yes
<cachio> Chipaca, :)
<ogra> popey, avahi in snaps does not work ... i started a thread about it a month or two ago
<Chipaca> cachio: mozilla broke snapd on non-intel architectures, and we let them
<cachio> Chipaca, nice
<Chipaca> cachio: i thought zyga was fixing this but apparently no
<ogra> popey, here is a hack in a wrapper script https://github.com/ogra1/dashkiosk-client-browser/blob/master/chromium.launcher ... and here is the thread https://forum.snapcraft.io/t/no-mdns-support-in-snaps-should-core-have-a-modified-nsswitch-conf/7603
<ondra> ogra what? what do you mean?
<popey> oddly my machine can't see any avahi things
<popey> another laptop can!
<popey> on the same network
<ogra> ondra, snaps can not use mdns due to nsswitch.conf
<ondra> ogra ah, that's when you want to use libc
<cachio> Chipaca, good to know, thanks
 * zyga lost track of things to fix
<popey> typo, works now
<ondra> ogra avahi client still works
<ogra> popey, you can use layouts to overcome that but that means you are forced to snapcraft 3.0 and core18
<zyga> Sorry about that chipaca
<ogra> ondra, sure ...
<Chipaca> cachio: Â¯\_(ã)_/Â¯
<ondra> ogra core 18?
<Chipaca> cachio: i  think this blocks 2.36
<ogra> ondra, <popey> we have a broken snap and trying to prove avahi in snap works
<ogra> ondra, yes, for layouts without passthrough
<Chipaca> zyga: no problem
<Chipaca> zyga: i mean
<Chipaca> zyga: i'm very tired, i'm probably not the only one
<Chipaca> i might just work half a day tomorrow
<zyga> are you fixing the ptrace bug?
<zyga> Can you file it please, even a small bug for tracking
<zyga> I think we need to fix our ability to store, triage and react to issues
<jdstrand> zyga: you mentioned 2.36.1 will be released today. I don't think it can be released if the fp/fpx ptrace issue is present since if it goes to stable, you'll blow up kiosks
<jdstrand> zyga: perhaps it is best to revert the PRs if you don't have time. then reintroduce in 2.36.2
<zyga> Ack
<Chipaca> zyga: go for it
<zyga> I agree but I donât know if the issue is in edge/master only
<zyga> Or also in the release branch
<Chipaca> didn't 2.36 already inlcude the fp/fpx thing?
<zyga> Chipaca: ack, the bug is on me now
<Chipaca> zyga: i meant go for filing it
<zyga> I donât remember Chipaca
<jdstrand> zyga: actually, it seems it is only in master. I just checked out 2.36 and don't see the code. sorry
<Chipaca> zyga: remember what
<zyga> Iâm taking the dog out now, took a break before. After I am back I will report the bug, check if it present in the release branch and coordinate with mvo
 * Chipaca is confused
<Chipaca> zyga: ah
<Chipaca> zyga: walk away
<Chipaca> zyga: okk
<zyga> Chipaca, IRC is slow from phone
<zyga> Sorry about that
<Chipaca> zyga: i'll fix tomorrow if you haven't by the time i wake up
<Chipaca> i plan to not wake up early
<zyga> Ok
<Chipaca> :-)
<zyga> Good plan
 * Chipaca hasn't felt this tired in a while
<zyga> I keep doing 1-2am
<zyga> :/
<Chipaca> have i mentioned how being in a room full of people tires me out? :-)
<Chipaca> and that, yes :-D
<zyga> Hey
<zyga> At least you are not sharing a room this week :-)
<mup> PR snapcraft#2396 closed: Partial Revert "build providers: fix osx non base and injection" <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2396>
<pedronis> jdstrand: I don't think, we meant released to stable, 2.36 didn't even make it to candidate
<pedronis> unless me is very confused
<pedronis> jdstrand: I think mvo meant pushing .1 to beta
<pedronis> or so I hope
<zyga> re
<zyga> pedronis: that's correct
<mvo> zyga: ok
<mvo> pedronis: yeah, the plan is to push .1 today but I will wait for zyga to get back to me about this issue that jdstrand  described (fp/fpx)
<zyga> mvo: on that now
<zyga> mvo: release branch is not affected
<zyga> go for .1
<zyga> I'll fix the master issue
<zyga> Chipaca, jdstrand: FYI filed as https://bugs.launchpad.net/snapd/+bug/1802362
<mup> Bug #1802362: browser-support broken on certain arches due to ptrace  <snapd:In Progress by zyga> <https://launchpad.net/bugs/1802362>
<Chipaca> zyga: ACK
<Chipaca> EOD from me (mostly)
<mvo> zyga: ta
 * zyga pours a glass of Jim beam and gets to work
<zyga> pedronis: I saw your comment on the forum. I will respond and improve the post tomorrow. Today I just want to wrap up
<jdstrand> mvo, pedronis: yeah I mispoke, 2.36 isn't affected by the fp/fpx
<jdstrand> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1802124 already existed for that
<mup> Bug #1802124: Error installing chromium-mir-kiosk on RPi3/edge <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1802124>
<jdstrand> zyga: I also think your conclusion in your bug is wrong. just like with AF_IB or or that set_tls is an arm-specific call, the policy shouldn't be arch specific. the backend should be smarter
<zyga> I think I swing towards that conclusion as well now
<zyga> it's easier to handle on that end
<jdstrand> zyga: yeah. a profiler should only have to worry about policy being safe or not. the backend can just be smart about archs
<jdstrand> zyga: cool, thanks
<zyga> thank you :)
<sborovkov> Hello, is the kernel with B+ support released to stable?
<jdstrand> zyga: not sure who will be assigned to that, but ahppy to review it (I can't jump on it right away, otherwise I would)
<zyga> I am fixing it now
<zyga> just trying to make sure I understand it and can see the fix working
<mvo> zyga: how do I reset the mount namespaces again? I suspect I Know why my test is not reproducing the core failure that ack reported
<zyga> mvo: just use snap-discar-dns
<zyga> discard-ns
<zyga> mvo: /usr/lib/snapd/snap-discard-ns snap-name
<mvo> zyga: no args?
<zyga> note that it does more than it used to long time ago so please use that rather than work on unmounting the mount namespace alone
<zyga> just the snap name
<ijohnson> zyga: does discard-ns also undo the device cgroup setup for a snap?
<zyga> no
<zyga> interesting
<ijohnson> is there a command that does that?
<zyga> nope
<zyga> we never remove them
<zyga> ijohnson: (feels like a bug)
<ijohnson> I currently have had to just reboot my machine to get it to go away after uninstalling a snap with the device cgroup on it
<ijohnson> shall I file a bug about it?
<zyga> please
<ijohnson> okay, will do in a bit, about to go out for lunch
<zyga> ijohnson: AFAIK that's been true since snapd got started
<zyga> ijohnson: I have some related work on refreshes pending
<zyga> so I think we can fix it then
<ijohnson> okay cool
<zyga> ijohnson: you can stop rebooting
<zyga> it should be easy to clean up for development
<ijohnson> yeah I'm sure there's a way I haven't looked into it too much yet though
 * ijohnson -> lunch
<mvo> zyga: I'm afraid we need something like 6118 for 2.36
<zyga> looking
<mvo> zyga: i.e. on classic we have the quirks code in snap-confine that always assumes core
<zyga> mmmm
<zyga> I think that should only run on core, not on core18
<zyga> quirks need to die
<zyga> they are useless now
<zyga> so I suspect we could just ditch them
<zyga> lxd is a snap
<mvo> zyga: fair enough, I can fix the PR
<zyga> I'm sorry that it lived for so long
<zyga> let me read the PR in full
<zyga> mvo: the patch looks good
<zyga> I don't oppose merging it
<zyga> we should follow up with removal of quirks for base != "core"
<mvo> zyga: thanks, lets see if CI is happy too
<zyga> that is, quirks only on classic when running against core
<zyga> I suspect we could sync with stgraber and remove it entirely now
<zyga> quirks exist for one reason:
<zyga> allow lxd from the host to be visible in the snap
<zyga> specifically the socket
<zyga> but I think the socket moved since
<mvo> zyga: oh, nice
<zyga> for super compatibility I would probably stick to deprecation
<mvo> zyga: well, I can trivially add "if base_snap_name == "core" to the PR
<zyga> but maybe we can skip ahead and just drop it
<zyga> yeah, plese
<zyga> once green
<stgraber> zyga: what's that?
<zyga> I don't want to derail evening
<zyga> stgraber: hey,
<zyga> stgraber: we have a quirk in snapd that puts /var/lib/lxd from the host into the snap mount namespace
<stgraber> that wasn't for lxd
<zyga> it was added to allow snaps to talk to lxd socket that is otherwise not visible in the core snap (/var/lib/lxd doesn't even exist there)
<zyga> no?
<zyga> what was it for?
<stgraber> the LXD snap never accessed /var/lib/lxd
<zyga> (mental shortcut: it was for snaps that want to talk to lxd)
<stgraber> well, lxd.migrate does but it always used /var/lib/snapd/hostfs/var/lib/lxd
<zyga> where does lxd keep the socket now?
<stgraber> yeah, probably was for some other random snaps that wanted to talk to a non-snap LXD on the host, no idea what those would be
<zyga> stgraber: that's correct
<zyga> it was behind an interface access so we could probably check too
<zyga> (across store snaps)
<zyga> where does lxd store the socket now?
<stgraber> these days, they should be using the LXD snap anyway, socket would be at /var/snap/lxd/common/lxd/unix.socket
<mvo> ackk: 6118 has a fix, thanks for reporting the core18 only bug
<stgraber> lxd-client interface gets you access to that
<zyga> stgraber: thank you
<zyga> mvo: I just checked the interface
<stgraber> if someone really needs to talk to the non-snap LXD, I guess a lxd-deb-client interface or something could be introduced that gets you /var/lib/snapd/hostfs/var/lib/lxd/unix.socket
<zyga> there is no interface that grants access to /var/lib/lxd anymore
<zyga> I think we can remove this quirk entirely now
<zyga> stgraber: I agree
<zyga> jdstrand: FYI, based on the discussion above I think we can remove the quirk for /var/lib/lxd
<zyga> mvo: let's go ahead with your fix as-is
<zyga> and then clean up by removing the whole hack
<zyga> along with extra permissions
<zyga> tests and what not
<mvo> zyga: ok, lets see what CI says
<zyga> I took forever to boot a pi3
<zyga> to ensure that ptrace issue is fixed
<zyga> but it's not for the release so no stress
<zyga> mvo: offtopic, I think we may strip our snapd bits
<zyga> I wonder what's the size of snapd.snap with stripped go
<ackk> mvo, great, thank you for the fix
<mvo> zyga: good point
<mvo> zyga: strip> yeah
<mvo> zyga: tests still running, I check the PR in the morning, need sleep :/
<zyga> ok
<zyga> ttyl
 * mvo waves
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/6120
<zyga> not sure if it will pass
<mup> PR #6120: cmd/snap-seccomp: add full complement of ptrace constants <Created by zyga> <https://github.com/snapcore/snapd/pull/6120>
<zyga> it works on armv7
<zyga> (and on amd64)
<mup> PR snapd#6120 opened: cmd/snap-seccomp: add full complement of ptrace constants <Created by zyga> <https://github.com/snapcore/snapd/pull/6120>
<zyga> thanks to chipaca's brilliant cross-built test suite we will know soon if it passes on other arhces
<zyga> *arches
<zyga> jdstrand: anyway, I'll EOD now, please let me know what you think about this patch
<zyga> jdstrand: can you look at the update on https://github.com/snapcore/snapd/pull/6120
<mup> PR #6120: cmd/snap-seccomp: add full complement of ptrace constants <Created by zyga> <https://github.com/snapcore/snapd/pull/6120>
<zyga> not sure if you like it still
<zyga> ideally I'd say that some things are -1 or NaN or similar
<zyga> but it's hard in the current structure since -1 is a valid value at that level
<zyga> I could refactor that if you want
<zyga> though I don't believe it is required for this specific part (ptrace constants)
<zyga> specifically the set we are dealing with here
<zyga> jdstrand: not sure if you have the time but I would love a quick look at a simple open, fstatat function; https://github.com/snapcore/snapd/pull/6116
<mup> PR #6116: cmd/libsnap: add simplified feature flag checker <Created by zyga> <https://github.com/snapcore/snapd/pull/6116>
<zyga> the code is at https://github.com/snapcore/snapd/pull/6116/files#diff-034bb7401eb457bc8862f9b4ee97edc8R33
<zyga> the rests are tests
<jdstrand> zyga: if you were going to go that route, I think readNumber would have to return a 3rd value, 'skip' rather than interpreting the value
<zyga> yeah
<jdstrand> zyga: but this is like what we do for AF_IB, etc
<zyga> it just sucks because we have the knowledge in C as a macro
<jdstrand> what you're doing now
<jdstrand> I'm ok with the approach, just verifying something
<zyga> it's all doable, just a bit more uphill
<zyga> thank you
<zyga> FYI: I ran cross compile tests locally (thanks to chipaca's fantastic cross test suite)
<zyga> where locally is really locally invoked spread :)
<mup> PR snapd#6115 closed: cmd: update autogen.sh for opensuse <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6115>
#snappy 2018-11-09
<mwhudson> hey i broke snapcraft https://launchpadlibrarian.net/396538792/buildlog_snap_ubuntu_xenial_ppc64el_go-tip_BUILDING.txt.gz
<mup> PR snapd#6121 opened: tests: new test for snapshots with more than 1 user <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6121>
<mup> Issue core18#89 opened: bash completion not installed if "core" snap is not installed <Created by albertodonato> <https://github.com/snapcore/core18/issue/89>
<mborzecki> morning
<mborzecki> brb
<zyga> Good morning
<zyga> mwhudson: hello
<mborzecki> zyga: hey
<zyga> Quick question sir: what is the Debin policy for golang builds. That is, what more is needed in top of vanilla go build to do what packaging macros do
<mwhudson> zyga: i don't understand the question
<mwhudson> zyga: but basically you have a bunch of golang-*-dev packages for your build depends
<zyga> For example: in openSUSE to be compliant you need to pass -buildmode=pie to âgo buildâ
<zyga> Is there something like that in Debian?
<mwhudson> ah
<mwhudson> no
<mwhudson> you can, you can override dh_auto_build to run dh_auto_build -- -buildmode=pie or whatever
<mwhudson> (if you particularly hate i386 users...)
<mwhudson> zyga: you should probably join #debian-golang on oftc
<zyga>  I should, yes
<zyga> I have a deeper interest but Iâm tired and wanted to have a slow morning today
<zyga> So still AFK
<zyga> Good morning mvo
<mborzecki> mvo: hey
<mvo> hey zyga and mborzecki
<mvo> zyga: 6118 contains the fix for snap-confine we dicussed yesterday
<zyga> Hey
<pstolowski> morning
<mvo> good morning pstolowski
<zyga> mvo: Iâm still afk, doing a slow start today
<zyga> Sorry about that
<mvo> zyga: now worries, still waiting for travis in any case
<pstolowski> trivial https://github.com/snapcore/snapd/pull/6117 needs 2nd review
<mup> PR #6117: overlord/ifacestate: don't remove the dash when generating unique slot name <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6117>
<ackk> mvo, hi, I run in another issue yesterday with core18 only installed: https://github.com/snapcore/core18/issues/89
<mvo> ackk: thanks, looking
<mup> PR snapd#6120 closed: cmd/snap-seccomp: add full complement of ptrace constants <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6120>
<mborzecki> #6065 needs a 2nd review
<mup> PR #6065: cmd: make coreSupportsReExec faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6065>
<mvo> mborzecki: I have a look, sorry this was on my list but slipped
<mborzecki> pedronis: hi, did you happen to git push to the wrong remote by accident? origin/pedronis-localInstallCleanup-doc
<mup> PR snapd#6117 closed: overlord/ifacestate: don't remove the dash when generating unique slot name <Hotplug ð> <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6117>
<mvo> mborzecki: I'm looking at 6039 and the error tweak there right now - or is that something you are already doing?
<mborzecki> mvo: yeah, just started
<mborzecki> mvo: do you want to look into this or shuld i?
<mvo> mborzecki: its fine, just go ahead, I will do more reviews then
<mup> PR snapd#6065 closed: cmd: make coreSupportsReExec faster <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6065>
<mvo> pedronis: is 6070 something you want to look at (at a high level) or can I just go ahead and merge?
<mvo> zyga: do you know the status of 5696?
<thresh> is snap store dead again?
<mborzecki> mvo: it needs a 2nd review
<thresh> The Snap Store encountered an error while processing your request: internal server error (code 500).
<pedronis> mborzecki: hi,  do we have spread tests about refreshing parallel installed snaps through the store?
<mup> PR snapd#6119 closed: sanity, release, cmd/snap: refuse to try to do things on WSL <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6119>
<pedronis> mborzecki: no,  I used direct editing in github, I will remove the branch now that is merged
<mborzecki> pedronis: no, i don't think we have any, we have tests for install but not for refresh, i can look into adding one
<pedronis> mborzecki: yes, I think we should have some
<pedronis> thank you
<pedronis> mvo: can you give me a bit more context about 6070 ?
<pedronis> and hi
<mvo> pedronis: sure, let me update this
<mvo> pedronis: context in the PR description I assume?
<pedronis> mvo: what's the coverage like of those function in store?
<mvo> pedronis: the coverage change with this PR you mean? I checked that the bits that get mocked are also tested inside store but let me run the percentages
<zyga> mvo: good for merge AFAIK
<pstolowski> pedronis: could this land https://github.com/snapcore/snapd/pull/6072 ? got 2 reviews and is probably uncontroversial as it's touching  the udevmon bits
<mup> PR #6072: ifacestate/udevmonitor: added callback to signal end of enumeration <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6072>
<pedronis> pstolowski: yes, seems fine in itself
<pstolowski> thanks
<mborzecki> mvo: pedronis: i've updated 6039 with new error kind
<mborzecki> zyga: can you take a look at #5696 and +1 it if it looks ok for you?
<mup> PR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5696>
<pedronis> mborzecki: would try to get a review from John first
<mborzecki> pedronis: ok
<pedronis> I requested one there
<pedronis> I will look after him
<pedronis> zyga: are you blocked by 6116, or can you go forward and just deal with tweaks down the line?
<pedronis> anyway I see there are comments there
<mvo> pedronis: I updated 6070 with pointers to the tests and a bit more motivation, I hope this is what you asked for, if I misread, please let me know
<zyga> pedronis: I can move forward
<pedronis> zyga: thx
<pedronis> mvo: ah, you added a test as well
<thresh> is there any way to use JVM inside a snap, without providing the JVM itself?  Like a plug, maybe?
<mvo> pedronis: yeah, one was missing actually, not a super critical one but it was missing :)
<thresh> I don't really want to ship JVM as a part of VLC snap, but in case of Blu-Ray discs (which have Java-based menus) it can be useful
<mvo> zyga: 6118 is ready for review, tests are green except a curl 51 error on opensuse :/
<pedronis> thresh: theoretically there should be a way to have a content snaps for this, like we do for gnome library, the question is how to coordinate/mantain this, maybe something to discuss with advocacy/snapcrafters
<pedronis> thresh: sounds a fine forum discussion
<zyga> Uh
<pedronis> zyga: ?
<pedronis> mvo: btw have we broken the coverage reports, I don't see them in recent green PRs
<pedronis> ?
<mup> PR snapd#6122 opened: Tests core18 base configure 2.36 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6122>
<zyga> I mean the 51 error on suse
<zyga> archive woes
<mvo> pedronis: yeah, I haven't seen them either, let me look
 * zyga works on some reviews now
<zyga> sorry for starting late and everyone
<mvo> pedronis: I can't install codecov for snapcore/snapd - only an admin can do this, so looks like we need to ask Gustavo
<pedronis> mvo: why do we need to install it? did github change something so that we need to install it again?
<mvo> pedronis: I don't know, I don't see it in the installed services or the installed github apps anymore
<pedronis> I see
<mvo> pedronis: I don't know why it went away :/ I will dig a bit more but not sure I have enough prems to do much
<pedronis> mvo: no, that's fine
<pedronis> sounds like we need niemeyer
<pedronis> and as we know a general question about getting more people with the perms
<pedronis> your and/or me
<mvo> pedronis: yeah
 * pedronis dives back into reviews
<kyrofa> cjwatson, I want to thank you for your email, and let you know that we're at the snapcraft summit this week with very little brain space for anything else, but will get back to you next week if that's alright
<tomwardill> kyrofa: colin is off today
<kyrofa> tomwardill, well then, that works out
<mvo> a review for https://github.com/snapcore/core18/pull/83 would be great
<mup> PR core18#83: add swapfile support (ported from ubuntu-core-config) <Created by mvo5> <https://github.com/snapcore/core18/pull/83>
<mup> PR core18#84 closed: hooks: port classic mode generation to UC18 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/84>
<mvo> and https://github.com/snapcore/core18/pull/88 :)
<mup> PR core18#88: hooks: make ld-so symlink in /lib64 relative <Created by mvo5> <https://github.com/snapcore/core18/pull/88>
<zyga> mvo: do you need https://github.com/snapcore/snapd/pull/6118 squashed?
<mup> PR #6118: tests: add core18 only hooks test and fix running core18 only on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/6118>
<mborzecki> #5897 should be ready for landing once jdstrand approves it
<mup> PR #5897: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
<mup> PR snapd#6118 closed: tests: add core18 only hooks test and fix running core18 only on classic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6118>
<zyga> mvo: I'd like to squash merge and add https://github.com/snapcore/snapd/pull/5696 to 2.36.1, what do you think?
<mup> PR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5696>
<Chipaca> mvo: I only get grey reviews in core18
<mvo> Chipaca: thanks
<mvo> Chipaca: I think we need to talk to foundations why this is
<mup> PR snapd#5696 closed: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5696>
<mvo> Chipaca: thanks for the reviews! while you are here,  any idea about https://github.com/snapcore/core18/issues/89
<mborzecki> zyga: 5696 squash merged as requested ;)
<zyga> thanky you! :)
<Chipaca> mvo: I'll take a look
<mup> PR snapcraft#2400 closed: tests: fix maven spread test <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2400>
<mup> PR snapcraft#2401 closed: ci: reduce spread system declarations <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2401>
<Chipaca> mvo: yes a few
<Chipaca> mvo: ideas i mean
<Chipaca> mvo: core18 doesn't have the completer bits. I presume they're in the snapd snap
<Chipaca> mvo: but core18 also does not have bash completion itself
<mvo> Chipaca: oh, interessting - /usr/lib/snapd, right? that should be available via the host (deb package)
<Chipaca> mvo: it's got all the completers, but not the completion
<zyga> pstolowski: updated https://github.com/snapcore/snapd/pull/6116 :)
<zyga> I used a slightly different function name
<mup> PR #6116: cmd/libsnap: add simplified feature flag checker <Created by zyga> <https://github.com/snapcore/snapd/pull/6116>
<mvo> Chipaca: aha! so just a misisng package in there?
<Chipaca> mvo: perhaps
<mvo> Chipaca: that should be easy to fix :)
<pstolowski> zyga: thanks! will take a look in a moment
<zyga> thank you
<Chipaca> mvo: yes it looks like it's missing the bash-completion package
<Chipaca> mvo: should  that be from core, or in snapd itself? dunno
<mvo> niemeyer: when is a good time for you to chat about the dotfiles/files/sensitive-files naming? should we have a quick HO with pedronis  maybe later today about it? or early next week?
<niemeyer> mvo: Heya
<Chipaca> mvo: probably from core as it's used in the context of the snap-provided completer, i.e. with the base
<niemeyer> mvo: I can do it now
<mvo> Chipaca: making that part of core18 seems ok, no?
<Chipaca> mvo: sitll digging to see if this would be enough though
<Chipaca> mvo: i think so yes
<niemeyer> Just let me grab my power cable so laptop doesn't run off in the middle
<Chipaca> mvo: 'snap run --shell' doesn't work :-(
<pedronis> niemeyer: mvo: I can do it if it doesn't drag too long (almost lunch), otherwise we will need a follow up
<mvo> Chipaca: ta, let me know if you need help but hopefully the PR against core18 is trivial
<niemeyer> pedronis: Yeah, same here
<mvo> same here
<mvo> I'm in the standup HO, ready when you are
<zyga> hey niemeyer :)
<Chipaca> mvo: 	CompleteSh = filepath.Join(SnapMountDir, "core/current/usr/lib/snapd/complete.sh")
<Chipaca> mvo: so not just a core fix, needs a snapd change
<mvo> Chipaca: :/ ta
<Chipaca> !osutil.IsWritable(dirs.CompletersDir) || !osutil.FileExists(dirs.CompletersDir)
<Chipaca> hmmm
 * Chipaca wonders how many non-existent writable things exist out there
<zyga> mvo: what we discussed last night https://github.com/snapcore/snapd/pull/6123
<mup> PR #6123: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <https://github.com/snapcore/snapd/pull/6123>
<mup> PR snapd#6123 opened: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <https://github.com/snapcore/snapd/pull/6123>
 * zyga -> quick lunch break
<mvo> zyga: ta, I check after lunch
<mup> PR snapd#6124 opened: tests: simple reproducer for snap try and hooks bug <Created by stolowski> <https://github.com/snapcore/snapd/pull/6124>
<cachio> mvo, pedronis hey, I need to go to make a study now
<cachio> I'll try to by for the stand up
<cachio> perhaps a bit late
 * cachio afk
<pedronis> zyga: on a system with snapd snap we add implicit slots to it, right?
<pedronis> pstolowski: ensureSystemSnapIsPresent seems to have the wrong implementation now ^, also the name should probably have "is" or nothing, "ensure" sounds like it will install it if it's not there
<pstolowski> pedronis: wrong because of CoreInfo implementation?
<pedronis> pstolowski: yes
<pedronis> it doesn't account for when snapd is used for that
<pedronis> pstolowski: I suppose zyga can remind us what's the best way to get that info
<pedronis> seems we need a bit more help from mapper
<pedronis> actually
<pstolowski> pedronis: we may need to revisit repo code and its guessSystemSnap(), there is some fuzzyness there
<pedronis> maybe, not sure it's related
<pedronis> this code I'm talking about is all in ifacestate
<pedronis> atm
<pedronis> pstolowski: will we rerun the interface hooks when a hotplug slot that was gone reappers?
<pstolowski> pedronis: yes. and we will run disconnect hooks when you unplug
<pedronis> pstolowski: should we clear the dynamic attributes of gone connections then?
<pedronis> pstolowski: for context, I'm looking at the byHotplug case in doDisconnect
<pstolowski> pedronis: we probably could. are you thinking about just optimization or something more?
<pedronis> pstolowski: will we end up using them by mistake when we reconnect?
<pedronis> that's more my question, not worried about opt
<zyga> pedronis: I updated https://forum.snapcraft.io/t/issue-with-repackaged-core-and-testing/8394/3 - let me know if that answers your questions
<pstolowski> pedronis: looking at the code, in Connect we start off with empty dynamic attributes, so this should not happen
<zyga> Unless you disagree I want to work on a fix for this issue now, that would limit re-packaging to just snap-exec, outside of 16.04 world
<zyga> alternatively I can work on snap-confine and work with mvo on this in the evening
<pedronis> zyga: I need to re-read the forum post first, I think you should continue on user namespaces until I understand more
<zyga> ok
<pedronis> pstolowski: ok, I think it would be marginally cleaner/safer to reset them but can be done in any PR, not urgent
<zyga> pedronis: the only impact now is testing recent distributions
<pstolowski> pedronis: allright
<zyga> pedronis: it is not a problem in actual production use
<zyga> (even in future distributions)
<pedronis> zyga: yea, that's why I don't think you should jump on it
<zyga> ok
<zyga> mvo: 6122 approved
<zyga> did you say 2.36.1?
<pstolowski> pedronis: shall i look at printing a warning on snap try & hooks, or do we want to think about it some more?
<pedronis> pstolowski: no, you should look, likely with a bit of input from zyga how to fix ensureSystemSnapIsPresent, unless you have already something else
<pedronis> I fear adding that warning is messy
<pstolowski> pedronis: ok
<pedronis> pstolowski: btw, if it wasn't clear, I'm still absorbing the already landed hotplug code atm
<pstolowski> pedronis: yes, yes, it was clear
<pstolowski> pedronis: thanks
<mup> PR snapd#6122 closed: tests,snap-confine: add core18 only hooks test and fix running core18 only on classic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6122>
<zyga> heh
<zyga> I just realised we need facts for one more reason
<zyga> we need to know the PATH to set
<zyga> fedora29 cannot use ubuntu PATH
<pedronis> zyga: I re-read the forum topic, there is definitely more to clarify before it can be acted on, I can write more there and/or we can chat on it next week
<zyga> pedronis: thank you, I think if you write some more questions or concerns we can think about them and then have a call next week
<zyga> note, I just talked to pawel about monday
<zyga> our government decided to make Monday a holiday just now
<zyga> so I will (or should be) off
<pedronis> zyga: one first question, do we run our tests mostly with reexec on all distros? even if they default to not reexec
<zyga> it's not reexec
<zyga> it's re-packaging of core that breaks this
<zyga> we run with native setting of reexec
<zyga> so enabled where it works
<pedronis> zyga: ok, but some of your proposal don't make in the non reexec case
<pedronis> make sense
<zyga> there are two proposal: solution and workaround
<pedronis> no there are many bits
<zyga> solution is to build snapd with ubuntu 16.04 toolchain and re-package core with that build results
<mup> PR snapd#6125 opened: release: 2.36.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6125>
<pedronis> no, you propose to change some bind mounting too
<zyga> the workaround is to stop repackaging with the special exception of snap-exec
<zyga> because snap-exec is safe
<pedronis> that doesn't make sense in general
<zyga> indeed, sorry, that is a special case of what we do today on core18 snaps
<zyga> we cannot use the host package as source for certain binaries
<zyga> we must bind mount from snapd.snap
<pedronis> if we don't reexec
<pedronis> or depending on which binary
<zyga> yes, even if we don't reexec
<pedronis> it's complicatted
<zyga> I mean when we run a core18 snap app,
<zyga> (I agree)
<pedronis> anyway it's not ready to be worked on
<zyga> we _may_ in some cases use host binaries with ill effects
<pedronis> I'll write some this in the post later
<zyga> thank you!
<zyga> it's super complicated because of many possible interactions
<zyga> I think in general the solution case is easy, it would just cost test time to build snapd twice
<zyga> and it matches reality in non-test useage
<zyga> there are certainly some tweaks to do for core18 and fedora29 based snaps
<zyga> but those are nearly not as broken as the repackaging today
<mup> PR snapd#6116 closed: cmd/libsnap: add simplified feature flag checker <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6116>
<ogra> mvo, so when you install an app on UC18 today ... it is very likely that this app pulls in core16 (simply since we only have very few UC18 core apps yet) ... once the apps switch to core 18, do we have some automation to remove the core16 snap automatically once nothing depends o it anymore ?
<ogra> if not ... could we add that ?
<mborzecki> mvo: can you publish the files to github release page?
<zyga> mvo: yes please, I'll release 2.36.1 for suse too
<mvo> mborzecki: yes, will do so in a little bit
<mup> PR snapd#6072 closed: ifacestate/udevmonitor: added callback to signal end of enumeration <Hotplug ð> <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6072>
<mvo> ogra: we have no auto-cleanup of unused bases yet but its planned
<ogra> good
<ackk> ogra, there are also a few issues currenty if you don't have "core" installed
<ogra> it just struck me that 3xcore16 on disk will easily eat 200-300MB
<ogra> for devices with 4GB MMC (which we have a lot) thats quite a lot
<zyga> ogra: we may save a lot soon
<zyga> I'll tell you more after the standup
<ogra> interesting
<zyga> re
<zyga> ogra: golang can now strip correctly
<zyga> tl;dr
<zyga> we can investigate
<ogra> zyga, that doesnt help much with the core snap size i fear
<zyga> ogra: it's way bigger because of snapd
<zyga> anyway
<zyga> pstolowski: let's chat in an hour or two
<zyga> I need to get home
<ogra> (i dont think there is a single go binary in it apart from snapd)
<pstolowski> zyga: sounds good, i need (late) lunch
<Chipaca> ogra: also there's a config to only keep 2x instead of 3x
<ogra> \o/
<ogra> that was about time !!!
<ogra> awesome !
<Chipaca> ogra: there since 2.34
<Chipaca> ogra: https://github.com/snapcore/snapd/pull/5207
<mup> PR #5207: overlord/{config,snap}state: the number of inactive revisions is config <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5207>
<ogra> you guy need a promotion agent !!! such features deserve way more noise ... even TV ads for thi particular one ;)
<ogra> *guy
<ogra> *guys
<ogra> bah
<Chipaca> ogra: and you need a keyboard with two S keys in a hot-hot configuration
<ogra> yeah ... i'm so sad this KBD *again* only lasted 1y ... i really like it
<ogra> funnily usually the vowels break ... this is the firsst time i killed an S
<Chipaca> fun fact: snap.BaseDir() is not the directory of the base of a snap
<pstolowski> :)
 * cachio lunch
<jdstrand> mborzecki: hi, fyi, I approved PR 5897, but please fix the two typos before merging
<mup> PR #5897: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
<mborzecki> jdstrand: thanks for the review, i'll look into it in a while
<jdstrand> mborzecki: thanks!
<Chipaca> mvo: let me know when you have 5-10' to go over /usr/lib/snapd/* wrt bases
<mvo> Chipaca: in a meeting right now
<Chipaca> mvo: yea
<Chipaca> mvo: you have all the fun, i know
<mvo> Chipaca: we bind mount this ususally, either from the host or from the snapd snap
<mvo> Chipaca: yeah, envy me!
<mvo> ackk: the fix for the issue you reported about core18 onyl on classic went into 2.36 we will sru this either today or early monday
<mvo> cachio: everything except i386 is ready for beta validation
<ackk> mvo, \o/ thanks
<mvo> thank *you* for reporting and the reproducer!
<mvo> cachio: i386 is now also ready for beta validation
<ogra> ppisati, oh my ... bug 1802320 sounds like you had a really painful time just for some blinking
<mup> Bug #1802320: rpi3bp+: ethernet leds don't blink <patch> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1802320>
<ppisati> ogra: yep, actually fixing the leds made the ethernet controller die
<ppisati> ogra: but in the end it was fun
<ogra> heh
<kenvandine> what provides location-observe?
<kenvandine> sudo snap connect gnome-clocks:location-observe
<kenvandine> error: snap "core" has no "location-observe" interface slots
<pedronis> kenvandine: afaik only the locationd snap provides that
<pedronis> but I don't have enough context to say what that is, or what we should do instead
<pedronis> sorry, s/what that is/why that is/
<zyga> Finally home
<zyga> Tea and work
<zyga> Maybe coffee instead
<pedronis> zyga: I wrote a bit more in that forum post, it's a bit rambly I fear, I don't think it yet capture the problem in a way that one can tell yes, this is the problem. Also I'm confused if we have related bugs outside of tests, I suppose not, but reading your comment it sounds like we do
<pedronis> zyga: either way, not urgent to answer, do it when you feel good/rested
<pedronis> *it's a bit rambly, it there is my own answer
<pedronis> pstolowski: in case I finish going through the preexisting code, can you tell me where I should start the important reviews for hotplug?
<pstolowski> pedronis: sure, let me take a look
<kenvandine> pedronis: thanks
<cachio> mvo, running
<pstolowski> pedronis: i suggest the simple #6082 first; then three PRs closely related to each other: #6069, #6114, #6100
<mup> PR #6082: overlord/ifacestate: set hotplug-key of the connection when connecting hotplug slots <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6082>
<mup> PR #6069: ifacestate/hotplug: removeDevice helper <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6069>
<mup> PR #6114: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>
<mup> PR #6100: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100>
<pedronis> pstolowski: thx, I'll see how far I get on monday
<cachio> zyga, do you have the link for this python utility
<cachio> ?
<dot-tobias> Is launchpad currently unavailable? Estimated build time for my snaps is 5+ hours, and is still at 5h after 2h wait.
<ogra> dot-tobias, https://launchpad.net/builders is always a good place to check
<mup> PR snapd#6126 opened: dirs, wrappers, overlord/snapstate: make completion + bases work <Created by chipaca> <https://github.com/snapcore/snapd/pull/6126>
<dot-tobias> ogra: thanks!
<zyga> cachio: yes, one sec
<zyga> pedronis: offtopic, https://github.com/snapcore/snapweb is pinned if you go to GitHub.com/snapcore/ perhaps we should unpin it as it's not really maintained
<zyga> cachio: this is here https://github.com/snapcore/core-build/tree/master/initramfs/testing
<zyga> cachio: I think it's not useful as-is for you directly
<zyga> cachio: but it should be not too hard to extract a little bit out
<zyga> cachio: that can drive kvm and do the snapshot / restore
<kenvandine> mvo: i just learned there's a "bare" snap.  Would it make sense for a content snap like gtk-common-themes to use base: bare?
<zyga> kenvandine: hey
<kenvandine> hey zyga
<zyga> kenvandine: content snaps don't provide apps
<zyga> kenvandine: I don't think it needs to be using the bare base
<kenvandine> oh, so if no app is defined it won't care?
<zyga> precisely
<kenvandine> great
<zyga> bases are the roots for running stuff
<zyga> nothing to run, nothing to care about :)
<kenvandine> awesome
<cachio> zyga, tx
<Chipaca> um
<Chipaca> well
<Chipaca> zyga: if it doesn't say base: <something>, we'll dutifully install core for it
<zyga> Chipaca: we should change thta
<zyga> Chipaca: so that no apps == no base needed, no prerequisites
<Chipaca> just confirmed, 'snap install gtk-common-themes' pulls in core
<zyga> fun
<zyga> I'll file a bug
<Chipaca> kenvandine: can you think of a core18-based snap that uses gtk-common-themes?
<Chipaca> i notice gimp doesn't
<kenvandine> Chipaca: yes, several
<kenvandine> evince
<kenvandine> gnome-chess
<kenvandine> gnome-clocks in candidate
<Chipaca> hm
<Chipaca> that's interesting, maybe the check is smarter now
 * Chipaca wonders
<kenvandine> Chipaca: i'm in the process moving all the gnome snaps to core18/gnome-3-28-1804
<Chipaca> ah,no, there we go
<Chipaca> it got 'core' as well
<kenvandine> not moving the seeded snaps just yet though :)
<Chipaca> zyga: on a bare system (no snaps at all), snap install gimp -> you get core18 and gimp; snap install evince -> you get fun
<Chipaca> core, core18, evince, gnome-2-28-potato, gtk-common-themes
<pedronis> zyga: Chipaca: we cannot change what no base means,  we might need a way to express no base tough
<kenvandine> base: none ?
<kenvandine> for gtk-common-themes
<pedronis> that will try to find a snap called none atm
<zyga> Chipaca: https://bugs.launchpad.net/snapd/+bug/1802541
<mup> Bug #1802541: Installing a snap without any apps or hooks should depend on the base snap <snapd:New> <https://launchpad.net/bugs/1802541>
<zyga> pedronis: I think we could just be smart about what prerequisites to pull
<zyga> pedronis: but we'd have to see the snap.info of a snap from the store
<zyga> including apps/hooks
<Chipaca> zyga: i think you a not
<pedronis> zyga: maybe
<Chipaca> zyga: note we aready get the raw yaml to look at content interface thinigs
<Chipaca> things
<zyga>  ah, I didn't know that
<zyga> we may also need to know if hooks exist
<zyga> even if undeclared in yaml
<zyga> it would be nice if snapcraft created full hook defs
<pedronis> that is a bit balooning
<Chipaca> zyga: i edited the description to include a 'not', and changed the wording a bit
<pedronis> anyway good that is captured in a bug
<Chipaca> zyga: "even if undeclared in yaml", when are they declared?
<zyga> Chipaca: when they need interfaces
<zyga> they _can_ be declared
<zyga> it would be neat if store knew
<zyga> yep
<zyga> cachio: about that python kvm thing, you can clone the repo and run it locally
<kenvandine> zyga: thanks for the bug report, that was exactly the issue i was concerned with
<zyga> cachio: the main idea is that you can just talk to kvm to make a super fast snapshot
<zyga> and restore it
<zyga> in the project I linked to it is used to drive tests
<zyga> that run on the inside
<zyga> the whole VM is reverted before each test
<zyga> so it's always 100% pristine
<zyga> since it is written for testing initramfs it is a bit specific in how it operats
<zyga> (tests are written in python and are defined on the host, are transformed to shell and run in the initrd in the guest)
<zyga> but that's all orthogonal to the main idea of snapshots
<zyga> I mainly mentioned it because it is extremely fast
<zyga> that test def setup ran >>10 tests in pristine VM per_second_ on my old laptop
<mup> PR snapd#6125 closed: release: 2.36.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6125>
<mvo> hm, 6039 needs a second review
<zyga> looking
<mvo> zyga: you reviewed it already
<mvo> :)
<zyga> ah :/
<pedronis> mvo: Chipaca should look at it
<pedronis> #6039
<mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<cachio> zyga, it is pretty nice
<cachio> it is using the snapshot features provided by qemu
<cachio> zyga, it also set the qemu monitor
<cachio> and uses it to save/restore the vm
<cachio> this it nice
<pedronis> Chipaca: zyga: I wrote something in the bug about the challengens
<zyga> pedronis: thanks, I replied
<zyga> I think it's not a high priority problem
<zyga> but we should take it into account if we change how installation works
<mborzecki> zyga: fyi, gpg 2.2.10 is in arch too, but the test that fails in TW does not seem to fail there
<zyga> isn't it disabled there?
<zyga> if not then that is indeed curious
<zyga> something else is at play
<zyga> but that's also reassuring :)
<mborzecki> heh, let me check
<zyga> mborzecki: would you be interested in looking at the makefile in https://github.com/snapcore/snapd/pull/6111
<mborzecki> zyga: it's not
<zyga> I think it would (or might be) good fit for arch
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<mborzecki> (not disabled)
<zyga> should cut the boilerplate
<zyga> and provide consistency
<zyga> (ack)
<zyga> uh, 19:00 on Friday
<zyga> sorry about that :)
<zyga> well, I'll get back to some coding I want to finish but I don't expect reviews at this time :)"
<mborzecki> zyga: checked pacman log, gnupg update to 2.2.10 arrived on 05.09, so it's been a while
<mborzecki> zyga: as for the PR, i looked briefly in the morning but didn't leave any comments, imo there should a way of overriding things like -buildmode, fedora does =pie, arch doesn't care and yocto does =shared by default
<zyga> yes
<zyga> that's indigo
<mborzecki> zyga: also LC_ALL=C.UTF-8 is non standard glibc extension
<zyga> this is just temporary
<zyga> all of the go build policy is handled by indigo
<zyga> ish -- I think we need something like that
<zyga> I mean
<zyga> LC_ALL=C won't pass tests
<zyga> we need either a real locale
<zyga> or C.UTF-8
<pedronis> zyga: about those gpg tests, have you tried what the test tries manually on a box, without expect etc in the way? that seems step one to understand if it's a test issue vs other
<pedronis> I mean a box with the affected distro
<mborzecki> zyga: or fix the culprit
<zyga> pedronis: partially, I only ran it in a test VM as I wasn't fully familiar with what that test was doing to keys, I can run it on my machine easily though
<zyga> (I'm developing on tumbleweed for the last few weeks
<zyga> mborzecki: remember this was for release :)
<zyga> mborzecki: to fix it we just need to set environment in a bunch of tests
<pedronis> Chipaca: given that #6039 is introducing that error, maybe that fact that is not good is a blocker :)
<mborzecki> zyga: heh, i see that now, * instead of â
<mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<zyga> mborzecki: yes :)
<zyga> Chipaca: ^
<zyga> Chipaca: tests don't mock locale so they fail if you have unset LANG and stuff
<pedronis> Chipaca: this is 2.37 material, if you have suggestion for a better error, please suggest
<mborzecki> Chipaca: pedronis: how about `classic confinment requested, but snap %q is not a classic confined snap` ?
<mborzecki> the original version by mvo was `classic confinment requested for a non classic confined snap', maybe a variant of this could work
<pedronis> mborzecki: I think Chipaca is suggesting that it's one of those longer messages, explaining a bit the concept as well
<pedronis> I'm honestly a bit too tired right now to make a suggestion
<pedronis> like the ones for SnapNeeds*
<pedronis> maybe the error needs to carry the actual confinement to help produce a better error
<pedronis> message
<pedronis> as well
<mup> PR core-build#37 opened: Introduce recovery-mode for factory-reset <Created by slimjim777> <https://github.com/snapcore/core-build/pull/37>
<pedronis> mborzecki: Chipaca: I copied this convo in the PR
<Chipaca> pedronis: mborzecki: sorry i was afk
 * Chipaca looks at errors.go
<Chipaca> mborzecki: pedronis: i'm very tired so not sure this suggestion is any good, but something like "snap %q is not compatible with --classic" would spell out exactly what the user did wrong
<Chipaca> my main complaint is that it doesn't tell the user what they did wrong, and doesn't tell them how to fix it
<Chipaca> "wtf drop that --classic nonsense" would work too
<Chipaca> mborzecki: pedronis: let's all EOW and worry on Monday/Tuesday/whatever is the appropriate day next week
<mborzecki> ack :)
<zyga> 2.36.1 in opensuse now
<zyga> mborzecki: is arch package up to date? :-) (wink wink)
<mborzecki> hehe
<mborzecki> nah, haven't pushed an update yet
<zyga> I will push the snapd sync in a moment
<zyga> or maybe not,
<zyga> it's trivial bump of two lines
<zyga> can wait
<pedronis> Chipaca: it's fine, as I said it's not urgent to land afaict and I'm tired too
<pedronis> Chipaca: I pasted that into the PR in case
 * pedronis goes away
<zyga> o/
<pedronis> ttfn
<Chipaca> o/ eow here
#snappy 2018-11-10
<mup> PR snapd#6127 opened: overlord/ifacestate: setup systemd backend in separate pass <Created by zyga> <https://github.com/snapcore/snapd/pull/6127>
<thresh> when I run snap run --shell $snap, where is the rootfs for the snap?  do I get the same env vars as defined by snap run $snap?
<thresh> trying to debug why vulkan doesnt work inside the snpa
<zyga> thresh: cd $SNAP
<thresh> right :)
<zyga> thresh: the env is the same except for things defined in the wrappers
<zyga> that are in $SNAP
<zyga> you can extract variables from there
<thresh> so vulkaninfo shows lots of stuff
 * zyga runs for lunch :)
<thresh> is there a way to enable ptrace in the confined env?
<thresh> I dont want to launch & strace my snapped app, I want to strace something else
<thresh> (vulkaninfo to be exact)
<thresh> yeah I guess I can just change the wrapper & snap try it
<thresh> INFO: [loader] Code 0 : Found ICD manifest file /snap/vlc/x3/usr/share/vulkan/icd.d/intel_icd.x86_64.json, version "1.0.0"
<thresh> open("/usr/lib/x86_64-linux-gnu/libvulkan_intel.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
<thresh> eh
<thresh> so I guess that's why it doesnt work
<thresh> made vulkan video output work inside a snap \o/
<thresh> got to apply a hack on top of vulkan ubuntu packaging: https://git.videolan.org/?p=vlc.git;a=commitdiff;h=58c57d1c4bdf17459f74dd70a3374f25cb38911e
<ogra> thresh, awesome !
#snappy 2019-11-04
<mborzecki> morning
<mup> PR snapd#7703 closed: cmd/snap: make 'snap list' shorten latest/$RISK to $RISK <Channels ð·ï¸> <Simple ð> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7703>
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mup> PR snapd#7454 closed: interfaces: extend the fwupd slot to be implicit on classic <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7454>
<zyga> good morning
<mborzecki> zyga: hey
<zyga> 5 days left
<zyga> let's make it count!
<mup> PR snapd#7717 closed: tests/docker-smoke: add minimal docker smoke test <Simple ð> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7717>
<mborzecki> mvo: some conflicts in #7714
<mup> PR #7714: overlord: refactor mgrsSuite and extract kernelSuite <Created by mvo5> <https://github.com/snapcore/snapd/pull/7714>
<mborzecki> mvo: i can look into that, unless you've already fixed it
<mvo> mborzecki: missed the ping, either way is fine
<mvo> hey zyga
<mborzecki> mvo: ok, i'll push it
<mvo> ta!
<mborzecki> mvo: #7715 is based on 7714 isn't it?
<mup> PR #7715: overlord: add base->base remodel undo tests and fixes <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>
<mvo> mborzecki: correct
<mborzecki> mvo: ok, i'll update that one too then
<mvo> ok
<mvo> mborzecki: it also needs a review and some more things (that samuele pointed out) but lets do the mechanical bits first
<mvo> mborzecki: hm, looks like 7665 is in some strange state, says its waiting for CI for me, mabe we ned to push master to it
<mborzecki> mvo: yeah, i'll be addressing your comments and will push there
<mvo> ta
<zyga> brb
<mvo> mborzecki: are you working on the remodel-kernel-undo-tests PR? it has no conflicts so I could just address the feedback and push and ask you to review :) ?
<mborzecki> mvo: no, i just pushed a little patch to 7714 and gave it +1
<mvo> mborzecki: cool, I will just address samuele points in 7682 then and push and then you can review that too,
<mborzecki> mvo: i think we can land 7714 and then update 7715, otherwise i'll get messy i think
<mvo> mborzecki: its a subset so review should be trivial
<mvo> mborzecki: aha, even better
<mvo> mborzecki: one small issue is that 7714 includes 7682
<mvo> mborzecki: so I need to make this one ok first ./
<mvo> mborzecki: sorry, I should have done the refactor indepedantly
<mborzecki> haha
<zyga> re
<pstolowski> morning
<zyga> hey pawel
<mborzecki> pstolowski: hey
<pstolowski> o/
<zyga> mborzecki: trying to fix the name=snapd branch now
<zyga> mborzecki: made it conditional on v1/v2 mode, to use different directories
<zyga> hoping /sys/fs/cgroup/snapd survives into lxd
<zyga> and permissions there are sufficient
<mborzecki> zyga: you likely need to merge master, paralle instances landed on friday
<zyga> mborzecki: I know, I plan to soon
<mborzecki> mvo: left a comment about retry-tool in place of the while loop, feels a bit awkward bc of grep
<mborzecki> mvo: so i'll skip this one, and the mockSuccessfulReboot(), actually that second one is mroe interesting, it assumes snap_mode = try, but we don't switch the gadget snap during reboot, only base/kernel
<zyga> brb
<mvo> mborzecki: aha, right - good point
<mvo> mborzecki: sorry, I missed that
<mborzecki> mvo: no worries, i think we could make mockSuccessfulReboot work with some tweaking to catch unintended test cases
<mvo> mborzecki: *nod*
<zyga> chrome said to restart
<zyga> mvo: ^
<Chipaca> mborzecki: mo'in. Does your +1 to #7669 apply to #7670? :)
<mup> PR #7669: snap, cmd/snap: support (but warn) deprecated multi-slash channel <Channels ð·ï¸> <Needs Samuele review> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/7669>
<mup> PR #7670: cmd/snap: support (but warn) using deprecated multi-slash channel <Channels ð·ï¸> <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7670>
<mborzecki> Chipaca: let me take a look
<mborzecki> Chipaca: idk, the suffering strings are gone ;)
<Chipaca> mborzecki: ikr
<Chipaca> mborzecki: OTOH valid value + error is a weird flex
<Chipaca> mborzecki: how did you make a comment on an error message that is no longer there?
<mborzecki> haha
<mborzecki> yeah
<mborzecki> Chipaca: btw. do we use the british or us spelling in the messages?
<Chipaca> mborzecki: us :-/
<zyga> another test pass,
<zyga> test passed
<zyga> that's very promising
<zyga> running more challenging test
<Chipaca> mvo: #7714 has two +1s but it includes #7682 which has some nits pointed out by pedronis
<Chipaca> mvo: up to you whether to merge it and then followup or what
<mup> PR #7714: overlord: refactor mgrsSuite and extract kernelSuite <Created by mvo5> <https://github.com/snapcore/snapd/pull/7714>
<mup> PR #7682: overlord: add kernel remodel undo tests and fix undo <Priority :racehorse:> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7682>
<Chipaca> grr
<Chipaca> #7682
<mup> PR #7682: overlord: add kernel remodel undo tests and fix undo <Priority ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7682>
<Chipaca> better :)
<mvo> Chipaca: I'm just finishing the unit test asked for in 7682, should be ready in some minutes
<zyga> making progress, next up is the lxd test
<mvo> Chipaca, mborzecki  7682 should be ready now, I addressed the comments from samuele
<zyga> updated cgroup dir based on v1 / v2 mode in snapd side, resuming tests
<mvo> Chipaca, mborzecki actually, yeah, probably/possible easier if I merge 7714 and do my other bits as a followup, up to you if you feel this is easier to review
<zyga> mborzecki: the changes are not too terrible, not great
<Chipaca> mvo: sgtm
<zyga> mborzecki: we should do runc-like change later on
<mborzecki> mvo: landing 7714 sgtm
<mup> PR snapd#7714 closed: overlord: refactor mgrsSuite and extract kernelSuite <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7714>
<mvo> mborzecki: 7665 now has conflicts, let me know if I should help. and a strange spread failure
<mvo> Chipaca, mborzecki 7682 should be much simpler to review now :)
<Chipaca> \o/
<zyga> tests passed
<zyga> good
<zyga> moving on
<mborzecki> mvo: that failure in 7665 looks like something raised in the forums during the weekend
<zyga> running the lxd test now
<mborzecki> mvo:  https://forum.snapcraft.io/t/snap-remove-fails-because-of-user-data/13990
<Chipaca> mborzecki: saw that one, still puzzled by it
 * Chipaca replies with as much
<mvo> mborzecki: ok, feel free to restart the test if its unrelated
<pstolowski> zyga: i've responded to #7675
<mup> PR #7675: release: preseed mode flag <Prebaking ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7675>
<zyga> pstolowski: thank you, looking now
<zyga> pstolowski: replied
<zyga> mvo: lxd test has passed with the new feature enabled *outside*
<pstolowski> zyga: thanks
<zyga> mvo: this is promising, looking at making the inside case now
<zyga> mvo: the other case is just test adjustment which will later on become a change to lxd
<zyga> mvo: this is really promising, I think it will work
<mvo> zyga: cool
<mborzecki> Chipaca: hmm regarding snap download, there's some code in image/helpers.go that just calls os.Exit(1) on sigint ;)
<Chipaca> mborzecki: does it also Finalize the progress bar?
<Chipaca> (also, yes, exit 1 would probably be the right thing to do)
<Chipaca> (but after finalizing the progress bar)
<mborzecki> it's Finished() followed by os.Exit()
<Chipaca> perfect :)
<Chipaca> Finished, Finalize, Fwhatever
<mborzecki> hm also, snap download --remote leaves a *.partial file behind, but one that goes via snapd does not?
<Chipaca> make-the-terminal-usable-again
<Chipaca> mborzecki: --direct doesn't leave a .partial when interrupted?
<Chipaca> that'd be a(nother) regression
<mborzecki> Chipaca: --direct does leave *.partial, the non-direct one does not
 * mborzecki tries to parse what he just wrote
<Chipaca> mborzecki: ah, that's a known regression
<Chipaca> mborzecki: non-direct does not know how to resume
<Chipaca> and indeed it'll take a refactor of the download endpoint to do it
<mvo> Chipaca: yeah, I think we need to talk what to do - I think I will give your idea of "snap download --indirect" a shoot and then we can iterate on this without regressions
<mvo> mborzecki: thanks for looking at this so carefully!
<Chipaca> mvo: my biggest concern is that i don't see how to get resume without a rest api refactor
<Chipaca> actually thinking a bit more, it's a minor refactor, a change to which things are obligatory i guess
<Chipaca> and a change to how it's used for sure
<Chipaca> that's my brain coming back to me with this that i'd been mulling over the weekend
<Chipaca> mvo: for snap download, what you want to do is first do an exact search by name, and take the info you get back to (1) check whether you have that file already, (2) check if you have a partial, (3) download exactly that revision, maybe with a resume in it
<Chipaca> so the refactor for download is (a) always take the revision, and (b) optioanlly take a resume position
<Chipaca> that's at the api level; internally it's a bit bigger of a change because snap download itself shouldn't be doing the two requests, i guess? in that maybe there's a way to not have to hit info again server-side
<Chipaca> in the fast case at least
<Chipaca> but that can be a later optimization
<Chipaca> or
<Chipaca> OR!
<Chipaca> we could make snap download take the snap id, and then reconstructing the download irl is easier?
<zyga> mvo: I'm working on the denial, no idea what is it yet
<zyga> mvo: I've simplified the test and will iterate interactively on the next shell
<mborzecki> Chipaca: for starters we could just write the data to *.partial file and rename, seeing *.snap that isn't really complete is bit confusing
<mborzecki> cachio: did you have a patched version of spread that can run tests in a specific order?
<cachio> mborzecki, yes
<mborzecki> can you point me to it?
<zyga> currently stuck on one denial:
<zyga> cannot remount /sys/fs/cgroup read-write: Permission denied
<zyga> Nov 04 12:13:45 nov041205-146458 audit[28564]: AVC apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-my-ubuntu_</var/snap/lxd/common/lxd>" name="/sys/fs/cgroup/" pid=28564 comm="snap-confine" flags="rw, remount"
<cachio> mborzecki, sure
<zyga> I changed the apparmor profile of lxd to contain
<zyga>   mount options=(remount, rw) /sys/fs/cgroup/,
<cachio> mborzecki,  https://cachio.s3.amazonaws.com/spread/spread2
<zyga> but perhaps I misunderstand, need to check what those paths map to in practice
<mborzecki> zyga: isn't that a profile that lxd created for the container?
<zyga> mborzecki: yes
<mborzecki> cachio: thanks!
<zyga> mborzecki: the denial is for the profile from lxd
<cachio> mborzecki, np
<zyga> mborzecki: that is what I am changing
<zyga> mborzecki: inside the test I patch and reload that profile
<zyga> mborzecki: on the container host
<mborzecki> ah ok
<cachio> just use: -order -workers 1
<cachio> mborzecki, this will use 1 instance for all the tests
<cachio> and run the tests in the order you add them in the command line
<mvo> Chipaca: thank you, yeah, in some sense its an optimization
<zyga> mborzecki: interesting, I can switch all of the apparmor for lxd into complain mode
<mborzecki> cachio: ok, running it now
<zyga> and it doesn't help
<zyga> I probably don't understand what is really going on
<mvo> mborzecki: 7665 has now conflicts :/
<mborzecki> mvo: mhm, first trying to catch the problem with removal of /var/snap/
<mvo> mborzecki: no worries, I can fix the conflicts
 * pstolowski lunch
<mborzecki> mvo: thanks for merging master to the remodel branch!
<mvo> mborzecki: no worries, I want to see it merged :)
<Chipaca> mvo: is there an IRL bug that triggered #7682?
<mup> PR #7682: overlord: add kernel remodel undo tests and fix undo <Priority ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7682>
<cachio> zyga, hey
<mvo> Chipaca: no real life bug
<cachio> did you see something like this: https://paste.ubuntu.com/p/6NYyBbjtMW/
<Chipaca> mvo: phew
<mvo> Chipaca: it was just the result of missing undo testing in the handlers code
<mvo> Chipaca: yeah
<cachio> it is failing on ubunto-core-18 tests on pi3 for edge cahnnel
 * mvo gets some lunch
<zyga> making some more progress
<zyga> hey cachio
<zyga> I realized lxd start / stop rewrites the container profile
<zyga> so my changes are not effective
<zyga> I started the container
<zyga> and use apparmor parser to switch it to complain mode after taht
<zyga> I used aa-status to check what the outcome is after taht
<zyga> and see that some of the chagnes are applied, there are a number of processes with complain profiles
<zyga> but I can see that the bulk of the container is confined
<zyga> I'm exploring why
<zyga> the output of aa-status is
<zyga> https://www.irccloud.com/pastebin/3m0f3aYx/
<zyga> in case someone figures out why
<cachio> zyga, all this is related to the mount namespaces error?
<zyga> cachio: no, this is ongoing work on new cgroup
<cachio> ahh, ok
<zyga> I managed to switch snap-confine profile into complain mode
<zyga> it seems there's no propagation of any kind
<zyga> so changing the profile on the host doesn't impact profiles derived from it in any way
<zyga> but that's fine
<zyga> so
<zyga> progress:
<zyga> snap-confine inside is in complain mode but I still get a denial
<zyga> looking at why now :)
<zyga> perhaps I just put the wrong one in complain mode
<zyga> it's not re-execing
<zyga> checking
<zyga> more profiles in complain mode https://www.irccloud.com/pastebin/cwRZuduL/
<zyga> mvo: in the meantime I'm running all tests to see if anything is impacted , 50% there, I'll know soon
<mborzecki> google:ubuntu-core-18-64 .../tests/main/remodel-gadget# ls /var/snap/pc
<mborzecki> 1001  1002
<mborzecki> heh, wtf??
 * diddledan sees zyga wants complaints so moans that it's not bed time yet
<zyga> _weird_
<zyga> improvement
<zyga> I got ALLOWED messages
<zyga> so it did switch to complain mode
<zyga> and the things mentioned were really about what is new in the code
<zyga> but I got the error still
<zyga> but even though i still got an error from ount
<zyga> checking why
<zyga> the error in case anyone sees error in my logic https://www.irccloud.com/pastebin/9JmCN4RA/
 * Chipaca wanders off mumbling something about lunch
<zyga> Chipaca: good idea
<zyga> I'll update the test to do what I did manually
<zyga> and wrap up for lunch
<zyga> test modified, restarted clean
<zyga> I think it is better
<zyga> I'll double check the code, maybe there is something silly in my patch
<zyga> mvo: we are all doomed ;-)
<zyga> https://m.tagesspiegel.de/berlin/experten-warnten-schon-2017-it-katastrophe-am-berliner-kammergericht-kam-mit-ansage/25163810.html
<zyga> I want more of https://mspoweruser.com/microsoft-4-day-workweek/ though ;)
<zyga> but first, let's ship it for vancouver
<zyga> mvo: regular tests are move than 90% complete now
<zyga> mvo: if anything exploded I'll know soon
<mup> PR snapd#7718 opened: sandbox/seccomp: accept build ID generated by Go toolchain <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7718>
<mborzecki> mvo: zyga: it'd be nice to get it for 2.43
<mborzecki> also pinged jdstrand for a review though the bit is trivial
<cachio> mborzecki, hey, this error is hapenning when updating the arch image https://travis-ci.org/snapcore/spread-cron/builds/607000141#L2056
<cachio> any idea ?
<mborzecki> cachio: yeah, looks like the package needs an update
<mborzecki> let me see if there's anything i can do about it
 * zyga is afk for lunch now
<zyga> only lxd and mount-ns tests failed, so good and expected
<cachio> mborzecki, nice thanks
<mborzecki> cachio: pinged the guy who maintains the package with a patch that should fix it, let's see if it lands today/tomorrow, if not i can fork the package, put it on github and we can pull it from that location
<cachio> mborzecki, nice thanks!!
<zyga> hmmm
<zyga> stgraber: hello, can you please help me how lxd uses apparmor profiles
<zyga> stgraber: I'm trying to understand how to switch the entire container into complain mode
<zyga> stgraber: I tried running apparmor_parser -r --complain /var/snap/lxd/common/lxd/security/...
<zyga> stgraber: using aa-status on the host I can see some changes but I still see a number of confined profiles
<zyga> er, enforcing profiles
<zyga> e.g. the output of aa-status from the container host is
<zyga> https://www.irccloud.com/pastebin/08Gl52Z9/
<zyga> I would appreciate if you can shed some light on this
<stgraber> LXD regenerates and reload the container profile on container startup, files are mostly there to inspect but changes won't persist
<zyga> stgraber: right, but is there more than one file to change?
<zyga> stgraber: I'm getting things I don't quite understand, after a lot of hand-called apparmor_parser --complian --reload I get some ALLOW but still some EPERM and nothing logged with DENIED
<zyga> stgraber: is it safe to change any profiles after the container is started?
<zyga> stgraber: note that I suspect that "deny" rules silence logging
<zyga> stgraber: so perhaps what I'm hitting is a deny somewhere
<zyga> stgraber: alternatively
<zyga> stgraber: is there a knob on lxd that would allow me to run a container with complain more apparmor?
<zyga> 15 minute break
<zyga> stgraber: I'm all ears if you have some ideas
<zyga> stgraber: but I'll be sending patches to lxd to help with this case, it's a one-liner *I believe* for now
<stgraber> zyga: what'
<stgraber> zyga: what's the one liner?
<zyga> stgraber: to remount /sys/fs/cgroup rw
<zyga> all I need is
<zyga> mount -o remount,rw /sys/fs/cgroup
<zyga> mkdir /sys/fs/cgroup/snapd
<zyga> mount -o remount,ro /sys/fs/cgroup
<zyga> mount -t cgroup cgroup /sys/fs/cgroup/snapd -o none,name=snapd
<zyga> that's all
<zyga> I believe all but the rw remount are permitted
<stgraber> zyga: I'm reasonably sure that we cannot allow that without causing a big security issue
<zyga> hmmm
<zyga> because of remount or because of something else
<zyga> please tell me what you think, it's important in our design
<stgraber> because of the apparmor rule generator being broken
<zyga> stgraber: is there anything we can do?
<stgraber> if rw,remount hits the parser bug, no
<zyga> aha
<stgraber> adding such a rule would allow every single mounts to succeed
<stgraber> zyga: why are you trying to mount your own v1 hierarchy anyway?
<zyga> stgraber: can we do something else to avoid the need to mkdir, can we mkdir early in systemd somewhere?
<zyga> stgraber: for tracking processes correctly, it's the only way we found that works well in v1 and v2 mode
<stgraber> zyga: how do you do it in v2 where /sys/fs/cgroup is a cgroup2 mount?
<zyga> stgraber: in /run/snapd/cgroup
<stgraber> ah so you're assuming that a cgroup2 system will still have cgroup1 enabled in the kernel?
<zyga> stgraber: I wanted it to be in /run/snapd/cgroup now but this is more complex to do so that it works in lxd correctly
<zyga> stgraber: yes, for now yes
<zyga> stgraber: we need to work on extending cgroup2 usage in systemd
<stgraber> zyga: why would /run/snapd/cgroup be harder in LXD?
<stgraber> zyga: that should actually be easier. Obviously you'll have the problem that this will fail on any system which doesn't have LXD on the host
<zyga> stgraber: because /run is changed by lxd and we need to change it so that it is not necessary to have that mount inside the per-snap mount namespace
<mup> PR snapd#7670 closed: cmd/snap: support (but warn) using deprecated multi-slash channel <Channels ð·ï¸> <Needs Samuele review> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7670>
<stgraber> zyga: so you're going to break a LOT of systems, but that's going to happen regardless so long as you want your own named controller
<zyga> stgraber: can you explain how we will break things?
<stgraber> zyga: unprivileged users are only allowed to mount existing controllers
<stgraber> zyga: if your host doesn't have a name=snapd controller, no container will be allowed to mount it
<zyga> aha
<zyga> the host will have it
<stgraber> no it won't
<zyga> perhaps I misunderstand
<stgraber> not for anyone who's not using the snap
<zyga> and are there people who are not using lxd as a snap that will run into this?
<stgraber> so you'll break all chromebooks, all gentoo users, all alpine users, most arch users, ...
<zyga> I see
<zyga> that's bad news indeed
<zyga> I wonder if we have some ideas as a way out then
<zyga> stgraber: can you tell me more about the rule
<stgraber> we actually ran into that very same problem when systemd introduced name=systemd in the first place
<zyga> stgraber: about what makes the cgroup mount fail if it doesn't exist on the host
<stgraber> any distro which wasn't using systemd was unable to run systemd containers because of it
<zyga> stgraber: note that the feature is still not on by default, or merged for that matter
<mborzecki> mvo: got a fix for the test failure that occurred in #7665, i'll propse it separately unless the travis job that's currently running fails
<zyga> stgraber: we just need _a_ way to track processes reliably
<mup> PR #7665:  devicestate: add support for gadget->gadget remodel  <Priority ð> <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
<zyga> stgraber: and we have found none better than this
<stgraber> zyga: the kernel effectively looks at all existing controllers (same list you'd see in /proc/self/cgroups) and anything that's not in that list, you can't mount unless you're real root outside of a cgroup namespace
<zyga> I see
<zyga> and it treats the name=... thing as a controller in this sense?
<zyga> note that our hierarchy has no controllers at all
<zyga> but I'm sure you know that, just checking if I understand right
<stgraber> zyga: given that your current plan will not work on any distro which has fully transitioned to cgroup2 (no more cgroup1 in kernel) and will break for a lot of container users, it doesn't seem to me like a particularly good plan :)
<stgraber> zyga: yes
<zyga> stgraber: there are no better plans yet
<stgraber> zyga: you wouldn't want an unprivileged container being able to mount thousands of those, allocating global kernel structs
<zyga> stgraber: pure v2 doesn't let us track processes because we'll interfere with systemd
<stgraber> zyga: can't you just keep snap-confine as the parent of the processes in the snap and make it a subreaper?
<mborzecki> zyga: stgraber: tbh we don't seem to have a reliable, race free way of tracking processes in v2 world without complicating things
<zyga> stgraber: if we do that, we know if a process dies
<zyga> stgraber: but not if there are any left
<stgraber> zyga: but you know that when you die all subprocesses will too
<zyga> stgraber: we'd need to match fork and exit reliably but that's not what subreaper can do
<zyga> stgraber: I'm not sure I follow, are you saying that we can then kill snap-confine tracking process to kill all the children?
<stgraber> zyga: yes
<zyga> stgraber: that's not what we are trying to do
<zyga> stgraber: the goal is to know when it's safe to refresh
<zyga> stgraber: when no apps are running
<zyga> stgraber: in a zygote-like mode when snap-confine sticks around and watches processes die
<zyga> stgraber: we could perhaps know something useful but I don't believe we can do what we want to with just that
<zyga> mborzecki, mvo: I think we need to abort and come up with another idea
<zyga> based on what stgraber said above I don't believe this is something we can salvage unfortunately
<zyga> this still leaves us with no tracking, let alone notification past v1
<zyga> stgraber: how did you fix the issue affecting systemd needing to mount name=systemd
<stgraber> zyga: most distros switched to systemd, the rest are mounting the systemd controller on the host anyway
<zyga> stgraber: I see
<mvo> mborzecki: thank you
<zyga> mvo, mborzecki: can we meet later today
<stgraber> zyga: so sadly there's no nice way that I know for you to get notified when a namespace goes away, otherwise you could use something like a uts namespace
<zyga> I have an idea
<zyga> stgraber: I planned to use release agent on the name=snapd hierarchy
<zyga> but thinking about it now
<zyga> how to work without any cgroups
<stgraber> zyga: have one namespace per snap, dump all new processes in there, then when you want to know if the snap is safe to refresh, check if any process uses it
<zyga> stgraber: one uts namespace?
<zyga> stgraber: and in v2 mode?
<zyga> stgraber: in v1 we can use the freezer for that
<zyga> stgraber: (note that we need to have per-app understanding in our current model but perhaps we could drop that)
<zyga> stgraber: but what the name=snapd idea was about is something that works both in v1 and v2 mode
<stgraber> zyga: doesn't matter v1/v2, this wouldn't use cgroups at all
<zyga> ah
<zyga> sorry
<zyga> I didn't understand
<zyga> uts namespace
<zyga> so iterate over process
<zyga> and check which uts namespace is used by each?
<zyga> and check if any of those match that of our snap processes?
<stgraber> yeah, that's the part that's not amazing, having to iterate but otherwise should work fine
<zyga> yes
<zyga> that might w
<zyga> that might work
<zyga> I was thinking to use the existing mount namespace
<zyga> given that we already create one for strict snaps
<zyga> and are about to for classic snaps
<stgraber> yeah but your mntns are per snap + per user or something so that wouldn't work so well
<mup> PR snapd#7682 closed: overlord: add kernel remodel undo tests and fix undo <Priority ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7682>
<zyga> stgraber: yes
<zyga> stgraber: so you are saying we could create and save one for each pkg.app pair
<stgraber> the tracking with a uts namespace would still be bypassable by any snap allowed to do fancy clone/unshare, but that's unlikely to really matter, you're not building security on this, if a snap wants to make itself break on refresh, whatever :)
<zyga> stgraber: correct but the kind of snaps that would be hurt by this (think things like docker) really would as they would get unexpected refresh semantics
<zyga> stgraber: but thank you for the idea, I think this is workable
<stgraber> zyga: yeah, on initial startup, you'd unshare the uts namespace, bind-mount its inode somewhere in /run/snap as you do for mntns, then any new process gets added using setns and to see if it's safe, you iterate through /proc for anything that has a matching inode on ns/uts
<zyga> stgraber: correct
<zyga> stgraber: I agree this would work
<stgraber> you could even make actual use of the uts namespace and give each snap a unique hostname
<zyga> stgraber: I think that will break snaps
<zyga> stgraber: especially it would be unexpected for snap with classic confinement
<stgraber> indeed :)
<zyga> stgraber: or maybe the time namespace
<zyga> ;-)
<stgraber> one thing to keep in mind is that if the hostname changes on the host, it won't in the snap
<zyga> stgraber: yeah, I think it's a good route but we need to plan which namespace to use
<zyga> uts doesn't feel like it
<stgraber> you certainly don't want to use ipc, mnt, net, pid or user
<zyga> I would ideally do it via mount namespace and just save those with finer granularity
<stgraber> so you have two options really
<mborzecki> feels like it's the same borderline use as the pids controller right now
<zyga> I think mount is indeed unworkable on second thought
<stgraber> mount is the most used namespace, a lot of software mess with it and snapd already has more than one mntns per snap, so seems pretty hard to track
<stgraber> cgroup and uts are the two easy ones, cgroup may actually be a better option
<stgraber> hmm, though it may seem weird
<stgraber> yeah, no, don't use cgroup, you'll break lxd :)
<stgraber> uts won't break us though, the only issue with it is the hostname changes not getting propagated until a snap restart, but I don't think anyone will really notice/care
<stgraber> zyga: we could probably do something with pidfds though, but that's likely to be an issue due to lack of kernel support right now and it still being in very active development (by us)
<zyga> stgraber: how about netlink
<zyga> and observing all process activity
 * cachio lunch
<zyga> so match fork/exec/exit
<stgraber> zyga: I didn't think we had a reliable API for that in netlink, short of having to ptrace stuff
<zyga> stgraber: I think there's something, not ptrace, there's a program that shows that (fork exec across all system) using netlink
<stgraber> zyga: also, that'll break when snapd restarts as you'll miss all those events
<zyga> but yeah, I don't know how that works yet
<zyga> stgraber: yes, it'd have to be a special process that's never quitting
<stgraber> and if it's relying on tracing, then it won't work in containers
<zyga> zygote like per snap
<zyga> AFAIK it is pure netlink
<mborzecki> stgraber: alternative we considered before was putting the process in a well-known cgroup name eg. snap.app under the cgroup created for it by systemd (just one level deeper), but that'd involve walking /proc/*/cgroup
<mborzecki> and walking /proc/*/cgroup feels like a bad idea
<zyga> in v2 everything is somewhere in a hierarchy somewhere
<stgraber> zyga: forkstat/netlink connector requires real root
<zyga> stgraber: I see
<zyga> stgraber: thank you for checking
<stgraber> zyga: it's also apparently lossy, under load there's no delivery guarantee
<zyga> stgraber: thank you, this is even more relevant
<zyga> stgraber: anything we could use to tag a process with
<zyga> stgraber: I don't mind enumeration
<zyga> it won't be done all the time
<zyga> just in special moments
<zyga> I just want to see if we can identify a process as belonging to a snap
<zyga> even weird things like containers
<zyga> stgraber: thank you for all the input, it was invaluable,
<zyga> I think we need to rethink the idea
<stgraber> zyga: there have been discussions about ptags in the past but nothing ever got merged
<mup> PR snapd#7719 opened: tests/main/gadget-update-pc: cleanup per-revision directories <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7719>
<mborzecki> mvo: this addresses the failures due to /var/snap/pc/<rev> directories being left behind in the tests
<mborzecki> mvo: ^^
<stgraber> zyga: effectively arbitrary process tags which would be inherited and could even be marked immutable in some cases, it was one of the ideas put forth to solve the audit id issue for containers but after years of bikeshedding, nothing really happened
<mvo> mborzecki: nice, *thank you*
<zyga> stgraber: utterly crazy idea, set timerclask_ns to a unique value, use that
<zyga> timerslack_ns
<diddledan> I prefer timertelegram_ns :-p
<diddledan> slack is second place :-D
<mvo> mborzecki: but in a meeting right now so will look in a bit
<mup> PR snapd#7719 closed: tests/main/gadget-update-pc: cleanup per-revision directories <Simple ð> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7719>
<zyga> mvo: do you have time today?
<zyga> mvo: for a 10 minute call?
<zyga> mborzecki: do you have any technical ideas?
<zyga> mborzecki: or can we exchange ideas before your EOD
<zyga> mborzecki: it's fine to say no, perhaps at this stage having some rest would help
<zyga> mborzecki: I don't see a way to solve this issue now
<mborzecki> zyga: tomorrow morning, i'm taking kids to some extra classes in 10
<zyga> ok
<zyga> thank you
<xnox> stgraber:  can snapd run inside lxd, on travis, on arm64? https://travis-ci.org/snapcore/core20/jobs/600808794?utm_medium=notification&utm_source=github_status
<xnox> stoopkid:  i see that core snap fails to setup security profiles?
<xnox> stoopkid:  unping
<xnox> stoopkid:  i see that core snap fails to setup security profiles, and i'm trying to get arm64 ci going with travis.
<zyga> it seems udevadm failed
<zyga> exit code 2
<xnox> i'll restart the build to see if things got any better
<mup> PR snapd#7680 closed: daemon: parse and reject invalid channels in snap ops <Channels ð·ï¸> <Simple ð> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7680>
<stgraber> xnox: just try to run the snap install twice
<stgraber> xnox: that's usually enough for those
<Chipaca> #7671 needs two (2!) reviews, and it's the last chunk of the channels preparatory work
<mup> PR #7671: overlord/patch: normalize tracking channel in state <Channels ð·ï¸> <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7671>
<zyga> Chipaca: is it okay if I call it quits now, sorry, if it was one review I'd jump in
<zyga> but I need to break, think and move a little
<Chipaca> zyga: you can call it quits any time you need to
<Chipaca> zyga: also: stepping away from the keyboard to think is not quitting
<zyga> and all my work is essentially down the drain today
<zyga> so need to think if anything can save it
 * Chipaca hugs zyga 
 * diddledan hugs too
 * zyga hugs Chipaca 
<zyga> thank you guys!
 * zyga hugs diddledan too :)
<zyga> anything, as crazy as possible, that technically works, is good
<zyga> I'll grab my bike and go for a ride
<mvo> zyga: was in meetings, sorry
<oSoMoN> jdstrand, when do you plan on making a release of review-tools that includes https://git.launchpad.net/review-tools/commit/?id=31c894178a8fd110b9f65f0ee532b7e11384f8b8 ?
<jdstrand> oSoMoN: let me prepare a release now
<oSoMoN> perfect, thanks!
<jdstrand> roadmr: hi! would you mind pulling 20191104-1644UTC?
<roadmr> jdstrand: sure
<jdstrand> roadmr: thanks :)
<jdstrand> oSoMoN: fyi ^ (will be a bit before in production)
<oSoMoN> cheers
<zyga> jdstrand: no name=snapd for now
<zyga> jdstrand: if you want to know more I can summarize
<zyga> jdstrand: if not we're going to discuss more tomorrow to see if we have other options
<jdstrand> zyga: I read backscroll
<jdstrand> zyga: it's too bad cause it seemed really elegant. guess it was too elegant, but good thing we got stgraber in the loop
<zyga> yes, the lesson I learned is to ask more experts early
<zyga> I wasn't aware of the extra limitations on rootless containers
<zyga> actually
<zyga> one idea
<xnox> stgraber:  har har har
<zyga> stgraber: can you answer one more question please
<zyga> stgraber: if we set a subreaper per snaps
<zyga> *per snap*
<zyga> stgraber: will we be able to follow that chain reliably
<zyga> from random process, to their parent pid, to the subreaper
<zyga> so that effectively, as long as the "watcher" subreapers are alive
<zyga> we can reliably trace lineage?
<zyga> so the idea is that instead of killing the watchers to kill the "container"
<zyga> we can just scan all processes and try to match them to the reaper
<zyga> hmmm, reading the man page it seems not useful
<zyga> because it is not preserved across fork/clone
<zyga> but is across exec
<zyga> so we could watch our immediately forked process die
<zyga> and if they had any children processes, we could watch them die if their parent (that we started) did quit
<zyga> but I don't see anything in the man page linking the descendants to the reaper in a way that can be read
 * zyga goes to experiment
<zyga> maybe it's not too bad actually
<mup> PR snapcraft#2783 closed: cli: run review tools before pushing to the store if available <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2783>
<zyga> stgraber ^ this works
<zyga> jdstrand: ^ this works
<zyga> we can track all children existence
<zyga> it's even better because the reaper can quit when they all all gone
<zyga> so all we need to do is to unlink a "this snap is busy" file then
<zyga> stgraber: ^
<mup> PR snapcraft#2785 closed: remote-build: add initial command unit tests <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2785>
<zyga> a super-simple interactive reaper
<zyga> https://paste.ubuntu.com/p/kYqhmWGtn3/
<zyga> I don't know if this can be made to work with proper pid tracking (e.g. how would this ever work for services)
<zyga> but it's *something*
<zyga> need to ponder on it more
<ondra> sergiusens did we change way SNAPCRAFT_PROJECT_DIR behaves? I'm getting empty string there
<ondra> sergiusens SNAPCRAFT_PROJECT_NAME and SNAPCRAFT_PROJECT_GRADE seems to work fine
<sergiusens> ondra: no we did not change it
<ondra> sergiusens then there is regression, as suddenly I'm getting empty string
<sergiusens> ondra: on stable?
<ondra> sergiusens stable and candidate
<ondra> sergiusens at least what I tested
<sergiusens> ondra: well stable has not changed for the pass 2 months
<ondra> sergiusens hmm, then it must be this particular snap triggering it
<ondra> sergiusens defo happening also with stable
<litheum> it seems like snap is doing something terribly wrong with apparmor on lubuntu 18.04. i've installed both snap-store and vlc and both of them just throw tons of apparmor errors when i try to start them.
<Chipaca> litheum: could you open a topic about this in the forum?
<Chipaca> litheum: it should just work :-) if it doesn't we want to fix it
<Chipaca> but I, personally, don't want to even think about fixing it at this time
<Chipaca> :-) 'm off to bed
<mup> PR snapcraft#2791 opened: introduce bind-ssh support <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2791>
#snappy 2019-11-05
<mup> PR pc-amd64-gadget#22 closed: Store changes <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/22>
<ogra> hrm
<ogra> why does the home interface not allow me to read data produced by one snap via the other in a ~/snap/<snapname>/current/ subdir
<ogra> ogra@acheron:~/snap/arduino-mhall119/current/Arduino/test$ esptool -cp /dev/ttyUSB0 -cd none -ca 0x40000 -cf test.ino.generic.bin
<ogra> produces :
<ogra> Nov 05 01:39:38 acheron audit[4633]: AVC apparmor="DENIED" operation="open" profile="snap.esptool.esptool" name="/home/ogra/snap/arduino-mhall119/5/Arduino/test/test.ino.generic.bin" pid=4633 comm="esptool" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<ogra> funnily enough i can copy the file to ~/ and am allowed to open it
<ogra> i'd have thought he home interface allows this ?
<zyga> ogra: that is by design
<zyga> Snaps cannot read each otherâs data
<mborzecki> morning
<mup> PR snapd#7718 closed: sandbox/seccomp: accept build ID generated by Go toolchain <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7718>
<zyga> hey mborzecki
<mborzecki> zyga: hey hey
<zyga> mborzecki: we should talk today
<zyga> mborzecki: about how to salvage app tracking
<mborzecki> zyga: do we need mvo for this discussion too?
<zyga> mborzecki: we can split the call into more technical and more strategic parts
<zyga> mborzecki: in this sense we can discuss without him
<zyga> mborzecki: let's try to have a call in an hour or so
<zyga> mborzecki: I have one idea for a frankenstein that might owrk
<zyga> mborzecki: but it's all terrible
<zyga> how can I remove this *** tracker
<zyga> it spawns every few seconds logging stuff
<mborzecki> zyga: what tracker?
<zyga> Started Tracker metadata database store and lookup manager.
<zyga> this shows up every few seconds
<zyga> it is a systemd unit in the user session
<zyga> tried disabling it
<zyga> doesn't hel
<zyga> help
<zyga> disabled search in gnome
<zyga> removing it would remove half of ubuntu
<mborzecki> zyga: try the tracker command, `tracker daemon <something>` iirc
<mborzecki> hm didn't know it's already hooked up as user service
<zyga> thanks, let's see if that helps
 * zyga break
<pstolowski> morning
<mborzecki> pstolowski: mvo: hey
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/7665 is green
<mup> PR #7665:  devicestate: add support for gadget->gadget remodel  <Priority ð> <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
<mvo> mborzecki: yes, I just looked at this and thats great
<mvo> it just needs a second review
<mvo> pstolowski: do you think you could have a look at 7665 ?
<pstolowski> mvo: sure
<mvo> thank you :)
<mborzecki> pstolowski: thanks!
<mborzecki> mvo: in #7715 there's a check whether a base/kernel needsInstall, and otherwise it's just adding task set with link snap task, do you think we need to do the same for gadget snap?
<mup> PR #7715: overlord: add base->base remodel undo tests and fixes <Priority ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>
<mvo> mborzecki: its done this way so that the bootloader is updatd
<mvo> mborzecki: link-snap is a bit overkill actually, all we really need there is just "set-next-boot"
<mvo> mborzecki: we may want something similar for gadget but its much less important, for bases its quite common to go e.g. core18->core20 but having core20 already installed because its used by some app snaps
<mborzecki> mvo: ok, so maybe there's a case missing after all, iirc snapstate.Install() errors out if the snap is already installed, so a remodel back to the old one when the old gadget snap is still around could fail?
<mvo> mborzecki: correct
<mvo> mborzecki: I think this is not terrible, a followup is ifne
<mborzecki> mvo: rigth, so land 7665, 7715 and then a followup using some code from 7715
<mvo> mborzecki: its really a corner case
<mvo> mborzecki: correct
<mborzecki> mvo: sgtm
<mvo> mborzecki: cool
<zyga> re
<Chipaca> zyga: feeling better today?
<zyga> Chipaca: I'll feel good if we can make the feature work
<zyga> Chipaca: last evening was grim
<zyga> but some light at the end of the tunnel
<Chipaca> zyga: imagine if you'd found out after implementing the whole thing
<mborzecki> Chipaca: and merging to master ;)
<Chipaca> mborzecki: and then steal it again!
<Chipaca> wait no that's https://www.youtube.com/watch?v=ALZZx1xmAzg
<mborzecki> hahah
<Chipaca> man lubuntu is *fast*
<mup> PR snapd#7547 closed: many: use a dedicated named cgroup hierarchy for tracking <â Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7547>
<mborzecki> mvo:  can you cherry-pick to 5995e03cf8b2e34ef4327a6419922fe49d41332f ?
<mborzecki> mvo: to 2.42 ofc :)
<mborzecki> mvo: looks like we're missing the release artifacts for 2.42.1
<mvo> mborzecki: oh, right, let me fix that
<mvo> mborzecki: cherry-picked :)
<mborzecki> mvo: thanks!
<mvo> mborzecki: published, sorry for that
<mborzecki> mvo: np, i can update the arch and fedora packges now
<mvo> ta
<mborzecki> need to run an errand, back online in 40 or so
 * Chipaca not feeling too good today
<zyga> take care Chipaca
<Chipaca> i am :) thanks
 * dot-tobias waves
<Chipaca> eh, might as well do this mandatory training now
<zyga> mvo: I discussed ideas with mborzecki
<mvo> zyga: nice
<zyga> mvo: the idea is to use a sub-directory of whatever cgroup is assigned by systemd
<mup> PR snapd#7659 closed: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7659>
<mvo> zyga: oh, that will work?
<zyga> mvo: not for notification, but we can scan /proc and find out what we need in a loop
<Chipaca> zyga: wrt xdg thing, ask also for non-issue
<Chipaca> zyga: otherwise nobody trying it, and everybody trying it and finding no issues, looks the same :)
<zyga> Chipaca: pardon, I don't follow
<zyga> Chipaca: ah
<zyga> I see
<zyga> +1
<zyga> good idea
<zyga> my mind is blank but I'll do my best to implement it
<zyga> it's more likely to succeed than the idea from last evening
<mborzecki> re
<mborzecki> pstolowski: thanks for the review, i'll be addressing your comments shortly
<pstolowski> mborzecki: np, ping me for re-review
<mborzecki> mvo: can you also cherry pick 08397513608150c6fd796ceb974557c0e19d6085 to 2.42?
<mvo> mborzecki: yes, done
<mvo> mborzecki: thank you!
<mvo> pstolowski: thanks for the review of 7665!
<ogra> zyga, hrm ... we should really have some kind of interface to allow this ... coyping files to home first is very annoying
<pstolowski> yw
<mborzecki> mvo: cool, thanks!
<zyga> ogra: it'd be somewhat tricky to make since there's a bunch of special code to make sure you cannot read /home/*/snap/ using home
<ogra> i mean, it is the first time i hit this and i can probably mke the arduino ide store to home but it kind of hinders productivity since snaps typically point to ~/snap/snapname/current for their default paths ... and i can imagine a lot of use cases where one snap uses data created by another
<ogra> (i.e. creating graphics with the gimp snap that i want to use in a libreoffice presentation with the libreoffice snap ... forcing people to copy around the world for that wont really make us freinds among users :) )
<dot-tobias> zyga, mvo, jdstrand: Re: https://github.com/snapcore/snapd/pull/7655 â Thanks for the 2.42.1 candidate, I tested my snap against the new version. Does the change also cover the post-refresh hook? When I run the code that requires the Introspectable interface from a plugged app, it works fine now. But when the same code is run during post-refresh, I still get the same AppArmor denial. network-manager is plugged in top-level > hooks >
<dot-tobias>  post-refresh > plugs, and I also added a top-level âplugsâ dict with `network-manager: {}` to no avail. Holding it wrong?
<mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
<zyga> dot-tobias: can you check the generated apparmor profile in /var/lib/snapd/apparmor/profiles/snap.$SNAP_NAME.hooks.post-refresh
<zyga> and see if it has the introspection chunk
<mvo> dot-tobias: I don't recall cherry-picking anything for post-refresh, its probably in edge only. if you tell me a git rev I can cherry pick in case we do a 2.42.2
<zyga> mvo: it wasn't for post refresh, it was for network-manager introspection on dbus
<mvo> dot-tobias: otherwise in the next stable release in ~4 weeks
<zyga> mvo: I could find the patch number if you want
<mvo> zyga: aha, sry, in any case, if anything needs cherry picking please let me know but only if its really important
<zyga> mvo: 5bc7682f2ef572f074dd0764015358cbe139d35d
<zyga> dot-tobias: note that it was made to only affect core
<mvo> aha, right
<mvo> thanks
<mvo> well, if its really important I can cherry pick, otherwise its in 2.43 (its not clear we do a 2.42.2 at this point)
<zyga> I didn't check if that's in a point release
<mvo> pstolowski: while in the remodel review swing, maybe you can have a look at 7715?
<zyga> I think it might but please check what's in the apparmor profile I mentioned first
<mvo> pstolowski: it should be very similar in style to the gadget one you just reviewed :)
<pstolowski> mvo: sure, will do
<dot-tobias> zyga: https://paste.ubuntu.com/p/yJbVPHnXsX/ â apparmor profile seems to contain the necessary chunk for post-refresh. Note this is after I refreshed the snap from a local unsquashed FS via `snap try`, which had the part of its post-refresh hook disabled where Introspectable would be called.
<zyga> dot-tobias: please don't use snap try for refresh-related hooks
<zyga> they don't operate correctly
<zyga> because snapd is confused by "before" and "after" being the same revision
<dot-tobias> zyga: Testing on a Core device. Oh ok, would it suffice if I reset the snap to an older revision and then `snap try` the newer revision with the patched post-refresh hook? The older revision doesn't plug network-manager for the hook, so I don't know how to test otherwise.
<zyga> dot-tobias: I think using snap try in testing the refresh hook is not useful
<zyga> just snap pack the new version
<dot-tobias> zyga: And then refresh from this local .snap file?
<zyga> correct
<dot-tobias> Will test, brb
<dot-tobias> zyga: Nope, still the same AppArmor denial. I packed the modified version (changed meta/snap.yaml to include a top-level plug `network-manager: {}` and incremented version number) + installed via snap install. Relevant log entry: https://paste.ubuntu.com/p/HjC6pjcb8K/
<zyga> dot-tobias: can you look at journalctl
<zyga> dot-tobias: perhaps we run the hook before the profile of network-manager is updated?
<zyga> dot-tobias: if so that would be a separate bug, which would be unfortunate
<dot-tobias> zyga: What should I look for in journalctl specifically? When I search for the AppArmor denial, the lines above indicate that the network-manager profile *is* updated before: `Nov 05 12:37:29 localhost kernel: audit: type=1400 audit(1572953849.274:306): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.network-manager.networkmanager" pid=14712 comm="apparmor_parser"`
<dot-tobias> (same for the other network-manager 3 profiles)
<dot-tobias> zyga: So â¦ I checked the AppArmor profile for NetworkManager itself and it seems that even if I plug network-manager for my post-refresh hook, the profile doesn't seem to be updated. I'll open a forum thread about this.
<zyga> dot-tobias: re
<zyga> sorry, watching some internal HR stuff
<zyga> dot-tobias: so in journal - look at the *order* for the events where apparmor_parser is invoked
<zyga> for the hook
<zyga> and for the network-manager service
<zyga> ok
<zyga> looking
<zyga> it's interesting because it says "same as current"
<zyga> perhaps the bug is not fixed afer all
<zyga> because network manager ought to get the permission to receive it
<dot-tobias> no worries, appreciate all the help from your side ð
<dot-tobias> zyga: ^ and: I'm double-checking if I made a mistake, but what trips me up is that the Introspectable access works fine once my snap is refreshed (which only works when I disable the NM-related parts of my post-refresh hook, ofc).
<zyga> dot-tobias: review the patch I sent for fixing this and check if there is anything that looks wrong
<zyga> it should be symmetric
<dot-tobias> zyga: You mean the two snippets in https://github.com/snapcore/snapd/pull/7655/files#diff-323f555eb7f1a661aaa0bea83295e4f1R297 right? I'm writing up my test procedure and results, brb
<mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
<zyga> yes
<pstolowski> Chipaca: hey, what's the status of https://bugs.launchpad.net/snapd/+bug/1660970 ?
<mup> Bug #1660970: snap info could autocomplete against installed snaps <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1660970>
<Chipaca> pstolowski: still in progress: snap run doesn't complete yet
<Chipaca> pstolowski: I've got it tagged to reply in more detail when i can
<Chipaca> pstolowski: (from zyga asking me(
<Chipaca> ))
<pstolowski> Chipaca: great, thanks
<pstolowski> Chipaca: there is one other bug where zyga asked you for a status - https://bugs.launchpad.net/snapd/+bug/1750527
<mup> Bug #1750527: dashboard does not validate text fields <review-tools:Fix Released by jdstrand> <Snapcraft:New> <snapd:In Progress by chipaca> <Snap Store:Fix Released by matiasb> <https://launchpad.net/bugs/1750527>
<Chipaca> pstolowski: yep, also tagged
<pstolowski> ð
<dot-tobias> zyga: https://paste.ubuntu.com/p/pq29pv6zK8/ â It seems to me that your hunch is right: the NetworkManager slot rule is not updated for the post-refresh hook
<zyga> dot-tobias: that's interesting, if you disable and enable n-m (via snap disable/enable)
<zyga> if so that's a serious bug
<Chipaca> pstolowski: also the ellipsis in utf8 one
<Chipaca> and the snapd on 1804 proxy settings one
<zyga> mborzecki: question on the idea
<zyga> mborzecki: can we use the unified hierarchy in v1
<dot-tobias> zyga: snap disable n-m / enable n-m shows no change to the Introspectable chunks â¦ (don't know if *that* is the serious bug or if it would update ð )
<zyga> dot-tobias: that's not bad then, it's a regular bug then
<zyga> dot-tobias: we should check why there's no snippet there though
<zyga> one second please
<dot-tobias> sure
<zyga> mborzecki: the logic I have so far looks for non-v2 cgroup hierarchy that has name=systemd
<zyga> mborzecki: but also supports the v2 nameless, controllerless one
<zyga> but this other choice, id=0 one is always present as /sys/fs/cgroup/unified in v1 world
<zyga> and we can put processes there
<zyga> so... perhaps that's consistency?
<zyga> (after all?)
<mborzecki> zyga: id=0 (i.e. 0::/some/path) is actually v2 hierarchy
<zyga> I know
<mborzecki> zyga: so yeah, we can do it ;)
<zyga> that's why I menitoned id
<zyga> yeah
<zyga> I will go for it
<zyga> it's consistent and easier
<zyga> and actually
<mborzecki> zyga: double check on 14.04 if we still care
<zyga> I don't know how to make use of the ID otherwise
<zyga> the only other piece that references it is /proc/cgroups
<mborzecki> zyga: 0 is reserved for v2 anywya
<zyga> but from there it's hard to match to /proc/self/mountinfo
<zyga> unless I need to match the ID to controller
<zyga> and then consider anything with that controller viable
<zyga> but I don't see any supporting evidence in the documentation
<zyga> I will check 14.04 before proceeding
<mborzecki> zyga: w8, why matching with data from /proc/self/mountinfo?
<zyga> mborzecki: because you don't know where the cgroup is mounted
<zyga> is might be /sys/fs/cgroup or /sys/fs/cgroup/unified
<zyga> I know we can check for v1-v2 mode
<zyga> but it'd be nicer if this was not so "based on assumption"
<zyga> hmm, my nas is down (didn't power up after last power outage)
<zyga> so my 14.04 image os off, I'll just spawn spread
<mborzecki> zyga: duh, right
<mborzecki> zyga: hm there's only one possible instance of v2 so just looking for mount of type cgroup2 will do
<zyga> yes
<zyga> that's why I want to do it
<zyga> it's non-ambiguous
<zyga> unlike v1
<zyga> it also has one more property
<zyga> we _could_ actually use the events file
<mborzecki> haha
<zyga> though I didn't think about how deeper yet
<zyga> but we could
<zyga> anyway
<mborzecki> zyga: double check on 14.04 ;)
<zyga> back to checking
<zyga> I wish spread had -workers 1 or something
<zyga> oh well
<mborzecki> zyga: cachio's spread does
<zyga> yeah but you know
<zyga> ...
<zyga> I only have one spread
<mborzecki> spread-ng ;)
<cachio> zyga, https://cachio.s3.amazonaws.com/spread/spread2
<zyga> cachio: thanks!
<zyga> cachio: any outlook for merging -workers 1 into spread?
<cachio> zyga, you can use -workers 1 -order
<cachio> to follow the specific order also
<zyga> dot-tobias: let me know if you find out more please
<zyga> cachio: right
<cachio> zyga, there is a PR for this https://github.com/snapcore/spread/pull/79
<mup> PR spread#79: New -workers option used to define the number of workers by system <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/79>
<cachio> but not reviews yet
<zyga> cachio: try pinging gustavo maybe
<zyga> he's really receptive when pinged IMO
<zyga> mborzecki: we're good,
<zyga> mborzecki: 14.04 has it and it's full of stuff already (not barren)
<dot-tobias> zyga: Will do, is there something specific I should test? Not quite sure where to start here. In any case, I'll put the tasks that post-refresh should do for my snap in a service startup; shouldn't be too much overhead to run them on each startup instead of once per refresh.
<zyga> dot-tobias: I think the mystery is why n-m doesn't have the new snippet
<zyga> dot-tobias: look at the patch and at the file, I don't know why it might not be present
<zyga> maybe our assumptions are wrong somehow?
<dot-tobias> zyga: Slightly of my depth on this (should become my motto here â¦) ð As a starter, how is ###PLUG_SECURITY_TAGS### generated in https://github.com/snapcore/snapd/pull/7655/files#diff-323f555eb7f1a661aaa0bea83295e4f1R312 ?
<mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
<zyga> dot-tobias: it's generated in the line above, hidden in the diff: https://github.com/snapcore/snapd/pull/7655/files#diff-323f555eb7f1a661aaa0bea83295e4f1L480
<zyga> that returns a string that describes the labels of all plugs connected to the slot
<dot-tobias> I'm assuming the profile for n-m is only updated if there are new rules, and if my snap's post-refresh hook is somehow not recognized by the plugAppLabelExpr helper, it won't be included there?
<dot-tobias> https://github.com/snapcore/snapd/blob/aebfc2b83d7ac3ec49ff6811ddf8bc8c4c93b92d/interfaces/builtin/utils.go#L73 â would plug.Apps() also return hooks?
<zyga> dot-tobias: the profile is generated in memory and reloaded if it changes; we even reload them if they don't change for a specific reason, this is why you saw the message that profile was the same as before
<zyga> dot-tobias: yes, that's correct
<zyga> plug.Apps would not return hooks
<zyga> perhaps that is the bug?!
<zyga> that's cool
<zyga> that's the bug IMO
<dot-tobias> zyga: A shy âyes â¦ maybe??â from me ð
<zyga> pstolowski: ^
<zyga> dot-tobias: can you add that the the existing bug or open a new one
<zyga> I think it's unfortunate for you but this is should be easy to address
<zyga> but on the up side, now that it is know it can be fixed, otherwise the next release would be equally buggy
<zyga> dot-tobias: thank you! you nailed it
<dot-tobias> Hey, happy to help out once instead of just receiving help ð I'll open a new bug since this probably affects all hooks, brb
<zyga> yes, I think a new bug is more appropriate
<pstolowski> zyga: why should Apps return hooks too?
<zyga> they should not
<zyga> but the label ought to include hooks too
<zyga> using slotAppLabelExpr is just wrong
<zyga> it ought to say slotAppOrHookLabel(slot)
<zyga> because why would we refuse to allow hooks to have those permissions?
<dot-tobias> zyga: That might also explain why my connect-plug-network-manager hook kept failing with similar AppArmor denials for n-m:service, even though that's the whole point of connect-plug-* hooks ð
<zyga> oops /o\
<zyga> thank you for catching that!
<zyga> and I'm sorry for not writing a spread test
<zyga> it would show this
<zyga> mborzecki: offtopic, I learned to love #pragma once
<zyga> every production toolchain supports it
<zyga> and it's far less silly than the ifndef approach
<zyga> no need to invent names
<pstolowski> zyga: i see
 * pstolowski school run, bbiab
<dot-tobias> zyga: No worries, you people have so much on your plate with the snap ecosystem â¦ there's always some workflow to improve, and resources are constrained. Happy to help ð
<zyga> dot-tobias: I'll gladly help you fix this if you want to
<mborzecki> pstolowski: pushed fixes to https://github.com/snapcore/snapd/pull/7665
<mup> PR #7665:  devicestate: add support for gadget->gadget remodel  <Priority ð> <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
<dot-tobias> zyga: Very much wanted, because I'd probably overlook some helper or introduce even worse bugs ð
<zyga> dot-tobias: expand AppLabelExpr to take a map of hooks as well
<zyga> the rest is a consequence of that
<zyga> adjust names of the functions to convey the fact that it is not just apps now
<zyga> I think this bug is silly
<zyga> it's an old design that we lifted
<zyga> but buggily so
<zyga> we designed it so that hooks could not have interfaces initially, not all of them
<zyga> I think we never noticed when this restriction went away
<zyga> that the label expression is only for apps
<zyga> there's some tricky code in that function
<zyga> as it tries to produce nicer output than brute force
<zyga> my suggestion would be to cahng it so that it considers not hooks or apps
<zyga> but just a slice of names
<zyga> whatever they are
<zyga> and have the names be a concatenation of app labels and hook labels
<dot-tobias> âappsâ in that context are apps + services in snapcraft lingo?
<zyga> dot-tobias: there are no tests for appLabelExpr so I would suggest to start with that
<mborzecki> ok, moving back home
<zyga> just create a test that checks the label for the current code
<zyga> dot-tobias: yes, apps are all apps, equally
<zyga> services are just certain apps
<zyga> dot-tobias: there is code that tests this indirectly
<dot-tobias> zyga: Ok, I'll install go, set up snapd locally and then get back to you in a week or two ð
<zyga> but a direct test that generates snap.pkg.*, snap.pkg.{app1,app2} and snap.pkg.app3 as output would be good
<zyga> as those are all the variants the current logic handles
<zyga> dot-tobias: let us know if you need help but I think this is fairly nicely scoped
<zyga> dot-tobias: you can build a new function, move code over from the old function, remove the old function in stages
<dot-tobias> zyga: Will do. I have some spare time atm, so this should be a nice way to a) contribute code and b) learn something new
<zyga> dot-tobias: this definitely affects lots of interfaces, just git grep AppLabelExpr
<dot-tobias> zyga: Would you recommend setting things up directly on a Ubuntu host, or can I use my main macOS env to develop?
<zyga> dot-tobias: linux is strongly recommended, you will have issues as our code has many parts that only build on linux
<zyga> dot-tobias: personally I use vmware fusion
<zyga> dot-tobias: as for the host, any linux will do really
<zyga> dot-tobias: for this sort of change at least
<dot-tobias> zyga: thought so, check. Ok, I'll start with completing the bug report ð
<zyga> uh
<zyga> found an issue
<zyga> but I'll wait for maciek
<dot-tobias> zyga: ^ does this relate to the issue we discussed, or sth else?
<zyga> no no
<zyga> it's for the cgroup thing
<dot-tobias> ð
<zyga> mvo: I'll run the new plan by stgraber and xnox today
<zyga> maybe to avoid and learn from the last experience?
 * zyga needs a break
<zyga> see you all at the standup
<mvo> zyga: cool, thanks for chasing this
<xnox> mvo:  so.... model assertions
<xnox> mvo:  $ snap known --remote model series=20 model="ubuntu-core-20-amd64" brand-id=canonical
<mvo> xnox: in a meeting
<xnox> tells me that none are found =)
<mvo> xnox: right, will reply in a wee bit
<xnox> who should i talk to, about making a core20 pc-kernel model? =)
<xnox> ack
<mvo> xnox: you can try https://paste.ubuntu.com/p/DpZ2c3y4h9/ ?
<mvo> xnox: its "my" model, not the canocnial one yet
<mvo> xnox: but I get error: cannot use gadget snap because its base "" is different from model base "core20" with that so I need to look
<mvo> xnox: either pc is not quite right (the snap) or something else, haven't had time yet to dig (meeting)
<xnox> mvo:  why is it series=16?
<mvo> xnox: loooooong story
<xnox> mvo:  would be nice to be series 20 and make that the default track
<xnox> mvo:  why is there no snapd snap listed?
<mvo> xnox: the "series" is about the "format" of the entire architecture of snaps
<xnox> mvo:  how does one specify to use "edge"?
<mvo> xnox: its implicit, I guess we could/should make it explicit though
<mvo> xnox: ubuntu-image --channel=edge
<mvo> xnox: that should work
<xnox> ok
<mvo> xnox: I got further, my image creation is now exploding that "dangerous" is not yet supported
<xnox> mvo:  how does one create model assertions?
 * xnox wants to play with this stuff
<xnox> mvo:  also do we have git models committed anywhere? or is it simply in the store?
<mvo> xnox: use https://paste.ubuntu.com/p/VfkNwGQCHK/ as input, modify brand-id and then run snap sign
<xnox> mvo:  ack
<mvo> xnox: there is a doc that describes this, still in a meeting so can give you only 15% of my attention
 * xnox ponders to commit them into the pc gadget git repo, on respective branches
<xnox> i am confused what are the magic values of like authority-id brand-id id
<mvo> xnox: its in your account page
<xnox> ack
<mvo> xnox: meeting over, now you can have more attention :)
<mvo> xnox: https://dashboard.snapcraft.io/dev/account/
<mvo> xnox: there is the accound-id there
<mvo> xnox: use that for brandh-id, authority-id
<xnox> mvo:  ok, and ids on snaps? is that the unique ids of the snaps, in addition to just their name?
<Chipaca> xnox: snap info --verbose will show you the snap id
<mvo> xnox: correct, snap info --verbose <name> will give you those
<xnox> mvo:  can timestamp be in the future? we should set it to 2020-04-23T20:04:00:00.0Z
<mvo> xnox: not sure that this will work
<xnox> mvo:  because you think hardware clocks have real time?! that's just silly.
<xnox> mvo:  grade dangerous is invalid, no? it's called "devel"
<mvo> xnox: that sounds slightly outdated, let me try to find where this was written down but I can point you to the code. its "unset", "secured", "signed" and "dangerous" there
<xnox> mvo:  i find it extremly odd to use key "grade" in both model & snapcraft, with widely different meaning and values.
<mvo> xnox: https://github.com/snapcore/snapd/blob/master/asserts/model.go#L320
<mvo> xnox: right, unfortunately samuele is on vac, that's a topic for him
<xnox> mvo:  then it should be called like model-grade, not just grade =/
<xnox> mvo:  imho we should be able to build "signed" one today, no need for "dangerous"
<mvo> xnox: yeah, if you feel strongly, please mail samuele to discuss this, I don't think its set in stone but it will get harder to change the closer we get :)
<xnox> mvo:  also, this implies we will have two models, and two images for core20 => with and without tpm-fde? but current working assumption is that a single image can be both.
<xnox> i.e. "signed" should be allowed to be "secured", wheres as "secured" should not be. Ie. "signed" should be a superset of "secured", and ditto "signed" and "dangerous" should be supersets of previous one.
<xnox> i.e. it's totally fine to have "dangerous" one effectively running as "secured" if all pieces work.
<mvo> xnox: dangerous can still have fde, it just allows to sideload stuff, or am I misunderstanding?
<mvo> xnox: also, my next meeting starts now ./ so back to 15% of my attention for you
<mvo> xnox: sorry!
<roadmr> ETOOMANYMEETINGS? ð¤
<xnox> snap sign cannot do GPG it seems.... it cannot find a key named "default" wtf?!
 * xnox uses a smartcard
<mborzeck1> cmatsuoka: some comments under #7687
<mup> PR #7687: snap-bootstrap: check gadget versus disk partitions <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7687>
<kjackal> hey snappy people, in a classic snap, when I use sudo, should i use the "sudo" binary of core?
<xnox> kjackal:  you should simply use sudo, with PATH discovery. ie. just "sudo" not any absolute path.
<kjackal> I see MicroK8s in Centos 8.0 and fedora 29 failing when using sudo and I am wondering if I should package sudo or use the host's, or use the core's
<xnox> note sudo is not universal, and is not guaranteed to be installed, or usable.
<xnox> one might be root already, then no sudo should be needed, etc.
<kjackal> xnox: this is the error I am getting https://forum.snapcraft.io/t/pam-account-management-error/14026
<xnox> kjackal:  some of it, looks like a broken core snap
<kjackal> in my case sudo is available but the libraries are not in the right places (?)
<xnox> or rather mixed up LD configuration / overrides / preloads, ie. system pam is used with libraries from a core snap, which will never work =)
<xnox> kjackal:  i wonder if environment that snap setup for you, is interfering with using system PAM session correctly
<zyga> Back home now
<kjackal> xnox: I am setting some env variables here: https://github.com/ubuntu/microk8s/blob/master/microk8s-resources/wrappers/microk8s-enable.wrapper#L4 could these be a problem?
 * cachio afk
 * cachio lunch
<xnox> kjackal:  yes, all of them.
<xnox> kjackal:  these are good, for using binaries from inside the snap, but bad if one tries to dlopen system installed ones (like pam does for pam modules which dlopen things)
<kjackal> xnox: but i am doing for example "sudo <something_in_my_snap>" so... ?
<xnox> kjackal:  which is operating sudo itself with those environment variables in effect. which is bombing out.
<xnox> because sudo, tries to open a pam session, as per system wide config, loads pam modules from the system-wide, yet with LD_ path pointing inside the snap which is incompatible with with system-wide libraries
<xnox> kjackal:  store and export original path, ie. with export STOCK_PATH=$PATH ditto for STOCK LD_LIBRARY_PATH
<xnox> kjackal:  and i expect something like this will work:
<xnox> PATH=$STOCK_PATH LD_LIBRARY_PATH=$STOCK_LD_LIBRARY_PATH sudo PATH=$PATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH sed -i
<xnox> kjackal:  ie. use system wide sudo, with system-wide PATH & LD_LIBRARY_PATH, but use snap paths for sed.
<xnox> although imho one can rely on system sed too, as it's fundamental too.
<xnox> although imho one can rely on system sed too, as it's fundamental tool.
<kjackal> I see, will try that
<kjackal> thank you xnox
<xnox> kjackal:  your problem is that one cannot really create and use pam session from inside a snap, and expect it to work with the system-wide pam config. Meaning one has to use system-wide sudo
<xnox> because all of those things use absolute paths to dlopen() libraries which all must match.
<xnox> it "works" by magic on like Ubuntu due to e.g. snap build on xenial, and libraries staying compatible for basic things like that
<xnox> (i.e. when host == snap abi's by accident)
<xnox> kjackal:  also note that i have no idea what i'm talking about and i'm jsut a random person on irc who has zero idea about how snaps work =)
<kjackal> :)
<mborzecki> snapd in AUR has been updated to 2.42.1
 * mvo hugs mborzecki 
<pstolowski> spread tests in #7715 and #7665 are very alike, i'm not sure who was first ;) fwtw i'm adding same comments ;)
<mup> PR #7715: overlord: add base->base remodel undo tests and fixes <Priority ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>
<mup> PR #7665:  devicestate: add support for gadget->gadget remodel  <Priority ð> <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
<xnox> mvo:  error: cannot override channels, add local snaps or extra snaps with a model of grade higher than dangerous
<xnox> mvo:  hm..... prepare-image fails..... but i'm confused about these constraints. How do I build image of a model, using edge channels? model doesn't allow to specify channel does it?
<mvo> xnox: yeah, I hit this too, I'm looking into it
<mvo> xnox: basicly we need to land one more PR (7712
<mvo> xnox: then we can have a "grade: dangerous" model that allows overriding
<mvo> xnox: I was also looking into: https://paste.ubuntu.com/p/5bhBPMvVJj/
<mvo> xnox: but that fails with a strange error, that it can't find core20 which I think is a lie
<pstolowski> mvo: reviewed #7715
<mup> PR #7715: overlord: add base->base remodel undo tests and fixes <Priority ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>
<xnox> mvo:  hm.... i'm not sure if that's what i am hitting..... because all the snaps i'm using are acked and in store. I'm not using any unsigned, or unasserted snaps
<mvo> xnox: you did specify --channel=edge, maybe?
<mvo> pstolowski: cool, will look
 * mvo needs to taxi kids around for ~30min
<mvo> bbiab
<xnox> for me it's fetching the wrong gadget snap!
<zyga> re again
 * zyga had dinner and an unexpected encounter
<zyga> my neighbor was venting old stuff and asked me if ... I want any of his 90s games collection
<zyga> so now I have a CD-ROM with dungeon master 2
<zyga> and a few similar games
<zyga> anyway
<zyga> back to work
<zyga> xnox: hey
<zyga> xnox: we have an idea and before pursuing further wanted to ask you for advice
<zyga> xnox: it is related to systemd and cgroups
<zyga> xnox: the idea is: when snaps are invoked they put themselves into a new leaf under wherever systemd had placed them
<zyga> xnox: in the unified v2 hierarchy
<zyga> xnox: so for example, on /user.slice/user-1000.slice/user@100.service/snap.pkg.app
<zyga> xnox: or something equally appropriate for system services
<zyga> xnox: we'd be stealing the process from systemd
<zyga> xnox: but placing it deeper in the same hierarchy
<zyga> xnox: casual testing shows that systemd is not confused and still manages services correctly
<zyga> xnox: we intend to use the unified hierarchy in v2 mode, obviously, because we have no other choice
<zyga> xnox: but also in the v1 mode
<zyga> xnox: because it is seemingly working the same way for what we intend (associating PIDs with snaps)
<xnox> so i have this https://bugs.launchpad.net/snapd/+bug/1851401
<mup> Bug #1851401: snap prepare-image downloads wrong snaps <snapd:New> <https://launchpad.net/bugs/1851401>
<xnox> zyga:  "when snaps are invoked they put themselves into a new leaf under wherever systemd had placed them"  using children, and further scoping is always safe. Moving "up" is usually either not-allowed, or is a priviledged operation. Systemd should not get confused, as long as you don't change notification agents on it. And yes it should be fine under v1/v2/hybrid. BTW why do you want to do this?
<xnox> i.e. what are you trying to solve?
<zyga> xnox: that's good news
<zyga> xnox: we want this to implement a feature where snapd pauses refreshes while an app is open
<xnox> that's insecure and abusable.
<zyga> xnox: and can, having tried to refresh but deciding not to
<xnox> as unpriviledged user can create those cgroups and put arbitrary processes into them.
<zyga> xnox: then decide to refresh it reasonably fast after it was closed
<zyga> xnox: that's ok, we have safeguards for that
<zyga> xnox: that is, firefox running forever in a snap will eventually referesh anyway
<zyga> *refresh
<xnox> i.e. you could make binaries be "systemd-run actual binary" cause then pid1 will put the process into a system cgroup, which is authoritative.
<zyga> xnox: we considered that but we don't have systemd-run across all versions we support
<zyga> xnox: but it's also a problem there
<zyga> xnox: because we want to have this available uniformly across all apps
<zyga> xnox: including services
<zyga> xnox: and using systemd-run from inside what is effectively a service file with Exec line
<xnox> zyga:  you do have sytemd-run everywhere.... given that it's in core16
<zyga> xnox: we are at the mercy of what systemd allows us to do here sadly, as snaps need to integrate with existing system services and be managed by systemd directly
<xnox> zyga:  you don't need systemd-run for services, as pid1 already placed them into an authoritative cgroup
<zyga> xnox: I think we don't have that on 14.04
<zyga> xnox: but even then the other problem is more severe
<zyga> xnox: "apache", "firefox" and "grep" type workloads need to be supported in this mode
<xnox> zyga:  systemd-run is inside core snap, and on 14.04 it runs against subordinate systemd which has it.....
<zyga> xnox: I see but core is not mandatory and it would also complicate startup, what if you install a snap with bare base on 14.04?
<xnox> zyga:  if you only do this for "user" apps, that's fine. I.e. i don't want to hold up daemon refreshes, due to unpriviledged user controlled cgroups.
<zyga> xnox: we want this to work uniformly for all applications but there's some smarts for services
<xnox> i.e. somebody executing "snap --help" and freezing it, should not prevent snapd refresh for example
<zyga> xnox: snap --help won't prevent snapd from refreshing
<xnox> zyga:  it's insecure, thus you must have security team review / signoff on this logic.
<zyga> xnox: can you specify what is insecure specifically
<zyga> xnox: (we always get security review for features like that)
<xnox> zyga: arbittrary users can create the cgroups like /user.slice/user-1000.slice/user@100.service/snap.pkg.app which have never been executed via snap/snapd
<xnox> with zombie /bin/true process
<zyga> indeed, this is true
<zyga> xnox: at this point we ran out of ideas for things that work across the stack unfortunately
<xnox> you could use kernel keyrign to list snap invocation_ids which is read only, to then lock that up. Cause that's what e.g. systemd-run does
<zyga> xnox: users don't have to be nasty, they can just run the real app
<zyga> xnox: so it is not a new problem of the feature
<xnox> zyga:  also i challenge you on the 14.04 assertion, i believe systemd-run is available there.
<zyga> xnox: invocation IDs?
<xnox> systemd creates process keyring and puts a unique key there and makes it readonly and exports it as an evironment variable. Then processes can share that keyring (ie. group of services) and then they can all know that they are part of the same "reexec" for example. Kind of like a cohort key.
<xnox> but with kernel protection that nobody can modify or fake it
<zyga> xnox: interesting, which syscalls govern that? I'll read about it
<zyga> xnox: and do you know if this will work inside LXD
<zyga> xnox: as whatever we need to do needs to work in lxd across the stack
<xnox> it does work in lxd today, but i don't remeber when it was added.
<zyga> (we are in this situation after we realized mounting a v1 name=snapd cgroup doesn't work)
<xnox> zyga:  why do you care about 14.04?
<zyga> xnox: it's still supported, we cannot abandon it without some official kick
<zyga> xnox: but I would not hold onto 14.04
<zyga> xnox: it's just that systemd-run doesn't do what we want to AFAIK
<xnox> zyga:  it's passed end of basic support, and excludes support for snapd in ESM
<zyga> xnox: unless I misunderstand
<xnox> zyga:  it's dead to you
<xnox> and i.e. subordinate systemd is not supported there for sure.
<zyga> xnox: I need mvo to tell me that, I asked recently and I got a different answer
<xnox> mvo
<xnox> not in this channel
<zyga> it seems he is not connected now
<zyga> xnox: but even assuming we can run systemd-run
<zyga> xnox: can you outline how we could use that to identify all snap execution entry points?
<zyga> that is, all apps, hooks and services
<zyga> so that when scanning PIDs
<zyga> we can see where they came from
<xnox> zyga:  and 14.04 is very unconfined, as far as i understand. i.e. most interesting interfaces are not supported on 14.04 anyway.
<zyga> xnox: I think actually only fuse is not, everything else is not special cased on 14.04
<zyga> it's not supported for desktop apps but that is all
<xnox> vorlon:  what's status of supporting snapd on 14.04? i thought it's dead and not part of ESM.
<zyga> xnox: so would snap-run invoke systemd-run which would invoke snap-confine and then snap-exec?
<vorlon> xnox: I don't know why you had that impression; you should look to the Security Team for a specific support statement, but I'd be surprised if snapd wasn't in scope
<zyga> I suspect that the nature of ESM is that it's too soon to say something is not supported
<zyga> the policy in snapd team, for now, as far as I know, is that 14.04 is still a target
<xnox> zyga:  imho that call chain "makes sense" but potentially breaks a lot of desktop integration, unless one is careful to do --user / --system for the systemd-run bit.
<zyga> and we are not introducing features that don't support it
<zyga> xnox: can you walk me through the operations of systemd-run, what do we get by using it and how should we invoke it?
<xnox> zyga:  i'm very busy, and i've spend too much time talking to you already. So no, i don't. plese read man pages for systemd-run, they have a lot of details.
<zyga> xnox: I will, thank you for the advice and for the discussion, it's very useful
<zyga> xnox: I don't think we can use systemd-run
<zyga> xnox: based on the man page itself
<xnox> vorlon:  zyga: snapd is explicitely called out as an exclusion for 14.04 ESM that's where i got this impression from https://wiki.ubuntu.com/SecurityTeam/ESM/14.04#Exclusions
<zyga> xnox: but we should be able to use the cgroup sub-directort leaf
<xnox> zyga:  it starts an invocation, as a dynamic .service unit. meaning one can query it with systemctl list-units snapd-execs.* for example
<xnox> and it can like prevent user from having two copies of the thing running in parallel, etc.
<zyga> yes, but it doesn't give me a way to run a classic snap this way, e.g. a classic installation of python, to get interactive pty
<vorlon> xnox: well, if it's published as an exclusion, there's your answer :-)
<zyga> it needs to support all the kinds of interactions snap apps support: desktop apps, services and all the command line stuff, including classic snaps
<xnox> mostly useful to start "dynamic" things but monitored, i.e. executing user-written hooks, which can be arbitrary long, with journald logging, confiment, etc.
<xnox> it does break the scope & confiment, even basic things like "what is my stdin"
<zyga> yeah, so while we could use it for services, for services arguably systemd is already giving us all of that already
<zyga> I think it will also be a less invasive change
<zyga> I'm very curious about the keyring operation
<zyga> as that seems like a way out of the too-easy-to-spoof problem
<xnox> zyga:  start with keyctl manpage about kernel keyring, and invocation_id stuff inside systemd
<zyga> though it doesn't really solve the problem as you can just run the real thing (real snap app) and not close it for the same effect
<zyga> it seems like a potentially interesting replacement for the snap cookie concept though
<zyga> but I need to read on it more now
 * zyga hugs xnox 
<zyga> thank you :)
 * cachio afk
 * ijohnson hugs zyga after reading backlog
<zyga> ijohnson: what specifically? :
<zyga> :)
<ijohnson> the many changes to refresh awareness, sounds like quite a rollercoaster
<zyga> ijohnson: the only question is
<zyga> ijohnson: is it still going up or are we already going down? ;)
<zyga> but yeah, it's quite a feature
<ijohnson> haha :-)
 * ijohnson is not really around today, still in Arizona for meetings
 * ogra waits for the time where the snapd snap is bigger than his kernel snaps on core images
 * ijohnson quietly shoves edgex snap inside snapd to get ogra to stop waiting
<ogra> haha
<ogra> ijohnson, reading that ... we'll need to talk about edgex before EOM ... (got another exhibition and we want to shw edgex finally)
<ogra> the setup doc we have seems outdated
<ijohnson> sure that doc is probably out of date, but let's try to keep Tony and Don in the loop too
<ijohnson> ogra: when is your exhibition?
<ogra> last week of nov.
<ogra> (i think at least ... /me checks)
<ogra> yeah, 26 to 28 https://sps.mesago.com/nuernberg/en.html
<ijohnson> ogra: ack are you going to be in vancouver next week for the sprint?
<zyga> ogra: we will link everything into one binary so that it can stay at comfortable 20MBs forever
<zyga> mvo: heye
<zyga> mvo: you missed some nice discussion about systemd stuff with xnox
<zyga> mvo: I think I will wrap it for today
<zyga> mvo: the big takeaway is that xnox effectively confirmed that the idea from Maciek is workable
<zyga> mvo: he also raised a number of important points for us to discuss
<zyga> mvo: but I will try to propose the branch implementing this tomorrow
<xnox> mvo:  everything is broken and nothing works, but i made progress!
<mvo> hey zyga
<zyga> mvo: hey :)
<mvo> xnox: ha!
<mvo> zyga: cool
<mvo> xnox: I think we have a bug in the core20 getting
<mvo> xnox: what kind of progress did you made?
<mvo> xnox: the pending PR#7712 should make everything easier, I will review it tomorrow morning
<xnox> mvo:  see email from me. if that PR helps that's great, will try that if/when it's available to me in a track/grade/branch to me
<xnox> mvo:  some things i can work around with, by like passing locally downloaded snaps etc. but other things seem broken - i.e. ubuntu-image doesn't do anything for me.
<mvo> xnox: aha, nice
<mvo> xnox: got the mail now
<xnox> mvo:  and i question some design choices in the model assertion, which i guess i need to type up and send.
<zyga> I'm wrapping up
<ogra> ijohnson, no vancouver for me ...
<ijohnson> ogra: cool maybe we could setup a hangout early next week then
<ogra> yeah, that sounds fine
<Chipaca> ok, EOD for me
<Chipaca> ð
<mup> PR snapd#7720 opened: asserts: add "snapd" type to valid types in the model assertion <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7720>
<mup> PR snapcraft#2792 opened: pluginhandler: use well-formed build package/snap lists <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2792>
<mup> PR snapcraft#2793 opened: tests: enable SNAPCRAFT_BUILD_INFO for spread <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2793>
#snappy 2019-11-06
<mup> PR snapd#7665 closed:  devicestate: add support for gadget->gadget remodel  <Priority ð> <Remodel ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7665>
<mborzecki> morning
<mborzecki> mvo: thanks for merging 7665, do you need help with other remodel PRs?
<mvo> mborzecki: hey, good morning!
<mvo> mborzecki: maybe, let me see what pawel wrote
<mborzecki> mvo: ok
<mvo> mborzecki: 7720 needs a second review, should be super simple
<mborzecki> mvo: ok, on it
<zyga> Hello
<zyga> Starting soon
<mvo> zyga: good morning
<mvo> mborzecki: I updated 7715, there is one question about test improvements, I need to think about it but I think it's not a blocker, feel free to ponder over this, I will not attack this today (his question about testing the taskEdges)
<mborzecki> zyga: hey
<mborzecki> mvo: let me check that
<mborzecki> zyga: did you dream about keyctl? :)
<zyga> in the office now
<zyga> mborzecki: no, I decided to really rest today
<mborzecki> zyga: i went through https://www.kernel.org/doc/html/v4.13/security/keys/core.html and then ecryptfs key usage examples but feel none wiser really
<zyga> mborzecki: I'm sure there are keys here
<zyga> https://twitter.com/zygoon/status/1191776451995095041
<zyga> but not like you know it ;)
<zyga> mborzecki: I think given timing we need to investigate keys next week
<mborzecki> zyga: still, it feels like a replacement for a cookie, so half of the problem could be addressed
<zyga> this week I'd like to get the cgroup in place and adjust snapd
<zyga> maybe get the UI proposed
<mup> PR snapd#7687 closed: snap-bootstrap: check gadget versus disk partitions <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7687>
 * zyga break, some back pain, may work from floor today
<pstolowski> morning
<mvo> good morning pstolowski
<zyga> Breakfast
<zyga> Implemented the cgroup idea
<zyga> Running tests
<zyga> Snapd side changes next
<mup> PR snapd#7721 opened: gadget: add support for hybrid partitioning schemas <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7721>
<mborzecki> pstolowski:  hey
<mborzecki> trivial PR for gadget ^^
<pstolowski> mborzecki: sure
<mborzecki> pstolowski: thanks!
<zyga> I really want snap set system reexec=no
<mup> PR snapd#7720 closed: asserts: add "snapd" type to valid types in the model assertion <Needs Samuele review> <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7720>
<zyga> Some progress
<zyga> Freezer freezing snap confine is silly
<mborzecki> hahah
<mborzecki> zyga: you mean s-c froze itself? :)
<mborzecki> google:ubuntu-core-18-64:tests/main/remodel-gadget failed on master :/
<mvo> a second review for 7711 would be great, it has one already and is green. hopefully straightforward
<mvo> mborzecki: oh no! in what way?
<mborzecki> - Remove data for snap "pc" (36) (failed to remove snap "pc" base directory: remove /var/snap/pc: directory not empty)
<zyga> mborzecki: just being silly
<zyga> mborzecki: it works now
<mborzecki> hm probably some other test leaving stuff behind
<zyga> https://www.irccloud.com/pastebin/DUaJsF5k/
<zyga> mborzecki: no, I put it in the wrong spot
<zyga> mborzecki: lxd escapes us though
<zyga> mborzecki: I'll send the patch with the function in a moment
<zyga> mborzecki: need to clean up the commit tree
<zyga> mborzecki: lxd escaping all cgroups  https://www.irccloud.com/pastebin/76oMP7KO/
<zyga> mborzecki: the C diff https://paste.ubuntu.com/p/T9NmjppHrY/
<dot-tobias> zyga: FYI, filed https://bugs.launchpad.net/snapd/+bug/1851480 (forgot to hit âsubmitâ yesterday â¦). Will ping here if I get stuck in my fix attempt
<mup> Bug #1851480: Hooks are not included in slot/plug label expressions <snapd:New> <https://launchpad.net/bugs/1851480>
<zyga> mborzecki: have a look at https://github.com/snapcore/snapd/pull/7722
<mup> PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
<zyga> dot-tobias: hey
<mup> PR snapd#7722 opened: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
<zyga> dot-tobias: thanks!
<zyga> mborzecki: on top I have the move of cgroup handling so that it affects all snap kinds
<dot-tobias> zyga: Welcome, hope I got half the snapd lingo right ð
<zyga> mborzecki: and a one liner than enables this new logic
<zyga> mborzecki: my thinking is we can keep the pids thing for a while
<zyga> mborzecki: and nuke it later once I'm done with snapd-side change
<zyga> dot-tobias: yeah, the bug report looks great
<zyga> mborzecki: does this seem sensible?
<mborzecki> zyga: the diff doesn't look too bad
<mborzecki> zyga: it'd be nice to run the idea by jamie and mvo too before we spend too much time digging
<mborzecki> zyga: i mean jdstrand
<mborzecki> uhh, the way we restore the system in tests is broken
<zyga> mvo, jdstrand: ^
<mvo> zyga: whats the high level idea? I have the C diff loaded now
<zyga> mvo: the high-level idea is that we use a sub-directory of the current unified/v2 cgroup as a tag
<zyga> mvo: and move the process there to identify it as a process belonging to a snap
<zyga> mvo: I discussed this with xnox yesterday for in the context of being systemd-safe
<zyga> mvo: it's safe to move to a deeper hierarchy
<zyga> mvo: (moving up is not)
<zyga> mvo: it uses v2 in all systems, giving us notification ability
<zyga> mvo: the new idea is from maciek really, that cgroups can act as process tags
<zyga> mvo: the idea to use v2 is because it is very much like name=snapd in v1 world (no controllers)
<zyga> mvo: and in v2 world it doesn't fall apart as we don't have to steal a process entirely
<zyga> mvo: and we can move it deper wherever systemd had originally placed it
<zyga> mvo: this is the key improvement: it works in v2 in a way that doesn't disable systemd's operation
<mvo> zyga: aha, ok
<zyga> mvo: it works in lxd as well, I confirmed this with stgraber two days ago
<mvo> zyga: that sounds promising!
<zyga> mvo: notification is implemented differently
<zyga> mvo: and enumeration is implemented differently
<zyga> mvo: and both are coming as follow-ups to snapd
<zyga> mvo: first enumeration, so that existing code can be moved over (along with all the spread tests for this)
<zyga> mvo: notification should let us salvage the UI work that is waiting now
<zyga> mvo: so maybe... just maybe... it will really work by Friday
<zyga> mvo: no rush to merge it, I'll carry on implementing it, but it would be good to review and discuss with jamie
<zyga> mvo: xnox raised a concern about security aspect of keeping an app open
<zyga> mvo: because it would prevent refreshes
<zyga> mvo: but I think this is really the feature design
<zyga> mvo: we are also looking with mborzecki at kernel keyring as a way to prevent spoofing
<zyga> mvo: where all our processes could hold something that cannot be forged
<zyga> mvo: but all it does is make the feature more security tight, it doesn't change that anyone can run a snap and prevent it from refreshing using "snap run..."
<zyga> mvo: so our existing snapd-side safeguards must suffice - that is the window of time after which we refresh anyway
<mvo> zyga: right, agreed
<zyga> mvo: there's enough priority items not to review it yet
<zyga> mvo: but we might try to review all of it by end of week
<zyga> mvo: just to be able to say "it's in master"
<geekgonecrazy> is there a way to bypass the restriction on refreshing to a revision?
<geekgonecrazy> some how during recent update we discovered several users skipped a revision
<geekgonecrazy> and during some troubleshooting we really need them to refresh or revert to that revisiom
<geekgonecrazy> revision*
<zyga> geekgonecrazy: can you explain how skipping a revision was a problem for your users?
<zyga> geekgonecrazy: based on what you said it seems like snap epochs are the solution we had designed and implemented for this problem
<zyga> geekgonecrazy: where you can force all users to migrate through a set of revisions
<zyga> geekgonecrazy: e.g. everyone will see and run the revision that can migrate your data format from v1 to v2
<zyga> geekgonecrazy: before allowing them to refresh to a revision that only has v2 support
<geekgonecrazy> where is this magic?  we thought it was this way out of the box
<zyga> geekgonecrazy: how did you think it operats?
<zyga> geekgonecrazy: (it doesn't but I'd like to understand)
<zyga> geekgonecrazy: let me refer to the docs on this feature, hold on
<zyga> geekgonecrazy: https://snapcraft.io/docs/snap-epochs
<geekgonecrazy> it was exactly that.  we had to upgrade db and introduced revision and gave it a week thinking all would be updated before introducing the next revision
<zyga> geekgonecrazy: you need to use epochs to really make that a guarantee
<zyga> geekgonecrazy: as to what to do in an existing situation, I don't know the details of what you did to answer
<zyga> geekgonecrazy: perhaps you can refresh everyone to an intermediate revision that still understands old formats
<zyga> geekgonecrazy: and publish the one that doesn't in a new epoch
<zyga> geekgonecrazy: please read about this feature first
<geekgonecrazy> so for us we were on mongo 3.4 then intermediate revision (the one some have missed) sets compatibility mode which has to be set before it csn go to 3.6.  then latest revision is 3.6
<Chipaca> geekgonecrazy: epochs is meant to be used for that kind of thing
<Chipaca> geekgonecrazy: https://snapcraft.io/docs/snap-epochs
<Chipaca> heh, i see zyga linked there already
<Chipaca> ok
 * zyga hugs Chipaca for implementing this magic
<geekgonecrazy> so in theory we could release another revision requiring both of those and if they already had all would be fine?
<Chipaca> geekgonecrazy: both of which?
<geekgonecrazy> or will we have to hack past and put this revision in another channel and have them refresh to that channel to run that revision and then back to the latest
<geekgonecrazy> Chipaca: both required revisions
<Chipaca> sorry, i don't follow
<geekgonecrazy> ok.  so problem is we have that revision some didnt hit.  now they cant refresh or revert there. so we need some way for them to get that revision
<geekgonecrazy> we cant release new revision.  because would take those that succeeded backwards in database breaking their installs
<geekgonecrazy> so trying to figure out if there is a way we could have them manually refresh to it
<geekgonecrazy> then back to stable
<Chipaca> geekgonecrazy: ah
<Chipaca> geekgonecrazy: can you detect a broken install programmatically?
<geekgonecrazy> Chipaca: yes.  But... fixing requires the older database version.
<Chipaca> geekgonecrazy: it does sound like your easiest way forward is to use a branch
<Chipaca> and then in future start using epochs so it doesn't happen again
<geekgonecrazy> really wish i would have known of epochs sooner :) would have been perfect
<Chipaca> geekgonecrazy: a branch is like a temporary track that goes away on ts own
<Chipaca> so you push the snap that would fix it to latest/stable/fix-for-the-thing, and tell affected users to refresh to it
<geekgonecrazy> oh dang.. didnt know you could do that either
<geekgonecrazy> we still are trying to figure
<geekgonecrazy> out the tracks :)
<Chipaca> :)
<Chipaca> branches are hard to explain until you need them
<Chipaca> rather like epochs actually
<geekgonecrazy> thanks Chipaca & zyga !
<geekgonecrazy> btw Chipaca on thr forum post regarding dig it seems its another dependency and dig just wont run.  so will be digging after this fire and getting to bottom of it.
<Chipaca> geekgonecrazy: good luck!
<mvo> sil2100: I pushed a tiny PR to ubuntu-image so that we can have /boot on the system-seed partitoin, this should bring us one step closer to a botting image, hopefully a trviail review (cc xnox)
<mvo> Chipaca: do you think we should have a short catchup today on recovery.grub? I think we are getting to a point where it will be useful :)
<Chipaca> mvo: I was just trying the image created with your steps from yesterday, and something seems off
<mvo> Chipaca: i.e. we can create an image now but right now (due to a bug) it has no /boot but even when it has that we still don't have a recovery grub that will work.
<Chipaca> mvo: but maybe i'm missing something :-)
<Chipaca> so, yeah
<mvo> Chipaca: tell me!
<Chipaca> mvo: /systems/2019yadda/ is empty, and instead things are in /snaps/ ?
<mvo> Chipaca: its fully empty?
<mvo> Chipaca: so "/snaps" has all the snaps that are shared between recoveries that is ok
<Chipaca> mvo: ah, i missed that
<mvo> Chipaca: but /systems/20191106/ should not be empty
<Chipaca> mvo: empty of snaps
<mvo> Chipaca: thats ok :) assertions and the model should be there
<Chipaca> yep that's there
<mvo> Chipaca: there will only be local unasserted snaps iirc
<mvo> Chipaca: cool
<mvo> Chipaca: once we have https://github.com/CanonicalLtd/ubuntu-image/pull/177 we should be able to get /boot too with grub.cfg and grubenv
<mup> PR CanonicalLtd/ubuntu-image#177: System seed boot dir <Created by mvo5> <https://github.com/CanonicalLtd/ubuntu-image/pull/177>
<mvo> Chipaca: but we also need to tweak boot.MakeBootable to copy the right grub :)
<mvo> Chipaca: but I'm excited, we are relatively close I think(?)
<Chipaca> mvo: where's the bit that creates writable?
<mvo> Chipaca: we create only "ubuntu-seed" nowdays, the recovery kernel then boots and the recovery initramfs will notice it runs in "install" mode and will run "snap-bootstrap" which will create all the missing partitions
<Chipaca> hmmm, maybe i did something wrong
<Chipaca> mvo: i thought i'd kicked that off, but it hung
<Chipaca> mvo: i'll try again, paying more attention :)
<mvo> Chipaca: no worries! you kicked what off?
<Chipaca> mvo: booted the kernel, with the initramfs
<Chipaca> and it got to the mounting step and hung
<mvo> Chipaca: oh, woah - how did that happen?
<Chipaca> mvo: the booting? or the hanging? :)
<mvo> Chipaca: I mean, how did you manage to get a booting kernel?
<Chipaca> mvo: i can walk you through that, it's not hard
<mvo> Chipaca: a pastebin with the commands would be great
<Chipaca> mvo: or i can write a workng grub.cfg for the image as it is right now
<mvo> Chipaca: but thats actually much better news than I anticipated
<Chipaca> mvo: but, basically, grub is awesome (as long as you're patient)
 * mvo hugs Chipaca really hard
<mvo> Chipaca: s/grub/chipaca/
<mvo> Chipaca: (and strike the patient part)
<Chipaca> nah leave that one on
<mvo> Chipaca: thats super exciting, can't wait to learn more
<Chipaca> mvo: "ubuntu-seed"'s label is actually 'Recovery', fwiw
<Chipaca> not sure if that's a bug or not :)
<mvo> Chipaca: in the gadget.yaml ? or where is it set to Recovery?
<mvo> Chipaca: it sounds like a bug
<Chipaca> mvo: on the image
<Chipaca> haven't looked at the yaml
<mborzecki> quick errand, back in 30
<mvo> Chipaca: ha! you are right
<mvo> Chipaca: its in the gadget.yaml, should be trivial to fix
<mvo> Chipaca: I have lunch now, let's sync on the grub stuff when I'm back
<Chipaca> hm, again it reached "Running /scripts/local-premount" and gets stuck there
<Chipaca> maybe i'm being impatient?
 * Chipaca waits more
<mvo> Chipaca: will probably timeout eventually - alternatively the usual "break=top" or so should work. *maybe* even "systemd.debug-shell=1"
<mvo> Chipaca: this is the new stuff from xnox, we may have systemd already in initiramfs :)
<Chipaca> mvo: ah i was about t'ask
<Chipaca> "the required kernel commandline snap_core is not set"
<mvo> Chipaca: silly thing :)
<Chipaca> that's not a thing in 20
<mvo> Chipaca: I think we need quite a few updates to our initramfs
<cachio> Chipaca, is this conversation related to the removel-gadget test is failing on master?
<mvo> Chipaca: and the fact that we can boot a kernel now means we can actually do it (hurazzz!)
<Chipaca> cachio: no :)
<cachio> Chipaca, ok, I'll take a look to the test in that case
<cachio> thanks!!
<cachio> :)
<mvo> cachio: AFAICT noone has looked deeper into this one yet :/ any hints appreciated (but maybe mborzecki  has looked at the failing remodel-gadget on master, not sure)
 * mvo gets lunch first
<Chipaca> mvo: i'll get an editable workable grub.cfg into a pastebin so more people can play
<mvo> Chipaca: \o/
<mvo> Chipaca: or even into github.com:snpcore/pc-gadget in the 20 branch? :) ?
<sil2100> mvo: ah! Nice catch! I forgot we're skipping that one
<cachio> mvo, ok
<sil2100> mvo: let's wait for at least one test run to finish and I'll merge it
<Chipaca> mvo: something else is is snapcore/pc-gadget a thing?
<Chipaca> er
<Chipaca> mvo: sorry those were two separate things
<Chipaca> mvo: second part first: where is this snapcore/pc-gadget?
<Chipaca> mvo: first part: something else needs doing because it's not picking up grub.cfg from the obvious place
<Chipaca> might be the old fat vs vfat names sillyness
 * Chipaca tries
<zyga> hmm
<zyga> Chipaca: without reading the backlog, is something failing and you are looking at pc-gadget?
<Chipaca> zyga: not really no
<mborzecki> re
<zyga> mborzecki: making progress, some more complexity but nothing breaking
<mborzecki> zyga: sound like you're having fun :)
<mborzecki> mvo: cachio: yes i have, and the way we restore the system state after the test is wrong or just lacking
<cachio> mborzecki, what I see is that the test is failing just when other test is executed before
<mborzecki> mvo: cachio: in short what happens is that we have a tar.gz with files that existed *before* the test, and in restore the restore that state, but things that are newly added during the test stay behind, they don't get cleaned up
<mborzecki> mvo: cachio: imo what we need is like rsync --delete or just fix the tests to do the cleanups
<cachio> mborzecki, nice, I'll try that
<mborzecki> cachio: i'm fixing the tests for now, but maybe i can find a sensible way of detecting when stuff is left behind
<mborzecki> sensible, as in not invovling gruesome shell one liners
<zyga> - Remove data for snap "pc" (36) (failed to remove snap "pc" base directory: remove /var/snap/pc: directory not empty) <- Chipaca <- was that the topic?
<mup> PR snapcraft#2792 closed: pluginhandler: use well-formed build package/snap lists <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2792>
<Chipaca> zyga: no
<mvo> mborzecki: nice, thanks for looking into this
<mvo> Chipaca: re gadget> https://github.com/snapcore/pc-amd64-gadget/tree/20
<mvo> Chipaca: that's the current place and we can update the 20 branch
<Chipaca> mvo: where is EFI, on the resulting image?
<mvo> Chipaca: a good question, I need to look
<mvo> Chipaca: not sure if that needs special handling
<mvo> Chipaca: aha, hmmmm, I *think* we did that using the gadget.yaml
<mvo> Chipaca: maybe that needs updating
<Chipaca> mvo: I mean, gadget.yaml talks about EFI, but there is no /EFI/ in the recovery partition afaict
<mvo> Chipaca: hmm, that might need tweaks to ubuntu-image again
<mvo> Chipaca: https://github.com/snapcore/pc-amd64-gadget/blob/20/gadget.yaml#L23 should populate the partition
<mvo> Chipaca: but when I look I also see no content there
<Chipaca> mvo: also, also, i'd like to be able to load a grub module :)
<mvo> Chipaca: what does that involve?
<Chipaca> is that doable?
<Chipaca> mvo: in grub.cfg it's an insmod, and a file under EFI/
<Chipaca> not sure how it interferes with secure boot though
<Chipaca> maybe a question for cmatsuoka
<mvo> Chipaca: should be ok - we may hardcode it into grub though, i.e. build grub with the module built-in
<Chipaca> mvo: but insmod regexp gives me globs so i can loop over a directory and pick out stuff without having to have env vars for everything
<Chipaca> mvo: so i think we want that :)
<mvo> Chipaca: right
<mvo> Chipaca: so I think we have two options, we can built it into grub or add the module to the gadget.yaml
<mvo> Chipaca: I think the later is quicker for now
<Chipaca> mvo: only if adding it to gadget.yaml actually puts it somewhere :)
<mvo> Chipaca: but maybe xnox has an opinion on regexp module vs build-in
<mvo> Chipaca: right, that's indeed a bit of a mystery right now
<xnox> Chipaca:  mvo: loading modules is prohibited under Secureboot
<xnox> and i thought regex is a built-in already anyway
<xnox> mvo:  also i see grub.conf in the pc-gadget, is that a bad symlink that should have been called grub.cnf?
<xnox> also generated image has duplicate full copies of snaps itseems, that's quite suboptimal.
<xnox> note systemd-seed is vfat thus no hardlinks / symlinks available...
<xnox> (unless my world view is wrong about vfat)
<mvo> xnox: grub.conf vs grub.cfg is a long story
<xnox> mvo:  i slowly back away. cool then.
<mvo> xnox: I don't see duplicated snaps
<mup> PR snapd#7723 opened: snap-bootstrap: create encrypted partition <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7723>
<mvo> xnox: I just see /snaps and a bunch of them there
<Chipaca> xnox: AFACIT the regexp module is not built-in
<xnox> so reading source code i beleve regexp module is built-into our grub efi image at least. On bios it needs to be loaded, which is allowed there.
<xnox> Chipaca:  hm.
<Chipaca> so maybe this is booting via the bios one?
<xnox> Chipaca:  how are you booting it?
<Chipaca> seems strange, because it loads the cfg from EFI
<mvo> Chipaca: I will wrestle a bit why ubuntu-image does not include the content on the recovery partition unless sil2100 has an idea, I will probably have to do some deep dive
<xnox> Chipaca:  we are dual-boot/hybrid by default.....
<Chipaca> xnox: you know that email from mvo saying how to get a pc.img ?
<Chipaca> xnox: that
<Chipaca> xnox: how can i know if it's booting in efi or bios?
<mborzecki> we shoudl really get rsync into the core snap
<xnox> Chipaca:  are you using a VM? and have you provided OVMF firware to do bios boot and get a spash with tiano core? or do you use seabios ie. default.
<Chipaca> xnox: ah, this is a vm but wihtout the fancy ovmf stuff
<sil2100> mvo: I think I know the reason
<Chipaca> so i guess it's plain ol bios
<xnox> Chipaca:  there is nothing in the email that tells people how to boot it. qemu binary defaults to bios boot, unless one provides EFI firwmare. I use virt-manager, and use gui to specify ovmf stuff.
<xnox> Chipaca:  which is not our primary target.  =)
<mvo> mborzecki: we have a rsync snap, no?
<xnox> we are racing to boot unencrypted with UEFI =)
<sil2100> mvo: my expectation was that what snap prepare-image generates will already have all the necessary EFI/ directories
<Chipaca> xnox: right, i'll get that rig up (not my main rig because it still refuses to upgrade out of 1604)
<sil2100> mvo: but if that's still required to be done by ubuntu-image, then I can do that
<mvo> sil2100: aha, interessting
<xnox> har har
<zyga> mborzecki: another chunk https://github.com/snapcore/snapd/pull/7724
<mup> PR #7724: cmd/snap-confine: tracking processes with classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7724>
<mvo> sil2100: its a good question, in theory we have all the code to do that I think
<zyga> mborzecki: this applies the tracking (still with pids) for classic confiement
<Chipaca> ruh roh, ubuntulog fight!
<mborzecki> mvo: right, but it's a snap, and i need to restore this on a core device
<mvo> mborzecki: could we download it to /var/tmp and unpack there?
<mvo> mborzecki: or is that too crazy
<mborzecki> mvo: ha, this might even work! :)
<Chipaca> mborzecki: ssh + tar dude
<mborzecki> mvo: ok, let me finish up with this simple fix i have now and i can try that later
<Chipaca> mborzecki: tar cz path/to/tar | ssh 'tar xvz'
<mvo> mborzecki: \o/
<mborzecki> Chipaca: i'd seriously just want rsync -a in prepare, then rsync -a --delete in restore
<Chipaca> mborzecki: or, snap install rsync --devmode
<mborzecki> Chipaca: right, but the cleanup is in restore, where we dump the mount units, the state and so on, that's why unpacking to /tmp/rsync sounds appealing
<mborzecki> unpacking the snap ofc
<Chipaca> mborzecki: should work as long as it's the same core
<mborzecki> mhm
<mup> PR snapd#7711 closed: seed: test and improve Core 20 seed handling errors <Priority ð> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7711>
<Chipaca> brb, reboot
<mup> PR snapd#7725 opened: tests/lib/state: snapshot and restore /var/snap during the tests <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7725>
<mborzecki> mvo: cachio: zyga: poor man's fix ^^
<zyga> mborzecki: classic mount namespaces
<zyga> mborzecki: is that why you picked /var/snap/* over /var/snap
<zyga> ?
<mvo> pstolowski: I updated 7715 with most of your comments
<sil2100> mvo: ok, PR coming to you in a minute, just finishing running the unit tests
<mvo> sil2100: \o/
<Chipaca> ijohnson: do you know if mksquashfs lets you append to an existing squash using a different compression level?
<ijohnson> Chipaca: you can set compression options like block size and dictionary size, but it doesn't significantly improve performance because those things don't 1:1 correspond to compression ratio and you the size differences are minimal between that and the default
<ijohnson> Chipaca: I don't know I haven't looked at that
<ijohnson> Chipaca: my gut guess is that no, you can only use a single compression level for the whole squash image because the compression options are written in exactly one place in the image for the different types (i.e. file data, file metadata, and something)
<Chipaca> ijohnson: yeah, unless an append adds a new superblock, i don't see it happening either
<popey> https://forum.snapcraft.io/t/support-for-man-pages/2299
<popey> i saw somewhere that we might add man page support to snapd. or did I dream that?
<ijohnson> Chipaca: yeah exactly
<sil2100> mvo: hopefully this will do it: https://github.com/CanonicalLtd/ubuntu-image/pull/178
<mup> PR CanonicalLtd/ubuntu-image#178: System seed boot content <trivial> <Created by sil2100> <https://github.com/CanonicalLtd/ubuntu-image/pull/178>
<sil2100> I mean, if I didn't mix it up in my head
<pstolowski> mvo: #7715 +1, with one final remark
<mup> PR #7715: overlord: add base->base remodel undo tests and fixes <Priority ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>
<zyga> mborzecki: snapd side now works too
<zyga> mborzecki: I need to adjust spread tests that measure exactly how refresh app awareness is implemented
<zyga> mborzecki: wanna see a quick diff
<zyga> mborzecki: I cannot propose it yet because it depends on the rest
<zyga> popey: hey
<zyga> popey: not a dream
<zyga> popey: it's likely next cycle
<zyga> popey: and based on what others said it doesn't look like a big task
<zyga> mborzecki: minimal, tests-passing, patch to snapd to support this new scheme
<zyga> https://paste.ubuntu.com/p/6gtpY8q4VG/
<Chipaca> popey: its coming
<Chipaca> popey: hoping to get it in as part of 20 work, it's above the line for now :)
<zyga> mborzecki: running spread tests, also removed all pids cgroup usage from snap-confine now
<popey> Great! Thanks chaps!
<zyga> mborzecki: I'll structure the patches so that they are a linear progression
<mborzecki> zyga: looks like we might need a helper that hides cgroup.PidsInFile and security tag
<Chipaca> huh, tab completion for 'mount' is broken with the default awk in mate eoan
<mborzecki> zyga: like sandbox.PidsForSnap(<tag>) ?
<zyga> mborzecki: yeah, can do
<zyga> mborzecki: it cannot take tag
<zyga> mborzecki: it can take a snap info, return a map
<zyga> mborzecki: it could take a tag but I don't see use of that, we'd need to scan the same set of files really, just ignore more, and derive the name anyway for locking
<zyga> locking might need adjustment (will for sure)
<zyga> once UI is glued correctly
<Chipaca> mvo: so, once I add the missing files to the image, it boots in EFI (or is it UEFI) mode as well
<mvo> Chipaca: nice!
<mvo> sil2100: thank you, looking now
<mvo> pstolowski: thank you, I'm looking now
<Chipaca> xnox: and I can confirm 'regexp' exists in the (U)EFI grub
<Chipaca> so globs will work, supposedly
 * Chipaca tries
<Chipaca> yep! :-) winning
<mvo> Chipaca: \o/
<mvo> Chipaca: the PR from lukasz should make this all work now
<mvo> Chipaca: now we just need to expand gadget.yaml to include the extra partitions that are needed but thats not in the crticial path for booting just yet (it will be once we boot :)
 * sil2100 hopes his PR fixes it
<Chipaca> mvo: is the initramfs the core18 one right now?
<sil2100> Later today I'll prepare my env to actually test this on the test model
<mvo> Chipaca: pretty much AIUI
<mvo> Chipaca: xnox told me he will use the spike one for now which is close to core18
<mvo> sil2100: should be fine, we can test for you
<mvo> sil2100: well, except $meetings :/ oh well
 * cachio lunch
 * zyga goes for lunch
<zyga> mborzecki: tests updated, let's see if they pass
<zyga> mborzecki: I used a little hacky logic to find the place where snap-confine will put things
<zyga> mborzecki: ideas welcome https://www.irccloud.com/pastebin/L1e8JZxX/
<zyga> but first food
<zyga> cachio, mvo: I see ret tests because of 403 from the store
<zyga> search is 403ing
<zyga> is that expected now?
<mvo> zyga: might be worth raising with #snapstore
<zyga> k
<mborzecki> nothing like an occasional 403
<xnox> Chipaca:  pc-kernel is built from eoan, with initrd from eoan, whatever that contains.
<xnox> Chipaca:  i think it's not on-par with spike-tools, but better than just bionic.
<xnox> mvo:  ^
<xnox> bah
<xnox> wrong
<xnox> unwind
 * Chipaca unwinds
<xnox> Chipaca:  mvo: pc-kernel 20/* is built from FOCAL, with initrd from FOCAL, whatever that contains.
 * mvo is in a meeting but will read backlog
<xnox> which is not my stuff, and incomplete spike-tools version, as far as I can tell.
<mvo> xnox: if its not yours, who should work in it?
<Chipaca> jdstrand: FWIW that weird X thing happens if you try to run snapped X apps in vncserver, per https://forum.snapcraft.io/t/gui-snaps-cant-connect-to-display-in-vnc/14028/3?u=chipaca
<Chipaca> jdstrand: but only if you don't start vncserver when in an X session
<Chipaca> jdstrand: that is: log in via the terminal, start vncserver, connect to the vncserver, try to start a snapped app and it'll fail
<Chipaca> anyway, probably not a "you" issue
<sil2100> mvo: thanks for the review! I'll be merging it and we can iterate a bit more in case that's not enough or something ;)
<zyga> re
<jdstrand> Chipaca: ok, thanks
<mup> PR snapcraft#2794 opened: WIP: Add gnome 3 34 extension <Created by hellsworth> <https://github.com/snapcore/snapcraft/pull/2794>
<zyga> jdstrand: hey
<jdstrand> zyga: so, the basic idea is that you want to use the pids cgroup and move all snap processes into it?
<hellsworth> yeah i'm still cleaning things up, but thought i would go ahead and open it up for comments.
<jdstrand> zyga: but don't set the max or anything?
<zyga> jdstrand: not pids
<jdstrand> https://www.irccloud.com/pastebin/DUaJsF5k/
<jdstrand> lists:
<jdstrand> https://www.irccloud.com/pastebin/DUaJsF5k/
<jdstrand> meh
<jdstrand> 10:pids:/snap.travis.travis
<zyga> https://github.com/snapcore/snapd/pull/7722
<mup> PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
<zyga> jdstrand: tl;dr; -> if cgroup2 is mounted we use that (even in hybrid mode)
<zyga> jdstrand: if not we use cgroup name=systemd
<zyga> jdstrand: the new idea is really that we dig deeper into _whatever_ systemd has placed us already
<zyga> jdstrand: thereby not stealing the process
<zyga> jdstrand: thereby not breaking systemd in v2 mode
<zyga> jdstrand: I have two PRs and almost all the changes after that also ready
 * jdstrand is wondering what https://www.irccloud.com/pastebin/DUaJsF5k/ was trying to show me
<zyga> 0::/user.slice/user-1000.slice/session-2.scope/snap.travis.travis
<zyga> this
 * jdstrand also wonders why 'pids' is being used, but that is a different question
<zyga> pids was used so far in the earlier iteration of the work on refresh app awareness
<zyga> it's been like that for half a year roughly
<zyga> but it's not _enabled_ in production yet
<zyga> jdstrand: usage of pids is entirely replaced by the new idea
<jdstrand> zyga: does that not happen with devmode? I just tried in a devmode snap and noticed that /proc/self/cgroup had this: 8:pids:/user.slice/user-1000.slice/user@1000.service
<zyga> that's systemd
<zyga> not us
<jdstrand> I know that
<zyga> the paste I shared was from my local machine
<zyga> you won't see the changes elsewhere yet
<jdstrand> why does the devmode snap use systemd, bu tyour travis paste uses snap.travis...
<jdstrand> ok. I was confused by your "it's been there half a year" comment then
<zyga> jdstrand: I don't understand, travis was strated in my desktop session so it was placed in /user.slice/user-1000.slice/session-2.scope/
<jdstrand> ok, anyway
<zyga> jdstrand: snap-confine moved it to a subdirectory
<zyga> jdstrand: which is named after the security tag
<zyga> jdstrand: hence 0::/user.slice/user-1000.slice/session-2.scope/snap.travis.travis
<jdstrand> zyga: please look you this: https://www.irccloud.com/pastebin/DUaJsF5k/
<jdstrand> zyga: *you* mentioned that paste in backscroll earlier today
<zyga> right
<zyga> are you asking about why pids= is like that?
<zyga> or about something else?
<jdstrand> 10:pids:/snap.travis.travis
<jdstrand> yes :)
<zyga> ah, forgive me :)
<zyga> so, pids= implements stealing that we used for tracking
<zyga> current WIP branch no longer does that
<zyga> but
<zyga> the stealing is like that for a good amount of time
<zyga> and we just want to stop doing that
<jdstrand> ok
<jdstrand> so I'll ignore that
<zyga> sorry for making this confusing, I should have highlighted what I was trying to convey
<jdstrand> that said, mvo and I had discussed unconditionally putting all snap processes into both a pids and a mem cgroup so that management snaps could place resource constraints on them
<xnox> mvo:  "not mine" as in "not the new shiny systemd stuff" I think i'm still on the hook to maintain either initramfs-tools based initrd or the systemd based initrd =)
<jdstrand> if we did that, couldn't we just look at those cgroups to see if there are any processes currently in them?
<zyga> jdstrand: how do you want that to work in v2 world?
<jdstrand> zyga: sorry, seeing 'pids' in that paste reminded me of this
<zyga> jdstrand: yes but this doesn't exist in v2 world
<zyga> jdstrand: this is why we're doing this
<zyga> jdstrand: in v2 world my patch set already does what you want, in a way, because now you can put constraints on snaps regardless of which session they are in
<zyga> jdstrand: or if they are system or user processes
<mvo> sil2100: yeah, thanks so much for your help with u-i!
<zyga> jdstrand: because _all_ snaps in v2 are in sub-directory of where systemd placed the workload initially
<zyga> jdstrand: in v1 mode we can do the same thing for pids/memory
<jdstrand> I'm sorry, I'm having a hard time context switching. also, I said unconditionally into a pids cgroup, I mean cpu and mem
<mvo> xnox: aha, excellent! yes, sorry, I just misunderstood
<zyga> right
<jdstrand> also, the v2 world has cpu and mem cgroups based on https://www.kernel.org/doc/Documentation/cgroup-v2.txt
<jdstrand> so, and this is the part I forget, the limitation in a v2 world is how systemd is using it, correct?
<zyga> jdstrand: v2 world has only one tree
 * jdstrand has not done much in a v2 only world yet, besides having abstract conversations about it
<jdstrand> zyga: yes, but, as you mentioned in backscroll, you caan go deeper, just not higher, right?
<zyga> jdstrand: what you can do is to put constraints on a given point in the v2 tree
<zyga> jdstrand: yes
<zyga> jdstrand: so my patch set does that for v2 already
<jdstrand> zyga: yes, I understand
<zyga> jdstrand: note that the 0::/... line is the only thing you will see in pure v2 world
<zyga> jdstrand: so if you already scope each snap workload to the snap security tag
<zyga> jdstrand: you can put constraints now
<zyga> jdstrand: we can expand this to v1 world as well
<zyga> jdstrand: using a similar idea
<zyga> jdstrand: and pretty much the same logic we have in my first patch
<jdstrand> zyga: but I was then discussing, why not put snaps into a deep cpu and mem cgroup? and then use that for pid tracking?
<zyga> jdstrand: because I wanted to use just one thing, not several for pid tracking
<zyga> jdstrand: and that one thing is v2 if availalble (18.04+) or name=systemd as fallback
<zyga> jdstrand: because we can rely on that as well
<jdstrand> zyga: sure, but you could just pick one. if they are both unconditional, then just use cpu
<jdstrand> (for example)
<zyga> yes but it has semantics and this one does not, it's strictly for tracking and not resource allocation
<zyga> jdstrand: up until earlier today I was not considering name=systemd fallback at all, as we hoped we could avoid that
<jdstrand> zyga: yes... and that's fine. It's just that when I saw 'pids' I was reminded of this unconditional cpu/mem thing, which we don't have, but we want. snapd doesn't do anything with cpu and mem, so lumping that in with tracking
<zyga> I understand
<jdstrand> zyga: but, I guess if we can do one for tracking, we can do two more for cpu/mem
<zyga> yeah, I think this is safer
<zyga> name=systemd subdirectory is only used by systemd
<jdstrand> anyway, it is just a thought
<zyga> sure, sorry if I feel defensive about this, I'm trying to manage making this something that's realistically available
<zyga> I think it's a good idea to expand this to cpu/mem, not sure how people would configure that but if that's all the interface we give (guaranteed name) then I think that's okay
<jdstrand> that was the only idea
<jdstrand> I mean, we could then create an interface for managing snap* cpu/mem cgroups, etc
<zyga> an interfaces in permission or an API via snapd?
<jdstrand> but snapd itself wouldn't do anything cause it can't make an intelligent decision
<jdstrand> interfaces/builtin
<jdstrand> but I'm distracting us
<zyga> jdstrand: we can do it if we have a driving use case, right now that part feels easy but making sure it's what someone wants is harder
<jdstrand> zyga: yeah, there have been customer requests to make it easier to set cpu and mem limits on snaps
<jdstrand> anyway, again, I'm distracting
<zyga> thank you for sharing this, I will follow up with this idea soon
<jdstrand> thanks!
<jdstrand> zyga: is it documented anywhere in the forum or elsewhere all the cgroups stuff? like, v1 vs v2 vs unified within the context of systemd (perhaps by version) and how snapd currently fits, along with what other distros do and the recommendations?
<zyga> no, I don't believe so
<zyga> jdstrand: this idea was bounced internally between me and mborzecki for some time
<zyga> jdstrand: and after name=snapd collapsed I picked it up as the only sensible alternative
<jdstrand> zyga: I ask, cause, I get that all into my brain so I can somewhat talk about it, then persoanlly don't play with it at all, so I lose it until the next time
<jdstrand> zyga: I can't be the only one who is in a similar position. I mean, if one lives and breathes cgroups, that is one thing. that isn't me
<zyga> jdstrand: I will write it down on the refresh app awareness thread
<zyga> jdstrand: it's just so much happened recently I didn't manage to settle
<jdstrand> zyga: thank you. I think it would help everyone sync up and get on the same page for future changes in this area
<jdstrand> zyga: totally understand. I just feel like I'm slowing things down have to reconstruct everything in my head :)
<jdstrand> having*
<jdstrand> I guess there is some benefit to that. it means that the code, comments and spec need to be clear ;)
<jdstrand> but we can manage that *and* have things documented :)
<jdstrand> zyga: /sys/fs/cgroup/systemd is used in a v2 only world?
<zyga> no, in v2 world there's just one directory /sys/fs/cgroup and it's always a v2 mount
<zyga> it has all the roles combined
<jdstrand> that's right. jeez
<zyga> [zyga@fedora31 ~]$ mount | grep cgroup
<zyga> cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate)
<jdstrand> zyga: ok, dumb question, why is /sys/fs/cgroup/systemd empty on my eoan system?
<zyga> empty as in empty directory?
<zyga> it see plenty of stuff on eoan there
<jdstrand> meh, I fat fingered it. sorry
<zyga> 1K entries
<zyga> ah, ok :)
<zyga> uff :)
<zyga> I checked with stgraber and xnox and I think this is something we can rely on
<zyga> unified (hybrid), pure v2 or name=systemd
<jdstrand> it is great to have checked with them :)
<zyga> I should chop and push the rest of the changes
<zyga> need to add some more tests to refresh.go as well
<zyga> jdstrand: I have the entire refresh app awareness ported over to this now
<zyga> maybe tomorrow I can glue the gui to it
<zyga> and have the whole thing as a PR for vancouver
<zyga> the GUI is ready in another branch but the critical element I need to think about and (re)write is how snapd notices it's safe to refresh now
<sil2100> mvo: yw! If anything else pops up, just give me a poke
<ijohnson> zyga: when you have branches ready for this stuff, please request reviews from me :-)
<zyga> ijohnson: your wish is my command
<zyga> ijohnson: please review two first PRs
<zyga> https://github.com/snapcore/snapd/pull/7722
<zyga> https://github.com/snapcore/snapd/pull/7724
<mup> PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
<mup> PR #7724: cmd/snap-confine: tracking processes with classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7724>
<zyga> ijohnson: I'll add some more unit tests and commit the rest into several branches
<ijohnson> zyga: ack, sounds good!
<zyga> or maybe
<zyga> one branch and several patches
<zyga> it's better if the next stage is one PR as it's consistent this way
<ijohnson> zyga: still finishing up pedronis' greedy plugs PR review then I can switch to yours I think
<zyga> perfect
<zyga> I will have the third one that builds on this today
<zyga> code wise it's not big
<zyga> removes some now-dead code
<zyga> changes a few places, nothing huge
<mvo> sil2100: is it easy for you to trigger a new ubuntu-image build into edge? it seems like we have the code all landed now?
<mvo> Chipaca: silly question - with your grub.cfg and if we boot with qemu in UEFI mode - do we actually need anything to make the system bootable (i.e. do we need to tweak seed.go and friends at all?). it's an ESP partition and has the right binary names, so it should just work(tm), yes?
<mvo> Chipaca: which would be pretty nice, so we may get a booting recovery today afterall :)
<mup> PR snapd#7726 opened: RFC: change how snapd tracks processes <Created by zyga> <https://github.com/snapcore/snapd/pull/7726>
<zyga> ijohnson, jdstrand: https://github.com/snapcore/snapd/pull/7726
<mup> PR #7726: RFC: change how snapd tracks processes <Created by zyga> <https://github.com/snapcore/snapd/pull/7726>
<zyga> This is the RFC with all the changes that are going in, I'll be splitting the "many" patch next but I need a break for coffee
<ijohnson> nice
<mup> PR snapd#7715 closed: overlord: add base->base remodel undo tests and fixes <Priority ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7715>
<mup> PR snapd#7438 closed: devicestate: add support for base->base remodel <Priority ð> <Remodel ð> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7438>
<zyga> mvo: ^ proooogress :)
<zyga> mvo: it has feature party with master but works in more places
<zyga> I need to bring the patch that extended the LXD test to use this now
<zyga> to have sane sleep tonight
<zyga> but first
<zyga> coffee
<zyga> really
<zyga> brb
<mvo> zyga: woah, that sounds pretty great
<ijohnson> hmm mvo, jdstrand, or Chipaca are y'all available to discuss pedronis's greedy plugs PR with me a little bit? I'm sorta confused on what some of these tests are doing cause it feels like a test there is testing greedy _slots_ when I thought this PR was strictly about greedy _plugs_
<ijohnson> (this is about #7652 btw)
<mup> PR #7652: o/ifacestate,interfaces,interfaces/policy: slots-for-plug: * <Priority ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7652>
<sil2100> mvo: ah, crap, let me poke it
<sil2100> mvo: it operates on a github mirror on launchpad, probably stupid thing didn't update yet
<sil2100> I always forget there's this stupid delay
<popey> jdstrand: where is the bug tracker for snappy-debug?
<popey> https://launchpad.net/snappy-hub looks right, but not configured
<zyga> re
 * cachio breack
<zyga> did you guys notice that travis started showing the CPU column
<zyga> interesting
<zyga> (the CPU architecture)
<jdstrand> popey: the forum currently. snaappy-hub should have it configured, but I don't have the ability to do that
<Chipaca> zyga: for about a month now, since they started offering arm builders (runners? workers?)
<zyga> yeah, I think it makes sense given their overall direction
<zyga> just cute with nice icon :)
<jdstrand> popey: probably the snapcraft category
<Chipaca> ijohnson|lunch: not today :-|
<Chipaca> for me i mean; others may :)
<Chipaca> mvo: I'm trying to determine that. I can probably make a grub.cfg that will set the boot vars up to boot in core18 mode, which seems to be needed for now
<Chipaca> mvo: unless by "boot" you mean "reach initramfs" in which case yes, sure, done :)
<zyga> https://blog.quarkslab.com/analysis-of-qualcomm-secure-boot-chains.html <- interesting
<zyga> mvo: ^ share this with claduio if I  forget
<Chipaca> cmatsuoka: ^^
<Chipaca> zyga: like that?
<zyga> oh, is my memory failing me or did claudio change his irc nick
<zyga> man I could just be tired
<zyga> Chipaca: thank you sir :)
<Chipaca> zyga: hey, maybe i'm wrong and i've been sharing stuff with the wrong irc persona
<jdstrand> zyga, mvo (cc xnox): I did a first pass at pr 7722. the most important comment is my Delegate= observation wrt https://systemd.io/CGROUP_DELEGATION.html in https://github.com/snapcore/snapd/pull/7722#pullrequestreview-312613176
<mup> PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
<zyga> looking
<mvo> Chipaca: "boot" means initramfs for now
<mvo> Chipaca: no need to do anything uc18 compatible
<zyga> jdstrand: we looked at scopes with mborzecki
<mvo> Chipaca: I think we will figure out there we have no partitions and no run mode so we assume install and call snap-boostrap
<zyga> jdstrand: and AFAIR we cannot use them
<jdstrand> zyga: scopes with Delegate?
<zyga> delegate breaks service management
<zyga> AFAIK
<mvo> zyga: reading
<zyga> if we carve a place and say that we are a delegate there
<zyga> systemd doesn't handle any service ops anymore
<zyga> we had a look at delegate earlier and it was deemed ok to run things like a container there
<zyga> but not things that look like they are "on" the host
<jdstrand> zyga: I'm not sure why that side-effect would be there. The Delegate as documented in that page is referring to cgroups
<zyga> we talked to systemd upstream about it
<jdstrand> zyga: that doesn't mean that side-effect is *not* there, just that the page didn't mention it (unless I missed it)
<mvo> sil2100: no worries, if the mirror picks it up by itself by tomorrow thats totally fine, was just curious :)
<zyga> it's late and maciek is not here so we'll pick it up first thing tomororw
<mvo> sil2100: and it looks like it got build \O/
<jdstrand> zyga: well, there are 3 options according to that page. I just have real concerns that systemd may decide to move things, since, well, in that page it said it could
<mvo> Chipaca: so feel free to share the grub.cfg, I think we can then unblock xnox to hack on initramfs :)
<jdstrand> zyga: if we are going against their recommendations, I think at the very least we need to document why and have some assurances that it won't just immediately break
<jdstrand> zyga: again, I'm not saying it will break, I just have a lot of concerns based on that page
<jdstrand> (which is why I left a comment rather than a request changes
<jdstrand> )
<zyga> yeah, I don't blame you for it
<zyga> it's super tricky part
<zyga> I don't think we can use delegate at all
<zyga> because:
<zyga> it seems to require a unit file, that's okay for services but not for hooks and apps
<jdstrand> zyga: I guess it feels like we are trying to play nice with systemd in general, letting it do its thing, except we slide this bit in
<zyga> for non-service things we could use the dbus API to have systemd spawn them but then we don't have the semantics we had before
<zyga> (like having connected tty and things like that)
<zyga> if we have a special unit for snaps then we no longer have the way to set any per-user constraints
<zyga> so if a user has limit on some memory
<cmatsuoka> Chipaca: even for just booting in run mode, core18-style, a few changes inside the initramfs were necessary in the spike. to support installation the changes were fairly extensive
<zyga> all they need to do is to run a snap, that would be moved to a delegated place that is not in their user tree anymore
<jdstrand> zyga: how I thought of it, and again, this is without trying anything, is there is scope unit with Delegate= in it that is part of snapd install. that setups up a /sys/fs/cgroup/something/snapd directory. because Delegate is used, snapd will ignore that
<zyga> jdstrand: I acknowledge the fact that all three options are suboptimal and we are bending the rules slightly
<zyga> (systemd will ignore that)
<jdstrand> zyga: then snap-confine can create the subdirs under that
<zyga> we tried that approach earlier
<Chipaca> mvo: sweet! will do that this pm
<zyga> jdstrand: it breaks things like you log out and things get killed
<Chipaca> cmatsuoka: that's a relief because it wasn't working :-)
<zyga> jdstrand: and resource management associated with this
<zyga> jdstrand: AFAIK, I could be wrong because layers-of-complexity, this also breaks things like systemctl stop
<Chipaca> mvo: cmatsuoka: also i'm actually washing dishes, not working on grub.cfg, at this moment
<zyga> I'll double check with maciek tomorrow
<Chipaca> s/actually/supposedly/ :)
<cmatsuoka> cmatsuoka: the labels are different now, so at least these will need to be handled differently
<mvo> Chipaca: heh, thats fine - I try to bring the kids to bed too
<zyga> jdstrand: some of those options also require snap-confine to make dbus calls as well, meaning that snapd depends on dbus for all "snap run" commands
<mvo> Chipaca: just want something to play with in my morning ;)
<Chipaca> zyga: what's the significance of the maciej â maciek change?
<zyga> jdstrand: right now what we have is a compromise upon compromise
<jdstrand> zyga: zyga I mean, I could be wrong. *but* that page talks about Delegate and references resource controls, etc. it doesn't mention service control
<zyga> Chipaca: which change specifically?
<zyga> jdstrand: I could be wrong too but we explored this page, all three options, including discussing this with systemd developers
 * cachio afk
 * Chipaca afks too, before the dishes take over
<jdstrand> zyga: yes, only option 2 is available then. I just don't have experience with Delegate=
<zyga> jdstrand: I honestly think that we need a 4. expand systemd to have things like "portable services" delivered by things other than systemd
<jdstrand> zyga: upstream said to use your current approach?
<zyga> where there's a runtime and there are rules on how systemd and the runtime interact
<popey> jdstrand: ok, will start a forum thread
<zyga> jdstrand: no, they did not, we only evaluated the 1-3 options with them and it was an imperfect fit in all cases
<zyga> jdstrand: what was picked was the current proposal, after experiments and casual-check-with xnox
<jdstrand> https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#Delegate= only is talking about control groups. it seems odd that service control would fall apart with it
<zyga> jdstrand: it's based on control groups
<jdstrand> again, not saying that there aren't side-effects, just they aren't documented in what I am seeing
<zyga> I see
<zyga> jdstrand: btw, I replied on one comment
<zyga> https://github.com/snapcore/snapd/pull/7722#discussion_r343271853
<mup> PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
<zyga> I'll get to the rest later, I'll wrap up the day soon after adding some more unit tests
<jdstrand> zyga: oh, you're saying that systemd's service management is all around how it configures the cgroups for tracking?
<zyga> yes
<jdstrand> ok, that makes sense
<jdstrand> unfortunate, but makes sense
<zyga> I think it requires upstream love as well
<zyga> as in, us working upstream
<zyga> on something that is not just a "doesn't break yet" hack
<zyga> but something documented to work
<jdstrand> zyga: so, in PR 7722, I was with you all the way until sc_cgroup_create_and_join(current_hierarchy_path, security_tag, pid);
<mup> PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
<zyga> hmm?
<zyga> and what happened there?
<zyga> as in what does this do?
<zyga> or something else?
<jdstrand> zyga: then, since I *just* read that page, I got worried
<zyga> ah :)
<zyga> I understand
<jdstrand> I was going to ask a question based on that comment, but then need to think more
<zyga> I think we could use help from foundations
<zyga> to find _a_ way of doing what we want
<zyga> all the approaches we found so far are stretching the protocol
<zyga> or outright don't work in v2 world
<zyga> jdstrand: oh and btw:
<zyga> jdstrand: it works in lxd :) https://www.irccloud.com/pastebin/g3GPX3Nc/
<zyga> brb, family calling\
<zyga> \
<jdstrand> yes, I believe it would work, it is just, what is systemd going to do after we moved a pid in there
<jdstrand> I read the cgroups man page and was highly optimistic
<jdstrand> then I read the systemd cgroups delegation page and got worried
<jdstrand> zyga: curious, with your patch as is and moving pids into the new leaf dir, does service manage work ok?
<jdstrand> management*
<jdstrand> zyga: like, if you move the pid, does systemd lose track of it?
<zyga> re
<zyga> jdstrand: yes
<zyga> jdstrand: because it recursively scans the tree it created
<jdstrand> yes, as in it works I guess. and, it doesn't put it back?
<zyga> put it back?
<zyga> no, it doesn't seem to move anything after the initial context of the starting
<zyga> I guess it forks, sets up everything and execs
<zyga> and the fact we move in our exec chain doesn't bother it
<jdstrand> zyga: this is blackbox investigation, not documented/recommended/code inspected/whatever ?
<zyga> yes
<zyga> we did some code inspections
<zyga> we did experiments and discussed stuff as well
<zyga> but it's not documented proper behavior
<jdstrand> note that https://systemd.io/CGROUP_DELEGATION.html says: "The fact that systemd keeps these hierarchies in sync means that the legacy and hybrid hierarchies are conceptually very close to the unified hierarchy. In particular this allows us to talk of one specific cgroup and actually mean the same cgroup in all available controller hierarchies. E.g. if we talk about the cgroup /foo/bar/ then we actually
<jdstrand> mean /sys/fs/cgroup/cpu/foo/bar/ as well as /sys/fs/cgroup/memory/foo/bar/, /sys/fs/cgroup/pids/foo/bar/, and so on."
<jdstrand> I'm conerned about /sys/fs/cgroup/unified/user.slice/user-1000.slice/user@1000.service/foo.service/snap.foo
<jdstrand> != /sys/fs/cgroup/unified/user.slice/user-1000.slice/user@1000.service/foo.service
<zyga> in some sense that is a problem, as you see it, but if you put constraints on /sys/fs/cgroup/unified/user.slice/user-1000.slice/user@1000.service/foo.service they apply underneath as well
<zyga> the only difference is that cgroup.procs doesn't contain the service process there (no processes in intermediate nodes rule)
<jdstrand> zyga: right, unless you reduce in foo.services/cgroup.subtree_control
<jdstrand> anyway, it sounds like everyone has discussed this. I think there may be room for more investigation/confirmation that the approach should work with systemd as designed, and then document all this in code comments
<zyga> jdstrand: it's not rock solid design, it's just either this or we have no way to deliver the feature at all; it's a fallback at this stage
<jdstrand> ie, say why we can't use the recommendations in https://systemd.io/CGROUP_DELEGATION.html but why what we are doing should work
<zyga> jdstrand: it might well be that someone comes along and says "it cannot work for this-and-that-reason" and they will be right
<zyga> that's a good remark, I'll make sure this is documented
<jdstrand> zyga: that is what I am afraid of :( I would hate to deliver this and then have it buggy, break down the line with no recourse, etc
<zyga> jdstrand: I had one more idea that doesn't rely on cgroups
<zyga> jdstrand: but it's bad for other reasons
<zyga> jdstrand: I implemented a prototype for it
<zyga> jdstrand: but the rough idea is that snap-confine is a service manager and watches a subtree of processes as a subreaper
<jdstrand> zyga: I'll mention that there is something that works on systems with apparmor: look at the security label. it is not atomic but you will get what you want
<zyga> jdstrand: that's true
<zyga> jdstrand: in fact any pid-tagging system works
<zyga> jdstrand: we effectively use this as pid tagging
<jdstrand> zyga: on Ubunt uTouch the security label was key in process lifecycle
<zyga> jdstrand: let me just briefly finish the problems I found with the mini-service-manager idea
<zyga> jdstrand: to retain the feeling that snap-{run,confine,exec} chain just execs your program in the end
<jdstrand> zyga: with pid tagging, are you talking about 'ptags'?
<zyga> ptags?
<zyga> I meant it as anything that can associate some information with a process
<jdstrand> I just googled pid tagging and found https://lwn.net/Articles/702639/
<zyga> I was told there's no such thing yet
<zyga> jdstrand: (contd.) to retain the feeling that it's just a chain of exec, the service manager part forks off and forks off the application process
<zyga> watching for deaths of all the processes in that subreaper tree
<jdstrand> it doesn't seem committed, no. but, LSMs can do that (as mentioned, apparmor security label)
<zyga> and relying signals and exit status to the stub process
<zyga> it's ugly and I would not want to ship it but it did the job somewhat
<jdstrand> zyga: a fork or fork/exec?
<zyga> jdstrand: indeed though scanning proc is even worse than scanning cgroup
<jdstrand> zyga: it is not great, no, but if cgroups are a no go...
<zyga> jdstrand: I can show you the rough idea on a piece of paper, hold on, it might be easier
<jdstrand> I'll admit it isn't exciting thinking about snap-confine as a service
<zyga> it would be closer to lxd model
<zyga> where such things are used
<zyga> https://usercontent.irccloud-cdn.com/file/ND62Rwl7/snap-confine-service-manager.jpeg
<zyga> jdstrand: the surogate is what others will track as "main pid"
<zyga> surrogate*
<jdstrand> lxd could actually use the Delegate= idea since it does all its management
<zyga> I'm sure it is doing that
<zyga> it feels like a use case for that exactly)
<jdstrand> indeed
<zyga> jdstrand: so the diagram has the entry at the top, the surrogate waits for the real application to exit or die to relay the wait status
<jdstrand> LXD is a full container manager, which that page is talking about
<zyga> jdstrand: the fork chain to the left reparents the service manager and application parts
<zyga> the service manager becomes a subreaper
<zyga> forks off to exec the app and loops on waitpid(-1, ...)
<jdstrand> this is PR_SET_CHILD_SUBREAPER?
<zyga> as long as there are things to wait for it will collect
<zyga> yes
<zyga> if it collects the app pid it relays that to the surrogate via eventfd
<zyga> if it collects other things it just carries on
<zyga> eventually nothing more is needed and it quits
<zyga> it could also monitor the surrogate and kill the real app (I didn't implement that)
<zyga> on the up side it doesn't use cgroups :)
<jdstrand> aiui, it is going to lose zombies
<zyga> in fact it doesn't touch the filesystem
<zyga> why?
<zyga> jdstrand: (for a moment I also considered setting timer slack nanosecond to a unique value as a cookie but that's an idea from hell)
<zyga> jdstrand: waitpid will grab dead children from things forked by the app as well
<jdstrand> waiting on a pid to die or exit. that pid forks off stuff and dies. the zombies get reassigned to init. but reading the man page for PR_SET_CHILD_SUBREAPER, I guess that isn't true
<zyga> (that's what a subreaper does effectively)
<jdstrand> right
<zyga> yeah, that's the whole idea
<zyga> and the fact that you can wait on your children's children this way
<zyga> and know there are no more
<zyga> (ECHILD)
<zyga> I'm sure there are dragons in this idea
<zyga> I just feel I ran out of anything resembling ideas at this stage :)
<zyga> and that was the last one
<jdstrand> zyga: we could probably make it 'ok' from a security perspective through dropping, changing profiles, etc, etc. but it does feel heavyweight since we always have two processes per started snap command
<zyga> jdstrand: I also considered the manager to get the pid (pidfd) via socket
<zyga> I didn't implement that
<zyga> but I think this mode breaks subreaper
<zyga> and waiting
<zyga> it's only good for "have a handle to kill that guy"
<zyga> not for anything useful
<zyga> (beyond that)
<zyga> it's really a shame that we cannot just treat processes as files all the way with the right mechanics
<zyga> but I guess by the time I retire people will argue abut it and it will be the problem we are at today + lots of new related syscalls
<jdstrand> well, if snapd was the parent... but that is not desired due to design constraints
<zyga> yes
<zyga> we're between a hard place and initial design
<zyga> or something like that
<zyga> it's funny that in 2019, it's hard to answer "is this running" reliably because of how everything is interconnected
<jdstrand> zyga: I'd like you to... reconsider is probably strong... but not rule out LSM labelling as a part of a potential solution. remember, on any system with any apparmor enabled, classic, devmode and strict all get it. it is possible to start snaps under selinux with a per-snap label as well
<zyga> interesting
<jdstrand> zyga: if the cgroup thing doesn't work out that is.
<zyga> so are you saying that we could use selinux tags for a process that somehow map to snap security tags
<zyga> (selinux labels, sorry)
<zyga> I'm not ruling it out, if you had that impression
<jdstrand> zyga: its had wavy, but I was more saying that snapd is updated to launch every snap under its own label rather than under the shared label/unconfined
<jdstrand> it's*
<zyga> hmm
<zyga> please refresh my memory
<zyga> classic confined snaps get a label with a permissive profile, correct?
<jdstrand> it would require work, but you can see we just define policy for each snap that is installed taht is the same as what we have now
<zyga> jdstrand: related to classic confinement: https://github.com/snapcore/snapd/pull/7724
<mup> PR #7724: cmd/snap-confine: tracking processes with classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7724>
<jdstrand> (selinux there)
<jdstrand> zyga: re classic: *yes*
<zyga> jdstrand: mm
<zyga> jdstrand: well, I'll get over the whole design with mborzecki tomorrow
<zyga> jdstrand: as long as we can answer our UI driven questions I won't complain :)
<zyga> jdstrand: this feature looked so good on paper initially
<zyga> jdstrand: it's such a maze in reality
<jdstrand> $ ps auZ|grep test-classic
<jdstrand> snap.test-classic.sh (complain) jamie     5593  0.1  0.0   9604  3436 pts/16   S    13:54   0:00 /bin/bash /snap/test-classic/x1/bin/sh
<zyga> that's good
<jdstrand> $ snap list|grep test-classic
<jdstrand> test-classic                            0                                 x1     -          -                  classic
<jdstrand> zyga: yes, that was part of the design so we'd have tracking throughout the system
<zyga> jdstrand: I wonder if 20.10 will go to v2 mode
<zyga> jdstrand: 20.04 is totally premature
<zyga> but after, hmm
<jdstrand> zyga: so, if cgroups works, yay, just please document. if not, bummer since that is a great way to do this, but could limit to the feature to apparmor-enabled systems initially, then expand to selinux
<zyga> jdstrand: yes, I think this is a good idea
<zyga> have a look at the other PR
<zyga> it's much smaller in scope and risk
<zyga> and relatively tiny in size too
<zyga> landing it will bring me one step closer to whatever we do in the end :)
<jdstrand> zyga: I lost it in backscroll. number?
<zyga> https://github.com/snapcore/snapd/pull/7724/files
<mup> PR #7724: cmd/snap-confine: tracking processes with classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7724>
<zyga> tl;dr version is it makes classic confinement have pids= controller for tracking
<zyga> with the intent of swapping out that for the one in the other branch
<zyga> as can be seen in the WIP draft that has everything
<jdstrand> zyga: sorry about my concerns and not having a lot of answers there. interactions between systemd, snapd (and container managers like k8s, docker, greengrass, etc, etc) is always... frustrating?
<zyga> yes :)
<zyga> no need to be sorry
<jdstrand> zyga: but, at the very least, perhaps we can get some assurances that the proposed idea should work
<jdstrand> and knowing sooner if it won't is definitely better than not :)
<zyga> jdstrand: I wish I checked better earlier
<jdstrand> well, this is a minefield
<jdstrand> and hey, that's what reviews are for. we caught this stuff before it went live
<zyga> ijohnson, jdstrand: I've updated https://github.com/snapcore/snapd/pull/7726 to have more tests for PidsOfSnap (in overlord/snapstate/refresh.go) and I will call it a day
<zyga> I've spawned another test run
<mup> PR #7726: RFC: change how snapd tracks processes <Created by zyga> <https://github.com/snapcore/snapd/pull/7726>
<zyga> ijohnson: you will see that jdstrand did a thorough review of the main PR already but please do your review if time permits
<zyga> with that, I'm wrapping up :)
<zyga> in my free time I will write something easy, like a toy compiler maybe
<zyga> at least that's like, rewind to 60s and read a book
<zyga> jdstrand: oh, if we decide to pick a different hierarchy at some point
<zyga> jdstrand: e.g. someone runs new systemd and it gives us unified or something
<zyga> jdstrand: that's ok too
<zyga> jdstrand: because we scan all of /sys/fs/cgroup
<zyga> but I really need to wrap up and rest
<zyga> ttyl and thank you for the focus jdstrand!
<ijohnson> ack zyga
<ijohnson> Have a good night and get good rest!
<jdstrand> zyga: heh, take care :)
<mup> PR snapd#7725 closed: tests/lib/state: snapshot and restore /var/snap during the tests <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7725>
<mup> PR snapcraft#2793 closed: tests: enable SNAPCRAFT_BUILD_INFO for spread <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2793>
#snappy 2019-11-07
<mup> PR snapcraft#2795 opened: manifest: track and annotate `primed-stage-packages` <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2795>
<mwhudson> hm core refreshed and now google-play-music-desktop-player broke?
<mborzecki> morning
<zyga> Hey mborzecki
<zyga> Please read the review I got from Jamie
<zyga> We need to discuss this
<mborzecki> zyga: hey hey, i've landed the fix for master yesterday, so please update your PRs if needed
<zyga> Perhaps at 8:30?
<zyga> mborzecki: will do
<mborzecki> zyga: yeah, 830 sounds fine
<mborzecki> zyga: duh, epel8 build failed on s390x :/
<zyga> mborzecki: order one to debug at home ;D
<mborzecki> haha
<zyga> mborzecki: I rebased and pushed on https://github.com/snapcore/snapd/pull/7726
<mup> PR #7726: RFC: change how snapd tracks processes <Created by zyga> <https://github.com/snapcore/snapd/pull/7726>
<zyga> the other two can wait, we need to discuss them first
<zyga> mborzecki: I also enabled f31 locally and confirmed 7726 *passes* there
<mborzecki> zyga: nothing we can fix though https://kojipkgs.fedoraproject.org//work/tasks/4109/38804109/root.log Eighth_Doctor probably knows if this is being addressed
<zyga> yeah, let's ignore that
<zyga> brb
<mborzecki> hmm mvo isn't around yet
 * zyga adds test for https://github.com/snapcore/snapd/pull/7724
<mup> PR #7724: cmd/snap-confine: tracking processes with classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7724>
<zyga> mborzecki: I have a swap day for Friday
<zyga> mborzecki: I'll get a swap day for Monday at the sprint
<zyga> mborzecki: and two days for travel
<zyga> mborzecki: but I have a feeling I wont ever take them :/
<zyga> that's nearly a swap week now
<mborzecki> unlimited company vacation? :)
<mborzecki> zyga: btw. with your tweek from yday, it looks like you're prepping up fro the 4-day working week, tryign to squeeze 5 days worth of work into 4 days :P
<mborzecki> and the productivity is up :)
<zyga> :D
<zyga> I wish I had 4 day week
<zyga> or that 5 hour workday
<zyga> I feel tired lately
<mborzecki> mvo: morning
<zyga> hey mvo
<mvo> hey mborzecki and zyga
<zyga> mvo: it's been a long evening
<mborzecki> mvo: pinged you in https://github.com/snapcore/snapd/pull/7721 could use your input there
<mup> PR #7721: gadget: add support for hybrid partitioning schemas <Simple ð> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7721>
<zyga> https://github.com/snapcore/snapd/pull/7722 :)
<mup> PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
<mvo> mborzecki: thanks, I have a look
<mup> PR snapd#7652 closed: o/ifacestate,interfaces,interfaces/policy: slots-per-plug: * <Needs Samuele review> <Priority ð> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7652>
 * zyga -> breakfast
 * zyga pushed a patch to https://github.com/snapcore/snapd/pull/7724 and now _really_ does breakfast
<mup> PR #7724: cmd/snap-confine: tracking processes with classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7724>
<pstolowski> mornings
<mborzecki> pstolowski: hey
 * zyga breaks to rest for a while
 * dot-tobias hey all
<zyga> hey dot-tobias :)
<ackk> hi, I'm getting an error when running snap commands (and in the snap service as well) about meta/snap.yaml not being found. but the file is obviously there
<ackk> this is from a "snap try"
<zyga> ackk: is it visible from the preserved mount namespace?
<zyga> ackk: to find out: sudo nsenter -m/run/snapd/ns/maas.mnt
<zyga> ackk: stat /snap/maas/current/meta/snap.yaml
<ackk> zyga, it's not maas this time :)
<zyga> ackk: /o\ :D
<ackk> zyga, stat fails
<ackk> zyga, (it's canonical-rbac)
<zyga> now you can explore what is there
<ackk> zyga, https://paste.ubuntu.com/p/V9mn5GZztg/
<zyga> check what is mounted there
<ackk> zyga, from within the ns or outside?
<ackk> zyga, from outside I see nsfs on /run/snapd/ns/canonical-rbac.mnt type nsfs (rw)
<zyga> ackk: inside, where it is broken please
<dot-tobias> mvo: core 2.42.1 has been in candidate since Monday, will it get promoted to stable this week or did someone discover issues? Asking for an anxious stakeholder ð
<ackk> zyga, https://paste.ubuntu.com/p/FG4g8mBRNX/
<mup> PR snapd#7727 opened: tests: improve TestDoPrereqRetryWhenBaseInFlight to fix occasional flakiness <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7727>
<zyga> ackk: and on the host?
<ackk> zyga, https://paste.ubuntu.com/p/6GqMpSKWVt/
<ackk> zyga, note, this is in a bionic container
<ackk> (on disco as host)
<zyga> right
<zyga> ideally compare what is mounted where you see the snap.yaml
<zyga> and what is mounted where you don't
<ackk> zyga, so the /snap directory inside is empty apart from those 2 files, which seems broken?
<mvo> dot-tobias: it was planned to go to stable yesterday, I need to check what happend, worst case is that it gets promoted this monday
<zyga> mborzecki: so
<zyga> mborzecki, mvo: that branch can be scrapped
<zyga> but we can do something else still that's supported by systemd
<popey> ogra: https://snapcraft.io/beebeep - you gonna update that? looks like a new release in edge?
<zyga> but snap-confine will depend on dbus
<zyga> and will require to use dbus to talk to systemd to run anything that is not a service
<zyga> and will need to know if something is a service or not
<zyga> that's the status quo
<mborzecki> zyga: hm reading #fedora-devel now
<mborzecki> zyga: ehh, so dbus and scope then?
<zyga> yes
<zyga> no other way
<mborzecki> damn, that sucks
<zyga> I'm trying to pull some documentation that's better than just reading the source
<mborzecki> zyga: so if i'm reading this right, fire up transient scope, wait for it, then move the process to that scope right?
<zyga> yes
<zyga> StartTransientUnit and AttachProcessesToUnit
<zyga> and it should be a scope, not a slice, for the reasons I gave on #fedora-devel
<mborzecki> hm not exactly something we can simulate as separate steps in systemd-run
<zyga> mborzecki: wanna jump into this? :)
<mborzecki> zyga: fixing up the f31 pr, but let's sync afterwards maybe?
<zyga> sure
<zyga> I was supposed to rest anyway
<popey> ogra: in fact there's an even newer upstream release. 5.8.2 - you should setup automatic builds :D
<mborzecki> zyga: btw. one scope per user right?
<diddledan> if only there was a service for automated snap builds
<mup> PR pc-amd64-gadget#23 opened: Add missing partitions and improve grub.cfg-recovery <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/23>
<zyga> mborzecki: I don't know yet
<zyga> mborzecki: I think ... not
<zyga> mborzecki: I thik it's just one scope if I'm right
<zyga> but let me write a prototype first
<mborzecki> zyga: https://gist.github.com/bboozzoo/76b1535c93686a27bb7fdbaad0f560f7#user-process some notes from before
<mborzecki> zyga: there's even a note about separate scope for snaps
<dot-tobias> mvo: Thanks for the update! (re Core update release)
<Chipaca> mvo: btw i've been puzzling over this 'have two grub.cfg' and i'm not sure i understand it
<pstolowski> doh, "{\"error_list\":[{\"code\":null,\"message\":\"Nonce is missing or
<Chipaca> pstolowski: where was that?
<pstolowski> Chipaca: https://api.travis-ci.org/v3/job/608640768/log.txt
<pstolowski> Chipaca: google:fedora-30-64:tests/main/selinux-lxd
<Chipaca> pstolowski: log seems truncated
<Chipaca> anyway, i guess we need to retry those :-/
<pstolowski> Chipaca: ah i restarted the job assuming .txt would be kept
<Chipaca> no worries
<ogra> popey, yeah, will update it... i asked upstream about taking it over but he didnt reply (we actually had an active conversation that somehow died from his side)
<mvo> Chipaca: in a meeting right now
<mvo> Chipaca: but happy to talk to talk after
<popey> ogra: cool. i wanted to pimp it on the snapcraft social account
<popey> but don't want to do that if it's not up to date
<ogra> great, i'll test the edge version today and will promote it if it works
<Chipaca> popey: ogra: maybe pimping it is the push needed for them to take it on?
<ogra> yeah, perhaps
<popey> well, once we pimp it, the numbers will rise
<popey> it already has quite a few installs, but I think we can probably double it
<ogra> the numbers are pretty high already ... i think its my most downloaded snap atm
<popey> I had never heard of it before today
<popey> did you know you can tell if it's your most downloaded by going to https://snapcraft.io/snaps
<ogra> (an it still has one prob ... it doesnt beep :P ... )
<popey> it shows a graph at the top
<ogra> yeah
<popey> https://usercontent.irccloud-cdn.com/file/IQu0dsu0/Screenshot%20from%202019-11-07%2011-04-27.png
<ogra> 90k ?
<ogra> whats that ?
<Chipaca> ogra: popey: maybe update the description so it doesn't say you need to unzip it?
<popey> yeah :)
<ogra> one of yours
<ogra> Chipaca, lol, thanks, will do
<popey> no, not mine. just one i have access to
<popey> I bet diddledan has a nice looking graph on his page :)
<ogra> (that snap was actually the result of an ubuntu-users ML discussion... i only invested like 30min into it to prove how quick one can make a snap out of 3rd party SW)
<popey> (higher than any of mine)
<popey> nice
<popey> put another 30 mins in :)
<ogra> nah, rather 1h or two
<ogra> it never really got polished
<popey> is it a pulseaudio problem?
<popey> ok, I won't pimp it till you get audio and the theme looking a bit less.... Windows 95
<ogra> it uses some KDE audio lib
<popey> maybe use the kde frameworks snap
<ogra> some outdated thing ...
<popey> to re-use their libs
<popey> oh, arts?
<ogra> no, the thing after arts
<ogra> something with q or p ... i forgot the name
<ogra> phonon !
<popey> ah yes
<zyga> jdstrand: some news
<zyga> jdstrand: bad news: we cannot do what I did in that PR
<popey> See, this is one thing I love about snaps, is preserving this old crap :)
<ogra> haha
<popey> see also: mosaic
<zyga> jdstrand: good news: we can ask systemd to do exactly that for us
<zyga> jdstrand: bad news: it requires us to talk to systemd over dbus
<zyga> jdstrand: good news: it really works
<popey> mosaic has nearly 300 installs. Lunatics :)
<zyga> jdstrand: good news: it does not change the snapd sice of the task much, the only difference is that the location is a scope so it looks like snap.foo.bar.scope
<zyga> jdstrand: bad news it's somewhat racy, we need to create a transient unit with the pid of the process we want to have
<zyga> jdstrand: and if that fails we instead need to attach process to the scope
<zyga> jdstrand: if that fails we need to retry creating the unit
<ogra> popey, well, it is one of these things you install, try out once and forget
<popey> true
 * popey schedules a tweet about mosaic for 7th January, when it will be 23 years old
<ogra> i'm sure i have an idling mosaic install on one of my machines that i only tried once
 * popey looks at Chipaca 
 * popey looks at the wikipedia page for netscape navigator
 * popey looks back at Chipaca 
<Chipaca> popey: I know!
<popey> :D
<Chipaca> popey: but the on-disk filesystem seems to be incompatible :-(
<Chipaca> I need to give it a weekend
<Chipaca> popey: something changed _on disk_ since the libc5 days
<Chipaca> at least that's what the errors tell me
<Chipaca> popey: HOWever, mosaic isn't the oldest software in the store :)
<popey> the birthday is 21s February, so you have until then :)
<popey> oh?
<Chipaca> popey: mosaic is from 1993
<Chipaca> popey: simcity is from 1989
<popey> is simcity in the store?
<Chipaca> obvs
<popey> i didnt find it
<Chipaca> popey: 'micropolis'
<popey> oh!
<Chipaca> popey: simcity is (tm) ea
<Chipaca> popey: micropolis is a build from the now-free-software simcity code
<popey> clever
 * popey hugs diddledan 
 * popey gets that on the hype train
<Chipaca> one of the nicest things about these old-as-hat things is that they're tiny :)
<ogra> bah
<ogra> $ beebeep
<ogra> ln: failed to create symbolic link '/home/ogra/snap/beebeep/13/.config/gtk-2.0/gtkfilechooser.ini': File exists
<ogra> /snap/beebeep/13/beebeep: error while loading shared libraries: libxcb.so.1: wrong ELF class: ELFCLASS64
<ogra> so that requires some actual work it seems
<Chipaca> ogra: the elves class war! sounds like a socialist dystopia d&d thing
<mborzecki> man, spread suite on f31 is messy
<mborzecki> it's like the stuff breaks in most akward ways
<mborzecki> quick errand, back in 30
 * zyga lunch
<mvo> Chipaca: back now, if you want we can have a quick HO (now or later) about the two grubs/uc20 etc
<mvo> Chipaca: s/now/in 5min/ :)
<Chipaca> mvo: digging into some bugs atm
<Chipaca> mvo: didn't we land a fix to allow snapd in a model?
<Chipaca> in fact this model here has snapd
<ogra> crap .. the new beepeep will need core18 ...
<Chipaca> ogra: everybody's on core18 these days
<pstolowski> doh #2,  x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error"
<Chipaca> pstolowski: _where_ are those coming from?! i got the too, a few days ago
<pstolowski> Chipaca: https://api.travis-ci.org/v3/job/608640768/log.txt (not restarting it this time ;))
<pstolowski> Chipaca: seems that those debian-sid tests failed because of that
<Chipaca> yeah
<Chipaca> pstolowski: i've raised it with the store, but please let me know if you see it again (and in what distro)
<Chipaca> it might be a broken CA wotsit on debian, for all i know
<pstolowski> Chipaca: uhmm. going to restart it again
<Chipaca> pstolowski: k
<mup> PR snapd#7470 closed: DRAFT: core20 snap install <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/7470>
<Chipaca> cmatsuoka: ð
<cmatsuoka> Chipaca: hello
<mvo> Chipaca: yeah, snapd should work, I think we are at the point now where the next missing piece is the extraction of the kernel
<Chipaca> cmatsuoka: do you know if, as well as the kernel, we need to have the initrd extracted for secure boot?
<mvo> hey cmatsuoka ! good morning :)
<cmatsuoka> mvo: hi. good morning. I just closed #7470 because all parts are handled elsewhere, I hope you don't mind
<mup> PR #7470: DRAFT: core20 snap install <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/7470>
<mvo> Chipaca: my understanding is ( cmatsuoka please correct me if I'm wrong) that the uc20 kernel will be a single file with an embedded initrmafs
<Chipaca> ahhhh
<mvo> cmatsuoka: yeah, thats great
<Chipaca> i was just thinking / remembering the days of single-blob kernel+initramfs (on a floppy)
<mvo> Chipaca: I'm not sure this is the case today though, I need to check
<mvo> Chipaca: haha - it all comes back (what is a floppy btw?)
<Chipaca> mvo: that thing that looks like a vending machine
<mvo> Chipaca: lol
<cmatsuoka> Chipaca, mvo: yes, I think the idea is still to have a single file
<Chipaca> mvo: that was in reference to this, btw: https://mobile.twitter.com/fea0er/status/1160099135569063936
<mvo> Chipaca, cmatsuoka I just extracted the pc-kernel snap and it looks like at least today there is still an initramfs :/
<cmatsuoka> Chipaca, mvo: at that time I was probably rebuilding my kernels to avoid using initrds
<Chipaca> cmatsuoka: dhcp in the kernel, but tinyX in the initrd
<Chipaca> hm, let me try something :-)
<cmatsuoka> mvo, Chipaca: I didn't check the latest kernel snap but a few weeks ago it was quite outdated, I had to inject newer versions to run those entropy and crash tests
<mvo> cmatsuoka: thanks, thats good to know
<Eighth_Doctor> zyga: I filed a bug report about it: https://pagure.io/releng/issue/8977
<Chipaca> ok, i'm going out for a bit
 * zyga goes to implement the new thing 
<Chipaca> mvo: looks like having an embedded initramfs means recompiling the kernel every time you need to change the initramfs
<Chipaca> it's not just appending one to t'other
<mvo> Chipaca: uh, that will make testing very inconvenient
<Chipaca> yes
<Chipaca> maybe there's a workaround, none of this is too well documented
<Chipaca> anyway, i really need to step out for a bit :)
 * Chipaca goes, now
<zyga> Eighth_Doctor: thanks!
<mborzecki> re
<mborzecki> Eighth_Doctor: so releng is the right place for problems like this?
<Eighth_Doctor> usually, yes
<Eighth_Doctor> it means something went wrong when the packages were imported from the Red Hat CDN into Koji
<mborzecki> Eighth_Doctor: got it!
<mvo> Chipaca: silly question, I thought the uefi grub has regexp build-in, I boot with -bios ...OVMF.fd but I dont't get regexp in my grub. did I misundersttood?
<mvo> Chipaca: anyway, not urgent, need to get lunch first :)
<ogra> hmm ... diddledan do you know anything about the alsa-libs part not working on build.s.io ? seems it stumbles over the ftp url
<ogra> works fine locally
 * pstolowski lunch
<ogra> ok, here we go ... switching to http download helps :)
<zyga> mborzecki: back?
<mborzecki> zyga: yes
<zyga> mborzecki: I added a hack and it works
<zyga> mborzecki: using the dbus api now
<zyga> I'll run a spread pass now
<zyga> mborzecki: I need to check instances as I'm worried that _ is invalid in scopes
<zyga> but that's fine, we can escape if needed
<mborzecki> zyga: _ ?
<zyga> yes
<mborzecki> zyga: does systemd complain or just mishebaves?
<zyga> mborzecki: I didn't try it yet
<mborzecki> zyga: ah, ok, so it's written down somewhere, tha's fine then
<zyga> yeah, whatever it is it's okay
<zyga> I _think_ the situation is somewhat okay now
<zyga> but
<zyga> I need to check one last thing
<zyga> is using delegate breaking services now
<zyga> or not
<zyga> given that we tell systemd what we did
<zyga> (the suspense continues)
<ogra> popey, the beebeep snap is updated and works so far (it even beeps now!!) but i have a hard time convincing my system to be english for an updated screenshot
<ogra> popey, mind installing it from --edge and do a screenshot of the window ?
<popey> sho thang
<ogra> gracias !
<popey> does it use bonjour?
<ogra> yeah ...
<ogra> needs two machines if you actually want to chat ... and on first start it offers to create a username, pick different ones on different machines
<zyga> jdstrand: around?
<ogra> voice messages dont work (yet) btw
<popey> I once had a train using my phone as an insecure hotspot. Some rando connected to it, and I saw them show up via bonjour in pidgin. I pinged them and said "Yes, it is okay to use my hotspot" :D
<zyga> mborzecki: I think the next step is to implement that in C
<popey> bonjour is awesome.
<zyga> mborzecki: but apart from that... not terrible?
<ogra> yep ...
<ogra> too bad android doesnt support it at all :(
<ogra> (all my core installs around the house use it (using the avahi snap) but my phone always needs the IP anyway ...
<ogra> my first snap using "audio-playback" !!
 * ogra knows jamie will like that
<ogra> funnily pulse is still autoconnecting ... not sure why
<popey> ogra: sent you some via telegram
<zyga> oh drat, I think jamie is off
<zyga> oh well
<zyga> Chipaca: it's odd that one cannot install a classic snap on core with --jailmode
<ogra> bah, since when do we have these silly minimal size restrictions for screenshots !
<popey> use convert to scale it up :D
<zyga> brb
<mborzecki> cachio: hey, do we tweak the umask in fedora images for our spread tests?
<ogra> popey, i used gimp to add a transparent frame :P
<ogra> popey, anyway, website updated ... i'll promote it to stable now and we should be done
<popey> that looks much better!
<popey> thanks ogra <3
<popey> will line up a social post
<ogra> bah and now chromium is stuck :P
<ogra> aaand ... promoted
<dot-tobias> ogra: Is there a way to build a Core image in which only *one* snap is not from latest/stable? E.g. I want all snaps from the normal stable channel, but one snap from other-track/stable.
<dot-tobias> required-snaps in the model assertion complains about invalid snap names if I use the notation that's allowed in build-snaps, i.e. `snap-name/track/channel`
<zyga> dot-tobias: AFAIK no, known limitation
<ogra> dot-tobias, not sure, i know there was a request to support that a while ago, but i dont know if anything was implemented yet
<Chipaca> zyga: you were working on #1851480, yes?
<mup> Bug #1851480: Hooks are not included in slot/plug label expressions <snapd:New> <https://launchpad.net/bugs/1851480>
<zyga> Chipaca: no, dot-tobias is
<Chipaca> orly
<Chipaca> dot-tobias: should I set the bug to in progress?
<dot-tobias> Chipaca: Not really, haven't had the time to start yet. Will ping here once there's something, have to dig into Go + snapd inner workings first
<Chipaca> dot-tobias: should I assign the bug to you?
<zyga> Chipaca: if you set it to in progress then please assign it to someone (dot-tobias)
<dot-tobias> Chipaca: Yes please, unless there's someone idling around craving to fix this, I'll try to get to it until next week
<Chipaca> dot-tobias: what's your lp nick?
<zyga> dot-tobias: oh, btw, I'll be in US west coast timezone all of next week
<zyga> dot-tobias: and typically busy
<zyga> I'm always on IRC but if I'm not responding this is probably why
<dot-tobias> Chipaca: https://launchpad.net/~glancr â or you mean the display name?
<dot-tobias> zyga: Good to know, thanks for the heads-up ð
<dot-tobias> zyga, ogra: Thanks for the feedback re ubuntu-image, I could've had a quick look at the ubuntu-image bug tracker before stealing your time: https://bugs.launchpad.net/ubuntu-image/+bug/1815580 â seems to me like --snap my-snap:channel is supported, though one needs to remember to juggle required-snaps in the assertion + --snap args for ubuntu-image
<mup> Bug #1815580: Support for snap prepare-image --snap=<snap>=<channel> <Ubuntu Image:Fix Committed by sil2100> <ubuntu-image (Ubuntu):Fix Released> <https://launchpad.net/bugs/1815580>
<ogra> dot-tobias, yeah ... thats a workaround/hack to overcome the current limitation ;)
<mvo> dot-tobias: just got clarification that core is actually promoted to stable, its just not at 100% rollout yet
<dot-tobias> mvo: Ah, great! Helps a lot, thank you for inquiring on my behalf. Much appreciated
<cachio> mborzecki, no, we don't
<ogra> roadmr, so i got this graph at the top of https://snapcraft.io/snaps ... any idea why my most used snap is not in the list/graph at all ?
<ogra> (mjpeg-streamer has way more users than any other snap i own but is not listed at all in that overview ... on its own metrics page it is fine though)
<mborzecki> cachio: pushed the last batch of fixes to #7702, the suite should be able to run succesfully on f31 now
<mup> PR #7702: tests: adding fedora 31 to google-unstable backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7702>
<mvo> dot-tobias: you're welcome
<cachio> mborzecki, thanks a lot
<zyga> mvo: can we restrict refresh-app-awareness to 18.04+
<zyga> mvo: if so I think this can be done
<zyga> OR can we backport systemd ;_)
<mvo> zyga: sounds like a question for foundations
<zyga> mvo: then I can rephrase my question as
<mvo> Chipaca: how do you run qemu/kvm to get the uefi grub? or is there a way to know which one was run?
<zyga> mvo: can I really require proper systemd version for this and not implement any hacks
<zyga> mvo: then if so I will focus on that
<zyga> mvo: and we can discuss backport as an option for foundations
<zyga> mvo: but I personally would not cry if it was not on 16.04
<mvo> zyga: I think its a conversation - chances are not that great but its worth a shoot
<mvo> zyga: maybe the relevant bits can simply be backported
<zyga> mvo: the feature is coupled to systemd running as a user session manager
<Chipaca> mvo: i go by the splash screen, but i think you can ask grub, but i'd need to get the efi-able box up to confirm (and i can't access it rn)
<zyga> mvo: aka 16.04 not having that, when that feature was implemented the APIs were created to support that
<Chipaca> mvo: basically, enter grub's commandline and see what "echo $prefix" prints
<diddledan> supporting such an old release as 14.04 was gonna be painful eventually :-)
<Chipaca> if it says EFI, it isn't EFI
<mvo> Chipaca: ok, I will poke around - I tried "regexp" iirc and that gave me an error
<Chipaca> mvo: ah, then you're not in EFI
<Chipaca> mvo: you need to copy regexp.mod in as well for that to work
<Chipaca> mvo: (EFI grub has regexp built in)
<mvo> Chipaca: I'm sure I'm holding it wrong, echo $prefix says (hd0,gpt2)/EFI/ubuntu
<Chipaca> mvo: it goes in EFI/ubuntu/i386-pc/regexp.mod
<mvo> Chipaca: but *maybe* I have the uc18 grub
<mvo> Chipaca: let me try to download the focal one
<Chipaca> mvo: the grub on the machine you run ubuntu-image impacts the grub on the image?
<Chipaca> mvo: note it's booting in i386-pc mode afaict (the error should mention it)
<Chipaca> mvo: so you'll need to find that mod, not the amd64 one you probably have
<mvo> Chipaca: I had to build my own pc gadget and I suspect it build it against core18
<mvo> Chipaca: again, thanks, that is good to know
<mvo> Chipaca: ha! I have grub 2.02 but focal has 2.04 so its all my fault
<zyga> mborzecki: check this out
<zyga> mborzecki: the test passes on 64 bit 16.04
<zyga> mborzecki: fails on 32 bit 16.04
<zyga> ?!?!?
<zyga> on the 32bit it doesn't have AttachProcessToUnit
<zyga> Unknown method 'AttachProcessesToUnit' or interface 'org.freedesktop.systemd1.Manager'.
<zyga> but it really really works on 64bit
<diddledan> zyga: just do it twice on 32bit so you have 64 :-p
 * zyga spawns shell to confirm this
<zyga> but
<zyga> mvo: ^ this might indicate that we're not in hot water
<zyga> as 16.04 x86_64 is where most of the sweet spot for support starts
<zyga> or perhaps our 32bit images are old
<zyga> I'll know soon (tm)
<diddledan> I imagine the 64bit has a newer version somehow. It certainly seems odd for an API to not exist in a supposedly same release with different bittiness
<zyga> diddledan: I suspect it's just a fluke in our test image
<zyga> cachio: are 32 bit and 64 bit images for ubuntu 16.04 in sync?
<diddledan> "computer says no"
<cachio> zyga, in sync?
<zyga> cachio: I suspect systemd version is different between them
<zyga> cachio: are the packages updated equally
<cachio> zyga, on Monday both were updated
<zyga> interesting
<zyga> thanks, I'll know the details soon
<cachio> zyga, I don't have the details about that update
<cachio> I know we update && upgrade
<cachio> and install all the snapd dependencies
<mup> PR snapd#7683 closed: overlord/ifacestate: remove automatic connections if plug/slot missing <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7683>
<zyga> mborzecki: I went towards uuid named scope
<zyga> mborzecki: this works on 16.04+
<zyga> mvo: is https://bugs.launchpad.net/snapd/+bug/1848567 fixed in 2.42.1?
<mup> Bug #1848567: autogenerated per-snap snap-update-ns apparmor profile may contain many duplicate mount rules causing excessive parser memory usage <aa-parser> <AppArmor:New> <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1848567>
<zyga> did you cherry pick that apparmor parser memory fix?
<mvo> zyga: it is
<zyga> ta
<mvo> zyga: but we need someone from foudnations to actually approve the SRU :/
<mborzecki> cmatsuoka: posted some comments under #7723
<mup> PR #7723: snap-bootstrap: create encrypted partition <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7723>
<jdstrand> zyga: I am here now
<cmatsuoka> mborzecki: thanks!
<zyga> jdstrand: hey!
<zyga> jdstrand: so ... so much progress
<zyga>  :D
<jdstrand> zyga: that is good news :)
<zyga> jdstrand: where do I start, I think the news is indeed good
<zyga> jdstrand: I sent an update to the PR
<jdstrand> ah, I only read backscroll
<zyga> jdstrand: I wanted to ask you how you feel about dbus
<zyga> https://github.com/snapcore/snapd/pull/7722#issuecomment-551086170
 * cachio lunch
<mup> PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
<jdstrand> zyga: let me read. otoh I have a comment, but let me read what you have
<zyga> jdstrand: tl;dr; we cannot do the move but we can ask systemd to do the move by calling a dbus methodf
<zyga> that's all, I'll let you read the details
<jdstrand> zyga: right
<jdstrand> zyga: oh, heh, that comment is basically backscroll :)
<mvo> xnox: can I build a new pc gadget with core20 ? I think you did a build against core18 but that means we have grub 2.02 without regexp in there which will not work with the latest grub.cfg that john added
 * jdstrand reads patch
<zyga> jdstrand: the API exists on 16.04+
<zyga> not on 14.04
<zyga> jdstrand: the patch in the -wip branch does the two-way dance (with attach as a fallback) but I since reworked it
<jdstrand> I think that is ok with how we defined 14.04 support
<zyga> jdstrand: to spawn a new scope each time
<zyga> jdstrand: with uuid inside
<jdstrand> but let me keep reading
<zyga> jdstrand: yes, I'm happy with that, 14.04 is ok
<zyga> ok
<mvo> Chipaca: I get a uc20 that boots now \o/ with your grub.cfg. it hangs in initrd but thats ok :)
<zyga> jdstrand: for the dbus call I was thinking to use sd-dbus C API, since we link to libudev which is a differently-named version of systemd it is not a new dependency
<jdstrand> zyga: hehe, busctl
<zyga> yes :D
<zyga> take that security
<zyga> let's system() out to busctl
<zyga> :D
<jdstrand> \o/
<zyga> but it helped to prototype this
<jdstrand> ok, more seriously
<jdstrand> of course :)
<jdstrand> so, it is super validating that my interpretation of that page was reasonable and my highlevel idea is what upstream recommends, even if I didn't precisely know how to do it ;P
<jdstrand> this isn't options 1-3 though
<jdstrand> anyhoo
<jdstrand> cool that there is a way with systemd
<mvo> sil2100: hey, I noticed its your SRU day, can I ask you to review the 2.42.1 SRU in unapproved please :) ?
<jdstrand> (it is sorta 3 I guess)
<jdstrand> ok
 * zyga checks the 1-3 list again
<jdstrand> zyga: it doesn't really matter. what I had forgotten and you reminded me today and yesterday is dbus is required
<zyga> jdstrand: there's one more cool thing there that I could mention
<jdstrand> please do
<zyga> jdstrand: systemd has a concept of a controller
<zyga> jdstrand: I'm not 100% sure how this is meant to be used
<zyga> but
<zyga> jdstrand: you can have a unit that a controller watches over
<zyga> jdstrand: and it will tell you when it wants to wrap it up cause the job died
<zyga> jdstrand: and I was wondering if that's like notification for us
<jdstrand> oh
<jdstrand> yeah
<jdstrand> interesting
<zyga> jdstrand: but before I would go there I'd have to check more
<zyga> jdstrand: it's not documented, I read most of what I found by reading systemd directly
 * jdstrand nods
<zyga> jdstrand: there's a property on a scope
<zyga> jdstrand: controller
<zyga> jdstrand: it's not a cgroup controller
<zyga> jdstrand: it's a dbus path of the place you can call
<zyga> jdstrand: and it calls it with one method, RequestStop or something like that
<zyga> jdstrand: it _smells_ like something reaching into a container via a container manager
<zyga> jdstrand: but I think we don't need to rely on that
<zyga> jdstrand: just found it interesting
<zyga> jdstrand: to answer your earlier question
<zyga> jdstrand: this is mode 1 a
<jdstrand> zyga: it makes sense> you put everything in places so systemd could track. it has a way to tell you about what it is tracking. that would obviate the need for the parsing code
<zyga> jdstrand: which is the :-) (happy face) variant
<zyga> jdstrand: I was thinking we _might_ keep the parsing code
<mborzecki> Chipaca: you're interested in nonce logs?
<zyga> jdstrand: until snap-confine can be told it's starting a service
<Chipaca> mborzecki: sure
<zyga> jdstrand: then we could only do the scope for user commands
<zyga> jdstrand: and not for services where it is ... weird
<jdstrand> zyga: maybe that is what nspawn uses </guess>
<mborzecki> Chipaca: https://paste.ubuntu.com/p/wMr9Wq66BB/
<zyga> jdstrand: and I think this makes sense in more ways actually
<zyga> jdstrand: because it means all kinds of workloads are managed by systemd now
<zyga> jdstrand: services, user services, non-service apps and hooks
<zyga> jdstrand: each one is understood by systemd as a thing
<zyga> jdstrand: we could even feed it with unit level meta-data
<zyga> jdstrand: like Description
<zyga> jdstrand: man page references
<zyga> jdstrand: perhaps we could even reference snaps or whatever, I'd have to check
<zyga> jdstrand: since we make a dbus call and we can populate anything that a scope unit can model
<jdstrand> zyga: ok, so as exciting as this is, I have some reservations about dbus, but I think we may be able to mitigate those concerns. hear me out (I'll type .. when done)
<zyga> jdstrand: understood
<jdstrand> a) calling dbus from snap-confine is going to bring a significant attack surface into snap-confine in terms of addressable apis in the address space
<jdstrand> b) calling dbus is going to bring some likely undesired rules into the apparmor profile
<xnox> mvo:  so the pc-gadget in launchpad is built againt focal, with focal binaries. I can retrigger that, download, unsquashfs, sed core18 to core20 and release into the store
<xnox> mvo:  despite declaring core18, all binaries inside it are from focal
<jdstrand> c) the combination of a and b is likely going to weaken the security posture of our hardening (primarily apparmor, but see address space)
<ogra> xnox, cheater !!! :)
<jdstrand> d) having a dbus call in the list of things we do is going to really slow things down. not a big deal for a service, but for a non-daemon, yikes
<xnox> ogra:  i only am blocked on IS to deploy my launchpad-buildd changes, and for my launchpad UI branches to be merged and deployed by webops.
<jdstrand> (now to the mitigations)
<xnox> ogra:  it's not like i didn't do everything to fix our infra to do the right thing properly first.
 * ogra hugs xnox ... i wasnt serious :)
<zyga> jdstrand: as a remark, a, b and c *might* not be needed if I can make it work from snap-run before setuid happens
<jdstrand> reading the patch, I was happy to see that we first create the scope and then slice based on the security label
<jdstrand> if that is the full label with command name, potentially not as nice
<zyga> scope/slice? there's only scope, the slice is what we got originally
<zyga> (as in given to us by systemd)
<jdstrand> I was happy cause I thought, ok, the first command invocation was slow, but then we can just add stuff ourselves, which is fast
<jdstrand> but then you said to add stuff, we need the second api
<jdstrand> zyga: I said slice trying to use systemd parlance, but might've mispoke. I meant the scope ends up being a branch and the security label a leaf
<zyga> yes, that's correct
<jdstrand> (back to soliliquy)
<jdstrand> and the second api requires a dbus call, so every snap command invocation needs the calls
<jdstrand> so (I
<jdstrand> 'm getting there)
<jdstrand> the first thought is, have a snap-dbus-helper in go that snap-confine calls out to
<jdstrand> we can profile transition to it and alleviate the setuidness/address space/expanding policy issues
<jdstrand> (a-c)
<jdstrand> if we fork/exec this we don't have to wait on it. we let it do its thing and perform the move any time later
<jdstrand> (d)
<xnox> mvo:  i think i will take your PR and push it into the store
<jdstrand> the snap run idea is interesting as well. we can discuss the merits of that
<jdstrand> ..
<zyga> so I think that's the thing to investigate now
<zyga> my thinking is as follows:
<zyga> snap run checks if a service is being started
<zyga> if so, nothing new needs to happen
<zyga> we can use existing systemd cgroup machinery for services to find what we need
<zyga> if this is not a service or it is a hook then we call the dbus api from go and move snap run to a new scope with UUID + snap security tag in the name
<zyga> snapd side we can differentiate those and scan /sys/fs/cgroup/{,systemd}
<zyga> in both cases holding a lock we can build the security-tag -> definitely-not-running data set
<zyga> (and if possibly running we know the PIDs that existed at the time)
<zyga> ..
<zyga> oh and perhaps as a side note, I would not go and optimize the dbus part until we know how much it really costs
<jdstrand> zyga: it is 100 going to cost. feel free to measure it
<jdstrand> 100%
<jdstrand> how much, I don't know
<jdstrand> but, in theory, this can happen asynchronyously
<jdstrand> it easily measurable, but don't do the measuring with busctl
<jdstrand> it's*
<jdstrand> so, does this api work with user sessions?
<jdstrand> zyga: I would be surprised that a non-root process could move itself to a new leaf
<zyga> zyga@eoan:~/go/src/github.com/snapcore/snapd$ time busctl --user call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager StartTransientUnit 'ssa(sv)a(sa(sv))' testing.$(cat /proc/sys/kernel/random/uuid).scope fail 1 PIDs au 1 $BASHPID 0
<zyga> o "/org/freedesktop/systemd1/job/787"
<zyga> real	0m0,010s
<zyga> user	0m0,006s
<zyga> sys	0m0,003s
<jdstrand> which would be required with snap run
<zyga> it can if all the permissions match
<zyga> the pid is the same as the invoker and owner of the unit
<jdstrand> zyga: the permissions being the uid/gid on the leaf?
<zyga> (since you can move to a service as well)
<zyga> not on the leaf, on the unit
<zyga> scopes have no oner
<zyga> since they are crated dynamically and are injected relative to where you are
<zyga> after I invoked that call I got move tod:
<zyga> 0::/user.slice/user-1000.slice/user@1000.service/testing.ba4454d6-0242-49ac-864e-e6ab1d6c2fb4.scope
<zyga> *moved to
<zyga> try it
<jdstrand> zyga: ok, so that would mean the scope would need to be per command, and per command per uid owner, no?
<zyga> no root needed
<zyga> there's a per command scope, yes
<zyga> my point is that the owner of each scope matches the invoker because that's the only way to have a scope
<zyga> there's no unit for a scope file on disk
<jdstrand> zyga: how do you calculate the uuid?
<zyga> I ask the kernel for one, look at the command above
<jdstrand> that's another thing that would block in low entropy scenarios
<jdstrand> could*
<zyga> yes, alternative is to just use a counter
<zyga> jdstrand: but I wasn't sure what is doing the counting
<jdstrand> well, not block, but I guess this isn't a security mechanism
<zyga> for things like sessions or systemd-run
<zyga> a counter would be preferred if we can count reliably
<zyga> but that might imply we need to maintain the counter in snap confine
<zyga> alternatively perhaps we could open a tmp file on /run/snapd/counters
<zyga> and the inode of that file is the value
<zyga> but ...
<zyga> no ... that is broken
<zyga> anyway, I think uuid is "good enough" to proceed
<jdstrand> zyga: can you mockup the series of 0::s from the /proc/pid/cgroup for when a snap daemon starts, then a snap command is started twice by the same user and then a snap command is started once by a different user?
<zyga> yeah, hold on
 * jdstrand wants to visualize the end result to make sure we are on the same page
<zyga> note that it depends on "where" the user is
<zyga> in particular it differs if I run firefox from the dock
<zyga> or run it from the terminal :)
<zyga> I'll show you
<jdstrand> zyga: sure, mix two calls from the dock and one from the terminal in
<jdstrand> zyga: (this would likely turn into a requested code comment ;)
<jdstrand> zyga: while you are doing that, it means that dbus must be up and running before a snap can be started (unless we fork off). that is perhaps fine since systemd probably needs it itself early on, but a consideration nonetheless
<zyga> jdstrand: indeed, I think there is a way to depend on it though
<zyga> I mean
<zyga> it's socket activated
<zyga> so no need to really
 * jdstrand is trying to think through side effects
<jdstrand> potentially will slow down the first thing that is started, but shouldn't be a concern
<jdstrand> zyga: I'll also say, this is probably not something that we can land in master before the sprint due to time constraints, measuring, etc. however, I think that mvo would be able to speak to this well. eg, "lots of investigative work was done and the probably is now fully understood. there were systemd interactions that complicated things, and we wanted to ensure we implemented something robust. until
<jdstrand> last week, everything was brittle, but now we know the methodology to use (confirmed with upstream) and we are working through the most performant and robust design. we should have that in the next week or so. I
<jdstrand> While we missed the roadmap item, I
<jdstrand> 'm pleased with the work and the solid direction"
<jdstrand> or similar
<jdstrand> :)
<jdstrand> if it were me, I would handle it that way. it isn't my call though
<jdstrand> what is my call is letting you know that I'm concerned about rushing this. we should get Samuele signoff imho
<jdstrand> mvo: fyi ^
<zyga> firefox started from gnome shell: 0::/user.slice/user-1000.slice/user@1000.service/testing.cbdc667d-d3e6-4246-8ecb-7461ba346f51.scope
<jdstrand> s/probably/problem/
<zyga> various programs started from the shell:
<zyga> 0::/user.slice/user-1000.slice/user@1000.service/testing.cd8f04c3-56d2-425a-a74a-0693440a78a3.scope
<zyga> 0::/user.slice/user-1000.slice/user@1000.service/testing.dd2b526f-379f-465c-a704-10eb243fa991.scope
<zyga> (all as my user)
<zyga> odd, this is fedora 31, I think I noticed that it used to have some more variance before
<jdstrand> (please show the leaves as well
<jdstrand> )
<jdstrand> zyga: this might be better understood in a pastebin
<zyga> yeah, I'll collect it, sorry for pasting in-the-middle work
<mvo> jdstrand: in a meeting, will read backlog
<zyga> the leaves are owned my my user
<zyga> [zyga@fedora31 ~]$ ls -ld /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/testing.dd2b526f-379f-465c-a704-10eb243fa991.scope
<zyga> drwxr-xr-x. 2 zyga zyga 0 11-07 17:01 /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/testing.dd2b526f-379f-465c-a704-10eb243fa991.scope
<jdstrand> no worries. I want to be able to see all of it so we can discuss by referencing line numbers
<zyga> ok
<jdstrand> zyga: ftr, I'm *very* encouraged by this as an overall concept. how we iron out the details of the concept is all we're talking about
<jdstrand> (ie, the scope/delegate/dbus bits)
<jdstrand> (the snap run bits are the details :)
<jdstrand> (or snap-confine, etc, etc...)
<zyga> 0::/system.slice/sleep.service <- a regular service
 * zyga collects everything
<jdstrand> thanks
<ijohnson> hey marcustomlinson, is it okay if I adopt your patch at https://github.com/snapcore/snapd/commit/49114d576feb371a27fa4c0d5074dfa487aab358 to merge into snapd? I will need to refactor it a bit before we can merge it likely, and we can't use the 3rd party dep you have there, but this is great work and I would like to see it merged into snapd (as well as use it more for snap startup performance investigations)
<ijohnson> if you'd like I can just add commits on top of your commit in a branch, or I could just make a new commit with your changes there and provide attribution in the commit message/PR description
<marcustomlinson> ijohnson: either is fine, I don't mind :)
<marcustomlinson> ijohnson: and yes please! go ahead
<zyga> jdstrand: so I have a little bit
<zyga> https://www.irccloud.com/pastebin/mlAOGSGg/
<jdstrand> zyga: fyi, my comment in the pr without putting any time constraints on you: https://github.com/snapcore/snapd/pull/7722#issuecomment-551159049
<mup> PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
<zyga> jdstrand: I'm nearly convinced this doesn't need to be in snap-confine
<zyga> jdstrand: I'll try to move this to snap run
<zyga> jdstrand: with uuid and stuff
<zyga> jdstrand: 0 changes to snap confine would be a sweet deal out of this work
<jdstrand> zyga: ok, so with this you are skipping the security label
<zyga> jdstrand: yeah, I think so
<zyga> jdstrand: well,
<jdstrand> zyga: that is one of the things I wanted to get on the same page about. I was still thinking there would be a leaf
<zyga> jdstrand: given where we've been so far I think it's hard to say so for sure ;-)
 * jdstrand nods
<zyga> jdstrand: the leaf is the scope here, no/
<jdstrand> zyga: what is happening at line 15? the ls seems to contain the same thing as the new scope
<zyga> in line 15 I just check the ownership of the scope
<ijohnson> marcustomlinson: great, thanks!
<zyga> in line 12 I read it
<jdstrand> oh, I missed -d
<zyga> it's printed on line 13
<jdstrand> sorry
<zyga> no worries :)
<jdstrand> zyga: remind me, StartTransient unit with Delegate is enough to keep systemd happy and for us to track?
<zyga> without delegate
<zyga> delegate was needed to be able to move a process there later
<jdstrand> I was trying to read backscroll and lost track of that
<jdstrand> ah right
<zyga> but given that it dependso n more recent systemd and using an uuid is good enough I don't think we need to use that
<jdstrand> this is purely for tracking and don't need to move
<zyga> so just starting a transient unit of type scope with snap-run PID
<zyga> yes
<zyga> we could even leverage that in hooks
<zyga> where we "try" to kill hooks that are long running
<zyga> but now we can really actually stop them
<zyga> reliably
<jdstrand> zyga: and the real thing my do s/testing/snap-run/ (or something)
<jdstrand> might*
<jdstrand> (for the scope name)
<zyga> are you asking about the scope name to use for real?
<jdstrand> yes
<jdstrand> or were you thinkg the security label?
<zyga> I think it should be f($SNAP_SECURITY_TAG), something like snap.PKG{,.hook}.NAME.$UUID
<jdstrand> ok
<zyga> we can shuffle those around to look nice
<zyga> but I think it's a good start
<zyga> and as I mentioned earlier, only for non-service apps and hooks
<zyga> services are good to go as is
<jdstrand> zyga: with this, every command invocation gets a new uuid. when are these cleaned up? will systemd be able to handle potentially thousands of these?
<zyga> they are automatically cleaned by systemd
<zyga> I can try how it scales
<jdstrand> I think we'd need to understand that with the uuid approach
<jdstrand> zyga: not saying we need to be thinking like this, but, it would seem ok if the best implementation used newer systemd features. we could downgrade from one to another but more I was thinking perhaps systems without a new enough systemd don't get the feature
<jdstrand> zyga: thinking being, this is mostly handy for desktop, and desktop tends to keep moving forward
<mvo> zyga, jdstrand still in a meeting - but if we have dbus in the hot path of starting snaps we should probably get some sense how fast/slow this is, i.e. if it makes starting snaps slower
<jdstrand> anyway, just something for back of mind
<zyga> given that this is supported in 16.04 I think it's a good idea as-is
<jdstrand> zyga: I was more talking if the uuid approach wasn't as great as it could be, but we aren't there yet
<zyga> jdstrand: ah
<zyga> I see
<zyga> jdstrand: I ran 1000 commands this way and they are not in sysfs anymore
<jdstrand> mvo: yes. we discussed that and agree it needs to be measured. there are options that might allow us to fork and move on and let the child do the dbus stuff asynchronously
<jdstrand> mvo: not sure how that would work with the current 'as of this minute transient unit via snap run' thinking, but yes, we agree it must be looked at
<zyga> jdstrand: we could send the method and perhaps not wait for the reply
<jdstrand> zyga: those were command that exited though. how about 1000 sleep 600 commands?
<zyga> jdstrand: but something of this kind, it's really a message dispatch
<zyga> jdstrand: you read my mind :)
<jdstrand> zyga: I
<jdstrand> meh
<zyga> jdstrand: though I did a sleep $i instead ;)
<jdstrand> (different keyboard)
<jdstrand> zyga: I'm assuming they exited that is
<zyga> jdstrand: yep
<zyga> jdstrand: while they are running you can see them
<zyga> https://www.irccloud.com/pastebin/KdUgFNrZ/
<jdstrand> zyga: yeah, send and forget is perhaps good enough. I wonder how that command can fail (and we therefore lose track of a pid)
<zyga> they even can be checked
<zyga> jdstrand: well, it's either that or wait :)
<jdstrand> zyga: well, if we fork, the child can wait and retry
<zyga> and if that fails?
<jdstrand> then we lose it
<zyga> sure but at some point: 1) you are failing but the app is running 2) the app is running untracked
<jdstrand> it could be seen as best effort in that regard
<zyga> yep
<zyga> though I would not go there initially, we need to see how it works still
<mup> PR snapcraft#2782 closed: snapcraft: introduce click-based YAML configuration file support <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2782>
<jdstrand> which by far most of the time would be great
<zyga> jdstrand: re cgroups, they are cleaned up as the scopes become empty
<jdstrand> zyga: right, so the thing exits, systemd sees the last one left, it removes the scope. makes sense
<zyga> jdstrand: there's one reason we might want to use a delegate though
<zyga> jdstrand: using a delegate we could have another leaf level
<zyga> jdstrand: and attach eBPF programs there
<zyga> jdstrand: perhaps we will have to for device cgroup
<jdstrand> zyga: I wonder how well that works with name=systemd since, aiui, they woul dhave to poll the cgroup.proc file rather than listen on cgroup.events in v2
<jdstrand> zyga: also for the cpu/mem discussion yesterday
<zyga> jdstrand: for cpu/mem it is relevant
<zyga> jdstrand: we cannot do that according to systemd rules
<zyga> jdstrand: you cannot write to anything that you are not a delegate of
<zyga> jdstrand: you can ask systemd to change properties of existing scopes/services
<jdstrand> zyga: but maybe we just use systemd apis to control systemd's cpu/mem handling?
<zyga> jdstrand: but not externally by poking at sysfs directly
<jdstrand> right
<zyga> yes, I think that's good if we can do that
 * jdstrand nods
<zyga> because the alternative is that we do use delegates for services
<jdstrand> exactly
<zyga> i.e. have a slice (not a scope)
 * jdstrand nods
<zyga> and put Delegate=snaps.slice
<zyga> and then inside that be system manager and handle things
<zyga> but I think ... that's systemd's job
<zyga> s/system/service/
<jdstrand> right. we are trying to play nicely with it and leverage it, so why not for this too?
<jdstrand> it does mean we are probably forever coupled to systemd
<jdstrand> it is imaginable for an alternative init to be used with what we have now (service management, timers, etc)
<jdstrand> even if that is a heap of work
<jdstrand> this talks us a bit farther down the systemd path
<jdstrand> takes*
<zyga> jdstrand: yes, but perhaps to good effect,
<jdstrand> I may not have slept enough last night ;)
<zyga> jdstrand: for instance killing hooks was sys-v init style
<jdstrand> zyga: oh for sure, just calling it out. not a blocker
<zyga> I think I'll wrap up for now
<jdstrand> zyga: a property I like about snap run is that the correct user is doing the dbus call
<zyga> it's 18:00 and I want to not repeat yesterday
<zyga> and you are right this won't land before the sprint
<jdstrand> zyga: a property I like about snap-confine is it is in a position to organize things rigidly
<jdstrand> zyga: food for thought
<zyga> hmm, now that I think of it
<jdstrand> zyga: this was *super* interesting and fruitful
<zyga> I think as a user I got a polkit prompt from the shell
<jdstrand> ohh....
<zyga> need to double check that
<jdstrand> that is important. that is cached
<zyga> wait, I'm dumb
<jdstrand> zyga: if snap-confine is back on the table, I think I feel quite strongly we need a helper and that be written in go
<jdstrand> (not saying it is)
<zyga> no prompt
<zyga> I was passing --system :D
<jdstrand> just for back of mind
<zyga> https://www.irccloud.com/pastebin/8wRREiYV/
<zyga> I'll double check that on ubuntu with v1
<zyga> same
 * jdstrand nods
<zyga> no prompt
<jdstrand> yeah, come to think of it
<zyga> so it can safely live in snap-run
<jdstrand> you wouldn
<jdstrand> t need polkit for --user (duh) and it is also ok for the unconfined user to call the apis that systemd exports. moving this down doesn't affect the properties of the resource limits...
<jdstrand> and snap run is pre confinement
<jdstrand> well, except when it isn't (snap calling snap)
<zyga> jdstrand: snap calling snap is semi-supported
<jdstrand> there might be more to investigate there
<zyga> jdstrand: I don't know what actually relies on it nowadays
<jdstrand> yeah
<zyga> jdstrand: and apart from that, it only works in devmode
<jdstrand> but we should understand the implications
<zyga> jdstrand: as otherwise snap-confine cannot reassociate with pid-1 mount ns
<zyga> jdstrand: so in strict mode it is refused anywa
<jdstrand> also, make sure that classic doesn't have any gotchas
<zyga> *anyway
<zyga> jdstrand: I _think_ it doesn't
<zyga> I mean, classic is not affecting this in any way as far as I can see
<jdstrand> zyga: yep, thanks so much for the work and discussion. we'll definitely pick this up, next week if not sooner
<zyga> jdstrand: tomorrow I'll focus on making snap-run do this via go-dbus
<jdstrand> zyga: sure. a classic snap can call sddbus itself. anyway, just thinking through pain points and things to document
<zyga> jdstrand: both in a standalone PR and in a wip PR with the snapd side using it
<jdstrand> zyga: have nice evening :) have a beer or do something fun. I think we cracked the overall approach :)
<zyga> I think so
<zyga> I don't know if I have any at home :)
<zyga> but I plan to see what the family is up to upstairs
<jdstrand> this might be cause to leave the cave
<zyga> thank you for your focus, attention and wisdom :)
<zyga> haha
<zyga> yes
<jdstrand> zyga: back at you :)
<jdstrand> (and thanks!)
<zyga> see you tomorrow or if we miss each other somehow at the sprint next week :)
<jdstrand> sounds good. take care
<zyga> o/
 * zyga EODs
<zyga> jdstrand, mvo: I wrote down the implementation plan on https://github.com/snapcore/snapd/pull/7722#issuecomment-551179377
<mup> PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
<zyga> I didn't include things like testing and measurement because I want to EOD but I agree those will happen
<jdstrand> zyga: for when you come back online. when thinking about the benefits of snap run, lets also consider what is required for device (and freezer) cgroup (equivalents) going forward. ie, perhaps that means snap-confine calling a helper is better to have a uniform approach going forward (or not, just don't want you to do snap run only to realize we maybe didn't think that all the way through with future work)
<zyga> just wanted to write it down while fresh
<jdstrand> ah, heh
<zyga> ha
<zyga> freezer can go away at some point via new mount api
<zyga> in pure v2 we should just really assume you have matching kernel and use new syscalls
<zyga> devices are more complex because they require (helper or not) eBPF attached to cgroup
<zyga> we cannot do that unless we ask for delegate unit
<jdstrand> that perhaps makes sense
<zyga> there's some special handling that happens then
<jdstrand> right
<zyga> because the eBPF programs systemd itself uses are added with different mode
<mvo> zyga: yeah, lets discuss more tomorrow, get some rest :)
<zyga> so that all programs run (aka multi mode)
<jdstrand> my ony point is if we know that, and we know what that will sorta look like, maybe we look at tracking through that lens
<jdstrand> anyway, enjoy your evening :)
<zyga> I think we can use helpers or bake it into snap* but it needs the delegate "hop" at some point
<zyga> but that's a good observation that we can align on this for other features
<zyga> mvo: yeah, :)
 * zyga really EOD now
<jdstrand> mvo: are you out of your meeting?
<mvo> jdstrand: yes
<jdstrand> mvo: hey, so that is a lot of backscroll. let me get you the most important thing for next week (outside of the comments in the PR we made in the last day)
<mvo> jdstrand: thats super nice of you, thank you!
<mvo> jdstrand: I will have dinner now but you can mail or /msg me the important bits if that is ok
<jdstrand> mvo: a) I think we want pedronis to review this and b) https://paste.ubuntu.com/p/7HdCp9p9K5/
<jdstrand> mvo: that is fine. enjoy dinner
<mvo> jdstrand: thank you!
<mvo> jdstrand: yeah, thanks for the pastebin, I think thats a reasonable answer. will you be in vancouver?
<jdstrand> mvo: meh, in the paste: /the probably/the problem/
<jdstrand> mvo: I will
<jdstrand> mvo: I have limited availability tomorrow (similar to today; front loaded the week with work)
<jdstrand> mvo: but in Vancouver next week and zy ga and I will continue to discuss this
<mvo> jdstrand: excellent!
 * Chipaca EODs
 * cachio afk
<mup> PR snapd#7724 closed: cmd/snap-confine: tracking processes with classic confinement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7724>
<blake_r> having issue where calculating the version of the maas snap is failing now with snapcraft
<blake_r> i now see in the logs
<blake_r> fatal: not a git repository (or any of the parent directories): .git
<blake_r> fatal: not a git repository (or any of the parent directories): .git
<blake_r> some reason the .git directory is no longer being copied into the VM
<blake_r> using just source: .
<blake_r> with no source-type defined
<blake_r> any ideas on why that is occurring now, when it didn't happen before
<blake_r> sergiusens: ^
#snappy 2019-11-08
<blake_r> sergiusens: nvm figured it out
<mborzecki> morning
<zyga> Hi
<zyga> Looking after kids
<zyga> Will start in about an hour maybe
<mborzecki> zyga: hey hey
<mborzecki> #7702 needs reviews
<mup> PR #7702: tests: adding fedora 31 to google-unstable backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7702>
<mborzecki> mvo: hey
<mvo> hey mborzecki
<pstolowski> mornings
<mborzecki> pstolowski:  hey
<zyga> back now
<zyga> so
<zyga> what shall I do
<zyga> mvo: after Vancouver I will have 4 swap days: for last Friday, for next Monday which is a holiday and two more for travel
<zyga> how will I ever use that :/
<mvo> zyga: we will find a way
<ogra> take 8 half days :P
<mborzecki> zyga:  come to work on monday and start your weekend on tuesday
<Saviq> cachio: hey, is there a focal image yet? could we have one, if not? :)
<cachio> Saviq, hey, there is not one yet, let me take a look
<Saviq> thanks :)
<Saviq> cachio: would it be easy to have a -devel one, like LXD has, so we don't have to play catch-up after a release?
<cachio> Saviq, there are few of them
<cachio> I am testing one right now
 * zyga is afk
<Saviq> cachio: yeah, but I mean one that is *called* ubuntu-devel-64
<Saviq> which is always what the latest devel image is :)
<Saviq> s/is/would be/
<cachio> Saviq, so, if you want to use the last image published the best way is
<cachio> image: ubuntu-os-cloud-devel/ubuntu-2004-lts
<Saviq> cachio: well, but that means for 2010 I'll have to change spread.yaml
<Saviq> could there be one like ubuntu-os-cloud-devel/ubuntu-devel ?
<Saviq> lxc has "ubuntu-daily:devel", which automagically points to the latest development release
<cachio> the one I sent is the last of devel
<Saviq> cachio: but it is explicit
<Saviq> cachio: upon 2004 release
<Saviq> that won't be the last of devel
<cachio> when they publish a new one spread will take that last one
<cachio> Saviq, currently there are 3
<cachio> daily-ubuntu-2004-focal-v20191022                     ubuntu-os-cloud-devel  ubuntu-2004-lts                               READY
<cachio> daily-ubuntu-2004-focal-v20191028                     ubuntu-os-cloud-devel  ubuntu-2004-lts                               READY
<cachio> daily-ubuntu-2004-focal-v20191029                     ubuntu-os-cloud-devel  ubuntu-2004-lts                               READY
<Saviq> cachio: I don't think you get what I mean :)
<Saviq> I don't want to explicitly call out 2004
<Saviq> just because that is current devel
<cachio> Saviq, ahh
<cachio> Saviq, the images are organized by release
<cachio> Saviq, these are all the images https://paste.ubuntu.com/p/383XJfp3Ty/
<Saviq> cachio: thanks, so there isn't a "devel" alias, meh :|
<Saviq> we'll deal with that, thanks
<cachio> Saviq, exactly
<cachio> Saviq, once every 6 months you need to make the change in the spread.yaml
<cachio> once 2004 is released you also need to update the image
<cachio> Saviq, move from ubuntu-os-cloud-devel to ubuntu-os-cloud
<cachio> Saviq, you could propose this "devel" image to the cloud team
<cachio> Saviq, seems to be useful
<cachio> for them it is just a name
<Saviq> cachio: will do, now I realize it's them building those images :)
<cachio> Saviq, :)
<mborzecki> off to pick up the kids
<mvo> mborzecki: I updated the TestRemodelSwitchCoreToBase test - this is passing now too, was incomplete simulation
<mvo> mborzecki: in the remodel-switch-core-to-base PR
<mvo> mborzecki: eh, s/PR/branch/
<popey> mvo: Chipaca i have nothing for our meeting today.
<mvo> popey: suits me, let's skip then
<mborzecki> re
<mborzecki> mvo: thanks!
<sergiusens> blake_r: hey, sorry for not getting back to you, just getting started today
<mborzecki> cachio: can you take a look at the changes in pushed to #7702 ?
<mup> PR #7702: tests: adding fedora 31 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7702>
<woutervb> Hi there, I posted a request to get an interface autoconnected some days ago (https://forum.snapcraft.io/t/autoconnect-juju-client-observe-for-cloud-status/14025) could I get some votes on this?
 * Chipaca breaks a take
<zyga> Chipaca break take # RPN
<mborzecki> and my isp suck today
<Chipaca> zyga: is the zygoon lab still a thing?
<Chipaca> zyga: in particular wrt armhf and/or arm64
<Chipaca> hmm
<Chipaca> ogra: any chance your qemu-virgil could grow a "be a raspberry pi" command?
<Chipaca> ogra: (I don't know how to get a working system from just qemu-virgil.arm :) )
<zyga> Chipaca: it can be
<zyga> Chipaca: but I turned everything off since I was not using it
<zyga> Chipaca: but I can prepare the arm64 nvidia board
<Chipaca> zyga: no worries, I'm trying the qemu approach now
<zyga> Chipaca: it's pretty good
<zyga> Chipaca: fast and lots of ram
<Chipaca> zyga: qemu, or nvidia? :)
<zyga> Chipaca: both :D
<Chipaca> when/if i get more than a black screen in qemu i'll agree
<zyga> Chipaca: let me know by EOD today please
<Chipaca> zyga: sure
<zyga> Chipaca: but no worries otherwise, I'll happily prepare it
<zyga> it's a hw prep day anyway
<ogra> Chipaca, i dont think it can run as Rpi ... it probably could run as beaglebone or begale XM ... properly implemented arm board in qemu are rare ... the best bet is always vexpress
<ogra> *boards
<ogra> but for vexpress we indeed have no core images
<mborzecki> ijohnson: mvo: trying to find the bug about opening the urls from a slack snap, it was a similar problem, windows would get associated with the slack application, rather than an already open firefox instance
<ogra> Chipaca, qemu-virgil.arm -machine help
<mborzecki> ijohnson: mvo: https://bugs.launchpad.net/snapd/+bug/1835024
<mup> Bug #1835024: Links triggered within most snap apps open in a separate browser session <snapd:Confirmed> <xdg-utils (Ubuntu):New> <https://launchpad.net/bugs/1835024>
<ogra> Chipaca, the raspi2 in there is very rudimentary
<ogra> (i.e. it gets you to boot half a kernel on a very hand-made image)
<ijohnson> Nice thanks mborzecki feel free to respond if you like before I get to it
<mborzecki> ijohnson: already responded there before ;) i did see thig happen on 18.04.3, it'd be great to double check on 19.04/10, iirc it seemed to work correctly there
<zyga> ah, I wanted to mention something to maciek
<mborzecki> another reboot, and bluetooth is back, right when i don't need it anymore
<mup> PR pc-amd64-gadget#23 closed: Add missing partitions and improve grub.cfg-recovery <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/23>
<b_b> hi
<b_b> i haven't been here for a while
<b_b> and i'm discovering base: items
<b_b> anyone know if i can't find a concise tutorial about upgrading a legacy snap ?
<b_b> i'm maintening this one : https://github.com/thetimelineproj/timeline_snap
<b_b> well, not a good start i'm still on ubuntu 16.04
<Chipaca> b_b: 1604 should still be fine
<b_b> 'k
<Chipaca> b_b: get snapcraft as a snap
<Chipaca> b_b: remove the apt one
<Chipaca> b_b: and then try to run snapcraft as you did before
<Chipaca> b_b: it's got a 'legacy' mode where it _should_ work just as it did, no (or minimal) changes needed
<Chipaca> b_b: but, as soon as you add a base: to your snapcraft.yaml it's no longer in legacy mode
<Chipaca> b_b: the good thing is, the non-legacy snapcraft, running on 1604, can build core:18 snaps
<Chipaca> base:core18 *
<b_b> i've found that sudo snap install --classic snapcraft could do the job to start
<Chipaca> b_b: right, that and multipass and you should be golden
<Chipaca> (multipass only for non-legacy mode though)
<b_b> so i have to apt remove snapcraft too ?
<Chipaca> b_b: i think otherwise it'll not be using the snap one
<b_b> 'k doing this
<b_b> thise base thing could finally make the timeline snap use the gtk theme \o/
<b_b> thx for the help Chipaca
<Chipaca> b_b: you'll want to connect to gtk-common-themes for that i suspect
<Chipaca> b_b: i don't think it's got to do with bases :) but i'm not an expert on that side of things
<b_b> 'm reading this https://snapcraft.io/docs/t/desktop-app-support-gtk/6834
<b_b> so the base is "just" needed
<Chipaca> b_b: ð
<Chipaca> well, it does say there are other approaches but that core18 is the recommended one
<mup> PR snapd#7675 closed: release: preseed mode flag <Preseeding ð> <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7675>
<b_b> 'xactlly
<b_b> so i still got snapd 2.40 installed from apt, is it ok ?
<Chipaca> b_b: what does 'snap version' say?
<b_b> snap    2.42.1
<b_b> snapd   2.42.1
<b_b> series  16
<b_b> ubuntu  16.04
<b_b> kernel  4.15.0-52-generic
<b_b> and snapcraft --version => snapcraft, version 3.8
<Chipaca> b_b: you should be fine then :)
<b_b> nice, still got to install multpass
<b_b> "However, if you have previously packaged snaps using LXD and have not used bases, you may have some initial transition issues, and it is good to know how to handle the new development environment in a seamless manner."
<b_b> â this is clearly my state :p
 * cachio lunch
<b_b> hmmm
<b_b> error: snap "multipass" is not available on stable but is available to install on the following
<b_b> let's go for a beta first
<Chipaca> :-) sage
<b_b> claro, i have to test the transition of the actual snap
<b_b> and bump it to latest 2.0.0 of the app
<b_b> don't want to pass hourrs on this, since i don't use the app as a snap but from source...
<genii> Hm
 * cachio eow
#snappy 2019-11-10
<b_b> hi there
<b_b> so, i've managed to upgrade my old snap package to the latest version which use python3 instrad of python2
<b_b> but it breaks ervery other build than amd64
<b_b> here is the changes i've made to my snap
<b_b> https://github.com/thetimelineproj/timeline_snap/compare/master@%7B1day%7D...master
<b_b> i can see in the failed build log mentions about python 2.7, maybe it's the cause of the failure ?
<b_b> sunday, should be better to ask on the forum ;)
<b_b> see U
