#snappy 2015-07-13
<dholbach> good morning
<fgimenez> good morning
<davidcalle> Morning
<mvo> ogra_: Hi, I looked into not using the py3 from the snappy-core image this morning by providing something better in snapcraft. but it seems like this is not trivial as there is no offical binary build for python . what did you do for py-snapper here?
<ogra_> mvo, nothinng, since snapcraft is now supposed to grow that we decided to drop py-snapper
<mvo> ogra_: ok - I was wondering if you had investigated if there are semi-official py3 builds we could use
<ogra_> mvo, but else i would just have re-used the nodejs install bits from node-snapper (without the npm parts)
<JamesTait> Good morning all; happy Monday, and happy Embrace Your Geekness Day! ð
<sergiusens> good morning
<sergiusens> mvo: the lack of a python binary is complicated, can't we debuild a custom one and use that with snapcraft?
<ogra_> why cant you use the one from the archive ?
<sergiusens> ogra_: it was hard to relocate without a lot of work from what I saw
<ogra_> weird
<mvo> sergiusens: yeah, its tricky, it seems building a custom one is indeed the best option, its actually not that terrible, took ~2min only on my box (which is relatively fast but not super fast)
<ogra_> mvo, and now build it for armhf :P
<mvo> ogra_: *cough*
<ogra_> also, isnt there a way to do a static build of the interpreter ?
<ogra_> we should perhaps just have a python3-static package in the archive that we can consume
<tbr> so, is it possible to build aargh64 images yet?
 * tbr started playing with his dragonboard
<ogra_> there are still packages missing i thinnk
<tbr> the linaro ubuntu desktop image is a bit 'special needs'
<Chipaca> sergiusens: ogra_: static micropython ftw
<ogra_> +1
<Chipaca> sergiusens: ogra_: https://micropython.org/
<Chipaca> or, well, https://github.com/micropython/micropython
<ogra_> is it fully py3 compatible ?
<Chipaca> no
<ogra_> sad
<Chipaca> mostly around things that don't make sense on a PIC
<Chipaca> but the unix port is zippy :)
<Chipaca> also i somewhat trust contributor #5
<Chipaca> anyway, that was in jest
<Chipaca> i need help with mir :(
<ogra_> you trust him ? really ?
<ogra_> :)
<Chipaca> well, somewhat, as i say
<sergiusens> Chipaca: he looks a lot like you! Might have stolen your identity ;)
<Chipaca> sergiusens: probably not me; i'm a lot greener and paler right now
<ogra_> is that a mir sideefect ?
<Chipaca> ogra_: yes
<Chipaca> ogra_: hazardous work environment
<Chipaca> ogra_: i should sue
<ogra_> heh
<Chipaca> ;-p
<ogra_> did kgunn have that working already ?
<Chipaca> ogra_: allegedly yes
<Chipaca> but only the deb2snap way
<Chipaca> that is, the failing is mine
<ogra_> tbr, btw:
<ogra_> The following packages have unmet dependencies:
<ogra_>  ubuntu-snappy : Depends: ubuntu-core-security-utils but it is not installable
<ogra_> E: Unable to correct problems, you have held broken packages.
<ogra_> (arm64)
<tbr> ogra_: ok, so I won't bother for now :)
<mvo> ogra_: this http://paste.ubuntu.com/11872034/ is mostly working for cross-build, but make install fails with some obscure ensurepip error, I'm not sure its worth debugging, its seems like a less than ideal path forward
<ogra_> mvo, well, why not have a statically built version in the archive so you could just consume the binary from there
 * ogra_ isnt a fan of building on-demand if we can have archive binaries
<mvo> ogra_: indeed, the archive is probably the best option
<Chipaca> kgunn: hiya
<Chipaca> kgunn: does mir always load xkb?
<kgunn> Chipaca: for that, might wanna ping anpok or alf in #ubuntu-mir
 * Chipaca goes with alf, because anpok isn't there afaict
<elopio> good morning.
<jdstrand> ogra_: oh, re ubuntu-core-security-utils, I just need to update it-- seccomp in wily now supports arm64
 * jdstrand does quick upload
<ogra_> whee !
<ogra_> not getting the image build failure mails every day would be so awesome :)
<mvo> jdstrand: \o/
<sergiusens> \o/ on no failure emails
<ogra_> well, they kind of were an reliable notifier that the build has run :)
<elopio> fgimenez_: after doing ifup, I'm able to ssh into rolling edge. But how are you running the tests?
<ogra_> elopio, whats the content of /etc/network/interfaces.d ? is there more than one file ?
<elopio> ogra_: only one, ens3.
<ogra_> ok
<sergiusens> ogra_: I think we established that that file needs to be created way earlier in the boot process
<ogra_> udevadm trigger --sysname-match=ens3 ...
<elopio> http://paste.ubuntu.com/11872571/
<ogra_> sergiusens, thats what pitti said on friday ... we could add it somewhere in the boot process
<ogra_> sergiusens, i fear we wont catch the actual uevent since that will likely happen inside the initrd where we cant yet bring up the interface
<ogra_> so i guess having the udev trigger added to some systemd unit is best here
<elopio> https://bugs.launchpad.net/snappy/+bug/1473838
<ogra_> oh !
<ogra_> shouldnt that have an "auto ens3" line ?
<ogra_> elopio, could you add such a line and check if it comes up after reboot ?
<elopio> I can. Lets see...
<fgimenez_> elopio, once the instance is reachable i execute them with the -ip flag, even for localhost
<pitti> yes, don't try to create config files earlier than the kernel detects devices, that's doomed to fail
<pitti> just re-trigger them
<sergiusens> oh, missing auto...
<sergiusens> pitti: that file is created after reading /proc/net/dev so I guess the kernel has seen it
<sergiusens> from reading*
<elopio> ogra: added the auto line, rebooted and it's up.
<ogra_> ha !
<ogra_> sergiusens, where do we add it ?
<ogra_> is that ubuntu-core-config ?
<sergiusens> ogra_: firstboot
<sergiusens> ogra_: we still have a potential race, or do we not anymore?
<ogra_> and where is the code for that ?
<ogra_> not sure we have a race .... we should try with auto added in advance
<sergiusens> ogra_: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/snappy/firstboot.go#L134
<sergiusens> ogra_: well that is surely a bug we need to fix :-)
<ogra_> i'm not sure there is a race
<sergiusens> ogra_: just edit the "data := ..." line
<elopio> mterry: why are you using camel case in snapcraft ?
<mterry> elopio, is that considered bad?  (I thought both it and underscores were valid python strategies)
<ogra_> sergiusens, https://code.launchpad.net/~ogra/snappy/fix-interfaces-file/+merge/264578
<elopio> mterry: well, bad is relative. But it doesn't follow pep8, so yes, it's bad :)
<elopio> https://www.python.org/dev/peps/pep-0008/#function-names
<mterry> elopio, I see that link, but the pep8 command doesn't warn about it... huh  (we run that with our tests)
<mterry> elopio, also I have this giant escape clause: "mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility."
<mterry> elopio, it's already the prevailing style in snapcraft!  ;)
<mterry> elopio, well I can switch if we want to
<sergiusens> ogra_: you should probably remove that changelog line, we are building them on release
<elopio> mterry: yeah, it's all relative to which snapcraft you are talking about... :) But if the idea was to use python because more developers will find it familiar, those developers will find the use of camelCase unfamiliar.
<mterry> sergiusens, "On subsequent uploads I think it only reads 'name' and 'version'." -- are you saying that if I have a snap at version A that depends on mir and ships a foo binary, when I update it to version B, which no longer depends on mir and ships a bar binary instead, those notices aren't picked up by the store?  That can't be right.
<ogra_> sergiusens, bah ... ok
<mterry> elopio, noted, I can put it on my TODO.  My poor pinky finger...
<ogra_> sergiusens, done
<elopio> writing pretty python is painful, I know :)
<ogra_> s/pretty//
<ogra_> :P
<elopio> I can help with this. I'm also not convinced about allowing the long lines either :p
<elopio> mterry: when I run the tests I get: http://paste.ubuntu.com/11872692/
<elopio> am I missing something?
<mterry> elopio, run on wily or add ppa:hardware-certification/public to your system
<elopio> ack.
<mterry> elopio, long lines I am more comfortable defending
<mterry> 80 chars was already limiting a decade ago
<mvo> ogra_: the goal is to have something like git-dch auto-build our changelogs for us :)
<elopio> mterry: yes, I'm not going to discuss about that. It's ok, I guess... I'll just have to control the freak-pep8-follower in me.
<ogra_> whatever that is :P
<elopio> mterry: and last pita comment, there's no README.
<mvo> ogra_: its pretty nice, it takes the git history and builds a debian/changelog file from it, once you get used to it, you never want to go back :)
 * ogra_ doesnt mind to use debian/changelog :) ... similar to how we use it in livecd-rootfs (thats actually my favorite way of managing a package)
<mterry> elopio, a good place to add a comment about the ppa for sure  :)
<ogra_> mvo, well, it involves git ... i still cant imagine that i "never want to go back" from git any time :)
<sergiusens> mvo: I love the git changelog magic, do things once and automate from there
<mvo> sergiusens: yeah, exactly
<mvo> ogra_: its not tied to git as such, a bzr-dch would be equally possible, just noone bothered writing one
<ogra_> heh
<ogra_> yeah, nobody bothers to write anything for bzr anymore :)
<sergiusens> ogra_: you need to fix the tests as well ;-)
<ogra_> pffft ... tests ... who does them anyway :P
<seb128> did we resolve the /boot enospace issue?
<ogra_> well, sergiusens prepared an MP that would ive /boot 512M
<ogra_> *give
<ogra_> which is a bit much on a 4G image i suppose :)
<seb128> right
<seb128> also that doesn't resolve the existing systems upgrade right?
<seb128> what do we do for those?
<jdstrand> seb128: hey, is this the right place to ask about ubuntu-personal? are there docs for generating ubuntu-personal images?
<sergiusens> jdstrand: ubuntu-device-flash personal rolling --channel edge --output personal.img
<sergiusens> jdstrand: if not on wily you need the ppa:snappy-dev/tools-proposed
<jdstrand> sergiusens: yeah, I tried that and got:
<jdstrand> failed to find user uid/gid
<jdstrand> generic-amd64 failed to install: unpack /tmp/generic-amd64709922737 to /tmp/diskimage222895386/system/oem/generic-amd64/1.4 failed with exit status 1
 * jdstrand -> steps into a meeting
<ogra_> jdstrand, you need u-d-f 0.26
<jdstrand> $ apt-cache policy ubuntu-device-flash
<jdstrand> 0.27-0ubuntu1
<ogra_> oh
<ogra_> hmm, works here
 * jdstrand really goes to meeting
<ogra_> (well, used to on friday )
<seb128> jdstrand, what sergiusens said
<seb128> I didn't try udf today, let me do that
<seb128> jdstrand, what ubuntu-snappy version do you have?
<stgraber> is there some documentation on how to make a compiled snap available for both x86 and arm?
<ogra_> stgraber, there are some example packages ...
<ogra_> iirc something like the xkcd webserver
<ogra_> it boils down to "have a wrapper script that calls uname to set your vars to the right arch dirs)
<stgraber> ok
<rsalveti> ogra_: let us know when you're able to promote the image to alpha
<ogra_> rsalveti, after landing meeting (30min)
<rsalveti> ogra_: thanks!
<elopio> stgraber: are you planning to add lxc templates for snappy?
<ogra_> sergiusens, do i need to do anything to trigger a new tarmac run on my MP ?
<sergiusens> ogra_: reapproval
<ogra_> ah
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~ogra/snappy/fix-interfaces-file/+merge/264578 | Approve: 1 (less than a day old)
<nothal> https://code.launchpad.net/~fgimenez/snappy/enable-all-for-remote-testbeds/+merge/264523 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~sergiusens/snappy/rollYourOwnCorePersonal/+merge/264405 | Needs Information: 1 (2 days old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-review-tools-reenable/+merge/264301 | No reviews (3 days old)
<nothal> https://code.launchpad.net/~fgimenez/snappy/failover-with-fake-update/+merge/264251 | No reviews (3 days old)
<ogra_> do we usually do that ourselves if there was an initial approval already ?
<sergiusens> ogra_: depends on the change, I did it just now fwiw
<ogra_> thx
<stgraber> elopio: not until apparmor supports profile stacking
<stgraber> elopio: for now what I'm working on is getting LXD into the snappy app store
<elopio> stgraber: I saw that, it's great.
<ogra_> rsalveti, elopio, have fun with 15.04/alpha image 4 for armhf and amd64 :)
<elopio> ogra_: thanks!
<beuno> so, if I want to install rolling on my bbb, is it 15.04 edge?
<elopio> beuno: it's rolling edge.
<elopio> sudo ubuntu-device-flash core rolling --channel edge --oem beagleblack --install=webdm --enable-ssh --output ubuntu-rolling-snappy-armhf-bbb.img
<beuno> elopio, thanks
<beuno> I looked everywhere online and in cdimage
<beuno> and couldn't find it
<elopio> beuno: https://developer.ubuntu.com/en/snappy/guides/channels/
<elopio> if that is not clear, please file a bug.
<beuno> elopio, right. I guess my confusion is that I was looking for an image to download
<beuno> instead of running a command
<elopio> beuno: yes, I think that's bad. Sometimes we use wget and sometimes ubuntu-device-flash.
<sergiusens> beuno: we don't do releases for rolling
<beuno> sergiusens, I understand releases. Why no images?
<sergiusens> beuno: we have images for 15.04
<beuno> sergiusens, sorry, it seems you're answering a different question?  :)
<sergiusens> beuno: 'Why no images?' needs some extra words for a more specific answer
<sergiusens> :-)
<beuno> sergiusens, why are we not creating images for rolling on a certain cadence?
<sergiusens> beuno: to avoid support questions for something that can break easily
<sergiusens> beuno: and the fact that we have no where to do that automatically ;-)
<elopio> IMO, the docs should only document u-d-f. Not cdimage.ubuntu.com.
<beuno> sergiusens, it's documented already, as elopio pointed out
<beuno> the latter I can understand
<beuno> I'm hoping to provide a service for that once all the parts are snaps
<elopio> hrm, I can't rollback on bbb from alpha 4 to alpha 3.
<rsalveti> elopio: hm, what is the issue?
<rsalveti> did it work with kvm?
<elopio> rsalveti: it worked with kvm. I'm collecting the serial log to see what it says.
<rsalveti> alright
<elopio> http://paste.ubuntu.com/11873742/
<elopio> I flashed #3, upgraded to #4, rebooted. Then rollback, and reboot.
<elopio> that paste is the serial console after I rebooted.
<elopio> rsalveti: ^
<elopio> spl_load_image_fat_os: error reading image args, err - -1
<rsalveti> elopio: it seems that might be a red herring
<rsalveti> elopio: and after the last reboot, which image are you running as host?
<rsalveti> it's system-b
<rsalveti> so would imagine image 4
<rsalveti> Starting kernel ...
<rsalveti> U-Boot SPL 2014.04-00015-gb4422bd (Apr 22 2014 - 13:24:29)
<elopio> rsalveti: yup. http://paste.ubuntu.com/11873784/
<rsalveti> so it tried booting the kernel, but it seems it just rebooted
<rsalveti> no kernel message at all
<rsalveti> elopio: what happens if you try to rollback again?
<rsalveti> let me get by bbb
<rsalveti> maybe sergiusens can give us a hand as well ^
<elopio> rsalveti: same thing. I tried three or four times. I end up in #4 every time.
<rsalveti> hm, that sucks
<elopio> it's weird that it shows no message saying why it didn't like kernel #3.
<rsalveti> yeah, it's like it rebooted while booting the kernel
<elopio> here's my test log, http://paste.ubuntu.com/11873826/
<rsalveti> adding earlyprintk to the kernel cmdline arguments might help
<rsalveti> yeah, setting up my beagle now to see
<sergiusens> rsalveti: elopio k
<sergiusens> rsalveti: alpha, right?
<elopio> sergiusens: right. flash alpha -1, update and rollback.
<rsalveti> updating still
<rsalveti> sergiusens: elopio: worked fine here
 * sergiusens is still dd'ing
<rsalveti> http://paste.ubuntu.com/11874036/
<rsalveti> elopio: either your kernel is corrupted or something similar
<elopio> I'll retry.
<rsalveti> try changing /boot/uboot/snappy-system.txt, append 'earlyprintk' after fixrtc
<rsalveti> elopio: check the free disk space at your boot partition
<rsalveti> but it worked fine here
<rsalveti> I did get one FSCK0000.REC at my vfat partition
<rsalveti> Syncing boot files is taking ages =\
<elopio> 53% used in /boot
<rsalveti> that's fine
<rsalveti> using 61% here
<sergiusens> rsalveti: rollback should not take ages though
<rsalveti> wonder why it's not the same
<rsalveti> sergiusens: no, that was an update for an image that was already there
<rsalveti> was trying to get back to image 4 with snappy update
<rsalveti> hm, one problem
<rsalveti> did an update to 4 after finishing the rollback (and booting into it), and now the kernel used at image 4 is the same from image 3
<rsalveti> Welcome to emergency mode! After logging in, type "journalctl -xb" to view
<rsalveti> system logs, "systemctl reboot" to reboot, "systroot@localhost:~# [   28.475311] libphy: PHY 4a101000.mdio:01 not found
<rsalveti> yay :-)
<rsalveti> [   19.017145] FAT-fs (mmcblk0p1): IO charset iso8859-1 not found
<rsalveti> [FAILED] Failed to mount /boot/uboot.
<rsalveti> since the kernel was the wrong one, it couldn't find the modules
<rsalveti> and exploded
<rsalveti> omg, cloud-init is so slow
<rsalveti> and now it's trying to automatically reboot again :-)
<rsalveti> snappy autopilot triggered a reboot to boot into an up to date system-- temprorarily disable the reboot by running 'sudo shutdown -c'
<rsalveti> The system is going down for reboot at Mon 2015-07-13 20:10:48 UTC!
<elopio> earlyprintk doesn't add anything to the logs.
<rsalveti> and yeah, kernel a and b are the same here
<rsalveti> let me see if I can reproduce this issue again
<elopio> I'm going to reflash #3.
<rsalveti> elopio: so still unable to boot?
<balloons> rsalveti, why the automatic reboot? I didn't realize snappy would do that. Is there something to switch that off?
<sergiusens> rsalveti: we usually see the iso8859-1 issue when we have filesystem corruption
<rsalveti> sergiusens: that is because it couldn't find a matching module
<rsalveti> because the kernel is wrong
<rsalveti> it booted image 4 with the kernel from image 3
<rsalveti> balloons: I didn't know we had an automatic reboot either :-)
<sergiusens> rsalveti: hmmm, did we backport anything wrt that?
<balloons> rsalveti, LOL.. I found that during the open house and was surprised to see it
<rsalveti> sergiusens: backport what exactly, the feature?
<rsalveti> or possible bug fixes around it
 * rsalveti reflashing image 3 again
<sergiusens> rsalveti: anything related to lp:snappy//partitions
 * sergiusens uses double / to avoid confusion with the series notation
<sergiusens> rsalveti: I bet this is just an untested path
<rsalveti> sergiusens: not sure
<rsalveti> sergiusens: right :-)
<rsalveti> it should be easy to reproduce, trying again
<rsalveti> flash 3 -> update -> rollback -> update -> boom
<rsalveti> sergiusens: how it finds out the kernel that needs to be copied over when doing the 'Syncing boot files'?
<rsalveti> that is the process that ended up copying the wrong kernel
<sergiusens> rsalveti: I bet that is the issue
<sergiusens> rsalveti: does that run on rollback?
<sergiusens> rsalveti: if so, that is wrong
<rsalveti> sergiusens: no, that was after I did the rollback, booted and called update
<rsalveti> so, updating from 3->4 again
<sergiusens> rsalveti: oh, bummer
<ogra_> rsalveti, the kernel messages are quiet because they go to the wrong console ...
<rsalveti> they are not always quiet
<ogra_> (we set two console= options pointing to different console devices)
<rsalveti> [    0.000000] Kernel command line: console=ttyO0,115200n8 root=/dev/disk/by-label/system-a init=/lib/systemd/systemd ro panic=-1 fixrtc rootfstype=ext4 rootwait
<rsalveti> not on bbb
<ogra_> oh
<sergiusens> rsalveti: I see the bug
<sergiusens> in the code that is
 * ogra_ votes for including vfat byy default in the core kernel 
<rsalveti> sergiusens: what is the issue?
<sergiusens> rsalveti: elopio https://plus.google.com/hangouts/_/canonical.com/bummer?authuser=1
<ogra_> (regardless of the issue i mean)
<rsalveti> elopio: if you can join ^
<elopio> trying to join.
<sergiusens> balloons: rsalveti http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/autopilot.md
<elopio> this "updating boot files" should have a progress thingy.
<rsalveti> sergiusens: https://bugs.launchpad.net/snappy/+bug/1474125
<ubottu> Launchpad bug 1474125 in Snappy 15.04 "Image got in a broken state after update -> rollback -> update (wrong kernel)" [Critical,In progress]
<rsalveti> elopio: yeah, open a bug for it
<elopio> I got the same error as the first time.
<rsalveti> now why the hell it can't rollback
<rsalveti> keeps trying to load the kernel and aborts eventually
<sergiusens> rsalveti: I can fix that easily but not without breaking the channel switching hack for upgrade testing
<rsalveti> it's like the kernel got corrupted or something, but nothing really changed
<sergiusens> rsalveti: fix the bug we just talked about
<rsalveti> right, maybe we can update the channel switch hack?
<rsalveti> elopio: ^?
<sergiusens> rsalveti: I need to think about all the test cases this breaks
<elopio> https://bugs.launchpad.net/snappy/+bug/1474126
<ubottu> Launchpad bug 1474126 in Snappy "failed to rollback from 15.04 alpha #4 to #3" [Undecided,New]
<elopio> sergiusens, rsalveti : what is the channel switch hack? Not sure what you are talking about.
<rsalveti> sergiusens: why are we mounting partition a (when booted with b) as writable?
<rsalveti> /dev/mmcblk0p2 on /writable/cache/system type ext4 (ro,relatime,data=ordered)
<ogra_> shouldnt that be a disk/by-label/ path for the device ?
<ogra_> why is there a /dev/mmcblk* at all
<rsalveti> might be mounted via label I guess?
<ogra_> well, it should also use the by-lable path in fstab
<sergiusens> elopio: rsalveti the mount something mvo wanted to be able to run snappy list --updates as non root
<rsalveti> actually it's not rw, just ro
<rsalveti> got it
<sergiusens> rsalveti: the 'as writable' you mean /writable/cache/system right?
<rsalveti> sergiusens: yeah, but it's not writable, mounted as ro :-)
<rsalveti> just the path that is confusing
<sergiusens> rsalveti: no arguments there ;-)
<elopio> I didn't know about snappy list --updates.
<elopio> sounds handy.
<elopio> for our current testing, it doesn't matter that sudo is required, as we can call sudo anytime.
<elopio> I suppose mvo had a reason for wanting that without sudo.
<sergiusens> rsalveti: elopio I have mapped a workable solution in my head that is minimally invasive (6 lines of code sans tests) which I will work on tonight
<rsalveti> sergiusens: cool
<rsalveti> elopio: yeah, something is quite broken with the rollback, failed again =\
<elopio> I'm starving, so I'll go and have lunch.
<rsalveti> checking the md5 and such now to see what happened
<elopio> ping me on telegram if you need me and I'll get back.
<rsalveti> sure, enjoy
<ogra_> sounds like no release today either then ...
<rsalveti> nops, need to get these bugs fixed first
<ogra_> yeah
<rsalveti> $ sudo snappy update
<rsalveti> another snappy is running, try again later
<rsalveti> hahah, what a weird message
<rsalveti> there is a snappy running around here
<ogra_> hide !
<balloons> sergiusens, ty for the doc.. However, if it's disabled by default then we have a bug in the image, as I certainly didn't enable it. So the docs or the implementation aren't quite right
<rsalveti> elopio: sergiusens: updated bug https://bugs.launchpad.net/snappy/+bug/1474126
<ubottu> Launchpad bug 1474126 in Snappy "failed to rollback from 15.04 alpha #4 to #3" [Critical,Confirmed]
<rsalveti> but basically the kernel/initrd got corrupted during the update process
<rsalveti> which explains why it works sometimes
<rsalveti> bbl, dinner
#snappy 2015-07-14
<sergiusens> elopio: rollback fails for you, right?
<rsalveti> sergiusens: fails for me as well
<rsalveti> sergiusens: check https://bugs.launchpad.net/snappy/+bug/1474126
<ubottu> Launchpad bug 1474126 in Snappy "failed to rollback from 15.04 alpha #4 to #3" [Critical,Confirmed]
<sergiusens> rsalveti: I have this fix I've been trying to test for a while now :-/
<sergiusens> rsalveti: first a bad sdcard with fully corrupted content, now this...
<rsalveti> right, this corruption issue seems to be quite normal
<sergiusens> rsalveti: oh, and not sure I ever noticed, but it doesn't look like vfat
<rsalveti> seems at the moment we call fsck for the vfat partition things break
<sergiusens> rsalveti: HARDWA~1.YAM
<rsalveti> sergiusens: that is vfat
<sergiusens> yeah
<sergiusens> rsalveti: don't we get long file names?
<rsalveti> that's an extension
<rsalveti> it seems fsck changed it
<rsalveti> it is supported by the original flash
<rsalveti> all good and so on, but at the time it runs fsck, boom
<rsalveti> the time it worked fine I had a FSCK... file in the partition
<rsalveti> FSCK0000.REC
<rsalveti> when it failed I didn't get this file, but the content changed
<rsalveti> not sure yet when we call fsck
<sergiusens> rsalveti: fsck is part of our new init?
<rsalveti> doesn't look like it
<rsalveti> maybe part of the boot process, done by systemd, not sure
<rsalveti> going to bed now, we can check tomorrow
<sergiusens> rsalveti: ok, then you don't get to test my fix
<sergiusens> :-P
<sergiusens> until tomorrow
<rsalveti> right :-)
<sergiusens> rsalveti: smart in using the dup files btw ;-)
<rsalveti> propose it anyway
<rsalveti> great
<sergiusens> rsalveti: I will, as soon as I can do some street testing
<rsalveti> alright, later man, have a good night
<sergiusens> good night
<fgimenez> good morning
<dholbach> good morning
<ogra_> yippie !!!
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image/+build/32370
<ogra_> we has arm64 images :)
<tbr> ogra_: oh. does that mean I'll be able to try something on the dragonborad?
<ogra_> tbr, well, no idea if it boots or how our bootloader setup on arm64 is at all
<tbr> (yes, I'm able to bring my own hw-adaptation. Just rebuilt the kernel to get usb-networking)
<tbr> the state of bootloaders on aargh64 is 'special'.
<ogra_> at least all packages build and enable rolling a rootfs, not sure i can say more about these images :)
<JamesTait> Good morning all; happy Pandemonium Day! ð
<ogra_> uuuuuh
<tbr> that's fine. I might give it a go, but will probably have some questions
 * tbr wishes JamesTait a merry Setting Orange
 * JamesTait sets his orange on the desk, to eat later.
<Chipaca>             sourceFiles |= set([os.path.join(root, d) for d in dirs])
<Chipaca> mterry:
<Chipaca> oh, no mterry
<rsalveti> morning
<Chipaca> mo'in
<rsalveti> ogra_: mvo: did you guys had time to check the email sergiusens sent yesterday?
<rsalveti> about bug 1474126
<ubottu> bug 1474126 in Snappy "failed to rollback from 15.04 alpha #4 to #3" [Critical,Confirmed] https://launchpad.net/bugs/1474126
<mvo> rsalveti: not yet, sorry, let me do that now. I was absorbed in snapcraft stuff, mterry has too many good ideas :)
 * mvo looks now
<rsalveti> mvo: haha, no worries :-)
<ogra_> hmm
 * ogra_ didnt notice a mail 
<ogra_> checking again
<rsalveti> ogra_: it seems sergiusens forgot to include you
<rsalveti> but was basically about this bug ^
<rsalveti> he created https://code.launchpad.net/~sergiusens/snappy/noUselessUpdate/+merge/264665 to fix 1474125
<rsalveti> but we can't test it easily because of bug 1474126
<ubottu> bug 1474126 in Snappy "failed to rollback from 15.04 alpha #4 to #3" [Critical,Confirmed] https://launchpad.net/bugs/1474126
<ogra_> right, i saw that
<ogra_> so as i commented on the bug, it could well be that fatwrite messes up the filesystem
 * ogra_ doesnt really trust it 
<ogra_> still so new and rarely used anywhere
<rsalveti> ogra_: yeah, looks like it
<rsalveti> ogra_: I did the update, then decided to run fsck.vfat and it was all good
<rsalveti> but once I rebooted, boom
<ogra_> i wonder if it is something simple ... like fatwrite not being aboe to truncate files ...
<ogra_> so you would have to delete them first
<ogra_> i didnt really find many bugs though ... i guess it is really rarely used
<rsalveti> ogra_: mvo: one other question I had, why do we keep /boot/uboot mounted all the time?
<ogra_> we shouldnt (i dont know why, ask jodh ? )
<mvo> rsalveti: I don't think there is a good reason
<ogra_> also, why dont we sync mount it ?
<mvo> I think we do that, no?
 * ogra_ doesnt see a sync option 
<mvo> the sync mount I mean
<rsalveti> /dev/mmcblk0p1 on /boot/uboot type vfat (rw,relatime,sync,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
<rsalveti> we do use the sync option
<ogra_> hmm
<mvo> ogra_: outdated initrd ;) ?
<rsalveti> let me remove the fatwrite piece and check again
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ mount|grep boot
<ogra_> /dev/mmcblk0p1 on /boot/uboot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
<ogra_> weird
<rsalveti> it seems that makes fsck.vfat unhappy and then it changes the fs
<ogra_> shouldnt be to outdated
<rsalveti> I was on image 4 (bbb)
<ogra_> (15.04 stable image 3 though)
<ogra_> but i thought that should have sync set
<mvo> ogra_: yeah, we set to sync a good while ago, in the 15.04 timeframe
<mvo> odd
<ogra_> right
<ogra_> i use the initrd from cdimage with removed modules
<ogra_> nothing else changed
<ogra_> rsalveti, are our tools able to remount /boot rw before operating on it ?
<ogra_> just switching it to ro might be a bit dangerous if they dont :)
<rsalveti> /boot/uboot is always rw
<ogra_> yes, it shouldnt
<ogra_> but if we make it ro, can the tools deal with it ?
<ogra_> hmm
<ogra_>                 else
<ogra_>                         bootdir="$ubootdir"
<ogra_>                         echo "$boot_partition $bootdir auto sync 0 2" >> "$fstab"
<ogra_>                 f
<rsalveti> I'd expect it to only be mounted when needed, since it's a vfat partition
<ogra_> so that is what it is supposed to write to fstab
<rsalveti> yup
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ grep uboot /etc/fstab
<ogra_> /dev/mmcblk0p1 /boot/uboot auto defaults 0 0
<ogra_> and that is what my fstab has
<rsalveti> /dev/mmcblk0p1 /boot/uboot auto sync 0 2
<rsalveti> bbb, image 3
<ogra_> rpi image 3
<ogra_> how weird
<ogra_> i wonder if systemd re-writes the fstab entry somehow
<ogra_> i dont see any explanation in the code why it would be "auto default"
<rsalveti> mvo: oh, and https://code.launchpad.net/~sergiusens/snappy/noUselessUpdate/+merge/264665 reminds me that we need to prioritize the work to update the upgrader before doing the upgrade
<tedg> Morning folks
<rsalveti> not super urgent, but would be good for us to put some hands on it later this month
<tedg> Chipaca, Were you able to get a libxcbcommon patch working?
<Chipaca> tedg: i'm not sure, right now
<Chipaca> um
<Chipaca> read: i have a working patch
<Chipaca> but i'm not sure the patch works
<Chipaca> is that clearer? i'm not sure :)
<tedg> Hmm, how do you know it's a working patch then? :-)
<mvo> rsalveti: indeed
<mvo> tedg: it builds, so we shipped it.
<tedg> \o/
<Chipaca> tedg: and the not sure is because http://pastebin.ubuntu.com/11877692/
<sergiusens> morning
<tedg> Chipaca, There seems to be reads from /home/ubuntu/thing/lib and /apps/qmlapp.sideload/0/usr/lib, seems there should only be one of those?
<rsalveti> sergiusens: morning :-)
<Chipaca> tedg: it is one, there's a symlink but i'll unify so it melts minds less
<tedg> If you're running confined, symlinks don't help.
<Chipaca> not running confined
<rsalveti> sergiusens: ogra_: mvo: yeah, if I remove the fatwrite command it all works fine
<mvo> hey sergiusens, good morning
<Chipaca> tedg: http://pastebin.ubuntu.com/11877734/
<mvo> Chipaca: hm, that looks like progress compared to yesterday, no?
<Chipaca> tedg: oh, wait, that one is using the wrong socket
<tedg> Chipaca, Ah, so to the next step :-)  Looks like it can't find the Mir socket. Probably not running as user 1000
<Chipaca> tedg: with the right socket: http://pastebin.ubuntu.com/11877746/
<tedg> Yeah, need to set MIR_SOCKET probably.
<ogra_> rsalveti, well, how do you switch ? by manually editing the file ?
<Chipaca> yeh, i'd commented it out, because with that it finds it but still can't connect (?)
<Chipaca> but it gets further ahead with it, so
<Chipaca> permission denied
<Chipaca> dammit
<Chipaca> http://pastebin.ubuntu.com/11877751/
<Chipaca> ^ with the right perms, and the right socket
<tedg> What Mir server are we using? Demo Server? System compositor?
<Chipaca> demo server
<Chipaca> which is what is in the mir package
<tedg> K, I don't think that it requires notification that we're going to connect. I think it stubs out the auth parts.
<Chipaca> tedg: the permission denied was on the socket itself
<Chipaca> tedg: but i don't know if you're talking about that :)
<tedg> Kinda both :-)
<tedg> Mir also does it's own auth depending on the server.
<Chipaca> ah, ok
<tedg> There are some MIR debugging environment variables, let me try to find them.
<Chipaca> the mir wrapper does take care of the socket and its permissions, but i'm running it directly myself to have the console output
<tedg> Well, you can get the console output from systemd
<Chipaca> i know i should be able to, but couldn't find it in journalctl
<tedg> Oh, my Mir branch was only 200K objects out of date...
<ogra_> rsalveti, so i'd really like to get rid of using fatwrite, i wonder if we could ship a uboot.env file wih a binary environment instead ... only containing the a/b variable, that way we can just run saveenv to switch it (if anything reads the snappy_stamp.txt file from userspace we need to handle that separately though)
<tedg> Chipaca, I think this is the useful variable: MIR_CLIENT_RPC_REPORT=log
<Chipaca> tedg: in the environ of the server, client, both?
<tedg> Chipaca, Client, though sever can also be used if we're confused still :-)
<tedg> Chipaca, Here is what I wrote down: MIR_SERVER_{DISPLAY_REPORT,COMPOSITOR_REPORT,CONNECTOR_REPORT,MSG_PROCESSOR_REPORT,SESSION_MEDIATOR_REPORT}=log
<mvo> sergiusens: thanks for your branch, I'm trying to reproduce this now
<Chipaca> oh yeah baby
<Chipaca> tedg: http://pastebin.ubuntu.com/11877784/
<mvo> rsalveti: is there anything unusual about your sd card? particularly big maybe?
<tedg> Chipaca, Huh, perhaps look at the server?
<Chipaca> tedg: that was on the server, fwiw
<tedg> Otherwise we're gonna need #ubuntu-mir's help
<tedg> Oh, try on the client.
<Chipaca> tedg: i get no extra input from the client with those, nor with MIR_CLIENT_ of same
<Chipaca> tedg: i've got to run, will read when i return
<tedg> Chipaca, K, I'll ping some central time folks when they log in as well.
<Chipaca> ta
<Chipaca> and i'll get the different bits and bobs up when i return, also, so others can reproduce
<sergiusens> mvo: np
<ogra_> pitti, could anything in systemd touch/modify fstab during boot ?
 * ogra_ really doesnt get how the /boot/uboot entry can end up differently in fstab than what was echoed into it 
<pitti> ogra_: read for sure; changing, I'm not aware of anything
<ogra_> i have this code ... echo "$boot_partition $bootdir auto sync 0 2" >> "$fstab"
<ogra_> and end up with:
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ grep boot /etc/fstab
<ogra_> /dev/mmcblk0p1 /boot/uboot auto defaults 0 0
<ogra_> i dont get how that can happen
<pitti> so that's not system-image writing fstab from a template and writable-paths or so?
<pitti> and is /etc/fstab writable in the first place?
<ogra_> no, it is the initrd script checking for uboot and then echoing this line into fstab
<pitti> so /etc/fstab is a symlink to /etc/writable/fstab or so?
<ogra_> to my knowledge thats the only place we handle /boot/uboot
<ogra_> fstab is a bindmount
<ogra_> into /run/image.fstab
<pitti> so perhaps your echo happens before the bind mount?
<ogra_> http://paste.ubuntu.com/11877845/
<ogra_> thats the code snippet
<ogra_> (it happens afterwards)
<ogra_> i dont see anything wrong with that code
<pitti> what does handle_writable_paths() do?
<pitti> it doesn't happen to assign fstab= to something else by chance?
<ogra_> it loops over the writable paths file and echos the lines as proper fstab lines
<ogra_> oh
 * ogra_ checks for uboot in writable-paths
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ grep boot /etc/system-image/writable-paths
<ogra_> (RaspberryPi2)ubuntu@localhost:~$
<ogra_> nope
<rsalveti> mvo: nothing unusual, no
<rsalveti> ogra_: we got logic from our userspace to check for that stamp file
<rsalveti> to then change the boot mode because it was successful
<rsalveti> since it boots with "try" first
<ogra_> rsalveti, right, so the uboot.env would have to add it to cmdline and the initrd would have to echo that into the stamp file
<ogra_> so that uboot.env still stays the master and writin only happens from the kernel vfat driver
<ogra_> and not from uboot
<rsalveti> right, I guess that's a way
<rsalveti> env + kernel cmdline + logic in initrd
<ogra_> yeah
<ogra_> just requires that all uboots we support can handle such an env
<ogra_> at least for upgradeable devices
<rsalveti> ogra_: are we shipping uboot with bbb?
<rsalveti> or are we booting the uboot that is already flashed in the board?
<ogra_> we are shipping a uboot.img
<ogra_> (and SPL too i think)
<rsalveti> that uboot is super old
<ogra_> hmm
<ogra_> i wonder if you guys actually boot the EMMc one
<rsalveti> easy to check
<rsalveti> ogra_: yeah, we're loading the spl and uboot that is already flashed in the emmc
<mvo> ogra_: I like your idea
<ogra_> aha !
<rsalveti> because to boot from the sd card completely you have to hold the button while turning on the board
<ogra_> rsalveti, so likely a different fatwrite then
<rsalveti> U-Boot SPL 2014.10-dirty (Dec 18 2014 - 22:07:26)
<ogra_> or wipe the MMC
<rsalveti> U-Boot 2014.10-dirty (Dec 18 2014 - 22:07:26)
<rsalveti> the one we ship
<rsalveti> right
<rsalveti> U-Boot SPL 2014.04-00015-gb4422bd (Apr 22 2014 - 13:24:29)
<rsalveti> U-Boot 2014.04-00015-gb4422bd (Apr 22 2014 - 13:24:29)
<rsalveti> the one we boot
<ogra_> well, less dirty at least :P
<ogra_> damn ...
<ogra_> didnt zyga's patch land that was supposed to enforce that ?
<rsalveti> ogra_: nops
<rsalveti> since the only way to force our bootloader is by not having the original one or by pressing the button
<ogra_> https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833
<mvo> hm, I did a fresh flash of my sd card some minutes ago and I have: "U-Boot 2014.10-dirty (Dec 18 2014 - 22:07:26)" in my boot message - but I did press the button in the past, will it remember that?
<rsalveti> maybe you wiped out your emmc
<ogra_> well, it is supposed to remember it
<ogra_> but i have no clue how that works
<mvo> both is likely
<rsalveti> don't think it remembers it
<mvo> ok
<rsalveti> at the moment you unplug power and plug it again, it should try emmc first again
<ogra_> so looking at zyga'S patch there ... it would still use the MMC uboot
<ogra_> but enforce loading the SD
<ogra_> so that wouldnt actualyl help
<rsalveti> no, when you run that you're already in uboot
<ogra_> right :/
 * ogra_ sees no way around this except wiping the MMC on first boto or some such
<ogra_> *boot
<ogra_> ... not great :/
<rsalveti> ogra_: or do your env dance suggestion you said
<rsalveti> I'm checking now if our fatwrite is better
<ogra_> well, will that help ? are we sure the bootx command behaves the same ... etc etc ?
<ogra_> its not only fatwrite
<ogra_> i ean, we can indeed use my suggestion to take fatwrite out of the equation ... but there are 6 months between the two uboots ... i would be surprised if we wouldnt hit other issues
<ogra_> *mean
<ogra_> (8 monts actually ... temporary math weakness :P )
<mvo> sergiusens, rsalveti: hrm, so I tried to test 15.04a3 -> 15.04a4 -> 15.04a3 but when I rollback I get the following error http://paste.ubuntu.com/11877942/ on boot. this is new, right?
<mvo> ogra_: -^
<ogra_> mvo, no, thats exactly the issue we are diuscussing
<ogra_> *discussing
<mvo> ogra_: thats the corruption?
<ogra_> fatwrite updates the file and trashes the vfat
<mvo> ok, cool
<ogra_> if the fatwrite from the older uboot is used
<mvo> so  â¦ I get this with "U-Boot 2014.10-dirty (Dec 18 2014 - 22:07:26)
<mvo> "
<rsalveti> yeah, so that shows that our uboot is busted as well
<mvo> I never see a different U-Boot boot string
<ogra_> yeah
<mvo> *weeeh*
<rsalveti> and another interesting thing, my ethernet doesn't work with our uboot
<rsalveti> it only works with the uboot provided by the board
<rsalveti> got bbb rev c
<ogra_> wow. thats weird
<rsalveti> mvo: that's the issue that elopio had for quite a while
<rsalveti> but that we were never able to find out why
<sergiusens> mvo: that's the second bug
<sergiusens> mvo: to test the fix for the first bug, resync the kernel and initrd from /boot ;-)
<elopio> good morning.
<mvo> sergiusens: :) just commented, I will look into adding a test now, but a cup of tea first :)
<elopio> fgimenez: looking at your failures, for some reason systemctl status docker_docker-daemon_*.service prints nothing for you on the stdout.
<elopio> I'll check what's going on.
<elopio> fgimenez: lets skip our meeting today, unless you want to discuss about something.
<mvo> sergiusens: honestly this fatwrite thing is really alarming to me shows that we really need some bbb auto testing
<fgimenez> elopio, ok np, i'll check the output of systemctl
<rsalveti> mvo: yeah
<rsalveti> on the good side plars is getting that going soon :-)
<rsalveti> but yeah, it's super bad
<sergiusens> mvo: to be fair, this is an untested code path
<ogra_> sergiusens, rolling back and upgradin is untested ?
<rsalveti> guess the main problem is when we're changing kernel versions
<elopio> fgimenez: I see, the *.service seems to work on 15.04 but not on rolling.
<rsalveti> when updating/rolling back with the same kernel version I think that's mostly fine
<rsalveti> but might still get broken I believe, and why elopio got it from time to time
<sergiusens> ogra_: for new kernels, yes
<ogra_> ah, it is our first new kernel ?
<ogra_> k
<fgimenez> elopio, yes, the output is from rolling/edge 107
<sergiusens> ogra_: I don't think so, but channel changing for testing this are all flawed IMO (unless it is indeed a channel change test)
<fgimenez> elopio, btw i have a branch for selecting the release, branch and revision for the tests almost done, will ping you when pushed
<elopio> fgimenez: nice.
<mvo> rsalveti: yeah, thats the good part, we have the tests and a plan and all that :)
<mvo> and thats probably what the erle guys also experienced from time to time
<ogra_> yeah
<elopio> pitti: do you know why this works on systemd 219 but not on 222?
<elopio> systemctl status docker_docker-daemon_*.service
<pitti> elopio: not off the top of my head; what does "not work" mean?
<elopio> pitti: on 219 it returs the status. On 222 it returns nothing.
<pitti> elopio: indeed; mind filing a bug about this, so that we can track this? (busy with something else right now)
<elopio> pitti: sure thing.
<pitti> elopio: thanks; I'll bisect it
<sergiusens> rsalveti: ogra_ if we revert the fix in uenv.txt, will we get something workable again (wrt fatwrite)?
<ogra_> sergiusens, no
<ogra_> that fix wont change anything
<sergiusens> ogra_: why did this only start now?
<ogra_> sergiusens, dunno, did we do this kind of test before ? (multiple updates and rollbacks)
<sergiusens> ogra_: yes we have
<sergiusens> ogra_: just the previous release was a 3 to 4 jump between releases
<ogra_> probably it only happenms if the fat content changes between two fatwrites
<ogra_> which now happens due to the kernel upgrade
<ogra_> (i'm really just guessing here ... fact is that it doesnt break if fatwrite isnt used at all)
<rsalveti> right, I believe it's because of the newer kernel
<ogra_> do we know if the uboot fat driver can handle long filenames  ?
<elopio> pitti: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1474426
<ubottu> Launchpad bug 1474426 in systemd (Ubuntu) "systemctl status globbing does not work on version 222" [Undecided,New]
<ogra_> we also started using the longer filenames for the kernel
<elopio> fgimenez: for now, I'll modify GetCurrentVersion to get a packageName.
<ogra_> (thanks to the version)
<pitti> elopio: thanks
<plars> ogra_: rsalveti: sorry, just now catching up after I got off a call - yes this is what I was complaining about a long time ago when trying to get BBB to boot properly - that we just accidentally boot snappy on it because we have a working uboot on emmc, and that uboot could easily break on the sd card if you don't force it to boot from there
<ogra_> plars, yeah, but there is no way for us to enforce SD ...
<ogra_> unless we wipe it
<ogra_> well, wipe the MMC
<plars> ogra_: there is one other way
<mvo> ohhhh?
<ogra_> how ?
<plars> ogra_: holding the s2 button down, or jumpering lcd_data02 I think, to gnd will do it
<ogra_> right
<plars> it forces booting from the sd (including bootloader)
<ogra_> or solder a wire ...
<plars> ogra_: well, a jumper wire is so much easier :)
<ogra_> not realy a softwareish solution :)
<ogra_> and we cant really destroy peoples MMC installs
<plars> ogra_: so my current plans for instrumenting bbb include this, and use s2 along with a stable image on emmc to flash the sd, then force booting onto the sd
<plars> ogra_: but if/when we get the recovery stuff, then we won't want to do that of course - and it becomes really critical that we don't break uboot
<ogra_> yeah :(
<plars> ogra_: but that makes me wonder, do we really need to change the bootloader that often? except maybe at the beginning?
<plars> ogra_: once it stabilizes shouldn't we be able to mostly leave it alone?
<ogra_> well, its not our bootloader that has issues ... it is the case where we boot the onboard one and use fatwrite from it
<plars> if you are updating it only ever 12-16 months, it's much easier to be super careful and make sure we don't break it before landing the change
<plars> ah
<plars> ogra_: why is it calling fatwrite from the onboard one?
<ogra_> the uboot scripts execute it to set the a or b partition in a file on the boot partition
<plars> oh, right
<plars> so this is just the nature of bbb, by default it tries to load the bootloader from emmc, unless you press the s2 button after poweron
<beuno> FWIW, in both my bbb
<beuno> I didn't need to press anything
<beuno> it boots from the SD if it's there
<plars> beuno: yeah, that's accidental and the source of the problem :)
<beuno> plars, this is why I don't do hardware  :p
<plars> beuno: I've been complaining about this for a while now, what's happening is that it's loading the bootloader off of your emmc
<plars> but the bbb default image is set up to check if there's something it can load from the sd
<elopio> pitti: other question, is there a way to wait for a service to be loaded and running?
<pitti> elopio: another unit should just have After=foo.service
<elopio> pitti: but not inside a unit. Like I install a package, and I want a command to wait until it's up before using it.
<pitti> elopio: other than polling "systemctl is-active foo.service" I don't know; usually invoke-rc.d waits until it's up already
<pitti> elopio: asking on #systemd (freenode) might be useful, perhaps I'm missing some kind of "wait-active"
<elopio> pitti: ack, thanks.
<elopio> is-active is already an improvement to what I have :)
<pitti> elopio: other than that a while/is-active/sleep loop would work for now
<pitti> elopio: that smells a bit weird -- you  have a package whose postinst auto-starts a service, but it's not up when apt-get finishes?
<plars> ogra_: if there's a known fix for this uboot bug, I'm sure rcn-ee would be open to adding it in his images, then we could point people who are running the default image on emmc to update to that?
<pitti> elopio: packages are expected to do that; i. e. that sounds like a bug in that .service, or in the package
<elopio> pitti: well, on snaps we don't have post-inst.
<ogra_> plars, well, the issue is to use fatwrite at all :P
<plars> oh
<ogra_> plars, i'm looking at a way to not use it at all
<elopio> I'm not sure if we can make something to wait on install.
<plars> ok
<pitti> elopio: ah, ok
<pitti> elopio: but what would start the shipped units then?
<pitti> elopio: whatever that ^ is, if it does "systemctl start", that's also synchronous, i. e. waits until it's started
<pitti> elopio: unless you call it with --no-block
<elopio> pitti: hum, so maybe that works. I'm just following this comment that says:
<elopio> "FIXME: sucks, needed because "systemctl start" does not wait until the service is really started."
<elopio> maybe that's not true anymore.
<pitti> that has never been true
<pitti> it might be true that the .sevice's Exec* commands do not wait
<pitti> i. e. do whatever you need to do to wait until the started service is up
<pitti> but then the polling loop doesn't help you either
<pitti> or it specifies a wrong Type= (simple instead of forking, etc.)
<elopio> pitti: I see. Oh, but here's another case where we do need to wait:
<elopio> if ssh starts before the service starts, then the test might run before the service is running.
<pitti> elopio: ah, this might be something to fix in autopkgtest
<pitti> elopio: i. e. not start before systemctl list-jobs becomes empty
<elopio> pitti: oh, I like that.
<plars> Is there a good description somewhere of pxe booting snappy?
<elopio> I see that the service has no type, which defaults to simple, which should wait until the service is up. So if it doesn't, is a package bug.
<elopio> fgimenez: are you ok if I remove all this waits, and see how it goes? If it fails, we report bugs to fix the packages.
<fgimenez> elopio, yes, much better. If we need to wait for something we could use goroutines and channels too
<elopio> fgimenez: I was trying to use a ticker to poll every 1 second, and made a mess instead :)
<elopio> I need to get better at parallelization.
<fgimenez> elopio, me too :) we could encapsulate all this logic somehow so that we can reuse, we'll need it again for sure
<elopio> fgimenez: btw there's this tiny branch that needs review: https://code.launchpad.net/~elopio/snappy/test_the_tests_tests/+merge/264170
<fgimenez> elopio, sure
<rsalveti> lool: why are we not using the u-boot from the archive?
<rsalveti> it seems we're using the one from http://people.canonical.com/~lool/snappy-bbb/
<ogra_> lool, did your patches land upstream (so that they would be in the wily archive uboot) ?
<rsalveti> sergiusens: how can I retrieve the content of the beaglebone oem snap from the store?
<elopio> ok, xkcd fails without the sleep. So I suppose there's a bug on the networking-service template.
<sergiusens> rsalveti: get it from te link
<sergiusens> rsalveti: https://search.apps.ubuntu.com/api/v1/package/beagleblack the anondownload one
<sergiusens> rsalveti: or just lp:snappy-hub and look for the snappy-systems branch (I would create a series, but I think asac is still owning the snappy-hub project).
<tedg> Uhg, so I installed the Mir demo server before setting up SSH.
<tedg> Is there a way to figure out the IP address KVM gave something?
<rsalveti> sergiusens: cool, thanks
<sergiusens> tedg: kvm only does lo by default, so you would need to redir anyways and not care about the ip
<tedg> I used virt-manager so it sets up the interface.
<sergiusens> tedg: I do alias kvm_snappy='kvm -m 1500 -redir :8022::22 -redir :8080::8080 -redir :4200::4200'
<sergiusens> tedg: oh, then I don't know :-)
<jobot> Hello, I have snappy on a beaglebone black using the image from here https://developer.ubuntu.com/en/snappy/start/#try-beaglebone. I have installed owncloud and would like it to use storage from a usb drive, but I cannot seem to mount the usb to have it writeable. Any guidance appreciated. Thanks
<elopio> jobot: I could mount my usb drive on bbb.
<elopio> and then I can use chown to give the ubuntu user write permissions on the mount.
<elopio> what's the problem you are getting
<elopio> ?
<jobot> Thanks. It's when I set owncloud storage to /mountlocation , it says that it's not writable
<jobot> I guess I didn't chown it. Are there any other mount settings required?
<elopio> jobot: I haven't used owncloud yet, so I don't know. But I can write to my usb.
<jobot> ok I will give it a go. Thanks!
 * rsalveti is still trying to clone git://git.denx.de/u-boot.git
<ogra_> did it grow so much the recent years ?
<rsalveti> ogra_: no, just super slow to clone
<rsalveti> 30kb/s
<ogra_> nice, feels like home :P
<rsalveti> hahah
<plars> someone picked up the other phone and messed up the modem? :)
<plars> elopio: is https://code.launchpad.net/~snappy-dev/snappy/selftest still the right place to look for snappy selftests?
<plars> elopio: or is there newer test code somewhere else?
<sergiusens> plars: it's all in trunk now
<plars> elopio: sergiusens: awesome, thanks, looking through the readme now... it looks like it may prompt me for a ssh password? does it try a default or can you give it one in advance to try?
<sergiusens> plars: don't think so, but I can't attest to that
<sergiusens> :-)
<plars> sergiusens: hmm, I can't even get it to run at the moment, but it's probably some go issue
<plars> it doesn't seem to work like the previous adt stuff did
<sergiusens> plars: build on x86 and run on arm? maybe missing some cross compile flags there ;)
<sergiusens> elopio should be able to help there
<plars> sergiusens: yeah, I'll talk to him when he's back around
<rsalveti> sergiusens: what removes snappy-stamp.txt?
<sergiusens> rsalveti: nothing
<sergiusens> rsalveti: is it being removed?
<rsalveti> sergiusens: that's the file created by u-boot, just wanted to know about the logic that handles it
<rsalveti> in the userspace side
<rsalveti> doc says it's undone by /lib/systemd/system/ubuntu-core-snappy.service
<rsalveti> which doesn't exist
<rsalveti> so someone removes /boot/uboot/snappy-stamp.txt
<sergiusens> rsalveti: it's not called ubuntu-core-snappy.service, that's one problem I guess
<rsalveti> right :-)
<sergiusens> rsalveti: there seems to be a job missing ...
<rsalveti> the file gets removed
<sergiusens> rsalveti: it's ubuntu-snappy.boot-ok.service
<sergiusens> rsalveti: oh, nvm, it's a task most likely and systemctl doesn't list those by defualt
<sergiusens> rsalveti: sudo journalctl -u ubuntu-snappy.boot-ok.service
<rsalveti> sergiusens: right, so it's snappy itself that handles it
<rsalveti> ExecStart=/usr/bin/snappy booted
<sergiusens> rsalveti: oh, yeah, sorry, forgot that was only obvious to 3 people :-P
<sergiusens> rsalveti: I fixed a bug there not long ago to avoid needless writes if you may recall
<rsalveti> sergiusens: yeah, I wonder if the problem is because the file size is 0 for the stamp file
<rsalveti> trying to write some data on it now
<sergiusens> rsalveti: it should never be zero
<rsalveti> not a lot of changes from upstream at the fat code
<sergiusens> rsalveti: oh, the stamp file, not snappy-system.txt
<sergiusens> got it
<rsalveti> fatwrite mmc ${mmcdev}:${mmcpart} 0x0 ${snappy_stamp} 0
<rsalveti> yeah, stamp
<sergiusens> rsalveti: snappy booted does not erase that iirc, it's the bootloader; this way we can rollback if the kernel is corrupted
<sergiusens> as an example
<sergiusens> rsalveti: nvm, http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/partition/bootloader_uboot.go#L203
<sergiusens> rsalveti: I forgot how this all works! lool you around?
<rsalveti> yeah, saw that
<rsalveti> sergiusens: didn't break this time with a file != 0
<rsalveti> let me build a new image with your fix so I can also test the rollback
<sergiusens> rsalveti: interesting, so if uEnv.txt fatwrote this with something > 0 it would be fine?
<rsalveti> sergiusens: that is what I'm trying to confirm
<rsalveti> sergiusens: elopio: give this a try, change /boot/uboot/snappy-system.txt
<rsalveti> with image 3
<rsalveti> change "fatwrite mmc ${mmcdev}:${mmcpart} 0x0 ${snappy_stamp} 0" to "fatwrite mmc ${mmcdev}:${mmcpart} ${loadaddr} ${snappy_stamp} 10"
<rsalveti> then do the update
<sergiusens> rsalveti: k
<sergiusens> rsalveti: will take a shortcut and format system-b
 * sergiusens waits
<rsalveti> yeah, tried twice and wasn't able to get the same corruption
<rsalveti> hm, ubuntu-device-flash is the one creating snappy-system.txt
<sergiusens> rsalveti: yes it is
<sergiusens> rsalveti: it's not updatable
<rsalveti> sergiusens: yeah, guess we can fix this all when we split the updater
<rsalveti> migrating 124 to alpha
<rsalveti> argh, there is one importer running
<sergiusens> rsalveti:  I can add a fix for u-d-f to at least have new images work correctly
<rsalveti> sergiusens: I'm waiting the next alpha to show up and will do a bit more testing
<rsalveti> but got a local change already for that
<rsalveti> importer takes forever lately
<rsalveti> wget https://public.apps.ubuntu.com/anon/download/canonical/beagleblack.canonical/beagleblack.canonical_1.8_all.snap
<rsalveti> HTTP request sent, awaiting response... 500 INTERNAL SERVER ERROR
<rsalveti> beuno: any issue with the store?
<rsalveti> yeah, unable to create a beagle image
<rsalveti> sigh
<sergiusens> rsalveti: it downloads fine here
<rsalveti> sergiusens: yeah, it's working again
<beuno> rsalveti, looking at outages, for future reference, noodles is usually up and running at this hour
<beuno> or just ask in #u1-internal
<rsalveti> alright, thanks
<rsalveti> was giving this error for about 10 minutes for me
<beuno> rsalveti, looks like a storm in the internal cloud
<beuno> being managed by IS
<rsalveti> alright :-)
<rsalveti> sergiusens: elopio: alpha 5 is now available
<beuno> (winds are picking up, might get a bit bumpier before it gets better)
#snappy 2015-07-15
<rsalveti> sergiusens: elopio: failed to me even when not empty, this bug sucks
<rsalveti> we need a smarter workaround
<sergiusens> rsalveti: what failed? snappy-stamp?
<rsalveti> sergiusens: the fat partition got corrupted even when the stamp is not 0
<rsalveti> so we need to go with ogra_'s solution
<rsalveti> to use env + kernel cmdline
<rsalveti> and do that under the initrd
<sergiusens> rsalveti: I guess we can have some logic in lp:snappy to carry this change
<rsalveti> right
<sergiusens> rsalveti: I was just coming in to propose and do something like that for the fatwrite thing
<sergiusens> rsalveti: I don't understand ogra's solution though; instead of a stamp file the env would be stored on disk? is that it?
<sergiusens> rsalveti: env being snappy_ab, snappy_mode and snappy-stamp's replacement ?
<rsalveti> trying to remember the details
<rsalveti> but we can try something different as long we're not writing from the bootloader
<rsalveti> we can read from the bootloader
<rsalveti> and pass over arguments via kernel cmdline, for example
<rsalveti> need to get off for dinner, try to propose something, otherwise we can talk tomorrow
<sergiusens> rsalveti: well we need to write from the bootloader when something fails at that level
<rsalveti> can't you just invert the logic?
<rsalveti> if the file is not there, it means the previous boot didn't work
<rsalveti> bbl
<sergiusens> rsalveti: I guess, and that is a much simpler fix
<sergiusens> rsalveti: but we can't reverse the logic at this stage
<fgimenez> good morning
<dholbach> good morning
<JamesTait> Good morning all; happy Gummi Worm Day! ð
<Chipaca> JamesTait: i'm starting to suspect your days calendar is subsidised in part by haribo
<JamesTait> Chipaca, now there's an idea!
<Chipaca> JamesTait: you could save *dozens* on your kids' uni tuition!
<ogra_> lool, *tickle*
<JamesTait> Chipaca, who said anything about the kids?
<Chipaca> JamesTait: I did. Just now. Pay attention!
<JamesTait> Yes, sire. Sorry, sir.
<lool> ogra_: hey
<ogra_> lool, did your patches for uboot ever make it upstream ?
<lool> ogra_: sorry was away yesterday, I see you were discussing some u-boot stuff with ricardo s
<ogra_> yeah
<lool> no idea, checking
<lool> it was a one line patch to the config
<ogra_> seems fatwrite is constantly corrupting the vfat ... we are looking of the newer uboot from the wily archive could perhaps help
<ogra_> *if the
<lool> ogra_: oh wow, that sucks
<ogra_> (and in general we'd like to base off an archive package)
<lool> I dont care about basing on archive TBH
<ogra_> well, you got everything in one central place there
<lool> ogra_: I dont see my patch merged upstream, but it seems to me the config includes were reworked in a way that enables this particular config
<lool> ogra_: we dont want to be the central place for firmware IMO
<ogra_> was it really just config ? i thought you needed some extra stuff for raw initrd
<lool> ogra_: no, just a config
<lool> ogra_: http://people.canonical.com/~lool/snappy-bbb/0001-Enable-SUPPORT_RAW_INITRD-to-load-initrd.img.patch
<ogra_> we want to be able to maintain the firmware for our supported imaes
<ogra_> and having that centralized makes it easier
<lool> nowadays, include/configs/am335x_evm.h includes include/configs/ti_am335x_common.h which includes include/configs/ti_armv7_common.h which defines CONFIG_SUPPORT_RAW_INITRD
<lool> ogra_: I dont think we want to maintain that firmware; also it's ok if we build it once and stop worrying about it
<ogra_> ah, cool. that was the thing i needed to knwo
<lool> I know this sounds extreme and contrary to our usual standards
<lool> but it's just make work where we have no value
<ogra_> well, we ship that firmware and we *wnat* to control it ... at least til we know it isnt bugy anymore
 * ogra_ needs new kbd (or new fingers)
<ogra_> for now we only want fatwrite to work or find an alternative though :)
<ogra_> my idea was to ship a uboot.env by default that carries the values, but that needs some hackery if we want to change them from userspace after boot
<lool> ogra_: do you have a recipe to trigger the fatwrite issue?
<ogra_> lool, doing multiple rollback and update actions on a BBB 15.04 alpha image
<ogra_> the prob is also that the BBB can fall back to the internal uboot ... which has fatwrite enabled but is 8 months older than what we ship
<lool> ogra_: FYI, upstream commit we care about is:
<ogra_> so might even have other bugs
<lool> commit 6440b807399c81c3670f7c9805c917308cfdd5d3
<lool> Author: Guillaume GARDET <guillaume.gardet@free.fr>
<lool> Date:   Mon Nov 3 14:26:17 2014 +0100
<lool> ARM: TI: Enable raw initrd support
<lool> (my patch was produced later but on top of the previous u-boot release
<ogra_> right
<lool> ogra_: what's the symptom of the fatwrite issue?
<ogra_> corrupt files on the vfat ... kernel or dtb usually
<sergiusens> morning
<ogra_> bug 1474126 is one of the current bugs with it
<ubottu> bug 1474126 in Snappy "failed to rollback from 15.04 alpha #4 to #3" [Critical,Confirmed] https://launchpad.net/bugs/1474126
<ogra_> rsalveti confirmed that he never gets the issue when removing fatwrite from the process and hacking the a/b stuff manually instead
<rsalveti> morning
<rsalveti> ogra_: latest uboot doesn't help
<ogra_> ah, i feared that
<ogra_> i didnt see anything about it in the backlog
<lool> so we've likely found an u-boot bug, or we have a misconception
<lool> how do we deal with it?
<ogra_> i think fatwrite is used so rarely that it still has many bugs
<sergiusens> lool: that is what is under discussion
<sergiusens> dealing with it
<rsalveti> ideally I'd like to not use fatwrite
<ogra_> lool, as i said, one option would be a uboot.env by default
<lool> I wonder whether it's by virtue of u-boot touching the MMC at all; that is, the abstraction of the MMC controller doing the writes might just result in corruption (dependent on the SD card brand) and then we need to go back to the drawing board
<rsalveti> either invert the logic or get to another solution
<ogra_> but snappy needs to be able to disassemble and change it
<sergiusens> last night rsalveti proposed inverting the logic (file not there for u-boot and file created by snappy)
<sergiusens> but that isn't backwards compatible
<lool> u-boot needs to be able to write some flag
<rsalveti> sergiusens: I don't think we can do any solution that is backwards compatible
<ogra_> and wont work for a/b
<lool> otherwise you have no u-boot retries
<ogra_> right
<rsalveti> because we can't change the file that does the fatwrite
<lool> we can drop the u-boot retries if that's more pain than use
 * ogra_ still thinks we should just use a uboot env var
<rsalveti> what I thought was inverting the logic and giving the u-boot var via kernel cmdline
<rsalveti> and touch the file from the initrd
<rsalveti> fatread is fine, fatwrite is the problem
<lool> rsalveti: this is not enough
<lool> rsalveti: I mean, it's less than today
<rsalveti> why?
<rsalveti> we only check for the file to know if the boot succeeded or not
<lool> how do you record that you've attempted the boot?
<lool> kernel panics, board reboots, you're back to the same bootloader logic, how do you avoid the boot loop?
<rsalveti> can't use save via env var in uboot?
<lool> there is no flash on BBB
<lool> so it's either over FAT, or we create a new u-boot environment partition on the emmc
<lool> we can even have redundant environment!  :-)
<lool> but that diverges quite a lot from upstream u-boot
<rsalveti> yeah
<lool> or we debug fatwrite / emmc issue and we find the issue
<rsalveti> the only thing I don't like about that is that we'd be enforcing a newer u-boot (or patch) for everyone
<ogra_> gah, what was that
<ogra_> the stamp file can actually be touched from initrd, but the snappy_ab var needs to be dynamic and to be set before uboot tries to boot anything
<ogra_> so the kernel commandline doesnt buy you much
 * ogra_ goes to find lunch
<sergiusens> ogra_: lool rsalveti to be fair, we don't have this stamping logic for grub based systems
<sergiusens> iirc
<rsalveti> sergiusens: what do we do there?
<lool> sergiusens: we dont?
<sergiusens> rsalveti: I'm not sure, wasn't involved (I think nothing), mvo do you know?
<lool> I thought we were writing to the grub environment and setting a/b from there
<lool> but never saw it
<sergiusens> lool: yes, a/b we set, but we have nothing similar to the stamp file
<rsalveti> we need a way to know that we should not continue trying to boot one specific kernel
<sergiusens> lool: rsalveti ah, snappy_trial_boot
<sergiusens> grubenv
<lool> the general problem is as follows: we want to demonstrate product-grade reliability across updates including kernel breakage, that relies on the bootloader being at least able to tell whether it's trying again or not; we're demo-ing on BBB
<lool> I see two ways out of this
<sergiusens> path uboot
<sergiusens> patch*
<lool> either we find another path to track the "retry"; for instance, we could use memory, but that's fragile
<lool> (e.g. trigger the reboot with some concept, much like "reboot to recovery" on android)
<lool> or we deliver a firmware which does what we want
<lool> and we drop the "upstream firmware" artificial constraint
<ogra_> well, we only need to move the backend off the vfat
<lool> which is just a constraint we're imposing on ourselves to be good citizens
<ogra_> i.e. into a uboot var
<lool> ogra_: that's fine with me, but then we need to use a patched bootloader to do this
<ogra_> why is that ?
<lool> sergiusens: so GRUB does implement the logic? good to know
<ogra_> i thought uboot can generally use env blobs
<lool> ogra_: hmm, perhaps it does support a raw environment at a fixed SD card offset, that might be a solution
<lool> another solution of this kind to consider is to ditch u-boot in favor of edk2
<ogra_> lool, well, more a blob file
<rsalveti> I think it supports that
<ogra_> lool, like on the rpi
<rsalveti> ogra_: a blob file in a fs or in an offset?
<lool> ogra_: a blob file might be more reliable, but not sure
<ogra_> it doesnt have any requirements on the partitioning
<lool> I guess u-boot *might* be clever enough to overwrite the same blocks when updating the env file
<lool> but this might also be equally unreliable
<ogra_> you can use saveenv in the uboot script
<ogra_> it will properly update
<rsalveti> but where would we save the blob?
<lool> ogra_: the question is whether it's any reliable
<ogra_> in uboot.env o the vfat
<ogra_> *on
<lool> if it's replacing an unreliable solution with another unreliable one, it's not a good deal IMO
<rsalveti> right, but not sure if that is reliable
<rsalveti> still writing in the fat partition
<ogra_> i thinnk it is as reliable as the uboot env is in general
<ogra_> as long as we can safely load that blob file we are fine
<lool> rsalveti: perhaps we can just add a sync/flush in the u-boot logic to shrink the window where the fs is getting corrupted?
<rsalveti> I don't think it's a sync problem
<rsalveti> but we can try
<lool> rsalveti: you sync ;-) it's an actual bug in the fat logic?
<lool> that would be worth fixing in any case
 * lool notes that everyone focuses on u-boot since I agitated the edk2 broom
<rsalveti> yeah, just that this is holding our stable release
 * ogra_ already proposed to switch arm to grub yesterday 
<rsalveti> but, we're not going to be able to update the bootloader anyway
<ogra_> :P
<rsalveti> so I believe we just release the stable image and try to fix the uboot issue
<rsalveti> lool: what do you think?
 * ogra_ wonders if thats not actually to serious to release with it 
<lool> rsalveti: I think it's a fine way forward given the other things we need to think about
<lool> is this only hitting BBB/omap platforms?
<lool> I wonder whether it would affect the pi2
<ogra_> lool, we dont support upgrades/rollbacks on any others
<lool> right
<ogra_> so no way to test
<lool> I personally like to think we will move to UEFI and replace this with the GRUB logic entirely
<ogra_> even on armhf ?
<ogra_> (who would be doing that grub port? )
<rsalveti> ogra_: lool: problem is, we can't update the bootloader
<rsalveti> we don't have support for that
<rsalveti> so even if we find the fix, we'd need someone to manually update it
<rsalveti> or we add enough logic to handle that
<rsalveti> which is kind of separating the upgrader from snappy
<lool> rsalveti: let's do a bootloader update snap
<rsalveti> that's kind of the upgrader snap
<lool> we could call it update-manager.deb
<rsalveti> because we want to update the upgrader before doing the upgrade
<rsalveti> to work around issues in the upgrader code
<lool> rsalveti: well I think it's ok to say "we had a critical issue with BBB reliable updates; we recommend you dump+restore your installation as follows" with 16.04
<ogra_> well, one of the lessons we learned with the pandaboard is that we should definitely be able to update the bootloader :)
<ogra_> i wonder why we make the same mistake again
<lool> but we need a working solution :-)
<rsalveti> ogra_: right!
<rsalveti> and why did we decide to not be able to update the snappy-update uboot script
<rsalveti> we can have bugs anywhere
<ogra_> because it is dynamically created by udf today
<ogra_> but i guess it could just move into the snap
<rsalveti> right, which is bad
<rsalveti> so will send an email saying we're holding up the stable image until we are able to identify a fix for the bootloader
<ogra_> going with an env blob would enable us to actually drop all these files and have vars instead
<rsalveti> ogra_: maybe something you can experiment
<ogra_> yes
<mvo_> grub uses the grubenv which is a magic file that can be written from grub
<ogra_> right, uboot.env would be the same
<mvo_> and there we do the same try-dance
<ogra_> the prob is that we need to touch the stamp after boot
<ogra_> so something in userspaxce needs to be able to modify the blob file
<mvo_> ogra_: yeah, grub has a save_env function for this
<sergiusens> rsalveti: ogra_ in rolling snappy-system.txt can be updated fwiw
<ogra_> how does that work outside of the grub env ?
<sergiusens> rsalveti: ogra_ just needs to go into the oem/gadget snap
<ogra_> uboot has a saveenv command too ... but that only works inside uboot
<mvo_> ogra_: oh, that works in both grub itself and the grub binary afaik
<sergiusens> ogra_: shouldn't fw_saveenv work?
<ogra_> it might
<mvo_> ogra_: the implementation seems to be very simple, its a static 1k file, and it will simply update that, i.e. no grow/shrink and no filesystems like zfs where stuff might explode (or is checksumed)
<mvo_> that might explain why btfs and grubenv might be problematic
<ogra_> yeah
<ogra_> thats the idea for uboot.env too
<mvo_> the alternative idea? or the idea behing fatwrite?
<ogra_> the idea to replace fatwrite
<ogra_> theoretically we could even get rid of snappy-system.txt with that
<mvo_> ogra_: cool. if it works the same way as grub we could write a small helper that modifies the file making the same assumptions as grub
<ogra_> yeah
<mvo_> ogra_: i.e. no grow/shrink etc
<ogra_> i guess thats the missing bit atm
<ogra_> (beyond proving that the blob on top if a fat doesnt corrupt things as well :P )
<ogra_> (i assume it doesnt, but this indeed needs testing)
<rsalveti> ogra_: alright, sent the email, on you now :-)
<ogra_> heh, ok
<mvo_> ogra_: writing the helper should be straightforward, aiui, the cluster size in fat32 is at least 2k so as long as thats enough we should be able to do the same as grubenv is doing in a single fat32 cluster
<mvo_> ogra_: but let me refresh my memory by looking at some actual documentation :)
<ogra_> mvo_, well, the uboot binary blob is a text file with uboot hearder afaik
<ogra_> we'd just need to remove the header and can edit it ... then re-add the header
<ogra_> or use fw_saveenv ... but i have to look if thats still working with current uboot ...
<mvo_> ok
<sergiusens> ogra_: last I tried fw-saveenv wasn't working for me and lool gave me a fancy explanation
<sergiusens> rsalveti: I say we delay release until this is fixed so new installs have a working solution
<sergiusens> reduces the possible affected surface
<ogra_> can we actually change uEnv.txt in the snap (wwill it be upgraded ?)
<ogra_> since that has the logic to read snappy-system.txt ... so even if we cant update that file in 15.04 we could just leave it around but not use it anymore
<sergiusens> mvo_: thanks for those tests! where/how to insert the mock partition thing was why I took so long
<sergiusens> ogra_: in rolling yes
<sergiusens> ogra_: in 15.04 no, but I can backport a fix
<ogra_> sergiusens, ah, what *can* we updae in 15.04 ?
<sergiusens> not going to be straightforward due to all the refactoring that happened though
<mvo_> sergiusens: no problem, thanks for finding the issue, that was the hard part
<rsalveti> sergiusens: yeah, already sent an email saying we're delaying the release
<longsleep> i just saw that email, how is fatwrite related to the base image? Is this not a u-boot issue?
<longsleep> i mean, i had to backport basically the whole fat driver for the ODROID u-boot to get rid of corruption.
<ogra_> longsleep, well, fatwrite is only used for the rollback/update logic of the core system... yes, it is a uboot issue
 * ogra_ lols ... 
<ogra_> so Commodore sells phones now
<ogra_> they dont look like breadboxes !
<longsleep> ogra_: yes - so i fail to see how it is related to any release of the base system. U-Boot is specific to the hardware is it not?
<ogra_> longsleep, we ship our own uboot on the SD
<longsleep> ogra_: Ok - but specific for the BBB right?
<ogra_> specific to any of the debvices, yes
<ogra_> *devices
<ogra_> (every image ships a device specific uboot)
<longsleep> ogra_: and that u-boot does not have the latest fat drivers?
<ogra_> it does, but still causes corruption on the BBB
<longsleep> mhm
<longsleep> i see
<ogra_> and we want to get rid of the fatwrite bits altogether
<longsleep> that sounds good - it gave me lots of trouble :)
<ogra_> the plan is to have a uboot env in a file instead
<longsleep> If it helps, check if the u-boot really has all the commits i merged in https://github.com/longsleep/u-boot-odroidc/commits/master
<ogra_> so that we can use vars and saveenv instead ...
<longsleep> i hope very much that these commands are not some "rather" new feature of u-boot :)
<ogra_> no, the oldest ones :)
<jdstrand> elopio: hey, in the title and description of 1474658 I think you at times mistyped 'hello-world-fwk' (which doesn't exist) for 'hello-dbus-fwk' (which does). not saying anything about the bug, just saying that reading the report is confusing because of that
<elopio> good morning,
<elopio> jdstrand: yes, at first it was my fault for mistyping it.
<elopio> then it turned out to be a real bug. I forgot to update the title.
<elopio> from fgimenez reply, I suppose that the result of search should include the origin.
<elopio> but I'm not really sure why it works for hello-world without origin.
<jdstrand> elopio: I think hello-world has an alias in the store
<elopio> mmm, that would make sense. So I think I would like to see the origin as part of the name in the search output.
<Chipaca> tedg: you around?
 * ogra_ is waiting for him too ... for a phone question
<Chipaca> ogra_: cantÃ© pri!
 * Chipaca has no idea how to translate that
<Chipaca> ogra_: something like "dibs!"
<elopio> the translation to costa rican would be: "Â¡primas!".
<Chipaca> elopio: i'm not sure where your female cousins come into it, but it sounds like a lot of fun.
<elopio> puzzles me too. But I just do as the rest.
<Chipaca> elopio: this might help:
<Chipaca> http://buscon.rae.es/drae/srv/search?id=v0qAEEf8TDXX2jytCRSE|aiJ5mOGSxDXX2KPmUIAG
<Chipaca> elopio: 20 definitions for "prima"
<elopio> the beauty of spanish... ^_^
<elopio> fgimenez: a little style comment, we probably shouldn't use "get" in the function names:
<elopio> http://golang.org/doc/effective_go.html#Getters
<tedg> Then how to you get a getter for Git without a getGitGetter function?
<tedg> mvo_, ICANHAZ your libxcb patch?
<elopio> tedg: you just can't. go fmt will refactor it to panic.
<tedg> elopio, That's it, we need to stick with Bazaar then.
<elopio> +1.
 * ogra_ notes that tedg is hiding from the #ubuntu-app-devel channel
<tedg> Oh, didn't realize there was one...
<mterry> elopio, why are the tests in snappy under a directory called "_integration_tests"?  underscore feels weird
<ogra_> upperscore is harder to type :P
<elopio> mterry: I found no way to exclude them from the unit test execution.
<mvo_> tedg: Chipaca probably has a better version if not I can pass you my original quick diff
<Chipaca> 1 sec
<mterry> elopio, huh.  you mean "go test" was finding them?
<Chipaca> uh, why did i just edit this :-/
<Chipaca> tedg: http://pastebin.ubuntu.com/11882626/
<tedg> Chipaca, Thanks!
<tedg> meep
<elopio> mterry: yes, go test ./... ignores the dirs beginning with underscore.
<elopio> but this was just a quick solution.
<mterry> elopio, cool, just curious  :)
<mterry> thanks for explaining  :)
<elopio> maybe we can put all the unit tests in the unit package, and use -filter unit
<elopio> or maybe we can extend gocheck filter to have a -x.
<Chipaca> tedg: point that variable to somewhere you've copied /usr/share/X11/xkb to
<Chipaca> and it's mvo's patch; the only difference is that he said FOO, and I changed it to the more confusing XKB_CONFIG_ROOT
<Chipaca> was tempted to make it XKB_RENDER_ENGINE
<tedg> I'd really like it to be XKB_MEEP
<Chipaca> tedg: XKB_MEEP_MEEP, and we call it the roadrunner patch
<elopio> mterry: about functional tests for snapcraft, do you think we should install the snap in a snappy machine and run the binaries? or just check that the generated file seems correct?
<mterry> elopio, so far I've just been testing that the files we would put in the snap are fine.  But I can see the virtue in installing the snap in a snappy machine.  Maybe not for all tests, but certainly when testing our final "make a snap" step
<elopio> mterry: shouldn't be hard, in this case we just need to deploy a rolling edge snappy, and adt-run takes care of that. I'm thinking about running the examples, at least.
<mterry> elopio, we have some integration tests already, using plainbox (in tests/plainbox)
<mterry> elopio, but nothing that uses adt-run yet
<mterry> elopio, for tests that want to download big things (like the go1.4 binary tarball)...  how do we best do that in an automated way?
<elopio> mterry: many options. But I'm inclined to run the big download at least once. So maybe do unit tests for all the parts faking the download, or one integration tests using a local source. This will be run on each MP.
<elopio> and then we can have a daily suite that does the real thing, hitting the real server.
<ogra_> rsalveti, sergiusens, mvo_, so we seems to be missing a setting in the BBB binary ... #define FAT_ENV_FILE		"uboot.env"
<ogra_> that allows it to boot the env blob
<ogra_> (it is funny, since most other TI targets actually have it set by default ... just am335x_* doesnt)
<ogra_> oh man
<ogra_> http://lists.freebsd.org/pipermail/svn-ports-head/2014-December/079896.html
<ogra_> -+#define FAT_ENV_FILE		"uboot.env"
<ogra_> ++#define FAT_ENV_FILE		"u-boot.env"
<ogra_> srysly !
<ogra_> (yay for standadized names :( ... )
<sergiusens> ogra_: gotta love forks :-)
<ogra_> yeah... i'm more into spooning than into forking usually though :)
<ogra_> lool, so where exactly is the source we use for our uboot on the BBB
<lool> ogra_: it's 2014.10 + the patch I linked earleir
<sergiusens> ogra_: comes from that readme I gave yesterday
<ogra_> lool, ah, mailine ?
<ogra_> *main
<sergiusens> ogra_: http://people.canonical.com/~lool/snappy-bbb/build
<ogra_> ah, i only had seen the README :P
<mterry> mvo_, I mentioned in an MR that I think assemble() should only wrap the binaries that are mentioned in package.yaml.  I think I'll make a merge for that, FYI
<mvo_> mterry: yeah, that makes perfect sense
<mterry> mvo_, when we move the original executable out of the way...  do you like ".real" as a suffix?  or ".snapcraft"?  Or ".orig" maybe?
<mvo_> mterry: hm, no strong opinion, .snapcraft is so specific it has the least risk of collisions :) but then,  we should protect against this anyway, I don't really mind. .real is good enough for me
<mvo_> (but .orig is also fine)
<mterry> mvo_, or we could make a new directory in the snap, snapcraft/ and put a wrapper in there, and modify package.yaml to point at our version
<mterry> But maybe other parts of their code have hardcoded relative paths to their executable
<mterry> But that should be fine...
<mterry> They'd already be running under the right env
<mterry> Well, .orig is less invasive for now
<mvo_> mterry: yep
<mvo_> mterry: silly question, how can I test inside ./snap ? would it make sense to generate the wrappers already in the stage where the ./snap is generated ?
<mvo_> mterry: I'm snappyfying libreoffice right now for bjoern :)
<mterry> mvo_, maybe?  I've used "snapcraft shell" to test inside stage/
<mterry> mvo_, are you kidding?  :)
<mvo_> mterry: I am - mostly, I use the deb plugin to see how far I can get with just that :)
<mterry> mvo_, for libreoffice, you'll almost certainly hit the hardcoded path problem
<mvo_> yeah
<mterry> mvo_, do we want to add ld_preload logic to snapcraft?  As an interim for the final bindmount/overlayfs solution?
<ogra_> jdstrand, did you notice the ML ? someone is asking about mounting his USB driver to extend the writable space ... do we have any story for such a use case yet ?
<ogra_> *drive
<mvo_> mterry: maybe as a option? its a pretty cool feature
<mvo_> mterry: just like you said :/ http://paste.ubuntu.com/11882956/
 * ogra_ notices elopio has an airtame too ... we need to talk the mir team into supporting that from the phone ;)
<jdstrand> ogra_: it needs to be handle by a storage framework (access to a shared resource). touch is developing one. snappy doesn't have one at this time
<mterry> mvo_, :(  hardcoded paths are pervasive
<elopio> ogra_: saviq offered on the forums to write an app.
<mvo_> yep
<ogra_> jdstrand, ok, i guess we need the same framework on both ... are the people designing that aware of this fact ?
<ogra_> iven the phone will switch to snappy eventually
<jdstrand> ogra_: or, snappy could define something as part of its FHS and then app-specific rules could be added for the external storage. basically, someone needs to work with the architects to define something
<ogra_> right
<jdstrand> ogra_: tvoss is designing it. he is on the architects team
<ogra_> would just be bad to have something on the phone that we have to throw away or re-write
<jdstrand> ogra_: I don't think snappy was explicitly mentioned. this was more of a user-driven interaction type of thing with content-hub
<ogra_> i assume it would be nice if we could at least provide some hack for users so their device gets into fstab somehow
<jdstrand> that with a change to the snappy FHS and we could create security policy for it
<ogra_> the guy asking actually only wants to use it in docker ... which i guess can be done via some configuration if the device is actually available or mounted
<jdstrand> that is my understanding, yes
<Chipaca> mterry: mvo_: hardcoded paths are pervasive, but we don't have to fix them all at once
 * ogra_ would also like to use owncloud on his rpi ... 
<ogra_> (with 1G writable space thats kind of pointless though)
<Saviq> elopio, yeah, I was even PM'ing with them for a bit about it but they went silent since
<ogra_> Saviq, well, is Mir even capable of doing such stuff ?
<ogra_> beyond vnc ...
<Saviq> ogra_, depends what you mean by "such stuff"
<ogra_> remote desktop ...
<ogra_> or desktop forwarding
<Saviq> ogra_, but, for what their mobile apps do (streaming content, not remote desktop), no mir support needed
<ogra_> (or phone forwarding)
<ogra_> ah
<ogra_> only content streaming, ok
<Saviq> ogra_, but Mir can do screen sharing, too
<Saviq> ogra_, the troublesome bit there is compression
<ogra_> well, i know it cant do anything like X11 forwarding ... or ssh X forwarding
<Saviq> airtame can't, either
<Saviq> airtame's a video streamer, is all
<ogra_> doesnt that depend on what you feed it ?
<Saviq> the device itself is really just a h264 decoder
<ogra_> ah
 * ogra_ still hasnt used any of his airtames 
<ogra_> i have two
<ogra_> (one early adopter version)
<Saviq> ogra_, I did discuss compression with Mir folk before, and FWIW it should be possible to use hardware compression capabilities of the GPU
<Saviq> well, SoC
<Saviq> is what's used for camera video
<Saviq> s
<mterry> dholbach, heyo!  I found a weird typo I guess in snappy docs:  https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/  -- look at the "binaries" example.  The two examples use exec and name differently
<Saviq> in theory you could feed it your screen
<Saviq> and stream that to the airtame
<ogra_> yeah
<davidcalle> mterry, nice catch, thanks
<dholbach> mterry, very soon we'll have the docs auto imported :)
<ogra_> and everything will break :)
<davidcalle> ogra_, of course, but isn't this nice ?  http://i.imgur.com/jX4SSJs.png , http://i.imgur.com/qUlDv1q.png :)
<ogra_> sweet !
<davidcalle> mterry, fixed
<sergiusens> davidcalle: it sure is!
<mterry> davidcalle, dholbach: awesome, thanks
<Chipaca> i've got to go to the mechanic, will bbl
<Chipaca> tedg: any quesitons or blockers, telegram will work
<tedg> Chipaca, Cool
<tedg> Chipaca, Good luck :-)
<elopio> sergiusens: I like your proposal for map + Scan, but for the format compliance tests.
<elopio> what we are doing in the integration tests is closer to pattern matching: a user will ignore big chunks of text and care only about some lines. I find regexp and .* to express that nicely.
<elopio> We have a card for the format tests, where we will want to check every single line. I'll copy your comment in there.
<elopio> what do you think?
<elopio> fgimenez: before you go, can you please review https://code.launchpad.net/~elopio/snappy/test_go_install_framework/+merge/264666 ?
<elopio> that one blocks some of the others already approved.
<fgimenez> elopio, sure
<sergiusens> elopio: it's fine; scanning is also good to see how long a specific message takes to get on screen; but is leagues away
<elopio> sergiusens: for that I was thinking about gocheck's StartTimer and StopTimer to surround the Exec call. But you are right, that won't work if what we want is to check when the downloading message appears, or when does it end.
<elopio> Doesn't seem to be that far away, though.
<fgimenez> elopio, you are working on test_go_install_framework right?
<elopio> fgimenez: agh, no that's ready.
<elopio> I left the comment on the wrong branch.
<fgimenez> elopio, ok np :)
<elopio> fgimenez: it's ok if I delete the generated control files, right?
<fgimenez> elopio, sure, we should remove them
<elopio> ok, that makes it easier.
<plars> elopio: if you have a moment today, can you help me sort out how to run the snappy selftests now? I was running a snapshot of the older adt stuff in lp:~snappy-dev/selftests but I understand it's all in trunk now
<elopio> plars: yes! I wanted to meet with you after we got all the tests running in bbb, but we are close to that now.
<elopio> plars: take a look here: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/_integration-tests/README.md
<plars> elopio: I have a fully automated local setup still for automated provisioning and testing
<plars> elopio: just landed some more code to support that in a more flexible way, so you can specify how the device gets a hard reset, boot mode selection, and stuff like that through just a config change
<plars> elopio: that way once the hardware lands in the lab, we can easily support that
<elopio> plars: nice. And are we going to be able to choose the release, channel and image that gets flashed?
<plars> elopio: yeah, I looked at that, but I couldn't get it to work, getting stuff like this:
<plars> https://www.irccloud.com/pastebin/jqCr0J8s/
<plars> elopio: well, it's assuming you provide an image, so that's external to this process
<elopio> plars: you need to set up the go tree
<elopio> and export the env vars.
<plars> elopio: for now, I need to build the image outside and provide a url to download it from (preferably gzipped - downloading a 4GB image to bbb is *really* slow)
<elopio> that's explained on the main REAMDE.
<plars> elopio: yeah, I thought I had all that set up though... I'll look again, maybe I missed one
<plars> elopio: does this not run easily through adt anymore?
<elopio> plars: that sounds fine. We are generating the image, we would just need to uplaod it.
<plars> elopio: it seems like there should be an easy way to run this all from a script
<elopio> plars: it does run through adt. Easily, that's relative.
<elopio> plars: your go tree should look like /tmp/scratch/go/src/launchpad.net/snappy.
<plars> elopio: how would you run it through adt today? I didn't see a debian/tests or anything
<elopio> plars: once you get it set up as the root README says, and have autopkgtest installed, you can ./run-checks.
<kyrofa> seb128, how should I give the snappy scope .deb a test run on Ubuntu Personal?
<elopio> plars: we generate the adt-run control file on-the-fly. And pass the path as  an argument.
<seb128> kyrofa, build a daily image, boot it (vm or usb stick), mount / rw, install the deb, reboot
<elopio> plars: we can't really put the tests in debian/tests as they access the internet, and they require an snappy image. If we put them in debian/tests they will run in proposed migration, making a mess.
<elopio> plars: once we are able to specify this requirements in the control test-class, we could move them to debian/tests. Make a default control file that will have everything we want proposed migration to run.
<kyrofa> seb128, very good. I know you'll be leaving shortly. Assuming everything works okay, what are the next steps? Since the Ubuntu Personal seed pulls (I assume) from the archives, do I need to set it up to land in the archives somewhere?
<elopio> plars: anyway, we can meet whenever you want. I would prefer fgimenez to be around, but that would have to wait until friday.
 * Chipaca back
<elopio> if you prefer to do it earlier, we can just fill him in by mail.
<seb128> kyrofa, it needs to land in Ubuntu first, then to be added to http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/desktop
<plars> elopio: normally, I would use the ssh provider or similar for adt and run something like "adt-run --built-tree /tmp/scratch/selftests --output /tmp/results-0123 --- ssh -d -l ubuntu -P ubuntu -H 192.168.1.147
<elopio> plars: yeah, no, we had to wrap that in our own script because adt-run works fine for running, but not for provisioning.
<plars> elopio: the recent changes seem to have made this work very differently from running other tests
<plars> elopio: oh, I provision it ahead of time
<plars> elopio: by provisioning you mean installing the snappy image?
<elopio> plars: go run _integration-tests/main.go --ip  192.168.1.147 would give you that.
<plars> elopio: right, but that's what requires all the aditional go setup, and not just an adt-run
<kyrofa> seb128, alright, I'll get that setup
<sergiusens> ogra_: by the way, your 64MiB suggestion for boot won't work, the modules in the kernel add up to 187MiB
<elopio> plars: if you pass the ip, it does only adt-run, not building the image.
<seb128> kyrofa, thanks, when you have a sponsoring bug for the new package feel free to subscribe me
<sergiusens> ogra_: but we don't keep that in boot...
<elopio> plars: but we still need to generate the tests, generate snappy if you want to validate trunk, and some other stuff.
<plars> elopio: I'm not seeing much about go/path setup in http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/_integration-tests/README.md
<elopio> plars: take a look at that main.go. Is now nice and readable thanks to fgimenez' refactor.
<plars> elopio: I'm just interested in running the selftests on a device that has already been provisioned
<elopio> plars: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/README.md
<elopio> plars: yes, you still have to copy the tests to that provisioned device.
<elopio> maybe I should add a pointer to the other README.
<plars> ah, I see some of the integration tests are in go now... I didn't look one level deeper
<plars> I was just seeing the shell ones
<elopio> plars: hopefully, all of them will be go by the end of this week.
<plars> doing things like this means a lot more requirements on the host side need to be supported, but if they have to be in go, I'm not sure there's a great way to do it
<plars> I can see the problem
<elopio> plars: what kind of requirements do you think we need?
<plars> elopio: just all the go stuff to get it building on the host, paths set up, etc... not as simple as the adt-run we did previously
<elopio> plars: right, that's because previously you were running the tests on the published image.
<elopio> we need to run the tests before an image is published. So we have to build snappy and get it into the image.
<plars> elopio: I got as far as go build working, but the test run bit doesn't work
<plars> it just drops a binary for snappy itself in /tmp
<sergiusens> ogra_: rsalveti btw, bind mounting modules.img to /lib/modules worked like a charm :-)
<elopio> plars: can you paste the output?
<plars> elopio: I did, it was the previous pastebin
<elopio> plars: on the previous pastebin you didn't have the proper go path, that's why it doesn't find the gocheck module.
<sergiusens> plars: godeps -u dependencies.tsv
<plars> $ echo $GOPATH
<plars> /home/plars/go/work
<plars> elopio: under that, it seems to have downloaded all the necessary bits
<plars> elopio: but I'd rather it didn't, don't we want it to pull from the branch checked out so it gets what's there?
<elopio> plars: so cd /home/plars/go/work/src/launchpad.net/snappy and ./run-checks in there.
<plars> sergiusens: I don't seem to have godeps
<elopio> plars: not sure what you meant with the last statement.
<plars> elopio: that's using a downloaded copy from launchpad.net right? how do you tell it to just use what you have checked out (and possibly changed locally)
<plars> elopio: or do you have to download it with 'go get' and modify the copy in your $GOPATH/src/...
<elopio> plars: with go get you only download the dependencies.
<elopio> you get snappy from the bzr branch.
<elopio> not yet sure if that's what you are asking though :)
<elopio> fgimenez: https://code.launchpad.net/~elopio/snappy/test_go_info/+merge/264790 is again ready for review.
<fgimenez> elopio, ok i'll take a look
<elopio> not sure if it's already late for you. If so, don't worry, we'll get it on friday.
<plars> elopio: run-checks seems to be trying to generate the image, which is precisely what I *don't* want to do
<elopio> plars: I know.
<elopio> that's just to check that you have everything in place.
<plars> elopio: I suppose I would also need to build these for arm right?
<elopio> no, instead of ./run-checks, do
<elopio> go run _integration-tests/main.go --ip {remote-device-ip}
<elopio> plars: ah, right
<elopio> go run _integration-tests/main.go --ip {remote-device-ip} --arch arm
<plars> adt-virt-ssh: error: unrecognized arguments: --reboot
<plars> elopio: I guess I need a different version of adt-run?
<elopio> plars: you need the latest one.
<plars> I just have 3.13 from vivid
<elopio> on the _integration-tests/REAMDE you'll find the link.
<plars> ah, I see
<elopio> plars: the one for wily is ok, but sometimes pitti fixes something for us so even that one can be outdated.
<plars> yeah
<elopio> plars: https://trello.com/c/KHFqlCce/157-make-sure-that-the-machines-running-the-tests-have-the-latest-adt-run
<plars> elopio: ok, it's getting farther... I'll see what I can do with this. Thanks a lot for the help!
<plars> elopio: which test beds is that aimed at? something you have set up somewhere?
<elopio> plars: just in general. Everything we use as a test host needs the latest adt-run.
<elopio> we are currently playing with a canonistack machine that will deploy other canonistack machines as testbed. And locally from our dev machines.
<fgimenez> elopio, done with test_go_info, dropped a comment
<plars> ah, ok. so a pre-run check
<fgimenez> nice evening everyone o/
<elopio> plars: yes.
<sergiusens> mvo_: do you know what creates /lib/firmware?
<sergiusens> mvo_: oh, nevermind, I'll fix the 500 binary task to not remove the dir :-)
<elopio> plars: so, when you get this bbbs running from the lab, we will extend main.go to run the tests in there in addition to in kvms.
<elopio> we'll give you an image path, and you'll return us an ip. Everything will then just work (tm).
<plars> elopio: well, the image really needs to feed into it before you call main.go
<elopio> plars: why is that?
<plars> elopio: so we can just call ubuntu-device-flash somewhere else, build the image and push it to a download site, then the provisioner makes sure the device is stable and flashes it, boots into the image, then the script to run the test is called
<elopio> plars: I think we need to start that whole process from main.go.
<plars> elopio: it's already a very weird process from everything else, but that's the only sane thing I can think of to do
<plars> elopio: that's going to be a problem I'm afraid
<plars> elopio: the provisioning is handling a lot more than building an image, and in fact doesn't even build the image
<plars> it needs the image handed to it
<plars> elopio: it also handles detecting if the device is even available, or if it needs to be recovered to some working state
<elopio> plars: ok, we can call main.go to an already generated and provisioned device.
<elopio> plars: but I'd like two things:
<elopio> 1. tarmac notices a new merge proposal is ready for review, so it triggers the whole test suite in kvm and bbb.
<plars> hah, watching adt-run complain about apparmor rules and autopilot introspection in this context is a bit funny
<elopio> 2. something notices that there's a new image in the channel and triggers the whole suite in kvm and bbb.
<elopio> I think you are thinking about giving us 2, which is useful. But 1 it's more important atm.
<plars> elopio: that part is on your side like all other teams, we just provide the hardware :)
<plars> elopio: you really should sync up with the ci (ols) team and start taking a look at what they are working on
<sergiusens> plars: that ci is not the thing we need; I don't think they are doing source level ci which is what elopio wants; in any case, once we have webhooks and we can talk to this hardware somehow, it won't be a problem
<plars> sergiusens: I'd like to understand how that works, I would imagine that someone wants to test on hardware?
<beuno> elopio, plars, sergiusens, CI is *only* focusing on product testing. That is, testing an image with one or many snaps, and their test suite however that's defined
<beuno> unit tests on branches it out of scope for the CI work being done, or planned to be done
<beuno> the entry point is a built snap
<elopio> beuno: yes, this is not unit testing. This is testing snappy as-installed.
<elopio> now, if snappy is a deb, not a snap. So, that's out of your scope?
<plars> beuno: right, and this may be very different from the tarmac stuff they want to do right now, but if anyone wants to use the selftests as we have done before for testing snappy images, it would need to fit into that process somehow
<beuno> elopio, we start off from a pre-built image, and can put snaps on top. CI won't care how that image is put together
<beuno> elopio, once it's all snaps, it will be able to compose images on-the-fly
<beuno> plars, yeah, we have uses cases for testing snaps before putting them in the store (or publishing them to any channel). Is that what you had in mind?
<beuno> it's still a snap as a starting point
<elopio> ok, so everything will just work. We just need to plug everything.
<beuno> elopio, correct
<elopio> once I know who to get a bbb provisioned, I'll add it.
<elopio> and once I know how to define a test as part of a snapp, I'll add it.
<beuno> elopio, the first MVP will be able to take a URL for an image, trigger test runs in jenkinses controlled by you and in hardware controlled by plars
<beuno> report back
<elopio> and once I know how to generate a image on the fly, I'll add it.
<beuno> second MVP, that, but also install a snap
<elopio> sounds easy :)
<beuno> elopio, I expect plars to sort out bbb provisioning for you
<beuno> he owns the lab
<beuno> and you just focus on where and how to run tests
<beuno> you slap on a small agent to the jenkinses and CI takes over in driving tests and reporting back
<elopio> beuno: yes, all good.
<elopio> however, I expect we will start having problems when the boundaries between runner, provisioning and test are blurry.
<elopio> for example, we'll run the whole suite on a given image, that's the easy case.
<plars> beuno: as I understand it, a test request can be made with or without a new snap. It just needs to be provided with a image to install and a test payload
<elopio> then we will want to specify image 15.04 alpha -1. Update it, reboot and then run more tests.
<beuno> plars, correct
<elopio> that's harder. But we'll get to it after solving the first case.
<plars> beuno: BBB provisioning is sorted out locally, and as soon as the hardware we've ordered arrives, it will be sorted in the lab
<beuno> elopio, indeed. So provisioning will need to support that, and there's plenty of places to collaborate
<beuno> plars, awesome. The good thing about our current model is that we could run it on your bbb and elopio's until we do  :)
<plars> beuno: my concern here was that provisioning needs an image, not a go binary to try to handle everything fo rit
<elopio> plars: so, for now, we just need an ip from you.
<elopio> we will adt-run into that ip.
<plars> beuno: indeed! I'm sitting next to a breadboard with relays and a BBB fully instrumented right now :)
<plars> elopio: but you don't know how to drive those relays, the control mechanism, hard power on/off, etc
<plars> elopio: that's why I need to have the local provisioning agent handle that
<elopio> plars: what you need is make an adt-run controller that knows how to handle that.
<plars> elopio: it's not that your scripts can't be taught to do that, but it's configured locally per device, so there's no way to know how to do that in a generic way for any device in any environment
<elopio> but in our current tests, we don't need hard power. Not yet.
<plars> elopio: I do, for provisioning and recovery
<elopio> that's only needed on your side, after a test ends.
<plars> elopio: that's why the hard poweroff is needed
<plars> elopio: no
<plars> elopio: for provisioning, the bbb needs to boot either into emmc or sd
<elopio> plars: but that's on your side too.
<plars> elopio: you can never assume that the image on there before was ok to boot from
<plars> elopio: exactly, that's why you *should* want me to handle provisioning, not your tests, and definitely not adt
<elopio> we will give you an image, you provision however you want and we'll wait.
<plars> that's way too late in the process
<elopio> once we get the ip, we run the tetsts.
<plars> and there's no way to make it generic enough for those to handle it
<plars> it's a local device problem to solve
<plars> that way you can just say "here's the image, you sort out how to get it on the device"
<elopio> plars: you are saying just what I'm saying, I don't understand why you say it's too late.
<elopio> we will give you the image, somehow.
<plars> elopio: then that's fine
<elopio> you put it in a device, somehow.
<elopio> when that's ready, you give us an ip, and we adt-run into that ip.
<plars> sort of...
<plars> you would tell us where the test payload lives, which we need to figure out
<elopio> plars: adt-run takes care of setting up the tests, through ssh.
<plars> then a local script would probably have to detect that it's this selftest thing, not a regular adt test, and set up the go environment, call your main.go with the ip of $device
<elopio> you don't need to know anything about the tests.
<plars> then save off the results somewhere you can get to them
<plars> elopio: well, sadly I do now
<plars> elopio: because I can't treat it as a regular adt-run
<elopio> not yet, at least. Once we want to test hardware power-off, then it's harder. But again, we'll figure it out later.
<elopio> plars: adt-run takes care of collecting the results, through ssh again.
<plars> off the device... then what?
<plars> elopio: you don't have access to the local setup, and all that is going to get destroyed locally, not kept forever
<elopio> why can't you treat them as regular adt-run?
<plars> elopio: you said I couldn't
<elopio> plars: yes, but you destroy it after the test finished. After adt-run collected everything.
<plars> elopio: you said I had to set up the go build environment and build it first
<elopio> plars: oh, I meant not as regular dep8 tests.
<plars> right :)
<elopio> these are not normal debian package tests, because they can't run in any debian, they need to run in a snappy.
<plars> elopio: so at that point the tests are sitting on a host system half-way around the world... I assume you'd like to get at them somehow?
<elopio> plars: so, the host is my machine, and the test bed is a bbb in the lab.
<plars> elopio: sure, the previous selftest could run directly from adt-run though, and didn't require building and setup ahead of time, that's what I meant
<plars> elopio: ah, that's where the confusion is
<elopio> once I have the ip of the bbb, from my machine I use adt-run to get the tests  into the bbb, to run the tests, and to collect back the results.
<plars> elopio: your local machine may be the one requesting the test, but it's definitely not the host machine from which adt-run gets called
<plars> elopio: assume  lab, private network, etc
<elopio> plars: it has to be either my machine, or the tarmac machine, or the jenkins machine.
<plars> elopio: otherwise, if you want to instrument beaglebones and run them all locally, that's an option
<plars> elopio: why?
<plars> elopio: this is not that different to the problem on phones... you need something that manages that resource, connects to it locally, etc
<plars> if it's in a lab, it needs to be something there, providing a service that lets you request provisioning, testing, etc. and feeds you back the results
<plars> elopio: otherwise there's no way to stop you from stomping on stuff others are doing, or stop them from messing up your stuff
<plars> elopio: now if it's something sitting locally on your desk, that's not a shared device and you can locally control access to it
<plars> elopio: but the automated provisioning has to be handled locally, or else done manually
<elopio> plars: yes, so you will have in the lab a tarmac machine that will ./run-checks from a snappy branch. And that will request a bbb and run tests in there.
<elopio> that tarmac machine will take care of collecting the results, and  posting them to launchpad.
<elopio> ev, let me paste the log for you.
<ev> thanks
<elopio> thought I feel that we are going in circles. Once there's an API I can call, everything will be easier.
<ev> I'll read over it after lunch
<beuno> I think it's all fine, FWIW, and this will be clear once we have the first piece in place
<beuno> but the journey of the conversation was super valuable
<plars> indeed, I think it will make a lot more sense as soon as some of those pieces land
<plars> elopio: for you, I think the process will work something roughly like: request $test on $image_url, receive a unique id, poll $somewhere for results (including a link to details result tarball and pass/fail status), download $results_url
<plars> elopio: from that, if it's tarmac, it could use that to make a decision on the MP landing for example
<plars> elopio: there's a lot of flexibility here
<elopio> ev: noise][: http://paste.ubuntu.com/11883742/
<noise][> elopio: thx
<elopio> plars: and can that request $test look like: request "bzr branch lp:snappy && ./run-checks"?
<plars> elopio: for now, I don't think so.  It's going to need some wrapper to help it find the device, ensure the host environment doesn't get trashed, etc
<plars> elopio: in the beginning, I have good support for adt-run on some branch (I was using the old selftests as a prototype actually!)
<plars> elopio: and I was planning to add plainbox to that soon, so it could see some sort of test_type or something, and figure out which thing to call
<plars> elopio: I'm sure we can support a special one for you, it's just too bad that it can't just be adt-run directly on the branch
<plars> elopio: now if it's a snap that's already in the image, then I would bet it could work that way
<elopio> if we can't specify the branch we want to test, then it's useful, yes, but we will get results too late.
<elopio> plars: it can't be adt-run directly on the branch to run all the tests we want, at the moment we want to run them.
<elopio> but it's possible for a subset of the tests, sure.
<elopio> again, just give me the specs that the test needs to meet. And we will make it happen.
<plars> elopio: I think specifying the branch would be just fine, it can be part of that test payload
<plars> elopio: in fact, I was counting on it :)
<elopio> plars: ok, but then how are you planning to build the branch?
<elopio> you can't just bzr-bd, because you will end up with a .deb that you can't install on the snappy image.
<plars> elopio: as I said, I can treat this as a 3rd "type" of test, and it would need to set up GOPATH, go get $something, and run it
<plars> elopio: go run _integration-tests/main.go --ip $THIS_DEVICE_IP --arch arm
<elopio> plars: ok, that's fine. I just started by saying that this "test from snappy build from a branch" is our main goal, it's what gives us more useful information.
<elopio> a "test from snappy already published in an image" is useful, but not that much as the results will arrive a day late.
<plars> elopio: incidentally, where can I find the output dir after running that?
<kyrofa> seb128, I've got the .deb installed, but I'm not sure how to launch it. I can't seem to be able to drag up from the launcher
<plars> elopio: well you have to build the image somehow? can't you pull the branch and build the image from that, then give me the url for it?
<elopio> plars: not yet. Currently we depend on launchpad for building the image.
<plars> elopio: and ./run_checks does that somehow?
<elopio> ogra_ will work on rootstock to give us a quick way to build it locally, and beuno's team will at some point work on giving us images built on-the-fly.
<plars> elopio: I'm assuming *something* can get the image you really want to check
<elopio> plars: no, the trick run-checks does is that it puts the build snappy binary in the PATH, so instead of running the installed one, it runs the one from the branch.
<plars> published, unpublished, or otherwise
<elopio> that's also a temporary workaround that should be adjusted once more testability features start landing.
<elopio> plars: the restuls are in /tmp/snappy-tests
<elopio> /tmp/snappy-test
<kyrofa> kgunn, have you gotten up and running with a recent Ubuntu Personal image?
<plars> elopio: cool, found it. I got a bunch of failures, but to be fair this was an old image I was running it on. I'd like to do a newer one and try again at some point
<elopio> plars: yes, and we haven't landed the branch that makes all the tests pass in bbb.
<elopio> ...because we still have to make that branch :)
<plars> elopio: ah, cool. Please let me know when that branch lands, that one will be interesting to watch for :)
<elopio> currently it passes 100% only on kvm, 90% on canonistack.
<plars> elopio: sure, understandable
<elopio> bbb, I'm not sure now. I'll get back to it tomorrow.
<plars> a lot of stuff does pass too btw
<plars> so hopefully it's not *too* far off
<elopio> plars: many tests are quite simple. The problem is with the failover ones.
<plars> oh.. yeah
<elopio> there are some real bugs, and there are some things that work differently on the board.
<elopio> but yeah, we are close.
<elopio> early next week, tops.
 * rsalveti reading the huge backlog
<rsalveti> elopio: yeah, the way I see the main difference to when we're testing the landings with image testing is that for the first case we'd be generating the image by hand
<rsalveti> and giving that to CI
<rsalveti> plars: so where is the real lab going to be, in taiwan?
<plars> rsalveti: yes
<rsalveti> plars: so we need a real amd64 box in order to do the same tests but for kvm
<rsalveti> since we can't do nested kvm easily
<rsalveti> I was trying to get a machine so we could drive such testing, but that might still take a bit of time
<rsalveti> plars: so wonder if we could just have a real box in there that could run such kvm testing
<rsalveti> so we can follow the same testing path/logic for both kvm and bbb
<plars> rsalveti: hmm, I'll have to talk to my manager about that. It's not something we were planning for right now.
<rsalveti> and then drive the jobs by a custom jenkins or something along that line
<plars> rsalveti: I wonder though, could you use a cloud instance instead of hardware+kvm?
<rsalveti> plars: problem is nested kvm
<plars> rsalveti: right, I don't mean run kvm on the instance, I mean the instance running snappy itself
<rsalveti> so the host would need to be bare metal
<rsalveti> that's kind of what elopio and federico are doing, but wonder if it will be fast enough
<rsalveti> elopio: how are you planning on feeding the images on that case?
<elopio> rsalveti: for our cloud testing so far, we are just taking the latest image in canonistack.
<elopio> putting on top of that the built snappy from the branch and updating the PATH.
<rsalveti> right, to test our own images we'd need to have a way to feed images
<plars> elopio: the ci team had code to build an image with ubuntu-device-flash, convert it, and upload to glance
<rsalveti> is that something we can do?
<plars> and it even ran snappy selftests on it iirc :)
<elopio> plars: /me wants!
<plars> but just the old one
<plars> elopio: hang on, there's even a microservice for it
<rsalveti> plars: but on canonistack?
<beuno> plars, how about maas + hardware in the lab?
<beuno> to provision images for x86
<beuno> I'm sure we can either find the hardware or get some
<plars> beuno: we *may* have something like this for our own sanity, but very likely not for test hardware directly
 * beuno nods
 * beuno lets plars figure out how to make computers dance
 * elopio C< lunch.
<mterry> My snappy-rolling install still has python3.  I thought we dropped that?
<mterry> ah
<mterry> I'm not really rolling
<mterry> 15.04/edge
<kgunn> kyrofa: i did last week, but haven't done much with it since
<kgunn> what's up?
<sergiusens> mterry: no, rolling still has python3
<mterry> sergiusens, guh
<sergiusens> mterry: we need to drop system-image first and get a new cloud-init
<rsalveti> yeah
<rsalveti> hopefully we can drop system-image soon
<rsalveti> at least
<kyrofa> kgunn, I can't swipe up on the app scope to get access to other scopes, so I can't test mine out, haha
<kyrofa> kgunn, can you?
<kyrofa> kgunn, swipe up, I mean
<kgunn> lemme check kyrofa
<kgunn> gimme a sec to build a new img
<kyrofa> kgunn, thank you :)
<kyrofa> kgunn, mine is a bit old at this point too... maybe I should do that
<kgunn> kyrofa: you still using this incantation ?
<kgunn> u-d-f personal rolling --channel edge --output wily.img
 * kgunn checks cause you never know what changes in a week :)
<kyrofa> kgunn, yessir!
<mterry> barry, got a sec for python import questions?  If I installed python2 into /usr/local as well as a python module into /usr/local (but otherwise the same way ubuntu does), would python2 know how to find that module without any env vars?
<barry> mterry: depends on where in /usr/local :)
<mterry> barry, I'm testing a snap with python2 installed
<mterry> barry, inside the snap. I also put a module in there
<barry> mterry: you can always tell for sure by running `python -c "import sys; print(sys.path)"
<mterry> barry, and somehow python2 is finding the module, I wouldn't have expected that
<mterry> good point, /me tries that
<barry> mterry: this is a python built for ubuntu right?  (it will have different default paths than a built-from-upstream-source version)
<mterry> barry, this is ubuntu python, yeah
<mterry> (amd64)ubuntu@localhost:~$ spongeshaker.sha3sum /usr/bin/env['/apps/spongeshaker.sideload/0/bin', '/apps/spongeshaker.sideload/0', '/apps/spongeshaker.sideload/0/usr/lib/python2.7', '/apps/spongeshaker.sideload/0/usr/lib/python2.7/plat-x86_64-linux-gnu', '/apps/spongeshaker.sideload/0/usr/lib/python2.7/lib-tk', '/apps/spongeshaker.sideload/0/usr/lib/python2.7/lib-old', '/apps/spongeshaker.sideload/0/usr/lib/python2.7/lib-dynload', '/apps/spongeshaker
<mterry> .sideload/0/usr/lib/python2.7/dist-packages']
<mterry> barry, ^ looks like it finds it alright, along with a bunch of other weird stuff
<barry> mterry: weird (well, the spongeshaker prefixes).  i haven't yet had time to follow your work here too closely
<mterry> barry, ignore the silly spongeshaker stuff
<mterry> barry, that's just the name of the snap I'm testing with
<barry> mterry: cool, the lib-tk, lib-old, lib-dynload are expected
<barry> as is the plat triplet
<mterry> barry, and the dist-packages presumably
<mterry> barry, so our python2 looks at where it's being run from, and assumes the prefix from that?
<barry> mterry: yep, that's the debian-ism
<mterry> barry, that's pleasantly progressive of it
<mterry> barry, considering we know we're always running from /usr
<mterry> barry, well, usually  ;)
<barry> mterry: python generally looks for some landmarks and crafts its default sys.path from those
<barry> i don't remember the landmark, it's changed a few times.  could be os.py these days
<beuno> jdstrand, o/   I want to make my automated blinds thing a proper snap I can submit to the store. Is the hardware permissions story in 15.04 at all, or should I target (and install) rolling instead?
<beuno> my code is all sudo this and sudo that atm  :)
<kgunn> kyrofa: ok, had a little 'puter trouble, back now and got my unity8 personal up...what exactly were you experiencing trouble with ?
<kyrofa> Well, on the phone, I can drag up from the bottom to get access to all installed scopes. That default window in Ubuntu Personal looks the same, but I'm unable to drag that little arrow up from the bottom to get access to other scopes
<kyrofa> kgunn, ^^
<kgunn> ah
<kgunn> one sec
<kgunn> yeah...having the same prob
<kgunn> i suspect some issue with pointer events in window mode
<kyrofa> kgunn, hmm... tough to test scopes out that way. I don't know another way to launch them. Any ideas?
<kgunn> mzanetti: ^ any ideas ? is there a cli maybe to reveal the manage dash ?
<kgunn> seems on personal image (windowed mode unity8 in a vm) that bottom edge of dash is either impossible or close to impossible
<kyrofa> cihelp: I have a package that's running in jenkins and autolanding. I need the configuration changed so that I can land it in the archives. What do I do?
<kyrofa> Oops... wrong room
<kyrofa> Ahem...
<mzanetti> kgunn, kyrofa: try launching it with "-mousetouch"
<mzanetti> that should convert all mouse input to touch events and allow activating those touch-only drag areas
<kyrofa> kgunn, do we have a terminal we can do that ^^ in?
<kyrofa> mzanetti, , not sure how mir displays work, but I assume I can't do that on SSH and expect it to work
<mzanetti> kyrofa, how do you launch the dash? is it autostarted?
<kyrofa> mzanetti, yeah, autostarted
<mzanetti> then I think you can edit /usr/share/upstart/sessions/unity8-dash.qml
<mzanetti> and add some args there somewhere
<mzanetti> use "restart unity8-dash"
<kgunn> mmm...
<kgunn> but can we flip to vt1 ?
<kgunn> think there's a bug maybe
<kgunn> ah...it worked
<kyrofa> kgunn, I can get there
<kgunn> nice
<kyrofa> kgunn, ah, good
<kgunn> :)
<mzanetti> to use "restart unity8-dash" you need to have session variables exported tho...
<kyrofa> mzanetti, how about a reboot?
<mzanetti> yeah, that would work too :)
<mzanetti> here's a terminal for unity8... http://notyetthere.org/data/com.ubuntu.terminal_0.7.latest_amd64_rev015.click
<mzanetti> I found that quite useful
<kyrofa> mzanetti, awesome, thank you!
<mzanetti> np
<tedg> kyrofa, I just used a session upstart job. Copied the /usr/share/upstart/sessions one to ~/.config/upstart and then added the -mouse touch parameter.
<kyrofa> tedg, good call, thanks
<kyrofa> tedg, just add the -mousetouch at the end of the exec line?
<kyrofa> It's not working for me. Perhaps I'm putting that param in the wrong place
<tedg> kyrofa, I did it for unity8 not the dash, not sure if they work differently.
<jdstrand> beuno: everything that is in rolling is in 15.04 afaik. so hw-assign works and so does assign via the oem snap
<jdstrand> beuno: you might talk to snappy core guys for updates. I do know that it isn't documented well and there is a bug on that
<kirkland> does icon.png have to be a specific dimension?
<tedg> I think that icons can only be SVGs
<ev> elopio: for what it's worth (after that whole discussion earlier), you don't have to work strictly in images. We have a potential use case in testing pre-snappy phones. Because you never pass along an actual image but instead a reference to an image (a URL or whatever text you want), this can be ubuntu-device-flash --do-stuff or whatever.
<ev> Also, the core of this system is product based testing with clear separation between three actors: test authors, labs, and promotion. CI purposefully knows nothing about the tests. They can be written in DEP8 or Haskell for all we care. However, the tests should not reach beyond their role: they shouldn't manage the lifecycle of the device under test, as
<ev> that's a property of the lab. They need to be able to ensure that you're not phoning them up complaining about BBBs being wedged.
<ev> We're going to follow this up with happy shiny documentation to explain it more eloquently than I can over IRC
<elopio> my quassel is angry at me again.
<elopio> ev: sounds good. The test experiment we are doing on writing the test in go is awesome because it's self contained, it's just a binary you run and it will have all the dependencies.
<elopio> for that part, we only need to know what is the api and the format expected from us, and we'll compy.
<elopio> there's one detail that's hard, and we don't yet know how to solve, and that's generating an image without waiting for launchpad to do it for us.
<elopio> but even that it's a problem that we can solve as we go. Worst case scenario, we keep our hack with the PATH which is OK for now.
<elopio> but I'm sure the solution will be a lot better than the worst case scenario.
<ev> elopio: image composition is something we're being mindful of, but exists outside of the CI product: https://docs.google.com/presentation/d/1Ds08fWyDkd-oddA7LMuj0iO6iHa2OyqsIWHGg5_4mv8/edit#slide=id.gb43807a7b_0_497 and https://docs.google.com/document/d/1aIKRneZWge6U6BuuchGE7MWBYE67dog900zWqJU0zi8/edit (grep for img_composer)
<ev> elopio: might I recommend IRCCloud ;)
<ev> it almost makes IRC tolerable
<elopio> ev: I love quassel, despite all its tantrums. Generally it works on my desktop when it fails on my laptop, like today :)
<elopio> ev: we are close to finish our first goal for the test suite. Then, focus will be on running the tests often, so I'll soon send a calendar appointment with you and plars to re-sync.
<elopio> for now, I think we are good enough. If you or somebody from your team could run the snappy _integration-test locally to get a sense of what we are doing, that would be awesome.
<ev> elopio: that's more for you to do directly. This is self-service CI. We purposefully don't have knowledge of the tests, how they're ultimately run, or how to interpret the results.
<ev> The team is working on documenting how to submit results, how to (work with plars) to configure the agent's provisioner, and where to poll for results.
<ev> I'll reach out to you once those docs are in place to reviewÂ our progress towards the story of validating the core snappy product
<ev> (that's slides 2-4 in https://docs.google.com/presentation/d/1Ds08fWyDkd-oddA7LMuj0iO6iHa2OyqsIWHGg5_4mv8/edit#slide=id.gb43807a7b_0_366 )
<ev> s,how to submit results,how to submit new test opportunities,
<ev> this, incidentally, means you have more freedom to do what you need, but at present it requires that you drive the process (until we hook up to the firehose of the store)
<beuno> *cough* public channel *cough*
#snappy 2015-07-16
<kirkland> been beating my head against the wall for 3 hours now
<kirkland>  Operation not permitted
<kirkland> trying to launch docker inside of my snap
<sergiusens> elopio: there's a hackish way to generate an image with a new snappy, I can show you; not that complicated
<elopio> sergiusens: show me please.
<dholbach> good morning
<ogra_> mvo, doko pinged me if we are aware about the gcc 5 transition ...
<mvo> ogra_: how does it affect us?
<ogra_> mvo, no idea ...
<ogra_> i just found that PM ping from last night :)
<mvo> ogra_: fwiw, I'm just looking at the uboot source, aiui the plan is to use saveenv on the fat partition, correct? if so we may hit the same issue :/ both cmd_fat.c:do_fat_fswrite() and env_fat.c:saveenv() use the same file_fat_write() code. we may be lucky of course because we keep rewriting the same cluster with saveenv :) just wanted to mention it that we need to be extra careful
<mvo> ogra_: well, we don't have any c++, maybe he just wants to says that it might be bumpy? but then its all done in a silo, soâ¦
<ogra_> yeah
<ogra_> well, do we use the go compiler ?
<mvo> we do for arm64
<mvo> but aiui we already use gcc5 for go
<ogra_> ah
<ogra_> mvo, well, if the env file in fat doesnt work we could still resort to a raw env partition ... but i'd like to see that as last resort due to the complexity it adds to the partitioning
<Mohammads> Hi
<JamesTait> Good morning all; happy Corn Fritters Day! ð
<mvo> ogra_: yeah, I am confident it will work ifwe ship a 1k (thats the env size, right?) pre-populated env file
<ogra_> right, but if it doesnt we still have options :)
<Mohammads> Does anyone work on Beaglebone Black Device tree overlay development?
<mvo> ogra_: so looking at the u-boot code it seems like all its doing is adding a 32bit crc plus a 8bit flags header, the rest is just char data.
<mvo> ogra_: want me to write a c-program that can deal with that? or will you do that, either way is fine, just offering help where I feel like I can be useful
<ogra_> mvo, you mean to edit it from userspace ?
<mvo> ogra_: yeah
<ogra_> yeah, sure ... one sec i can give you an existing env file (from rpi) ...
<mvo> ogra_: oh, thats awsome
<mvo> ogra_: what is your prefered interface? just something like "uboot-env load" dump on stdout, uboot-env save file" read from stdin and save to the given file?
<ogra_> either that or a file converter with a txt file as option
<ogra_> mvo, http://people.canonical.com/~ogra/uboot.env
<mvo> ta
<ogra_> Mohammads, yes, but no ETA yet
<mvo> ogra_: silly question, how did you generate the inital version of the file?
<ogra_> mvo, i actually used lool's file ... but afaik you just create a txt file and use mkimage (from uboot-tools) to add a header
<mvo> ogra_: nice, I explore that, thanks
<mvo> ogra_: yay, I think I found all I need, will give you some stuff in some minutes (or hours, depends how it goes :)
<ogra_> heh, no hurry, i'll need a few hours myself still :)
<lool> mvo: there's a fw_printenv / setenv in u-boot-tools
<ogra_> i thought that doesnt work ?
<lool> I had a perl script to create env files too, but not sure where I've put it
<ogra_> (didnt you say that yesterday ? ... )
<lool> ogra_: hmm it might be mtd only
<ogra_> ah, no that was sergiusens
<mvo> lool: yeah, thats the one I found and was trying to use
<mvo> lool: it does support vfat afaict
<mvo> lool: at least the examples do
<ogra_> thre are other tools out there worst case
<mvo> yeah, its easy enough to write one
<ogra_> http://free-electrons.com/blog/mkenvimage-uboot-binary-env-generator/
<mvo> but fw_* is my current approach
<lool> ah I remember now, the tool will work on files if it's built without CONFIG_MTD
<ogra_> someone in the comments claims:
<ogra_> mkimage -T script -C none -n 'setenv-name' -d u-boot.env u-boot.env.img
<ogra_> should work
<mvo> lool: it works for me on my BBB  afaict, tested it some minutes ago
<lool> ogra_: that's surprizing
<ogra_> lool, yeah, well, not sure he is just guessing :)
<mvo> lool: is there a reason that mkenvimage is not included in the u-boot-tools? it seems to be what we need. if you don't mind I will upload that to wily and send a patch to debian (unless there is a good reason not to have it)
<lool> mvo: grr, I hate the fact I didn't check the u-boot tree earlier
<lool> mvo: I suspect it's not in the package just because the debian package was created before the tool was added
<mvo> lool: no worries, I will upload and push patch unless you want to commit directly to the debian tree
<lool> mvo: yes, please do upload this
<mvo> lool: sure, thats fine, thanks!
<mvo> lool: http://paste.ubuntu.com/11886878/
<mvo> ogra_: do we have a trello card for the env work? I would like to add a checklist so that I don't forget the steps I need to do :)
<ogra_> mvo, hmm, i dont think so
<ogra_> where would that go ? snappy-core-roadmap ?
<mvo> ogra_: I create one, hope I'm not too hyperactive in the morning, had strong tea today
<mvo> ogra_: work-in-progress would be my guess
<ogra_> mvo, created a card and added you
<mvo> ogra_: \o/
<mvo> ogra_: I added a checklist, would be great if you could check if it makes sense
<ogra_> mvo, why do we need to modify snappy-system-txt to use getenv ?
<ogra_> (if we move away from it anyway)
<mvo> ogra_: I don't know, if that does not make sense, kill it, its my ignorance speaking
<ogra_> well, we should keep it as is until we drop it i thionk
<mvo> ogra_: I thought we do it in two steps, keep snappy-systems.txt initially and use the env and then move it all into the env
<mvo> ogra_: but if that does not make sense, thats fine
<ogra_> i dont think that needs any modification in snappy-system.txt (i need to check though)
<mvo> aha, even better
<mvo> just adjust the checklist as needed :)
<mvo> (you have a better overview about this I think)
<ogra_> yeah... i need to try first though, lets keep it (with a more generic text)
 * mvo nods
<ogra_> hmm, how do i move an item
<ogra_> hah !
<ogra_> drag n drop ... crazy stuff
<mvo> :)
 * mvo gets lunch
<mvo> ogra_: I will add the /etc/fw_env.config to livecd-rootfs after lunch for armhf
<ogra_> does it work ?
<ogra_> (did you try the fw_* commands on teh file yet)
<sergiusens> ogra_: lool mvo nice to know that it works. For the record I tried fw_saveenv way back on the first iteration of the bbb port and didn't work and remember lool giving me a fancy explanation of why and did not look into it anymore :)
<mvo> ogra_, sergiusens: it seems to be working: http://paste.ubuntu.com/11887048/
<ogra_> mvo, well, does it also work on a uboot prompt :)
<mvo> oh, I have no idea, let me try. I though this way around was the problem
<ogra_> but yeah, smells like it could work fine
<ogra_> note the current uboot on BB wont load the file
<ogra_> (thats what i'm working on atm)
<ogra_> you can use it on a rpi though
<sergiusens> mvo: ogra_ nice, when I played with this I wasn't using a uboot.env file though :-)
<ogra_> ah
<lool> mvo: nice
 * lool lunch &
<ogra_> sergiusens, erm
<ogra_> ogra@anubis:~/datengrab/rpi/uboot/package/u-boot-2015.04+dfsg1$ ls -l /media/ogra/system-boot/
<ogra_> insgesamt 4
<ogra_> drwx------ 3 ogra ogra  512 Jan 18 11:31 a
<ogra_> drwx------ 3 ogra ogra  512 Jan 18 11:31 b
<ogra_> -rw-r--r-- 1 ogra ogra 1596 Jan 22 06:05 snappy-system.txt
<ogra_> -rw-r--r-- 1 ogra ogra  237 Jan 18 11:31 uEnv.txt
<ogra_> where exactly is our uboot ?
<ogra_> (its not in a or b either
<ogra_> )
<ogra_> (dont tell me we dd it raw somewhere
<ogra_> )
<mvo> I think we do, but sergiusens will confirm
<ogra_> bah
<mvo> ogra_: fwiw, this u-boot env will make the bootloader code more similar so massive opportunity for cleanup here, I love that soooooo much
<ogra_> :D
<mvo> i.e. MarkCurrentBootSuccessful is now identical in boot uboot/grub :-D
 * mvo will push a MP soon
<sergiusens> mvo: consider we need to backport some things to 15.04 (the file copy part at least)
<mvo> sergiusens: yeah, the backport is tricky, how do we create /boot/uboot/uboot.env on existing systems :/
<sergiusens> ogra_: u-boot and slp are dd'ed instead of file copied per lool's recommendation
<sergiusens> mvo: if our update provides the latest snappy update again soonish and it would be picked up
<ogra_> sergiusens, do you have the lines we use for that (offset etc)
<sergiusens> ogra_: look in the package.yaml for the oem package
<ogra_> is there a bzr tree ?
<sergiusens> ogra_: yes sir
<sergiusens> ogra_: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/beagleblack/meta/package.yaml
<ogra_> thx
<ogra_> hmm, that doesnt work :/
<ogra_> (dd does, but the board doesnt boot)
<sergiusens> ogra_: for using dd https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSDcard
<sergiusens> ogra_: don't truncate :-P
<ogra_> well,. thats what i'm using
<sergiusens> ogra_: compile u-boot for arch == armhf? :-P
<ogra_> lol
 * sergiusens asks ogra_ some very random dumb questions
<ogra_> very funny :P
<ogra_> sigh
<ogra_> aha
<sergiusens> sigha
<ogra_> S2 and reset doesnt work at all ... it only works if you actually make the board powerless
<sergiusens> ogra_: isn't that documented?
 * sergiusens thought it was
<ogra_> at least i have it now booting to a uboot promot with my own build
<sergiusens> I did that dance with power cycling
<ogra_> might be that it is documented :)
<rsalveti> morning
<mvo> sergiusens: hm, we would have to convert the existing uEnv.txt, no? i.e. we can not just ship a static file to existing systems (?)
<mvo> ogra_: snappy is ready now too, but I did not do further cleanups, I wait for an end-to-end test to ensure this all works first :)
<ogra_> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
<ogra_> reading uboot.env
<ogra_> ** Unable to read "uboot.env" from mmc0:1 **
<ogra_> Using default environment
<ogra_> \o/
<rsalveti> ogra_: yeah, uboot is in a raw partition
<rsalveti> same for mlo
<ogra_> ugly :P
 * ogra_ puts his rpi uboot.env in place for a test
<sergiusens> mvo: yes we would
<rsalveti> mvo: sergiusens: we can't easily update running 15.04 systems right?
<rsalveti> because of the upgrader issue (running the upgrader from the older image)
<ogra_> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
<ogra_> reading uboot.env
<ogra_> *** Warning - bad CRC, using default environment
<ogra_> hmpf
<rsalveti> oops
<ogra_> but at least:
<ogra_> U-Boot# saveenv
<ogra_> Saving Environment to FAT...
<ogra_> writing uboot.env
<ogra_> done
<ogra_> aha
<ogra_> and after reset
<ogra_> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
<ogra_> reading uboot.env
<ogra_> Net:   cpsw, usb_ether
<ogra_> Hit any key to stop autoboot:  0
<ogra_> so the uboot.env file we use for the rpi doesnt work ...
<ogra_> which indicates they are not generic :/
<ogra_> (and that we might have to create the initial file using the uboot prompt ... thats rather suboptimal)
<rsalveti> well, dump the file and check for the header
<rsalveti> and the format
<ogra_> crap
<ogra_> so lool's raw initrd support breaks it
<ogra_> as soon as i enable that uboot hangs
<ogra_> with it disabled everything seems to work
<mvo> ogra_: I can send you a uboot.env that I created via mkenvimage from uEnv.txt if you want
<ogra_> mvo, well, i still need a working binary first
<mvo> sure
<ogra_> mvo, ok, i got something booting, gimme the file :)
<mvo> ogra_: http://people.canonical.com/~mvo/tmp/uboot.env
<mvo> ogra_: that i sa version of the stock uEnv.txt
<ogra_> 403
<ogra_> (forbidden)
<ogra_> ah, better
<mvo> ogra_: I can create one with both snappy-system.txt and uEnv.txt too, or you can do it yourself via "mkenvimage
<mvo> ogra_: ups, try again
<mvo> mkenvimage -s 0x4000 -o uboot.env snappy-system.txt
<mvo> from u-boot-tools in wily (not sure if its published yet)
<mvo> but I'm happy to do that until it is :)
<ogra_> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
<ogra_> reading uboot.env
<ogra_> *** Warning - bad CRC, using default environment
<ogra_> nope ...
<ogra_> doesnt work
<ogra_> mvo, these three work together http://people.canonical.com/~ogra/snappy/bootloader/
<ogra_> (though uboot.env is just a "saveenv" dump on the uboot prompt)
<ogra_> (README has flashing instructions)
<ogra_> see if that file is usable with your fw_* setup
<mvo> ogra_: hm, thats suprising that it gives a crc error
<sergiusens> rsalveti: snappy should have the logic for the next update to be successful and have the correct uenv and uboot.envs .. we don't have logic to update the bootloader, but that can be added
<ogra_> well, i can try again
<rsalveti> sergiusens: right, but would just be fixed on a following update
<mvo> ogra_: let check the source, I wonder if there is something funny here
<sergiusens> rsalveti: correct
<mvo> ogra_: could you try a updated version?
<mvo> ogra_: just pushed it to the same place
<ogra_> sure
<ogra_> mvo, still bad CRC
<mvo> meh, thanks
 * ogra_ melts
<kyrofa> mzanetti, yesterday you suggested I add -mousetouch to /usr/share/upstart/sessions/unity8-dash.conf to get be able to drag the dash scopes drawer up. I assume that's supposed to go on the exec line? Does it matter where? I can't get it to work
<ogra_> mvo, hmm, i get the crc error with fw_printenv too http://paste.ubuntu.com/11887435/
<mvo> ogra_: could you try the latest again? this seems to be ok for me via fw_printenv:  http://paste.ubuntu.com/11887439/
<mvo> ogra_: I have not tried uboot itself yet though
<ogra_> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
<ogra_> reading uboot.env
<ogra_> *** Warning - bad CRC, using default environment
<ogra_> nope ...
<mvo> meh
<ogra_> fw_printenv also shows me the CRC error
<mvo> oh
<ogra_> (thouh i have a slight werid setup)
<ogra_> ogra@anubis:~/datengrab/rpi/uboot/bbb/u-boot$ cat /etc/fw_env.config
<ogra_> ./uboot.env 0x0000 0x4000
<mvo> I use:
<mvo> root@localhost:/boot/uboot# cat /etc/fw_env.config
<mvo> /boot/uboot/uboot.env 0x0000 0x4000
<mvo> on the bbb
<mzanetti> kyrofa, let me try
<ogra_> well, i use it on my desktop
<ogra_> (my BBB cant boot atm)
<ogra_> mvo, oh, and your MP has an error ... .conf vs .config
<mvo> ogra_: hm, so the boot crc is on the rpi? I wonder if some configure option is different?
<ogra_> mvo, no, the CRC error is in uboot on the BBB
<ogra_> and on my trusty PC when using fw_printenv
<mvo> ogra_: meh, ok
<ogra_> heh
<ogra_> ogra@anubis:/media/ogra/system-boot$ fw_printenv
<ogra_> Cannot access MTD device /media/ogra/syst: No such file or directory
<ogra_> that is when i give it the full path
<ogra_> (in fw_env.config )
<mzanetti> kyrofa, doesn't work indeed
<ogra_> well, even mounting in /mnt and adjusting the path doesnt help
<mzanetti> I guess that touch->mouse conversion only works for X11
<kyrofa> mzanetti, hmm.... interesting
<kyrofa> mzanetti, any idea what would be involved to make it happen?
<mzanetti> kyrofa, I guess it might be possible to change the dconf key for favorited scopes
<mzanetti> kyrofa, so that they show up by default
<kyrofa> mzanetti, ah, that's a good workaround
<mzanetti> other than that, you could launch the scopetool
<ogra_> -rwxr-xr-x 1 root root 131072 Jul 16 14:11 uboot.env
<ogra_> mvo, ^^^^
<ogra_> i think the size is our issue
<ogra_> my saveenv'ed file is way bigger than yours
<ogra_> -rw-rw-r--   1 ogra ogra  16384 Jul 16 14:11 uboot.env
<ogra_> thast is yours for comparison
<mvo> ogra_: eh, 100k? thats a bit much
<ogra_> well, thats the whole saevenv dump
<mvo> ogra_: what else is in there?
<ogra_> i could show you if i could scroll in screen ... but many many lines :)
<kyrofa> mzanetti, unity-scope-tool?
<ogra_> (the default env isnt actually smnall)
<ogra_> we would have to use the defaults anyway so we should adjust the size
<mvo> 100k is a lot, thats not exactly fits-into-a-single-cluster :/
<ogra_> http://paste.ubuntu.com/11887481/
<ogra_> well
<ogra_> Environment size: 3862/131067 bytes
<ogra_> its not actually 100k
<mzanetti> kyrofa, yes
<ogra_> (the file is, but the content is 3k)
<mvo> ogra_: do you happen to know what is the ENV_SIZE for the bbb? or maybe lool?
<ogra_> could be that i defined that in my patch, one sec
<mvo> maybe thats the issue that the board is configured with a different one than what I set
<ogra_> hmm, no, i dont
<ogra_>  44 /* Always 128 KiB env size */
<ogra_>  45 #define CONFIG_ENV_SIZE                 (128 << 10)
<mvo> for the bbb?
<ogra_> yes
<ogra_> thats the default
<ogra_> (usually that lives on the eMMC)
<ogra_> i guess i can try going down to 16k
<mvo> ogra_: that would be cool
<mvo> ogra_: it seems like the ENV_SIZE is hardcoded for the loading/crc calculation, so either I need to increase the size to make the 128k or you need to decrease it, either way is fine with me
<mvo> ogra_: maybe I increase ? thats probably quicker than the recompile(?)
<kyrofa> mzanetti, not /com/canonical/unity/launcher, right? Those are the only favorites I see
<mzanetti> kyrofa, no, that's the launcher
<mzanetti> the panel on the left
<mzanetti> no clue where the scopes settings are tbh
<mzanetti> kyrofa, tsdgeos will know
<kyrofa> mzanetti, right. That's all that's under /com/canonical/unity, though
<kyrofa> mzanetti, alright, I'll ask him when he gets in. Thank you!
<mzanetti> kyrofa, he's in... just not in this channel
<mzanetti> seems the wrong one for this discussion anyways :)
<ogra_> mvo, ok, 16k works
<kyrofa> mzanetti, meh... Ubuntu Personal... snappy... :P
<mvo> ogra_: \o/
<mzanetti> oh well... as far as I'm concerned we're working with click still
<ogra_> hmm, or not
<mvo> :(
<ogra_> that was the wrong file
<ogra_> reading uboot.env
<ogra_> *** Warning - bad CRC, using default environment
<ogra_> using your file
<ogra_> bah
<ogra_> and saveenv still creates a 128k file
<ogra_> even though i lowered it in the config
<mvo> ogra_: any luck with http://people.canonical.com/~mvo/tmp/uboot.env4 with the default config?
<ogra_> let me try
<mvo> ogra_: thats with -s 131072
<ogra_> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
<ogra_> reading uboot.env
<ogra_> *** Warning - bad CRC, using default environment
<ogra_> nope
<ogra_> seems to only work right if i create it with saveenv
<ogra_> at the uboot prompt directly
<mvo> bÃ¤
<ogra_> can you actually read and modify my file ?
<mvo> ogra_: could you put that somehwere so that I can compare the headers?
 * ogra_ suspects fw_printenv does simply not do the right thing
<mvo> but it really should be just the crc :/
<ogra_> i did ... 30min ago ...
<ogra_> http://people.canonical.com/~ogra/snappy/bootloader/
<ogra_> mvo, i dont think it is bad to pre-create the file (from an empty env via uboot's saveenv) ... but we still need to be able to modify it and add stuff then
<mvo> ta
<mvo> let me try
<ogra_> mvo, oh, how do you build mkenvimage ?
<mvo> ogra_: it gets build as part of the nomral package build, I did not change that, just added it to debian/u-boot-tools.install
<ogra_> it seems to use the crc32.o object from the actual uboot build
<ogra_> which might perhaps differ between versions/builds
<mvo> ogra_: hm, I can't read your file fw_printenv gives me "Read error on /boot/uboot/uboot.env: Success"
<mvo> ogra_: hm, I see in the envfile that you use U-Boot 2014.10-dirty ( - i use the uboot from the archive for the fw_setenv etc
<mvo> ogra_: I wonder if that might play a role?
<ogra_> it could
<ogra_> i'm just trying to build mkenvimage here
<ogra_> nope, CRC error even with my own mkenvimage
<ogra_> mvo, well, i use the same base that lool used for the uboot we currently use ... which is upstreqams tree with 2014.10-dirty branch
 * ogra_ needs some fresh coffee ... brb
<sergiusens> elopio: your question from last night http://paste.ubuntu.com/11887593/
<mvo> ogra_: I'm a bit lost, I don't get the crc errors, I will look at the source some more
<ogra_> mvo, it loads the file on boot for you ?
<ogra_> (with my MLO and u-boot.img from the above url)
<genii> mmm coffee
<ogra_> (i dont really care so much if *my* fw_printenv works or my mkenvimage ... but i get the CRC error on boot when it loads it)
<mvo> ogra_: I haven't flashed it yet, I was poking with fw_printenv so far only on the bbb
<mvo> ogra_: that is the image iwth the 128k, right?
<ogra_> mvo, yeah
<ogra_> mvo, so rsalveti suggested we dump both files and compare them ... (checking header with hex editor or some such)
<ogra_> hmm, so in a hex editor i see the official file is filled with 00 ... while the one you created is filled with FF
<ogra_> and neither of them seems to have any header
<ogra_> s/filled/padded/
<mvo> ogra_: there should be 4byte of crc on each
<mvo> ogra_: let me check
<mvo> ogra_: I can change the padding to 00
<ogra_> yeah, thats the only difference i see
<ogra_> oh, wait
<ogra_> there is indeed a 4 byte header
<mvo> ogra_: this is what I see, it seems like there is one additional byte in yours
<mvo> ogra_: let me try to create one with this extra padding
<mvo> ogra_: I guess http://people.canonical.com/~mvo/tmp/uboot.env5 is still no good?
 * ogra_ humps mvo's leg 
<ogra_> http://people.canonical.com/~mvo/tmp/uboot.env5
<ogra_> err
<ogra_> http://paste.ubuntu.com/11887669/
<mvo> ogra_: ohhhhh?
<mvo> ogra_: sweet
<ogra_> mvo, so that works ... now the tricky part ... lool's setup is additive toi the default env (which we just wiped) ...
<ogra_> so we need to put all the defaults into your env file
<mvo> ogra_: and make fw_setenv work again, that seems to be not working now for me with that file :/ I will dig into it
<ogra_> mvo, did you adjust the size in the .config file ?
<mvo> I did
<ogra_> indeed that needs to match
<mvo> root@localhost:/boot/uboot# fw_printenv
<mvo> Read error on /boot/uboot/uboot.env: Success
<mvo> which is funny, I mean, no crc error and the error code is "success"
<mvo> I think it wants to make fun of me ;)
<ogra_> well, they want you to think positive, even in frustrating moments ;)
<mvo> ogra_: it might be short reads, I will add debug
<lool> mvo: I've seen similar bugs in u-boot before where the error is not bubbled up correctly  :-(
<ogra_> but at least it makes you feel good
<kyrofa> seb128, you want the snappy scope landing in wily, not the overlay, correct?
<seb128> kyrofa, correct
<mvo> lool: yeah - just building it is a pita
<mvo> (to add my debug stuff)
<lool> mvo: you can cross-build relatively easily, but yeah the tools build is ugly
<elopio> good morning.
<lool> you can't just make -C tools, or similar, the build system is too custom
<ogra_> you can make all
<mvo> lool: thats what I mean, I get all sorts of strange error
<ogra_> wotks fine here
<ogra_> *works
<lool> mvo: I tend to clean every thing with make mrproper between each build
<mvo> ogra_: did you do the menuconfig dance first? is there a shortcut for this?
<lool> (reconfigure with make boardname_defconfig, make, make tools or similar)
<mvo> aha, make tools
<mvo> I need to try that
<ogra_> i just run "make -j4 CROSS_COMPILE=arm-linux-gnueabihf- O=uboot-bbb.bin all"
<lool> I think that's what I used to use, not sure anymore
<ogra_> that gets me the tools in uboot-bbb.bin/tools/
<lool> ah it does exist but so does a cross_tools target
<ogra_> and yeah, mrproper and "make CROSS_COMPILE=arm-linux-gnueabihf- O=uboot-bbb.bin am335x_boneblack_config" before each build
<ogra_> btw, this is my config patch http://paste.ubuntu.com/11887776/
<ogra_> (i guess i could leave out the ifndef/endif bits)
<ogra_> lool, interestingly the boot hangs if i put the CONFIG_SUPPORT_RAW_INITRD at the top of the file ... reliably
<elopio> sergiusens: can you tarmac machine start a vm in canonistack?
<elopio> sergiusens: and thanks for the paste. With that, I'm now not really sure if we need the full rootstock build.
<elopio> will talk about that with ogra_ once Federico returns.
<ogra_> elopio, yeah, sorry, rootstock work is a bit on hold while i hack on the uboot fixes
<ogra_> i'll hopefully have time tomorrow aain
<ogra_> *again
<elopio> ogra_: don't worry, what I'm saying is that it's probably not needed.
<elopio> or well, it would be nice, but the extra info and security it will give is might not be worth it. Lets talk again before you spend your time on it.
<mvo> ogra_: its funny (for some value of that) http://paste.ubuntu.com/11887823/
<ogra_> mvo, twice ?
<mvo> ogra_: so fw_*env uses the exta padding byte only if its in a HaveRedundEnv mode
<ogra_> (the line in you config file)
<mvo> ogra_: yes, once is not enough
<mvo> ogra_: thats what makes it work
<ogra_> lol
 * ogra_ tries
<mvo> ogra_: don't ask why, this is from reading the source, the source does not tell me what the rational for this is
<ogra_> i think because NAND has two env partitions by default ofr some such weridness
<mvo> ogra_: that sounds reasonable, still, having a different head that is impossible to know what sizeit will have from looking at it, *not good*
<sergiusens> elopio: no worries. Can canonistack be reached from external servers? The other thing we can do is just put that tarmac instance on canonistack and free up my server ;-)
<ogra_> yeah
<mvo> ogra_: like - you know - having the first byte for header size and then tools could figure it out
<elopio> sergiusens: yes, to both.
<mvo> anyway, sorry for ranting
<sergiusens> elopio: let's discuss after standup then!
<elopio> sergiusens: you would need credentials for your server to access canonistack, so I think moving the server to canonistack would be better.
<ogra_> mvo, ranting in context of uboot is allowed and expected
<elopio> we just need to make sure that we have an easy way to redeploy it, because things seem to die suddenly on canonistack.
<mvo> ogra_: it also does not make any sense, only the last entry counts
<mvo> ogra_: in the config
<ogra_> heh
<mvo> hm, thats actually incorrect, it will read/write both it seems
 * mvo shakes head
<ogra_> just re-implement it in go ;)
<ogra_> without all the mess
<mvo> ogra_: thats actually a really good idea, I will do that
<mvo> ogra_: probably quicker too
<ogra_> HAHAHAHA !!!
<ogra_> (that was definitely not meant serious ... but if it helps :)  )
<lool> mvo: I'm sure you're in love with the u-boot code base by now!  :-)
<sergiusens> elopio: time you learnt juju then :-P There's a tarmac charm fwiw
<ogra_> lool, how could anyone not be !
<elopio> sergiusens: why not? throw it to the pile of things to learn :)
<elopio> should be easy. We just need your tarmac config, give it to juju, and profit.
<mvo> lool: indeed
<mvo> lool: it still boggles my mind
<ogra_> haha
<ogra_> mvo, now you know how all of us arm hackers got into this mental state ;)
<mvo> lol
<sergiusens> elopio: https://jujucharms.com/u/tanuki/tarmac/trusty/0
<mvo> also  - /etc/fw_env.config - wuuuuut? how about fw_printenv -f /boot/uboot.env ?
<mvo> I mean, seriously?!?
<ogra_> would be lovely
<sergiusens> elopio: but it seems to be more popular on precise https://jujucharms.com/u/canonical-ci-engineering/tarmac/precise/29
<elopio> sergiusens: no precise please.
<elopio> I can try both.
<kyrofa> seb128, I could use a terminal in the Ubuntu Personal image. It doesn't seem that I can install the one from the click store?
<seb128> kyrofa, no clue about that
<seb128> don't ask me
<seb128> I usually ssh in
<seb128> or switch to a vt
<kyrofa> Me too... but I need the dbus session variables
<seb128> grep SSH in /proc/pidof unity8-dash/environ
<seb128> then export
<kyrofa> seb128, ah, I always forget that trick
<mterry> Can snaps have symbolic links now?  They used to not be able to
<Chipaca> yes
<Chipaca> mterry: we fixed that before 15.04 release, i think :)
<beuno> I think 15.04 itself is symbolic!
<Chipaca> ur-symbolism ftw
<elopio> plars: I'm interested on that u-d-f to glance you mentioned.
<elopio> did you find anything?
<kyrofa> kgunn, quick update, since you were helping me on this: the touch-only areas don't seem to work with -mousetouch on mir
<plars> elopio: oh right, sorry I forgot to send you that
<kyrofa> kgunn, so to test other scopes you need to add them to the "favorites" list manually, with gsettings set com.canonical.Unity.Dash favorite-scopes
<plars> elopio: I think it's mostly here: https://launchpad.net/snappy-proposed-image-builder
<plars> elopio: you can talk to the ci team, not sure what their future plans are with that service
<elopio> plars: good, thanks!
<kgunn> kyrofa: ah, man that kinda stinks
<kyrofa> kgunn, yeah it does. Although the usability of the sliding drawer with a mouse kinda sucks anyway. Will that be changed a bit eventually for windowed mode?
<kgunn> yeah, i think we should
<kgunn> kyrofa: we're putting some time in on windowed mode, lemme see if it's something we can do
<kyrofa> kgunn, awesome. I'm not aware of other "touch areas" in unity8, but I'm sure there are some. We obviously need to figure out how to work with those, even if it's something as simple as making -touchmouse work on mir
<kyrofa> kgunn, which may not be trivial, I'm not sure
<kyrofa> kgunn, Ubuntu Personal may be in a bit of a tough spot. Correct me if I'm wrong, but we envision it being used on both mouse- and touch-driven devices, yes?
<kgunn> kyrofa: yep, this is just lack of design input, but mzanetti just made some noise...and we got the general ideo
<kgunn> idea
<kgunn> close enough that we can add something in the near term
<kgunn> (while design designs)
<kyrofa> kgunn, cool!
<mvo> ogra_: https://github.com/mvo5/uboot-env-go needs some love and better cmdline parsing but works
<mzanetti> kgunn, kyrofa: this should help: https://code.launchpad.net/~mzanetti/unity8/unity8-clickable-bottom-edge-hint/+merge/265019
<ogra_> mvo, sexy !
<kgunn> mzanetti: curious, is it something we can land ? e.g. should only show up in windowed mode
<mzanetti> yep
<kgunn> cool
<mvo> ogra_: yes, dinner time now :)
<mzanetti> kgunn, visuals don't change at all. The label arrow is clickable with a mouse (not with touch)
<mvo> ogra_: but the other stuff will also work, so I hope you are not blocked, lets continue tomorrow
<ogra_> mvo, same here ... and i might not return today ...
<ogra_> yeah
<mvo> enjoy!
<kgunn> ack
<ogra_> you too !
<kyrofa> mzanetti, quick work man, thanks!
<mzanetti> kyrofa, np. please let me know if you notice and oddities
<mzanetti> kyrofa, it's not perfect, the label will hide when scrolling (as per touch design) but while it's there you can click it an open the overview
<kyrofa> mzanetti, yeah, that's fine to get us up and running a bit better :)
 * mterry works on java snapcraft plugin
<mterry> sergiusens, tarmac seems to have not gotten to https://code.launchpad.net/~mvo/snapcraft/python3-project/+merge/264521 after 4 hours (it's usually faster, right?)  is there a problem with the branch or am I just impatient?
<rsalveti> mterry: no commit message I'd guess
<mterry> rsalveti, duh of course.  I want an error for that
<mterry> rsalveti, that's fine, I found a nit anyway  :)  yay for not merging yet
<rsalveti> cool
<sergiusens> mterry: yeah, mvo uses lp-propose which tells you it's setting a commit message when in reality it is setting a description :-)
 * mvo adds commit message
#snappy 2015-07-17
 * conyoo good morning o_O
<fgimenez> good morning
<JamesTait> Good morning all; happy Friday, and happy Yellow Pig Day! ð
<mvo> ogra_: I think we are getting somewhere https://github.com/mvo5/uboot-env-go might be simpler for us than fw_setenv/printenv and we can use it directly, but I will stop on that for now and wait how the rest of the uboot env work goes
<ogra_> mvo, yeah, i'm fiddlin with a snap currently to have the needed bits (and i also did a new checkout of the latest uboot before producing the new binary)
<mvo> ogra_: nice
<ogra_> mvo, wget http://people.canonical.com/~ogra/snappy/bootloader/beagleblack_1.9_all.snap && sudo ubuntu-device-flash core --channel=edge --oem beagleblack_1.9_all.snap --developer-mode -o bbb.img 15.04 ... then dd it ...
<ogra_> it has all env vars inside the uboot.env and ships an empty uEnv.txt (i think snappy still checks for that file to determine if we boot uboot)
<ogra_> boots fine for me
<ogra_> mvo, http://paste.ubuntu.com/11892121/ is the content of my input file for uboot.env
<ogra_> (note there is nothing from snapy-system.txt in it yet)
<mvo> ogra_: hm, we need that snappy-system.txt in there too, no?
<ogra_> yes, and the stamp
<mvo> ogra_: yeah, uEnv.txt is currently needed, my branch fixes that (or will)
<ogra_> but that requires changes to udf
<mvo> aha, is that writing it?
<ogra_> i think so ... sergiusens should know
<mvo> so udf would basilcy have to take the uboot.env and append the new bits from the oem snap (?)
<mvo> out uboot.env with all the default config
<mvo> if so I add a task for that to the card
<ogra_> well, the above is only the basic bit, with that we should have a good image to do the further work
<mvo> ok
<mvo> so the uboot.env will just load the snappy-system.txt (?)
<ogra_> i guess we *could* just put the snappy-system.txt content inside uboot.env at the snap level
<mvo> I guess thats fine, we may even keep that if its just reading from that file, i.e. as long as we keep the system_ab and stuff out
<ogra_> i would like to get rid of all these scattered single files ...
<mvo> the important part is that the uEnv.txt needs to no longer take the stamp into account and instead a new trail boot var
<mvo> yeah, agreed
<ogra_> the question is, do we want  that for 15.04
<ogra_> or do we just want the very basic bits for 15.04 to not risk stability
<mvo> thats a good question, my gut feeling is yes, the amount of churn is already pretty substancial, so best to have 15.04 and 16.04 in sync
<ogra_> (whouch would mean only snappy_ab and the stamp inside the env
<ogra_> ok, then we need udf involvement i thinnk
<ogra_> and either write the snappy-system.txt content to the uboot.env directly ... or have the file content in the snap (not sure why we dont have that currently, there might be a reason)
<mvo> I guess the reason is to keep snappy-system.txt bits small
<ogra_> i'm a little curious what happens to the env settings that come from ATAGs ... once we call "saveenv" they will be stored in uboot.env
<ogra_> (MAC address and the like ... nothing that chnages anyway, but i wonder if uboot will get alon with them being already set)
<mvo> ATAGs?
<ogra_> well, or values from the dtb ... not sure, but there are like 10 vars set by default even without any environment
<mvo> aha
<mvo> ok
<ogra_> and saveenv during the boot will save them in uboot.env
<ogra_> (and i dont thin there is something where you can only save a single var change to the environment, afaik it is all or nothing)+
<sergiusens> mvo: ogra_ that is automatic already (if the file is listed)
<ogra_> sergiusens, "that" ?
<sergiusens> ogra_: uboot.env copy from udf
<ogra_> sergiusens, yeah, thats not the issue
<ogra_> sergiusens, we need to feed the content of snappy-system.txt into uboot.env
<ogra_> and afaik thats created by udf, no ?
<sergiusens> ogra_: yes
<ogra_> so it needs to learn about that ... or we move snappy-system.txt content directly into the snap
<sergiusens> ogra_: you should be able to override it by adding it to the gadget (and that would be supported in uprgades for rolling at least)
<ogra_> (meaning directly into uboot.env at creation time)
<ogra_> so i could ship an empty file ... and in parallel push the content into uboot.env
<ogra_> hmm
<ogra_> sounds doable
<sergiusens> ogra_: this might put some stress in mvo's work into doing the right thing (TM) inside snappy on upgrades, but he's smart ;-)
<ogra_> yeah, snappy needs to modify uboot.env
<ogra_> instead of the txt files
<ogra_> hrm
<sergiusens> ogra_: right, but it needs to save the snappy-system.txt values before overwritting it, that's all
<ogra_> and we need to completely re-write the whole logic of the snappy_boot command
<ogra_> sergiusens, we can just have "snappy_stamp_last", "snappy_ab_last" and "snappy_mode_last" vars if we need that
<ogra_> and have snappy store the values inside uboot.env too
<ogra_> i want to get rid of all additional files
<ogra_> at least for rolling (not sure we fcan for 15.04)
<mvo> ogra_: do we need to change it all? grub is also doing it with a single env, it seems we can copy that behavior for now. and yes +1 for snappy_ab_last etc
<mvo> ogra_: thats going to be needed anyway for the os/kernel snap work
<mvo> ogra_, sergiusens: sound I need to write some uenv merge code, let me do that
<ogra_> mvo, whats "it" ?
<ogra_> do you mean snappy_boot ?
<ogra_> we need to et rid of the fatwrite call in it at least ... and also change the testing for snappy_stamp ... since it wont be a file but a variable value now
<mvo> ogra_: right, there is a snappy_trial_boot env in grub, one sec and I give you the details
<mvo> ogra_: ok, so grub works like this: on boot grub itself sets snappy_trial_boot=1 and the boot-sucesss command in snappy clears that
<mvo> ogra_: we could simply do the same for uboot now, right? my branch for snappy implements this cleaning in uboot now too
<ogra_> yeah
<ogra_> i'm just preparing a snap with merged snappy-systerm-txt (and an empty .txt file)
<mvo> silly question, whats the canonical location for uEnv.txt?
<mvo> ogra_: coool!
<ogra_> (still using the old snappy_boot command though)
<mvo> ok
 * ogra_ wishes for faster dd
<ogra_> *twiddle*
<ogra_> yay, seems to boot
<ogra_> bah
<ogra_> sergiusens, udf doesnt seem to respect the empty snappy-system.txt file ...
<ogra_> i still have content in it
<ogra_> http://paste.ubuntu.com/11892317/
<ogra_> sergiusens, ^^^
 * ogra_ empties it manually ... crosses fingers and reboots
<ogra_> looks like it boots
<sergiusens> ogra_: k
<ogra_> geez !
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ cat /boot/uboot/snappy-system.txt
<ogra_> snappy_mode=regular
<ogra_> snappy_ab=a
<ogra_> still writes to it somewhere
<sergiusens> ogra_: you need a new snappy which mvo is taking care of I gues
<sergiusens> s
<ogra_> ah, it writes that file after boot ?
<sergiusens> ogra_: yeah, with the snappy-boot task
<ogra_> k
<sergiusens> or snappy booted
<ogra_> well, but udf needs fixing too
<sergiusens> ogra_: yes; but it is going to be hard to fix as we need to support older images too :-/
<sergiusens> ogra_: that use that snappy logic
<ogra_> well, just make it not create the snappy-system.txt file if the snap ships it
<ogra_> that would be anough
<ogra_> *enouh
<ogra_> bah !
<sergiusens> ogra_: right, but think of 15.04 and creating older images which still use the older snappy logic
<ogra_> i only think of 15.04 here
<sergiusens> ogra_: 15.04 rev 1 then
<ogra_> right
<ogra_> but there the snaps dont ship snappy-system.txt at all
<ogra_> so that should be safe
 * ogra_ would really like to know why he only gets the colored "OK" output every second boot 
<sergiusens> ogra_: right, but if we replace it from u-d-f and the old snappy logic is in place, rollbacks and upgrades would be broken
<ogra_> hmm
<mvo> where is the cannical uEnv.txt location? do we have that in git somewhere?
<ogra_> in the snap
<ogra_> (snappy-hub i think... )
 * ogra_ hacks the loading of snappy-system.txt out of uboot.env ... lets see if it gets along, then the content wont matter 
<ogra_> and more dd fun ...
<mvo> ogra_: try godd - it has a progress bar :)
<ogra_> mvo, and that makes it faster ?
<ogra_> :P
<mvo> ogra_: weeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeel
<ogra_> :D
<mvo> ogra_: do you want me to build you a snappy with boot-success that uses snappy_trial_boot?
<ogra_> well, if that can write to uboot.env already
<mvo> it can using fw_setenv, but I can make you a better (native) version I think that does not need /etc/fw_env.config
<ogra_> with your ned code ? yeah
<ogra_> *new
<mvo> yep
<mvo> ogra_: eh, sorry, I mean, whats the canonical location of snappy-system.txt ? i.e. the file that implements the actual logic?
<ogra_> mvo, on disk it is /boot/uboot/snappy-system.txt ... in udf i dont know
<ogra_> if this dd ever finishes i'll know if we can boot completely without it
<mvo> ogra_: right, udf was the bit that I was looking for, thanks! i.e. in what version control system it is
<mvo> thanks!
 * sergiusens celebrates an exit status 2 on snappy install
<ogra_> looks good !
<mvo> sergiusens: you were on fire yesterday? so many branches
<ogra_> (the boot i mean)
<sergiusens> mvo: well none are really ready for review, I just got scared that I'd lose my laptop somehow and have to redo stuff :-P
<mvo> lol
<ogra_> i updated http://people.canonical.com/~ogra/snappy/bootloader/beagleblack_1.9_all.snap ... snappy-system.txt shouldnt be used at all anymore with that
<ogra_> (now we have snappy_stamp left)
<mvo> near
<mvo> neat
<mvo> !
<ogra_> so we shouldnt need changes to udf
<ogra_> (it is just ugly that the file sticks around but wont do harm)
 * ogra_ notes it might be time for some breakfast
<ogra_> :P
<ogra_> brb
<ogra_> bah, crap, forgot the meerting ... no food for me then
<mvo> ogra_: highly untested, but http://people.canonical.com/~mvo/tmp/snappy will use /boot/uboot/uboot.env  to set snappy_ab, snappy_mode and snappy_trial_boot
<ogra_> mvo, i assujme i replace /usr/bin/snappy with that ?
<mvo> ogra_: yes
<ogra_> [FAILED] Failed to start Notify bootloader that boot was successful.
<ogra_> [FAILED] Failed to start Run snappy firstboot setup.
<ogra_> [FAILED] Failed to start Run snappy compatibility hooks.
<mvo> ogra_: uh, thats the amd64 build
<mvo> ogra_: I need to give you the arm build of course
<ogra_> lovely :P
<ogra_> at least we know it still boots to a prompt even with broken snappy binary :P
<ogra_> ogra@anubis:~/datengrab/rpi/uboot/bbb$ file snappy
<ogra_> snappy: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=faa20b2d15c5c16533f51239a2a517f78db36dd6, not stripped
<ogra_> heh, yeah
<mvo> ogra_: armhf version is upload
<mvo> ogra_: armhf version is uploading
<ogra_> cool
<mvo> ogra_: try http://people.canonical.com/~mvo/tmp/snappy_armhf
<ogra_> mvo, looks good, no failures this time
<mvo> ogra_: cool, will a binary that can dump the env help?
<mvo> ogra_: to verify that it works?
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ cat /boot/uboot/snappy-system.txt
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$
<ogra_> and it didnt write to the file :)
<ogra_> yeah, that might help
<ogra_> i guess to test the whole update/rollback stuff i need to build a -1 image
<ogra_> (and even then i'm not sure i can actually update)
<mvo> ogra_: http://people.canonical.com/~mvo/tmp/uboot-env-armhf
<mvo> ogra_: that uboot-env-armhf /boot/uboot/uboot.env print
<mvo> ogra_: hopefully works
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ ./uboot-env-armhf /boot/uboot/uboot.env print|wc -l
<ogra_> 70
<ogra_> mvo, looks good
<mvo> ogra_: does the content look ok too? i.e. snappy_boot_trial is cleared (if you set it already)?
<ogra_> not sure a regular user should be able to run this :)
<mvo> ogra_: and try is set back to regular?
<mvo> ogra_: heh :)
<ogra_> mvo, http://paste.ubuntu.com/11892475/
<mvo> ogra_: that looks good can you try "uboot-env-armhf /boot/uboot/uboot.env set snappy_mode=try", then reboot, then see if the boot sets it to "snappy_mode=regular" after the boot?
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ sudo ./uboot-env-armhf /boot/uboot/uboot.env set snapy_mode=try
<ogra_> panic: runtime error: index out of rang
<mvo> ups, sorry
<mvo> ogra_: that looks good can you try "uboot-env-armhf /boot/uboot/uboot.env set snappy_mode try"
<mvo> has to be two args
<ogra_> doesnt work :(
<mvo> same error?
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ sudo ./uboot-env-armhf /boot/uboot/uboot.env set snapy_mode try
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ ./uboot-env-armhf /boot/uboot/uboot.env print|grep ^snappy_mode
<ogra_> snappy_mode=regular
<ogra_> no error ...
<mvo> uh
<ogra_> oh
<ogra_> bah
 * ogra_ tries without typo 
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ sudo ./uboot-env-armhf /boot/uboot/uboot.env set snappy_mode try
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ ./uboot-env-armhf /boot/uboot/uboot.env print|grep ^snappy_mode
<ogra_> snappy_mode=try
<mvo> :)
<ogra_> works without PEBKAC
<ogra_> ;)
<mvo> puhhh, I was scared for a minute
<kyrofa> kgunn, another change we might want to consider making for Ubuntu Personal: Disable the automatic reboot
<kyrofa> kgunn, just make the power button red or something
<kgunn> kyrofa: sorry...automatic reboot ?
<kyrofa> kgunn, yeah, Ubuntu Core seems to be configured to automatically update and reboot. Which makes a certain amount of sense for embedded devices
<kyrofa> kgunn, but I'm not sure how much sense it makes for Ubuntu Personal (which still seems to be configured that way)
<kgunn> seb128: ^ not sure who we'd talk to...i mean i guess this is based on our touch update technology, and it doesn't autoupdate/reboot afaik
<seb128> kgunn, kyrofa, does it really make more sense for an embedded device? depends what the device is doing
<kyrofa> kgunn, yeah, heads up-- first few times you fire up the VM and try to ssh in only to see "snappy autopilot triggered a reboot to boot into an up to date system" or "Going down for a reboot" it catches you a bit by surprise :P
<seb128> if that's your car engine control you don't want it to reboot while you are driving :p
<kyrofa> seb128, oh it certainly depends!
<kyrofa> seb128, but I can see it making sense for a router or something. Keep it up-to-date and secure
<kyrofa> seb128, if it was up to me, I'd definitely not make it the default on anything
<kyrofa> seb128, but it seems to be that way on Ubuntu Core, at least for the time being
<kyrofa> seb128, wait... maybe that's an edge thing?
<seb128> kyrofa, even a router, it might be on a critical infrastructure that should get package cut even for 10 secondes
<seb128> unsure
<kyrofa> kgunn, seb128: This may be a non-issue if it's only on edge. sergiusens can answer for sure
<kyrofa> seb128, agreed on the auto-updates. Tough to make that case
<seb128> yeah
<seb128> how can we turn it off? do you know?
<sergiusens> kgunn: kyrofa seb128 I'd discuss the issue with the architecture team
<sergiusens> snappy config ubuntu-core config_with_ap_disabled
<seb128> do we have a way to ship a different default config on the image?
<seb128> or a standard place in livecd-rootfs or such to call that
<mterry> mvo, I know you're busy today, but if you have time, I have some snapcraft branches I'd love some action on
<sergiusens> seb128: create your own gadget snap
<sergiusens> seb128: and have u-d-f pull that in instead of generic-amd64
<seb128> just for that?
<seb128> hum
<seb128> that sounds like more work that the change is worth
<seb128> kyrofa, kgunn ^
<kyrofa> seb128, hum indeed
<sergiusens> gadget snaps are exactly for that, configs
<kyrofa> seb128, depends on what's in generic-amd64 though. Might not be too bad
<sergiusens> seb128: I bet you will diverge more (e.g.; seed in some preinstalled snaps)
<kyrofa> seb128, yeah, we may need to do that eventually anyway
<seb128> sergiusens, that's probably true yeah
<sergiusens> seb128: the gadget snap is like the custom tarball on the phone
<sergiusens> except that it is declared and not just overlayed
<seb128> sergiusens, yeah, those are things I didn't look at so far and I've no clue about
<seb128> so I guess it's a good time to learn about them ;-)
<sergiusens> seb128: don't look too deep though, ricmm is redefining it all
<seb128> k
<sergiusens> seb128: some things may move back to the kernel snap (as we had it before)
<tedg> mterry, So, did you have thoughts about editing the package.yaml in snapcraft?
<tedg> mterry, It seems like something we're gonna need, and probably in a generic way.
<mterry> tedg, how do you mean editing?
<tedg> mterry, For instance having a plugin add a binary
<tedg> mterry, But also adding the architecture
<mterry> tedg, oh... I guess I imagined the user would explicitly add binaries and such they wanted -- it's hard to do automatically.  There's caps and maybe calling the binary something different, etc
<tedg> mterry, So Chipaca was thinking that the QML plugin would get the QML file, and then add a binary for it that was the execution of qmlscene.
<tedg> mterry, I think that's a reasonable use case, and there'll probably be others. For instance if a plugin added tools.
<rsalveti> ogra_: so to test if you get the fs corruption or not try image 3 from alpha
<rsalveti> and update/rollback to image 5
<ogra_> rsalveti, right, not completely done yet
<ogra_> wget http://people.canonical.com/~ogra/snappy/bootloader/beagleblack_1.9_all.snap && sudo ubuntu-device-flash core --channel=edge --oem beagleblack_1.9_all.snap --developer-mode -o bbb.img 15.04 ... then dd it ...
<ogra_> that gets you a setup which doesnt use snappy-system.txt anymore ... but we still need to re-work snappy_boot to remove the fatwrite and need to integrate mvos snappy changes
<rsalveti> did we land the snappy changes from mvo?
<ogra_> not yet
<rsalveti> right
<rsalveti> and udf changes as well
<ogra_> i only managed to do an initial test before he left ... we'll work on it more once he returns
<ogra_> udf changes arent needed
<ogra_> only cosmetic
<rsalveti> but might be good to manually test it with the alpha release, to know if all the work we did will indeed not cause the fs corruption we had
<ogra_> (teh file will be created but not used by anything)
<mterry> tedg, so for that use case, we'd want an assemble_fixes() step or something?
<ogra_> right, once we have all bits ready i'll test alpha
<tedg> mterry, Yeah, or perhaps the "snap_file()" command would pass the current YAML as an object.
<tedg> mterry, So then everyone would update it and it gets written out once.
<mterry> tedg, well there's more they might want to edit, like the apparmor stuff maybe?   But for sure the yaml object is 99% case
<mterry> tedg, I don't think it semantically fits with snap_files(), but it is the same step
<mterry> tedg, edit_package()?
<mterry> tedg, we also might want to version our plugin interface, btw
<tedg> mterry, Yeah, I guess I figured it was the "final step" or perhaps with assemble.
<tedg> mterry, Sure, but let's wait until we have plugins that aren't in tree.
<mterry> tedg, no, snap_files() is actually called on 'snap' step, not 'assemble' one
<tedg> mterry, Yes, I was more suggesting where it might edit the packaging.
<mterry> tedg, ah.  Well so far we only copy the metadata into place during assemble.  But maybe we should actually do that during snap...
<mterry> tedg, maybe all the bits in assemble should really be in snap, so the user can muck with everything in its final position/state
<mterry> tedg, then assemble is truly just a snappy build call
<elopio> good morning.
 * mterry waves at elopio
<nuclearbob> is there a bug somewhere about gpio/i2c support that I can follow?
<tedg> mterry, Yeah, that makes sense to me.
<elopio> nuclearbob: there is not.
<elopio> nuclearbob: only a mailing list thread and the promise by ogra_ that he will let us know when it's ready. You can file one.
<ogra_> well, and it is a broader thin ...
<ogra_> *thing
<nuclearbob> ogra_: if subscribing to the list is the best thing to do, I can do that
<ogra_> the bugs is "adding support for overlay devicetree files" ...
<nuclearbob> elopio: thanks
<nuclearbob> oh
<nuclearbob> that does sound broader
<ogra_> it is ... and rather complex, since we look for a generic way and the boards function differently
<elopio> on my beaglebone I saw the /dev/i2c-0
<elopio> I'll play with that :)
<ogra_> i will have overlay support in the next rpi image (via manual hacks) but not yet on the beaglebone
<nuclearbob> okay, the rpi is what I'm looking for since I've got the orange matchbox
<ogra_> rsalveti, gah
<ogra_> so now i definitely know that fatwrite even messes up the uboot.env file
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ ./uboot-env-armhf /boot/uboot/uboot.env print|grep ^snappy_mode
<ogra_> 2015/07/17 14:29:29 readUbootEnv failed for /boot/uboot/uboot.env: bad CRC: 4063564654 != 861698245
 * ogra_ forgot to take the fatwrite out before reboot
<ogra_> ogra@anubis:~/datengrab/rpi/uboot/bbb$ ls /media/ogra/system-boot/a/
<ogra_> DTBS  HARDWA~1.YAM  INITRD.IMG  VMLINUZ
<ogra_> rsalveti, btw, that looks like the root cause of our corruption ^^^^
<ogra_> 8+3 ...
<ogra_> (after fatwrite )
<rsalveti> ogra_: sorry, what is the root cause?
<rsalveti> so fatwrite even when writing to a known file is already enough to cause the issue
<ogra_> rsalveti, seems the driver used by fatwrite doesnt support long filenames
<rsalveti> it actually does
<rsalveti> that's a consequence of fsck.vfat I believe
<ogra_> so the a and b directory content names get rewritten
<ogra_> oh, ok
<rsalveti> that doesn't happen all the time
<rsalveti> sometimes it stays fine, but fsck creates a FSCK0000.REC file
<tedg> Chipaca, so getting those modules added means my snap is now 190 MB
<ogra_> lovely
<ogra_> should we perhaps kick it out ?
<rsalveti> ogra_: so it looks like a combination of fatwrite + fsck
<Chipaca> tedg: hah
<Chipaca> tedg: I win, then
<Chipaca> tedg: you're copying too much stuff
<tedg> Chipaca, I have fonts ;-)
<rsalveti> so basically we got back to the initial issue
<rsalveti> and might need some fatwrite debugging
<ogra_> well, as expected ...
<ogra_> as i said, i forgot to take out the fatwrite stuff before rebooting
<ogra_> i just find it interesting that it even kills the blob if used like we did
<ogra_> (this wont happen once we're done)
<Chipaca> tedg: 70MB of fonts?
<tedg> Chipaca, You can never have too many emoji
<sergiusens> Chipaca: tedg put it in a squash
<Chipaca> tedg: ð¹
<ogra_> +1
<ogra_> squash as squash can !
<Chipaca> also ï¿½ with a ï¿½ of ï¿½
 * ogra_ wonders whyt kinds of fonts you all use ... i only get broken chars here 
<sergiusens> ogra_: it's on purpose ;-)
<Chipaca> ogra_: symbola + quivira cover most of the fun stuff
<sergiusens> Chipaca: oh rly?
<sergiusens> Chipaca: I thought this was a squashing pun :-P
<Chipaca> fonts are already compressed, fwiw
<Chipaca> ogra_: you just reminded me of my first 3d accelerator
<Chipaca> ogra_: :)
<ogra_> haha !
<ogra_> oh yeah, and the fun to get the dirver up
<elopio> fgimenez: ugh, that 91 tests depends on the 90 test. Are you ok if I just remove both?
<fgimenez> elopio, sure
<elopio> 91 in this case will just do a fake update, which we already have. And the 15.04_to_rolling branch fully replaces 91.
<fgimenez> elopio, yes, it's already covered
<fgimenez> elopio, i'm preparing a branch with the changes to main.go and the template
<elopio> fgimenez: not sure what you are talking about, but bring it on!
<fgimenez> elopio, :) for removing the includeShell code, i'll push it shortly
<elopio> fgimenez: I confirm that the RC test fails to reboot on latest rolling edge.
<mvo> ogra_: is there anything I need to do? i.e. are you blocked on me currently?
<fgimenez> elopio, yep i'll report it
<elopio> fgimenez: oh, good. Thanks for mentioning it, I was about to do the same. I give you the honors :)
<ogra_> mvo, well, land your stuff ... nothing beyond that ... i'll try to get the script bits done before EOD today ... the rest on monday then
<mvo> ogra_: ok
<fgimenez> elopio, :) thanks, done
<ogra_> mvo, so when turning snappy_stamp into a boolean we should be fine i guess ? starting with snappy_stamp=0 ... having the boot script set it to 1 (instead of touching the file) ... who sets it back to 0 ? (whi was responsible for deleting it from disk )
<mvo> ogra_: yeah, its snappy_trial_boot=1 in grub, would be good to just mimick that
<elopio> fgimenez: what do you think of moving all the tests to the tests directory?
<mvo> ogra_: so grub itself sets snappy_trial_boot=1 i in its environment on boot and then the boot-script clears that value
<elopio> if we have one single package, the filtering is easier.
<ogra_> mvo, for rolling for sure ... would we want to do that switch in 15.04 though ?
<ogra_> (reanming the var and all)
<mvo> ogra_: hm, good question, my gut feeling is yes, its a bigger change but at least its the same code path as grub and 16.04. and it will be different in any case from the previous version so the more uniform the better I would say
<fgimenez> elopio, mm at first we grouped them by the image they needed, hence the 'latest', 'update' packages, which translate to different binaries, i'm not sure if it's applicable yet?
<ogra_> mvo, ok
<sergiusens> mvo: ogra_ just convert the 0-1 into a counter
<elopio> fgimenez: oh, right. You'll have to read the 15.04_to_rolling first for this to make sense.
<ogra_> sergiusens, err
<elopio> we'll talk about it on monday.
<sergiusens> or is math not doeable in u-boot?
<fgimenez> elopio, ah ok
<ogra_> it is but that makes everything more complex
<sergiusens> ogra_: yeah, but we get counter failover which makes mvo happy ;-)
<ogra_> if test $snappy_stamp = 1; then ...
<sergiusens> not for 15.04 though
<ogra_> thats pretty trivial to add
<mvo> sergiusens, Chipaca: if one of you could review https://code.launchpad.net/~mvo/snappy/snappy-bootsuccess-env/+merge/264981 - that would be very cool, that would unblock ogra_
 * Chipaca looks
<sergiusens> mvo: not enough cleanup
<sergiusens> :-P
<mvo> sergiusens: followup branch ;)
 * sergiusens jokes
<sergiusens> mvo: oh, lol
<mvo> sergiusens: but totally agreed, there is so much more we can do now
<ogra_> dont ask me about go ... looks fine to me but that means nothing :P
<elopio> fgimenez: if you just leave a return at the end of a function, it will find the values it has to return?
<fgimenez> elopio, if they are named in the signature yes
<elopio> that is impressive.
<mvo> it does, but some people dislike this style
<fgimenez> elopio, coming from other languages a find it wonderful, yep :) anyway in this case it comes from the gocheck api, not sure if we have another options here
<Chipaca> elopio: also confusing, so don't do it* :)
<mvo> ogra_: I get some quick dinner, let me know if you need anything I will get to it when I return
<Chipaca> * unless you have good reason to ;)
 * elopio wants to approve this so much...
<ogra_> mvo, yeah, i dont think so ... will need to fiddle with the snappy_boot cmd now
<ogra_> (and i need some food myself)
<sergiusens> mvo: added questions
<elopio> fgimenez: I'll leave you the +1, you do the top approve when you update the return.
<Chipaca> mvo: lgtm, but sergio beat me to it :)
<sergiusens> mvo: elopio fgimenez boilerplate returns are ok if the function is small; but you shouldn't name vars if it only adds cruft and no meaning (e.g.; name these (string, string, string, error) but maybe not these (string, error))
<elopio> sergiusens: so better to keep the signature short than to use a bare return, that makes sense.
<sergiusens> elopio: go vet catches most of these btw
<fgimenez> sergiusens, ok, thanks, for implementing a custom checker here https://code.launchpad.net/~fgimenez/snappy/test-writable-paths/+merge/265110 i've seen this http://godoc.org/gopkg.in/check.v1#Checker, perhaps the interface can be satisfied without naming the return values?
<elopio> sergiusens: it seemed happy with the bare return version.
<sergiusens> elopio: fgimenez https://golang.org/doc/effective_go.html#named-results
<sergiusens> fgimenez: you don't need to name the return vals to satisfy an interface iirc
<sergiusens> fgimenez: elopio in any case, if it makes the code simpler and faster to read, it's a +1 to whatever ;-)
<fgimenez> sergiusens, or just "return result, error" as elopio mentioned? having them already defined seems to be handy
<kgunn> hey so, on a rolling core image, i do snappy search mir, i see it...then sudo snappy install mir  fails to install "snappy package not found"
<elopio> sergiusens: yes, that link basically says the opposite of what you said :)
<kgunn> what's up with that ^ ?
<elopio> kgunn: do you have the ens3 iface up?
<kgunn> yes
<kgunn> without it, i couldn't see results in search
<elopio> let me kill my instance and try.
<sergiusens> kgunn: didn't we have this conversation already? :-P
<elopio> it might need to add the origin.
<sergiusens> kgunn: there is no 'mir' package https://search.apps.ubuntu.com/api/v1/package/mir
<elopio> or that :)
<sergiusens> kgunn: https://search.apps.ubuntu.com/api/v1/search?q=mir does say there isa mir.mvp-demo with no alias
<sergiusens> which is not ok for a framework
<sergiusens> kgunn: I'd ask the store guys
<elopio> sergiusens: how do you add an alias ?
 * sergiusens pokes at nessita and beuno 
<kgunn> all news to me
<sergiusens> elopio: by being a store admin
<elopio> https://bugs.launchpad.net/snappy/+bug/1474658
<ubottu> Launchpad bug 1474658 in Snappy "Can't install hello-dbus-fwk: snappy package not found" [Undecided,Confirmed]
<kgunn> all i know is search returns "mir" and you can't install it
<elopio> kgunn: sergiusens: so it's the same bug ^
<sergiusens> elopio: so someone must of fiddled with the store database :-/
<elopio> either the search should return the origin, or it should be installed without an origin.
<sergiusens> elopio: yeah, https://search.apps.ubuntu.com/api/v1/search?q=hello-dbus-fwk no alias there
<sergiusens> elopio: no, frameworks without origin aren't allowed
<sergiusens> elopio: so the proper client solution is to not show them in the search results until they have an alias
<elopio> sergiusens: I mean that snappy install could append the origin to the name you pass. Just a suggestion, not saying it's good.
<elopio> sergiusens: ok, I like that too.
<elopio> fgimenez: so, I'd say "return result, error", because Chipaca finds it confusing. I was confused too when I read it. Handy, but maybe too fancy.
 * Chipaca is the receptacle of the truth, and as such, if he finds something confusing it is only because it *is* confusing
<elopio> no need to state the obvious :)
<elopio> sergiusens: can you give the the credentials for the snappy-tarmac user?
<kgunn> bbiab
<sergiusens> elopio: let me add your ssh keys
<fgimenez> elopio, ok done, much clearer now :)
<fgimenez> nice weekend everyone o/
<sergiusens> elopio: extending https://tour.golang.org/basics/7
<elopio> beuno: ev: is this something you will be supporting? https://launchpad.net/snappy-proposed-image-builder
<ev> elopio: no, that's legacy
<ev> elopio: CI works in images; it does not handle creating them. A service can be created for composing an image given some snaps, but the CI architecture won't know about its internals
<elopio> ev: ack. utlemming: what can we do to start a canonistack machine with the latest rolling edge?
<utlemming> elopio: rolling edge will be created sometime automatically and then published to Canonistack. One the build appears, you would launch it like you would any other Openstack instance
<elopio> utlemming: good. Is there an easy way to know the name of the latest image? Or do we have to grep for ubuntu-core and sort the date?
<ogra_> mvo, ok, http://people.canonical.com/~ogra/snappy/bootloader/beagleblack_1.9_all.snapshould now have workign logic ... it uses snappy_trial_boot as boolean (0/1) instead of the snappy-stamp.txt file ...
<mvo> ogra_: neat! where is the source for that? I would love to have a look
<ogra_> mvo, http://paste.ubuntu.com/11893726/ ... thats the input file used for uboot.env
<ogra_> http://paste.ubuntu.com/11893737/ has the steps i used
<ogra_> (beyond re-packing the .snap)
<mvo> ogra_: neat!
<mvo> sergiusens: thanks for your excellent feedback, I'm fixing now
<ogra_> with that we're ready for end to end testing on monday i think
<sergiusens> mvo: no worries, it only popped into my mind in retrospect of the grub work
<sergiusens> to avoid writing as much as possible :-)
<mvo> sergiusens: :)
<nessita> sergiusens, needing an alias?
<tedg> Uhg, I'm missing a variable somewhere.
<tedg> Chipaca, Did you ever get "qmlscene: could not find a Qt installation of ''"
<beuno> '' has been known to be hard to find
<tedg> I tried dividing by zero, but that didn't help.
<ogra_> hmm, telegram is dead on both of my phones
<tedg> ogra_, Thumbnailer issue, apparently they dropped the C++ lib
<ogra_> uuuh
<ogra_> oh, yeah http://people.canonical.com/~ogra/touch-image-stats/vivid/20150717.changes
 * ogra_ notes libsnappy1 in there :D
<ogra_> secretly sneaking into the phone :)
<kenvandine> plotting to take over the world
<ogra_> :D
<nessita> sergiusens, elopio, the store will not se any alias automatically, so if you need specific packages with alias, you should email Martin and me for us to set manually
<sergiusens> nessita: beuno it's aliases that WERE there and AREN'T anymore ;-)
<nessita> sergiusens, yeah? I would say "impossible", but tell me more :-)
<nessita> sergiusens, I personally never ever set an alias for mir
<sergiusens> nessita: at least hello-dbus-fwk had an alias
<nessita> perhaps beuno did, but lately he ask me to set alias
<beuno> I sometimes in my sleep change things to mess up sergiusens, yes
<sergiusens> nessita not sure about mir, all I know is that I told the people asking about it that it needs an alias
<sergiusens> beuno: lol
<nessita> sergiusens, what alias had hello-dbus-fwk set?
<sergiusens> nessita: aliased to hello-dbus-fwk
<nessita> sergiusens, and who setthe alias? (I didn't)
<sergiusens> nessita: I thought 'alias' is a gimmick, we always want it to be 'package_name'
<sergiusens> nessita: I have no idea! It worked, now it doesn't
<sergiusens> that's all I know
<sergiusens> nessita: and elopio reported a bug, I just saw it had no alias
<sergiusens> nessita: maybe we can just set it for hello-dbus-fwk and drink some scotch to forget this ever happened :-P
<nessita> sergiusens, so the only alias we have set are: generic-i386, generic-amd64
<sergiusens> nessita: what about webdm?
<nessita> sergiusens, we could do that, but I would like to know that the alias setting process is understood
<sergiusens> nessita: that did have an alias and made the arrangements to set it
<sergiusens> heh, yeah, webdm does have an alias
 * sergiusens wipes the sweat off his forehead
<nessita> as a summary: alias is set by hand by either beuno or matiasb or me, and we don't remove it unless explicitely asked for, and there is no automatic process to set one
<sergiusens> nessita: wrt the process, beuno promised me that oem and framework snaps would get auto aliased when getting approved into the store (he didn't say when though)
<beuno> sergiusens, FWIW, we're working on allowing al reviewers to set aliases
<beuno> like yourself
<sergiusens> beuno: great
<beuno> which we'll follow at some point with some automation
<beuno> but at least expand the group who can set it significantly
<sergiusens> beuno: great, because fwk and oem can't be forked
<mvo> Chipaca: libxkbcommon is uploaded to wily, I clone the repo for a pull-request now, lets see what upstream says
<sergiusens> nessita: in any case, I didn't ask for hello-dbus-fwk to be aliased, did not approve it into the store nor did I push it; I only noticed it is a framework and it is missing an alias :-)
 * sergiusens checks to see who approved hello-dbus-fwk and mir
<sergiusens> jdstrand: I see you approved hello-dbus-fwk into the store, did you ask any of the store guys to create an alias for it?
<sergiusens> jdstrand: ditto for mir. Bringing it up as they need to be aliased and it's not automatic
<jdstrand> sergiusens: I did not
<jdstrand> sergiusens: on either
<jdstrand> oh, I didn't realize that
<jdstrand> so, we must request that all new frameworks must have an alias?
<sergiusens> jdstrand: yes, it's all related to them not being able to have forks
<jdstrand> shouldn't the store just do that for us automatically?
<sergiusens> jdstrand: they have a task open (mentioned ^^)
<jdstrand> ok
<jdstrand> and yes, I understnad that frameworks can't have forks-- I just didn't realize we had to do the manual request
<jdstrand> but glad to hear that is being addressed too
<mvo> Chipaca: just fyi https://github.com/xkbcommon/libxkbcommon/pull/25
<tedg> jdstrand, I want to give my app access to /run/mir_socket, I don't see a cap for that, so do I just need to override for now?
<carif_> just confirming: if I were to install Ubuntu Core, I would get the same bits as Snappy Ubuntu core, but I'm using the debian packaging system, not snappy
<carif_> also, the file layout will be somewhat different because snappy operates a little differently. So I have /apps/**, I can have multiple versions installed, one of them being current and I can revert back to some prior version if I so choose
<carif_> the phone is somewhat different in that I run images on a device, say a nexus 4/7/10 and I use adb to push the images to the device and then ubuntu-device-flash to update it
<tedg> The phone and snappy are both image based, and ubuntu-core is basically the same, there are minor differences in the packages installed.
<jdstrand> tedg: there should be a mir_client policy group provided by the mir framework
<jdstrand> tedg: depend on the mir framework, then use mir_client
<tedg> Ah, it's in /var
<tedg> jdstrand, Thanks :-)
<jdstrand> np
<carif_> those packages are called "clicks" but clicks have been renamed to "snaps"
<carif_> tedg, ^^^ tar baby
<jdstrand> tedg: fyi, 'snappy-security list -V ubuntu-core' will show you what policy is available currently on the system
<carif_> will the phone eventually install its apps in /apps? etc?
<tedg> jdstrand, Oh, that's good to know. I just used "find" :-)
<jdstrand> find will work too :)
<tedg> carif_, Yes, in time phone applications will be snaps and the phone will be based on Snappy.
<carif_> tedg, ty
<tedg> jdstrand, Not if you start it in /usr â¦
<jdstrand> hehe, no
<carif_> tedg, when that transition happens will the phone utilities like ubuntu-device-flash be deprecated? So I will (say) snapp-remote a snap onto the phone?
 * carif_ isn't sure he's asking the question correctly
<tedg> carif_, No you can still use u-d-f to flash a phone from a raw state. But like it upgrades itself today, the snappy version will do the same.
<tedg> carif_, You could use snappy remote to upgrade/install a snap as well if you wanted. More an additional feature.
<carif_> vg, last question, in addition to finding snaps at the Ubuntu store, can I have my snappy device (kvm, etc) look for snaps on a local website? rather than using snap-remote to push a snap, I've like to do 'snappy install mikey' and have it find the snap on some local website
<carif_> tedg, ^^^ ... then I'll let you get back to work
<tedg> carif_, We're not going to support that out of the box, we want to do a lot with the store that isn't just "download a file" to make the updates smarter and faster. It's open source, and your device, and all that, but we'd really like people to put things in the store.
<tedg> Clearly you could write a shell script to do it if you wanted pretty easily.
<carif_> tedg, thanks dude
<tedg> There's also a ton of work going into the store so that you can have private stores and things like that.
<tedg> kgunn, I have Mir snap1, but I don't think that has the seccomp with the socketpair() in it, is there a more up-to-date snap?
<kgunn> tedg: i'm just now uploading actually
<rsalveti> tedg: mind giving a hand with some reviews? https://code.launchpad.net/~snappy-dev/snapcraft/core/+activereviews is quite a big list
<kgunn> tedg: but, yes y;day (i think) i took that change in from jamie
<tedg> kgunn, Upload faster! ;-)
<tedg> rsalveti, Sure, I'll give them a try. Still feel a bit like the student though :-)
<kgunn> tedg: actually...i just cancelled, gonna pull fresh and rebuild to make darn sure it's the right one
<rsalveti> tedg: :-)
<kgunn> rsalveti: so who is Mr. snappy store ?
<rsalveti> beuno: ^
<rsalveti> he's the store itself
<kgunn> lol
<beuno> I cp software into people's phone on demand
<kgunn> so i've got a new mir snap....and i altered the version to be "1.1" from "snap1"...so dropping the "snap"
<kgunn> and it no likie
<tedg> Because we love beuno we wrote snappy-remote to make his life easier.
<beuno> kgunn, it uses debian rules for versioning (for now)
<tedg> No more hand copying
<kgunn> ug, so i have to live with snap in the version string?
<beuno> you just want me out of a job
<beuno> kgunn, not really, you just need to make it newer from a debian versioning POV
<beuno> not sure what a character to integer path is
<beuno> kgunn, that will change in the next month or two
<kgunn> k, for now will just live with "snap" there....
<beuno> you'll be able to throw whatever you want as a version, and it'll do updates based on internal revision numbers
<beuno> but not yet, because phones use that to figure out if it's newer or not
<carif_> how long does it take for ubuntu-device-flash to update a device? And do I need need to "approve" the update on the device itself or is it just an adp think on my laptop?
#snappy 2015-07-18
<Chipaca> tedg: yes, i did get the 'no qt installation'
<Chipaca> tedg: you're using the qtchooser
<Chipaca> tedg: use qmlscene directly
<Chipaca> tedg: or, put the right qt config in your xdg config dir
<Chipaca> tedg: poke me if you want the latter
<tedg> Chipaca, Ah, I got it together. I have the qml plugin building the Qt configuration now.
#snappy 2016-07-18
<monsterjamp> Hey tsimonq2
<tsimonq2> monsterjamp: hey, what's your progress? :O
<tsimonq2> *:)
<monsterjamp> Well I passed all the checks, I'm not sure where to go from here. I guess I have to wait till one of the collaborators notices my pr?
<tsimonq2> monsterjamp: let me do a full review quick here, so I can see if I can spot anything they would :)
<tsimonq2> monsterjamp: have you signed the Canonical CLA?
<monsterjamp> Yeah but my launchpad username is different than my github one.
<tsimonq2> monsterjamp: can you indicate so in your PR description?
<monsterjamp> Alright
<tsimonq2> monsterjamp: can you link it here?
<monsterjamp> My launchpad account?
<monsterjamp> tsimonq2 https://launchpad.net/~filjoa
<tsimonq2> monsterjamp: no your PR
<monsterjamp> Oh :P
<monsterjamp> https://github.com/snapcore/snapcraft/pull/664
<mup> PR snapcraft#664: New plugin: Bash <Created by monsterjamp> <https://github.com/snapcore/snapcraft/pull/664>
<monsterjamp> Do most of the devs use Launchpad over GitHub?
<tsimonq2> well it depends
<tsimonq2> ...you aren't part of the Canonical CLA team in Launchpad?
<monsterjamp> I thought I signed it :/
<monsterjamp> One sec
<monsterjamp> tsimonq2 sorry for the long wait, I couldn't get passwords and keys program to work.
<monsterjamp> But I finally got the CLA signed
<monsterjamp> I think
<liuxg> does anyone know how to assign a hardware to a snap app? I tried to build the snap at https://github.com/snapcore/snapcraft/tree/master/demos/webcam-webui, however, the camera seems not opened, and I cannot capture any pics. thanks
<qengho> liuxg: "snap interfaces" and "snap connect"
<liuxg> qengho, how can I connect to the camera then? I used the command to connect the plug and slots. But I do not know how to connect to a camera
<qengho> liuxg: You connected the app to the "camera" interface?
<liuxg> qengho, oh, yeah, thanks. I did not notice the camera interface. I will have a try
<liuxg> qengho, so, it is something like something like: sudo snap connect foobar:camera ubuntu-core:camera, right?
<liuxg> qengho, for the webcam-webui case, it is like something like: sudo snap connect webcam-webui:camera ubuntu-core:camera, right?
<qengho> liuxg: Probably. All the pieces are in "snap interfaces" output.
<liuxg> qengho, yeah, previously, I did not see the "camera" interface there. thanks for your help!
<mup> PR snapd#1559 closed: network-observe: add device read support <Created by jaymell> <Closed by jaymell> <https://github.com/snapcore/snapd/pull/1559>
<mup> Bug #1603879 opened: Requesting additions to optical-drive interface for cdparanoia. <Snappy:New> <https://launchpad.net/bugs/1603879>
<liuxg> dholbach, ping
<dholbach> liuxg, pong
<liuxg> dholbach, how can I report a bug against the sample demo at https://github.com/snapcore/snapcraft/tree/master/demos/webcam-webui?
<dholbach> https://bugs.launchpad.net/snapcraft/+filebug
<liuxg> dholbach, the problem for the demo is that it misses the "camera" plug in the snapcraft.yaml
<dholbach> if that fixes it, you could send a pull request for it :)
<liuxg> dholbach, I think the tutorials for the docs both in the developer website and also the one in the documenthttps://github.com/snapcore/snapcraft/blob/master/docs/your-first-snap.md
<dholbach> ok
<liuxg> dholbach, I need to fork it first, right?
<dholbach> either that or just file a bug
<liuxg> dholbach, OK. I will file a bug first.
<dholbach> cool
<dz0ny> any idea on this one
<dz0ny> Uploading champ_0.0.1~git_amd64.snap [====================================] 100%
<dz0ny> Received 403: 'Developer profile is missing short namespace.'
<liuxg> dholbach, anyway, I have created a bug at https://bugs.launchpad.net/snapcraft/+bug/1603895
<mup> Bug #1603895: Missing "camera" plug in the webcam-webui sample app <Snapcraft:New> <https://launchpad.net/bugs/1603895>
<dholbach> dz0ny, do you need to head to https://myapps.developer.ubuntu.com/dev/click-apps/register-name/ maybe?
<dholbach> thanks liuxg
<liuxg> dholbach, you are welcome.
<pbek> ln: failed to create symbolic link
<pbek> sorry, I didn't want to paste that
<dz0ny> dholbach: thx :)
<pbek> Hi all, does anyone has an idea why the qownnotes snap doesn't use the native Qt theming even though the binary is called with `desktop-launch` and uses `desktop/qt5`? https://git.launchpad.net/~pbek/qownnotes-snap/tree/snapcraft.yaml
<pbek> -has +have
<pbek> dholbach: maybe you? :)
<dholbach> didrocks, ^ do you know? is this something pstolowski maybe figured out?
<cavan> Any good projects for a first snap?
<pbek> camako: https://uappexplorer.com/app/qownnotes.pbek ;)
<dholbach> davidcalle, nice work on the snappy report
<ogra_> snapport
<sborovkov> Hi. I've been running my snap on RPI without issues. But now I tried installing it classic image and getting this assertion. GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed; getpwuid_r(): failed due to unknown user id (0)
<sborovkov> any ideas why this can be happening?
<renatu> hey guys I am trying to install a new version of my snap app, but I got this error: error: cannot install snap file: snap "ubuntu-calendar-app" has changes in progress
<renatu> I tried abort the changes with: sudo snap abort 32
<renatu> it is saying the changes was aborted: 32   Abort   2016-07-18T12:23:40Z  -                     Install "ubuntu-calendar-app" snap from file "ubuntu-calendar-app_0.1_amd64.snap"
<renatu> but I am still not able to install the app
<dholbach> zyga, ^ do you know what renatu can do?
<mup> PR snapd#1560 opened: Drop warning about 2.0 API being different - we're already 2.0! <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1560>
<mup> PR snapd#1561 opened: many: remove integration-test coverage metrics  <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1561>
<mup> PR snapcraft#665 opened: Update broken links to https://snapcraft.io <Created by nottrobin> <https://github.com/snapcore/snapcraft/pull/665>
<willcooke> erk, I just ctrl-c'd the wrong terminal and interupted an installing snap and when I try install again it says there are changes in progress.  What do I do to fix it?
<balloons> dholbach, sure
<dholbach> balloons, what did you do and what's the error message?
<balloons> so whenever I do anything with snap, I get this error: sudo snap try prime/
<balloons> sorry, unless I use sudio I get: snap try prime/ error: access denied (snap login --help)
<dholbach> willcooke, it might be worth recording ("snap changes", etc.) the current state and let mvo, zyga and pedronis know
<balloons> it's a bit confusing and the help didn't really clarify things. I assume this is working as expected, but from the user side is confusing
<dholbach> willcooke, in the worst case, you'd need to use: https://github.com/zyga/devtools/blob/master/reset-state
<willcooke> thanks dholbach
<dholbach> balloons, what are you trying to do?
<balloons> dholbach, I made a snap, and now I want to iterate on it
<dholbach> balloons, afaik you shouldn't have to use "sudo" for "snappy try"
<dholbach> balloons, are any files owned by root now?
<balloons> dholbach, I installed it and had to use sudo or it gave me the error
<balloons> so if I shouldn't have to do that, then that's a bug I guess
<balloons> dholbach, well I can check. However, after installing, I couldn't find my new binary
<dholbach> can you remove the one that's already installed?
<balloons> (which is why I tried out 'snap try')
<dholbach> does "snap list" say?
<dholbach> does "snap list" list it?
<dholbach> and it's worth using "snap login" :)
<kyrofa> willcooke, snapd is actually two things: a client and a server
<balloons> snap list does list the one I installed with 'try'
<kyrofa> willcooke, ctrl+c'ing the client currently only cancels the displaying of the install-- not the install itself (which happens server-side)
<kyrofa> willcooke, this is a bug
<kyrofa> willcooke, if you run `snap changes` you'll see the installation still happening
<willcooke> kyrofa, ah! cool  Oki, so it says...
<willcooke> 105  Done    2016-07-18T13:53:57Z  2016-07-18T13:55:33Z  Install "libreoffice" snap from "beta" channel
<willcooke> so that's probably good news
<willcooke> and indeed it is!  It runs!
<kyrofa> willcooke, you can wait for it to finish, or you can abort it with `snap abort <change id>`
<willcooke> kyrofa, we're all good. thanks
<dholbach> balloons, can you remove it, then do snap login and then snap try without sudo?
<kyrofa> willcooke, no problem, just wanted to make sure you had the full picture
<dholbach> and maybe check if some of your files are now owned by root :)
<balloons> dholbach, I was under the impression I didn't need an account to use snappy. What would I login as?
<kyrofa> popey, are you in a session right now?
<dholbach> balloons, you don't have to, but it's nice to use it with the ubuntu store (just like the phone)
<dholbach> it's just normal sso
<balloons> dholbach, I'm assuming it will "fix" my issue, but it seems like there is a bug then if I can't do this without logging in?
<dholbach> let me try to log out and use 'snap try' just like that
<dholbach> I find it very convenient, so I never tried
<dholbach> (and I'm not hacking on snapd, so I don't know specifics :-))
<dholbach> ok, so logging out, I have to use "sudo snap try prime/"
<dholbach> and it works just fine
<balloons> dholbach, ok. So is that "expected" behavoir?
<balloons> sounds like I should just open a bug and see what the feedback is
<mup> PR snapd#1562 opened: many: cleanup/update rest.md; improve auth errors <Created by chipaca> <https://github.com/snapcore/snapd/pull/1562>
<dholbach> I think I'd rather send a mail to the list
<dholbach> especially if you don't know if it's a bug
<dholbach> let me see if I can find anything in the docs about this
<dholbach> "snap login --help" says http://paste.ubuntu.com/19901483/
<dholbach> so yeah, use "sudo" if you really don't want to use "login"
<dholbach> if "try" then still doesn't work, then that's a bug (if the prime/ directory of your snap is not broken)
<mup> Bug #1604016 opened: Snap requires sudo if not logged in <Snappy:New> <https://launchpad.net/bugs/1604016>
<dholbach> ...
<balloons> dholbach, I did see snap login --help, but I didn't find the help to be very clear
<balloons> (though obviously I did manage to figure it out and using sudo aligns well with the traditional apt experience)
<dholbach> ok, I think the bug is fair with regard to expecting a clearer error message
<Cavan> I just finished the 'Your first snap' on the Ubuntu website, how to I actually run the snap, I tried the commands and there not working...
<dholbach> balloons, does the snap work when you "try" it?
<balloons> dholbach, ty. Feel free to mark won't fix, etc. I may be the only one who missed the boat on it :-)
<dholbach> Cavan, which command fails?
<dholbach> balloons, no, sorry - I think the bug is quite fair :)
<balloons> dholbach, snap try prime does stuff, then prints a display showing the output of snap list with just my snap listed. That said, I think it's the snap. I have binaries in prime/bin, but there don't seem to be any executed
<Cavan> I may be doing something wrong, followed all the steps and completed in but cant figure out how to run it. 'command: bin/webcam-webui' Is the only command in the.yaml
<dholbach> balloons, does the snap contain a service or an app?
<dholbach> balloons, can you pastebin the snapcraft.yaml?
<dholbach> Cavan, it's supposed to run a service
<balloons> dholbach, http://paste.ubuntu.com/19902241/. This is another attempt at snapping juju. snapcraft handled it well enough it seems. hat snapcraft.yaml file is from like April :-)
<dholbach> Cavan, can you try to add 'camera' to the plugs definition?
<dholbach> balloons, can you just run ./prime/bin/juju --help?
<dz0ny> Cavan: if you have fresh install of snapd you have to reboot device
<balloons> dholbach, yes I can. Binary seems fine
<dz0ny> it needs to setup some discovery stuff for your profile :)
<mup> PR snapcraft#666 opened: Allow / in parts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/666>
<dholbach> balloons, if you have the juju Ubuntu package installed, it will trump whatever snap provides it ("which juju" should confirm)
<ratliff> if I am creating a snap for a project that uses a custom build script, do I have to create a script plugin or is there an existing plugin that will work?
<dholbach> sergiusens, ^ nice PR # :-P
<Cavan> dholbach, I think its already in the plug definitions, I can link you the website if you like? dz0ny, reboot my pc?
<dholbach> ratliff, yes, a custom plugin sounds sensible (https://developer.ubuntu.com/en/snappy/build-apps/plugins/)
<balloons> dholbach, blargh. /snap/bin/juju, not $SNAP/bin/juju
<balloons> makes more sense
<dz0ny> mhm, or just logout&login
<zyga> renatu, dholbach: sorry :/
<dholbach> Cavan, https://bugs.launchpad.net/developer-ubuntu-com/+bug/1600122 was filed earlier and I hadn't had time to look at it yet
<mup> Bug #1600122: Cannot successfully build the webcam-webui example on 16.04 <snap-docs> <Ubuntu Developer Portal:New> <Snapcraft:New> <https://launchpad.net/bugs/1600122>
<renatu> zyga, rebooting the machine did the trick :D
<dholbach> renatu, nice :-)
<ratliff> thanks, dholbach! next question: if I have a build config file (silently answers questions that the custom build script asks), does it exist in the directory next to snapcraft.yaml or should I store it elsewhere?
<Cavan> dholbach, I'm not receiving any errors, I just cant figure out how to run the service after the snap is complete
<dholbach> ratliff, where does your build script expect it?
<dholbach> Cavan, ok, let me try it too
<dholbach> Cavan, if you install it and do "ps afxvw | grep cam" - what do you see?
<ratliff> in the same directory as the build script. top level directory after the tarball is expanded
<dholbach> ratliff, ok, in that case just put it in the same dir
<Cavan> dholbach, ps afxvw | grep cam 26675 pts/1    S+     0:00      0   200 21099   960  0.0          |       \_ grep --color=auto cam 26665 ?        Ss     0:00      0     0  4508   796  0.0 /bin/sh /snap/test-snap/x2/bin/webcam-webui
<dholbach> ok, so the webui is running
<ratliff> do you mean copy it in after the tarball is expanded?
<Cavan> dholbach, is there anyway to view it, like an actual UI or something?
<balloons> dholbach, thanks for your help! When I'm in devmode, should I expect any differences between the binary in prime, and my snap binary?
<kyrofa> jdstrand, I'm having a snappy-debug issue: http://pastebin.ubuntu.com/19903287/
<dholbach> Cavan, looking at it right now - give me a minute
<balloons> dholbach, (I ask because clearly I'm seeing failures that only happen running the snapped version)
<dholbach> balloons, some, but I don't know specifics
<balloons> dholbach, brillant. So I'll work on solving them then. ty
<dholbach> balloons, you can use snappy-debug.security (from the store) to see failures logged
<ratliff> jdstrand is still supposed to be on vacation today
<ratliff> ^^ kyrofa
<kyrofa> ratliff, ah, thanks for the heads up
<dholbach> balloons, I think Jamie once wrote a mail to explain how it works and what exactly is different, but I can't find it right now - it'd be great to add that answer to http://askubuntu.com/questions/783945/what-is-devmode-for-snaps
<SamYaple> is there a way to host a private snappy repo that the `snap` tool can interact with yet?
<zyga> dpm: hey, do you want to meet and talk about day wrap up summay?
<zyga> summary*
<dholbach> kyrofa, does the webcam-webui work for you?
<balloons> dholbach, snappy debug showed me the app armor denials, which correspond to the issue I see. Thanks
<dholbach> balloons, cool
<mup> PR snapd#1563 opened: Hardware observe <Created by cwayne18> <https://github.com/snapcore/snapd/pull/1563>
<Croepha> SamYaple: I haven't tried it yet, but this looks fresh: https://github.com/noise/snapstore
<SamYaple> Croepha: so thats not official, but a RE of the apis. Worth following
<Cavan> dholback, any luck or should I just move to a different project for now?
<Cavan> dholbach*
<dholbach> ratliff, yep, that sounds good
<dholbach> Cavan, you could have a look at the other examples in https://github.com/ubuntu/snappy-playpen or https://github.com/snapcore/snapcraft/tree/master/demos
<dholbach> Cavan, they should give you a good idea of what's all possible
<dholbach> and ideas for your own project :)
<Cavan> dholbach, cool thanks
<dholbach> :-)
<thurston> i'm trying to make a snap package from a single executable binary (the output of a game engine),  however I can't seem to get it to work.  I can make the snap package, however when I install it and run the command to execute the program, it segfaults
<jibel> renatu, Hey I heard that you met this error while building the addressbook http://paste.ubuntu.com/19906424/
<jibel> renatu, do you have a workaround?
<dholbach> thurston, can you install 'snappy-debug' from the store (snap install snappy-debug) and run 'snappy-debug.security scanlog' and then run the snap again and see what happens?
<dz0ny> thurston: you will probably need bunch of dri,x11 libs in package too
<dholbach> thurston, I could imagine that it's an apparmor/seccomp denial
<dholbach> or what dz0ny said... missing deps(?)
<thurston> snappy debug?  i'll check it out
<dholbach> it's good stuff :)
<thurston> okay i have snappy-debug,  how to use it?
<thurston> can't even figure out what the man page is
<dholbach> "snappy-debug.security scanlog"
<dz0ny> dholbach: on that note, how would you enable access to specific libraries on host, like rpi video drivers in /opt/vcore ?
<dholbach> run that in one terminal, and run your app in another
<dholbach> dz0ny, I have no idea - I'd probably ask on the snapcraft list :-/
<thurston> OKAY
<thurston> looks like an apparmor problem
<thurston> Log: apparmor="DENIED" operation="connect" profile="snap.rpgdiceroller.rpgdiceroller" pid=24743 comm="rpgdiceroller" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/tmp/.X11-unix/X1" peer="unconfined"
<dholbach> thurston, add the x11 plug and rebuild the snap
<balloons> dholbach, thoughts on Log: apparmor="DENIED" operation="bind" profile="snap.juju.juju" pid=11972 comm="juju" family="unix" sock_type="stream" protocol=0 requested_mask="bind" denied_mask="bind" addr="@/var/lib/juju/mutex-/store-lock"? It seems like seccomp allows me to bind, but the /var/lib/juju is a no-no. How can I play ith this? I looked at playing with the profile rules directly, but that won't help the snap
<thurston> alright,  I've tried to read on how to add plugins,  but haven't successfully done it yet...   do i copy from my local libraries?
<dholbach> balloons, no idea - I'd suggest asking on the list or see if juju can be configured to look for data elsewhere?
<dholbach> thurston, not plugins, plugs
<dholbach> thurston, in the "apps:" definition
<thurston> k,  checking that out
<dholbach> cool
<thurston> how do i reference x11?   plugs: x11  doesn't work
<jibel> dholbach, I'm trying to build the calculator to test some autopilot stuff and get http://paste.ubuntu.com/19906424/ and the diff is http://paste.ubuntu.com/19906861/
<jibel> dholbach, this is with the snapcraft.yaml from trunk
<jibel> dholbach, do you know what it is? I'm building on yakkety
<thurston> got it, nevermind
<sergiusens> asac GOARCH=$arch GOARM=7 CGO_ENABLED=1 CC=${plat_abi}-gcc go build -ldflags "-extld=${plat_abi}-gcc"
<sergiusens> asac plat_abi=arm-linux-gnueabihf
<renatu> jibel, try this http://paste.ubuntu.com/19908318/
<renatu> jibel, is not working for gtk but I think it works for qt5
<thurston> k,  i got rid of the apparmor issue,  and now it just segfaults with no debug output
<jibel> renatu, it is not working
<camako> Is there a way to force-remove a snap? I am trying to remove the calculator app but am getting :
<camako> 2016-07-18T10:25:10-05:00 ERROR cannot remove snap file "ubuntu-calculator-app", will retry: [stop snap-ubuntu\x2dcalculator\x2dapp-5.mount] failed with exit status 1: Job for snap-ubuntu\x2dcalculator\x2dapp-5.mount failed. See "systemctl status "snap-ubuntu\\x2dcalculator\\x2dapp-5.mount"" and "journalctl -xe" for details.
<camako> [-] Remove snap "ubuntu-calculator-app" from the system
<dholbach> jibel, in a call, will get back to you in a bit
<balloons> dholbach, I'm seeing some of the snapd state issues again when using install / try: http://paste.ubuntu.com/19909550/
<dholbach> balloons, can you please send a mail to the snapcraft list?
<dholbach> I'm about to wrap up my day and need to finish something else
<balloons> dholbach, sure thing. No worries
<dholbach> cool
<dholbach> jibel, try to apply something like this: https://github.com/ubuntu/snappy-playpen/pull/178/files
<mup> PR ubuntu/snappy-playpen#178: fix build by working around #1600238 <Created by dholbach> <Merged by caldav> <https://github.com/ubuntu/snappy-playpen/pull/178>
<dholbach> lfaraone, according to popey Heidelberg sprint coordination stuff is fine in here ;-)
<lfaraone> kk :P
<iliv> what is the purpose of autotools related install-via: and what options does it support?
<dholbach> all right - I call it a day - see you all tomorrow!
<plars> who handles updates of ubuntu-core? I was wondering if/when that would be updated
<plars> some of the snap tests that we run in checkbox hit a problem with the version of snap installed inside the existing ubuntu-core snap (normally wouldn't be an issue I suspect but for us it is). If I force it to use a newer version of 'snap' then it works, but it's a bit hacky
<plars> if we had a more recently built version of the ubuntu-core snap thouh, I think it would just work
<kyrofa> plars, have you tried the one on edge?
<plars> kyrofa: seems to be the same version, unless I'm doing it wrong:
<plars> https://www.irccloud.com/pastebin/847trhlp/
<kyrofa> plars, ah, okay. Ask mvo, then
<plars> ack, thanks
<jaymell> I'm trying to package an app that requires apparmor read access to /dev/sda1, as well as cap_sys_rawio. This isn't currently provided by any of the default interfaces. Is this something that could potentially be added?
<jaymell> I'm not really sure that it fits with any of the existing interfaces, though (maybe 'system-observe', based purely on name, anyway)
<monsterjamp> tsimonq2 I guess it just takes a while for the CLA to be approved, but I just got an email that says I'm in the Canonical Contributor Agreement team on Launchpad.
<mup> PR snapd#1564 opened: snap/squashfs: fix test not to hardcode snap size <Created by zyga> <https://github.com/snapcore/snapd/pull/1564>
<mup> Bug #1604123 opened: speed-test snap error TypeError: Cannot read property 'settings' of null <Snappy:New> <https://launchpad.net/bugs/1604123>
<mup> Bug #1604123 changed: speed-test snap error TypeError: Cannot read property 'settings' of null <Snappy:Invalid> <https://launchpad.net/bugs/1604123>
<tsimonq2> well cool monsterjamp
<tsimonq2> kyrofa: ping
<ratliff> plainbox-test-tool in the demos section of https://github.com/snapcore/snapcraft errors out with "Issue while loading plugin: unknown plugin: plainbox-provider" after I issue the snapcraft command
<zyga> cwayne: ^^ (look at ratliff's comment please)
<mwhudson> are you guys going to release snap-confine again today or should i upload 1.0.38 to debian? :)
<cwayne> ratliff: zyga: which version of snapcraft were you running? it hasn't been included in a release yet afaik
#snappy 2016-07-19
<mup> PR snapd#1565 opened: interfaces: also allow rfkill in network_control <Created by lpotter> <https://github.com/snapcore/snapd/pull/1565>
<mup> PR snapd#1566 opened: network-observe: read perms for network devices <Created by jaymell> <https://github.com/snapcore/snapd/pull/1566>
<mwhudson> why might running a command from a snap fail with
<mwhudson> "cannot mind mount /media to /tmp/snap.rootfs_blah/media. errmsg: Permission denied" ?
<qengho> mwhudson: hrm, anything in "dmesg" around that time?
<dholbach> good morning
<qengho> hi
<gdw> hello, I would like to have some infos on how to manage license keys from the Ubuntu Store in a snap package. Thanks
<mup> PR snapd#1564 closed: snap/squashfs: fix test not to hardcode snap size <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1564>
<mup> PR snapd#1567 opened: store: small cleanups (more needed) <Created by chipaca> <https://github.com/snapcore/snapd/pull/1567>
<qengho> Is it my imagination, or is snapcraft's  organize:  not idempotent?
<mup> PR snapd#1568 opened: Enable SNAPPY_STORE_AUTH_DATA_FILENAME override for client auth data <Created by absoludity> <https://github.com/snapcore/snapd/pull/1568>
<miken> Thanks mvo. Is discussion for PRs here or on telegram?
<dz0ny> qengho: you mean build?
<dz0ny> if that's the case yes
<dz0ny> the problem is that it uses host ost instead ubuntu-core as base
<dholbach> can somebody respond to the last question in https://github.com/ubuntu/snappy-playpen/issues/145?
<dholbach> pbek seems to have quite a few issues with his snap
<dz0ny> a had all sorts of problems with linking
<ratliff> cwayne: snapcraft --version = 2.12.1 and I just did a git clone from the repo and tried to build the demos. the busybox snap works but the plainbox-test-tool doesn't
<ratliff> I was looking for a working demo of plugins
<qengho> ratliff: "doesn't work" isn't enough to comment about.
<ratliff> qengho: this is a continuation of an earlier discussion where I described exactly what "doesn't work"
<ratliff> qengho: 15:12 < ratliff> plainbox-test-tool in the demos section of https://github.com/snapcore/snapcraft errors out with "Issue while loading plugin: unknown plugin: plainbox-provider" after I issue the snapcraft command
<ratliff> qengho: 17:19 < cwayne> ratliff: zyga: which version of snapcraft were you running? it hasn't been included in a release yet afaik
<mup> PR snapd#1560 closed: Drop warning about 2.0 API being different - we're already 2.0! <Created by robert-ancell> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1560>
<mup> PR snapd#1569 opened: Drop license documentation and error kind - this has not been implemented <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1569>
<dpm> pstolowski, moved your session, please re-check the schedule
<dpm> pstolowski, I had to schedule it after the break
<magicaltrout> hello fine people
<magicaltrout> trying to write a first snap
<magicaltrout> if I want to get a remote zip file and just extract and use it as a part
<magicaltrout> a) can i
<magicaltrout> b) what plugin?
<tsimonq2> elopio: I just fixed the two bugs you reported! \o/
<tsimonq2> elopio: snapcraft#667
<mup> PR snapcraft#667: Fix two typos in `snapcraft help sources` and `snapcraft help plugins` respectively <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/667>
<mup> PR snapcraft#667 opened: Fix two typos in `snapcraft help sources` and `snapcraft help plugins` respectively <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/667>
<tsimonq2> ha ha
<qengho> magicaltrout: Use it how?
<dholbach> magicaltrout, yes you can - just use the .zip url in source: and use whatever plugin you need to build/copy
<magicaltrout> yeah so i was just looking at the copy plugin
<magicaltrout> if I don't want to compile anything just unzip and use it
<magicaltrout> does that sound like the right path?
<dholbach> yes, that sounds good
<magicaltrout> cool
<dholbach> :-D
<dholbach> magicaltrout, take a look at https://github.com/ubuntu/snappy-playpen/blob/master/jtiledownloader/snapcraft.yaml
<magicaltrout> ooh thanks dholbach
<magicaltrout> i was leaching the idea playpen example
<magicaltrout> but this one is better
<dholbach> I just used "git grep" to find if there was something for you :)
<magicaltrout> lol
<magicaltrout> i should probably search harder :)
<magicaltrout> okay dholbach, currently I have https://gist.github.com/anonymous/9fe1e674f4c2a35b4b4091ef149a6856 whilst testing this stuff
<magicaltrout> your example doesn't unzip the file, yet I assume this happens at some point
<dpm> hey robert_ancell, we had to reshuffle the schedule (surprise!) - can you join us for the app indicator support for desktop apps session at 11:45?
<magicaltrout> my pdi file is copied in  (I guess thats what I can see in prime) but isn't extracted and the command thing fails
<robert_ancell> dpm, sure
<qengho> My snapped Qt app wants to load theme images. "QML QQuickImage: Failed to get image from provider: image://theme/list-add". I see prime/usr/share/icons/Humanity/actions/48[[et al.]]/list-add.svg   What gives?
<dpm> robert_ancell, thanks, nothing like pinging you and then bumping into you on the main room :)
<qengho> magicaltrout: we only extract  source:  lines. If you say "file", you get a file.
<magicaltrout> ah right
<magicaltrout> thanks qengho
<magicaltrout> oh wow it built and nearly worked and everything
<dholbach> yeehaw :)
<qengho> magicaltrout: We're working on that last 2%. It's kind of tough.
<magicaltrout> no problem qengho! I'm just hacking around. (Full disclsure for anyone in Heidelberg I was the random guy asking about Java apps in the meeting this morning)
<qengho> magicaltrout: I'm not in Heidelberg, but I wish I was. I bet it's fun on the Neckar.
<magicaltrout> its warm :)
<ogra_> very warm
<ogra_> :)
<magicaltrout> i'm  used to english weather where high summer is about 17 C ;)
<qengho> magicaltrout: that's what radler is for.
<magicaltrout> qengho: you're like a mind reader
<dholbach> :-)
<magicaltrout> ok other random question
<magicaltrout> i stole the launcher script from that examaple and munged it up a bit
<magicaltrout> the command in the example is bin/launcher
<magicaltrout> how do I make sure the exec bit is set?
<magicaltrout> because in prime mine isn't
<magicaltrout> hmm maybe i need to clean to make sure the file is updated
<qengho> magicaltrout: hmm. That's hard. Can you run  bin/sh $SNAP/bin/launcher  instead?
<magicaltrout> i could, but I was curious to know why the playpen one didn't
<magicaltrout> but it may just be that my build didn't detect the +x and didn't replace the file
<dholbach> magicaltrout, what kind of app are you working on right now? is it anything to do with qt or gtk or java or anything else?
<qengho> magicaltrout: bzr and git store the x bit. snapcraft preserves it. Yeah, it might be that snapcraft doesn't see that as a change to apply when updating.
<magicaltrout> dholbach: java app, uses swing so I guess leverages gtk as well
<dholbach> ok
<magicaltrout> yeah qengho snapcraft clean solved it
<dholbach> so that example wasn't too far off :)
 * qengho yells at Qt snap not using humanity theme.
<magicaltrout> absolutely spot on dholbach, I picked idea cause I knew it was java based, but this one is much better
<magicaltrout> i have a bit of a plan once i have an idea of how it works to build a maven plugin to auto generate snapcraft.yaml from a pom definition, so that Java developers don't have to rebuild their build routine or do anything too weird to get onboard with snaps
<magicaltrout> we do similar with a spotify plugin for docker where you define the dockerfile in a maven pom and have it run as the last step in the chain
<qengho> magicaltrout, you are a madman. An awesome, awesome madman.
<magicaltrout> well if you're trying to get traction, telling people they need to rearrange their build process to add some random bash script to the end is normally a big turn off
<magicaltrout> so if I can write a maven plugin that creates the yaml and any other resources, that users can then implement inside their existing maven builds, thats a much cleaner way for people to integrate with snaps (if you're a maven user)
<magicaltrout> especially when people already have their CI systems, build processes in place and working
<magicaltrout> really need something to eat and drink.... refuse to leave my laptop until it at least boots.....
<magicaltrout> argh the thirst
<magicaltrout> okay
<magicaltrout> we're getting somewhere
<magicaltrout> it tried to load a lib from my user home directory
<magicaltrout> but I get permission denied errors
<magicaltrout> I guess more than anything whats best practice there? I'm not entirely sure how the lib got there in the first place, I suspect the java app probably populates the folder when it can't find the files
<magicaltrout> /home/bugg/.swt/lib/linux/x86_64/libswt-gtk-4332.so: /home/bugg/.swt/lib/linux/x86_64/libswt-gtk-4332.so: cannot open shared object file: Permission denied
<dholbach> hum... I've never seen ~/.swt
<dholbach> but I'm not an expert
<magicaltrout> yeah its dumped in by the app
<magicaltrout> if it can't find the lib it will put it in ~/.swt for you
<magicaltrout> but the app launcher clearly can't read/open it
<qengho> magicaltrout: find out what environment variable lets it know anything about /home/bugg/ . Whatever provided that should be set to something like $SNAP_USER_DATA anyway.
<magicaltrout> okay qengho
<magicaltrout> thanks
<mup> PR snapcraft#668 opened: Add exception for `tar-content` in `snapcraft help` <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/668>
<trijntje_> magicaltrout: I had a similar problem when an app wanted to put stuf in home, I solved it by adding "java -Duser.home=$SNAP_USER_DATA" to the wrapper
<qengho> ah yeah! ^^
<magicaltrout> ooh
<qengho> magicaltrout: after that, it works.
<qengho> modulo font problems.
<tsimonq2> thanks a ton for merging sergiusens :)
<mup> PR snapcraft#667 closed: Fix four typos in `snapcraft help` <Created by tsimonq2> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/667>
<tsimonq2> \o/
<mup> PR snapcraft#655 closed: Gradle plugin fix for command invocation <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/655>
<flexiondotorg> https://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/
<flexiondotorg> dpm, didrocks ^^
<mup> PR snapcraft#669 opened: Add detection for an existing `.snapcraft.yaml` file before running `snapcraft init` <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/669>
<tsimonq2> \o/
<mup> Bug #1604346 opened: snapd apparmor tests fail on ArchLinux <Snappy:New> <https://launchpad.net/bugs/1604346>
<timothy> zyga: :P
<magicaltrout> wooooo
<magicaltrout> it works and everything
<magicaltrout> thanks for the tip trijntje_
<magicaltrout> no i need to understand what i've done
<magicaltrout> +w
<magicaltrout> so it looks cool, I have a usabilty question (the answer is probably just: tough) https://ibin.co/2oaQDoBG8hXt.png
<magicaltrout> I've given the snap access to home
<magicaltrout> but the file browser doesn't make it obvious to users that they'd have to find their way there
<magicaltrout> also if a user clicks on file system is just throws an error because there is no access
<magicaltrout> anyone seen this or is this just a feature I've "introduced"? ;)
<magicaltrout> if I force it to go to /home/bugg
<magicaltrout> it renders my home just fine
<cwayne> ratliff: im not able to reproduce on a fresh pull of snapcraft on my xenial system, let me try and poke around
<cwayne> zyga: ^
<mup> Bug #1604356 opened: symlink creation over and over on install, creates file too long situation <Snappy:New> <https://launchpad.net/bugs/1604356>
<magicaltrout> alrighty
<magicaltrout> so here's what i'm thinking (a rough draft)
<magicaltrout> https://gist.github.com/anonymous/a9e3b2b5352ac4f91209502f006b4134
<magicaltrout> something like that  in a maven pom
<magicaltrout> to build the yaml
<trijntje_> magicaltrout: congrats on the working snap
<magicaltrout> and then have it call snapcraft afterwards
<trijntje_> and I also have the same concern about the usability regarding $HOME. But I'd guess there should be a way to start file dialogs in HOME
<magicaltrout> not just me then!
<thurston> i got my snap working!  however I'd like to make it create a launcher,  not just run from the command line.   is there a tutorial for that?
<dholbach> set up a setup/gui directory, like https://github.com/ubuntu/snappy-playpen/tree/master/qcomicbook/setup/gui
<thurston> ah,  i have the icon file there,  just no .desktop....thanks!
<dragly> Is it possible to package QML apps using the latest version of snappy? I had some trouble a couple of months ago because I couldn't access OpenGL, X or similar in a way that worked with snappy.
<mup> PR snapcraft#666 closed: Allow / in parts <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/666>
<balloons> jdstrand, got a minute to help explain getting through apparmor errors on a new snap?
<dholbach> thurston, I added it to askubuntu - feel free to comment/edit: http://askubuntu.com/questions/800437/how-can-i-create-a-menu-entry-for-my-snap
<balloons> dragly, absolutely. The core apps are written with qml and snap up.
<dholbach> dragly, that's possible - check out https://github.com/ubuntu/snappy-playpen/tree/master/ubuntu-clock-app
<dragly> balloons: Great, thanks! I'll try my app again. I remember I had issues with the clock app as well, so if that works, I should be all set :)
<dholbach> :-D
<mup> PR snapd#1570 opened: snapstate: remove artifacts from a snap try dir that vanished <Created by mvo5> <https://github.com/snapcore/snapd/pull/1570>
<thurston> woohoo!  i finished my snap!  dholbach thanks for all your help yesterday and today!
<dholbach> thurston, great work - which snap did you work on?
<thurston> my own dice rolling app.    there aren't any dice rollers for linux except for a command line one.  so i made one that works totally cross platform
<thurston> and has a gui
<dholbach> thurston, did you upload it to the store already?
<thurston> not yet...checking that out now.   i don't have a license for it yet....its not necessarily open source,  what license should i use?
<mup> PR snapd#1571 opened: tests: add network-observe interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1571>
<thurston> are there license requirements for snaps?
<dholbach> https://myapps.developer.ubuntu.com/dev/tos/ for uploading them to the store
<mup> PR snapcraft#670 opened: Remove .la files generated by autotools <Created by robert-ancell> <https://github.com/snapcore/snapcraft/pull/670>
<ogra_> thurston, well, it is kind of expected that you are allowed to redistribute whatever you upload
<ogra_> beyond that there are no reqs.
<thurston> yeah,  i'm just wondering about my situation.  because i made my app in a game engine that only spits out a single binary.   I don't think the source code is actually visible
<thurston> as a side note,  i've already published my app on google play store.... does that matter?
<mup> PR snapcraft#671 opened: Add initial snapcraft manpage <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/671>
<tsimonq2> \o/
<thurston> https://play.google.com/store/apps/details?id=org.godotengine.rpgdiceroller
<thurston> wait, do i even need to include a license?
<ogra_> well, whatever your upstream requires from you ...
<ogra_> their license should define what you can and should do when you distribute it
<thurston> well Godot is MIT licensed, and thus anything made with it can be relicensed any way the creator wants
<ogra_> then i would just include their license file
<mup> PR snapd#1567 closed: store: small cleanups (more needed) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1567>
<thurston> great,  got it.  CC-BY-SA 4.0 is perfect.   so now i'll publish
<dholbach> go go go! :)
<thurston> uploading now
<thurston> this is so much easier than dealing with .deb
<qengho> upload dance
<thurston> k its uploaded
<thurston> now whatt?
<ogra_> wait til the utomated tests finished
<ogra_> then click publish
<dholbach> you might have to choose a channel for it too
<dholbach> but I think that's just on first upload(?)
<ogra_> yeah ...
<thurston> k,  says its published
<ogra_> how is it called ??
<thurston> rpgdiceroller
<ogra_> ogra@styx:~/Devel/packages/snaps$ snap find rpgdiceroller
<ogra_> Name           Version  Developer    Notes  Summary
<ogra_> rpgdiceroller  1.7      quality-mix  -      A dice roller with simple GUI
<ogra_> ogra@styx:~/Devel/packages/snaps$
<ogra_> ;)
<thurston> yay!
<thurston> now that i know that works,  i'll be able to publish my games via snaps
<thurston> sweet
<mup> PR snapd#1522 closed: Introduce a simple key-value store for user-specific data <Created by stevenwilkin> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1522>
<thurston> thanks for your help everyone
<sergiusens> chrisatlee hey, what is the story behind firefox plugins
<chrisatlee> sergiusens: they're installed into the users profile directory
<chrisatlee> So they should work OK
<chrisatlee> I suppose some may need different permissions...
<sergiusens> chrisatlee great, that is one less worry
<mup> PR snapcraft#665 closed: Update broken links to https://snapcraft.io <Created by nottrobin> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/665>
<chrisatlee> sergiusens: There are some plugins that want to run commands that read stuff from your homedir for instance....those will probably break
<msvb-lab> A little lost (sorry) but I'm looking for some official collaboration from Canonical for a few forthcoming educational events, workshops. Anyone know who the contact would be for embedded/IoT snappy education?
<msvb-lab> Seems the role of community manager has not been filled since Jono?
<ogra_> it sure has ...
<ali1234> msvb-lab: there is a community team instead now
<msvb-lab> ali1234: Are they reachable in Launchpad or an IRC channel?
<ali1234> yes
<ogra_> yeah ... theyy went from dictatorship to democracy ;)
<ali1234> https://launchpad.net/~canonical-community
<zyga> tyhicks: hey
<zyga> tyhicks: can you please tell me what is the apparmor syntax for symlinks?
<ali1234> you can also ask them difficult and annoying questions on thursday afternoons i think, when they do a live stream
<ogra_> https://lists.ubuntu.com/mailman/listinfo/ubuntu-community-team
<ogra_> (and yes, what ali1234 pointed to ... )
<ali1234> the canonical team is the one you want
<mup> PR snapcraft#672 opened: Capture the correct exception when not being able to decode json <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/672>
<Croepha> protip: if you want to try out customizing ubuntu-core base image without having to build a new flash image, you can just mount over what you want to edit with tmpfs
<ogra_> works also for application snaps
<ogra_> just bind mount the changed file on top
<Croepha> nice
<Croepha> is there a way for ubuntu-device-flash to copy from a directory and preload stuff onto the writable partition?
<Croepha> actually, i shouldn't say partition, because there is only /one/ partition, but i mean the writable fs
<ogra_> not yet ... everything is changing and cloud.init will be able to do such stuff (that you have to define in the gadget snap)
<ogra_> *cloud-init
<Croepha> hmm, im probably not understanding (im not exactly sure what a gadget snap is), but the point of putting it into writable, was that it wouldn't actually be in a snap, so it could be edited later
<Croepha> but probably cloud-init could do that too
<Croepha> oh, do you mean, that it would get copied out of a snap and put onto writable by cloud-init ?
<gustavopadre> Hi guys, I'm wondering why telegram-sergiusens is not showing up anymore in terminal "snap find", I got to install with sudo snap install but can't find in snap find
<ogra_> Croepha, exactly
<ogra_> ogra@styx:~/Devel/packages/snaps/jTileDownloader$ snap find telegram-sergiusens|grep ^tele
<ogra_> telegram-sergiusens  0.9.49      sergiusens  -      Telegram desktop client
<ogra_> ogra@styx:~/Devel/packages/snaps/jTileDownloader$
<ogra_> i can find it here
<gustavopadre> ogra_, taskwarrior-plars          2.5.1-1                    pwlars                -        feature-rich console based todo list manager
<gustavopadre> teatime                    16.04                      paroj                 -        Simple egg timer application for the Unity Desktop
<gustavopadre> test-snapd-tools           1.0                        canonical             -        Tools for testing the snapd application
<gustavopadre> tio                        1.20                       lundmar               -        A simple TTY terminal I/O application
<gustavopadre> those are the only listed "T" here in snap find =[
<ogra_> that is what you get when you search for telegram-sergiusens ?
<gustavopadre> using your command I find your result
<gustavopadre> using only snap find I don't
<ogra_> because that is limited to 100 lines
<ogra_> and there are farm more than 100 snaps now
<ogra_> *far more
<gustavopadre> Oh, that's sad, I wish I could find all just by doing snap find, and it serves as good propaganda to the number of packages
<popey> msvb-lab: hello. feel free to drop me a mail - popey@ubuntu.com
<ogra_> https://uappexplorer.com/apps?sort=relevance&type=snappy
<ogra_> try that instead :)
<gustavopadre> ogra_, thanks
<ali1234> hey i just thought of something
<ali1234> if, in the future, i run snapcraft on ubuntu 16.10, does that mean i can build snaps using packages newer than the ones in 16.04, that will work on 16.04?
<ali1234> without having to go to the trouble of building all the stuff manually?
<mup> PR snapd#1572 opened: interfaces: add bluetooth-control interfaces <Created by morphis> <https://github.com/snapcore/snapd/pull/1572>
<mup> PR snapcraft#673 opened: Updating styling and examples for `snapcraft init` in lifecycle.py <Created by wandrewkeech> <https://github.com/snapcore/snapcraft/pull/673>
<thurston> i can't seem to get my snap to run on my desktop....  i can't tell why.  it uses different video drivers, but I didn't think that mattered?
<Croepha> what are the files you get from ubuntu_device_flash query? are they the default options to core for os and gadget snap?
<Croepha> so, if I need to customize the OS snap, does snapd know to not get updates?
<wililupy> I'm assuming the first partition in Ubuntu-Core that is labeled "grub" if the EFI partition?
<Croepha> on my system the second partition is efi
<Croepha> the first is a 4M partition called BIOS boot
<Croepha> not sure what that is
<wililupy> I just ran blkid against my ubuntu-core image and I see 3 partitions labeled p1 grub p2 system-boot and p3 writable
<Croepha> hmm maybe its because im on 16
<wililupy> Croepha, I am as well. I just built my image today with ubuntu-device-flash
<wililupy> I'm trying to flash my network device which uses UEFI booting only, but when it tries to update the grub.cfg to point to /boot/efi/EFI/ubuntu/grub.cfg, it doesn't see the path.
<Croepha> http://paste.ubuntu.com/20091228/
<Croepha> if it does a scan it should pick it up automatically, im booting off of efi
<Croepha> what do you mean by network device? are you netbooting?
<wililupy> I am flashing ubuntu-core onto a network switch.
<Croepha> im not sure I can help
<Croepha> all i can say is that efi on a PC works
<wililupy> I can get it to write to the device, but when it goes to update grub so that I can still load the diagnostic partitions on the device it fails becuase it cannot see my /boot/efi/EFI/BOOT/grubx64.efi
<Croepha> when you load the efi shell, can you search around for it?
<Croepha> try to load it manually
<wililupy> I think I figured it out. My script to convert the image to ONIE does not understand the EFI partition.
<ali1234> i think i am finally getting somewhere with getting a working Qt eglfs on ubuntu
<ali1234> i found the landing ppa for qt 5.6 on xenial... i have the videocore ppa... i know how to modify the qmake.conf so it uses the right EGL libraries
<ali1234> so it should be a matter of putting everything in a ppa and waiting
<MrMcaustin1> I need help with getting past the rainbow screen on a raspberry pi
<ali1234> okay?
<MrMcaustin1> Any help?
<ali1234> insert a correct sd card
<magicaltrout> everyone loves a rainbow
<MrMcaustin1> What do you mean by correct sd card? I have the sd card with snasppy on it
<ali1234> rainbow screen means the pi cannot understand what is on your sd card
<MrMcaustin1> So what do I do? :P
<magicaltrout>  23:33  ali1234| insert a correct sd card
<magicaltrout> ;)
<ali1234> tell us what you did
<ali1234> what version of raspberry pi
<ali1234> what version of snappy
<ali1234> how did you make the sd card
<ali1234> etc
<MrMcaustin1> First generation of raspberry pi B
<ali1234> well there is your problem
<ali1234> ubuntu won't run on that
<MrMcaustin1> Oh?
<ali1234> you need a 2B or 3B
<MrMcaustin1> Okay thanks :)
<mup> Bug #1604619 opened: ubuntu-fan keeps wifi from starting properly <Snappy:New> <https://launchpad.net/bugs/1604619>
<mup> Bug #1604619 changed: ubuntu-fan keeps wifi from starting properly <Snappy:New> <https://launchpad.net/bugs/1604619>
<thurston> any help in tracking down a bug?
#snappy 2016-07-20
<qengho> How does my Qt snapped app know what theme it should use? Qt is Martian technology and I don't understand it.
<Croepha> qengho: you can use env variables
<qengho> Croepha: that makes sense. I must not know what to use, because none I try changes it. I wish to use Humanity theme. What var and value?
<Croepha> I dont have experience with QT styles, but for QT to work right, you need QT_PLUGIN_PATH to get to the platfrom plugins
<Croepha> https://wiki.archlinux.org/index.php/Uniform_look_for_Qt_and_GTK_applications says to use QT_STYLE_OVERRIDE
<Croepha> there might also be a programatic way to do it
<Croepha> not sure
<Croepha> you might want to use strace to see if the app is actually trying to load anything
<qengho> I used strace. It's looking for hicolor only.
<Croepha> have you tried QT_STYLE_OVERRIDE='gtk2'
<qengho> I thought so. I'm trying again.
<Croepha> you might also want to try printing out the env from the app, to make sure that your env isn't getting dropped
<Croepha> I have a bash script inside of my snap that sets the required vars
<Croepha> probably a better way would be to set the vars from inside the app
<qengho> I have a wrapper too.
<Croepha> anyway, im not sure I can help, because I haven't messed with styles
<qengho> Okay then.
<RyanTG> How do I give the VLC snap package access to my DVD drive?
<RyanTG> I already have snapd-2.0.10 which is supposed to make DVDs usable with VLC, so what am I missing?
<RyanTG> found it: snap remove vlc && apt-get install vlc
<liuxg> if a snap needs a debian package, but it does not exist in the ubuntu archive, I can get the .deb file locally, how can I make use of the .deb file? thank
<qengho> liuxg: There's no way to import a deb file, only a named APT package. You could make a plugin to unpack it and install it.
<liuxg> qengho, I do not know how. This is a valid use case. For example, in China, there are some debian files which are not in the ubuntu archive (input method), there is no way to use stage-packages to do that. I think it would be good to support it in the snapcraft.
<qengho> liuxg: I agree it would. Please file a bug report to explain what you want.  $ ubuntu-bug snapcraft   # maybe?
<liuxg> qengho, sometimes, we need to add a specific ppa to get a software installed.
<liuxg> qengho, sure, I will do that. thanks
<qengho> liuxg: In the mean time, you can put a file at parts/plugins/x-deb-file.py , and extend  snapcraft.BasePlugin .  In your snapcraft, "plugin: deb-file" .
<liuxg> qengho, is there any document for this? I want to have a better picture of this about how to do it. thanks.
<qengho> liuxg: Yes. Google "write snapcraft plugins"
<liuxg> qengho, OK. many thanks!
<qengho> :)
<liuxg> qengho, by the way, i have created a bug report at https://bugs.launchpad.net/snapcraft/+bug/1604669
<mup> Bug #1604669: Support Installing a local deb package in the snapcraft <Snapcraft:New> <https://launchpad.net/bugs/1604669>
<qengho> liuxg: defining an APT source is useful too
<liuxg> qengho, how can I define an APT source for it? https://github.com/snapcore/snapcraft/blob/master/docs/snapcraft-syntax.md, at the link, I did not find anything about it.
<qengho> liuxg: I'm suggeting anther bug report.
<qengho> another
<liuxg> qengho, yes, I think it is a good idea :)
<liuxg> qengho, let me create one for it. thanks
<liuxg> qengho, there is a bug https://bugs.launchpad.net/snapcraft/+bug/1583236, it seems that APT is already supported?
<mup> Bug #1583236: snapcraft APT sources checking too strict <Snapcraft:New> <https://launchpad.net/bugs/1583236>
<liuxg> qengho, but I do not find it in any of the documents. it is weired.
<qengho> Hah, I filed that one. it refers to the system sources.list
<liuxg> qengho, so, it is not for the snapcraft?
<qengho> liuxg: That means that when installing stage-packages: or build-packages:, warnings cause failure.
<qengho> It has nothing to do with other sources from snapcraft configuratio.
<liuxg> qengho, so the API support for the snapcraft  is that it can install debian pacakges from other sources, right? Is this not supported? I just want to clarify this.
<qengho> liuxg: it is not supported to have your snapcraft refer to a package that is not in the distro or the local system's global source list.
<liuxg> qengho, OK. thanks..
<liuxg> qengho, I have filed a bug at  https://bugs.launchpad.net/snapcraft/+bug/1604671. would you please take a look at it? thanks
<mup> Bug #1604671: Adding APT source support in the snapcraft <Snapcraft:New> <https://launchpad.net/bugs/1604671>
<qengho> Cool.
<qengho> liuxg: Looks good to me.
<liuxg> qengho, nice. thanks!
<qengho> liuxg: Where are you physically?
<liuxg> qengho, I am physically in Beijing, China. How about you?
<qengho> Taipei. Just noticing your name and wondering if you were near.
<liuxg> qengho, good to know you. Are you from canonical?
<qengho> Yes.
<qengho> Though snappy is not what I work on usually.
<liuxg> qengho, oh, really? I am actually from phone team too :). by the way, I cannot find your irc nick name in our directory.
<qengho> lp:~cmiller
<liuxg> qengho, oh, you are from US. nice to meet you :)
<qengho> Likewise.
<liuxg> qengho, today, I tried to install the telegram app onto my desktop. I got the Chinese fonts in the snap. However, the input method does not work for me. I am wondering whether I need to install the input method into the snap.
<liuxg> qengho, the problem is that I can only get the deb package for the input method.
<qengho> I see. Hmm. I would think you don't need the input method in the snap.
<liuxg> qengho, I used to develop a Qt-based phone app and convert it to a snap. the characters are shown correctly unlike the telegram one.
<liuxg> qengho, then,  the Chinese characters are all shown as rectangle blocks :(
<qengho> liuxg: You *do* need fonts in the snap.
<liuxg> qengho, yes, I have installed the fonts already.
<liuxg> qengho, strange, right? http://paste.ubuntu.com/20145372/, this is the modified snapcraft.yaml
<liuxg> qengho, the Chinese input method does not work at all. I cannot input Chinese characters.
<liuxg> qengho, the original source code is at https://github.com/sergiusens/telegram-snap
 * qengho casts spell Summon Sergi.
<qengho> liuxg: sorryy, I do'nt know.
<liuxg> qengho, anyway, it is fine. it is just sth I experienced. internationalization is definitely one of the concerns. I think it would be easier to have the language support in the snapcraft as well.
<mup> PR snapd#1573 opened: asserts/tool,cmd/snap: introduce hidden "snap sign" <Created by pedronis> <https://github.com/snapcore/snapd/pull/1573>
<mup> PR snapcraft#672 closed: Capture the correct exception when not being able to decode json <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/672>
<mup> PR snapd#1568 closed: Enable SNAPPY_STORE_AUTH_DATA_FILENAME override for client auth data <Created by absoludity> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1568>
<mup> PR snapd#1574 opened: tests: add network-control interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1574>
<dholbach> hey hey
<mup> PR snapcraft#674 opened: Add reference.md <Created by elopio> <https://github.com/snapcore/snapcraft/pull/674>
<liuxg> dholbach, ping
<dholbach> liuxg, pong
<liuxg> dholbach, I just found that "snap run". but I do not how to use it. I tried it for the "hello-world" exmaple, it does not work. what should be the correct way to run it?
<liuxg> dholbach, I have tried it like "snap run hello-world" or "snap run hello-world.env", both did not work.
<dholbach> liuxg, you could ask all the others in the channel too - I'm not a snapd developer :-)
<dholbach> I have never used "snap run" yet
<pmp> liuxg: to run the hello-world-snap simply run hello-world
<pmp> snap is mainly for installing and managing snaps
<liuxg> dholbach, yes, it is a little strange. I have seen its help by running "snap run -h", and it shows something like http://paste.ubuntu.com/20152247/
<pmp> liuxg: hello-world.echo for example
<liuxg> pmp,  yes, that is what I normally use. However, what is the "run" command for there?
<pmp> liuxg: sorry, have never seen or used it myself
<liuxg> pmp, yes, I understood that. But why there is a "run" command when I run "snap --help"
<liuxg> pmp, it is a little confusing in that sense. if there is a command like "run", we can do sth like "snap run xxx".
<liuxg> pmp, maybe it simply means that way you talked about. Then the help is a little bit confusing there.
<liuxg> from the syntax there in the help, it is sth like "snap [OPTIONS] run [run-OPTIONS] <app name>". it is supposed to run a snap app.
<qengho> How does my Qt snapped app know what theme it should use? Qt is Martian technology and I don't understand it.
<qengho> I have heard that one can set an environment variable of some kind, to affect it, but that seems to be lies lies lies.
<liuxg> qengho, I think insider your Qt app, you can point what theme it should use.
<qengho> liuxg: Inside how? I run a snapped app. I get broken thee.
<qengho> theme
<liuxg> qengho, inside your MainView, there is a "theme" property.
<qengho> I am not going to edit the source.
<liuxg> qengho, http://paste.ubuntu.com/20152716/, you can assign the theme you want to use
<liuxg> qengho,   theme.name :"Ubuntu.Components.Themes.SuruDark"
<qengho> liuxg: It seems to be set to Ambiance. strace doesn't try to access Ambiance files, though, only hicolor .
 * qengho afk, back later.
<liuxg> qengho, I have a test project for ubuntu phone at https://github.com/liu-xiao-guo/theme. I think you probably need to package the theme stuff as well.
<mwhudson> zyga: are you going to release snap-confine again today? :)
<leousa> hey folks, is it possible to package a Mono based app that runs perfectly on the desktop as a snap?
<dholbach> leousa, I wouldn't see why not, but haven't heard of somebody try it yet
<dholbach> somebody did a MonoGame apparently: http://askubuntu.com/questions/779315/how-do-i-create-a-snap-for-a-monogame-application
<dholbach> leousa, what does the build use? is it autotools?
<leousa> yeah i tried that, but didnt work, although im by no means a snappy expert
<dholbach> is the source for the app available?
<leousa> i have only found the binaries unfortunately
<dholbach> ok
<dholbach> in that case, just using the copy plugin should be a good start
<dholbach> add the relevant dependencies to your stage-packages: definition
<dholbach> and define the binary to be run in the apps: section
<dholbach> let me see if there's a good example of something like that somewhere
<leousa> ok great, thanks I appreciate that dholbach
<dholbach> no worries
<dholbach> https://github.com/ubuntu/snappy-playpen/tree/master/gitter-im could be a good start, it uses a Makefile to handle the custom download of a .deb package somewhere
<dholbach> but you could easily replace that with    source: <url of tarball or zipfile>
<leousa> i tried ldd to find the package dependencies, there were quite a few, but had issues building the yaml file
<leousa> nice, ill have a look at it
<dholbach> or https://github.com/ubuntu/snappy-playpen/tree/master/jtiledownloader
<dholbach> leousa, which issues did you run into?
<dholbach> can you pastebine the snapcraft.yaml file?
<leousa> ok give me a min
<dholbach> sure sure :)
<leousa> http://pastebin.com/9RUCJZnD
<dholbach> cool, checking
<dholbach> ok, you could copy over the Forgotten\ Myths\ CCG.x86 file from wherever you get it from? Is it a tarball or something?
<dholbach> and you could use the package names for the libraries you're listing and add them to stage-packages:
<dholbach> let me try it
<leousa> you can get the files from this link
<leousa> https://drive.google.com/file/d/0B6jna1aYT5M1UHpPNHJ6dER5OXc/view
<leousa> it is a game that runs nice on the Ubuntu desktop, and wanted to package as a snap
<kalikiana> So... after rebooting all of my snaps do this:
<kalikiana> htop
<kalikiana> failed to create user data directory. errmsg: Permission denied
<kalikiana> On gitter it was suggested it could be related to my home being encrypted
<dholbach> leousa, something like this? http://paste.ubuntu.com/20158963/
<dholbach> kalikiana, does scanlog say anything when you start the app?
<kalikiana> what's scanlog?
<dholbach> http://askubuntu.com/questions/783979/how-do-i-debug-snaps
<kalikiana> Reading
<kalikiana> dholbach: Well, how would I run that? :-D
<dholbach> ?
<kalikiana> That's a snap...
<dholbach> Right, you install the snap, run the commands on that page, keep the terminal open...
<dholbach> then run your snap
<kalikiana> No, you don't get my problem: Any snap I run aborts.
<dholbach> ok, sorry, I missed that bit
<kalikiana> snappy-debug.security scanlog
<kalikiana> failed to create user data directory. errmsg: Permission denied
<dholbach> does "snap changes" say anything?
<dholbach> is snapd in a clean state?
<kalikiana> Yes, afair all is good, nothing "pending".
<kalikiana> (That was why I rebooted, I couldn't resolve it otherwise)
<dholbach> I guess you need to ping zyga, mvo, pedronis and Co
<dholbach> I don't know
<kalikiana> ls -lA ~/ | grep snap
<kalikiana> drwxrwxr-x 15 cris cris 4,0K Jul 20 11:31 snap
<kalikiana> drwx------  2 cris cris 4,0K Jun 19 00:33 .snap
<kalikiana> Those are my snap folder permissions if that has any relevance
<leousa> ok some progress, but throws error: Error downloading stage packages for part 'fmyth': no such package 'libx11'
<dholbach> sorry
<dholbach> libx11-6
<leousa> better
<leousa> [Errno 2] No such file or directory: '/home/leo/Applications/FM0_9545_linux/parts/fmyth/build/Forgotten\\ Myths\\ CCG.x86'
<leousa> funny thing is that directory and file exist
<dholbach> hohum
<dholbach> Do you think you can send a mail with your snapcraft.yaml (or a link to it) to the mailing list?
<dholbach> I don't quite know how to solve this one.
<leousa> sure thing i will send it
<dholbach> fantastic
<leousa> ok mail sent, thx again dholbach
<kalikiana> Okay, I found a way to run snappy-debug.security: SNAP=/snap/snappy-debug/22 /snap/snappy-debug/current/bin/snappy-security-scanlog | more
<mup> Bug #22: Legal Link <lp-foundations> <Launchpad itself:Fix Released> <https://launchpad.net/bugs/22>
<kalikiana> og: apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher
<kalikiana> " name="/home/.ecryptfs/cris/.Private/" pid=26032 comm="ubuntu-core-lau" reque
<kalikiana> sted_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000
<kalikiana> So for some reason ubuntu-core-launcher is trying to read my encrypted folder
<mup> PR snapd#1575 opened: osutil: check for nogrup instead of adm <Created by zyga> <https://github.com/snapcore/snapd/pull/1575>
<Croepha> so, when snappy is doing a refresh/update, and you have custom kernels and custom os snap, does snapd know to just install newer versions of the same snaps?
<mup> PR snapd#1575 closed: osutil: check for nogrup instead of adm <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1575>
<thurston> good morning all...  any help on figuring out some bugs?
<lfaraone> Is there ethernet available anywhere at the hotel, by the by?
<thurston> when i run my application's binary it runs with no warnings,  however when i run the application's snap, i get warnings about being unable to load libXrandr.so
<Cavan> I just finished the tomcat-webapp snap and installed it, is there anyway for me to check if its working correctly?
<Cavan> I just finished the tomcat-webapp snap and installed it, is there anyway for me to check if its working correctly?
<Croepha> Cavan if its a daemon, you can check its logs via journalctl
<ogra_> or just look at the processlist to see if it runs
<dholbach> thurston, you're on amd64 I guess? it might be looking for 32bit libraries :-(
<dholbach> thurston, it's something I just realised
<ogra_> we ship libc for 32bit execution in the core snap
<ogra_> but only that ...
<Cavan> Croepha, how do I know which logs are produced by tomcat?
<thurston> why would it work on my 64bit ubuntu laptop and not my 64bit ubuntu desktop?
<sborovkov> Hello. Any ideas what could be wrong here - running my snap on armhf classic image. Application crashes  KeyError: 'getpwuid(): uid not found: - look like it can not access /etc/passwd or something related to that. Any ideas what's the differnce with usual snappy image (everything works there)?
<Croepha> Cavan find service name via: systemctl list-unit-files '*snap*'  , then you can do journalctl -u "<service name>"
<Croepha> thurston: i dont really know about the 64bit angle, but have you tried copying the .so file into the snaps usr/lib ? that usually works for me, but i fear xrandr might end up wanting more and more things until you have all of xorg in your snap
<Croepha> thurston: thurston run ldd con your executable to see what its missing
<thurston> oh cool, thats a neat command!
<ogra_> sborovkov, i think snapd on classic just binad mounts the hosts /etcc/passwd readonly on top of the one in the core snap and does not use /var/lib/extrausers at all
<Cavan> Croepha, the terminal output was 'UNIT FILE STATE  0 unit files listed.' is that normal or?
<ogra_> i'm not sure if we want the extrausers stuff to actually be identical between native snappy and snappy on classic ... zyga would be the man to knw i guess
<ogra_> *know
<Croepha> Cavan, no, thats not normal, you should have a list of services, even without any snaps loaded, it should atleast match the system snap related services
<Croepha> Cavan: What is your OS? and what is the command you used exactly?
<Cavan> Ubuntu and ' systemctl list-unit-files 'tomcat-webapp-demo_1.0_amd64.snap''
<Cavan> Croepha
<thurston> should i paste the list here?
<Croepha> Cavan: i meant literally '*snap*'
<ogra_> on http://paste.ubuntu.com/
<sborovkov> ogra_: so snap does not see the usual /etc/passwd? I have this error both in python and glib which causes assertion that stops everything
<sborovkov> zyga: Hello, any idea ^^
<ogra_> sborovkov, why do you need the passwd file at all ?
<thurston> http://paste.ubuntu.com/20177325/
<Croepha> Cavan: the '*snap*' is kinda like | grep snap for systemctl
<Cavan> Croepha, ah thats brilliant thanks, it says the tomcat service is enabled.
<sborovkov> ogra_: I don't need it myself. Glib get some of that during initialization. No idea why. I get this warning and consequent assert at the end of the function https://github.com/GNOME/glib/blob/master/glib/gutils.c#L671
<Croepha> Cavan, ok, so the blahblah.service is the service name, so then you can do journalctl -u blahblah.service
<sborovkov> ogra_: and PythonQt gets that as well. Idk for what purpose honestly
<ogra_> sborovkov, aha, it seems to try to look up *your* UID
<ogra_> yeahm thats definietly a zyga thing and possible a jdstrand one ....
<thurston> the list of plugs I include in the .yaml include [x11, opengl, unity7]   and the app works on my laptop,  but not my desktop,  which use different nvidia drivers
<ogra_> snap-confine would have to somehow get that into into the core snap before executing the app
<ogra_> thurston, there is an open bug with the proprietary nvidia drivers
<lool> davmor2: hey
<lool> davmor2: ups, EPING
<lool> davidcalle: heya
<lool> davidcalle: around?
<davmor2> lool: D'oh
<thurston> and anyone else confirm for me that my snap won't run for them?
<sborovkov> ogra_: any ideas how I could workaround that for now? Or do I need to wait for a fix basically?
<ogra_> sborovkov, not sure, you could try bind mounting /etc/passwd on top of the ubuntu-core /etc/passwd ...
<ogra_> that is indeed a gross hack
<sborovkov> ogra_: eh, how would I do that?
<sborovkov> I don't care if it's very big hack if I can application running for now :)
<ogra_> mount|grep ubuntu-core ... to find the mountpoint for the highest version
<ogra_> then mount --bind /etc/passwd /snap/mountpoint/etc/passwd
<ogra_> you might need the same for shadow and group files too
<sborovkov> understood, I will try that, thanks
<sborovkov> ogra_: Should I file a bug for this?
<jdstrand> sborovkov: if you specify the 'network' plug you get /etc/passwd (because the network plug uses the 'nameservice' apparmor abstraction)
<sborovkov> jdstrand: Hmm. I have it though. (running in devmode btw)
<sborovkov> As I mentioned above it's working in snappy image
<jdstrand> I think you'll find that if we allowed /etc/passwd, then it would want /etc/group, then nsswitch.conf, then networking, etc
<sborovkov> but not in classic
<diddledan_> does snappy confinement prevent forking or have I got a duff compile of hexchat (the program I'm trying to snapify)?
<jdstrand> sborovkov: oh, then that isn't a security policy thing. what it sounds like is happening is that /etc/passwd from the core snap is being used
<diddledan_> the child process forked by the main client for each server is dying into [defunct] aka zombie state
<jdstrand> diddledan_: snappy allows fork() be default. try getting it to work when installing in --devmode
<thurston> whats the best way to include library files manually?
<diddledan_> ok, devmode works
<sborovkov> jdstrand: I tried mounting /etc/passwd, /etc/group, etc/shadow to ubuntu-core as ogra suggested to get it working with a hack. No luck though, still failing with the same error
<diddletest> see? :-p
<diddledan_> ok, so why does it die when used without devmode I wonder
<jdstrand> sborovkov: ogra_ suggested waiting for zyga. he knows the current state of bind mounts and I suggest waiting for him (since we ruled out the security policy)
<diddledan_> and thanks for the pointer, jdstrand
<sborovkov> jdstrand: Understood, thanks.
<jdstrand> diddledan_: use 'sudo snap install snappy-debug' then do: sudo /snap/bin/snappy-debug.security scanlog
<jdstrand> diddledan_: that should show you (non-dbus) sandbox denials with suggestions on what you need to do
<thurston> whats the best way to include library files manually?
<diddledan_> ok, it looks like it's trying to bind - so plug network-bind might fix it
<diddledan_> awesome. I think that's got it going
<mup> PR snapd#1576 opened: interfaces/builtin: allow getsockopt for connected x11 plugs <Created by zyga> <https://github.com/snapcore/snapd/pull/1576>
<jdstrand> diddledan_: great! :)
<diddledan_> right. now to publish it
<diddledan_> oh, I need to add a menu/launcher entry
<lool> j-b: can you open https://myapps.developer.ubuntu.com/dev/click-apps/5203/ ?
<j-b> lool: no.
<ogra_> sborovkov, i'll poke zyga in real life once he comes out of the session (we are at a sprint currently)
<lool> j-b: http https://search.apps.ubuntu.com/api/v1/search Accept:application/hal+json X-Ubuntu-Release:16 X-Ubuntu-Device-Channel:edge X-Ubuntu-Wire-Protocol:1 X-Ubuntu-Architecture:amd64 'q==vlc.caldav' fields==package_name,architecture,anon_download_url,confinement
<thurston> whats the best way to include library files manually?
<sborovkov> ogra_: thanks :)
<lool> j-b: https://myapps.developer.ubuntu.com/docs API docs
<kalikiana> jdstrand: Any suggestions on ucl chokin on ecryptfs? http://paste.ubuntu.com/20182986/
<lool> j-b: http://195.154.102.74:8000/
<timothy> kalikiana: it should be fixed in snap-confine 1.0.36
<mup> Bug #1604848 opened: Create interface for unity8 scopes <Snappy:New> <https://launchpad.net/bugs/1604848>
<thurston> whats the best way to include library files manually?
<zyga> sborovkov: you should see the real /etc/passwd except for an all-snap system
<zyga> sborovkov: http://pastebin.ubuntu.com/20184274/
<ogra_> hmm, then it is weird that getpwuid_r() actually fails
<zyga> sborovkov: run it in strace
<zyga> sborovkov: or give me the apparmor / seccomp denial
<zyga> didrocks: you can actually bind mount files
<zyga> didrocks: so standalone .mo or anything is ok
<kalikiana> timothy: How/when would I get that?
<kalikiana> Where do I see what version I have?
<thurston_> X Error:  BadValue
<thurston_>   Request Major code 154 (GLX)
<thurston_>   Request Minor code 3 ()
<thurston_>   Value 0x0
<thurston_>   Error Serial #22
<thurston_>   Current Serial #23
<thurston_> thats the error i get on my desktop
<j-b> lool: done.
<sborovkov> zyga: hmm how do I run service with strace?
<sborovkov> zyga: I don't have any apparmor denials, I am running in devmode. Just getpwuid fails
<sborovkov> zyga: I do see real /etc/passwd in ubuntu-core indeed. May be something else is missing, idk
<Cavan> I'm trying to make a snp of Apache Calcite but I cant find a conf file to direct a Makefile, any tips?
<mup> PR snapcraft#675 opened: Allow godeps to fetch Go dependencies <Created by stevenwilkin> <https://github.com/snapcore/snapcraft/pull/675>
<magicaltrout> Cavan: doesn't calcite use maven?
<Cavan> magicaltrout, I'm not too sure, if so would I just need to direct it to a git instead of a makefile?
<magicaltrout> https://github.com/apache/calcite
<magicaltrout> in which case
<magicaltrout> you could use the maven plugin I expect
<magicaltrout> https://github.com/ubuntu/snappy-playpen/blob/cc1e13ca60280c249034bfaa3766072387d38a22/wallpaperdownloader/snapcraft.yaml#L15
<Cavan> magicaltrout, do I need 'calcite:         plugin: tar-content         source: http://www.apache.org/dyn/closer.lua?filename=calcite/apache-calcite-1.8.0/apache-calcite-1.8.0-src.tar.gz&action=download' or should I use the github you just sent? I'm really new to this sorry
<magicaltrout> me too Cavan me too! ;)
<magicaltrout> that tar ball would still need compiling as its a src bundle
<Cavan> magicaltrout, thanks!
<magicaltrout> any time chief
<Cavan> magicaltrout, I've staged and snapped Calcite, any idea how I would check if its working correctly?
<magicaltrout> okay as a disclaimer I'm a developer who has worked with calcite a bit over the years.... my understanding of it in its current state it that a build of calcite would just give you a few libs to hook up to stuff.....
<magicaltrout> so I guess my question is, why calcite? and what are you try to achieve?
<Cavan> magicaltrout, Calcite was picked at random to be honest, just seeing what I can do with Snapcraft really
<magicaltrout> lol
<magicaltrout> okay
<magicaltrout> i'd pick something else
<Cavan> magicaltrout, any recomendations on what would be better?
<magicaltrout> sure there's lots of apache projects that would suit
<magicaltrout> let me peruse the list and find some
<magicaltrout> apache drill would be a good one Cavan if you're interested in data stuff
<magicaltrout> its a nice wrapper around calcite in reality
<magicaltrout> you could snap the spark engine
<magicaltrout> karaf
<magicaltrout> tomcat
<magicaltrout> kafka
<Cavan> magicaltrout, I'll give them all a go aha! Thanks very much
<magicaltrout> nifi
<magicaltrout> :)
<magicaltrout> pick a project thats not just a library basically :)
<jdstrand> kalikiana: yes, that is fixed in later ucl that hasn't landed yet. add this to /etc/apparmor.d/usr.bin.ubuntu-core-launcher: http://paste.ubuntu.com/20187635/
<jdstrand> kalikiana: then do: sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher
<magicaltrout> zeppelin would be a good one as well Cavan
<jdstrand> zyga, sergiusens (cc ratliff): hey, fyi some of the chrome/firefox interface issues can only be resolved once snap-confine 1.0.36 is in xenial. can one of you talk to JamieBennett or mvo to prioritize that SRU?
<jdstrand> I'd ask them myself, but they aren't here now. I will continue to follow up with them
<kalikiana> jdstrand: woot, everything works like a charm again.
 * kalikiana was feeling incomplete with no snaps all day
<kalikiana> thanks!
<jdstrand> kalikiana: np. there are bugs for that. it is queued (and will be fixed in 1.0.36 which I just asked about)
<zyga> jdstrand: ack
<sborovkov> zyga: so any ideas what could be going wrong that getpwuid is not working
<mup> Bug #1604880 opened: Missing inhibit interface <Snappy:New> <https://launchpad.net/bugs/1604880>
<Croepha> not that I really care at this point, but ubuntu-core essentially has a built in key-logger... pretty much every console keystroke I make gets logged as a kernel debug message
<mup> Bug #1604885 opened: Access to mounted USB drives <Snappy:New> <https://launchpad.net/bugs/1604885>
<mup> Bug #1604887 opened: MPRIS interface does not work <Snappy:New> <https://launchpad.net/bugs/1604887>
<thurston> can someone test my snap out on their machine?   sudo snap install rpgdiceroller
<Croepha> thurston: not a chance, sorry, what can we do that you cant do with virtualbox?
<thurston> my desktop throws me an x-window error, and i can't figure out if its because i have multi monitors or what
<thurston> Condition ' x11_window==0 ' is true.
<kalikiana> thurston: I'll try but without sudo ;-)
<kalikiana> could not load libXrandr.so, Error: libXrandr.so: cannot open shared object file: No such file or directory
<kalikiana> Only a single monitor connected right now
<thurston> i didn't realize you could use snap without sudo
<thurston> does the app still come up for you kalikiana?
<kalikiana> thurston: I briefly see a window which closes before I can really see it
<kalikiana> sudo is only required if you're not logged in
<Cavan> Just finished snapping Apache Zeppelin, anyone know any commands to check if i've odne it correctly?
<thurston> kalikiana: thanks for doing that.   i'm trying to figure out how to include libxrandr.   I've got libxrandr2 included, but apparently it doesn't care
<kalikiana> thurston: Is it in a folder in LD_LIBRARY_PATH? You might have to copy or organize the file(s)
<Cavan> (My internet died I dont know if I just sent this) Just finished snapping Apache Zeppelin, how would I check its working correctly, can I run it or?
<thurston> well,  using the plug x11,  it automatically fetches libxrandr2
<thurston> apart from that, i don't know really what you mean by LD_LIBRARY_PATH
<kalikiana> I mean if the lib is in a known path
<kalikiana> As I was having the problem before where the libs would not end up somewhere they would be found
<thurston> this is part of my problem,   i've been asking how exactly to include libraries manually?
<Cavan> How do i run a snap after installation?
<mup> PR snapcraft#676 opened: Special handling for pc files for conflicts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/676>
<thurston> sooo,  any help on how to add libraries to a snap manually?
<kalikiana> thurston: Could it be that you need a symlink?
<kalikiana> ls -R /snap/rpgdiceroller/current/ | grep libXrandr.so
<kalikiana> libXrandr.so.2
<Cavan> How do I run a snap from consol?
<Cavan> Anyone have any idea?
<Croepha> Cavan: is it a daemon ?
<Cavan> Croepha, I'm not too sure. Its Apache Zeppelin, snapped. But also I think I messed up the wrapper and just fixed it so I'm snapping again and seeing
<Croepha> this is your snap?
<Cavan> Yeah
<Croepha> does it have deamon in the app section?
<Cavan> Yes
<Croepha> do you know the service name?
<Cavan> No idea, where would I find that?
<Croepha> it should be systemctl start <service name>
<Croepha> to list snap services: systemctl list-unit-files '*snap*'
<kalikiana> You may want to turn the daemon: line into a comment and run it manually to see if it starts up correctly
<ralsina> Hi there snappers! I am having a weird problem. It seems snapcraft's python3 plugin can't install things that are only available as wheels (in my case, the entrypoints package). See http://pastebin.ubuntu.com/20204182/
<Croepha> ralsina , probably should file a bug
<ralsina> Croepha: ack
<Croepha> is there like a --no-wheel option you can pass to pip as a short term workaround?
<ralsina> Croepha: well, I *need* it to install a wheel
<ralsina> Croepha: and the whole pip invocation is done by the python3 plugin of snapcraft
<ralsina> Reported, bug #1604909
<mup> Bug #1604909: Python3 plugin fails to install requirements that are only available as wheels <Snapcraft:New> <https://launchpad.net/bugs/1604909>
<Croepha> well, if the goal is just to get something working as a snap, then you can bypass the python3 plugin and use the bash plugin, or the copy plugin, assuming you have built outside
<thurston> wow,  how is it so difficult to package a single binary spit out from a game engine?   i can execute the binary on almost any linux system i throw it at,  but when i try to snap it? nope
<Croepha> thurston: yep, its difficult
<kalikiana> Croepha: bash plugin? I don't see any such thing in list-plugins or search
<Croepha> kalikiana: snapcraft github
<Croepha> kalikiana: https://github.com/snapcore/snapcraft/pull/664
<mup> PR snapcraft#664: New plugin: Bash <Created by monsterjamp> <https://github.com/snapcore/snapcraft/pull/664>
<Croepha> miss pasted
<Cavan> When I try and start a service I get 'bash: syntax error near unexpected token `newline''
<ralsina> Croepha: this used to work until recently, the snap is Nikola, worked a few days ago. I suppose some dependency changed somewhere.
<Cavan> Trying to make a command to check if my snap works, i did 'apps:  zeppelin:    command: startzep    plugs: [network-bind]' Is this correct?
<Cavan> Should I remove the plug or should it work anyway?
<dak__> hello, i have a question about snapcraft. i tried to package the angband.
<dak__> i managed to build te snap, but it fail to load, because it looks for game files in /share/games/angband instead of $SNAP/share/games/angband
<dak__> i thouth compiling it with --no-install might help, since the files are all in the same directory
<dak__> but then i get "/snap/angband/100002/command-angband.wrapper: 5: exec: angband: Permission denied" :/
<dak__> any ideas wy the permission is denied?
<jdstrand> kyrofa: hey, re http://pastebin.ubuntu.com/19903287/ it looks like you are using a new snap-confine? I'm guessing /var/log isn't bind mounted so it can't find /var/log/syslog
<magicaltrout>     ttps://docs.google.com/presentation/d/1UdKSsuXpYSy25V9HuxnqgzQRmlC1DEtLJUgEY-5PDoc/edit?pref=2&pli=1#slide=id.p
<magicaltrout> if anyone is bored enough
<jdstrand> kyrofa: how/where are you invoking it?
<magicaltrout> theres the slides from tonights presentation/roasting of mark shuttleworth
 * jdstrand notes it works fine here on xenial classic
<magicaltrout> 2https://github.com/buggtb/snappy-maven-plugin
<magicaltrout> there is a maven plugin to build  a snappy yaml file and build the pacage
<magicaltrout> package
<jdstrand> balloons: re snap.juju.juju unix denial> you either need to create a juju interface or to create a named unix socket that is in $SNAP_DATA
<balloons> jdstrand, hmm
<jdstrand> balloons: is this socket just for internal communications?
<jdstrand> balloons: or are other snaps supposed to be able to consume it?
<tsimonq2> \o/ balloons
<balloons> jdstrand, ahh yes, internal
<balloons> jdstrand, I assume I'll find some more things like this, it would be lovely if I could get some understanding how to proceed with this one
<jdstrand> balloons: looking at the policy, you could make a smaller code change and have the abstract socket path match snap.@{SNAP_NAME}.*
<jdstrand> balloons: so instead of /var/lib/juju/mutex-/store-lock, use snap.juju.mutex/store-lock (or something similar)
<jdstrand> balloons: we have this rule: actually///
<jdstrand> ...
<jdstrand> balloons: actually, what we have should maybe work for you
<jdstrand> balloons: can you paste /var/lib/snapd/apparmor/profiles/snap.juju.juju ?
<balloons> jdstrand, sure
<jdstrand> balloons: actually, if what you pasted the other day was the full denial, I think we need one more rule. Can you file a bug and add the 'snapd-interface' tag? the interfaces team would need to discuss both default policy and/or possibly a new interface. I suspect that we can add a 'unix addr=@snap.${SNAP_NAME}.*,' with no problem. that would require you to make a small code change for the path to go from /var/lib/juju/mutex-/store-lock to snap.juju.
<jdstrand> balloons: but then it would be in your control
<balloons> jdstrand, so I was initially looking at changing /var/lib/juju to somewhere else
<jdstrand> balloons: that won't work atm. with what I am thinking, we can make that work
<balloons> jdstrand, so I can file a bug -- against snapd?
<jdstrand> balloons: the snappy project
<balloons> and you would change the default policy to allow me to bind, but against what path?
<jdstrand> balloons: https://bugs.launchpad.net/snappy/+filebug
<balloons> jdstrand, ohh on launchpad? not github?
<balloons> ohh right.. snappy uses lp. I remember
<jdstrand> balloons: that needs discussion, but I was thinking I'd give you two rules. 1) 'unix addr=@snap.${SNAP_NAME}.*,' and 2) 'unix addr=@/var/snap/@{SNAP_NAME}/**,'
<mup> Bug #1604967 opened: Apparmor denies bind to /var/lib/juju/mutex-/store-lock <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1604967>
<jdstrand> balloons: these aren't real paths in the filesystem-- they are paths in the kernel. we have to namespace them accordingly as a result, but by giving both paths, it makes it so that people can do things in a natural way
<balloons> bah, my install of snappy is still borked. I don't get any binaries after installing my snap anymore (or any other snap from the store)
<wililupy> I have an interresting snap installation error: http://pastebin.ubuntu.com/20229623/
<balloons> jdstrand, I'll work out my snappy install so I can get moving again, but do let me know if you need anything from me on this. As you might be able to tell, I'd like to try and get the juju client itself snappified. It would be nice to have for next week :-)
<jdstrand> balloons: ok, I jotted down my ideas in a trello card and assigned the bug to me
<balloons> jdstrand, many thanks. I assume I may hit another one of these issues, so if there's a way for me to proceed or test changes before you implement, do let me know. I'm happy to delve in a little.
<jdstrand> balloons: we won't have a snapd that will land in time for next week, but I can give you a rule to add to /var/lib/snapd/apparmor/profiles/snap.juju.juju as a workaround
<wililupy> I'm using a custom kernel (3.18.25) and I installed apparmor patches for 3.12, but I'm still getting the above errors. Do you know if Canonical as a patched 3.18.25 kernel in the kernel.ubuntu.com git? I can't seem to find one.
<balloons> jdstrand, yep proof of concept is all I'm after
<jdstrand> balloons: add this rule: 'unix addr="@/var/snap/@{SNAP_NAME}/**",' to that file
<jdstrand> balloons: then do: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.juju.juju
<jdstrand> balloons: then adjust your path internally to use /var/snap/juju/mutex-/store-lock
<balloons> jdstrand, ok, can do. Would /var/snap/juju be safe for other binds then? What about writes?
<jdstrand> balloons: if you just want to test out the existing path, use this apparmor rule instead: unix addr="@/var/lib/juju/mutex-/store-lock",
<jdstrand> balloons: /var/snap/juju would be safe for all the abstract unix sockets. binds, writes, everything is allowed with that rule
<jdstrand> balloons: so you can have 15 different abstract sockets if you wanted, all under /var/snap/juju/...
<jdstrand> or 3 or 37. you get the idea ;)
<balloons> jdstrand, awesome. That might just fix things
<jdstrand> balloons: the final rules that get implemented may be slightly different after discussing the PR, but the concept should be acceptable with no problems
<jdstrand> balloons: also sorry it took a while to respond. I was on holiday and just got back today
<balloons> jdstrand, no worries at all. I'm elated to see it might get solved so quickly :-)
<jdstrand> balloons: it's actually something I've thought a lot about. I'm glad to have a good use case
<diddledan_> o_O I can't figure-out what travis is complaining about in regards to my PR: https://github.com/ubuntu/snappy-playpen/pull/187
<mup> PR ubuntu/snappy-playpen#187: Update hexchat snapcraft.yml <Created by diddledan> <https://github.com/ubuntu/snappy-playpen/pull/187>
<mup> Bug #1605003 opened: cannot communicate with server - openSUSE Tumbleweed <Snappy:New> <https://launchpad.net/bugs/1605003>
<diddledan> ok, I've hit a snag with hexchat - somewhere fchown syscall is being used but I can't figure-out where - is there any way of getting a backtrace leading to the point that seccomp kills an app?
<ali1234> diddledan: i think you would run the program without seccomp and instead inside strace, which can print a backtrace when a specific system call is used rather than just killing it
<ali1234> something like strace -e trace=fchown -k hexchat
<diddledan> strace is telling me -k isn't valid with that
<ali1234> "This option is available only if strace is built with libunwind."
<ali1234> seems like on ubuntu it is not because -k doesn't work at all for me
<ali1234> do you know what file it is calling fchown on? if not, strace should be able to tell you that at least
<diddledan> seems not - all I get is "fchown(16, 1000, 1000)                  = 0"
<ali1234> 16 is the filedescriptor
<ali1234> you can find out what file it is through proc
 * diddledan goes hunting :-)
<ali1234> ls -l /proc/<hexchat pid>/fd/
<diddledan> hmm, 16 isn't there, only 0, 1 and 2
<diddledan> so it's transient
<diddledan> 0, 1 and 2 are stdio?
<diddledan> in, out and err
<ali1234> yes
<ali1234> you could try strace -e trace=open,fchown
<ali1234> then you should see when it opens the fd
<diddledan> roger that
<ali1234> unless it doesn't open it of course, but does fdupe or something
<diddledan> ok, let me paste the two important lines
<diddledan> http://pastebin.ubuntu.com/20241932/
<ali1234> you might need to do -e file which will make a huge log of all file access, and then pick through it
<ali1234> ah...
<ali1234> so it is the scrollback cache/log
<diddledan> yeah
<ali1234> and it is setting it to be read only by you, nobody else on the system, which is totally reasonable
<diddledan> I think it's using glib's IO functions for those
<diddledan> so either glib or the C library is calling the fchown
<ali1234> yes, but it will be initiated by hexchat
<diddledan> could this be it? >>> ostream = G_OUTPUT_STREAM(g_file_append_to (sess->scrollfile, G_FILE_CREATE_PRIVATE, NULL, NULL));
<ali1234> yes
<ali1234> G_FILE_CREATE_PRIVATE
<ali1234> and the filename on disk even contains goutputstream
<diddledan> that helped me narrow it down
<ali1234> that's in common/text.c?
<diddledan> yup
<ali1234> i was just opening that file to have a look :)
<ali1234> but you beat me to it
<ali1234> there's actually two places where G_FILE_CREATE_PRIVATE is used int hat file
<diddledan> there's two uses of that constant
<diddledan> yeah that ^^^
<ali1234> no idea how you are supposed to fix this though
<diddledan> me either
<diddledan> I'm wondering if the isolation rules might need adjusting to allow fchown to the current userid
<diddledan> (if that's even possible?)
<ali1234> i probably know less about that than you at this point
<diddledan> might be worth my while emailing the snappy-dev list so there's a more permanent record that can be commented-on
<ali1234> yeah
<ali1234> or ask here in business hours :)
<diddledan> :-)
<diddledan> I don't "do" business hours :-p
#snappy 2016-07-21
<qengho> diddledan: seccomp could totally change for that. Please file a bug report on "snappy" and then tag the report with "snapd-interface".
<qengho> $ ubuntu-bug snappy
<goddard> how can i build my snappy package if it doesn't have the library version i need
<goddard> it had a library i need from 14.04 but it isn't in 16.04
<qengho> goddard: You can get the source, assuming it's still online.
<goddard> qengho: and then with the source it can build the project an automatically find the library?
<qengho> goddard: Library is another part. Get the source with a tag or branch name.
<qengho> goddard: Try it!
<goddard> qengho: ok so i have to get the source of the library as well?
<qengho> goddard: I assume so!
<qengho> goddard: An example from my project:  http://bazaar.launchpad.net/~privacy-squad/+junk/tor-middle-relay-snap/view/head:/snapcraft.yaml
<qengho> .../qt5/qml/Ubuntu/Components/1.3/Icon.qml:113:5: QML QQuickImage: Failed to get image from provider: image://theme/back
<qengho> Argh.
<qengho> I need more tables to flip.
<wililupy> I lost it in my emails, how do I install the ubuntu-classic snap?
<wililupy> nm, found it.
<qengho> wililupy: what is it? Someone will see your question.
<wililupy> qengho: http://pastebin.ubuntu.com/20274792/
<qengho> wililupy: thanks!
<mup> PR snapd#1576 closed: interfaces/builtin: allow getsockopt for connected x11 plugs <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1576>
<liuxg> when I use license in snapcraft.yaml, it says "DEPRECATED: 'license' defined in snapcraft.yaml". what is the correct way to use a license file? thanks
<qengho> liuxg: I think you want something in meta/ dir.
<liuxg> qengho, it seems to me that the document is outdated. do you have an specific example for it?
<liuxg> qengho, meta/dir is the one generated during the snapcraft, right?
<qengho> liuxg: I have snapcraft source code!
<qengho> liuxg:  meta/license.txt
<liuxg> qengho, OK. In a snap project, we should not create the meta directory.
<qengho> liuxg: oh, wait.  setup/license.txt
<liuxg> qengho, everything must be from the snapcraft.yaml. so we need find something defined there.
<liuxg> qengho, it seems right :)
<dholbach> hey hey
<qengho> The Holbach. Good morning.
<dholbach> :-)
<dholbach> how are you all doing?
<liuxg> qengho, I just moved it to the "setup" directory, however, it seems it is still the same.
<qengho> Okay. The Qt app I'm working on has inexplicable failure.
<qengho> liuxg: remove "license" from your YAML.
<liuxg> qengho, then how about the other fields like "license-agreement"?
<liuxg> qengho, license-version?
<liuxg> qengho, I did it at your suggestion, when I installed it, it did not prompt me to accept the license file.
<qengho> liuxg: I think you need those. They are copied straight to snap YAML.
<liuxg> qengho, i need them in the snapcraft.yaml?
<qengho> liuxg: Yes, license-agreement and license-version .
<qengho> license-agreement: true  ?
<qengho> Not sure.
<liuxg> qengho, http://paste.ubuntu.com/20278290/, is this right?
<qengho> wo bu zhidao
<liuxg> qengho, thanks!
<kgunn> robert_ancell: https://bugs.launchpad.net/snappy/+bug/1574851
<mup> Bug #1574851: libgl not found on nvidia machines (so far) <Snappy:Triaged> <nvidia-graphics-drivers-361 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1574851>
<mup> PR snapd#1571 closed: tests: add network-observe interface spread test <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1571>
<mup> PR snapcraft#677 opened: playing with caching <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/677>
<mup> PR snapcraft#676 closed: Special handling for pc files for conflicts <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/676>
<mup> PR snapcraft#678 opened: Release debian/changelog for 2.13 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/678>
<seb128> sergiusens, hey, it was nicer when snapcraft changelog had a summary of the changes, more exciting as an user
<seb128> the new format doesn't motivates me to update
<seb128> like I don't see anything fancy/useful listed and I'm like "bah"
 * kalikiana wonders how to get rid of manpages and include files: snapcraft always fails when using "stage" to drop folders from parts/*/install
<didrocks> zyga: http://paste.ubuntu.com/20290323/
<qengho> kalikiana: I see that sometimes too.  :(
<qengho> kalikiana: I think, anyway. What is your error message?
<kalikiana> stage:
<kalikiana>     - -share/man
<kalikiana> [Errno 2] File or folder doesn't exist: '/home/cris/bau/neovim/stage/share/man/man1/nvim.1'
<qengho> kalikiana: is that during a clean build, or an update?
<qengho> kalikiana: I think we need a report of that bug. Do you mind filing it?  $ ubuntu-bug snapcraft  #probably
<qengho> (Distro agnosticism is making support harder.)
<kalikiana> qengho: Either one, makes no difference
<kalikiana> Well, ubuntu-bug should  be snapped, problem solved ;-)
<qengho> kalikiana: You are a genius.
<kalikiana> https://bugs.launchpad.net/snapcraft/+bug/1605164
<mup> Bug #1605164: Errors due to "missing" files using "stage:" <Snapcraft:New> <https://launchpad.net/bugs/1605164>
 * qengho hugs kalikiana.
<Cavan> Whats a simple run command for an snap I've created?
<kalikiana> SNAPNAME.APPNAME or SNAPNAME if SNAPNAME==APPNAME
<kalikiana> That's the formula
<kalikiana> And if it's a service it becomes snap.SNAPNAME.APPNAME
<qengho> Cavan: so, it's your defined command block name, or cavansnapname dot commandname if they're different.
<Cavan> I created a generic randomly named command in the .yaml and when I try to snap I get the error 'The specified command 'zep' defined in the app 'zep' does not exist or is not executable'
<Cavan> qengho*
<qengho> Cavan: $ find prime -type f -name zep |sed -e s,^prime/,,
<Cavan> qengho, nothing visable happens on the terminal after i type the command
<qengho> Cavan: then inside your snap result, you are not making something called "zep". Explore that "prime" tree.
<qengho> $ find prime |more
<Cavan> qengho, basically I'm trying to snap Apache Zeppelin, but I cant figure out how to run the snap. It only seems to run as a service when Its a Deamon and wont let me run it as a executable
<qengho> Cavan: Check the tree I said^. You're either not compiling what you think, or it's not called what you think.
<qengho> Cavan: Er, wait, it's running in one command block and not in another? Same name?
<Cavan> quengho, Originally it looked like this 'apps:  zeppelin:    command: bin/wrapper    daemon: simple    plugs: [network-bind]' And the service ran fine, but I cant do anything else with it. SO I tried changing it to this 'apps:  zep:    command: zep    plugs: [network-bind]' to see if I can run it but now it does nothing
<qengho> Cavan: You had a program called /bin/wrapper. It worked. Now you're trying to run /zep and it's not working. It's because /zep inside the snap is not a program
<qengho> Cavan, maybe you should look at bin/wrapper to see what it runs.
<Cavan> quengho, Can I paste the wrappen in chat so you can have a look if you dont mind?
<qengho> Cavan: Did you look?
<Cavan> qengho, Yeah there is a frew exports with file paths
<qengho> Cavan: The short of it is after "command: " is a real live file inside snap, and you can't just invent a name to put there. It has to be something that exists.
<Cavan> qengho, that makes sense aha, I'm very new to this
<qengho> Cavan: The short of it is, after "command: ", is a real live file inside the snap, and you can NOT just invent a name to put there. It has to be something that exists.
<qengho> Cavan: The name after "apps:", that begins the next block IS a name that you invent. It can be anything. The command: part coming after that is the name of somethign on disk, and you have no liberty there.
<ILoveArchLnx> Got some haters in the #ubuntu chat... pretty quick to ban/kick... no jesting allowed? do we have senses of humor in this room? How's everyone doing today/tonight?
<ILoveArchLnx> Not looking to troll, just want to participate in some chatting
<timothy> ILoveArchLnx: good nick
<sborovkov> Hi. So any ideas what I could do about getpwuid() failing on classic? should I file a bug?
<ILoveArchLnx> thank you timothy!
<ILoveArchLnx> If I ask the wrong question though I might get banned... I was really honestly looking to find out more about Snappy packages but I asked if they are newer than normal LTS and poof.. ban hammer.
<ILoveArchLnx> probably that question plus my nick... probably looked like trolling so I understand but garsh it was quick
<davmor2> ILoveArchLnx: snapcraft.io will tell you most of what you want to know
<ILoveArchLnx> thanks davmor2 ! You are amazing.
<ILoveArchLnx> whoa snaps on the Arch!?
<ILoveArchLnx> ... holy awesome?
<timothy> yes, I maintain it
<ILoveArchLnx> timothy I love you man, you are my hero.
<ILoveArchLnx> I only maintain a couple AUR packages but I would love to one day help contribute to something bigger than myself such as this. Are the snaps pretty much "on-par" with normal Arch packages as far as "in-line" with developer stable releases??
<ILoveArchLnx> "more in-line" I should say. Still takes maintainers but yes, are Snaps pretty "fresh" so to speak?
<timothy> it depends, snap are only a "cointainer". people can put it anything they want
<timothy> for example we have vlc "daily" snaps
<ILoveArchLnx> oh... like a jail or chroot? or more so like a Docker/rkt container?
<ILoveArchLnx> does it use lvm or some form of virtualized file-system and fs manager?
<timothy> it uses squashfs images + something to do containment
<ILoveArchLnx> or kernel level?? I'm excited sorry for the crazyness and I haven't slept and coffee lol
<timothy> in http://snapcraft.io/ you'll find any information
<ILoveArchLnx> nice, I've heard of squashfs but haven't read much into it
<ILoveArchLnx> Oh ok, thanks bud! I'll do some reading. I might be back later to talk someone's ear off if they have one they want talked off :) I like to conversate. Learning from books is awesome and so is learning from people.
<ILoveArchLnx> love love love learning!
<ILoveArchLnx> thanks everyone! see you all around sometime!
<ILoveArchLnx> you rock timothy !!
<Cavan> how do I stop a service?
<sborovkov> zyga: I don't see real /etc/passwd actually in ubuntu-core on classic. It's very similar file but has no ubuntu user for instance. Same with /etc/group, /etc/shadow. They are a bit different from real one
<zyga> sborovkov: you must be running an older version of snap-confine then
<ogra_> there should never be an ubuntu user inside /etc/passwd ... it should be in var/lib/extrausers
<zyga> sborovkov: the one coming out of the sru will be okay
<zyga> ogra_: this is classic )
<sborovkov> sru?
<ogra_> zyga, i thought he looks at the ubuntu-core snap under classic
<qengho> Cavan: Use "systemctl".
<mup> Bug #1605216 opened: cups-control interface doesn't allow printing <Snappy:New> <https://launchpad.net/bugs/1605216>
<sborovkov> ogra_: well it'ubuntu user is in /etc/passwd. From what zyga told me I should see the real one in ubuntu-core. And that's where I saw the difference
<sborovkov> so what's sru?
<ogra_> a stable release update
<ogra_> (of a package)
<sergiusens> seb128 it was an SRU team requirement for me to do the changelog this way
<seb128> ?!
<seb128> who in the SRU team?
<seb128> also SRU rules don't apply to yakkety :p
<zyga> sborovkov: you see the non-real one in /snap/ubuntu-core/current/etc/passwd
<zyga> sborovkov: run a shell inside a snap and see again
<zyga> sborovkov: sudo snap installl snapd-hacker-toolbelt
<tsimonq2> sergiusens: it owuld be nice to land my debian/control changes as well ;)
<zyga> sborovkov: snapd-hackert-toolbelt.busybox sh
<tsimonq2> *would
<Cavan> qengho, is there any specific command or help I can type to terminate the service, Cant seem to find it through that
<sergiusens> seb128 yeah, but I use the same changelog for each
<qengho> Cavan: "systemctl |grep yourservicename", "servicectl stop fullservicename"
<seb128> sergiusens, who in the SRU team told you that you can't describe what is new in the update?
<seb128> I want to talk to them
<sergiusens> seb128 -> slangasek
<seb128> that's nonsense
<seb128> sergiusens, thanks
<sergiusens> seb128 it is common practice in other packages though, isn't it?
<seb128> slangasek, hey, can you explain why a snapcraft SRU couldn't have its changelog to use " * new upstream version (lp...)\n-new option\n-nicer log\n-updated manpages"?
<MonkeyDust> hi, trying snappy for the first time, in a ubuntu 16.04 chroot ... when typing 'snap list', it returns this error ... hint & tips please ... http://paste.ubuntu.com/20301926/
<seb128> sergiusens, it's not uncommon but I tend to have "- ..." subitems describing the most interesting changes so users know what they get
<seb128> also most SRUs are not version updates but specific changes and those are detailed
<seb128> sergiusens, see e.g https://launchpad.net/ubuntu/+source/unity/7.4.0+16.04.20160715-0ubuntu1
<Cavan> qengho, I ran both commands and the service is still running?
<qengho> Cavan: How can you tell?
<Cavan> qengho, systemctl list-unit-files '*snap*'
<qengho> Cavan: does that say if it's running? I don't think so.
<Cavan> qengho, ah yeah sorry, the local host has stopped aswell, thanks!
<qengho> Cavan: If it is, you have your daemon misconfigured. See the "daemon: VALUE" in your snapcraft YAML.
<dholbach> tsimonq2, https://www.youtube.com/watch?v=nPFMcZLdmog â nice work
<dholbach> ^ dpm, davidcalle, didrocks, popey, mhall119
<tsimonq2> hey woah dholbach that talks about my PR being merged being in the past tense
<tsimonq2> dholbach: not really ready to show everyone yet :P
<dholbach> ok, I won't share it on @snapcraftio just yet then :-)
<dholbach> I thought your PR had already landed
<tsimonq2> hold your horses :)
<sborovkov> zyga: indeed. there is ubuntu when I do it that way. Does that mean that getpwuid fails because of some other reason?
<tsimonq2> dholbach: and btw my video is actually decent? :D
<dholbach> tsimonq2, very much so
<dholbach> nice work
<dholbach> let me know when I can share it publicly :)
<kalikiana> qengho: Wrt bug 1605164 I saw another yaml using "snap" instead of stage/prime as "snapcraft help plugins" suggests and tried that. That seems to work - I still don't get the behavior of "stage" but it does what I need.
<mup> Bug #1605164: Errors due to "missing" files using "stage:" <Snapcraft:New> <https://launchpad.net/bugs/1605164>
<qengho> kalikiana: Right, that changes which step omits that file from copying. It should work either place.
<kalikiana> qengho: I added the info to the bug. Me thinks the documentation here is lacking.
<kalikiana> Whatever stage does I cannot figure out at all
<qengho> Thx.
<kalikiana> Shaved 1M off my snap thanks to dropping unnecessary docs and headers :-D
<qengho> Nice.
<qengho> I need to do the same. I'll follow your lead.
<kalikiana> Grrr I really think "snap install/remove" should tell me if it finds running instances of commands from a snap, it's annoying that it's getting stuck all the time.
<qengho> kalikiana: I reported that already. https://bugs.launchpad.net/snappy/+bug/1587676
<mup> Bug #1587676: forked, background processes can prevent "snap remove" with unhelpful message <Snappy:New> <https://launchpad.net/bugs/1587676>
<kalikiana> qengho: Oh, nice, thanks
<MonkeyDust> hi, trying snappy for the first time, in a ubuntu 16.04 chroot ... when typing 'snap list', it returns this error ... hint & tips please ... http://paste.ubuntu.com/20301926/
<qengho> MonkeyDust: "chroot"?
<MonkeyDust> qengho  are you not familiar with chroot?
<qengho> MonkeyDust: snappy is snapd, and a kernel that has special security and filesystem features. I don't know what you're doing with chroot, but I would be astonished if it were enough.
<MonkeyDust> qengho  ok, then that's it, cannot be done in a chroot, thanks
<qengho> MonkeyDust: it's not just a bunch of files on disk. I don't think chroot will do it.
<MonkeyDust> qengho  then let that be my first 'snappy lesson'
<qengho> MonkeyDust: Your kernel might be enough. I don't know how you're going to hook to the main systemd, though, and that message looks like snapd isn't running.
<kalikiana> Interesting, all my terminals now hang indefinitely while "snap install" is stuck spinning "security profiles"
<mup> Bug #1605250 opened: the snap of the interface is combined with that of the only issue with the theme ambiance <Snappy:New> <https://launchpad.net/bugs/1605250>
<tsimonq2> sergiusens: can you take another look at snapcraft#619 ?
<mup> PR snapcraft#619: Add source-checksum option <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
<qengho> kalikiana: I bet "lsof |grep /snap" will illuminate you.
<tsimonq2> dholbach: snapcraft#619 is my PR ;)
<liuxg> sergiusens, I have tried your telegram app, which is cool. A shortcoming is that it does not support Chinese though I have tried to install the Chinese fonts by modifying it. Now, the new snapcraft.yaml looks like http://paste.ubuntu.com/20307314/ what could be the problem for it? thanks
<zyga> sborovkov: which version of snap-confine or ubuntu-core-launcher are you using?
<mup> Bug #1605258 opened: SNAPD_DEBUG_HTTP should print HTTP headers <Snappy:New> <https://launchpad.net/bugs/1605258>
<kalikiana> qengho: "all my terminals hang indefinitely" ;-) After having rebooted my guess is snapd ate all my RAM
<mup> PR snapcraft#679 opened: add multiple generator script options to autotools <Created by apachelogger> <https://github.com/snapcore/snapcraft/pull/679>
<sborovkov> zyga: snapd 2.0.10, ubuntu-core-launcher 1.0.27.1
<mhall119> zyga: I won't be able to make our weekly call today, but I figure you're busy this week too :)
<mhall119> shall we catch up next week?
<mup> PR snapcraft#678 closed: Release debian/changelog for 2.13 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/678>
<Cavan> I snapped Zeppelin but when I run the local host its connecting after install?
<kalikiana> If it's a service, yes
<mhall119> zyga: kyrofa: would it make sense for $HOME to be /home/$USER/ when a snap is connected to the "home" interface?
<mhall119> otherwise things like opening files in Geany become tedious
<Cavan> I snapped Zeppelin but when I run the local host its not* connecting after install?
<Cavan> misstype
<zyga> mhall119: maybe, we talked about it as something to explore for the caja snap
<zyga> mhall119: but then again we wanted the home interface to be provisional and temporary
<dholbach> didrocks, https://travis-ci.org/ubuntu/snappy-playpen/builds/146207147 - could it be that we need to add 'git' to the docker image?
<zyga> mhall119: yes, let's catch up next week (I'll be sprinting again but I'll try to make it)
<zyga> sborovkov: you probabyl want 1.0.38 for snap-confine
<zyga> sborovkov: wait for the SRU or try proposed
<sborovkov> zyga: proposed as in not stable version yet? How do I upgrade to it
<diddledan> ergh @ wrong package: https://bugs.launchpad.net/ubuntu/+source/snappy-player/+bug/1605273
<mup> Bug #1605273: Seccomp should allow fchown() with current userid/groupid <amd64> <apport-bug> <snapd-interface> <xenial> <snappy-player (Ubuntu):New> <https://launchpad.net/bugs/1605273>
<diddledan> sorry, can someone let me know what the correct package should be? snappy-player was automatic
<Cavan> Cant get the snapped Zeppelin to run in local host, any ideas?
<jdstrand> diddledan: I fixed it
<diddledan> thankyou
<slangasek> seb128, sergiusens: I did not say that the SRU changelog can't describe the contents of the update; I said that a package that has an SRU exception shouldn't include extra bug references in the changelog
<Cavan> How would I reference a spark plugin through the .yaml?
<dholbach> Cavan, is this a plugin you wrote?
<dholbach> http://snapcraft.io/docs/build-snaps/plugins
<boghison> Can someone please take a look? https://github.com/snapcore/snapcraft/pull/579
<mup> PR snapcraft#579: Add new plugin: rust <code-conflict> <Created by mariogrip> <Conflict> <https://github.com/snapcore/snapcraft/pull/579>
<Cavan> dholbach, I didnt use that but I'm about to
<dholbach> Cavan, nice
<seb128> slangasek, sergiusens, ha, that makes more sense to me ;-)
<dholbach> boghison, everybody's at a sprint right now, so code reviews could take a bit longer this week
<josepht> boghison: there are still conflicts in that PR
<boghison> josepht: Last message
<josepht> boghison: did you push to the correct branch?
<boghison> josepht: What do you mean? This is a commit in master in my fork of the OP's fork. I just want to fix those test issues and then the commit can be merged (he's still the author)
<josepht> boghison: sorry, I was confused.  I'll take a look in a bit.
<seb128> is that a known issue?
<seb128> "ecryptfs_dir_open: Error attempting to initialize the lower file for the dentry with name [/]; rc = [-13]"
<seb128> snaps refuse to start on my xenial I think due to that error
<seb128> jdstrand, ^ do you know about that?
<boghison> josepht: No worries :)
<jdstrand> I think that is likely fixed in the ucl that is trying to find its way in xenial. add this to /etc/apparmor.d/usr.bin.ubuntu-core-launcher : http://paste.ubuntu.com/20187635/, then do sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher
<seb128> jdstrand, thanks, I tried the proposed version and it fails on another issue, "cannot bind mount /media to /tmp/snap.rootfs_TOuoFW/media. errmsg: Permission denied"
<seb128> [  179.919020] audit: type=1400 audit(1469114803.329:42): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/tmp/snap.rootfs_TOuoFW/media/" pid=6392 comm="ubuntu-core-lau" srcname="/media/" flags="rw, rbind"
<seb128> let me go back to the previous version with your change
<jdstrand> zyga: fyi ^
<jdstrand> I saw /mdeia/ changes go through when I was on holiday
<seb128> things were working a week ago
<seb128> unsure what changed/regressed
<seb128> I hope it doesn't mean we got a regression/snappy not working on ecryptfs in .1
<jdstrand> xenial still has 1.0.27.1
<jdstrand> that has the ecryptfs fix
<seb128> that's the version I have
<seb128> ParamÃ©trage de ubuntu-core-launcher (1.0.27.1) ...
<seb128> $ gnome-logs-udt.bash
<seb128> failed to create user data directory. errmsg: Permission denied
<jdstrand> I fixed the ecryptfs policy a long time ago but with the snap-confine rename, etc, it never made it to sru
<jdstrand> so, when you upgraded, you would have gotten the ecryptfs change, but there was that /media/ issue. downgrading would have reverted the ecryptfs fix and you'd need the workaround again
<seb128> k
<SamYaple> reviews and merges for PRs in snapcraft seem to take a while. anything I can do to help with that?
<seb128> but things were working on that machine a week ago
<SamYaple> I have some week old PRs I would like to see merged
<seb128> I wonder why that just started being an issue
<jdstrand> seb128: I'm fairly certain I gave you the work around policy before
<jdstrand> so it would've been working
<seb128> oh, maybe I had it for a long time and forgot about it
<jdstrand> right
<seb128> k
<seb128> thanks jdstrand
<jdstrand> like I said, this sru has been many weeks
 * jdstrand will be glad when it lands
<seb128> well I didn't have the snap-confine binary before now
<seb128> so I wonder what reverted my local change
<seb128> but doesn't matter much
<jdstrand> SamYaple: I think one of those is on my todo-- I was on holiday until yesterday
<jdstrand> the upgrade would've removed the ubuntu-core-launcher profile and the reinstall would've put it back
<mup> Bug #1589527 changed: Debug option for http requests <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1589527>
<SamYaple> jdstrand: no rush, I just want to make sure whoever is goign to review it isn't waiting on me for anything
<jdstrand> SamYaple: also, most snappy devs are sprinting this week
<SamYaple> jdstrand: im trying to get the python2 and python3 plugins into shape so I can start packaging openstack
<seb128> jdstrand, back to a working system, thanks!
<SamYaple> jdstrand: does that mean more or less PR attention?
<jdstrand> SamYaple: anything that is needed from you should show up in the pr, so you should be fine
<jdstrand> SamYaple: not sure-- that sounds like something for the snapcraft devs (also sprinting)
<SamYaple> alrighty. well thanks for the info
<SamYaple> i believe someone mentioned being able to use a single snap but launching different daemons from it, i havent been able to figure that out yet
<SamYaple> can anyone point me in the right direction?
<jdstrand> SamYaple: if I understand your question, if you have 3 services you want to start on boot, you just do:
<jdstrand> apps:
<jdstrand>   foo:
<jdstrand>     command: ...
<jdstrand>     daemon: simple
<jdstrand>   bar:
<jdstrand>     command: ...
<jdstrand>     daemon: simple
<jdstrand>   baz:
<jdstrand>     command: ...
<jdstrand>     daemon: simple
<SamYaple> not quite, in your example I have tree services foo, bar, baz, they _can_ all run with the snap, but they should also be able to run without eachother
<jdstrand> you can have as many entries in 'apps' as you want. drop 'daemon: simple' for something you want exposed in /snap/bin
<SamYaple> so foo is on node1 and bar is on node2
<SamYaple> s/tree/three/
<SamYaple> so if a snap has multiple daemons, I want to be able to only run a subset of those, is that possible?
<jdstrand> SamYaple: otoh one was to solve that would be ship foo, bar and baz, but not expose them in 'apps', and create a manager application that is exposed via 'apps'. the manager application starts/stops foo, bar and baz based on communications with other nodes
<jdstrand> SamYaple: yes, you can ship all kinds of things in your snap including internal binaries, then you can control what runs when via something that is external (ie, in 'apps')
<jdstrand> SamYaple: another way to do it would be to expose foo, bar and baz in 'apps', but have all of them honor a config file that something else manages
<SamYaple> jdstrand: right thats what I was thinking
<SamYaple> but rather a manager like you suggested first
<SamYaple> i think that can work
<SamYaple> jdstrand: i think im following you. let me play around with ti for a bit and see if can make it do what im thinking
<jdstrand> SamYaple: note, if you are starting and stopping services yourself, you can't tie those services into the systemd boot (ie, the manager app owns all parts of the lifecycle for those)
<SamYaple> jdstrand: ok thats what I thought. so if I lay down a service file and tell it to run foo.service1 and seperate one for foo.service2 then i should be good?
<jdstrand> the managing of config files would allow those to tie into systemd. it all depends on what you need
<SamYaple> i think im with you. ill just need some testing to fully wrap my brain around it
<jdstrand> SamYaple: well, no-- that is what I was saying won't work. the only way you get service files is through daemon declarations in 'apps' (and you can only control the contents of those via the yaml directives-- you can't supply a service file).
<jdstrand> SamYaple: so if you try the first approach (manager launches things), you need to have all tha launching and management logic in the manager. if you use the second approach (all are daemons declared in 'apps' but they consult a config file you control on whether to actually start or not), then you can use systemd
<jdstrand> and the manager just manages the config files
<SamYaple> jdstrand: hmm should that not work though through systemd? lets say something simple like a uwsgi api, i can just launch `/snap/bin/foo.uswgi /path/to/config`?
<jdstrand> sure that would work
<SamYaple> ok thats what I was thinking of doing.
<jdstrand> I thought you implied corrdination via nodes, which is why I tossed the manager in there
<SamYaple> nah there is outside corrdination, the service itself is unaware
<lfaraone> During a `plugin: python2` part, are `stage-packages` supposed to be made available during the Snap build? I'm having issues building a snap that depends on `psycopg2` -- it fails with "    Error: You need to install postgresql-server-dev-X.Y for building a server-side extension or libpq-dev for building a client-side application.", but both
<lfaraone> `postgres-server-dev-all` and `ligpq-dev` are listed in `stage-packages`.
<SamYaple> lfaraone: that should be build-packages no?
<lfaraone> that sounds more correct, yes. :)
<jdstrand> SamYaple: make sure the config is in $SNAP_DATA somewhere (ie, the writable area), then the admin or whatever can adjust it
<SamYaple> jdstrand: im new here, im not sure what $SNAP_DATA is refering too? (or maybe I am but I am confused)
<jdstrand> SamYaple: an environment variable. you can see all the env vars by install hello-world then doing: hello-world.env |grep SNAP
<SamYaple> ok will check
<jdstrand> SamYaple: or play around with hello-world.sh which gives you a shell running under confinement
<SamYaple> jdstrand: so question here. for an explict example, I am using snappy to package openstack keystone and the replace a baremetal installed keystone service, its configs are located at /etc/keystone and I am hardcoding that into the snap, is this wrong?
<Cavan> Still having problems getting Apache Zepplin to work, just wont load into the localhost
<jdstrand> SamYaple: yes-- snaps have readable and writable areas available to them separate from each other and the system
<jdstrand> SamYaple: you'll want to put things that don't change in $SNAP (the install directory) and things that will change in $SNAP_DATA (the data directory)
<SamYaple> up until now i was just backing in the config for testing, but i think this might be an issue. the config needs to stay in /etc/keystone (not be moved to $SNAP_DATA)
<SamYaple> thats not possible is it?
<jdstrand> SamYaple: davidcalle and/or dholbach should be able to point you at up-to-date docs to help you. There is https://developer.ubuntu.com/en/snappy/guides/ but some of that is for series 15.04 and not series 16
<jdstrand> SamYaple: that is not allowed, no. you'll need to adjust your code to use /var/snap/keystone/current/etc/keystone or honor $SNAP_DATA (ideally the latter)
<SamYaple> well thats a real shame. thats a limitation im not going to be able to work around. for just about anything I would want to use snappy for
<jdstrand> SamYaple: why? it shouldn't be hard to adjust code to check the env var? that said, you might be interested in https://bugs.launchpad.net/snapcraft/+bug/1577514
<mup> Bug #1577514: Support preloading to make snaps feel at home <snapd-interface> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1577514>
<jdstrand> SamYaple: once implemented, that would allow you to declare what paths should be mapped without code changes
<jdstrand> SamYaple: eg, the code would use /etc/keystone, but you'd declare to map /etc/keystone to $SNAP_DATA/etc/keystone
<SamYaple> jdstrand: to answer your first question, no I can't adjust code to use an env variable, nor would I want to adjust code to be specific for a packing tool
<SamYaple> once what you are describing is implemented I can revisit the issue. its a pretty hard stop for me right now. im rackign my brain for other solutions
<SamYaple> hmm even if thats implemented, sharing sockets still won't be possible will it?
<SamYaple> well. maybe. i guess it would depend on the implementation
<jdstrand> SamYaple: a named socket should be doable using the same technique. anonymous sockets are allowed today and abstract sockets will be when bug #1604967 is implemented
<mup> Bug #1604967: Apparmor denies bind to abstract unix sockets such as @/var/lib/juju/mutex-/store-lock <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1604967>
<jdstrand> SamYaple: another approach would be adding interfaces for openstack
<jdstrand> SamYaple: (I might also mention that /etc isn't allowed in part because /etc is mounted readonly on all-snaps systems)
<jdstrand> SamYaple: ok, I noticed https://bugs.launchpad.net/snapcraft/+bug/1577514 didn't have a lot of detail so I tried to give some and asked for clarity on the priority and implementation. would you mind describing your use case and that the lack of this feature is a showstopper for you?
<mup> Bug #1577514: Support preloading to make snaps feel at home <snapd-interface> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1577514>
<Croepha> anyone here get pulseaudo to work on ubuntu-core? im trying to run it in a chroot, but udev isn't reporting back any sound cards
<jdstrand> niemeyer: hey, would you mind looking at https://bugs.launchpad.net/snapcraft/+bug/1577514/comments/6 (and (potentially) later comments) and ask JamieBennett (not on irc now) to take a look too? maybe you can have a hallway conversation to get the priority sorted (it came up again today in the context of openstack)
<mup> Bug #1577514: Support preloading to make snaps feel at home <snapd-interface> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1577514>
<Cavan> If the bin/ doesnt have a wrapper what should I direct it to? The snaps I've made have all had wrappers so I'm a tad confused
<SamYaple> jdstrand: its a showstopper for _me_ because I dont have the ability to control the config files locations. more accurately the projects I am attempting to integrate snappy with only use /etc/* folders for config files
<SamYaple> jdstrand: from a technical perspective, it should be doable. from a practicle perspective, not being able to pull in /etc/* configs is a sever limitation
<SamYaple> though there is always that occasion program that was coded poorly and hard codes a /etc/* conf into the source code too
<boghison> josepht: Any news?
<josepht> boghison: none yet
<iliv> I accidentally ran snap remove for a package that was mounted. snap was trying to remove it but it couldn't succeed for a long time so I interrupted its execution with Ctrl-C. Now when I try to run remove or install I get this error message:
<iliv> error: cannot remove "PKGNAME": snap "PKGNAME" has changes in progress
<iliv> how do I clean up this mess?
<balloons> open question -- does anyone know why after installing a snap, I don't get the binary in my PATH? How can I add snap binaries back to my path?
<iliv> balloons, what is your PATH/
<iliv> ?
<iliv> balloons, also, are you invoking your command in this format: pkgname.command ?
<balloons> iliv, /home/nskaggs/.local/share/umake/nodejs/nodejs-lang/bin:/home/nskaggs/.node_modules/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/bin:/home/nskaggs/projects/go/bin
<iliv> for example, mypackage.telnet
<iliv> balloons, this is what I have on my system:
<iliv> $ env |grep PATH
<iliv> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
<balloons> iliv, see for example: http://paste.ubuntu.com/20333336/
<iliv> not the /snap/bin at the end of the line
<balloons> iliv, that was the ticket, ty. I'm just not sure why I didn't get it added
<iliv> balloons, if memory serves, I didn't have to do anythign myself for it to be added to PATH
<iliv> balloons,
<iliv> $ grep "export PATH" /snap/hello/current/command-hello.wrapper
<iliv> export PATH="$SNAP/bin:$SNAP/usr/bin:$PATH"
<balloons> jdstrand, so I rebuilt my snap using the /var/snap path, and I'm trying to add unix addr="@/var/snap/@{SNAP_NAME}/**" as suggested. But it's not parsing the apparmor rule after I do it. What should it look like? http://paste.ubuntu.com/20334627/
 * balloons facepalms
<balloons> I missed a comma, sorry
<iliv> balloons, that happens more often that you'd think ;)
<balloons> what do you do in general with looking for config files in XDGDataHome?
<balloons> hmm.. looks like using a bash script to launch
<renatu> guys I created a interface for the calendar app, but I am getting this error: - Setup snap "ubuntu-calendar-app" (unset) security profiles (cannot setup mount for snap "ubuntu-calendar-app": cannot obtain mount security snippets for snap "ubuntu-calendar-app": unknown security system)
<renatu> and the dbus connection is not working when running app
<gustavopadre> hi guys, I'm really excited about snaps, could someone do a snap file of https://github.com/Aluxian/Whatsie
<josepht> gustavopadre: there's a gulp plugin that would likely be helpful.  http://snapcraft.io/create/  We're happy to help
<gustavopadre> josepht, I don't know how to program at all, is there any snaps that emulates whatsapp web available already?
#snappy 2016-07-22
<wililupy> When I install a snap, is it possible to have the ubuntu-core snap install in devmode as well with the --devmode flag?
<wililupy> Or should I install the ubuntu-core snap first, then my snap?
<wililupy> I have an apparmor issue where it is denying /dev/ptmx from root. Anyone familiar with this?
<wililupy> http://pastebin.ubuntu.com/20391811/
<wililupy> I refreshed my ubuntu-core snap to edge, and I get this error even when I try to install snaps like webdm.
<qengho> wililupy: find dmesg. File a bug on snappy and tag it "snapd-interface".
<wililupy> qengho: ack. thanks.
<qengho> Append in comment results of   $ snap list
<mup> Bug #1605438 opened: Apparmor denies /dev/ptmx on all snaps <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1605438>
<mup> Bug #1605471 opened: Cannot refresh a devmode snap <Snappy:New> <https://launchpad.net/bugs/1605471>
<dholbach> hey hey
<zyga> o/
<slvn> hello! just let you know, I have published 10 SDL2 small game as snaps!
<slvn> snap find 1bsyl
<slvn> those are smartphone games, but they run also on desktop
<mup> PR snapcraft#680 opened: Rewrite shebangs generated by the python plugins <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/680>
<mup> PR snapcraft#621 closed: Correctly check !# for commands in PATH <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/621>
<kalikiana> Btw random finding that helped me a lot: "snappy-security-scanlog -r" hadn't known that switch before, it magically told me what plug I needed to add to fix the denials without devmode
<jibel> zyga, for gtk apps the testability lib is added at run time by appending it to GTK_MODULES
<mup> PR snapd#1577 opened: daemon, cmd/snap: refresh --devmode <Created by chipaca> <https://github.com/snapcore/snapd/pull/1577>
<sborovkov> Hello. How can I install 1.0.38? Zyga told me I need it for snap confine... trying to deal with getpwduid failing on classic
<Cavan> Hey, trying to snap Spark and cant find a wrapper, any ideas?
<Cavan> Any idead?
<Cavan> ideas*
<magicaltrout> whats a wrapper?
<Cavan> I'm not 100% sure, I think it directs the initial command to start a service? Every snap I've made so far the .yaml has used ' command: bin/wrapper' in the apps
<magicaltrout> thats just a script you write or reuse
<magicaltrout> to kickstart the app
<magicaltrout> so its whatever you need it to be
<magicaltrout> or nothing at all
<magicaltrout> depends what variables need setting
<magicaltrout> http://pastebin.com/7E2pQAEw
<magicaltrout> that one i borrowed and maniuplated
<Cavan> I'm trying to get Spark working through snapcraft, any idea's what it should be? I tried directing it to the shell but that didnt work
<Cavan> And thanks I'll give that a go
<magicaltrout> depends what you're trying to do Cavan
<magicaltrout> i'd probably try and get it to start the sparkshell
<Cavan> Trying to get it to use the spark shell or allow me to access the service through localhost, I'll have a play around
<mup> Bug #1605438 changed: Apparmor denies /dev/ptmx/ on all snaps <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1605438>
<mup> PR snapd#1578 opened: image: add meta/gadget.yaml infrastructure <Created by mvo5> <https://github.com/snapcore/snapd/pull/1578>
<Guest40840> Hi, I have a short question concerning stage-packages. I try to create a snap... I need to link my project to deb packages which are stored in a local directory. I don't find a correct way to achieve this task (stage-packages only get deb packages stored in the xenial repositories). Any idea ?
<kyrofa> Hey Guest40840
<kyrofa> Guest40840, you're right, stage-packages use the archives configured on your host machine. They aren't meant to pick up a collection of local debs
<kyrofa> Guest40840, the best way I can recommend to work with that is to write a local plugin for snapcraft that unpacks those debs
<kyrofa> Guest40840, e.g. a makefile might be even easier
<kyrofa> Guest40840, it can just run dpkg -x my.deb $DESTDIR
<mup> PR snapd#1579 opened: snapstate: add daemon-reload to fix autopkgtest on yakkety <Created by mvo5> <https://github.com/snapcore/snapd/pull/1579>
<Guest40840> ok thank you I will try this
<ibrahim> Hi ..
<ibrahim> is there any way to save the progress of downloading a snap package
<ibrahim> i mean both internet or electricity are not stable here , so can i resume a halted snap download ?
<Cavan> How would I go about running the Spark Shell through snapcraft? Anytime I type a command it gets 'command not found'
<mup> PR snapd#1580 opened: wrappers: set BAMF_DESKTOP_FILE_HINT for unity <Created by mvo5> <https://github.com/snapcore/snapd/pull/1580>
<ogra_> kyrofa, bug 1605622 updated
<mup> Bug #1605622: if something creates meta/snap.yaml during a snapcraft build, "type: os" is not carried over from snapcraft.yaml during prime step <Snapcraft:New> <https://launchpad.net/bugs/1605622>
<kyrofa> ogra_, ahh, verified then?
<kyrofa> Very interesting
<ogra_> yes,, "rm -rf meta/" before priming fixes it
<kyrofa> ogra_, so weird
<ogra_> yeah
<kyrofa> ogra_, probably an easy fix though, thanks for the bug :)
<ogra_> yeah
<sborovkov> zyga: ping
<Cavan> I'm getting this error, any ideas? 'Value out of rangee-karaf-4.0.5.tar.gz'[======================            ]  65%'
<kalikiana> hrm I wish I could read the descriptions of installed snaps
<mup> PR snapcraft#681 opened: parser - Add handling for carriage returns in wiki <Created by josepht> <https://github.com/snapcore/snapcraft/pull/681>
<Son_Goku> zyga: ping
<zyga> Son_Goku: hey
<Son_Goku> zyga, have you started pushing things for Fedora yet?
<zyga> Son_Goku: not much, I crashed after returning to my room;
<zyga> Son_Goku: did you check the news?
<Son_Goku> no, what am I supposed to see?
<Son_Goku> I fell asleep after getting back to my room as well
<zyga> Son_Goku: check out any european news :/
<Son_Goku> oh geez
<Son_Goku> not again
<Son_Goku> zyga: https://fedoraproject.org/wiki/Bodhi/BuildRootOverrides
#snappy 2016-07-23
<Son_Goku> zyga: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IMI5TP2K6A6R7PSIOUBLOE62ENIZDXOA/
<Son_Goku> zyga: ping
<mup> PR snapcraft#682 opened: Extending the created yaml from `snapcraft init` <Created by wandrewkeech> <https://github.com/snapcore/snapcraft/pull/682>
<mup> PR snapcraft#673 closed: Updating styling and examples for `snapcraft init` in lifecycle.py <Created by wandrewkeech> <Closed by wandrewkeech> <https://github.com/snapcore/snapcraft/pull/673>
<ali1234> oooookay, i have a PPA with Qt with EGLFS support: https://launchpad.net/~a-j-buxton/+archive/ubuntu/qt5-raspi-eglfs
<ali1234> now i just need a snapcraft to build my app and bundle everything from the three required PPAs
<Cavan> Strange question: Is the snap completed if I can run the application? For example if I want to start karaf I have to go through the 'prime' folder and command it from there after its snapped
<Cavan> Anyone?
<ali1234> okay snap install doesn't work
<ali1234> i didn't expect that installing a snap would be harder than making one
<ali1234> - Make snap "ubuntu-core" available to the system (can not set next boot: cannot determine bootloader)
<ali1234> i see it's bug 1580403
<mup> Bug #1580403: snap tries to manage bootloader in snappy-on-ubuntu-classic mode <Snappy:Fix Committed by zyga> <https://launchpad.net/bugs/1580403>
<ali1234> ah, my snapd is quite out of date...
<ali1234> hey why does qt5launch not work on arm?
<ali1234> okay i need to fork qt5conf then
<ali1234> so how do i tell the yaml to use my fork of qt5conf instead of the wikipart?
<ali1234> figured it out
<ali1234> this is pretty good, i'm impressed
<pcktsnscrtch> How close are we to a raspberry pi 3 release?
<ali1234> good question
<ali1234> /snap/infodump/x4/bin/qt5-launch: 76: exec: infodump: Permission denied
<ali1234> wut?
<ali1234> i'm sooooo close to getting this to work :/
<Cavan> How can I change the npcraft directory, my installed snaps are in my C drive and I cant access them without copying them into a different folder
<ali1234> hmm okay, apparmor denied my snap from using exec
<Cavan> Anyone know how I could install the Karaf logs when I snap, current issue is there not ebing made
<Cavan> once i finish my snap a instance file becomes read-only, anyway to change that?
<sergiusens> ali1234 try the new desktop parts for didrocks
<sergiusens> glad to know you found your way around.
<Cavan> When snapping karaf I'm running into a problem, the files when made are read only and they need to be edited to run
<Cavan> 'Unable to update instance pid: /snap/karaf/x3/instances/instance.properties (Read-only file system)' how can I fix this?
<k4fka> hello
 * mactrent waves
<Elleo> is there a ppa for more recent versions of snapcraft? I'm trying to use the new desktop-launch command, but the version in xenial just says it doesn't exist
<ali1234> sergiusens: i'm not sure what that means, sorry
<ali1234> you mean eg [desktop/qt5] ?
<ogra_>  i guess thats what he means :)
<ali1234> it installs a load of stuff that i don't need :/
<ali1234> like light-themes
<ogra_> ell, thats an argument i constantly have with didrocks :)
<zyga> hello
<ali1234> i don't even have a desktop
<ogra_> (who created the launcher parts)
<zyga> Cavan: hello
<ali1234> i am running Qt on eglfs
<ogra_> ali1234, then grab the part and re-implement your own bsed on it
<ali1234> i literally don't need any of the stage-packages
<zyga> Cavan: you need to make the program write user specific data to a file relative to to the SNAP_USER_DATA environment variable
<ogra_> ali1234, there are a bunch non desktop related stage-packages in the list i think
<ogra_> ... that are important for qt execution
<ali1234> no, there aren't
<ogra_> well ... shrug
<Cavan> zyga, thanks, how would I go about doing that, any handy links or advice?
<ali1234> it's building glib
<ali1234> and x11
<ali1234> okay this fails to even build a snap
<ogra_> kyrofa, sergiusens, hmm, shouldnt "type: os" disable --all-root in the mksquashfs options in snapcraft ? seems it doesnt for my os snap LP builds ( /home/ubuntu is root owned)
<ali1234> ogra_: i don't understand how to make my own version of the part
<ali1234> i can fork it on github and modify it
<ali1234> but then how do i include it in my project if i do that?
<ali1234> it can't put my modified version on the wiki
<ogra_> i would just copy/paste the part from the upstream snapcraft.yaml into mine and then modify it
<ali1234> that doesn't work
<ali1234> there are two upstream yaml files
<ogra_> are there ?
<ali1234> https://github.com/ali1234/snapcraft-desktop-helpers/blob/master/qt/snapcraft.yaml and https://github.com/ali1234/snapcraft-desktop-helpers/blob/master/snapcraft.yaml
 * ogra_ has never touched that ... i consume it in a few snaps
<ali1234> and they both use relative paths
<ali1234> so i don't understand how to copy and paste it in
<ali1234> i was able to do it with qt5conf part, because it is much simpler
<ogra_> i fear you have to wait for didrocks (who is only strictly 8h online during work hours usually)
<ali1234> it's okay i figured it out
<ogra_> sergiusens, kyrofa, filed bug 1605903 for you guys
<mup> Bug #1605903: type: os does not unset --all-root option for mksquashfs when coming fro snapcraft.yaml <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1605903>
<ali1234> okay well desktop-launch still says permission denied
<ali1234> it fails on exec "$@" exactly the sample place where qt5-launch failed
<ali1234> *same
<ali1234> Jul 23 17:45:12 ubuntu audit[5434]: AVC apparmor="DENIED" operation="exec" profile="snap.infodump.infodump" name="/snap/bin/infodump" pid=5434 comm="desktop-launch" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
<Cavan> how can I predefine user data so the error 'Unable to update instance pid: /snap/karaf/x3/instances/instance.properties (Read-only file system)' wil stop?
<Cavan> how do I set the SNAP_DATA? Do I use the yaml?
<Elleo> I'm trying to snap an ubuntu sdk app, but despite including all the normal dependencies and 'desktop/qt5' I get "qmlscene: could not find a Qt installation of ''" when attempting to run it, any pointers?
<Elleo> this is my attempt so far: http://pastebin.ubuntu.com/20639883/
<Cavan> still keep getting 'cannot create directory â/snap/karaf/x7/data/logâ: Read-only file system'
<Cavan> how do I change the read only or allow the snap to create the files
<Cavan> Anyone there to give me a hand?
<LBo> I've created a simple snap for xcape: https://github.com/LeonB/snappy-xcape/blob/master/snapcraft.yaml
<LBo> But I keep getting a permission denied error when running it
<LBo> geteuid()                               = 1000
<LBo> write(2, "need to run as root or suid", 27need to run as root or suid) = 27
<LBo> write(2, "\n", 1
<LBo> )                       = 1
<LBo> exit_group(1)
<LBo> What could be the problem?
<LBo> I've created another snap and I got this same behaviour
<LBo> Running something like htop, installed from the store, seems to run fine
<LBo> So maybe it has something to do with my snapcraft.yaml's
<LBo> $ /snap/bin/xcape --help
<LBo> execv failed: Permission denied
<ali1234> LBo: i am currently getting the same problem
<LBo> ali1234: great, I'm not the only one :)
<LBo> 16.04 also?
<ali1234> yes
#snappy 2016-07-24
<karlthane> Experimenting with snappy. I installed atom-cwayne but cannot find any way to launch it.
<qengho> karlthane: happy weekend! Does your environment add /snap/bin to your shell's PATH?
<Son_Goku> morning everyone :)
<Cavan> How can I make files not read only? I cant run my snap after install because it converts the files to read only
<qengho> Cavan: All snap files are immutable by design. By read-only, do you mean no executable bit?
<qengho> "Read only" usually means not writable. It says nothing about executability.
<Cavan> Yeah thats what I mean sorry, the snap cant write the files which need to be written, the error is 'mkdir: cannot create directory â/snap/karaf/x9/data/logâ: Read-only file system'
<Cavan> qengho
<qengho> Cavan: You're writing to the wrong place. Write beneath $SNAP_DATA, not $SNAP.
<Cavan> I put 'export SNAP_DATA="$SNAP/data/log/"' in a wrapper, is that incorrect?
<qengho> That is very much incorrect. You shouldn't assign anything starting with SNAP.
 * qengho Zzz.
<Cavan> qengho, I'm very new to this as you can probably tell, is something like this better 'export KARAF_DATA="$SNAP_DATA/data/log/"'?
<qengho> Cavan: You have a program. If it's expecting some environment variable, you should set it, and export it to subprocess's environments. If it's expecting some parameter, you should construct it. What you have there looks fine to me, but I don't know your program at all. You have to know why you're doing that, and then you might know what, better.
<ali1234> why is the qmake plugin staging my app binary at stage/home/ubuntu/snap/infodump/parts/infodump/build/build/infodump instead of something sensible like stage/bin/infodump?
<luqmaanki> Can anyone assist me with snapcraft and how it works and some basics about Ubuntu Snappy Core. I've been to all possible web pages, but it seems like I'm missing something. Thanks
<sergiusens> ogra_ thanks for the bug, I suspect it is related to the way we migrate files from parts/<part-name>/install to stage and prime
<ogra_> sergiusens, yeah, there are also a few ldd issues at the very end of the build https://launchpadlibrarian.net/274817065/buildlog_snap_ubuntu_xenial_amd64_os-snap-test_BUILDING.txt.gz
 * ogra_ spent the whole day uploading hacked snapcrafts to the image ppa :)
<sergiusens> ogra_ yeah, you probably want to not elf crawl for type OS
<ogra_> right, actually it should just blindly copy everything over and call mksquashfs
 * ogra_ learned a lot about snapcraft today (stage and prime are still a bit of a myth to me though)
<ogra_> the kernel snap build works fine btw https://code.launchpad.net/~ogra/+snap/kernel-test-snap :)
<ogra_> (i still need to set it up for other arches than amd64 though)
<sergiusens> ogra_ yeah for an os snap we do, but for others, special attribs are not a good idea as we won't be able to easily support clean delta updates
<ogra_> indeed
<sergiusens> ogra_ and now I understand where those PPA build failures come from too :-)
<ogra_> heh
<ogra_> sorry for spamming
<mup> PR snapcraft#681 closed: parser - Add handling for carriage returns in wiki <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/681>
<Cavan> 'Still getting /snap/karaf/x14/data/log/karaf.log (Read-only file system)' How can I configure it to write the files? I've tried so many things and nothing has worked so far
<mup> Bug #1606053 opened: 'snap find <foo>' output is a little agressive when '<foo>' results in no snaps <Snappy:New> <https://launchpad.net/bugs/1606053>
<magicaltrout> Cavan: don't you tell it to write to $SNAP_USER_DATA ?
<Cavan> magicaltrout, is it as simple as writing 'export KARAF_DATA="$SNAP_USER_DATA"'? It wont write the files it needs to from the karaf data
<magicaltrout> dunno how karaf is setup to write Cavan
<magicaltrout> but something like that
<magicaltrout> you need to write it somewhere
<magicaltrout> depends  what its set to
<magicaltrout> you could also try
<magicaltrout> -Duser.home=$SNAP_USER_DATA
<magicaltrout> and see if it rewrites everything
<magicaltrout> it  might
<Cavan> magicaltrout, where should I put that, in the wrapper I made with the other exports ect?
<magicaltrout> somewhere that takes java  opts
#snappy 2017-07-17
<Agafnd> so this is my first time using snap...
<Agafnd> trying to install huggle on debian9
<Agafnd> am getting message "Run configure hook of "core" snap if present"
<Agafnd> with a spinning baton. not sure if I'm supposed to do something?
<Son_Goku> Agafnd: that means it's broken :(
<Agafnd> :(
<Agafnd> how do i fix?
<Agafnd> can i fix?
<Agafnd> oh...I ^C'd it, tried again, and now it seems to be installing huggle?
 * Son_Goku shrugs
<Son_Goku> it happens occasionally with me in Fedora too
<Son_Goku> there's no obvious reason why it happens, either
<Agafnd> I wish everyone used AppImage as the distro-agnostic format
<mwhudson> hmm reminds me i should update snapd in debian now that stretch is out
<Agafnd> never had problems with those
<Son_Goku> mwhudson, what is debian on right now?
<Son_Goku> in Fedora, we're at 2.26.3
<Agafnd> looks like 2.24
<mwhudson> 2.21
<Son_Goku> oh dear
<Son_Goku> that's before a number of core transition handling things
<mwhudson> Agafnd: that's the version from the core snap, i presume
<Agafnd> it's from the output of snap --version
<Son_Goku> mwhudson, does snapd do re-exec even for "snap --version"?
<Agafnd> "snap    2.24" "snapd   2.24" "series  16"
<mwhudson> Son_Goku: i think so and what Agafnd is saying certainly suggests that
<Son_Goku> oh dear
<Son_Goku> that's annoying
<Agafnd> well anyway, looks like i got huggle running
<Agafnd> so problem solved for me :D
<mwhudson> hmm maybe i should make zyga do this
<zyga> good morning
 * zyga fetches some coffee
 * zyga breakfast
<mup> PR snapcraft#1412 opened: lxd: Snapcraft update in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412>
<zyga> pedronis: good morning
<zyga> pedronis: how were your holidays?
<Chipaca> zyga: pedronis is off until wednesday, says the calendar
<zyga> ah, I though he would be back already
<zyga> Chipaca: warsaw looks a lot like impressions of london today
<Chipaca> zyga: ââââââââââââââââ?
<mup> PR snapd#3595 opened: debian: update debian/tests/control to use isolation-machine <Created by mvo5> <https://github.com/snapcore/snapd/pull/3595>
<zyga> Chipaca: exactly
<zyga> mvo: approved
<mvo> thanks zyga
<mup> PR snapd#3596 opened: tests: disable snapd-notify for the external backend <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3596>
<zyga> mvo: travis seems still to be dead
<mvo> zyga: :(
<zyga> Son_Goku: o/
<mup> PR core#49 opened: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
<zyga> ogra_: btw, is travis working for you
<ogra_> zyga, "pending" ...
<ogra_> hmm ... i once switched this pi3 to the beta channel, then switched back to edge ... http://paste.ubuntu.com/25111305/
<ogra_> shouldnt the refresh to edge have me downgraded to revision 30 again ?
<zyga> ogra_: looking
<ogra_> (at least that would be my user expectation)
<zyga> ogra_: yes, I think so, Chipaca ^ ?
<Chipaca> ogra_: you say "switched", how did you switch?
<ogra_> Chipaca, snap refresh --channelname
<ogra_> though ... hmm
<Chipaca> ogra_: yes, that would have brought 30 in
<Chipaca> ogra_: revert wouldn't've
<ogra_> thei SD is very old, could be that i once manually tinkered with some bootloader var
<ogra_> s/thei/this/ ... tsk
 * Chipaca makes a note to always ask ogra if he tinkered with the bootloader before worrying about weird behaviour
<ogra_> heh
<ogra_> well, put it in an envelope and send it to me so i dont ask stupid questions :P
<zyga> fgimenez: searching test failed, is that interacting with the store? 2017-07-17 10:04:03 Error executing autopkgtest:ubuntu-16.04-i386:tests/main/searching :
<Chipaca> âsnap refresh --channelname snapnameâ should leave you with what âsnap infoâ says is current for that channel
<ogra_> Chipaca, though doesnt snapd just care for the state file ?
<ogra_> manual tinklering with the bootloader shouldnt chnage the metadata, shoould it ?
<Chipaca> ogra_: that might be true if your view is narrow enough, but it isn't true in general
<Chipaca> I mean, I don't know of a bootloader var that could influence this behaviour
<Chipaca> other than telling it "use this one"
<Chipaca> _however_
<Chipaca> you're assuming the refresh worked :-)
<Chipaca> that is
<ogra_> heh, indeed
<Chipaca> if you refresh core on a device, reboot, and the reboot fails, the core will be rolled back
<Chipaca> but I'm not 100% sure the "track this channel" change is rolled back; I'd have to look
<Chipaca> (i think it is, unless there's a use case for it being special and is thus special-cased)
<ogra_> ah, yeah, that install had inssues often enough (bacause of me breaking it) so there will have been plenty of rollbacks
<fgimenez> zyga: yes it interacts with the store, i just got an error for that test on i386 too while validating 2.27~rc3 http://paste.ubuntu.com/25111252/
<Chipaca> ogra_: aren't 30 and 34 both very very old?
<fgimenez> no featured snaps for that arch it seems
<ogra_> Chipaca, no, 34 is current
<Chipaca> ah this is pi2-kernel, not core
<ogra_> 30 is pretty behind ... i need to sync again
<Chipaca> not sure why i thought it was core
<Chipaca> changing subjects completely, everything is terrible
<Chipaca> :-)
<Chipaca> i'm going to go for a run and think about this stuff (what i'm working on, not ogra_'s thing :-) )
<zyga> Chipaca: enjoy!
<zyga> fgimenez: aha
<zyga> fgimenez: anyway, feels like a store-side issue
<Chipaca> trying to sort out the client/snap/systemd imports is soul-sucking
<zyga> Chipaca: hmm?
<zyga> Chipaca: would it help if I was the garden troll and you'd explain the problem to me?
<zyga> Chipaca: you can even record audio while running for extra panting drama
<Chipaca> zyga: maybe. When I get back :-)
<Chipaca> zyga: basically, I had client importing systemd, and need to change that around, but client imports snap and snap imports systemd
<Chipaca> zyga: cleaning that up leads to less code, less duplication, woo
<Chipaca> right?
<Chipaca> but then... all the little changes...
<zyga> aw
<Chipaca> nothing serious, just soul-sucking (and needing a firm hand to not do more while i'm in there, or to do more in self-contained reviewable chunks)
<zyga> would it help if snap imports were copied into client?
<Chipaca> no, that would actually make it worse :-)
<zyga> mhm
<Chipaca> we already have two json serialization structs for apps, for example
<Chipaca> and they're _different_
<zyga> I'll gladly review the patches
<zyga> enjoy your run
 * zyga looks outside at the rain
<Chipaca> there's client.AppInfo that expects name and daemon, and there's daemon's appJSON that gives you name, daemon, and desktop-file
<Chipaca> anyhow!
 * Chipaca afk
<Son_Goku> zyga: hey
<zyga> Son_Goku: hey, interesting thread about flatpak for graphical apps
<zyga> Son_Goku: I'm working on voicing my opinion
 * zyga needs a drink
 * ogra_ hands zyga some schnaps :P
<zyga> ogra_: nah, I'm just drinking water today
<ogra_> :)
<ogra_> zyga, btw, doesnt look like travis will ever pick up on my branch ... still in "Waiting to be queued" state
<zyga> ogra_: I think travis was massively down
<zyga> ogra_: and they are replaying the whole requests that happened since
<zyga> ogra_: so they have a huge backlog
<zyga> ogra_: and will eventually get to each test
<zyga> ogra_: but I don't know how soon or not soon that is
<ogra_> zyga, ah ...
<mup> PR snapd#3575 closed: overlord: populate interface label with summary <Created by robert-ancell> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3575>
<niemeyer> zyga: Are you working on #3399?
<mup> PR core#50 opened: fix snapd.core-fixup.service symlink on core devices <Created by mvo5> <https://github.com/snapcore/core/pull/50>
<Son_Goku> zyga, have you had a chance to look at the 32-bit failures?
<Son_Goku> for snapd 2.27 and fedora
<mup> PR snapd#3399 opened: many: add the interface command <Decaying> <Created by zyga> <https://github.com/snapcore/snapd/pull/3399>
<zyga> Son_Goku: no, not yet, but I already spoke with morphis about looking at them (today)
<zyga> Son_Goku: I'm wrapping up my last PR
<zyga> niemeyer: yes
<niemeyer> zyga: I just reopened it and merged it into the review sprint
<zyga> niemeyer: thank oyu
<zyga> niemeyer: I have a few things to tidy and re-check all the points
<zyga> niemeyer: but it is looking good
<niemeyer> zyga: Super, thanks!
<zyga> niemeyer: are we skipping standup today?
<cachio> niemeyer, linode machines not working today, https://travis-ci.org/snapcore/snapd/builds/253590022
<niemeyer> zyga: I'll be on a plenary with mvo, and pawel and pedronis are out, so we can probably skip it
<zyga> niemeyer: ack
<zyga> niemeyer: I'm going out with my family, I could drop by in 2-3 hours
<niemeyer> zyga: That looks like it's working, but too much concurrency maybe..
<niemeyer> Please don't cancel builds, folks!
<Chipaca> niemeyer: i thought spread dealt alright with canceling builds now? (to be clear, i haven't canceled builds)
<niemeyer> Chipaca: It usually does, and some cancels won't really do any harm.. I'm just reviewing the systems now and so far they are all clean
<niemeyer> Chipaca: This might become an issue if somebody starts cancelling jobs pathologically
<niemeyer> Chipaca: Because that removes the chance of spread itself even cleaning the system
<Chipaca> good ol' pathos
<niemeyer> !
<Chipaca> :-)
<niemeyer> I can tell for instance that 4 hours ago several builds were interrupted..
<fgimenez> hey cachio, what's the status of the package install centralization that niemeyer mentions here https://github.com/snapcore/snapd/pull/3484/files#diff-5cb500f3c949d5be548c6dc2556eb6c1R12 is it already merged?
<mup> PR snapd#3484: tests: add autopilot-introspection interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3484>
 * zyga_ codes from his car
<cachio> fgimenez, no yet
<fgimenez> cachio: ok thanks! ping me when ready
<cachio> fgimenez, it needs approvals :)
<niemeyer> zyga-ubuntu: I just went through and cleaned all systems.. also deallocated one of the systems which seemed to have potential hardware issues based on the logs, and reallocated it elsewhere
<niemeyer> Please let me know if you see any failures that feel like Linode problems
<niemeyer> fgimenez, cachio ^
<cachio> niemeyer, sure
<niemeyer> cachio: Is the PR that needs approval already in the review board?
<cachio> niemeyer, it is the dependencies one, it is under review
<cachio> niemeyer, https://github.com/snapcore/snapd/pull/3483
<mup> PR snapd#3483: tests: dependency packages installed during prepare-project <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3483>
<niemeyer> cachio: Thanks
<zyga-ubuntu> niemeyer: ack
<cachio> fgimenez, comment on review addressed, thanks for reviewing
<fgimenez> cachio: np thank you
<Vamsi> Is it necessary that snaps be installed on snappy core only via the Ubuntu snap store
<Vamsi> ?
<Vamsi> Is it not possible to have a snap store that has got nothing to do with Ubuntu or Canonical?
<zyga-ubuntu> Vamsi: hey, you can install snaps locally without using the snap store
<zyga-ubuntu> Vamsi: there's ongoing work to add support for stores other than the ubuntu one
<zyga-ubuntu> Vamsi: but that's aimed at enterprise stores that sit on LAN and serve local devices
<Vamsi> zyga-ubuntu: Thank you for the info. I was indeed looking at the perspective of an enterprise. We are looking seriously into Ubuntu core for our IoT usecases and wanted to know about this piece of information.
<Vamsi> zyga-ubuntu: Could you please direct me to any documentation about this ongoing work that you were talkking about?
<coreycb> niemeyer: hi, if you have a moment would you be able to review this? https://forum.snapcraft.io/t/track-request-for-openstack-core-snaps/1282
 * zyga-ubuntu lunches
<zyga-ubuntu> Vamsi: yep, please wait 15 min
<Vamsi> zyga-ubuntu: No problem. Thanks mate!
<niemeyer> coreycb: Sure, sent a question there
<niemeyer> mvo: We've got some space for hacking, right outside of room 9
<zyga-ubuntu> niemeyer: I could join you if you have any need of my hlep
 * zyga-ubuntu hacks on interface PR 
<zyga-ubuntu> Vamsi: ok, let me try to help you
<niemeyer> zyga-ubuntu: We can *always* use your help :P
<zyga-ubuntu> Vamsi: there are some PRs in flight https://github.com/snapcore/snapd/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aopen%20custom%20store%20 but I think for a business use-case you can already use an enterprise store today
<zyga-ubuntu> Vamsi: if you want I can get you in touch with some business people at Canonical
 * zyga-ubuntu hugs niemeyer :-)
<niemeyer> zyga-ubuntu: We'll have the snapd session tomorrow.. maybe plan to be here the whole day tomorrow?
<zyga-ubuntu> niemeyer: sure, sounds good
<zyga-ubuntu> niemeyer: 8:30?
<niemeyer> zyga-ubuntu: Yeah
<Vamsi> zyga-ubuntu: That would be awesome!
<zyga-ubuntu> niemeyer: perfect, I'll see you there
<coreycb> niemeyer: thanks, responded
<niemeyer> cachio: #3483 reviewed again
<niemeyer> snapd#3483
<mup> PR snapd#3483: tests: dependency packages installed during prepare-project <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3483>
<cachio> niemeyer, I'll take a look tx
<niemeyer> coreycb: Responded to the response response :)
<coreycb> niemeyer: thanks :)
<zyga-ubuntu> niemeyer: store doens't return featured snaps for i386 anymore
<zyga-ubuntu> niemeyer: any store people there you can poke?
<zyga-ubuntu> https://travis-ci.org/snapcore/snapd/builds/254377475?utm_source=github_status&utm_medium=notification
<niemeyer> Huh
<niemeyer> Yeah, let me find somebody
<fgimenez> zyga-ubuntu: niemeyer they are also missing for dragonboard http://paste.ubuntu.com/25111989/
<zyga-ubuntu> fgimenez: thank you!
<fgimenez> zyga-ubuntu: niemeyer according to wgrant it is expected, there are no featured snaps supporting i386
<zyga-ubuntu> fgimenez: has that changed?
<fgimenez> zyga-ubuntu: indeed, the test was passing on friday
<wgrant> AFAIK Evan's team manages that set, but I'm not 100% sure on that.
<zyga-ubuntu> ev is at the sprint so niemeyer should be able to reach him
<cachio> fgimenez, zyga-ubuntu  perhaps we should check in the test if there are featured apps first
<wgrant> But yes, given the current set of snaps in the featured section, those failures are expected. The store is operating correctly here; the curated data just has some unusual properties.
<cachio> fgimenez, zyga-ubuntu make a call to the api or something similat
<cachio> that could fail also for other distros
<fgimenez> cachio: iirc we considered that a while ago when we hit issues like this, but at the end we prefrerred to left the test as is, there should always be featured snaps for all the architectures, maybe we could rethink that approach now
<zyga-ubuntu> ogra_: https://github.com/snapcore/core/pull/50 can you look please?
<mup> PR core#50: fix snapd.core-fixup.service symlink on core devices <Created by mvo5> <https://github.com/snapcore/core/pull/50>
<cachio> fgimenez, agree, do you know if someone is going to add a featured app to fix it? or we should put it as manual
<zyga-ubuntu> I'd wait till we have a response from store people what changed since last week
<fgimenez> cachio: i think Michael is trying to ask Ecosystem people about this right now
<cachio> fgimenez, ok
<zyga-ubuntu> ogra_: ?
<ogra_> zyga-ubuntu, lool king
<ogra_> lol
<ogra_> looking
<ogra_> how did my finget hit the tab key there ?
<zyga-ubuntu> ogra_: just use your finger, not your finget :D
 * zyga-ubuntu hugs ogra_ 
<ogra_> lol
<ogra_> zyga-ubuntu, approved
<zyga-ubuntu> :-)
<mup> PR core#50 closed: fix snapd.core-fixup.service symlink on core devices <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/core/pull/50>
<om26er> Hi! I want my snap to only build on armhf, is there a config to force that.
<ogra_> architectures:
<om26er> right now all my uploads are built for amd64 and armhf, my app is only relevant to RaspberryPi so armhf is the only arch I am interested in.
<ogra_>   - armhf
<om26er> ah, that's simple.
<om26er> another: what's the recommended way to build armhf snaps on amd64 system ?
<ogra_> note though that there is a bug in build.snapcraft.io that will make it run the amd64 build regardless ...
<ogra_> just ignore that one
<om26er> hmm
<om26er> can I use lxd for that ?
<ogra_> (it will eventually respect the architectures filed in snapcraft.yaml)
<om26er> does build.snapcraft.io support delta uploads ?
<ppisati> ogra_: can i set a variable in the prepare scriptlet and use it later in snapcraft.yaml?
<ppisati> ogra_: something like - https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial/tree/snapcraft.yaml?h=pc-test
<ppisati> ogra_: look PKGNAME
<ogra_> ppisati, dunno, try it ... (i'd prefix it with "export" though ... to make sure )
<cjwatson> ogra_,om26er: architectures isn't correct for this case.  See https://github.com/canonical-websites/build.snapcraft.io/issues/556
<ppisati> ogra_: unfortunately it doesn't work as it is... :( /me does some more tests
<cjwatson> om26er: Why do you care whether there's an optimisation of the internal upload of snaps from BSI (actually Launchpad) to the store?
<om26er> cjwatson: I expect the download size of the update to be smaller as a result.
<cjwatson> om26er: That's delta downloads, not delta uploads
<cjwatson> om26er: Download deltas are automatically computed by the store as needed - BSI doesn't need to support them
<om26er> cjwatson: ok, so is that enabled today ? I have a snap on edge channel that I need to quickly test and in many cases its just a single line change so I would enjoy faster downloads.
<cjwatson> om26er: I haven't explicitly checked recently but I don't see why it wouldn't be; that work was done months ago
<mup> PR snapd#3597 opened: arch,release: map armv6 correctly <Created by morphis> <https://github.com/snapcore/snapd/pull/3597>
<om26er> obviously a saner thing to do would be to build the snap locally instead of waiting for buid.snapcraft
<cjwatson> om26er: (though it's also not something I've worked on myself)
<ogra_> ppisati, well, ask the snapcraft guys in rocketchat ...
<cjwatson> om26er: if it's not working then that would be something to bring up as a store issue I think
<ogra_> deltas are disabled on core
<ogra_> (downloads that is)
<ogra_> xdiff3 can add minutes to the install process when they are (depending on the hardware)
<ogra_> err
<ogra_> s/xdiff3/xdelta3/
<Chipaca> ogra_: isn't that just on pi?
<Chipaca> all of armhf maybe?
<Chipaca> or is it all of core?
<ogra_> all of core
<ogra_> well ... not sure about amd64 (i rarely use that)
 * Chipaca kicks off a spread run and starts to wonder about dinner
<om26er> ogra_: re your forum.snapcraft reply about RPi GPIO interface. I updated my RPi candidate channel but I still don't see the GPIO interface
 * zyga-ubuntu needs a coffee 
<om26er> did `snap refresh core --candidate`
<om26er> same for pi2 and pi2-kernel
<om26er> (and rebooted)
<ogra_> om26er, as i said, gadgets do nnot get updated
<ogra_> you need to build an image from one of the mentioned channels
<ogra_> (well, gadgts get technically updated ... but not their contents)
<om26er> ogra_: so once the candidate becomes stable it will get fixed then ?
<om26er> for now I'll export GPIO pins manually.
<om26er> `echo pin_number > /sys/class/gpio/export` to the rescue.
<ogra_> om26er, no
<ogra_> once gadget updating has been implemented in snapd it will work
<ogra_> only then
<om26er> hmm, building my own image might not be feasible because I have to distribute my app and I don't expect everyone to rebuild the image.
<ogra_> also ... you wont have access to /sys/class/gpio/export without a connected gpio interface (unless you use devmode)
<ogra_> well, they can use my daily edge images or one of the candidate builds that cdimage provides
 * ogra_ goes afk
<zyga-ubuntu> ogra_: doesn't the gpio interface get declared in the gadget snap.yaml which gets updated?
 * zyga-ubuntu is busy on interfaces and hungry/thirsty
<zyga-ubuntu> (and on his way home)
<ogra_> zyga-ubuntu, if the gadget gets updated, for safety reasons we didnt do that yet
<om26er> even if I may export pins on OS startup using a udev rule, the problem will still remain i.e. I won't be able to actually write to GPIO config unless in devmode.
 * ogra_ really needs to go now, i'm 330min late already 
<ogra_> *0
<ogra_> bah
<ogra_> 30
<ogra_> -> off
<om26er> ogra_: sure, will catch you later.
<om26er> Hi! Does the network-observe interface support signalling or is that only based on request-response based ?
<om26er> -based
<zyga-ubuntu> om26er: can you be more specific?
<zyga-ubuntu> what do you intend to do?
<om26er> I have a snap that runs as a daemon, I want that snap to keep waiting for internet before trying to connect
<om26er> also when internet is lost I don't want it to keep trying crazily, rather get "notified" that connection is back. I may then ping to check if internet is really working.
<om26er> zyga-ubuntu: ^
<zyga-ubuntu> re
<zyga-ubuntu> om26er: I see, let me check
<zyga-ubuntu> om26er: you want network-status interface
<zyga-ubuntu> om26er: not network-observe
<zyga-ubuntu> om26er: but I don't see any signals there
<om26er> zyga-ubuntu: is that an unreleased interface ? Its not mentioned here https://snapcraft.io/docs/reference/interfaces
<zyga-ubuntu> om26er: which is really unfortunate because it means people have to poll
<om26er> yeah
<zyga-ubuntu> I don't know what that list contains or who maintains it
<zyga-ubuntu> om26er: on the up side I'm working on a way to ask snapd (via snap) about known interface
<zyga-ubuntu> interfaces*
<zyga-ubuntu> and any documentation they contain
 * zyga-ubuntu supper
<Pharaoh_Atem> zyga-ubuntu: I'm surprised you haven't commented on the thread yet...
<zyga-ubuntu> Pharaoh_Atem: I wrote a few sentences but it's I'm not done yet
<zyga-ubuntu> Pharaoh_Atem: I still plan to but I want to write a good post, not something "yeah, mee too"
<stokachu> anyone around that can look at https://forum.snapcraft.io/t/snapd-2-26-9-and-conjure-up-no-longer-work/1348
 * zyga-ubuntu 
<zyga-ubuntu> stokachu: replied on the forum
<stokachu> zyga-ubuntu:thanks updated
<stokachu> who's calling me from spain
<stokachu> zyga-ubuntu:updated the forum post
<stokachu> Can not open /var/lib/snapd/seccomp/profiles//snap.conjure-up.lxd (No such file or directory) aborting: No such file or directory
<zyga-ubuntu> stokachu: aha
<zyga-ubuntu> stokachu: interesting, it should have used the new seccomp binary profiles?
<stokachu> zyga-ubuntu:thanks for the quick reply!
<zyga-ubu1tu> stokachu: I'm investigating
<stokachu> zyga-ubu1tu: thanks, just lemme know if you need me to do anything
<zyga-ubu1tu> stokachu: I updated my analysis, this is a (new) bug
<zyga-ubu1tu> stokachu: and a pretty obscure one at that
<stokachu> Ok
<zyga-ubu1tu> stokachu: I'm looking at fixing it ASAP
<stokachu> zyga-ubu1tu: ok thank you! I sent out a heads up email to juju lists so people are aware we're working on it
<zyga-ubu1tu> stokachu: thank you
<zyga-ubu1tu> stokachu: can you please report it and give me the launchpad bug number
<stokachu> zyga-ubu1tu:to the snappy project>
<zyga-ubu1tu> stokachu: on snapd please
<zyga-ubu1tu> I wrote a test case, trying it now
<stokachu> Ok
<mup> PR snapd#3598 opened: tests: add test case for classic-schizofrenia-bug <Created by zyga> <https://github.com/snapcore/snapd/pull/3598>
<stokachu> zyga-ubu1tu:https://bugs.launchpad.net/snapd/+bug/1704860
<mup> Bug #1704860: classic confinement reexec <conjure> <snapd:New> <https://launchpad.net/bugs/1704860>
<zyga-ubu1tu> stokachu: thank you
<stokachu> zyga-ubu1tu:im at the sprint if you want to sync tom
<stokachu> i thought i saw you earlier
<zyga-ubu1tu> stokachu: I'm not at the sprint, I'll be there tomorrow though (all day)
<stokachu> zyga-ubu1tu:ok cool
 * zyga-ubu1tu EODs
<mup> Bug #1555569 changed: [snaps] Show human-readable names for store apps <gnome-software> <sdoc> <Snapcraft:New> <Software Center Agent:Fix Released> <gnome-software (Ubuntu):Fix Committed by robert-ancell> <gnome-software (Ubuntu Xenial):Triaged> <gnome-software (Ubuntu Yakkety):Won't Fix>
<mup> <gnome-software (Ubuntu Zesty):Triaged> <https://launchpad.net/bugs/1555569>
#snappy 2017-07-18
<mup> PR snapcraft#1413 opened: core: minimal windows support <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1413>
<mup> PR snapcraft#1414 opened: cmake plugin: call the cmake using build dir as source <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1414>
<zyga-ubuntu> jjohansen: hey
<zyga-ubuntu> jjohansen: I'm working on a larger tool patch for for aa-binary-policy-inspector
<zyga-ubuntu> jjohansen: should be out by the end of the week
<zyga-ubuntu> jjohansen: I sent some smallish patches to the ML and you acked one (thank you!)
<zyga-ubuntu> jjohansen: if you have a moment could you look at the remaining two please?
 * zyga-ubuntu wonders where Chipaca might be
<zyga-ubuntu> fgimenez: hey
<zyga-ubuntu> I have a thing I'd like to discuss with you
<fgimenez> hi zyga-ubuntu
<zyga-ubuntu> fgimenez: last night we had a PR that was fixing a bug in nested re-exec
<zyga-ubuntu> fgimenez: and I saw the upgrade/basic test fail on debian
<zyga-ubuntu> fgimenez: it failed a few times in a row
<zyga-ubuntu> fgimenez: the error was about /usr/lib/snapd/snap-update-ns not being there (it's not a part of the stable package in debian)
<zyga-ubuntu> fgimenez: the test just passed on both qemu and linode today
<zyga-ubuntu> fgimenez: without any changes in the PR
<fgimenez> zyga-ubuntu: sounds bad
<zyga-ubuntu> fgimenez: and here's the question, do you know of any store quirks that could explain this?
<zyga-ubuntu> fgimenez: (normally we should execute snap-update-ns from the core snap)
<fgimenez> zyga-ubuntu: nope afaik, do we have a log of the failed builds?
<zyga-ubuntu> fgimenez: I'm running it again a few more times just to be sure it's not a race
<zyga-ubuntu> fgimenez: (well, to be more convinced, not sure)
<zyga-ubuntu> fgimenez: let me check, but I think I killed it :/
<zyga-ubuntu> yeah, I killed it
<fgimenez> zyga-ubuntu: i'll try to reproduce too, not sure if upgrade/basic has been always enabled for debian
<zyga-ubuntu> let's see if it passes now
<zyga-ubuntu> it has
<zyga-ubuntu> remember that refresh --beta core thing we did just for debian?
<fgimenez> zyga-ubuntu: np, let's see if we can get it to fail again
<zyga-ubuntu> when the stable channel was somewhat broken there?
<fgimenez> zyga-ubuntu: ah yep
<zyga-ubuntu> I'm trying to understand what changed since last evening
<zyga-ubuntu> and since the branch did not, it could point towards the store
<fgimenez> zyga-ubuntu: makes sense, is there an apt upgrade in the upgrade/basic test? maybe the debian unstable repo could have changed too
<zyga-ubuntu> fgimenez: ah, interesting question, let me check
<zyga-ubuntu> fgimenez: according to https://packages.debian.org/sid/snapd it seems to be the exact same version we have uploaded ages ago
<zyga-ubuntu> fgimenez: 2.21-2+b1
<zyga-ubuntu> fgimenez: (which is also surprising because I would have assumed we'd keep sid updated frequently)
<zyga-ubuntu> mwhudson: hey ^ is debian snapd updated for each release? are you still the one doing those updates?
<fgimenez> zyga-ubuntu: i've just reproduced the upgrade/basic issue on debian http://paste.ubuntu.com/25117441/
<fgimenez> zyga-ubuntu: the session is open in case you want to have a look
<fgimenez> there's a /usr/lib/snapd/snap-discard-ns but not /usr/lib/snapd/snap-update-ns...
<zyga-ubuntu> fgimenez: excellent, please keep it
<zyga-ubuntu> fgimenez: thank you, please keep the session
<zyga-ubuntu> fgimenez: can you share credentials to mvo
<zyga-ubuntu> fgimenez: so that we can ssh and explore
<fgimenez> zyga-ubuntu: sure, 1sec
<zyga-ubuntu> fgimenez: how many times did you run it?
<zyga-ubuntu> fgimenez: I'm at my ~6th iteration locally and on linode
<zyga-ubuntu> it's clearly a race somewhere
<fgimenez> zyga-ubuntu: it failed on the 2nd execution, running on linode
<zyga-ubuntu> fgimenez: interesting, thank you!
<zyga-ubuntu> fgimenez: we're with mvo looking at the code there onw
<zyga-ubuntu> now*
<zyga-ubuntu> fgimenez: thanks for the credentials
<fgimenez> zyga-ubuntu: np :)
<magicaltrout> hi folks newb when i run a script inside a snap installed in devmode and reference /etc is that /etc on the host or the snap?
<magicaltrout> it seems to be the host
<magicaltrout> okay crickets on that one lets try this question instead
<magicaltrout> I have a config that includes a sub config file: include: file:///etc/openldap/schema/core.ldif
<magicaltrout> but I can't put env vars in there, is there anything in snappy that lets me define a concrete path?
<magicaltrout> or something relative
<magicaltrout> i don't care partiulcarly it just needs to be able to find the file
<mup> PR snapd#3599 opened: Fix/clasic schizofrenia bug <Created by mvo5> <https://github.com/snapcore/snapd/pull/3599>
<mup> PR snapd#3600 opened: many: expose service status in 'snap info' <Created by chipaca> <https://github.com/snapcore/snapd/pull/3600>
<Chipaca> wooo PR #3600
<Chipaca> where is my cake
<Chipaca> zyga-ubuntu: ^ you were making noises about reviewing the services thing, here's your chance :-D
<Chipaca> magicaltrout: I think you'll be luckier on the forum
<Chipaca> magicaltrout: IRC is too synchronous
<Chipaca> magicaltrout: the people that could properly answer your questions are sprinting and won't be listening on here for much of this week
<magicaltrout> no probs Chipaca i cross posted anyway thanks
<zyga-ubuntu> Chipaca: hey
<zyga-ubuntu> Chipaca: haha, good one :)
<zyga-ubuntu> Chipaca: I'lll do my best
<zyga-ubuntu> fgimenez: did you run the whole suite or just that specific test?
<fgimenez> zyga-ubuntu: just that test
<zyga-ubuntu> fgimenez: thank you!
 * zyga-ubuntu scratches head :)
<zyga-ubuntu> we've been running that test all day without failure (locally and in linode)
<zyga-ubuntu> we'd like to test a theory but for whatever reason it won't break now
 * Chipaca shakes his fist at interfaces-avahi-observe
<Chipaca> is spread being funny, or am I being unlucky?
 * Chipaca restarts the run 
<zyga-ubuntu> Chipaca: what are you seeing?
<zyga-ubuntu> Chipaca: we're chasing a heisenbug all morning
<Chipaca> zyga-ubuntu: failed prepares
<zyga-ubuntu> Chipaca: I saw that once
<zyga-ubuntu> Chipaca: we're really chasing tests/upgrade/basic on debian
<Chipaca> nice
<Chipaca> third's the charm, or something
<zyga-ubuntu> Chipaca: hey
<zyga-ubuntu> Chipaca: how do you feel like looking at release-critical https://github.com/snapcore/snapd/pull/3598
<mup> PR snapd#3598:  cmd,tests: fix classic confinement confusing re-execution code <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/3598>
<zyga-ubuntu> Chipaca: it's green now and we'd like to land it and release it
<zyga-ubuntu> and please hold for merging as we want to squash merge
 * Chipaca on it
<zyga-ubuntu> fgimenez: I logged out of the linode machine, I think we can recycle it now
<zyga-ubuntu> Chipaca: thanks
<fgimenez> zyga-ubuntu: great thanks!
<zyga-ubuntu> Chipaca: I'll get to your branches ASAP but not sure if I can sneak out of kubernetes talk ;)
<zyga-ubuntu> the snap info services
<Chipaca> zyga-ubuntu: +1
<Son_Goku> zyga-ubuntu: https://copr-be.cloud.fedoraproject.org/results/ngompa/snapd-prerel-fedora/fedora-rawhide-i386/00579417-snapd/build.log.gz ?
<Chipaca> zyga-ubu1tu: you also get a +1
<zyga-ubu1tu> thank you
<zyga-ubu1tu> Chipaca: I learned a new thing just now
<Chipaca> zyga-ubu1tu: go on
<zyga-ubu1tu> Chipaca: var *stuff; stuff.CalledOnNil()
<Chipaca> mhmm
<zyga-ubu1tu> queer :)
<Chipaca> zyga-ubu1tu: we've corrected some of those in review of your code, fwiw :-)
<Chipaca> where something could be nil and you weren't checking it
<zyga-ubu1tu> Chipaca: I was expecting the compiler to complain
<zyga-ubu1tu> Chipaca: I did some python lately and I just fell in love with mypy's static type checks and also, more importantly, None checks, so Optional[T]
<Chipaca> zyga-ubu1tu: that's probably the work of a friend of mine :-)
<zyga-ubu1tu> Chipaca: jukka?
 * zyga-ubu1tu might be doing a disservice to the mypy developer
<zyga-ubu1tu> (I know mypy is improved by lots of people now)
<Chipaca> ah, no, my friend is into bringing mypy to django
<Chipaca> https://2017.djangocon.eu/schedule/using-type-checking-in-django-projects-with-mypy/
<zyga-ubu1tu> ah
<zyga-ubu1tu> I was doing just plain CLI stuff
<zyga-ubu1tu> Chipaca: I found it hard to publish a pypi package with type introspection data though
<mup> PR snapd#3598 closed:  cmd,tests: fix classic confinement confusing re-execution code <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3598>
<mup> PR snapd#3601 opened: cmd,tests: fix classic confinement confusing re-execution code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3601>
<zyga-ubu1tu> Chipaca: half review up
<niemeyer> cachio: Heya
<niemeyer> cachio: Thanks for the changes in snadp#3483..
<niemeyer> cachio: Not sure if we talked about this before: we try hard not to rebase after a pull request is up
<niemeyer> cachio: It removes the ability to follow through changes during the review process
<niemeyer> cachio: "We went looking everywhere, but couldnât find those commits."
<niemeyer> Changing history is fine before the PR is pushed up, though
<cachio> niemeyer, ok
<cachio> niemeyer, first time you mention that
<niemeyer> cachio: Cool, np
<niemeyer> cachio: The PR looks good, thanks again for the changes
<niemeyer> cachio: We just a second review on it..
<niemeyer> Any takers?
<cachio> niemeyer, great, thanks
<Chipaca> niemeyer: I recently explicitly asked for a rebase on a PR
<Chipaca> niemeyer: it hadn't had any reviews and was a mess, very very hard to follow as it stood
<Chipaca> (talking something like 50 commits in there)
<niemeyer> Chipaca: That's the exception that validates the rule :)
<Chipaca> :-)
<Chipaca> cachio: +1'ed
<Chipaca> cachio: niemeyer: is that one to be squashed as well?
<niemeyer> Chipaca: Yeah, definitely
<niemeyer> We've been squashing pretty much every merge
<cachio> Chipaca, tx
<mup> PR snapd#3601 closed: cmd,tests: fix classic confinement confusing re-execution code <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3601>
<mup> PR snapd#3589 closed: tests: remove unneeded check for re-exec in InternalToolPath() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3589>
<cachio> Chipaca, ahey, any idea about why gpg 2 in opensuse is not getting the passphrase from the fake pinentry to export a key?
<Chipaca> cachio: no
<cachio> Chipaca, do you knowin which other systems are we using gpg 2?
<ogra_> zyga-ubuntu, https://forum.snapcraft.io/t/core-2381-breaks-ld-linux-so-2/1362 smells like some snap-confine/seccomp/namespaces issue (i dont think the linker or either of the two libc's we ship in core has changed recently)
<Chipaca> cachio: does it look for the pinentry in the same place?
<Chipaca> cachio: that is, the first thing I'd suspect is that for whatever reason it isn't even looking at ~/.snap/gnupg/gpg-agent.conf
<zyga-ubuntu> ogra_: looking
<Chipaca> cachio: second thing I'd suspect is that they don't have the pinentry-program option in their gpg2
<cachio> Chipaca, I'll check that
<ogra_> zyga-ubuntu, i actually wonder if we have any testing for the i386 libc we ship in the amd64 core for multiarch support
 * ogra_ bets we dont
<zyga-ubuntu> ogra_: replied on the forum, thank you
<ogra_> thanks !
<cachio> Chipaca, I think pinentry is used starting on gpg 2.1
<cachio> and in opensuse we have 2.0.8
<Chipaca> cachio: you think, or you know? :-)
<cachio> Chipaca, based on the doc
<cachio> Unattended passphrase
<cachio> Starting with GnuPG 2.1.0 the use of gpg-agent and pinentry is required, which may break backwards compatibility for passphrases piped in from STDIN using the --passphrase-fd 0 commandline option. In order to have the same type of functionality as the older releases two things must be done:
<zyga-ubuntu> cachio: something broke with gpg upgrade?
<zyga-ubuntu> do we actually talk to running instance of gpg or do we just link to some libraries?
<cachio> zyga-ubuntu, I understand we actually talk to running instance, but not totally sure
<zyga-ubuntu> ouch, that would be unnice
<zyga-ubuntu> cachio: are you trunning tumbleweed or leap?
<cachio> zyga-ubuntu, in leap
<zyga-ubuntu> cachio: thanks, interesting
<cachio> zyga-ubuntu, I'll research a bit more
<cachio> after lunch
<Chipaca> zyga-ubuntu: we run gpg
<Chipaca> it's in asserts/gpgkeypairmgr.go
<Chipaca> somewhat convoluted because gpg1 vs gpg2
<zyga-ubuntu> yes
<Chipaca> zyga-ubuntu: we "talk to running instance" in the sense that we exec it and read its output :-)
<Chipaca> this isn't bidirectional communication :-)
 * ogra_ sees the linker issue in the forum is actually around a 64bit classic snap executing 32bit binaries and runs away screaming :P
<ogra_> classic snaps should die !
 * ogra_ will show up with a sign on a stick saying that at the next sprint :P
<Pharaoh_Atem> Chipaca: I'm surprised you're not using gpgme
<Pharaoh_Atem> there's a go binding for it: https://github.com/proglottis/gpgme
<Chipaca> Pharaoh_Atem: is it pure go?
<Chipaca> answer: nope
<Chipaca> Pharaoh_Atem: so that's probably a chunk of why not
<Chipaca> of course, we could still use it as a helper, but it's not like we don't have other things to do :-)
<zyga-ubuntu> ogra_: hello
<ogra_> zyga-ubuntu, yo
<zyga-ubuntu> ogra_: do oyu have a armv7 device around?
<zyga-ubuntu> ogra_: one that rhymes with erry
<zyga-ubuntu> ogra_: we need a hand
<ogra_> well, remote
<zyga-ubuntu> ogra_: put rasbian on one
<zyga-ubuntu> ogra_: and install snapd
<ogra_> oh
<zyga-ubuntu> ogra_: and tell us what breaks when you install core
<zyga-ubuntu> ogra_: I think there's a syscall missing
<ogra_> can that wait til tomorrow morning ?
<zyga-ubuntu> ogra_: but my hardware is at home and I cannot check
<ogra_> (i'mm also not near the HW ... testing stuff remotely isnt a prob but physical access is a bit bad tonight)
<zyga-ubuntu> ogra_: ok, I think we can do that tomorrow
<ogra_> ok
<zyga-ubuntu> ogra_: I have a pi at home I can test but I'm at the sprint hotel
<ogra_> yeah, i grokked that
<kyleN> hey zyga-ubuntu. I'm doing an interface for a customer and using refresh-bits.sh. the interface appears but I get these seccomp profile errors: https://pastebin.canonical.com/193757/
<kyleN> zyga-ubuntu, notably: "fork/exec /usr/lib/snapd/snap-seccomp: no such file or directory"
<kyleN> zyga-ubuntu, which is correct, that snap-seccomp file does not exist. any tips to get passed this?
<zyga-ubuntu> interesting
<zyga-ubuntu> kyleN: so is this on raspbian?
<zyga-ubuntu> kyleN: on armv7?
<kyleN> zyga-ubuntu, no: amd64 ubuntu server 16.04
<zyga-ubuntu> o!?
<kyleN> what
<zyga-ubuntu> kyleN: can you do snap version
<kyleN> https://pastebin.canonical.com/193758/
<kyleN> i guess snapd is UNKNOWN because I am currently running the script to use the locally built snapd....
<zyga-ubuntu> kyleN: apt-cache policy snapd
<ogra_> 4.4.0-59-generic !!!
<kyleN> when I stop the script I get: snapd   2.26.9
<kyleN> all of these exclamation points!! l)
<ogra_> :)
<ogra_> well,that kernel is *pretty* old ...
<mvo> kyleN: or apt list snapd
<kyleN> yes hang on
<kyleN> Installed: 2.22.3
<kyleN> snapd/xenial-updates 2.25 amd64 [upgradable from: 2.22.3]
 * zyga-ubuntu brb
<mvo> kyleN: please keep it as it is for now (this version)
<mvo> kyleN: I suspect we know what is going on
<kyleN> darn, mvo I just upgrade snapd
<mvo> kyleN: no worries
<kyleN> upgradeD
<mvo> kyleN: if you just upgraded it, did the problem go away?
<mvo> kyleN: or stil lthe same error?
<kyleN> checking
<ogra_> you surely also want a new kernel ... one that has less open security holes :)
<kyleN> no, problem still exists.
<ogra_> (and also apparmor fixes that landed since -59-generic)
<ogra_> (we're at -83- currently)
<kyleN> ogra this is a hand crafted system (not by me) with hand installed kernel modules to support broadcom asic
<kyleN> so I don't want to muck with the kernel (but I can get Luke to if needed)
<ogra_> kyleN, well, i dont know wher, but there were seccomp and apparmor fixes since ...
<ogra_> s/wher/when/
<zyga-ubuntu> kyleN: can you pastebin the journal/syslog
<kyleN> ogra: ok, so you think this might be due to an old kernel?
<ogra_> i think it is likely they happened after the 53 revision
<ogra_> err
<ogra_> 59
<ogra_> if they use a server install with extra modules, someone should help them to make them dkms modules so you dont get stuck on the kernel version
<ogra_> else the system is vulnerable ...
<kyleN> zyga-ubuntu, here's the last part of the journal, its long: https://pastebin.canonical.com/193763/
<zyga-ubuntu> looking
<zyga-ubuntu> kyleN: can you please restart snapd (systemc restart snapd.service)
<zyga-ubuntu> kyleN: while having look at the logs
<zyga-ubuntu> kyleN: (journalctl -f)
<zyga-ubuntu> kyleN: and then pastebin the new parts that show up after the restart
<kyleN> ok
<kyleN> sorry for the delay
<mvo> kyleN: could you please snap refresh --edge core and see if that fixes the problem? we fixed a releated bug vsome minutes ago
<kyleN> zyga-ubuntu, https://pastebin.canonical.com/193766/
<kyleN> mvo, ok
<zyga-ubuntu> thank you, looking
<kyleN> mvo, after refreshing core from edge, I get the same error. of course the error occurs when using the locally built snapd with my dev interface. I am not clear whether it should be trying to find /usr/lib/snapd/snap-seccomp on that path or on the path of the temporary snapd...
<zyga-ubuntu> kyleN: ok, very interesting
<zyga-ubuntu> kyleN: did you change anything in /etc/ related to snapd reexec?
<kyleN> no
<kyleN> kust run: ubuntu@wedge100:~/go/src/github.com/devtools$ ./refresh-bits snapd setup run-snapd restore
<kyleN> Just run
<kyleN> then the error occurs when I do somethign with snap, like sudo snap interaces, or snap try...
<zyga-ubuntu> kyleN: OMG
<kyleN> not sure if that is good OMG or bad OMG ;)
<kyleN> I'll go with bad OMG as a starting position ;)
<mup> PR snapd#3602 opened: snap-seccomp: add secondary arch for unrestricted snaps as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/3602>
<zyga-ubuntu> kyleN: sorry
<kyleN> quite alright, this is fun
<zyga-ubuntu> kyleN: so, I think devtools is somewhat unmaintained
<kyleN> ah
<zyga-ubuntu> kyleN: and some things are missing
<mup> PR snapd#3603 opened: snap-seccomp: add secondary arch for unrestricted snaps as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/3603>
<kyleN> zyga-ubuntu, so I need to test my local snapd with my dev interface to prove it works before making  PR. what do you recommend
<zyga-ubuntu> kyleN: if you are hacking on a core device you may need to update devtools to copy new things over
<kyleN> is not a core device. is server
<zyga-ubuntu> kyleN: if you are hacking on a classic device it may be easier to just hack on it directly/build package/run commands from core/etc
<zyga-ubuntu> kyleN: if you need a hand I can elp
<zyga-ubuntu> kyleN: including in updating devtools to the point where it works again
<zyga-ubuntu> kyleN: but it's totally my fault that it's an unmaintained thing that poses as somethin that still works
<kyleN> zyga-ubuntu, I very much want to get this PR to snapd this week. can you perhaps fix up devtools so I can try again tomorrow?
<kyleN> I am totally open to whatever appraoch works for you zyga
<kyleN> zyga-ubuntu, ^
<zyga-ubuntu> kyleN: what's the PR?
<kyleN> broadcom-asic-control intefaces for customer
<kyleN> interface (not plural)
<zyga-ubuntu> kyleN: aha
<zyga-ubuntu> kyleN: well, can you please push the PR up (not sure if you already did, sorry about that) and we review it
<zyga-ubuntu> kyleN: for hacking locally just build the package (dpkg-buildpackage)
<zyga-ubuntu> kyleN: install it
<zyga-ubuntu> kyleN: and then you can just hack on interfaces
<kyleN> zyga-ubuntu, well, I wanted to prove to myself that it works before making the PR
<zyga-ubuntu> kyleN: and run sudo ./snapd from the tree
<zyga-ubuntu> kyleN: you may need to sudo systemctl stop snapd.{socket,service}
<zyga-ubuntu> kyleN: you can propose it even before it's finished
<zyga-ubuntu> kyleN: and update it mid way
<zyga-ubuntu> kyleN: as I suspect there may be more things than just the security bits
<kyleN> ok. it's pretty simple. just apparmor snippet
<zyga-ubuntu> kyleN: but the dpkg-buildpackage + install freshly built snapd.deb + stop / disable snapd.{socket,service} + sudo ./snapd approach will get you going
<kyleN> I find taht with my hand overriden snap command appA profile, I get no DENIED when the kernel module is used by the snap
<zyga-ubuntu> tyhicks, jdstrand could you please look at trivial/emergency PR: https://github.com/snapcore/snapd/pull/3603
<mup> PR snapd#3603: snap-seccomp: add secondary arch for unrestricted snaps as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/3603>
<zyga-ubuntu> kyleN: can you push your branch anywhere? I'd like to see the apparmor snippet
<kyleN> ok hang on
<mup> PR snapd#3599 closed: Fix/clasic schizofrenia bug <Created by mvo5> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3599>
<kyleN> zyga-ubuntu, https://github.com/knitzsche/snapd/tree/broadcom-asic-interface
<mup> PR snapd#3595 closed: debian: update debian/tests/control to use isolation-machine <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3595>
<mup> Bug #1705091 opened: unable to use snap after install <Snappy:New> <https://launchpad.net/bugs/1705091>
<mup> PR snapd#3603 closed: snap-seccomp: add secondary arch for unrestricted snaps as well <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3603>
<zyga-ubuntu> kyleN: thank you
<zyga-ubuntu> kyleN: if you don't need udev tagging you can just use commonInterface
<zyga-ubuntu> kyleN: less code to write
<zyga-ubuntu> kyleN: not sure if this interface should be implicit
<zyga-ubuntu> kyleN: that needs some more discussion
<niemeyer> Anyone around to handle a snap in the review queue?
<mwhudson> enozyga
<tyhicks> zyga-ubuntu: done! (I see that it was already merged and that's fine since it was a urgent issue that was trivial)
<mup> PR snapd#3604 opened: tests:  enable main suite for opensuse <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3604>
<invapid> anyone know if there is an easy way to get snappy to pull from ubuntu src?
<invapid> most packages' source can be downloaded with "apt source packagename"
<invapid> so wondering if snappy can pull src similarly
<kyrofa> invapid, I'm afraid not
<magicaltrout> hooks........
<magicaltrout> docs say i just need a hooks/configure file
<magicaltrout> if i copy this one https://github.com/snapcore/snapcraft/tree/master/demos/hooks/snap/hooks
<magicaltrout> and deploy my snap
<magicaltrout>  Run configure hook of "openldap" snap (snap "openldap" has no "configure" hook)
<magicaltrout> what moronic thing have i got wrong/
<magicaltrout> ?
<magicaltrout> bugg@tom-laptop2:~/Projects/openldap-snap$ ll /snap/openldap/current/hooks/configure
<magicaltrout> seems legit
<magicaltrout> hmm the demos dont work either
<magicaltrout> https://forum.snapcraft.io/t/configure-hook-doesnt-run/1365 if anyone gets bored
#snappy 2017-07-19
<zyga-ubuntu> good morning
 * zyga-ubuntu packs and goes to the sprint
<mup> PR snapcraft#1415 opened: tests: run the tests in travis using LXC containers <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1415>
<Chipaca> zyga-ubuntu: good morning!
<mup> Bug #1653286 changed: When connecting App to platform, needs a reboot to use <Snappy:New> <https://launchpad.net/bugs/1653286>
<pedronis> Chipaca: hi
<Chipaca> pedronis: greetings, stranger!
<Chipaca> pedronis: I'm assuming you're so suntanned I wouldn't recognise you
<pedronis> actually, no, just a little bit
<Chipaca> aw :-)
 * pedronis isn't into suntanning, though he went to a place that would have allowed that
<Chipaca> pedronis: at this point I'm so pale I'd get a comparatively decent suntan from just _being_ in places that allowed for it
<Chipaca> mmm... a week in brasil does not sound like a terrible idea
 * Chipaca should expand his list of places to catch the sun in
<Chipaca> jdstrand: o/! hope you're enjoying the weather in warsaw (?)
<Chipaca> jdstrand: WRT snapd#3548, was it being on openvswitch instead of openvswitch-support your only objection? if so i'll merge it :-)
<mup> PR snapd#3548: interfaces: Add /run/uuid/request to openvswitch <Created by coreycb> <https://github.com/snapcore/snapd/pull/3548>
<zyga-ubuntu> o/
<Chipaca> zyga-ubuntu: \o
<Chipaca> zyga-ubuntu: are you here to continue a certain review? :-)
<zyga-ubuntu> Chipaca: yep, I've started reviewing branches just now
<zyga-ubuntu> Chipaca: I'll do top-to-bottom unless you want me to jump to your PR quickly
<zyga-ubuntu> actually
<zyga-ubuntu> it's third on the list
<zyga-ubuntu> so in 2 minutes
<Chipaca> seems fine to me, it'll take me longer than that to check some things in the polkit branch
<mup> PR snapd#3602 closed: snap-seccomp: add secondary arch for unrestricted snaps as well (2.26) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3602>
<mup> Bug #1705220 opened: Removing desktop-ubuntu-app-platform broke any app relying on the webapp-helper <amd64> <apport-bug> <artful> <julyshakedown> <third-party-packages> <Snappy:New> <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1705220>
<stokachu> zyga-ubuntu:fyi https://github.com/conjure-up/conjure-up/issues/683#issuecomment-316321509 3 more confirmations the snap rexec bug is fixed
<Chipaca> zyga-ubuntu: I expect you'll have fun with snapd#3587
<mup> PR snapd#3587: Using udev tagging for snap interfaces <Created by adglkh> <https://github.com/snapcore/snapd/pull/3587>
<zyga-ubuntu> stokachu: fantastic news, thank you
<zyga-ubuntu> Chipaca: yes, I already replied to the forum theread, I need to read that :)
<stokachu> ty!
<mup> PR snapd#3605 opened: fix LP: #1628289, have Ubuntu snapd package recommend squashfuse <Created by dustinkirkland> <https://github.com/snapcore/snapd/pull/3605>
<zyga-ubuntu> Chipaca: reviewed
<zyga-ubuntu> more reviews after returning to the main area
 * zyga-ubuntu kicked some PRs for a fresh run with green master
<zyga-ubuntu> Chipaca: can you confirm one thing for me please
<zyga-ubuntu> https://forum.snapcraft.io/t/small-issue-with-snap-debug-confinement/1374
<ogra_> zyga-ubuntu, so you are doing the raspbian stuff ... ? do you still need me ?
<Chipaca> zyga-ubuntu: i can confirm that panic, if that's what you meant
<zyga-ubuntu> ogra_: no, thank you, I brouht the raspberry pi now and I have hands on testing
<zyga-ubuntu> Chipaca: yes, exactly, thank you
<ogra_> ok
 * zyga-ubuntu is never sure if this is just his system being in a wonky state
<ogra_> (i still dont get what the purpose of snapd in raspbian is without having a v6 core snap)
 * zyga-ubuntu just fixes bugs
<ogra_> (well, probably i should say "base" nowadays :) )
<Chipaca> zyga-ubuntu: thank you for the review! I'll implement fixes for all the nitses
<zyga-ubuntu> Chipaca: thank you for the branch, as I indicated you don't have to apply everything
<zyga-ubuntu> Chipaca: the branch was very nice
<Chipaca> zyga-ubuntu: ah, i'll only address the ones that are N such that when x= sin(t) and y=sin(t/N), the lissajous curve is closed
<om26er> ogra_: re: gpio on the pi. Who shall I bug regarding availability of the GPIO interface in the stable channel ?
<ogra_> om26er, we need support for gadget upgrades first ... it is on the list but i dont know the prio they have given it
<om26er> ogra_: is there a bug report for that ? We(Crossbar) might need that interface on the stable channel for commercial reasons.
<ogra_> om26er, for the missing gadget update feature, yeah
<ogra_> bug 166438, bug 1636927, bug 1654362
<mup> Bug #166438: XML::Parser installation instructions needed <linux> <packaging> <Inkscape:Fix Released by bryce> <https://launchpad.net/bugs/166438>
<mup> Bug #1636927: upgrading kernel/gadget snap on Pi3 did not update dtb files <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1636927>
<mup> Bug #1654362: updating gadget snaps does not update config files <Snappy:Triaged> <https://launchpad.net/bugs/1654362>
<ogra_> (there are more iirc but i cant find them right now ... make a pick)
<ogra_> hmm
<ogra_> bug 1664388
<mup> Bug #1664388: No way to update kernel cmdline via gadget snap update <ce> <snapd:Confirmed> <https://launchpad.net/bugs/1664388>
<ogra_> thats better
<om26er> yeah
<ogra_> (ignore the first one above)
<om26er> any chance these may get fixed before Ubuntu Core update ?
<om26er> ;)
<ogra_> Ubuntu Core update ?
<om26er> I might be not clear on the release cycle here. Maybe I meant on next snapd update, not sure.
<ogra_> thats up to the snapd team (though it might also require changes on the kernel and gadget packages)
<ogra_> perhaps ask on the forum ...
<om26er> will do.
<ogra_> om26er, also https://forum.snapcraft.io/t/development-sprint-june-26th-2017/415/46?u=ogra
<ogra_> thats the outcome of the sprint discussion
 * Chipaca sees https://github.com/kragniz/anyprint and thinks of sergiusens
<ogra_> that is clearly missing echo "foobar"
<cachio> Chipaca, could you please re-run the spread tests for PR 3483?
<Chipaca> cachio: you can't?
<Chipaca> niemeyer: i'm assuming that's something you need to fix ^ plz
<Chipaca> cachio: done
<cachio> Chipaca, sorry, I can now
<cachio> I didn't realize it :)
<Chipaca> ah
<Chipaca> niemeyer: never mind then :-)
<pedronis> Chipaca: no standups?
<Chipaca> pedronis: no standups
<Chipaca> pedronis: it's like a miny staycation
<Chipaca> mini*
<pedronis> heh
<pedronis> :)
<pedronis> mostly catching up on stuff today
<pedronis> (and also not feeling 100%, not sure why, came back from spain over the weekend, and was fine until yesterday)
<niemeyer> Welcome back pedronis!
<niemeyer> Chipaca: Consider it nevermind :)
<niemeyer> neverminded
<niemeyer> The spell checker screwed the joke
<Chipaca> pedronis: you're allergic to work /o\
<mup> PR snapd#3483 closed: tests: dependency packages installed during prepare-project <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3483>
<cachio> Chipaca, if you usually don't rebase the PR, how do you add the changes in trunk, with merge?
<cachio> Chipaca, I ask because the dependencies branch is merged now and I would like to integrate that change in the branches to support fedora and opensuse
<Chipaca> niemeyer: is there a trick to drinking brazilian yerba with argentine kit? The shop only had brazilian, and I'm drinking way too many bits :-)
<Chipaca> cachio: a merge, yes
<Chipaca> cachio: it's less a rule and more a guideline, but if you've got to ask, stick to the rule :-)
<cachio> Chipaca, sure :)
<pedronis> Chipaca: that would be scary news
<Chipaca> pedronis: I'm allergic to being awake
<zyga-ubuntu> pedronis: o/ hey
<zyga-ubuntu> how are you?
<Chipaca> pedronis: it makes me tired and drowsy
<pedronis> Chipaca: :)
<cachio> zyga-ubuntu, I run the test confinement-classic with opensuse and I am getting this error
<zyga-ubuntu> cachio: yes?
<cachio> https://paste.ubuntu.com/25125697/
<zyga-ubuntu> oh, nice
<zyga-ubuntu> can you fix it, it seems easy (altough annoying)
<zyga-ubuntu> what does uname -a say?
<cachio> Linux li166-151 4.9.36-x86_64-linode85 #1 SMP Thu Jul 6 15:31:23 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
<cachio> zyga-ubuntu, it should just to edit the snap makefile?
<niemeyer> Chipaca: The only trick I know of is buying "good" yerba.. I drink of a single local brand which is pure leaves, and really good at not having that "powder".. I don't know what to do if they go out of business :)
<Chipaca> niemeyer: I was once friends with a guy that sourced shade-grown stuff, but it was out of my reach at the time (and now i could afford it, i've lost touch)
<niemeyer> Chipaca: A lot of people use small filters.. they look a bit like a tea filter, tied into the straw.. I find it a bit.. unfortunate :P
<Chipaca> I think I'm going to chuck this (use it for the garden?) and get some proper stuff
<niemeyer> That's what I do too.. and it's not even a matter of price.. there are pretty expensive packs that are still mostly powder.. even the ones saying "thick" in the pack, are often just pieces of the branch, and the powder
<Son_Goku> niemeyer, have you seen morphis or zyga around lately?
<Son_Goku> I was wondering if either them have gotten around to fixing the breakage for 32-bit architecture builds of snap-confine
<niemeyer> Son_Goku: They are both here at the sprint, which is why they haven't been super active here this week
<Son_Goku> niemeyer, ah okay
<Son_Goku> yeah, because currently the latest 2.27 release code fails to build
<niemeyer> Son_Goku: Yeah, I think we have a new build from last night
<niemeyer> mvo was on it
<Son_Goku> oh okay
<Son_Goku> I didn't see any new commits here, so I wasn't sure: https://github.com/snapcore/snapd/commits/release/2.27
<niemeyer> Son_Goku: What issue, just to be sure we're talking about the same thing?
<niemeyer> Son_Goku: It was a critical update on 2.26 I think
<Son_Goku> # github.com/snapcore/snapd/cmd/snap-seccomp
<Son_Goku> In file included from /usr/include/xfs/xqm.h:21:0,
<Son_Goku>                  from src/github.com/snapcore/snapd/cmd/snap-seccomp/main.go:49:
<Son_Goku>  /usr/include/xfs/xfs.h:51:12: error: size of array 'xfs_assert_largefile' is too large
<Son_Goku>  extern int xfs_assert_largefile[sizeof(off_t)-8];
<Son_Goku>             ^~~~~~~~~~~~~~~~~~~~
<Son_Goku> error: Bad exit status from /var/tmp/rpm-tmp.LDoJXq (%build)
<Son_Goku> from: https://copr-be.cloud.fedoraproject.org/results/ngompa/snapd-prerel-fedora/fedora-rawhide-i386/00579417-snapd/build.log.gz
<Son_Goku> this affects armv7hl and i686
<niemeyer> Son_Goku: Thanks, I'll confirm with them here
<Son_Goku> thanks
<niemeyer> Son_Goku: I don't recall that being an issue, btw.. and it's definitely not a general problem on 32bit otherwise our tests would break
<Son_Goku> I think it has to do with new libxfs
<niemeyer> Son_Goku: Do you have a suggested fix for the issue already?
<niemeyer> Or do we have to investigate what the proper change is?
<Son_Goku> I know that zyga actually fixed this before for the C snap-confine code
<niemeyer> Aha, that's good info, thanks
<Son_Goku> it's just cropped up again for the snap-seccomp which pulls this in
<Chipaca> niemeyer: something like a missing -D_I_LIKE_BIG_FILES_AND_I_CANNOT_LIE
<niemeyer> That's what I was thinking we well :)
<niemeyer> as well
<zyga-ubuntu> cachio: re
<niemeyer> zyga-ubuntu: Son_Goku was just reporting a 32bit issue building 2.27 on Fedora above
<niemeyer> zyga-ubuntu: Apparently something you've fixed before the snap-seccomp change
<niemeyer> Son_Goku: Do we have a forum topic on it?
<Son_Goku> it predates forum
<Son_Goku> the last time we fixed this was around 2.16, I think
<zyga-ubuntu> niemeyer: I think this is lack of -D something something large file support that's set by default on ubuntu i386 but not on fedora
<zyga-ubuntu> Son_Goku: can you drop me a quick forum post about this, I'm finding it hard to keep track of all the things in flight today
<niemeyer> Son_Goku: Yeah, sorry, I meant just now about the problem we need to address
<mup> PR snapcraft#1416 opened: core: a clean command should clean <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1416>
<mup> PR snapcraft#1354 closed: catkin plugin: fix pythonpath for catkin_find <Created by mrjogo> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1354>
<niemeyer> zyga-ubuntu: Yeah, that's what we had guessed as well
<Pharaoh_Atem> zyga-ubuntu: did you see mattdm's reply to you on the mailing list?
<zyga-ubuntu> Pharaoh_Atem: no, not yet
 * zyga-ubuntu looks
<zyga-ubuntu> Pharaoh_Atem: interesting
<Pharaoh_Atem> zyga-ubuntu: this echoes what I've said the last few times we've talked about it
<zyga-ubuntu> Pharaoh_Atem: I'm making a reply but still distracted by the re-exec but we found
<Pharaoh_Atem> cool
 * zyga-ubuntu -> supper
<zyga-ubuntu> Pharaoh_Atem: replied
<mup> PR snapcraft#1400 closed: lxd: Distingish FileNotFoundError if not installed <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1400>
<mup> PR snapd#3606 opened: cmd: fix broken double re-executiong from snapd 2.21 <Created by zyga> <https://github.com/snapcore/snapd/pull/3606>
#snappy 2017-07-20
<mup> PR snapd#2807 opened: snap: add new `snap switch` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/2807>
<mup> PR snapd#3607 opened: cmd: fix re-exec bug when starting from snapd 2.21 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3607>
<mup> PR snapd#3608 opened: cmd: rework reexec detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/3608>
<Saviq> zyga-ubuntu: the crash: http://pastebin.ubuntu.com/25131529/
<zyga-ubuntu> Saviq: thank you
<mup> PR snapcraft#1413 closed: core: minimal windows support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1413>
<mup> PR snapd#3609 opened: Introduce the kvm interface <Created by Saviq> <https://github.com/snapcore/snapd/pull/3609>
<mup> PR snapd#3610 opened: snap: do not always quote the snap info summary <Created by mvo5> <https://github.com/snapcore/snapd/pull/3610>
 * Chipaca in a warren of undoes
<mup> PR snapcraft#1417 opened: Move cross-compiling from kernel to kbuild plugin <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1417>
<zyga-ubuntu> Chipaca: hey, can you have a look at a small pr for cmd.go please?
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3608
<mup> PR snapd#3608: cmd: rework reexec detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/3608>
<Chipaca> zyga-ubuntu: sure
<Chipaca> zyga-ubuntu: how will this work in places where it's not /snap?
<zyga-ubuntu> https://lwn.net/Articles/698073/
<zyga-ubuntu> Chipaca: it's not yet, we're aware
<zyga-ubuntu> Chipaca: but that's for future
<mup> PR snapd#3607 closed: cmd: fix re-exec bug when starting from snapd 2.21 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3607>
<Chipaca> pedronis: how're you feeling today, vis-a-vis being asked for reviews?
<pedronis> Chipaca: I'm ok
<Chipaca> pedronis: when you have a slot, I'd appreciate a look at snapd#3600
<mup> PR snapd#3600: many: expose service status in 'snap info' <Created by chipaca> <https://github.com/snapcore/snapd/pull/3600>
<Chipaca> meanwhile I'm fixing a bug in snapstate's copydata thing
<zyga-ubuntu> lip 20 14:17:55 fyke kernel: audit: type=1400 audit(1500553075.963:253): apparmor="DENIED" operation="capable" profile="/snap/core/2445/usr/lib/snapd/snap-confine" pid=10030 comm="snap-confine" capability=4  capname="fsetid"
<mup> PR snapd#3611 opened: overlord/snapstate/backend: some copydata improvements <Created by chipaca> <https://github.com/snapcore/snapd/pull/3611>
<pedronis> Chipaca: done
<Chipaca> pedronis: thanks!
<Chipaca> pedronis: I'll address your comments right now (as i just finished the copydata pr)
<Chipaca> "just" == "just now before reading your comments and making me some tea"
<mup> Bug #1705486 opened: SPI not working on Raspberry Pi 2 with ubuntu core <Snappy:New> <https://launchpad.net/bugs/1705486>
<niemeyer> zyga-ubuntu: github.com/rogpeppe/govers
<zyga-ubuntu> thanks!
<pedronis> Chipaca: to clarify, I thing you were trying to solve that  client and deamon API are the same, so why two struct, but now you are positing client == daemon == systemd, which I'm not sure about
<Chipaca> fair 'nuf
<Chipaca> thing is
<Chipaca> bah, forward-thinking to the actual services work
<Chipaca> not sure this distinction will continue to be as clear, but ok
<pedronis> which distinction?
<pedronis> about systemd?
<pedronis> the package
<Chipaca> bah
<Chipaca> i'm probably hung up on details of the past implementation
<mup> PR snapd#3606 closed: cmd: fix broken double re-executiong from snapd 2.21 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3606>
<mup> PR snapd#3608 closed: cmd: rework reexec detection <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3608>
<Chipaca> pedronis: you're right
<Chipaca> there's no reason this needs to be like this
 * Chipaca fixes
<pedronis> IÂ understand that having two structs is more annoying than 1, but reading client in the signatures of systemd is really strange, a bit unclear if the relationship will hold
<pedronis> but I agree we don't want/need 3 structs for this
<zyga-ubuntu> niemeyer: we don't have to switch, upstream just merged the fix :)
<mup> PR snapd#3612 opened: vendor: update go-flags to address crash in "snap debug" <Created by zyga> <https://github.com/snapcore/snapd/pull/3612>
<zyga-ubuntu> Chipaca: FYI https://forum.snapcraft.io/t/snap-remove-doesnt-remove-data-from-root-snap-snap-name/1387
<zyga-ubuntu> maybe true, maybe red herring
<zyga-ubuntu> maybe red dwarf
<mup> PR snapd#3525 closed: interfaces: add password-manager-service implicit classic interface (LP: #1653769) <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3525>
<Chipaca> zyga-ubuntu: Dude.
<zyga-ubuntu>  yes?
<cachio> zyga-ubuntu, I have updated PR 3604 to make seccomp work for opensuse as you requested
<cachio> zyga-ubuntu, could you take a look when you have some time?
<zyga-ubuntu> yes, looking
<cachio> tx
<zyga-ubuntu> cachio: commented,
<cachio> zyga-ubuntu, i see this error
<cachio> https://paste.ubuntu.com/25133113/
<cachio> when LDFLAGS contain a static link to seccomp
<cachio> zyga-ubuntu, any idea how to deal with it?
<mup> PR snapd#3548 closed: interfaces: Add /run/uuid/request to openvswitch <Created by coreycb> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3548>
<zyga-ubuntu> cachio: looking
<zyga-ubuntu> cachio: are we installing a package that ships libseccomp.a?
<Chipaca> zyga-ubuntu: wrt "dude", commented in the forum
<zyga-ubuntu> Chipaca: aha, thank you
<zyga-ubuntu> :D
<zyga-ubuntu> thanks!
<zyga-ubuntu> so pawel reported it too :D
<zyga-ubuntu> it must have been him then
 * zyga-ubuntu has rusty memory
<cachio> zyga-ubuntu, not sure but in snap-seccomp/main.go we are linking to it
<cachio> in opensuse libseccomp.a is not included in any package that we install
<kyrofa> Hey jdstrand, you wanted to ping you about that classic snap I'm playing with
<cachio> zyga-ubuntu, but we need to link statically to libseccomp
<kyrofa> I'm not awake yet and thus can't type
<cachio> zyga-ubuntu, at least there is a test for that
<kyrofa> jdstrand, it contains libraries for building its clients, and a tool for running several clients in a specific configuration based on a text file
<kyrofa> It looks for those clients in the PATH
<kyrofa> And even if the PATH is accessible in confinement, snap-confine strips it off
<kyrofa> So if the snap is strictly confined, it can't find anything to orchestrate in e.g. the home dir
<kyrofa> Thus classic
<cachio> zyga-ubuntu, why we need to link statically to libseccomp in ubuntu?
<pedronis> cachio: because of reexec
<cachio> pedronis, to make sure both are using the same one?
<pedronis> yes (though we don't do that with libudev because there the libudev<->kernel part is the more fragile one, but is not ideal)
<cachio> ok
<cachio> pedronis, thanks
<pedronis> zyga-ubuntu: not only it was reported, but we discussed not to touch it until we have snapshots, at least that was the conclusion in London
<kyrofa> jdstrand, moos-kyrofa is now in the review queue
<Chipaca> pedronis: fixed snapd#3600 as per your review; thanks!
<mup> PR snapd#3600: many: expose service status in 'snap info' <Created by chipaca> <https://github.com/snapcore/snapd/pull/3600>
<mup> PR snapd#3596 closed: tests: disable snapd-notify for the external backend <Created by fgimenez> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3596>
<mup> PR snapd#3503 closed: tests: add browser-support interface test <Created by fgimenez> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3503>
<pedronis> Chipaca: generally +1 with a comment about expected in the parser
<Chipaca> pedronis: gotcha. Yeah, it's a little convoluted as is
<Chipaca> pedronis: by having expected be an array, you mean then doing strutil.ListContains to check for unexpected stuff?
<Chipaca> bah, no real need, the switch handles that
<Chipaca> hmmm
<mup> PR snapd#3600 closed: many: expose service status in 'snap info' <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3600>
#snappy 2017-07-21
<jdstrand> kyrofa: hey, done
<mup> PR snapcraft#1397 closed: waf: enable cross-compilation support  <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1397>
<zyga-ubuntu> o/
 * Chipaca takes a break
<ogra_> zyga-ubuntu, any chance for me to get a second ack o the gadget changes today ?
<ogra_> *on
<zyga-ubuntu> ogra_: which one is that?
<ogra_> zyga-ubuntu, the one you self-appointed yourself for :)
<ogra_> https://github.com/snapcore/pi3-gadget/pull/11
<mup> PR pi3-gadget#11: build uboot from source, pull blobs from upstream, use dtbs from archive <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/11>
<ogra_> has been tested in and out and ondra nodded it off already
<kyleN> zyga-ubuntu, hey got a minute to discuss that interface pr issue?
<ogra_> EEK!
<ogra_> ogra@styx:~$ ls /snap/core/current/usr/bin/xdg-open
<ogra_> /snap/core/current/usr/bin/xdg-open
<ogra_> but ...
<ogra_> ogra@styx:~/Devel/branches/snapd/interfaces/builtin$ grep xdg-open unity7.go
<ogra_> # Snappy's 'xdg-open' talks to the snapd-xdg-open service which currently works
<ogra_> # snappy's xdg-open supports all snaps images, this access may move to another
<ogra_> /usr/local/bin/xdg-open ixr,
<ogra_> damn !
<mup> PR snapd#3613 opened: fix locations of xdg-open files <Created by ogra1> <https://github.com/snapcore/snapd/pull/3613>
<mup> PR snapcraft#1415 closed: tests: run the tests in travis using LXD containers <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1415>
 * ogra_ pokes launchpad with a pointy stick ... 
<cachio> niemeyer, do we want to run the c-unit-tests on fedora and opensuse?
<cachio> niemeyer, I am migrating the rest of the tests suites so I want to make sure
<cachio> fgimenez, if you have any time, could you please take a look to this one? PR 3505
<cachio> fgimenez, I have a new branch to enable more test suite for fedora but I need this one landed before
<fgimenez> cachio: sure i'll take a look in a bit
<cachio> fgimenez, tx
<ogra_> koza, did you see https://forum.snapcraft.io/t/bluetooth-powered-on-on-boot/1391/3  ?
<kyleN> hey folks, I have a branch to add the broadcom-asic-contro interface (a commonInterface). passes run-checks, but can't test it since I can't build the deb (https://pastebin.canonical.com/194128/).
<kyleN> Anyway, I'd appreciate eyes on the branch so I can hopefully submit the PR today (on holiday next week): https://github.com/knitzsche/snapd/tree/broadcom-asic-control-commonInterface-master
<niemeyer> cachio: Yeah, it would be great to have them working there
<cachio> niemeyer, ok
<mup> PR snapd#3614 opened: daemon, client, cmd/snap: implement "snap status" <Created by chipaca> <https://github.com/snapcore/snapd/pull/3614>
<Chipaca> ^ it's slowly coming together again \o/ nice way to wrap a friday for me
<mup> PR snapd#3615 opened: add broadcom-asic-control interface <Created by knitzsche> <https://github.com/snapcore/snapd/pull/3615>
<mup> PR snapd#3597 closed: arch,release: map armv6 correctly <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3597>
<mup> PR snapd#3613 closed: fix locations of xdg-open files <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3613>
<mup> PR snapd#3317 closed: many: start implenting "base" snap type on the snapd side <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3317>
#snappy 2017-07-22
<mup> PR snapcraft#1411 closed: tests: build the snapcraft snap in travis tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1411>
<station> Im on openmediavault (debian 8) succes with sudo apt-get install snap
<station> but with sudo snap install nextcloud
<station> ZOE ERROR (from /usr/lib/snap/snap): error opening file (/usr/share/snap/Zoe/HMM/install)
<station> ZOE library version 2013-02-16
<Chipaca>  /usr/share/snap/Zoe?
<station> no Idea
<Chipaca> station: I'd say ask in the forum, people are off irc right now
<Chipaca> station: you snap install nextcloud and the installation itself fails with that message?
<station> google didn't help much either
<station> y thats the comands and output ( first post
<Chipaca> let me see if i can get a debian 8 vm
<station> Im on  OMV Debian 8
<station> fresh install ...
<Chipaca> station: I don't know what OMV is
<station> openmediavault
<Chipaca> station: I don't know what that is
<Chipaca> station: I can say that it works in debian 9
<Chipaca> (i've got an image of that already)
<Chipaca> station: but the whole ZOE ERROR thing is weird, i have no idea where even that comes from
<station> like FreeNAS https://www.google.ro/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwj666Xy5p3VAhWCuBQKHasuCj8QFggmMAA&url=https%3A%2F%2Fwww.openmediavault.org%2F&usg=AFQjCNGsAPddstwxQ1OJDLVzXGfGbZGrYA
<station> https://www.openmediavault.org/
<Chipaca> Â¯\_(ã)_/Â¯
<station> lol ok thanks
<Chipaca> station: I'll dig a little bit to see if I see this ZOE ERROR which intrigues me
<Chipaca> station: but for a solution to your problem your best bet is the forum
<Chipaca> (and patience -- people were sprinting in warsaw this week so they're on their way back home now)
 * Son_Goku thinks of something else entirely when he sees OMV
<Chipaca> station: how did you get snapd on debian 8?
<station> sudo apt-get install snap
<station> my main problem is I'm newish to server â¦ I'm setting up an homeserver (media â¦) + it needs to serv to internet security cam, homeassistent Nextcloud shal I go with Proxmox and vritualise everything in its best enviroment
<Chipaca> ah, i needed to apt update inside the vm
<Chipaca> station: you seem to be asking random people in a random channel for advice on a home media server
<Chipaca> station: i'd suggest you ask in a home media server channel for advice about that in particular :-)
<Chipaca> hmm, the live cd might not have enough space for this
<station> well its not even an home media server channel question if there would be a channel for hosting and private server â¦
<Chipaca> station: so, just to get it out of the way, what do you get when you do "snap version"?
<station> lol strange lol
<station> SNAP - Semi-HMM-based Nucleic Acid Parser (version 2006-07-28)
<station> usage: snap [options] <HMM file> <FASTA file> [options]
<station> options:
<station>   -help           report useful information
<station>   -lcmask         treat lowercase as N
<station>   -plus           predict on plus strand only
<station>   -minus          predict on minus strand only
<station>   -gff            output annotation as GFF
<station>   -ace            output annotation as ACED
<station>   -quiet          do not send progress to STDERR
<station>   -aa <file>      create FASTA file of proteins
<station>   -tx <file>      create FASTA file of transcripts
<station>   -xdef <file>    external definitions
<station>   -name <string>  name for the gene [default snap]
<Chipaca> station: um
<station> what is that never heard of this Nucleic Acid Parser
<Chipaca> station: that is snap
<Chipaca> from the package 'snap'
<Chipaca> station: as opposed to snap, from the package 'snapd'
<station> y y y
<Chipaca> this might explain why i had no idea what the error was about :-D
<Chipaca> station: try again with 'snapd' :-)
<station> -bash: snapd: command not found
<Chipaca> no, sorry
<Chipaca> station: âsudo apt install snapdâ
<Chipaca> station: then, âsnap install nextcloudâ
<station> E: Unable to locate package snapd
<Chipaca> station: have you done âsudo apt updateâ?
<station> y all updated
<station> trough Webinterface so rechecking to be safe â¦
<Chipaca> gah
<Chipaca> station: I followed links for debian 8 but the thing i downloaded is debian 9
<Chipaca> station: it's entirely possible snapd isn't available for 8
 * Chipaca looks
<station> recheckd no change
<Chipaca> station: stretch 8, or 9?
<station> Debian GNU/Linux 8 _Jessie_
<Chipaca> station: so, old stable
<station> http://ftp.debian.org jessie-updates/main
<station> so they clame
<Chipaca> station: ok, so you need to make a forum post about whether it works on debian's old stable
<Chipaca> station: you might need to bump the kernel version for it to work, for example
<Chipaca> station: what is it you're trying to do again?
<station> basicaly there are a group of distros that offer NFS SAMBA â¦.  shareing +User administration in GUI besides those I need a bunch of selfhosted apps where OMV falls short but I thought it was shorter wav than installing all from bare bones Ubuntu server or Debian
<Son_Goku> there's no snapd for Debian 8
<Son_Goku> it's only available for Debian 9 and newer
<Son_Goku> I think there was some go-related thing that kept it from being available in jessie-backports
<Chipaca> station: I honestly don't know, but: doesn't nextcloud offer those things out of the box?
<Chipaca> Son_Goku: yeah, it might be possible to get working as long as the kernel is new enough, but only if built elsewhere (e.g. snarf the debian 9 deb)
<Chipaca> station: in nextcloud is sufficient, maybe you can install an all-snaps system and snap install nextcloud on it?
<station> y thats what im thinking + Raid Zfs or Btrfs
<Chipaca> anyway, i need to go do some REM and then some SWS over and over again
<Chipaca> o/
<station> Nexcloud + Homeassistent in snap
<station> thanks again
#snappy 2017-07-23
<fyber> https://github.com/3v1n0/electron-quick-start-snap To me this snap looks like it clones a project from github and runs `npm start` - so I replaced all mentions of `electron-quick-start` with my own project and I get /snap/nanowallet/x1/bin/desktop-launch: line 225: /snap/nanowallet/x1/nanowallet.wrapper: Permission denied
<fyber> I'm not sure where it's getting the .wrapper file from in that project
<fyber> looks like what I need
<fyber> most perplexing is that it says "permission denied" for something inside the snap
#snappy 2018-07-16
<razer2> I tried to install Spotify with snap and it would not launch. Is this a known problem?
<razer2> I ment to mention I'm using Debian.
<razer2> I believe the .deb repository/package does work though. I'm run it in the past.
<pstolowski|afk> Mornings
<eraserpencil> Hi
<eraserpencil> what is the difference between a kernel snap and a gadget snap
<Chipaca> moin moin
<Chipaca> mvo: thank you for the reviews!
<Chipaca> mvo: also, welcome back, I hope you had a lovely holiday
<mvo> Chipaca: hey, good morning! my pleasure, hope my ramblings were useful. I had a lovely vacation indeed. also happy to be back, hacking is also a lot of fun :)
<Chipaca> mvo: most of your ramblings are spot on
<Chipaca> mvo: which of course means I'll make fun of you over the only one you got wrong
 * Chipaca won't, tho
<mvo> Chipaca: heh :)
<mvo> Chipaca: thank you
<mvo> Chipaca: (for not making (too much) fun of me)
<Chipaca> mvo: and in your defence, it's not at all clear why the test function that tests fooPublisher would be called `TestGetEscapes`
 * mvo nods
<pedronis> mvo: welcome back,  I was a bit confused I thought you would still be on vacation
<pedronis> Chipaca: hi
<Chipaca> pedronis: let's all go on vacation and avoid these confusions
<mvo> pedronis: hey, thank you! maybe confused because Maciej is off for another week?
<mvo> pedronis: at least currently I can't be away longer, we have some deadlines to make (18.04.1 and core18) :/
<Chipaca> mvo: what part about "dead" in deadline is unclear
<pedronis> mvo: I think for a while IÂ thought you would be at the sprint,  but then I saw it was not the case so IÂ thought you were doing vacation, and maybe somebody said you were having 2 weeks
<pedronis> anyway
<mvo> pedronis: yeah, we decided I should skip the sprint to focus on core18 during the week. but indeed â¦ anyway :)
<mvo> pedronis: happy to be back, did I miss anything exciting?
<mvo> pstolowski: and hello to you as well :)
<pedronis> mvo: zyga's remapping branches went through some iterations but are not landed yet,  I need to re-review the last version
<mvo> pedronis: ok, I will check it out and can help with it if needed
<mvo> pedronis: I'm getting myself an overview about the open PR right now to see where we stand
<pedronis> mvo: I proposed one about conflicts, the first pass of streamlining about those
<mvo> pedronis: yeah, thanks for this!
<pedronis> I'm working on a follow up atm
<pedronis> seems we are bad at returning proper error kinds for anything that is not install/refresh etc
<mvo> pedronis: yeah, that sounds likely :/
<Chipaca> pedronis: kinds are added when requested by clients though
<pedronis> Chipaca: ?
<Chipaca> pedronis: error kinds are not always needed, and have been added by client request
<Chipaca> client == snap and gnome software, usuallly
<Chipaca> pedronis: OTOH we have an outstanding request from gnome software to add error kinds to async errors, which we haven't done yet
<pedronis> Chipaca: we don't return the various install related error kinds for install-path and try for example
<pedronis> Chipaca: and now it makes sense to return  the conflict kind for anything  that creates a change
<Chipaca> pedronis: that's a good example: the text error is (or was) good enough for 'snap', and gnome software doesn't let you do those things
<Chipaca> the kind is needed when the client needs to do something other than print the message to the user
<pedronis> Chipaca: are you saying I should not do this?
<pedronis> that logic doesn't make sense to me for a documented api
<Chipaca> pedronis: I'm just as much a completionist (completist?) as you :-) i'm just explaining why things are as they stand
<Chipaca> the documentation for `kind` is: Unique code for the error, to enable a snapd client to display appropriate behaviour (optional).
<pedronis> Chipaca: ok, but afaict we reached a point where that approach doesn't make sense
<Chipaca> pedronis: while you're working on this, give async ones a think too :-)
<pedronis> I'm still not sure what that means
<Chipaca> pedronis: if a change fails after it's being accepted, we don't return an error kind anywhere
<Chipaca> s/being/been/
<pedronis> well but definition we don't have kinds for those sort of errors
<pedronis> they are mostly fmt.Errorf anyway
<Chipaca> pedronis: and gnome software would like something like kinds to know how to present the error to the user
<Chipaca> at the same time, we don't have multi-errors for multi-snap actions, which might (or might not) be related
<Chipaca> pedronis: sorry if this is very braindump-y
<Chipaca> "tell pedronis all your gripes about errors"
<Chipaca> dunno what triggered that :-)
<mup> PR snapd#4940 opened: WIP: added UDevMonitor for future hotplug support <Created by stolowski> <https://github.com/snapcore/snapd/pull/4940>
<mup> PR snapd#5401 closed: asserts: add (optional) kernel-track to model assertion <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5401>
<Chipaca> mvo: I'm wondering what to do about fooPublisher and filler
<Chipaca> filler should probably be called fillerPublisher or something
<Chipaca> as it's the filler for (short)publisher
<Chipaca> (or for long publisher, but long publisher isn't in a table where it matters, yet)
<pedronis> Chipaca: have you looked at how Maintenance is set in responses?  I'm wondering if it's applicable looking at #5509 and warnings
<mup> PR #5509: daemon: move to use a constructor for Meta <Created by chipaca> <https://github.com/snapcore/snapd/pull/5509>
<eraserpencil> hey guys, if I'm following kyrofa's blog on publishing snaps, would I be spamming the store/repo? Afterall, they are tests. Is there an alternative store for all test snaps?
<Chipaca> pedronis: hmm, I hadn't noticed that, no
<Chipaca> eraserpencil: there is, but it's a pain to set up at this point (including needing a recompile of snapd)
<eraserpencil> anyway to unregister or remove it from the store?
<Chipaca> eraserpencil: not without manual admin intervention
<Chipaca> eraserpencil: you  could just make it private
<eraserpencil> kk thanks alot!
<pedronis> mvo: Chipaca:   working on one of my PRs I noticed we have prepare code like this:   https://github.com/snapcore/snapd/blob/master/tests/main/snap-run-symlink/task.yaml#L8   it sounds like we wouldn't need it anymore?
<Chipaca> pedronis: correct
<mup> PR snapd#5509 closed: daemon: move to use a constructor for Meta <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/5509>
<mup> PR snapd#5510 closed: daemon, overlord/state: warnings pipeline <Blocked> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/5510>
<mvo> pedronis: yeah, I will clean that up in a sec, thanks for noticing
<mup> PR snapd#5511 opened: tests: remove unneeded setup code in snap-run-symlink <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5511>
<pedronis> mvo: thx, snap-run-alias is the same
<mup> PR snapd#5512 opened: interfaces/builtin: create can-bus interface (2.34) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5512>
<mvo> pedronis: thanks, will work on this too
<mvo> Chipaca: fillerPUblisher sounds not bad, it clearly communicates what it does
<pedronis> Chipaca: glad that pattern can work warnings, I didn't look into details
<pedronis> *work for
<zyga> Hey ho
<Chipaca> pedronis: at some point I'm sure Response vs resp made sense, but these days it seems to be silly
<Chipaca> pedronis: in any case, yes it works
<Chipaca> pedronis: just need to find a name for the interface that provides both transmitMaintenance and addWarningsToMeta (or pay 2x interface lookup)
<mup> PR snapd#5512 closed: interfaces/builtin: create can-bus interface (2.34) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5512>
<mup> PR snapd#5513 opened: interfaces/builtin: create can-bus interface (2.34) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5513>
<mvo> zyga: hello! how are you? all well?
<mup> PR snapd#5508 closed: cmd/snap: print unset license as "unset", instead of "unknown <Simple> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5508>
<Chipaca> pedronis: _very_ happy with how this has turned out
<mup> PR snapd#5514 opened: daemon, overlord/state: warnings pipeline <Created by chipaca> <https://github.com/snapcore/snapd/pull/5514>
<Chipaca> and i'm off to the gym for a bit
<zyga> Mvo: all is good :-)
<zyga> Once you catch up with everything I would love to know if we are green
<mvo> zyga: green as in "the integration PR passes"?
<mup> Bug #1781906 opened: Content provider interfaces introduced to snaps aren't correctly set up <Snappy:New> <https://launchpad.net/bugs/1781906>
<Chipaca> mvo: this week the boys are on a different timetable, meaning they leave school at standup o'clock (2pm local), so i'm going to be missing (or at least very late) to the standups, probably
<Chipaca> pedronis: when you can, take a look at what I ended up doing wrt maintenanceTransmitter: https://github.com/snapcore/snapd/pull/5514/files#diff-1a1f3e7ad9b1d7584e2d3e7d0c4c3db9
<mup> PR #5514: daemon, overlord/state: warnings pipeline <Created by chipaca> <https://github.com/snapcore/snapd/pull/5514>
<pedronis> Chipaca: trying to finish this branch and then I will look at various reviews
<Chipaca> pedronis: no no no, I demand nothing less than you dropping everything and obeying my every whim
<zyga> mvo: yes, that integration passes on master + the remapping branch + the implicit snapd patch
 * zyga waves from the morning plenary
<ogra_> hmpf ... refreshing core to edge in a lvm instance gets me a hanging snapd shutdown process
<ogra_> ("A stop job is running for snappy daemon" (0:00/1:30))
<ogra_> s/lvm/kvm/
<Chipaca> ogra_: journalctl -u snapd ?
<ogra_> Chipaca, to late, it has shut down now so the journal is gone
<Chipaca> ogra_: you were holding it wrong anyway
<ogra_> but it should be easy to repro ofr anyone running kvm and switching from stable to edge
<ogra_> its a plain kvm with no additional snaps installed yet
<ogra_> and just "snap refresh --edge core"
<ogra_> (and reboot)
<Chipaca> ogra_: on a core device image, or classic with core?
<ogra_> Chipaca, kvm UbuntuCore image ... latest from cdimage
<Chipaca> ogra_: okey cokey
<Chipaca> okie cokie?
<Chipaca> wookie cookie?
<ogra_> sounds like a childrens TV show
<mvo> Chipaca: ok, thanks for letting me know
<mvo> zyga: sure, checking
<sergiusens> mvo: hi there, is there a plan to add base information to `snap info <snap-name>`?
<pedronis> sergiusens: we added it , in verbose mode
<sergiusens> ah, thanks
<popey> cjwatson: the launchpad builders seem a bit clogged with one recipe. Causing a small backlog.
 * Chipaca returns
<ogra_> "the second part of the movie series"
<mvo> pstolowski: I looked at my net-bpf stuff and I was indeed using unsafe.Pointer for the endianess detection, so I can offer no better approach unfortunately
<pstolowski> mvo: fair enough, thanks for checking. i think i convinced upstream it's the reasonable approach
<mup> PR snapd#5515 opened: daemon:  make sure most change generating handlers can produce errors with kinds <Created by pedronis> <https://github.com/snapcore/snapd/pull/5515>
<pedronis> Chipaca: mvo: ^   based on #5502
<mup> PR #5502: many: streamline the generic conflict check mechanisms <Created by pedronis> <https://github.com/snapcore/snapd/pull/5502>
<Chipaca> pedronis: thank you
<pedronis> mvo: #5491  bits about config seems wrong
<mup> PR #5491: overlord,daemon,cmd: re-map snap names around the edges of snapd <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5491>
<mvo> pedronis: yeah, I think so too
<mvo> pedronis: makes we wonder if we should grow a configstate.Remap* helper ?
<pedronis> it's an approach, IÂ don't have strong feelings either way, doing that, keeping the bits in snap
<mvo> pedronis: "keeping the bits in snap" you mean having snap.Remap* for all the remappings?
<pedronis> mvo: no, I mean keeping the current helper and use them only for config
<mvo> pedronis: aha, I see
<mvo> pedronis: my gut-feeling is that moving them into configstate is slightly cleaner as it will make clear that the mapping is related to config (only). but no super strong opinion
<pedronis> mvo: IÂ think it's fine as long as we know we don't need in the client,  client importing *state is strange
<pedronis>  /problematic
<mvo> pedronis: +100
<mvo> pedronis: what I like about the PR from zyga is that it drops the client side (re)mapping and that its all done on the server side, it seems a nice property
<pedronis> mvo: yes, that was the agreement
 * mvo nods
<pedronis> pstolowski: did you work on stopping snap connect to do something  if the connection already exist?
<cjwatson> popey: I was out, but I don't see a significant problem now.  Recipe builds are usually pretty short but happen in batches, so if you're just looking at /builders then they often look more significant than they are, FWIW
<cjwatson> popey: thanks for letting me know though
<popey> ah okay, thanks.
<pstolowski> pedronis: no, that's not started yet
<popey> cjwatson: another for you. possible proxy error. "fatal: unable to access 'https://git.xiph.org/celt.git/': Received HTTP code 503 from proxy after CONNECT" in lp builder.
<popey> https://launchpadlibrarian.net/378715573/buildlog_snap_ubuntu_xenial_armhf_96015d27dc6daea80ecdd7c5bac64b6c-xenial_BUILDING.txt.gz
<zyga> pedronis, mvo: I would suggest to solve the config remapping story within this PR so we cannot have fractured view of how things are mapped. I think that we should map core(state)-snapd(memory)-system(api) consistently and that this model is good. We just need to map the storage of the config using the existing function for this to work end to end
<pedronis> zyga: we don't store config on snapd, so not sure what that sentence mean
<zyga> pedronis: that we should map the actual config store with the remapper for state so that it is "core.foo" as we want
<zyga> pedronis: I want to avoid a special-cased mapper for config vs other cases
<pedronis> zyga: it doesn't make sense for the remapper to live ifacestate for that tough
<pedronis> what's the relation between config and interfaces
<zyga> pedronis: ish, I agree but the decision on which remapper to use was is made there for convenience. I agree this could all live in snapmgr
<pedronis> also using a remapper for state in api is also strange
<zyga> what do you mean about that?
<zyga> s/about/by/
<pedronis> I don't understand what you are proposing
<pedronis> it sounds very roundabout
<pedronis> it's unclear to me that what we do for config and interfaces is the same thing
<pedronis> it is just similar
<zyga> I think we want a consistent view
<zyga> if we have "system" thing that is mapped to something
<zyga> we should not have two opinions as to what that is mapped to
<pedronis> ?
<pedronis> but we have two options
<pedronis> config: system -> core
<pedronis> interfaces:  system -> core|snapd
<cjwatson> popey: could you file that sort of thing as a bug against launchpad-buildd, please?
<zyga> not really, interfaces are system->core (via snapd because it matters in memory)
<cjwatson> will take some investigation
<popey> sure thing
<zyga> I just want to avoid the possibility of having two pieces of code that remap and get out of sync
<pedronis> zyga: you are proposing to be very roundabout to avoid a very theoritecial problem
<pedronis> I'm not sure who that helps
<pedronis> not the reader of the code
<pedronis> anyway I'm happy to leave mvo pick a path forward
<zyga> pedronis: I don't think that's the case, I'm saying something very simple: remap the config store from system to core using one of the proposed functions, that's all (and not have a yet-another function for config explicitly).
<zyga> I also trust mvo to handle this gracefully
<pstolowski> pedronis: reviewed your branch, looks great, just one change equest
<pstolowski> *request
<pedronis> pstolowski: that doesn't work with the tests
<pedronis> unless we add some way to clear them but then it gets a bit too verbose vs the potential issue
<pedronis> and function cannot be compared in go
<pstolowski> pedronis: right, i see
<zyga> pedronis, mvo: I commented on the PR https://github.com/snapcore/snapd/pull/5491#discussion_r202718439 but I won't have time to explore this right now
<mup> PR #5491: overlord,daemon,cmd: re-map snap names around the edges of snapd <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5491>
<pstolowski> i just looked at task handlers, it's similiar
<pstolowski> fair enough
<pstolowski> +1
<pedronis> zyga: that is roundabout :) but IÂ let mvo think about it
<zyga> thanks mvo :)
<pstolowski> oh wow, git subtrees are awesome
<pstolowski> git fetch go-udev; git merge -s subtree go-udev/master merges latest go-udev changes into our osutil/udev
<pstolowski> magic
<mup> PR snapd#5516 opened: tests: add test that ensures we do not boot any system in degraded state <Created by mvo5> <https://github.com/snapcore/snapd/pull/5516>
<Chipaca> pstolowski: nice
<mup> PR snapd#5517 opened: osutil/udev: sync with upstream <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5517>
<mup> PR snapd#5518 opened: systemd: fix snapd.apparmor.service.in dependencies <Created by mvo5> <https://github.com/snapcore/snapd/pull/5518>
<mvo> pedronis, zyga thanks, I am working on the degraded boot regression right now, once that is fixed I look at the mapping (should be soon :)
<mup> PR snapd#5519 opened: debian: do not ship snapd.apparmor.service on ubuntu <Created by mvo5> <https://github.com/snapcore/snapd/pull/5519>
<ogra_> zyga, i playing with layouts here ... is it not possible to use single files (binaries) in layouts ? (i get a plethora of errors when trying to re-map a single binary from $SNAP/usr/bin)
<Chipaca> ogra_: note zyga is sprinting
<Chipaca> ogra_: telegram if urgent
<ogra_> yeah, i didnt expect an immediate answer
<ogra_> i assume he reads backlog :)
<ogra_> heh
<ogra_> /usr/lib/snapd/snap-device-helper: 18: /usr/lib/snapd/snap-device-helper: tr: not found
 * ogra_ tries a symlink instead of binding all of /usr/bin ...
 * Chipaca off
<mvo> zyga, pedronis I pushed some ideas to 5491, I am happy to revert and push as its own PR if that is more convenient. please let me know how it feels, spread tests are running right now
<mvo> fwiw, a review of 5410 would be great
<zyga> mvo: ack, I'll check soon
<pedronis> mvo: what are the   ConfigIfaceRemap...  functions ?
<pedronis> mvo: I don't think snap is a good place for this , some of its logic is very snapd internal state dependent
<mup> PR # closed: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mup> PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2040, snapcraft#2078, snapcraft#2105, snapcraft#2110, snapcraft#2121, snapcraft#2128, snapcraft#2135, snapcraft#2173, snapcraft#2176, snapcraft#2177, snapcraft#2180
<mup> PR # opened: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2040, snapcraft#2078, snapcraft#2105, snapcraft#2110, snapcraft#2121, snapcraft#2128, snapcraft#2135, snapcraft#2173, snapcraft#2176, snapcraft#2177, snapcraft#2180
<mup> PR # opened: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mup> PR # closed: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mup> PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2040, snapcraft#2078, snapcraft#2105, snapcraft#2110, snapcraft#2121, snapcraft#2128, snapcraft#2135, snapcraft#2173, snapcraft#2176, snapcraft#2177, snapcraft#2180
<mup> PR core18#41 opened: Revert "static: add systemd environment generator to ensure PATH contains /snap/bin" <Created by mvo5> <https://github.com/snapcore/core18/pull/41>
<mup> PR core18#43 opened: Remove manpages and other documentation, cleanup empty doc dirs <Created by sil2100> <https://github.com/snapcore/core18/pull/43>
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR # opened: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2040, snapcraft#2078, snapcraft#2105, snapcraft#2110, snapcraft#2121, snapcraft#2128, snapcraft#2135, snapcraft#2173, snapcraft#2176, snapcraft#2177, snapcraft#2180
<mup> PR # opened: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mup> PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> PR # closed: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR # opened: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> Issue core18#4 closed:  Crash qt gui aplication (build with core 18 on ubuntu 18.04(LXD))  <Created by EndrII> <https://github.com/snapcore/core18/issue/4>
<mup> PR core18#43 closed: Remove manpages and other documentation, cleanup empty doc dirs <Created by sil2100> <https://github.com/snapcore/core18/pull/43>
<mup> PR # closed: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mup> PR # opened: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mvo> pedronis: snap not a good place> ack - any suggestions? overlord/mapper as its own package seems a bit extreme
<mup> PR core18#41 opened: Revert "static: add systemd environment generator to ensure PATH contains /snap/bin" <Created by mvo5> <https://github.com/snapcore/core18/pull/41>
<mup> PR # closed: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mvo> pedronis: the ConfigIface* functions are a copy/paste error, sorry for that
<mup> Issue core18#4 closed:  Crash qt gui aplication (build with core 18 on ubuntu 18.04(LXD))  <Created by EndrII> <https://github.com/snapcore/core18/issue/4>
<mup> PR core18#41 closed: Revert "static: add systemd environment generator to ensure PATH contains /snap/bin" <Created by mvo5> <https://github.com/snapcore/core18/pull/41>
<mup> Issue core18#4 opened:  Crash qt gui aplication (build with core 18 on ubuntu 18.04(LXD))  <Created by EndrII> <https://github.com/snapcore/core18/issue/4>
<mup> PR core18#41 opened: Revert "static: add systemd environment generator to ensure PATH contains /snap/bin" <Created by mvo5> <https://github.com/snapcore/core18/pull/41>
<mup> PR # opened: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mup> PR core18#43 closed: Remove manpages and other documentation, cleanup empty doc dirs <Created by sil2100> <https://github.com/snapcore/core18/pull/43>
<mup> PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> PR # closed: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mup> Issue core18#4 opened:  Crash qt gui aplication (build with core 18 on ubuntu 18.04(LXD))  <Created by EndrII> <https://github.com/snapcore/core18/issue/4>
<mup> PR core18#41 opened: Revert "static: add systemd environment generator to ensure PATH contains /snap/bin" <Created by mvo5> <https://github.com/snapcore/core18/pull/41>
<mup> PR core18#43 opened: Remove manpages and other documentation, cleanup empty doc dirs <Created by sil2100> <https://github.com/snapcore/core18/pull/43>
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> PR # opened: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR # closed: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR # opened: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mup> Issue core18#4 closed:  Crash qt gui aplication (build with core 18 on ubuntu 18.04(LXD))  <Created by EndrII> <https://github.com/snapcore/core18/issue/4>
<mup> PR core18#41 closed: Revert "static: add systemd environment generator to ensure PATH contains /snap/bin" <Created by mvo5> <https://github.com/snapcore/core18/pull/41>
<mup> PR core18#43 closed: Remove manpages and other documentation, cleanup empty doc dirs <Created by sil2100> <https://github.com/snapcore/core18/pull/43>
<mup> PR # closed: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<mup> Issue core18#4 opened:  Crash qt gui aplication (build with core 18 on ubuntu 18.04(LXD))  <Created by EndrII> <https://github.com/snapcore/core18/issue/4>
<mup> PR # opened: snapd#4416, snapd#4767, snapd#4940, snapd#4951, snapd#5122, snapd#5170, snapd#5187, snapd#5234, snapd#5271, snapd#5307, snapd#5318, snapd#5340, snapd#5341, snapd#5346, snapd#5395, snapd#5410, snapd#5413, snapd#5421, snapd#5433, snapd#5434, snapd#5446, snapd#5450, snapd#5451,
<mup> snapd#5452, snapd#5456, snapd#5469, snapd#5473, snapd#5474, snapd#5475, snapd#5477, snapd#5486, snapd#5491, snapd#5495, snapd#5497, snapd#5502, snapd#5503, snapd#5505, snapd#5506, snapd#5507, snapd#5511, snapd#5513, snapd#5514, snapd#5515, snapd#5516, snapd#5517, snapd#5518, snapd#5519
<niemeyer> It's getting 500s from GitHub.. will disable it
<zyga> https://status.github.com/messages indicates github is experiencing issues and are fixing it
<niemeyer> Done.. the relevant plugins have been disabled. Will try enabling them again later today.
<niemeyer> mup: You ok for now?
<mup> niemeyer: I apologize, but I'm pretty strict about only responding to known commands.
<niemeyer> Cool
<niemeyer> o/
<pedronis> mvo: I don't know, my feeling in the end is that putting some bits in ifacestate and some in configstate would have been fine. if we don't think so then I fear we indeed need mapper or to stick them in snapstate because that's the one that everything can import
<pedronis> mvo: mapper is not a great name tough, too vague
<mvo> pedronis: ok, having bits in configstate and bits in ifstate is fine with me, I was mostly thinking it would be good to have a single place but probably overkill, I can (trivially) revert, my first commit was actually just doing this
<mvo> pedronis: thanks for your thoughts
<mvo> pedronis: I pushed a (much) simpler version of my previous PR to the same place, lets talk tomorrow :)
#snappy 2018-07-17
<mvo> pstolowski: good morning :)
<pedronis> mvo: hi, I'm going to merge #5502 today
<mup> PR #5502: many: streamline the generic conflict check mechanisms <Created by pedronis> <https://github.com/snapcore/snapd/pull/5502>
<mvo> pedronis: ok, I look at it now
<mvo> pstolowski: interessting fix in the osutil/udev PR - is this a signed/unsigned issue?
<mvo> s/is/was/
<pstolowski> mvo: yes
<pedronis> mvo: thx
<mvo> pstolowski: interessting
<pstolowski> mvo: it wouln't happen if my tests didn't use 0xff's to simulate invalid offset
<mvo> pedronis: thank you, nice improvement, also nice to see how much cleaner it got
<mvo> pstolowski: a, sweet
<mvo> pstolowski: I was wondering how you get such a big offset that its a problem on 32bit
<mvo> pstolowski: nice to know there was a test for it!
<pstolowski> mvo: i'm not quite sure why it didn't panic on 64bits though.
<pstolowski> mvo: but i added debug and it clearly showed negative number there
<mvo> pstolowski: I assume its because on 64bit 0xff000000 will not wrap to a neagative number (space in the 64 bit int left). but I have not really looked at the details so I might be wrong
<mvo> Chipaca: good morning
<pstolowski> mvo: i think you're right. re your earlier question, the test parses crafted garbage data
<Chipaca> mvo: it is! how're you today?
<mvo> fun! the degraded test found that we have a sshgurad.service that is broken in our test images
<mvo> pstolowski: tests ftw! nice job
<mvo> Chipaca: I'm well, thank you! having fun reading code and poking at our boot stuff
<pstolowski> i made a quickfix in the PR and also proposed it upstream
<mvo> Chipaca: hope you are well too?
<mvo> pstolowski: ta
<Chipaca> tests ftw indeed
<mvo> Chipaca: I'm also loosing hair over the question *why* the snap-run-hook test fails on core18
<Chipaca> mvo: yep! looking forward to the day
<Chipaca> mvo: SCSI Chain overterminated
<mvo> Chipaca: *cough* those were the days
 * Chipaca thinks the bofh excuse database needs updating
<pstolowski> nb, it's interesting Go chose to return int from len()
<Chipaca> pstolowski: uint is a second-class citizen
<mvo> pstolowski: fun, there is even a stack-overflow question about why go is doing that (and the answer even makes some sense)
<pstolowski> mvo: do you have a link?
<mvo> pstolowski: https://stackoverflow.com/questions/39088945/why-does-len-returned-a-signed-value
<pstolowski> mvo: thanks, interesting explanations
<Chipaca> pedronis: with 5502 landed, should I work on snapshotstate, or should i wait for a followup?
<Chipaca> pedronis: and what about #5474
<mup> PR #5474: many: finish sharing a single TaskRunner with all the the managers <Created by pedronis> <https://github.com/snapcore/snapd/pull/5474>
<pstolowski> hmm interesting failure of google:ubuntu-16.04-64:tests/main/interfaces-accounts-service
<pstolowski> https://www.irccloud.com/pastebin/XyMk8wi7/
<Chipaca> quoth the raven, WAT
<mvo> meh, I get quota CPUS exceeded
<mvo> in my latest PR
<Chipaca> mvo: have we alerted people about the sshguard service thing?
<mvo> Chipaca: not yet, might be related to our image
<mvo> Chipaca: I mean to our version of the cloud-image
<Chipaca> mvo: ah, i thought we were using stock
<mvo> Chipaca: I'm not sure, I wanted to check with cachio
<mvo> Chipaca: its slightly strange because sshguard is universe
<Chipaca> ah
<popey> https://forum.snapcraft.io/t/snap-refresh-fails-no-such-file-or-directory/6413
<popey> If someone has a moment to look at that I'd appreciate it
<Chipaca> popey: https://i.imgur.com/iJoG4Ks.jpg
<popey> IKR
<popey> (I have seen this before, but only now have captured it)
<ogra_> must be all these airplanes interfering with the cosmic rays at your place
<Chipaca> popey: the most WAT bit is that after the Error, r319 is active
<popey> fun, right?
<Chipaca> i.e the one it just said didn't exist
<Chipaca> waiiit
<popey> this isn't even a manky machine that's been running forever with all kinds of crap on it
<Chipaca> feck
<popey> it's a vm I woke up to test something unrelated
<Chipaca> I mean, <curses>
<Chipaca> it looks like we're adding the prerequisite N times
<Chipaca> that can't be good
<popey> so this is a snapd bug? :)
<Chipaca> 3 times
<Chipaca> yes
<popey> \o/
<popey> I mean, oh dear.
<popey> Thanks for looking at it.
<Chipaca> popey: where's my emoji for person-blowing-a-raspberry
<popey> colon thorn
<popey> :Ã¾
<Chipaca> >:Ã¾ then
<Chipaca> aka the angry lisping viking
<popey> shall I file a bug in snapd?
<Chipaca> popey: let me dig a little bit more first please
<popey> okeydokey
<Chipaca> my first dumb test of printing the name of the prerequisite when we decide to install it (after checking it wasn't due to be installed) shows that we're installing things that are already due to be installed
<Chipaca> ooooh
<Chipaca> this is probably because that snap is the default provider for a bunch of stuff
<Chipaca> innit?
<popey> Â¯\_(ã)_/Â¯
 * Chipaca talks to itself
<Chipaca> popey: yep, just repro'd it, on  install
<popey> yay
<Chipaca> still digging further
<Chipaca> (there is a race, which is why you're not seeing it all the time)
<Chipaca> so, yeah
<Chipaca> we r dumb
<Chipaca> popey: I'll work on a fix, but feel free to file a bug
<popey> kk
<popey> thanks
<Chipaca> popey: interestingly the refresh succeeded, also
<Chipaca> I mean, the change failed, but everything installed
<popey> yeah, when I have seen this in the past, I run "snap refresh" and it says it has nothing to do
<Chipaca> yep
<popey> also also, in other news "snap refresh" and "snap install" now take a phenomenally long time to actually do anything
<popey> I feel like I'm staring at a broken computer when i run snap refresh or install these days
<Chipaca> :-(
<Chipaca> popey: I know, they used to be so zippy! :-(
<Chipaca> interfaces code is _slow_
<popey> 14 seconds to do nothing
<popey> i just refreshed then tried to refresh again, 14 seconds for the second run
<Chipaca> popey: wait, it takes that long to say 'nothing to do'?
<popey> yes
<Chipaca> that's not what I thought you meant
<Chipaca> let me try
<pedronis> Chipaca: I will merge trunk in the follow ups, they will need review but you can start working on snapshot, you basically need to use AddAffectedSnapsByAttr
<popey> https://www.irccloud.com/pastebin/JadUttj8/
<Chipaca> pedronis: and drop the old kludgy conflicts stuff
<pedronis> yes
<popey> wtf is it doing for 14 seconds?
<Chipaca> popey: snap list | wc -l
<pedronis> Chipaca: I alos need to update the wiki, there's quite a few kinds not mentioned there
<Chipaca> popey: plz
<Chipaca> pedronis: :-( thanks :-)
<popey> 205
<Chipaca> do you have SNAPD_DEBUG enabled?
<popey> god i hope not
<popey> how can I tell?
<Chipaca> popey: nah it shouldn't slow things down, just log more
<Chipaca> popey: (and we've asked canonicalers to have it enabled (and SNAPD_DEBUG_HTTP=3 at least iirc) so we can figure out one-off errors from the logs)
<Chipaca> popey: âjournalctl -u snapdâ would have a lot of DEBUG lines
<popey> define " a lot" :)
<Chipaca> popey: more than 0
<popey> i haz 0
<Chipaca> so, not a lot
<Chipaca> :-)
<popey> want another bug?
<popey> news to me btw that you've asked canonicalers to have debug enabled
<Chipaca> popey: if you can (even momentarily) turn on debug, we can see where the bug is
<popey> ok
<Chipaca> popey: I can forward you the email :-)
<Chipaca> popey: subject Â«suggestion to work with debug enabled in snapdÂ», from a year ago
<popey> unread :)
 * Chipaca goes to the shed to get a 2x4
<popey> I have enabled this before (to debug store slow download issues) and having debug switched on made the error go away
<popey> I am reluctant to enable these things as it makes my system behave differently than the people I talk to every day
<popey> normals don't enable this, and neither to devs
<Chipaca> popey: the _only_ thing setting these debug flags does, afaik, is change the logging options
<popey> lies :)
<Chipaca> popey: but I see your point
<pedronis> well, but turning it off and on is worse
<pedronis> it involves a restart
<pedronis> which is sure to change things
<popey> https://forum.snapcraft.io/t/extremely-slow-snap-downloads/4668/7?u=popey
<pedronis> given how snapd works
<Chipaca> popey: snap downloads should be much faster since we switched to fastly
<Chipaca> popey: but, snap refresh != snap downloads
<popey> i have seen user reports of slow downloads
<Chipaca> popey: 14 seconds for snap refresh, with 200 snaps, is rather unique which is why i'd like to see logs of it to know who's being slow
<popey> https://askubuntu.com/questions/1056606/from-what-url-snaps-are-downloaded
<popey> for example
<popey> I am frustrated though, because the general response seems to be "ah well, can't do anything without debug data"
<pedronis> Chipaca: a review of #5515 would be appreciated
<mup> PR #5515: daemon: make sure most change generating handlers can produce errors with kinds <Created by pedronis> <https://github.com/snapcore/snapd/pull/5515>
<popey> right, just enabled debug, now snap refresh is instant
<Chipaca> popey: ok
<Chipaca> popey: keep it enabled for a while and tell us if it gets slow
<popey> will do, thanks
<Chipaca> popey: pretty please
<Chipaca> popey: (this would be bad news, or good news, because it'd indicate a bug in a part of snapd we're itching to change)
<pedronis> Chipaca: ?   is this a do nothing refresh
<Chipaca> pedronis: yes
<pedronis> Chipaca: do we have plans to change that?
<Chipaca> pedronis: see his pastebin
<pedronis> don't think so
<Chipaca> pedronis: if it's snapd getting slow after a while because state in-memory means walking whatever bit of state takes 14+ seconds, then yes it's  us
<popey> hahaha, its gone slow again already :D
<Chipaca> popey: e-e-excellent. gib logs.
<popey> which logs, how?
<Chipaca> popey: journalctl -u snapd
<Chipaca> popey: from the latest 'started snapd' line
<popey> http://paste.ubuntu.com/p/syNYjKjB64/
<popey> oh, too late, that's all of it
<Chipaca> popey: that's not debug logs
<popey> :(
<popey> I typed what you asked
<popey> maybe snapd didnt restart
 * popey tries again
<popey> my bad, line 4709 onwards http://paste.ubuntu.com/p/xKMMN3fSdg/
<Chipaca> popey: if Â« journalctl -u snapd | grep DEBUG: Â» is empty, it didn't work
<Chipaca> ah
<Chipaca> now yes :-D
<popey> haha, is that 200 stabs of the store api ? :)
<Chipaca> oh
<Chipaca> for the asserts refresh
<pedronis> assertions, it's  1 or 2 api calls per snap
<pedronis> we have plans to improve
<pedronis> that but not immediate plans
<Chipaca> the snaps refresh api call itself is super fast: 10:51:29.410762 to 10:51:30.377175
<popey> gold star for you :)
<Chipaca> bah, 'super fast', less than a second
<pedronis> :)
<popey> dirty brown star for the store :)
<Chipaca> it's python, less than a second is it doing its best
<mvo> as a quick fix, could we do the assertion update only for non-interactive refreshes or something
 * Chipaca suddenly finds himself to be evil
<pedronis> no
<pedronis> we can't
<pedronis> because validation
<mvo> indeed
<Chipaca> popey: could you file a bug, on snapd *and* snapstore, that having 200 snaps means refreshes take way too long
<popey> sure thing!
<popey>  on it
<Chipaca> popey: include these logs (from the last bit on), and the 'time' log
<popey> Thanks for spending time to help me debug
<popey> will do
<Chipaca> taw
<Chipaca> pedronis: dunno if you saw that we add prereqs twice and that breaks things
<pedronis> Chipaca: no
<pedronis> Chipaca: that's mvo actually :)
<Chipaca> pedronis: true, that
<Chipaca> mvo: it's all your fault!
<mvo> Chipaca: meh
<Chipaca> mvo: *all* of it
<pedronis> maybe
<Chipaca> mvo: even brexit
 * mvo crumbles in depair
<Chipaca> i'm telling the bbc
<pedronis> it depends exactly how it fails
<mvo> Chipaca: do you have a reproducer
<Chipaca> mvo: it's racy, but yes: snap install gnome-system-monitor gnome-calculator
<Chipaca> mvo: if it fails to repro, clean up with: snap remove gnome-system-monitor gnome-calculator gnome-3-26-1604 gtk-common-themes
<pedronis> theoretically there's only one prereq running at a time
<Chipaca> basically a snap can have another snap more than once in its prereqs
<Chipaca> and we don't check for that
<pedronis> Chipaca: a snap, or a pair of snaps?
<pedronis> ah, a snap
<Chipaca> pedronis: just one should be enough
<Chipaca> in fact it shold repro with just one
<mvo> Chipaca: ok, once I finished wrestling with the snap-run-hook failure on core18 I'm on this one
<Chipaca> mvo: already fixing it here
<pedronis> Chipaca: mvo: it's because   they added themes to the gnome lib snap itself
<mvo> Chipaca: \o/ even better
<pedronis> so now some snaps get to it through the snap and through gnome
<pedronis> so we have a snap that is a default provider both for a snap and a default provider of that snap
<pedronis> fun
<pedronis> should also be easy to solve
<popey> https://bugs.launchpad.net/snapstore/+bug/1782112 tada
<mup> Bug #1782112: snap refreh is slow with lots of snaps installed <snapd:New> <Snap Store:New> <https://launchpad.net/bugs/1782112>
<Chipaca> pedronis: wondering whether to solve it at install time, or at work-out-prereqs time
<Chipaca> pedronis: the latter seems saner, the former more foolproof
<pedronis> Chipaca: mmh
<pedronis> Chipaca: in theory it should work already, but the theory is fragile
<pedronis> apparently
<popey> I'm surprised we don't send a blob of data to the store with the list of everything we want rather than 200 separate requests.
<popey> seems terribly inefficient
<pedronis> popey: that is the question
<popey> Ah okay. Ignore me :)
<pedronis> popey: everybody has a different list so caching would be defeated
<pedronis> it needs bit more cleverness, some compromise
<mvo> pedronis: if you could have a look at 5491 again today that would be greatly appreciated
<pedronis> Chipaca: IÂ mean in theory when we install  gnome itself  we should detect that the themes are already being installed, that doesn't seem to work though
<popey> I appreciate I'm a bit of an outlier with 200 snaps installed :)
<popey> blazing a trail
<Chipaca> pedronis: because we create the task list and only add it to state if the whole thing worked
 * mvo hugs pop'trailblazer'ey
<pedronis> Chipaca: yes, but we atomically do that for each snap
<pedronis> or at least that's the intention
<pedronis> needs bit of digging
<pedronis> Chipaca: anyway in one of the plans we would do all of this upfront
<Chipaca> pedronis: I can show you where we're not checking for dupes, if you  want
<Chipaca> maybe I should check for dupes at both places, for extra extraness
<pedronis> Chipaca: but the dupes are indirect
<pedronis> in this case no?
<pedronis> so I'm not sure how there can be a place
<pedronis> (afair current code)
<Chipaca> pedronis: snapstate's defaultContentPlugProviders already gets the duplicated names
<pedronis> ?
<pedronis> from which snap
<pedronis> so it's silly bug?  not a deep bug?
<Chipaca> I forget but give me a moment to undo my fix and di can tell you
<Chipaca> pedronis: it seems to be, yes
<pedronis> ok
<pedronis> I see we were assuming that a snap will not repeat the default provider
<pedronis> but they do
<mvo> *cough* thats a silly bug indeed. thanks pedronis  and Chipaca
<Chipaca> pedronis: for gnome-system-monitor, defaultContentPlugProviders returns: gtk-common-themes, gtk-common-themes, gtk-common-themes, gnome-3-26-1604
<pedronis> wonderful
<pedronis> seems 2.34  material even
<Chipaca> pedronis: for gnome-calculator, gtk-common-themes, gtk-common-themes, gnome-3-26-1604, gtk-common-themes
<pedronis> if that is still possible
<Chipaca> it's surprising that it works some of the time :-)
<Chipaca> I'll fix defaultContentPlugProviders to not return dupes, and leave the slightly hairy code in handlers alone
<mvo> pedronis: yes, looks like we need a .1 anyway
<Chipaca> it'll fix this issue and not make things harder for us
<pedronis> Chipaca: thx
 * Chipaca looks for the unit tests of defautContentPlugProviders, and fails
<ogra_> jdstrand, i'd appreciate a manual apoproval at https://dashboard.snapcraft.io/snaps/xdmcp-client/revisions/1/  (uses the new mir-kiosk snap with a loopback x11 plug for Xwayland, source is at https://github.com/ogra1/xdmcp-client/ )
<popey> oooh
<ogra_> i plan to extend that with a few other clients and turn it into a thin-client appliance ;) (vnc, rdp ... )
<popey> great idea.
<popey> I had no success getting an app working with mir-kiosk, so will look at yours for inspiration
<ogra_> it sadly needs layouts to make Xephyr happy (hardcodes paths to binaries in the code) ... for normal apps it shoudl be a lot easier though
<pstolowski> i keep getting  cannot allocate new Google server for ubuntu-18.04-64: quota 'CPUS' exceeded. Limit: 600.0 in region us-east1 from travis
<mvo> pstolowski: I saw this as well and asked zyga to ask Gustavo about it. Hopefully he or cachio can help
<pstolowski> mvo: ack, thanks
<ppisati> ogra_: i'm debugging the snapcraft.yaml build issue for xenial and bionic, feel free to drop it if you have anything else
<ogra_> ppisati, https://forum.snapcraft.io/t/linux-4-15-0-snaps/6401/5
<ogra_> ppisati, and there seems to be an issue with "no such target "firmware_install" at the end of the build
<ppisati> ogra_: yep, i have patch similar to that
<ogra_> right, then only the missing firmware_install target is left ....
<ppisati> ogra_: 3794440b47ceada080b365e281b76313c7a2e255
<ogra_> grepping the whole tree the only mention of firmware_instakk is in debian/scripts which i thought wouldnt be run ...
<ogra_> *firmware_install
<boxrick> Hello, I added some values to the environment of my machine ( proxy ) and need the snapd service to reload those, is this possible without a full restart of the service?
<boxrick> And second if I wish to pin a package version, is that doable?
<boxrick> IE disable auto refresh
<Chipaca> boxrick: there are several knobs you can use to change when a refresh happens, but you can't disable it from the device, no
<Chipaca> mvo, pedronis, #5522 is the fix
<mup> PR #5522: overlord/snapstate: dedupe default content providers <Created by chipaca> <https://github.com/snapcore/snapd/pull/5522>
<Chipaca> feel free to tag it and target it appropriately
<Chipaca> boxrick: what're you wanting to stop refreshing, and why?
<boxrick> Since if and when it breaks, I want it to be in a controlled fashion. Or perhaps a checked upgrade in my dev environment before I roll it out in the real world.
<boxrick> Similar reasons I pin to software versions in config management
<boxrick> If I have a working environment, I need that to remain consistent.
<Chipaca> boxrick: as far as I know you get that level of control when you use a branded store
<Chipaca> boxrick: if this is for a device, you can also do revision pinning (but i'm not sure that isn't also tied to a branded store)
<ogra_> i think it is
<ogra_> (you actually pin it in the store ... )
<Chipaca> ogra_: k
<ogra_> (AFAIK at least ... :) )
<Chipaca> boxrick: depending on the snap, in some cases it'll be appropriate to let production track stable and have a canary tracking candidate
<boxrick> Any of example of how I can pin a version?
<Chipaca> or I could just be talking to a wall
 * Chipaca wanders off
<boxrick> Perhaps I have missed your point I apologise.
<boxrick> Well kind of unrelated, reloading enviroment. Any tips without a full snapdrestart?
<boxrick> Or some way of printing out the current environment that it has loaded up.
<ogra_> boxrick, i'd just try "systemctl reload snapd" ... technically that should reload the units config, parctically no idea if snapd picks it up though
<ogra_> *practically
<boxrick> Sadly not, seems I will have to poke the systemd service to find the PID then check the environment of that PID
<Chipaca> boxrick: how did you set the environment?
<boxrick> Just setting /etc/environment
<boxrick> ( Proxy settings in this case )
<boxrick> Which I then need snapd to read
<boxrick> And just restarting it every time is super ugly.
<Chipaca> boxrick: 'every time'?
<Chipaca> boxrick: (not sure why it's super ugly, but you can't change the environment of another process; not easily at least)
<boxrick> Well for example, I am deploying this with config management
<boxrick> So as part of a task it needs to make sure the environment is installed and snapd is running with it for example
<ogra_> well, systemctl reload should send a kill -HUP to the daemon ... and i would expect it to also process the .service file ... if snapd respects the -HUP it should then pick up the new env
<boxrick> Reload just bombs out with unsupported which is ashame
<boxrick> Not to worry anyway, I have a workaround. Its just a little long winded
<Chipaca> ogra_: systemctl reload does not work like that
<ogra_> oh ?
<niemeyer> Heya
<niemeyer> mvo: Any good hints about why the systems were hanging?
<Chipaca> ogra_: systemctl reload needs the service to have an ExecReload line
<niemeyer> I'm gcing just now
<ogra_> ah
<ogra_> so it isnt sysv-init ... who'd have thought that ! :)
<Chipaca> ogra_: and, on the other hand, sending a HUP does not cause an environment re-read :-)
<ogra_> depends on the daemon ... i have seen some do it
<r3r57> Hello, after I restart my computer I regularly get the following error when running some snap applications: 'cannot change profile for the next exec call: No such file or directory \n snap-update-ns failed with code 1: No such file or directory'. I don't know whether it's a distribution specific issue or not and I'm not able to fix it myself. Does anyone have a clue what might be the problem here? Thank you in advance.
<popey> r3r57: what's the output of "snap version" please?
<r3r57> popey, 'snap    2.32.9 snapd   2.32.9 series  16 solus   3.9999 kernel  4.17.3-81.current'
<popey> ahh, i think zyga mentioned this problem recently. I believe there is a workaround.
<Son_Goku> niemeyer, zyga, mvo: woohoo! https://pagure.io/flock/issue/87
<Son_Goku> note the tag on the right ;)
<popey> yay
<zyga> Hey r3r57
<zyga> There is a workaround but ikey needs to fix solid
<zyga> Solus
<zyga> Hey Son_Goku
<Son_Goku> zyga, I just sent the confirmation email to bexelbie for our talk
<zyga> That looks very good
<r3r57> zyga, okay thank you, did you mind tell me the workaround or should I ask in #solus?
<Son_Goku> this is good news to wake up to after having to stay up late last night for an OpenStack server migration last night :)
<zyga> r3r57: no, Just harder to type from my phone
<zyga> Do this please
<zyga> sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/*
<r3r57> magic
<r3r57> zyga, popey, thanks for your help, everything is working again.
<r3r57> and good luck with your talk ;)
<popey> Excellent, thanks zyga
<pedronis> Chipaca: I updated the wiki  https://github.com/snapcore/snapd/wiki/REST-API/_compare/2b0fc8772a1ac9cb57585f32e24ebd9a169fe940...acf58ecbbb071c4be741431ac648f9c5f0b63202 if you could double check
<pstolowski> mvo: hey, a question to https://github.com/snapcore/snapd/pull/5456
<mup> PR #5456: snapstate: refuse to remove bases or core if snaps need them <Created by mvo5> <https://github.com/snapcore/snapd/pull/5456>
<zyga> mvo: there?
<zyga> mvo: please fetch my remote
<zyga> mvo: and see if 47665f978a1d94ed44b3943a1d33f0e39be96459 makes any difference
<kenvandine> can anyone help me understand why /proc/mounts is significantly different from inside a snap that from the host?
<kenvandine>  /dev/loop30 /snap/spotify/13 squashfs ro,nodev,relatime 0 0
<kenvandine> on the host
<kenvandine> and
<Chipaca> kenvandine: because snaps have their own private mount namespace
<kenvandine>  /dev/loop30 /var/lib/snapd/hostfs/snap/spotify/13 squashfs ro,nodev,relatime 0 0
<kenvandine> in the snap
<kenvandine> we're trying to figure out how to filter out the noise in the gnome-system-monitor snap
<kenvandine> andyrock, ^^
<Chipaca> ah. Maybe zyga has insight into that.
<andyrock> I guess what happens to all the udev (and afterall udev-udisks2 rules)
<ogra_> i thought that was long fixed
<ogra_> oh ... "in the snap" ... sorry, missed that
<kenvandine> ogra_, yeah... looks terrible in the gnome-system-monitor snap, which is seeded
<kenvandine> ogra_, andyrock had patched libgtop2 to filter it out, but it filters based on what the host sees not the snap
<ogra_> right ... but that was fixed through a udev rule ... which likely doesnt apply from inside the sanp
<ogra_> yep, i remember discussiong it with him back then
<ogra_> did you try to ship said libgtop version in your snap ?
<kenvandine> yes
<ogra_> dang
<kenvandine> but it filters with a mnt of /snap
<kenvandine> there are other things showing up inside the snap as well, that don't on the host
<kenvandine> like /etc/alternatives
<kenvandine> and others
<ogra_> well, so filter with the hostfs prefix too
<ogra_> /var/lib/snapd/hostfs/snap is effectively /snap
<kenvandine> yeah
<kenvandine> but that would still leave noise
<ogra_> so you could just extend the filter
<kenvandine>  /dev/loop55 /var/lib/urandom squashfs ro,nodev,relatime 0 0
<kenvandine> for example
<kenvandine> the mount points are all over the place
<kenvandine> maybe we should ignore all loop
<kenvandine> not sure those are useful for gnome-system-monitor
<ogra_> but that would break something like mounted isos
<ogra_> (in case you want to allow people seeing them)
<pedronis> pstolowski|lunch: IÂ merged the conflict streamling branch, as expected there are conflicts with disconnect-hooks
<kenvandine> not sure those are interesting
<ogra_> probably a combo of loop and squashfs
<kenvandine> andyrock, what do you think?
<andyrock> kenvandine: I say that to filter snaps we need to extend the filter
<andyrock> let me check for the others
<ogra_> it will get really bad if you start having layouts too ...
<kenvandine> maybe we can filter all squashfs
<andyrock> kenvandine: btw the proposed upstream fix it this: https://gitlab.gnome.org/GNOME/libgtop/merge_requests/2
<kenvandine> the real use case for gnome-system-monitor is to see how much snap you have left
<kenvandine> s/snap/space :)
<pstolowski> pedronis: right. thanks
<zyga> kenvandine: because a snap runs with pivot root and many things in the mount namespace are different
<zyga> You will also find that the x- mount options are stored in a file in user space
<ogra_> i'm not so sure "nodev" is  good filter ... tht just tells that char and block devices *inside* the filesystem should be ignored
<zyga> And that file is off when looked at from inside a snap
<ogra_> you will also have it by default on nfs mounts or samba shares ..
<zyga> So libmount will not return those flags
<ogra_> (and i think udisks also sets it by default for everything it automounts under /media ... )
<Chipaca> pedronis: https://pastebin.ubuntu.com/p/YfPFpgQdDw/
<Chipaca> or maybe mvo
<Chipaca> dunno
<Chipaca> :-) just rfc as to whether that is too informal
<Chipaca> and, i need to go get the boys
<Chipaca> ttfn
<ogra_> tma !
<ogra_> (too many acronyms)
<kenvandine> :)
<mvo> Chipaca: nice
<mvo> Chipaca: ttfn
<mvo> zyga: running
<zyga> thanks
<mvo> zyga: running your python code
<zyga> note that the patch includes support for sd_notify use inside the service
<zyga> but it should be fully optional
<mvo> zyga: ok
<andyrock> zyga: is /proc/filesystems visible inside a snap?
<zyga> yes
<zyga> though confinement may block it
<zyga> so it's there (/proc, /sys and /dev are)
<zyga> but apparmor and device cgroups prevents access to arbitrary parts of it
<thresh> so uh
<thresh> how do I go about moving the publisher rights for the snap to a different account?
<thresh> as opposed to granting another account publisher rights
<thresh> we (VLC) originally used our supreme leader's account to publish it, and then he granted me publish rights
<timothy> hi, I have a problem to generate any snap:
<timothy> Err http://security.ubuntu.com/ubuntu bionic-security/main DEP-11 64x64 Icons
<ogra_> thresh, i think you need to file a post under the store category in the forum
<timothy>   Hash Sum mismatch
<ogra_> thresh, there should be a documented way (also in the forum)
<thresh> thanks ogra_
<ogra_> thresh, and while i have you here ... would it be possible to have an armhf build of vlc (i'm recently working on kiosk images for arm boards and having a vlc snap would be really helpful)
<thresh> we don't have hardware for that
<ogra_> well, i'd be fine with just having it switched on in build.snapcraft.io ... or do you use your own buuld infra ?
<thresh> yes, we build the snaps on our infra
<ogra_> ah, k
<popey> or launchpad could mirror it
<popey> and build _only_ the armhf build
<ogra_> yeah
<thresh> also I've just checked and kde neon repos (which we use to get newer Qt) dont have armv7/aarch64 packages
<ogra_> ah, ouch
<mvo> cachio: welcome back!
<thresh> *maybe* when we switch to 1804 core...
<zyga> core18
<zyga> cachio: hey :)
<thresh> right
<thresh> I would very much like not to depend on anything external to ubuntu repos, but that's impossible at the moment
<Chipaca> mvo: 5522 merged, was a single commit
<Chipaca> ogra_: dunno if your tma was on purpose or not, but TTFN started at ITMA :-)
<andyrock> zyga: would be possible to get /run/mount/utab visible inside a snap?
<andyrock> in this way we could mount all the squashfs with a x- user option
<andyrock> and the snap can read /run/mount/utab in order to filter out some squashfs
<mvo> Chipaca: thanks, I will cherry-pick it
<mvo> Chipaca: cherry-picked and pushed, thanks again
<zyga> andyrock: yes but note that it would be not showing the content you expect
<zyga> andyrock: we can meet and discuss this but it's not a trivial problem
<zyga> let me show you some notes
<zyga> https://forum.snapcraft.io/t/namespace-awareness-of-run-mount-utab-and-libmount/5987/5
<cachio> mvo, these are some results for 2.34 https://paste.ubuntu.com/p/Rmxw9t2NF6/
<zyga> mvo: hey, can you add to 2.34.1 a patch that fixes CUDA
<zyga> ah, please ignore me, they are out
<mvo> cachio: looking, thank you
<cachio> mvo, oood, I am checking 32 bits right now
<andyrock> zyga: regarding the private utab file proposed here https://forum.snapcraft.io/t/namespace-awareness-of-run-mount-utab-and-libmount/5987/5, would it show all the squashfs e.g.  (/etc/ssl, /var/lib/sudo, etc.) ?
<zyga> andyrock: we really don't know
<zyga> I'd rather not do that
<zyga> because we have no sane way of keeping that file correct now
<pstolowski> https://github.com/snapcore/snapd/pull/5433 needs 2nd review and is simple
<mup> PR #5433: interfaces/repo: added AllHotplugInterfaces helper <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5433>
<zyga> pedronis: thank you for the review of the remapper
<zyga> I will address the comments
<zyga> I'm super excited to see this land
<pedronis> zyga: I think mvo is workong on it as well
<zyga> yes, we just talked about it, mvo needs to work on release bits for a sec
<zyga> and I have a moment before the next session
<mvo> pedronis: just looking at 2.34 test failures, annoying :/
<zyga> gustavo just mentioned
<pedronis> ah
<zyga> we have 17 days for core18
<zyga> so ...
<zyga> I pushed an update to the remapping branch
<zyga> just one comment left
<mvo> zyga: ta
<zyga> we need to use the configstate.RemapToResponse in a few places
<zyga> adding those now
<mvo> cachio: looking at your failure list now, I think    - external:ubuntu-core-16-64:tests/main/snap-interface  and     - external:ubuntu-core-16-64:tests/regression/lp-1721518  should be fixed with pr 5525
<zyga> and pushed now
<mup> PR #5525: tests: cherry-pick test fixes from master for 2.34 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5525>
<zyga> mvo: it's ready
<zyga> I'll resume signal work
<mvo> zyga: yay, I will check in 5min or so, just going over some more failures
<mvo> zyga: thanks for that!
<zyga> sure :)
<cachio> mvo, yes
<cachio> mvo, thanks for this
<cachio> I'll take a look after lunch
<mvo> cachio: maybe also the catalog-refresh, just pushed a cherry-pick
<mvo> cachio: I think the prepare-image-uboot one is just a slow network, so hopefully (if 5525 passes) we will be green
<mvo> again :)
<cachio> mvo, yes
<zyga> mvo: DOH
<zyga> I'm such a moron :)
<zyga> mvo: I know why the python version fails
<zyga> because it doesn't have the file trigger
<cachio> prepare-image-uboot used to faile because of network slowness
<mvo> zyga: oh, of course, racy
<mvo> cachio: yeah, cool
<zyga> so I'll propose a python version
<mvo> cachio: almost done then I think
<zyga> with the file "notification"
<mvo> zyga: thank you
<zyga> and that should be good
<cachio> mvo, yes, for 32 bits we have the same issues, so it should be fixed for free
<zyga> mvo: do you want me to propose that fix in a separate PR or roll it into PR 5410
<mup> PR #5410: tests: update tests to work on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5410>
<mvo> zyga: it sounds like a separate is ok
<zyga> doing that now
<pedronis> zyga: mvo: 5491 still needs a 2nd review
<zyga> mvo: pushed https://github.com/snapcore/snapd/pull/5526
<mup> PR #5526: tests: fix raciness in stop mode tests <Created by zyga> <https://github.com/snapcore/snapd/pull/5526>
<zyga> pedronis: ack
<zyga> mvo: I updated 5410 with explanation about the raciness
<zyga> we have lunch now so I'll check back later
<mvo> zyga: ta
<razer2> The snap for Spotify does not run on Debian.
<cachio> niemeyer, https://forum.snapcraft.io/t/how-to-deploy-spread-gce-gleaner/6422
<cachio> please ping me in case something else is needed
<mvo> 5525 needs a review, all cherry-picks so should be trivial
<mvo> (cherry-picks to 2.34)
<pedronis> 5527 needs to be tagged core18 ?
<mvo> cachio: new 2.34.1 beta will be ready soon (next 1h)
<mvo> pedronis: yes
<pedronis> mvo: did you backport 5522 ?
<mvo> pedronis: yes, cherry-picked it directly
<pedronis> I see it now
<pedronis> sorry
<zyga> can someone please review https://github.com/snapcore/snapd/pull/5521
<mup> PR #5521: snap-confine: mount internal tooling even for the core snap on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5521>
<zyga> mvo: are you wrapping up for today?
<zyga> MATCH failed again
<zyga> man
<cwayne> mvo: and this beta will have that canbus interface PR?
<zyga> cwayne: yes
<zyga> it does
<cwayne> yay :)
<cwayne> jhodapp: ^
<mvo> zyga: not yet
<mvo> cwayne: yes
<mvo> cwayne, cachio new beta should be ready in ~30min or so
<cachio> mvo, waiting ifor this to validate it
<niemeyer> cachio: Thanks!
<cwayne> mvo: will keep an eye out, thanks
<cachio> niemeyer, yaw
<mvo> thanks guys
<mvo> cachio, cwayne 2.34.1 ready in beta
<cachio> mvo, already downloading inmages
<cwayne> mvo: already testing :)
<mvo> cwayne: \o/
 * cachio afk
<jhodapp> cwayne, woohoo!
#snappy 2018-07-18
<pstolowski> morning
<mvo> hey pstolowski, good morning
<mvo>  
<Chipaca> moin moin
<Chipaca> ...rude.
<mvo> Chipaca: hey good morning!
<mvo> Chipaca: rude?
<Chipaca> mvo: joke about somebody leaving without a word just after I said hello
<mvo> haha
<Chipaca> mvo: do you ready z_yga's "+1 but" as an actual +1, i.e. can I merge #5524?
<mup> PR #5524: cmd/snap: check for typographic dashes in command <Created by chipaca> <https://github.com/snapcore/snapd/pull/5524>
<Chipaca> read*
<Chipaca> mvo: also, did we reach a consensus on the flag to watch for "do not error if none found"? I know we agreed it wasn't --oknodo :-)
<Chipaca> was thinking of --no-error-on-empty taking a page from xargs, but it does seem a bit verbose
<Chipaca> alternatively, and perhaps more naturally given the flag is only for use with --last, we could add syntax to --last, e.g. Â«--last=foo?Â» vs Â«last=fooÂ»
<mvo> Chipaca: I'm not great with names but --no-error-on-empty seems to be ok (yes verbose but). alternatives might be "--empty-ok"
<mvo> Chipaca: I like "foo?"
<mvo> Chipaca: not sure about zygas +1, but he should be online soon(ish)
<Chipaca> sorted :-)
<mvo> Chipaca: ta
<Chipaca> mvo: ah, i thought they were further west
<mvo> Chipaca: its 6h from here, so I would expect (jetlag and all that) in ~2h
<zyga> 4am-orning
 * ogra_ grumbles about his kiosk app being rejected because of missing .desktop file ... how pointless
<Chipaca> hehe
<Chipaca> zyga: morning
<Chipaca> zyga: we were just talking about you and jetlag
<Chipaca> ogra_: wat?
<Chipaca> ogra_: what's rejecting your app because of that?
<zyga> Store Review tools
<zyga> How are you guys doing?
<ogra_> yeah ... it uses an x11 loopback interface to itself ... the review tools block if you dont have a .desktop file when this interface is found
<Chipaca> zyga: in #5224, does your "+1 but" mean an actual +1?
<Chipaca> wait
<Chipaca> zyga: #5524
 * Chipaca kicks mup
<zyga> Mup is partially off
<ogra_> jetlag
<zyga> Chipaca: that depends, if you agree then you can tweak the feature, if you donât you can treat my review as +1
<Chipaca> zyga: I disagree (explained a bit why on the pr)
<zyga> Ok
<Chipaca> zyga: (also i brought this other approach up with Juanreal before implementing it)
<zyga> I havenât read that yet
<mup> PR #5224: interfaces: remove Plug/Slot types <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5224>
<mup> PR #5524: cmd/snap: check for typographic dashes in command <Created by chipaca> <https://github.com/snapcore/snapd/pull/5524>
<zyga> mvo: how is core18?
<mvo> zyga: mostly happy, the snap-stop-mode test was still racy though, looks like output related, I added marker files and with that I got no failures yet (running with -repeat 100)
<mvo> zyga: the integration PR is failing with what looks like unrelated issues
<zyga> Thank you! That is good news
<mvo> zyga: I am discussing kernel track names right now, I added you to the mail thread and maybe you can ask Gustavo to have a look so that we can make a decision. its one of the blockers for the model assertion for core18
<zyga> How about the core18 snapd hosting  slots?
<mvo> zyga: you mean 5527? or something else?
<zyga> Yes
<Chipaca> snap set system refresh.hold=+2h
<zyga> I saw it was red
<Chipaca> why can't we do that :-)
<zyga> Didnât check deeper yet
<pedronis> Chipaca: the plan is to have a command to do that sort of stuff, was blocked on deciding how to call it and the fact we have too many commands
<Chipaca> pedronis: I could add it to corecfg (if we ignore that the function is called 'validate' and not 'validate-and-normalise'
<Chipaca> )
<pedronis> please don't
 * Chipaca quietly does 'git reset --hard'
<mvo> zyga: aha, indeed, its red because settle is not converging
<mvo> zyga: we need to either fake the production snapd id
<mvo> zyga: or add the test snapd-id to the detection if its the snapd snap, we had this issue before I think
<zyga> Ah, I remember now
<zyga> Can you patch that in some acceptable way
<zyga> Iâd love to say âwe can boot core18 and it worksâ
<mvo> zyga: I can add a patch, we will see if that is "acceptable" ;)
<mvo> zyga: just working on the sru for 2.34.1 will do in a little bit
<zyga> Thank you :-)
<zyga> Ok
 * Chipaca steels himself to go to the dentist
<zyga> mvo: feedback from the field: we should have a workflow where developers can copy a new kernel, snap install it and reboot
<mvo> zyga: to test new kernels?
<zyga> currently that doesn't work and requires time-consuming workarounds or use of ubuntu classic
<zyga> yes
<zyga> to do kernel development
<zyga> (driver etc)
<mvo> makes sense, we have some restrictions here currently mostly to avoid users doing strange things
<zyga> mhm
<zyga> maybe just --dangerous --very
<zyga> or something like this
<pstolowski> --scary
<zyga> --I-know-what-you-did-last-summer
<pstolowski> zyga: how is the sprint going?
<zyga> very good so far
<zyga> we have one interesting thing that was discussed yesterday evening
<zyga> we will change how refresh works
<zyga> I will share all the details later today/tomorrow (as time permits)
<zyga> it will involve a new hook as well
<pstolowski> interesting
<pstolowski> pedronis: RFC - https://github.com/snapcore/snapd/pull/5532
<mup> PR #5532: api/connect: report "nothing to do" if attempting to re-connect <Created by stolowski> <https://github.com/snapcore/snapd/pull/5532>
<pedronis> pstolowski: mmh,   that's a change of behavior
<pedronis> I think the old code just did nothing, not an error
<pstolowski> pedronis: indeed, the old code would just do nothing in the handler, but created the change etc.
<pedronis> pstolowski: we have  a similar case already
<pedronis> pstolowski: we do this:   https://github.com/snapcore/snapd/blob/master/daemon/api.go#L1436 but I think Connect shoudl return either an empty ts or some kind of error
<pedronis> to trigger that behavior
<pstolowski> pedronis: yes i considered empty ts, but wasn't sure a dummy change with 'done' status was a good idea (forgot we have a case already)
<pstolowski> pedronis: okay, i will do it that way then
 * Chipaca lunch
<Chipaca> hmm, clearing refresh.hold with "" seems to be broken
<Chipaca> 2018/07/18 12:48:39.556782 stateengine.go:101: state ensure error: internal error: cannot unmarshal snap "core" option "refresh.hold" into *time.Time: parsing time """" as ""2006-01-02T15:04:05Z07:00"": cannot parse """ as "2006", json: ""
<Chipaca> hmm
 * ogra_ curses loudly ... 
<ogra_> the damned review tools are making me mad today
<popey> Don't get mad, get even.
<ogra_> i think i tried evyery possible way to ship a pointless .desktop file for my kiosk daemon app now
<ogra_> but they all got rejected
 * ogra_ has no idea how to proceed with that
<ogra_> snap/gui/ doesnt work, specifying it in snapcraft.yaml and shipping it doesnt ... not sure what else to try
<popey> why not just put a valid desktop file?
<ogra_> ?
<popey> youre talking about a "pointless" desktop file
<popey> why don't you do what we do for every other snap and put a valid one in there
<ogra_> well, i use an IMHO valid file
<ogra_> the point is that this is a daemon
<ogra_> it doesnt need a desktop file since it cant be run from it
<popey> can I see the project/yaml/desktop file?
<ogra_> https://github.com/ogra1/xdmcp-client
<popey> i always put the desktop file in snap/gui/foo.desktop
<ogra_> (i originally shipped it in snap/gui, just moved it arouond to toplevel and defined it via deskto: )
<popey> and never mention it in the yaml
<popey> it gets automatically found
<ogra_> yes
<ogra_> thats what  did first
<ogra_> *I
<popey> your icon path is invalid
<popey> in the desktop file
<popey> put .desktop and .png in snap/gui, and make sure they are both called <snapname>.*
<ogra_> yeah, now it is :( ... (wasnt when it was in snap/gui
<ogra_> 9
<ogra_> thats what i had in the former revision ...
<ogra_> like in all other desktop snaps i create ...
<ogra_> but that just caused the very same review error
<ogra_> popey, https://github.com/ogra1/xdmcp-client/tree/c70eafedf3ea751730677a843782f567d7c2d816 was my last revision
<popey> filename is wrong
<popey> for the icon, make it xdmcp-client.png
<ogra_>  <snapname>.desktop
<popey> and refer to it as such in the desktop file
<ogra_> well, icon.png works for all other desktop snaps i have ... but happy to try
<niemeyer> mvo, nessita: Heya
<popey> you can run the snap review tools locally to test it
<popey> rather than do the store turn around time
<niemeyer> snap info on snaps published by canonical is showing that long email address instead of snaps@canonical..
<niemeyer> nessita: What do we need to do to fix that?
<nessita> niemeyer, we should reindex the snaps, let me do that
<niemeyer> nessita: Thanks!
<nessita> niemeyer, have an example of a snap showing the wrong email address?
<zyga> nessita: core
<nessita> zyga, I see. That's the contact url of a snap which is set by the publisher and is not automatically changed when SSO profile data changes
<popey> https://snapcraft.io/core could do with a metadata update too! as could https://snapcraft.io/canonical-livepatch
<ogra_> the core text came originally from mark FWIW
<ogra_> (i had a way longer text for the initial uploads)
<popey> That was when we only had "snap info" though, the web store needs more text to make it look compelling.
<Chipaca> not sure core needs to be compelling :-)
<nessita> zyga, niemeyer I filed an RT to have the contact_url changed for every snap
<ogra_> popey, true
<popey> people link to it, it needs more than one line
<ogra_> popey, so ... whatever i try i still get the same denial even with local review-tools
<ogra_> ogra@acheron:~/Devel/xdmcp-client:master$ review-tools.snap-review xdmcp-client_0.1_amd64.snap
<ogra_> Errors
<ogra_> ------
<ogra_>  - declaration-snap-v2:slots_deny-connection:xephyr:x11
<ogra_> 	human review required due to 'deny-connection' constraint for 'on-classic' from base declaration
<popey> thats not the same error
<popey> that's not a desktop file issue
<ogra_> (actually it doesnt look like the desktop file thing at all that i get by mail)
<ogra_> no
<popey> one for jamies
<ogra_> the desktop file is what i got by mail from the review
<ogra_> popey, hmm
<ogra_> ogra@acheron:~/Devel/xdmcp-client:master$ review-tools.snap-review xdmcp-client_0.1_amd64.snap
<ogra_> Errors
<ogra_> ------
<ogra_>  - declaration-snap-v2:slots_deny-connection:xephyr:x11
<ogra_> 	human review required due to 'deny-connection' constraint for 'on-classic' from base declaration
<ogra_> err
<ogra_> one sec, wrong paste
<ogra_> The reviewer provided the following feedback:
<ogra_> desktop interfaces (x11) specified without a corresponding meta/gui/*.desktop file. If using snapcraft, please see https://snapcraft.io/docs/build-snaps/metadata#fixed-assets. Otherwise, please provide a desktop file in meta/gui/*.desktop (it should reference one of the &#39;apps&#39; from your snapcraft/snap.yaml)
<ogra_> thats what i get by mail ...
<mup> PR #39: Login integration test closes #38 <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/39>
<ogra_> seems slightly contradicting to what the review tools tell
<ogra_> popey, is there a way to find out who did the manual review ?
<ogra_> https://dashboard.snapcraft.io/snaps/xdmcp-client/revisions/12/review/ would be one that caused the mail
<popey> Jamie
<ogra_> oh, yeah, i didnt know i could open that link even !
<ogra_> heh
<ogra_> well, the tools definitely reject it because the app needs to declare a " slots: [ x11 ]" in the apps: section
<ogra_> (to provide an x11 loopback interface for using XWayland under mir-kiosk)
<ogra_> geez .... i didnt expect that to be this complicated ....
<ogra_> yay ... new technology :)
 * ogra_ updates https://forum.snapcraft.io/t/review-tools-forcing-desktop-file-for-kiosk-apps/6436
<Chipaca> ogra_: "i didnt expect that to be this complicated" --napoleon, somewhere around sepember 1812
<kjackal> hi everyone. I am a bit confused. Is it possible to have the launchpad builders build and release snaps on a few different tracks? Can we have lp builders build from branch A and release to track A and at the same time have other(?) builders build from branch B and release to track B?
<roadmr> hello folks, there's currently an outage in the snap store, we're working to solve it, I'll update when it's fixed
<kjackal> I may be missing some button
<Chipaca> kjackal: I thought the builders only released to [foo?]/edge
<Chipaca> kjackal: but https://docs.snapcraft.io/build-snaps/ci-integration seems to imply you should be able to choose branches
<Chipaca> oh wait
<Chipaca> those are lp branches :-)
<Chipaca> kjackal: but in that same page, step 11
<kjackal> I think I understand it now. I have to start with the branch on LP and then create the builders. let me try that
<roadmr> store outage should now be resolved, thanks for your patience
<pstolowski> pedronis: if you have some time for reviews, https://github.com/snapcore/snapd/pull/4940 needs re-reviewing; and i'm waiting for spread test run of #5532
<mup> PR #4940: overlord: added UDevMonitor for future hotplug support <Created by stolowski> <https://github.com/snapcore/snapd/pull/4940>
<mup> PR #5532: api/connect: ignore connect if already connected <Created by stolowski> <https://github.com/snapcore/snapd/pull/5532>
<ogra_> Chipaca, lol
<pedronis> Chipaca: hi, could you look at #5515
<mup> PR #5515: daemon: make sure most change generating handlers can produce errors with kinds <Created by pedronis> <https://github.com/snapcore/snapd/pull/5515>
<Chipaca> pedronis: looking
<zyga> how are things going?
<zyga> or doing actually
<oSoMoN> I've added plugs for gtk-3-themes, icon-themes and sound-themes to the libreoffice snap like was done for a bunch of gnome app snaps, but I'm getting the following error and don't know what's causing it:
<oSoMoN> main.go:192: cannot change mount namespace of snap "libreoffice" according to change mount (/snap/gtk-common-themes/319/share/icons/Adwaita /snap/libreoffice/x1/data-dir/icons/Adwaita none bind,ro 0 0): cannot create writable mimic over "/snap/libreoffice/x1": permission denied
<oSoMoN> can anyone enlighten me?
<Chipaca> pedronis: youch
<oSoMoN> (this is what IÂ added to snapcraft.yaml: https://git.launchpad.net/~libreoffice/+git/libreoffice-snap/commit/?id=0e58538d71af93eef00c6d73b7767a548208e30d)
<oSoMoN> and the bug report with all the details is https://github.com/ubuntu/gtk-communitheme/issues/350
<zyga> oSoMoN: hey
<zyga> oSoMoN: can you share the snap yaml's of the two snaps and the output of "dmesg | grep DENIED" please
<zyga> oSoMoN: also snap version but I suspect you are just on the latest stable
<oSoMoN> zyga, snapcraft.yaml: https://git.launchpad.net/~libreoffice/+git/libreoffice-snap/tree/snap/snapcraft.yaml?h=6.0
<oSoMoN> $ snap version
<oSoMoN> snap    2.33.1
<oSoMoN> snapd   2.33.1
<oSoMoN> series  16
<oSoMoN> ubuntu  18.04
<oSoMoN> kernel  4.15.0-23-generic
<zyga> ok
<zyga> oSoMoN: can you tell me if $SNAP/data-dir/{themes,icons,sounds} all exist in the snap?
<zyga> I assume they don't
<oSoMoN> zyga, they don't
<zyga> ok
<zyga> please share the denial
<zyga> and /var/lib/snapd/apparmor/profiles/snap-update-ns.libreoffice from the affected machine
<oSoMoN> zyga, there are multiple denials, most of them are similar to this:
<oSoMoN> juil. 18 16:17:04 bribon audit[4274]: AVC apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.libreoffice" name="/tmp/.snap/snap/libreoffice/69/" pid=4274 comm="3" srcname="/snap/libreoffice/69/" flags="rw, rbind"
<oSoMoN> zyga, https://paste.ubuntu.com/p/HhXgw52vzY/
<zyga> ok
<zyga> this is https://github.com/snapcore/snapd/pull/5395
<mup> PR #5395: interfaces: generalize writable mimic profile <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5395>
<zyga> I will try to land this branch
<zyga> as a workaround please create, inside the libreoffice snap, the data-dir/
<zyga> then the rest should work
<zyga> it's the extra level of nesting that is breaking this
<Chipaca> pedronis: is sideloadCheck just moved?
<oSoMoN> zyga, thanks! I'll test creating the data-dir/ inside the snap
<oSoMoN> I wonder why this is working for other snaps, like evince or gedit, though
<oSoMoN> those don't have a data-dir/ directory either
<zyga> I don't know
<zyga> I will study the rules you gave me to see if this is the same thing I think for sure
<oSoMoN> thanks!
<zyga> oSoMoN: please let me know if this works for you
<oSoMoN> zyga, yes, I'm repacking the snap with an additional data-dir/ directory, will let you know
<zyga> oSoMoN: thank you
<zyga> you can just unsquash it, mkdir and snap pack it
<oSoMoN> zyga, yep, that's what I did
<oSoMoN> but same error
<oSoMoN> I verified that $SNAP/data-dir exists after installing
<zyga> can you be more specific please, what is the error you are getting now
<oSoMoN> cannot create writable mimic over "/snap/libreoffice/x1/data-dir": permission denied
<zyga> that is more curious
<zyga> hold on
<zyga> well, add the extra three directories and that will go away
<zyga> but I really need to get to the bottom of this
<oSoMoN> ok, adding those
<zyga> and please dmesg the denial that you saw now
<oSoMoN> AVC apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.libreoffice" name="/tmp/.snap/snap/libreoffice/x1/data-dir/" pid=8248 comm="3" srcname="/snap/libreoffice/x1/data-dir/" flags="rw, rbind"
<zyga> thank you
<pedronis> Chipaca: yes
<oSoMoN> repacking with all three directories now, let's see if that works
<Chipaca> pedronis: ah yes i edited locally to confirm :-)
<Chipaca> pedronis: before +1'ing it (without the edit it would've taken me a lot longer to review)
<pedronis> Chipaca: was moved far for some reason from either it's first or last usage
<pedronis> so IÂ moved it
<zyga> ah
<zyga> I know why it didn't help
<pedronis> Chipaca: that test file is too long (tm) :(
<zyga> but it's still that bug
<Chipaca> pedronis: as is api.go itself
<zyga> oSoMoN: the reason is that gtk-common-themes is actually exportng a number of items that are nested themselves
<zyga> the branch I referenced fixes this but, as I said, it's on me to land
<oSoMoN> zyga, I can confirm that creating the missing dirs works around the issue
<abeato> jdstrand, mind taking a look at https://github.com/snapcore/snapd/pull/5469 when you can?
<mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
<zyga> oSoMoN: thank you
<mvo> zyga: pr#5533  allows creating images with the new kernel-track feature of the model assertion. if Gustavo has a free minute it would be great to get his opinion on what kernel track name to pick. having one soon would be really great, then I can start writing an integration test
<mvo> hm, no mup currently?
<cachio> zyga, https://paste.ubuntu.com/p/BQHWShC7Zv/
<cachio> I see these denials executing a test for daemon-notify interface
<cachio> zyga, any idea why it could be happening
<cachio> =
<zyga> cachio: yes, it is not auto-connected
<zyga> you have a slot but it's not connected
<cachio> zyga, I manually connected it
<zyga> I wrote a thread about this on the forum
<zyga> it's too late
<zyga> you cannot connect it fast enough
<zyga> well
<zyga> I'd have to see your test service
<zyga> but in general you cannot use that from non-service started by systemd
<zyga> and you cannot connect it fast enough
<zyga> so in practice it's not really usable
<zyga> please read my forum post about this
<zyga> https://forum.snapcraft.io/t/its-a-little-bit-hard-to-use-daemon-notify-for-sd-notify/6366
<zyga> mvo: the github part of mup is off because of the github availability issue
<cachio> zyga, what I did is to connect it and the install it again
<cachio> zyga, but same issue
<zyga> that doesn't help
<zyga> it's not auto-connected
<zyga> because the install would likely fail
<zyga> because the daemon: notify cannot be installed without successfully talking to systemd
<zyga> can you show me the test please
<cachio> zyga, https://paste.ubuntu.com/p/rkf8VXVg5K/
<cachio> https://paste.ubuntu.com/p/wrmrZz2rNY/
<zyga> ok, and what did you expect to happen?
<cachio> zyga, I am checking logs to see I there is any denial
<cachio> zyga, still doing it manually
<zyga> the interface is not auto-connected so as soon as you start the service it is attempting to use a program it cannot use
<zyga> you can connect it
<zyga> restart the service
<zyga> but then it may not work _anyway_ depending on what systemd does
<cachio> ok
<zyga> if it allows you to talk over the socket (separately from our permission)
<cachio> zyga, I'll try that, thanks
<thiras> hello
<thiras> discord and spotify are broken
<thiras> $ snap run discord
<thiras> ln: failed to create symbolic link '/home/thiras/snap/discord/69/.config/gtk-2.0/gtkfilechooser.ini': File exists
<thiras> Gtk-Message: Failed to load module "gail"
<thiras> Gtk-Message: Failed to load module "atk-bridge"
<thiras> ubuntu 18.04
<jdstrand> abeato: yes. it is on my list. I looked at it and am ok with the approach, but I wanted to check a few things before giving my ack. I apologize for the delay. I've been meaning to get to it and am sprinting this week
<thiras> spotify has quite similar error log
<cachio> zyga, I have updated the PR #5535
<mup> PR #5535: tests: fix tests expecting old email address <Critical> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5535>
<zyga> cachio: I saw just now, thank you!
<cachio> zyga, np
#snappy 2018-07-19
<pstolowski> mornings
<mvo> hey pstolowski
<pstolowski> #5474 needs a 2nd review, would be great to land it
<mup> PR #5474: many: finish sharing a single TaskRunner with all the the managers <Created by pedronis> <https://github.com/snapcore/snapd/pull/5474>
<mvo> pstolowski: I have a look in a bit
<pstolowski> ty
<pstolowski> mvo can #5535 land, or is there more to it?
<mup> PR #5535: tests: fix tests expecting old email address <Critical> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5535>
<Chipaca> buenos dÃ­as, gente
<mvo> pstolowski: it can land, I fixed this 2h earlier but for some reason my PR was not visible, oh well
<mvo> pstolowski: s/not visible/not reviewed/
<mvo> pstolowski: if merged, please squash, we need it for the sru
<pstolowski> mvo: yep, noticed that..
<mvo> Chipaca: hey, good morning
<pstolowski> ouch, i merged a second ago, but not squashed
<pstolowski> sorry about that
<mvo> pstolowski: no worries, its just three commits so not a big deal
<Chipaca> hmm
<Chipaca> I've got a question about #5535
<mup> PR #5535: tests: fix tests expecting old email address <Critical> <Simple> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5535>
<Chipaca> why the unknown|unset change?
<Chipaca> that one's wrong
<Chipaca> and backwards
<pedronis> pstolowski: thanks for the review
<mvo> Chipaca: unset is the new one right?
<Chipaca> yes
<Chipaca> there should be nothing saying 'unknown' now, ever
<Chipaca> if there is, it's a bug
<mvo> Chipaca: did the server side sent it?
<mvo> Chipaca: or is this entirely local?
<Chipaca> mvo: server side sends "unset"
<mvo> Chipaca: sounds like we need a PR then that removes the unknown
<Chipaca> mvo: for local snaps with no set license snapd sent "unknown" until #5508
<mup> PR #5508: cmd/snap: print unset license as "unset", instead of "unknown <Simple> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5508>
<Chipaca> mvo: so I'm asking, before just pushing the PR to do it, because it was unset and obviously something broke, I need to understand what broke :-)
<Chipaca> i mean, i doubt cachio made the change just for fun
<pedronis> when was this?   is this related to the reindex or was from before?
 * pedronis is going to spend the morning on reviews
<Chipaca> pedronis: same pr as the email change
<pedronis> ah
<pedronis> maybe something is broken in the store and the reindex put unknown in places again?
<Chipaca> nope
<Chipaca> unless this is the fake store?
<Chipaca> the actual store is sending "Other Open Source"
<Chipaca> which wouldn't mach either of those :-)
<pedronis> mmh
<pedronis> yes
<pedronis> this is test-snapd-tools ?
<Chipaca> core, test-snapd-tools, and test-snapd-devmode
<pedronis> Chipaca: core says unknown here
<Chipaca> pedronis: where and how?
<pedronis> snap info core
<pedronis> with beta
<pedronis> IÂ mean 2.34.1
<Chipaca> pedronis: #5508 is recent,  probably only edge
<mup> PR #5508: cmd/snap: print unset license as "unset", instead of "unknown <Simple> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5508>
<pedronis> Chipaca: ah, but cachio is doing an SRU,  so it needs still the unknown
<Chipaca> merged 3 days ago
<Chipaca> pedronis: on master?
<pedronis> I'm not quite sure how is running things
<pedronis> no clue
<Chipaca> yeah
 * Chipaca grumbles some more
<Chipaca> anyhow
<Chipaca> pedronis: it's have-another-coffee o'clock
<pedronis> me I'm fininish my first tea
<Chipaca> after that i'll be working on snapshotstate conflicts
<Chipaca> wish me luck :-)
<pedronis> Chipaca: it should be easy
<pedronis> Chipaca: afaiu just use AddAffectedSnapsByAttr
<pedronis> with snapshot-setup
<jamesh> when calling /v2/interfaces?select=connected&plugs=true&slots=true, is it normal that unconnected plugs and slots are returned?
<jamesh> it only seems to filter out interface types that have no connected plugs or slots
<Chipaca> jamesh: I'm not sure. That code was refactored recently, so we might've fudged it
<Chipaca> zyga: ^ jamesh's question is for you I fear
<Chipaca> jamesh: zyga is further west than normal so I wouldn't expect a response for a few hours
<jamesh> Chipaca: Montreal?
<Chipaca> yah
<Chipaca> jamesh: OTOH the refactor is probably only on master (so on edge)
<Chipaca> jamesh: are you talking to edge?
<jamesh> good point.  I'm on edge at the moment.  I'll check stable
<Chipaca> jamesh: even if we didn't change the behaviour it's possible it's wrong :-) i'd be surprised to get unconnected things when i ask for connected ones
<pedronis> mvo: I don't understand the localSnaps change in the kernel-track branch, it seems to be done for all snaps
<jamesh> Chipaca: I want to find out if a particular snap has a connected plug for a particular interface, and didn't feel like sifting through the full list of connections.  This interface looked like it should do what I want, but didn't seem to be doing the filtering
<jamesh> Chipaca: okay.  Stable  (2.33.1) also shows unconnected plugs
<Chipaca> jamesh: so 'snap interfaces -i theinterface thesnap', but via the api?
<mvo> pedronis: hm, let me double check, maybe there is a test missing :(
<pedronis> mvo: did you forget to check that the snap name is the kernel name?
<mvo> pedronis: yes, silly me. plus a test is missing that should have failed, let me check why this is not failing, I thought I had checked for the channel
<jamesh> Chipaca: that command does client side filtering.  I was thinking of doing the equivalent of "snap interface pulseaudio" and then checking checking if the snap in question was listed as a plug
<pedronis> pstolowski: I tried to answer your doubt
<mvo> pedronis: aha, there is a test for two local snaps missing, let me fix that
<jamesh> that's "interface" rather than "interfaces"
<Chipaca> jamesh: ah, right, interfaces is the old one
<Chipaca> (what you get with select="")
<Chipaca> jamesh: looks like a bug to me
<Chipaca> jamesh: I have both vlc and firefox snaps, neither of which are connected to camera, yet 'snap interface camera' lists them
<Chipaca> jamesh: whereas i'd only expect them to appear under 'snap interface --all camera'
<jamesh> Chipaca: I'd expect them to show with select=all and not with select=connected
<jamesh> yeah
<Chipaca> exactly
<Chipaca> so, yeah, this looks like a bug to me
<Chipaca> also the output with --all should probably say connected/disconnected
<jamesh> The json doesn't currently tell you about the connection state, or what they are connected to
<jamesh> it'd kind of be nice if one of the output formats clearly had a superset of the data of the other
<mvo> pedronis: thanks again, fix pushed, can't wait to write integration tests for this
<Chipaca> jamesh: want to raise that last point in the forum?
<jamesh> Chipaca: sure.
<Chipaca> jamesh: I know niemeyer had Opinions about this, but I'm not sure the current interface command is that, or if there was going to be a connections command
<Chipaca> popey: is somebody working on a new minecraft snap?
<Chipaca> popey: (because I'm going to be asked for it this weekend)
<popey> @Chipaca looked at it last night, and mentioned to @Wimpress as I am on vacation starting today. he said he'd look at it if he gets time. Looks simple enough to dump the deb into a snap
<popey> we could put it in edge on the minecraft name
<Chipaca> popey: there's a deb now?
<popey> but need to test that it migrates from old minecraft to new properly
<popey> yes
<popey> its a chromium embedded (electron like) app
<Chipaca> saw that in the tarball, but didn't see a deb
<Chipaca> anyway, good to know
<Chipaca> popey: enjoy your holidays and your vacationdays
<popey> thanks. give Wimpress a nudge later when he's online
<popey> :)
<pedronis> mvo: not urgent, there's a couple of mispellings of "topic" in the roadmap entry for 2.34 in the forum
<mvo> pedronis: thank you, will fix in a bit
<ogra_> hmm, does aynone know if layouts can be used on top of dirs that are imported via a content interface ?
<ogra_> (i wonder if the ordering allows that)
<pedronis> mvo: 5533  looks good but I think it could be simplified a bit further
<pedronis> mvo: let me know if the comment/proposal are unclear
 * Chipaca afk for a while
<popey> Chipaca: should snap pack foo/   create a valid snap?
<Chipaca> popey: snap pack foo/ . should
<popey> it doesnt
<Chipaca> dunno how  good we are with the defaults
<popey> https://www.irccloud.com/pastebin/Q4A7E8gz/
<Chipaca> sigh
<Chipaca> popey: i'll take a look when i get back
<popey> ok :)
<popey> sorry
<Chipaca> no probs
<popey> shall i file a bug?
<Chipaca> this is part of why we want to have a single way to do this
<Chipaca> popey: please
<popey> on snapd?
<Chipaca> yup
<popey> kk
<popey>  on it
<popey> https://bugs.launchpad.net/snapd/+bug/1782545
<mup> Bug #1782545: "snap pack" doesn't make a valid snap <snapd:New> <https://launchpad.net/bugs/1782545>
<mvo> pedronis: thanks, looking
<pedronis> mvo: btw IÂ think the current code is probably even buggy (it would store the effective channel, instead of the tracking channel in some cases)
<pedronis> (which I don't think is what we want)
<mvo> pedronis: oh, you mean the pre-existing code? I will check that too
<pedronis> mvo: yes,  because we store info.Channel in the side,  but if you ask for some channel that is closed you might get something different
<pedronis> is not relevant if channel is stable anyway, that's why probably nobody noticed
<pedronis> is not a serious bug, but it's conceptually off
<mvo> pedronis: good catch
<mvo> pedronis: I do a fix in a bit
<pedronis> mvo: basically we need to store in seed what we set in dlOpts , not what we got in the info (which then also means the code in localSnaps is not needed)
<pedronis> should simplify a bunch of code, some tests might need re-tweaks
<mvo> pedronis: I will do a separate PR for this
<jamesh> Chipaca: here's the forum post: https://forum.snapcraft.io/t/should-v2-interfaces-select-connected-return-unconnected-plugs-slots/6455
<mvo> pedronis: I looked now and it seems we don't need a separate PR, the changes needed look quite small
<mup> Bug #1619258 changed: netplan should allow NICs to be disconnected and not stall the boot <rls-aa-incoming> <Snappy:Fix Released> <nplan (Ubuntu):In Progress by cyphermox> <systemd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1619258>
<pedronis> mvo: +1 with some small comments
<pedronis> mvo: thanks for the other changes
<mvo> pedronis: thank you, looking and tweaking :)
 * Chipaca wanders off in search of lunch
<zyga> o/
<pedronis> Chipaca: I reviewed the state bits of #5514
<mup> PR #5514: daemon, overlord/state: warnings pipeline <Created by chipaca> <https://github.com/snapcore/snapd/pull/5514>
<Chipaca> pedronis: saw that, thank you
<Chipaca> pedronis: the names of those things were (iirc) taken from the whiteboard, but yeah they're probably not the best
<Chipaca> especially because the lastSeen is from one pov and the lastShown from another
<Chipaca> and they're practically synonymous
<pedronis> yes, Seen doesn't work for me there
<Chipaca> pedronis: also was thinking we could drop the explicit delete method and just expire them on load
<Chipaca> anyway, really must lunch
<pedronis> Chipaca: given that we call the method Add*  maybe s/seen/added/
<pedronis> seems the most explicit
<pedronis> comment in the PR
<pedronis> a 2nd review of #5474  would be great
<mup> PR #5474: many: finish sharing a single TaskRunner with all the the managers <Created by pedronis> <https://github.com/snapcore/snapd/pull/5474>
<mvo> cachio: hey, 2.34.2 is uploaded into trusty,xenial,bionic, we need to do the validation this week for it to make it to 18.04.1
<cachio> mvo, sure
<cwayne> mvo: +1 for beta core
<mvo> cwayne: yay, thank you
<mvo> cachio: -^
<cwayne> mvo: once we get one of these kernel issues on a gateway figured out once and for all it'll go more quickly in the future :)
<cachio> mvo, promoting
<zyga> pedronis: thank you for the review, I'm addressing the comments now
<zyga> mvo: do you have any news on the racy stop mode tests? is that a logging issue at this stage (after all the other fixes?)
<pedronis> mvo: I added some comments to #5537, it looks good overall
<mup> PR #5537: snapstate: ensure kernel-track is honored on switch/refresh <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5537>
<zyga> I addressed stuff on https://github.com/snapcore/snapd/pull/5527 and it just needs a 2nd review
<mup> PR #5527: overlord/ifacestate: support implicit slots on snapd <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5527>
<ogra_> zyga, would layouts work on top of imported dirs from content interfaces (i suspect there might be ordering issues (if a layout symlink gets created before the interface connects etc))
<zyga> layouts are first
<zyga> but we should reject anything that is overlapping already
<zyga> if we don't that's a bug
<ogra_> k, note i didnt try it just asking conceptually
<ogra_> so overlaps arent allowed anyway ... hmm
<zyga> yes
<zyga> mvo: can we talk about https://github.com/snapcore/snapd/pull/5518 quickly?
<mup> PR #5518: systemd: fix snapd.apparmor.service.in dependencies <Created by mvo5> <https://github.com/snapcore/snapd/pull/5518>
<mvo> pedronis: thank you, will work on those
<mvo> zyga: stop mode is logging related but its not fully conclusive yet. my file based fix works for me(tm) as does decreasing the sleep
<mvo> zyga: aha, right, 5518
<mvo> zyga: yeah, lets kill the requiste=
<zyga> thanks!
<zyga> mvo: should we merge the general fixes I did earlier
<zyga> mvo: and then pursue logging separately
<zyga> mvo: or do you want to get to the bottom of the issue entirely
<mvo> zyga: merging your fix is great
<mvo> zyga: it fixes a lot of problems already
<mvo> zyga: and then we can use that to get to the bottom of the issue itself
<zyga> we need a 2nd review on https://github.com/snapcore/snapd/pull/5521
<zyga> Chipaca: ^ perhaps
<mup> PR #5521: snap-confine: mount internal tooling even for the core snap on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5521>
<Chipaca> zyga: ok
<zyga> thank you!
<zyga> Chipaca: please have a look at my comment here https://github.com/snapcore/snapd/pull/5531#pullrequestreview-138710326
<mup> PR #5531: cmd/snap: support `--last=<type>?` to mean "no error on empty" <Created by chipaca> <https://github.com/snapcore/snapd/pull/5531>
<popey> zyga: https://forum.snapcraft.io/t/spotify-doesnt-open-everytime-i-reboot/6460
<ogra_> popey, didnt you say your vacation starts today ? what are you doig here all day ?
 * popey disappears
<ogra_> popey, here ... a poster for you ... https://www.kotzendes-einhorn.de/blog/wp-content/uploads/2014/04/smartwatch.jpg
<ogra_> :)
<popey> I love that image
<zyga> popey: looking
<zyga> ah,
<odc> hi there
<zyga> but after the session
<zyga> hey there odc :)
<odc> question: i have a C++ app that requires C++14 and thus, can only be compiled on ubuntu bionic (doesn't compile on xenial). I have managed to create a .snap from bionic. Will snapcraft.io accept my snap since it doesn not compile on xenial?
<popey> it may accept it but it will likely segfault on user computers
<popey> because it will pull in core (ubuntu 16)
<odc> o.O it won't include the libstdc++ from bionic?
<ogra_> well, depends how you build it ... you would need to override libc and stdc++ an also hack the snapcraft.yaml in a way to get a proper compiler/toolchan
<Chipaca> zyga: responded
<ogra_> *and also hack
<odc> hm, i may be able to compile some libs as static
<ogra_> not sure the ibc/stdc++ overriding works
<ogra_> yeah, that might be ok
<odc> how can i view what files are in my snap?
<ogra_> i fthey are linked into your binary ... but even then you will execute on top of xenial
<ogra_> unsquashfs -ls /part/to/snap
<ogra_> *path
<popey> or look in prime/
<Chipaca> or if you're using snapcraft, look in prime/
<popey> which will be whats in the snap
<popey> sorry
<ogra_> right, if you have the source tree look in prime/
 * popey shuts up and closes irc
<popey> cheerio :)
<ogra_> haha
<odc> cool. thx all
<ogra_> go watch planes :)
 * Chipaca kicks popey off
<Chipaca> some people need help vacationing
<popey> ctrl+q
<odc> apparently, all the libs but libc are included in the snap :)
<odc> gonna test on xenial
<Chipaca> odc: libc is a problem
<Chipaca> odc: but you can force it to be included as well
<Chipaca> (i don't remember how though)
<Chipaca> odc: it's a problem because you'll be getting xenial's libc everywhere, and you built against bionic's, and they have different ABIs
<Chipaca> unless what you managed to do was build on xenial + backported libs, in which case i should shut up
<odc> nope, i build my snap in a docker container
<odc> (with bionic)
<Chipaca> odc: OTOH, you could use base: core18
<Chipaca> odc: in which case you might find bugs in core18 as it's not yet 'ready' :-) but it should work
<Chipaca> odc: (core18 is bionic-based)
<odc> interesting ;)
<odc> and indeed my snap does not work on xenial
<odc> Chipaca: is there documentation for "base"? I don't know where to put it
<pedronis> pstolowski: zyga: the issues with 5532 are IÂ think about not checking for Undesired
<pedronis> there can be an entry in conns that still means the connection is not there
<pstolowski> pedronis: yes i've a fix ready and testing atm
<Chipaca> odc: it goes in the top level (next to 'name:'), but if snapcraft doesn't support it yet you might need to put 'passthrough: base: core18'
<Chipaca> odc: (then once snapcraft supports it it'll let you know to drop it out of passthrough)
<Chipaca> zyga: I just wrote my longest commit message ever, and I'm blaming you
<Chipaca> zyga: (even though most of it was copy-paste of logs :-) )
<odc> Chipaca: it seems to have worked without passthrough
<Chipaca> odc: yay
<odc> it works!
<odc> well, kindof. The gtk theme is ugly and there is no font/text, but i guess that's because of isolation
<Chipaca> odc: that should work though
<Chipaca> odc: the snap should have access to the system's fonts
<Chipaca> well, assuming the right interfaces
<ogra_> just use one of the desktop helpers
<odc> >Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
<ogra_> right, the desktop helpers help with that
<odc> ok
<ogra_> but not sure what happens if you try to use them with "base: core18"
<ogra_> that might badly explode in your face and leave marks ;)
<Chipaca> i'm sure there are gnome snaps using core18, but don't know which ones offhand
<Chipaca> maybe mvo knows
<ogra_> well, the questio is if the package names used by the desktop wrappers are still the same etc
<ogra_> *question
<zyga> pedronis: mmm, interesting observation, I will check
<zyga> Chipaca: *thank you* very much, that really matters
<pedronis> zyga: pawel said he is on it
<zyga> pedronis: perfect, I'm just catching up onw
<zyga> *now
<odc> ok, i added these: plugs: [desktop, home, network, thumbnailer-service, x11]
<odc> now my app can load fonts, but i still get the gdk-pixbuf error and ugly theme
<ogra_> you need to add a desktop helper
<odc> o.O
 * odc looks it up
<ogra_> https://github.com/snapcrafters/wordpress-desktop/blob/master/snap/snapcraft.yaml#L32
<ogra_> here is an example
<odc> thanks!
<ogra_> (the "after:" bit ...
<ogra_> =
<ogra_> )
<odc> ogra_: what will that do?
<odc> i understand it will build this part first
<odc> nvm, i saw it in the traces
<ogra_> its a remote part ... it pulls and builds it forst and puts everything into your snap
<ogra_> *first
<ogra_> details are at https://wiki.ubuntu.com/snapcraft/parts (scroll down to snapcraft-desktop-helpers)
<odc> the result is still the same, but this may be the cause:
<odc> main.go:192: cannot change mount namespace of snap "ahoviewer" according to change mount (/var/lib/snapd/hostfs/usr/local/share/fonts /usr/local/share/fonts none bind,ro 0 0): cannot create writable mimic over "/usr": cannot create path "/tmp/.snap/usr": cannot mkdir path segment ".snap": permission denied
<ogra_> uh
<odc> bbl
<Chipaca> zyga: ^ cannot create mimable writer
<Chipaca> or writable mimic or sth
<pstolowski>  Mount snap "test-snapd-content-circular2" (2) ([start var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dcircular2-2.mount] failed with exit status 1: Job for var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dcircular2-2.mount failed.
<pstolowski> these kind of mount failures seem to be recurring
<zyga> odc: hello
<zyga> odc: sorry, I was busy, we please talk about this now
<zyga> odc: can you tell me about the snap, what features are you using (content interfaces, layouts, etc)
<Chipaca> zyga: <odc> bbl
<zyga> aha, thanks
<mvo> pedronis: I updated 5537 based on your comments, thanks for those!
<odc> aaand i'm back @ zyga
 * odc switches computer
<Chipaca> odc: he's having lunch
<Chipaca> odc: he'll be back in 15'
<odc> Chipaca: which begs the question, why are you not having lunch?
<Chipaca> odc: because I'm having tea
<Chipaca> I'm in London, he's in â¦ somewhere in the east of Canada
<mvo> yummy tea yummy
<odc> heh
<Chipaca> montreal, i think
<odc> he's not gonna like me then. I'm a "maudit franÃ§ais"
<Chipaca> odc: hes polish, so most probably dngaf
<odc> lol
<pedronis> mvo: +1, need a 2nd review
<zyga> re
<zyga> odc: back, thank you for waiting
<odc> hi zyga
<zyga> so, I think you pasted some basic information
<odc> i reproduced the previous error on my desktop
<odc> 1sec
<zyga> but because of the risk that I just need to run to another meeting
<zyga> can you paste all the details agin please
<zyga> I will copy that and look into it after the event, if necessary
<odc> https://usercontent.irccloud-cdn.com/file/T6hxxsx5/snapcraft.yaml
<zyga> I will definitely debug it as this part has to be just work and I'm on point for that
<odc> i see :)
<odc> well, the error happens both on ubuntu 16 and 18
<odc> i had no issue producing the snap
<odc> (i build them inside docker)
<odc> do you need me to paste the output when i run the app?
<odc> aloso, i got the error even before using "base: core18"
<pstolowski|afk> zyga: #5532 is fixed
<mup> PR #5532: api/connect: ignore connect if already connected <Created by stolowski> <https://github.com/snapcore/snapd/pull/5532>
<zyga> odc: ideally I'd get:
<zyga> odc: dmesg | grep DENIED # from the device where this just occurred
<zyga> odc: yaml's for the snap that was used (just the snap yaml, I don't need the snapcraft one)
<zyga> odc: I will inspect that and perhaps ask some follow up
<zyga> odc: if you can please share the binary snap file
<zyga> odc: (in private if you prefer)
<zyga> odc: as  I can then explore this and ensure it's fixed
<odc> zyga: what is "the snap yaml"?
<zyga> odc: the file meta/snap.yaml
<zyga> relative to the snap itself
<zyga> after installation you can find it in /snap/$snap-name/current/meta/snap.yaml
<odc> zyga: i think you've found the problem: audit: type=1400 audit(1532020065.397:83): apparmor="DENIED" operation="mkdir" profile="snap-update-ns.ahoviewer" name="/tmp/.snap/"
<zyga> odc: yes, that's quite what I was looking for
<zyga> odc: what is your "snap version"?
<odc> https://www.irccloud.com/pastebin/brSCw3ar/snap%20version
<zyga> thank you
<zyga> oh, that's interesting
<odc> orly?
<zyga> give me a moment please
<zyga> ahhh
<zyga> I see
<zyga> base: core18
<zyga> I think I understand the problem now
<zyga> can you share some more files:
<zyga> please collect: /var/lib/snapd/mount/snap.ahoviewer.fstab and /var/lib/snapd/mount/snap.ahoviewer.user-fstab
<odc> https://usercontent.irccloud-cdn.com/file/vRcLB7Sn/snap.yaml
<zyga> just paste them here (thank you for using ircloud, much easier)
<zyga> jdstrand: security question: should devmode snap run snap-update-ns with a non-enforcing policy?
<odc> https://usercontent.irccloud-cdn.com/file/X28bldY6/snap.ahoviewer.fstab https://usercontent.irccloud-cdn.com/file/ImM9PvMu/snap.ahoviewer.user-fstab
<zyga> mvo: hey
<zyga> odc: I know exactly what the problem is now
<zyga> odc: can you do this to test my theory:
<odc> \o/
<zyga> odc: please edit the snap.ahoviewer.fstab file
<zyga> odc: you can use sudo and any editor you like (e.g. nano)
<odc> yup
<odc> vi
<zyga> odc: please remove the second row
<zyga> odc: save the file
<zyga> and restart your application
<zyga> (not sure if it ran successfully or died on startup before)
 * zyga prepares a PR
<odc> zyga: it ran faster and i didn't get the error :)
<zyga> odc: so that was it? that was preventing the startup?
<zyga> odc: one more thing
<zyga> odc: please top the app
<zyga> odc: and run: sudo /usr/lib/snapd/snap-discard-ns  ahoviewer
<zyga> then run the application again
<zyga> (on command line perhaps)
<zyga> and see if it starts
<odc> zyga: the main problem is that the app does not use my gtk theme and there are plenty of gdk-pixbuf errors
<zyga> odc: the theme part is a separate issue,
<zyga> odc: for that and the pixbuf issue please go to the forum; I think you need to use the desktop helpers to integrate with that
<zyga> but I'm not the best person to talk about that so I don't know how to help you immediately
<odc> k
<zyga> I will fix this issue for the next release
<odc> well snap runs fine now :)
<zyga> on the forum kyrofa or popey can help you with the desktop intetgration
<zyga> odc: *thank you*
<zyga> thank you for using core18 early
<odc> nonono, thank YOU
<zyga> (we haven't released it fully yet)
<zyga> snaps would be nothing without people making and using them
<zyga> I'll get to it now
<odc> well, i never really liked deb packaging ^^
<cachio> mvo, sru is validated
<cachio> but there is a suite which wasn't executed
<jdstrand> zyga: I don't see why it should be unconfined
<cachio> mvo, the rest is everything ok
<cachio> mvo, should we re-execute this one?
<jdstrand> zyga: it's an equivalent question to ask if snap-confine should not be confined with devmode
<jdstrand> zyga: well, roughly equivalent. I mean, we have the profile so that it is limited in what it should do since it is called by root running processes
<jdstrand> zyga: and snap-confine calls snap-update-ns
<zyga> jdstrand: ack
<zyga> thank you
<zyga> mvo: https://github.com/snapcore/snapd/pull/5527 needs a 2nd review
<mup> PR #5527: overlord/ifacestate: support implicit slots on snapd <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5527>
<zyga> and I would love to see it in this week :)
<Chipaca> zyga: I added a comment in last.go, maybe it helps? (wrt the l==-1)
<Chipaca> zyga: this is in #5531
<mup> PR #5531: cmd/snap: support `--last=<type>?` to mean "no error on empty" <Created by chipaca> <https://github.com/snapcore/snapd/pull/5531>
<zyga> Chipaca: thanks, I'll check
<zyga> I'm looking at another branch of yours
<zyga> :-)
<Chipaca> zyga: is it very obvious I'm finding the ones I _should_ be doing to be challenging?
<Chipaca> :-)
<zyga> Chipaca: I suspect it works in practice
<zyga> just feels bad
<zyga> Chipaca: can you please please please review https://github.com/snapcore/snapd/pull/5527
<mup> PR #5527: overlord/ifacestate: support implicit slots on snapd <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5527>
<Chipaca> zyga: yes, now.
<Chipaca> zyga: is this the one you asked me before and i forgot?
<zyga> yes
<zyga> it's the most important one now
<zyga> Chipaca: actually, as a general comment, we could use all-hands-on-deck on core18 reviews
<zyga> we have very little time left
<zyga> another useful PR to review is https://github.com/snapcore/snapd/pull/5537
<mup> PR #5537: snapstate: ensure kernel-track is honored on switch/refresh <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5537>
<zyga> but I can do that now
<Chipaca> zyga: #5410 is good to go i think
<mup> PR #5410: tests: update tests to work on core18 <Core18> <Reviewed> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5410>
<zyga> Chipaca: yes, it was intertwined with the racy test but that got spun off
<bdx> hello, where can I file a bug for snapcraft?
<bdx> ahh got it
<bdx> somehow I was ending up at https://bugs.launchpad.net/~snapcraft
<bdx> I'm hitting https://paste.ubuntu.com/p/z8Cc2Pwv2x/
<bdx> not sure if its been handled yet ... looking through the bugs now
<bdx> oooh, possibly thats my bad actually ...
<bdx> looks like the issue may have been that I left the source-type, source-depth, and source-branch configs set after switching my source to local ... https://paste.ubuntu.com/p/jBBr3rVkT9/
<pedronis> Chipaca: where does the "\n"Â in fron comes in your change to #5537
<mup> PR #5537: snapstate: ensure kernel-track is honored on switch/refresh <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5537>
<pedronis> the template has kernel%s
<Chipaca> pedronis: look at how it's used
<Chipaca> aaand i forgot the initial '\n' myself
<Chipaca> dangit
 * Chipaca fixes
<pedronis> Chipaca: that's what I'm asking about
<Chipaca> pedronis: soz
<Chipaca> pedronis: pushed
<pedronis> better :)
<pedronis> Chipaca: you didn't run the tests locally IÂ suppose :)
<Chipaca> pedronis: not for this one
<Chipaca> I usually do :-)
<pedronis> anyway better to stop, I might start to spot inexistent issues
<Chipaca> otherwise you'd've seen this happen a lot more
<Chipaca> pedronis: "this PR has no dinner!"
<pedronis> Chipaca: anyway I was confused, because IÂ thought you would indeed :) so I was wondering what IÂ was missing
<mvo> zyga: will review either tonight or early in my morning
<zyga> mvo: thank you very much
<zyga> mvo: chipaca is helping with reviews
<zyga> mvo: I think we are very close now
<mvo> zyga: yay
<mvo> zyga: yeah, he pushed a very nice fix into 5537
 * mvo hugs Chipaca 
<mvo> zyga: aha and you suggested it :)
<mvo> zyga: do you want to do a final pass on 5537 or shall I merge? it has two +1 already
<mvo> zyga: also, whats up with 5529 ? does this need a pass from gustavo? or can it go in?
<mvo> 5450 also needs a second review â¦
<zyga> re
<zyga> mvo: looking
<zyga> yeah, let's get it in
<zyga> that is
<zyga> let's get 5537 in
<zyga> mvo: as for 5529 - are you sure that is the PR you were thinking about? it's a integration / test PR that's not meant for landing
<zyga> mvo: I will review 5450
<zyga> mvo: https://github.com/snapcore/snapd/pull/5530 has some conflicts but I didn't do anything to fix it yet
<mup> PR #5530: tests: use file based markers in snap-service-stop-mode <Blocked> <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5530>
<Chipaca> mvo: zyga: back from dinner, what needs reviewing?
<zyga> hey
<zyga> let me re-check
<zyga> I'm reading the hardlink PR
<zyga> but anything core 18 I suspect
<zyga> + Chipaca's fantastic small PRs
<zyga> but don't kill youself over this
<Chipaca> zyga: totally not killing myself
<zyga> I'd love to know if we can (or maybe we do already) run main tests on core18 already
<zyga> ah
<zyga> I just realized I'm dumb
<zyga> I didn't understand it was you talking
<Chipaca> zyga: isn't that #5529 ?
<mup> PR #5529: many: run all main tests on core18 <Blocked> <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5529>
<zyga> I thought that was mvo from his bbq
<zyga> :D
<zyga> Chipaca: no, that is a fat integration with lots of (now gone) patches AFAIR
<Chipaca> mvo + bbq? does not compute
<zyga> Chipaca: see
<Chipaca> unless this "bbq" has  no  meat
<zyga> maybe they slowly burn potatoes
<Chipaca> zyga: so... what needs reviewing :-)
<Chipaca> zyga: now that you know I'm me
#snappy 2018-07-20
<palasso> Hello, is there an RSS/Atom feed for this blog: https://snapcraft.io/blog ?
<pstolowski> mornings
<mvo> pstolowski: hey, good morning
<mvo> pedronis: can I merge 5474 (the single task-runner PR) or does someone else should look at it first? it got two +1 now
<pstolowski> yay!
<pstolowski> mvo, would you have a moment to take a look at https://github.com/snapcore/snapd/pull/5433 (it's simple)?
<mup> PR #5433: interfaces/repo: added AllHotplugInterfaces helper <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5433>
<mvo> pstolowski: sure, let me do this now
<pstolowski> mvo: thanks!
<pedronis> mvo: yes, can be merged, yes I will do a couple follow ups to see how it feelds to make some of those now often empty methods optional
<pstolowski> merged
<mvo> pedronis: \o/
<mvo> hm, I want mup back
<pstolowski> hmm indeed what happened to it?
<Chipaca> mo'in
<mvo> pstolowski: it got disabled when github was acting up some days ago
<pstolowski> i see
<mvo> a second review for 5542 would be great
<Chipaca> mvo: +1
<pedronis> github is a bit unresponsive for me today
<Chipaca> pedronis: it's the universe way of telling you to head to hr.canonical.com and ask for the day off
<pedronis> Chipaca: I have things to do also in gdocs, which work, too bad
<pedronis> (and the forum as well)
<Chipaca> pedronis: *that*'s the universe's way of saying https://www.youtube.com/watch?v=kdOPBP9vuZA
<Chipaca> pedronis: it's the week after next that you're away for two weeks, right?
<pedronis> yes
<Chipaca> pedronis: ok
<pedronis> from the 31st to be precise
<pedronis> I'll be around Monday 30
<Chipaca> pedronis: ack
<Chipaca> filed go-flags#264 fwiw
 * Chipaca hoped mup would point that to https://github.com/jessevdk/go-flags/issues/264 but, alas
<kjackal> Hello snappy people! I facing a problem with building snaps from launchpad (LP) builders. I have a single snap, named microk8s, and I would like to release to edge from the code's master branch and to track 1.10/edge  from the code's  1.10 branch. I first created a snap for the master->edge path, but then when I select the 1.10 code branch and click "Create a new snap package" in the snap "Name: " I have to use the name "microk8s"
<kjackal> again and this errors with "There is already a snap package owned by microk8s developers with this name."
<kjackal> So, same snap release with LP builders from different code branches to different tracks is where I am loosing it.
<kjackal> Should I go to the forum or is there something obvious I am missing?
<kjackal> Let me ask on #launchpad as well
<cjwatson> I've answered on #launchpad.
<kjackal> thanks cjwatson
<pedronis> Chipaca: mvo: I think IÂ never noticed but it seems you cannot edit very old posts (that are not wikis) even as original author.
<mvo> pedronis: interessting, I did not notice that yet
<Chipaca> pedronis: do you have an example?
<pedronis> Chipaca: yes, I was trying to update: https://forum.snapcraft.io/t/transactionality-locking-and-other-concurrency-coordination/50
<pedronis> no edit button for me
<Chipaca> pedronis: hmm, I see an edit button
<pedronis> Chipaca: remember you have more powers than me
<Chipaca> pedronis: but I need to expand the options to see it
<Chipaca> pedronis: that is: to the left of Reply I see like, link, and ellipsis
<Chipaca> pedronis: click the ellipsis, and in there i have edit
<pedronis> no ellispsis for me
<pedronis> I'm talking about the top post to be clear
<Chipaca> yep yep
<Chipaca> pedronis: and if i make it a wiki? would that help?
<pedronis> Chipaca: not sure,   does the top post and the last makes sense?  do we fear people only reading the top one and being confused because SetBlocked is going away?
<Chipaca> pedronis: if this is meant to document the topic, having half in the top and half at the bottom doesn't work, if that's what you're asking
<pedronis> Chipaca: yea, that's what I fear,  the top post sounds very descriptive/prescriptive, not narrative of a moment in time
<Chipaca> pedronis: if you reload, does it now let you edit?
<pedronis> no
<Chipaca> pedronis: and now
<pedronis> yes
<pedronis> you turned it into a wiki?
<Chipaca> pedronis: ok. let me know if you want me to dewoke it
<Chipaca> pedronis: yes. It's a reversible operation, and i can't make you admin, so Â¯\_(ã)_/Â¯
<pedronis> Chipaca: I have an errand very soon but I can tweak it after
<pedronis> and see from there
<Chipaca> pedronis: ok
<Chipaca> pedronis: I've got to go to the boys' school in a bit, and i might not be back online before your eod (but i'll be on later)
<Chipaca> in fact i'm late!
 * Chipaca runs
<pstolowski> mvo: hey, i'm hitting core18 failure in my disconnect-hooks branch, and i'm most likely doing something wrong in the new world. the problem i've is disconnect failure - "Disconnect core:core-support-plug from snapd:core-support (internal error: connection "core:core-support-plug snapd:core-support" not found in state)". i'm probably missing some sort of remapping in the new code; any hints?
<mvo> pstolowski: hm, this has the latest master?
<mvo> zyga: -^
<pstolowski> mvo: well, yes, but it's my branch with master changes merged
<mvo> pstolowski: hm, hm, I need to look at this
<pstolowski> mvo: so very likely something i'm not doinf or doing wrong
<pstolowski> mvo: cause i've changed a lot wrt disconnects
<mvo> pstolowski: or its a bug in the remapper
<mvo> pstolowski: not unlikely as well
<pstolowski> mvo: this is in code triggered on snap removals - i run "disconnect" tasks for all connections, and the handler expects connection in 'conns' in the state
<pedronis> pstolowski: in theory getConns and setConns should do the job for you
<pedronis> but I don't know if you have code by-passing them
 * pedronis has some relatively quick errands now
<pstolowski> pedronis: right; no, i'm not bypassing them
<pstolowski> although, maybe my lookups on conns are invalid when it comes to snap names now? i've connection refs coming from repo; i look them up in conns retrieved via getConns()
<pstolowski> ok, i suspect i need RemapSnapToState() as I look up manually constructed conn IDs .. testing
<zyga> Hey
<zyga> Sorry for not finishing the PR work last night mvo
<mvo> zyga: good morning - now worries
<thresh> does anyone know if mozilla plans to release asan-enabled firefox via snaps?
<zyga> thresh: I don't know anything about that, perhaps popey knows
<popey> Zyga. Sorry on vacation
<popey> Kenvandine and willcooke  know about Mozilla things though
<zyga> thanks
<mbeneto> hi, has anybody seen kyrofa around lately?
<mbeneto> or can anybody enable again the experimental channel "edge/classic-trusty"?
<phocean> hi
<phocean> any idea about this error when trying to launch a classic snap : "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks"
<phocean> my guess is that it is an apparmor issue, but how to fix it ?
<mbeneto> more details regarding the "edge/classic-trusty" channel here: https://forum.snapcraft.io/t/building-classic-snap-on-trusty-fails/5472/13
<phocean> it happened after I uninstalled snapd by accident because of a dependencie, and then I reinstalled it
<pstolowski> zyga ^
<pedronis> pstolowski: the fix abour remapping still looks strange to me
<pedronis> we are missing something
<pedronis> mvo: we'll need to look into that ^
<pstolowski> pedronis: thanks for keeping an eye on this
<pstolowski> i think i will leave it at this point and revisit after i'm back from vacation
<mvo> pedronis: ok
<pstolowski> see you o/
<zyga> what's the issue about the remapping you were talking about?
<pedronis> zyga: pawel is hitting strange bugs in his new code in disconnect-hooks, he added some strange remapping that doesn't make much sense on its own, either there's a bug in the remapping or the new code, either way we need to understand
<pedronis> we don't have a unit test, only failing spread tests, that the remapping that IÂ don't understand seeems to fix
<zyga> pedronis: I see, ok
<zyga> thanks, I'll talk to pawel next week
<pedronis> pawel is off
<pedronis> for two weeks
<pedronis> we'll need to dig but not today
<zyga> oooh
<zyga> pedronis: yeah, I see
<zyga> I will be off on Monday
<zyga> but then I need to task switch to fedora
<zyga> and then I plan a week of holidays
<zyga> so my best bet is to just work with you next week but not in full capacity
<zyga> so that this part is fully bullet-proof
<pstolowski|off> pedronis, zyga, mvo now that i think of it, i suspect this bug would be hit with existing discard-conns, if we had proper test. discard-conns is pretty liberal right now. with disconnect-hooks i'm essentially doing what discard-conns does, only more strict
<zyga> pstolowski|off: are we hitting the state manually there
<zyga> because all of connection load/store code applies mappings
<pstolowski|off> zyga: i get conns via getConns in doDisconnect() - something we didn't do before. and i do this: https://pastebin.ubuntu.com/p/TYDZc3v8dC/ based on plug/slot refs from disconnect command
<pstolowski|off> (the remapping part is the part that pedronis commented on above - the suspicious bit)
<zyga> interesting
<zyga> I don't think you need that
<zyga> you should not need that
<zyga> I'll look next week
<zyga> I'm a bit tired despite it being 1:30PM
<pstolowski|off> zyga: without that it fails
<zyga> I see
<zyga> I'll look next week
<pstolowski|off> with that - it passes
<zyga> we have another meeting coming up now
<pstolowski|off> at least passes the spread test i iterated on
<pstolowski|off> zyga: sure, i'm really of now as well.
<pstolowski|off> zyga: safe trips!
<zyga> thank you :)
<mvo> pstolowski|off: enjoy your time off!
<pstolowski|off> thanks!
<mvo> zyga: and safe travels for you
<zyga> thank you guys
<zyga> enjoy your weekends with your families
<zyga> I'll check if my legs fit :)
<thiras> hello
<thiras> gnome's default calculator doesn't start
<thiras> https://paste.ubuntu.com/p/TXBY2nskGz/
<thiras> here is the error log
<thiras> i'm really get sick of this permission denied errors (i've experienced few more of them and solved with re-installing the snap packages)
<thiras> it's 18.04
<bmath> Hi all, having some trouble with snaps after a kernel upgrade.  Getting an error about how ptrace was denied in syslog.  I checked the apparmor config file and it looks like that capability should be allowed.  Is there a kernel setting I need to enable?
<zyga> bmath: hey, can you please provide the output of "snap version"
<zyga> bmath: since I'm boarding soon I won't be able to assist you please open a forum topic at forum.snapcraft.io and reference me there with @zyga syntax
<zyga> bmath: ideally please also include the name of the snap that causes the issue and the output of `dmesg | grep DENIED`
<zyga> bmath: I'll be here for a few more moments but expect any answers from me on Tuesday, I have a long way home and I will rest a little
#snappy 2018-07-21
<EquusGrevyi> Hi folks, sorry to copy pasta from #ubuntu : Is there some way I can permit a snap installed from the store to access a particular folder tree? Trying to do this for Nextcloud without having to move the entire data folder to that place.
#snappy 2018-07-22
<zyga> Pharaoh_Atem: hey, are you all set for Flock?
<Son_Goku> zyga, in what sense?
<Son_Goku> zyga, I've got my flight, if that's what you're asking about
<crimson_king> Hello, where to report a problem with a snap which has "snapcrafters" as maintainer?
<zyga> Son_Goku: yeah, I'm sorting mine now :) (it should be all good tomorrow)
<new_gen> Does it make any difference if I install Jetbrains IntelliJ idea from Ubuntu Software center insted of downloading from Jetbrains official website???
#snappy 2019-07-15
<mvo> could someone with a fedora system check the selinux label for /lib/firware for me please (stat /lib/firmware)?
<mvo> pedronis, Chipaca good morning :)
<mvo> pedronis: thanks for your review!
<Chipaca> mvo: morning! i was here earlier but then needed to step away for a bit (and the laptop went to sleep :) )
<Chipaca> mvo: how's things?
<pedronis> Chipaca: mvo: hi
<mvo> Chipaca: things are looking good, very quiet in the morning with so many people on vac :)
<Chipaca> mvo: let's set things on fire :-)
<mvo> Chipaca: haha!
 * mvo fetches his asbestos suite (its still warm from the latest flamewars)
 * Chipaca puts away the kindling
<Chipaca> yeah... ha! ha!
<pedronis> I merged 7036 with a long commit message
<mvo> pedronis: thanks for this
<pedronis> Chipaca: as we talked about the various snapd type PRs are fou you to shepard from 6977 to 7086 (and 7092 but the last one needs snapcraft)
 * Chipaca nods
<pedronis> I will try myself to look at and move forward some of Pawel's PRs
<pedronis> my own PRs need reviews or 2nd reviews
<ogra> pedronis, remind me ... did we eventually allow interface connections from gadget.yaml by name ? ( https://forum.snapcraft.io/t/connection-with-gadget-spidev0-plug/12281 )
<ogra> (i think i remember you said something along that line a while ago)
<pedronis> ogra: we have a connections stanza in gadget.yaml
<pedronis> https://forum.snapcraft.io/t/the-gadget-snap/696
<pedronis> mvo: another comment on 7105
<mvo> pedronis: thanks, looking
<pedronis> mvo: is there anything else that is urgent for me to review?
<ogra> pedronis, yes, but in the past (and apparently at present too) that only allowed connections per-ID i thought i remembered there were plans to allow connections by-name ....
<mvo> pedronis: nothing urgent I think
<pedronis> ogra: no, that hasn't changed
<ogra> k, thanks
<pedronis> we don't allow names in defaults eitehr
<pedronis> *either
<ogra> yeah, i know
<Chipaca> mvo: can you confirm you're ok with the first snapd type pr now?
<Chipaca> (i think your issues were addressed?)
<Chipaca> I don't think I'll land it until they're all ready, but wanted to confirm
<mvo> Chipaca: will check in a a wee bit
<mvo> Chipaca: 6977 ?
<Chipaca> mvo: yus
<mvo> ta
<Chipaca> kenvandine: do we have a bug # for the "seed.yaml wronk in eoan daily cdimage" thing?
<Chipaca> kenvandine: because https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1836569
<Chipaca> dunno if it's actually the same as https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1828500
 * Chipaca goes to fix lunch
<mvo> Eighth_Doctor: hey, cgroup v2 is not yet enabled by default in fedora 31, is it? I am just playing with the livecd and it seems I still have v1 (?)
<Eighth_Doctor> mvo: not yet, no
<Eighth_Doctor> it'll likely get done next week
<Eighth_Doctor> but you can test in v2 mode now if you want
<Eighth_Doctor> mvo: almost everything in Fedora except snaps is ready for cgroups v2
<mvo> Eighth_Doctor: thanks! I'm looking into making sure snaps also work, this is why I was asking :)
<mvo> Eighth_Doctor: I use "systemd.unified_cgroup_hierarchy" in the kernel cmdline
<Eighth_Doctor> huh, then it might be enabled
<Eighth_Doctor> if `systemd.unified_cgroup_hierarchy=1` is set as a boot parameter, then it will use cgroups v2
<Eighth_Doctor> there's limited automatic translation of cgroupsv1 terms to cgroupsv2 terms by systemd itself
<mvo> Eighth_Doctor: thank you, I will keep poking (in  a meeting right now)
<kenvandine> Chipaca: i suspect that's the same as bug 1828500
 * Chipaca afk for a bit
<ackk> jdstrand, oh I had missed your message, thanks for the updated snapd package, will test now!
<ijohnson> mvo: reviewed 7105 for you
<mvo> ijohnson: thank you!
<ijohnson> what's the most up to date way to get spread installed locally? maybe cachio do you know?
<cachio> jutst download from ..
<cachio> ijohnson, https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz
<cachio> this is the officialbinary
<cachio> also you can use the spread snap
<ijohnson> cachio: ok, thanks
<zyga> ijohnson: try spread.zygoon.pl for images
<zyga> Greetings from almost Andorra
<ijohnson> hey zyga
<ijohnson> thanks I'll take a look there too
<ijohnson> it would be nice if HACKING.md was updated to mention zyga's spread images
<Chipaca> ijohnson: go for it
<Chipaca> ijohnson: bah
<Chipaca> ijohnson: check with zyga first?
<ijohnson> maybe I will
<Chipaca> ijohnson: he's mentioned them to me in private
<ijohnson> ... check with zyga
<Chipaca> ijohnson: not sure that url exists in a public place (meaning he might not want it crawled)
<ijohnson> I see
<ijohnson> I'll let zyga have his vacation and check on it next week
<Chipaca> ijohnson: :-)
<Chipaca> ijohnson: nah, message him, the photos he's posting to twitter are much too nice to let it pass
<zyga> Chipaca: it is public
<zyga> ijohnson: it is my new CDN setup, go for it please :-)
<Eighth_Doctor> zyga, robert_ancell_, mvo: I need help? https://src.fedoraproject.org/rpms/gnome-software/pull-request/1
<Eighth_Doctor> it looks like the core is that they think Ubuntu isn't using GNOME Software anymore: https://src.fedoraproject.org/rpms/gnome-software/pull-request/1#comment-27692
<Eighth_Doctor> if they could be assured otherwise in the ticket, then they may let us put it back
<ackk> Chipaca,  is it possible to pass additional LD_PRELOAD to snapcraft-preload?
<mvo> kenvandine, willcooke could you pleae have a look at the pr and lines from Eighth_Doctor above? not sure what exactly our plan so I don't feel qualified to comment myself
<ackk> actually, I should ask sergiusens :)
<jdstrand> msalvatore: hey, would you mind approving r79 through r84 of https://dashboard.snapcraft.io/snaps/test-snapd-daemon-user/ ?
<jdstrand> msalvatore: it is a test snap where the the review-tools don't have the current iteration of the snap.yaml for the feature
<msalvatore> jdstrand: ok, so they can be approved despite the warning?
<jdstrand> msalvatore: yes. I updated the tools, but it isn't in prod yet
<kenvandine> mvo: commented
<jdstrand> msalvatore: thanks!
<msalvatore> jdstrand: any time
<mvo> kenvandine: thank you!
<sergiusens> ackk: go ahead and ask :-)
<ackk> sergiusens, looking at snapcraft-preload code (and my cpp is very poor) it seems ifyou have LD_PRELOAD set, it should get passed on to called binaries. it that correct?
<sergiusens> ackk: the one snapcraft-preload sets, yes
<ackk> sergiusens, no I mean, if you have LD_PRELOAD set in the env where snapcraft-preload is called
<ackk> sergiusens, I see it looks at LD_PRELOAD in the env
<ackk> sergiusens, https://paste.ubuntu.com/p/3k3SgJVFFC/
<ackk> sergiusens, basically I would need to pass my LD_PRELOAD down
<sergiusens> ackk: as long as you do not use https://github.com/sergiusens/snapcraft-preload/blob/master/snapcraft-preload.in
<sergiusens> and do the preload declaration yourself
<ackk>     environment:
<ackk>       LD_PRELOAD: $SNAP/usr/lib/stub_initgroups.so
<ackk> sergiusens, ^ I have this in the snap app, and have command: bin/snapcraft-preload <mycommand>
<ackk> sergiusens, but that's not working
<sergiusens> ackk: well yeah, snapcraft-preload wipes your LD_PRELOAD as I just mentioned above
<ackk> sergiusens, is there a way to combine them?
<sergiusens> do not use the snapcraft-preload script seems like the first step and only LD_PRELOAD the library it creates
<ackk> sergiusens, ah I see
<ackk> sergiusens, thanks I'll try that way
<mvo> Eighth_Doctor: do you think you could have a quick check for https://github.com/snapcore/snapd/pull/7104/files ? the selinux bits there? should be easy for someone with selinux skills, but everyone if have with them is currently not around :/
<Eighth_Doctor> mvo: I'll take a look in a bit :)
<mvo> Eighth_Doctor: *thank you*
<cachio> mvo, hey, core validation is done but dragonboard beta image doesn't boot
<cachio> stable image with core rfom beta works well
<cachio> but beta image doesn't
<cachio> still debugging that
<mvo> cachio: thank you! that is unexpected, curious about your findings
<cachio> mvo, seems to be a problem wiht the image
<cachio> mvo, I am testing a new one now
<mvo> cachio: thank you
<cachio> mvo, yaw
<jdstrand> are there any tricks to make the 'prepare' step in spread to go faster?
<jdstrand> I use -reuse, but all I really want to do is adjust the task.yaml and retry
 * jdstrand wonders if he can run rerun a task.yaml while in -debug...
<ackk> jdstrand, ftr tested your 2.40-like build with daemon user, everything seems to work fine. thanks
<leftyfb> on the assumption that we can install a snap from the snap package file as opposed to the snap stop, in doing so, does that prevent the snap from auto-updating?
<jdstrand> ackk: great! fyi, I'm actively working on incorporating various feedback into the PR and will give you an updated deb when I have final approval on the snap.yaml. as it stand, it will change to 'system-users: [ snap_daemon ]', but that isn't *final*
<jdstrand> ackk: (which means you'll need to s/daemon/snap_daemon/ in the other parts of your snap (that part is final))
<jdstrand> ackk: if you'd prefer, I can give you a deb that uses the above snap.yaml and finalized 'snap_daemon' user, with the understanding that the snap.yaml will change, or we can just wait
<zyga> jdstrand: tip: use task.sh
<zyga> jdstrand: and in task.yaml, execute it
<zyga> jdstrand: it works best without prepare/restore inside task itself
<zyga> (I'm not really here, greetings from hotel wifi)
<jdstrand> zyga: ok, thanks, I'll play with that. and hello :)
<zyga> jdstrand: hello :)
<zyga> jdstrand: it also works nice with test-cleanup tool but that's just on my laptop, for now, it allows you to have prepare/restore like logic embedded inside task.sh+task.yaml
<zyga> jdstrand: I'm in Andorra today
<jdstrand> zyga: nice nice and cool :)
<ackk> jdstrand, it doesn't really matter until it's final, as we won't merge the changes for the system user until we have that
<jdstrand> ackk: that's what I figured. cool
<ackk> jdstrand, so "snap_daemon" *is* final you mean?
<ackk> just how you declare it isn't?
#snappy 2019-07-16
<mvo> hey Chipaca, good morning!
<mvo> 7096 needs a second review, should be an easy one
<Chipaca> mvo: looking
<mvo> ta
<pedronis> mmh
<mvo> pedronis: mmh? (and good morning :)
<pedronis> I have vague memories that the ! would go in front , but I'm probably misremembering, the notes says after
<pedronis> also the shell would scream if in front
<pedronis> so I'm misremembering for sure
<mvo> pedronis: oh, indeed
<pedronis> also in the context of the unset work, we shouldn't forget we decided to fix snap set a.x=... a=... by sorting
<mvo> pedronis: good point, I wonder if we captured this in one of the trello cards
<Chipaca> pedronis: what kind of sorting?
<Chipaca> ogra: mvo: do you know, offhand, how to pause the live cdimage before it boots into the actual live system? wanting to set SNAPD_DEBUG :)
<ogra> not sure you can ... but there should be a console on tty4
<ogra> (so you can do your edits and restart all involved bits)
<Chipaca> ogra: the thing i'm wanting to see is the seeding, and i'm not fast enough
<mvo> Chipaca: uh, thats a tricky one. I wonder if you could break into initramfs
<ogra> yeah, thats a possibility but also a lot of time consuming work
<ogra> (manually assmbling the rootfs, chrooting and editing etc)
<Chipaca> eugh
<Chipaca> I've asked laney, maybe they have a trick for it
<ogra> try break=bottom
<ogra> on the kernel commandline
<mvo> yeah, break=bottom was what I was thinking, then tweak and exit the shell and hope for the best
<Chipaca> trying that
<ogra> (there should be a way to enter this at the very start)
<Chipaca> break=bottom and then echo SNAPD_DEBUG=1 >> /root/etc/environment worked
<mvo> Chipaca: \o/
<Chipaca> need to step out for a bit, will bbiab
<pedronis> Chipaca: by depth
<mvo> 6878 (health status in info/list has two +1, I will merge it, I left one bikesheed comment though, but its fine to ignore that)
<pedronis> mvo: it's in the card https://trello.com/c/yxC3omC9/245-snap-unset-support
<pedronis> but not sure it was done yet (haven't looked at the PRs)
<mvo> pedronis: excellent, thank you!
<mvo> pedronis: not done yet in any of the PRs I have seen so far
<mvo> fwiw 7098 and 7102 should be easy wins
<pedronis> we are also missing snapctl unset
<mvo> pedronis: good catch
<pedronis> anyway I added actual todos to the card
<mvo> pedronis: thanks for adding it to the card!
<mvo> fwiw - I closed 5915 now (netplan apply) now that we have #7107
 * mvo really misses mup btw
<pedronis> mvo: thank you
<mvo> 7100 is now also green - its "funny" one, it requires that we update gorilla too
<pedronis> it needs Chipaca to look at it, then I will look at it as well
<ackk> sergiusens, hi, would you consider merging https://github.com/sergiusens/snapcraft-preload/pull/32? we'd need it for postgres, which tries to create /dev/shm/PostgreSQL.XXXXX files
<Chipaca> mvo: wrt 7100, why not have the prereq helpers also take context?
<Chipaca> mvo: they're called from a do* handler so you've got a tomb so you've got a natural context already
<mvo> Chipaca: aha, let me check that
<Chipaca> mvo: i mean, if they break all the tests in the world, maybe it's worth leaving them for later :-)
<Chipaca> but otherwise, ...?
<mvo> Chipaca: let me explore that
<mvo> Chipaca: I'm a bit slow (sry!) do you have an example helper name that could take the context for me? not sure I know what you have in mind
<Chipaca> mvo: installOneBaseOrRequired
<Chipaca> mvo: via installPrereqs
<mvo> Chipaca: aha, yes
<mvo> Chipaca: I can do that, however I think the reason its not done (now) is that the client-user-agent will only be set (in this PR) in the SnapAction store API call. once the change is created the client-user-agent is no longer available in the change. we could fix that but its more work and the win seems to be small. or am I missing something?
<mvo> Chipaca: we would have to persist the client-user-agent somewhere in the change if we want to keep it and use it in the handlers
<Chipaca> mvo: hm...
<Chipaca> ah so it's not in the tomb at all
<Chipaca> sary, missed that disconnect again
<Chipaca> mvo: in any case +1
<Chipaca> pedronis: does request-serial in classic hit the actual store?
<mvo> Chipaca: \o/ thank you!
<mvo> 7098 is green and has one +1 already and is smallâ¦
<Chipaca> mvo: it's got two +1's though
<pedronis> Chipaca: yes
<Chipaca> pedronis: that's taking ~30s
<Chipaca> pedronis: which is the same as seeding takes
<Chipaca> on this machine
<Chipaca> pedronis: seems slow for a single request
<Chipaca> Â¯\_(ã)_/Â¯
<pedronis> that is interesting
<Chipaca> pedronis: https://snapforum.s3.amazonaws.com/original/2X/5/55ca16db9b44fe934424c27999c3386948b4fb4e.png
<mvo> Chipaca: heh :)
<mvo> Chipaca: we are down to 51!
<Chipaca> pedronis: it's prepare-serial-request, not submit-serial-request, that takes that long though
<pedronis> Chipaca: ah, but we don't split retries
<pedronis> so a bit unclear
<pedronis> if that's one request or many retries
<Chipaca> pedronis: you can ask
<Chipaca> pedronis: you can ask me, even
<Chipaca> or you can get the iso and look for yerself :-p
<pedronis> prepare-serial-request
<pedronis> that is even weirder
<Chipaca> anyway i need to go comb my hair (just one of them) and get ready for the show
<pedronis> are we doing or changed something silly
<pedronis> we ask only a nonce from the store there
<pedronis> I need to dig/look around a bit
<Chipaca> pedronis: you ok to repro this on your own, or should i get the logs somewhere
<Chipaca> pedronis: instructions here: https://forum.snapcraft.io/t/snap-seeding-is-slow-racy/12310
<pedronis> Chipaca: well, I'm not promising to repro it
<pedronis> I'm promosing to understand what we need to look
<pedronis> more precisely
<Chipaca> pedronis: fair enough
<Chipaca> i look forward to learning more :-D
<Chipaca> but now i need to run
<mvo> Chipaca: I added a comment to 7083 that might be worth doing (not sure though, depends on the plans with 7092)
<Chipaca> mvo: ok, i'll take a look in a bit
<Chipaca> afk from irc but github will work :-)
<pedronis> I left some comments there
<pedronis> Chipaca: it takes ~200ms to get a nonce from the store, so something else is going on
<mvo> 7102 is another easy win
<mvo> xnox: snapd PR#7031 (re-enable the system PATH generator) is fixed now, right? or do we need some initramfs fix too (I have some vague memories that this was discussed but don't know the conclusion)
<mvo> xnox: once you  +1 it I will merge it
<ogra> sil2100, could we get this into all gadgets (core16 and 18) soon ? https://github.com/snapcore/pi3-gadget/pull/28
<ogra> (i asked ondra for a signoff too, to get more eyes on it, but in general someone should really monitor the pi firmware and push regular updates to the gadgets, they often fix over/under vlotage issues, overheating etc)
<cwayne> ogra: sil2100 i thought we just landed the same thing
<ogra> cwayne, well, i couldnt make any of our official images boot on the CM3 on my desk ... neither core16 nor core18 (though i dont look much at 18 anyway given the quality)
<ogra> CM3+
<ogra> sorry
<ogra> using my universal pi-kiosk snap with the latest firmware (also for pi4 support) boots it fine though
<ogra> otherwise it always hangs on the rainbow splashscreen (meaning the rpi bootloader itself dies before it can load anything)
<cwayne> ogra: did you try with a very recent image? think the updated gadget landed in stable ~5hrs ago
<cwayne> worked for 18 for us
<ogra> i tried both, 16 and 18 from the current dir on cdimage
<om26er> Hi! one of my snap failed to publish because I added a new hook, is that normal will have to go through a review or is that something that needs changing in my yaml ?
<om26er> the warning was "unknown hooks in meta/hooks: 'disconnect-plug-services-content' lint-snap-v2_unknown_hook"
<ogra> i also dont get why we still have separate images for pi2/3/cm3 and dont use the universal gadget, i thought we moved to that
<ackk> jdstrand, hi, wrt /run/uuidd/request, do you think it makes sense to file a bug for an interface request? I see it's currently available in openvswitch-support
<om26er> roadmr ^
<xnox> mvo:  you are correct. Needs https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814355 tasks for initramfs-tools done.
<xnox> let me comment on the PR
<mvo> xnox: thank you
<jdstrand> ackk: last we talked in Lyons, blake, et al all felt that the snap should be adjusted to use /proc/sys/kernel/random/uuid, which is standard and in the default template). there is nothing that will guarantee that /run/uuidd/request will be there on all distros. that said, it seems systemd is providing it and snapd requires systemd (and 14.04 is no longer supported by snapd)
<ackk> jdstrand maybe we can use snap layouts for that
<ackk> jdstrand, we don't explicitly use that socket, libuuid does that
<jdstrand> ackk: well, sure, but why use libuuid? :)
<ackk> jdstrand, actually we can't use templates as the kernel one is just a file you cat
<ackk> jdstrand, because it's somewhat standard? IDK we don't use it explicitly :)
<ackk> I mean it's not a direct dependency
<ackk> a lot of stuff use that
 * jdstrand wonders why it doesn't use the kernel interface rather than uuidd
 * cachio afk
<jdstrand> (when the kernel supports it)
<ackk> jdstrand, dunno, portability?
<ackk> I mean, sure libuuid could use that file if it's there
<jdstrand> right
<jdstrand> anyway, I've taken a todo to investigate this for the default template
<jdstrand> I suspect systemd will be looking at that file
<ackk> jdstrand, the python uuid uses os.urandom() afaics
<sil2100> ogra: that should be released already
<sil2100> ogra: the 'master' branch is out-of-date and not used
<sil2100> ogra: I actually need to just remove it
<mvo> ijohnson: just fyi, I'm poking at the tests in your netplan-apply pr right now
<sil2100> ogra: there are 16 and 18 branches, and both have the latest uboot bumps for the pi3
<ogra> sil2100, well, none of the images i tried on the CM3+ booted
<ogra> sil2100, this is not u-boot ... this is the raspberry pi firmware
<ogra> sil2100, it doesnt even get to a point where it would load u-boot, hangs in teh step before
<ogra> (on the ranbow colored splash screen (which shoudl really be disabled, not sure why thats on in the official gadgets)
<sil2100> ogra: ok, I see what's the problem - you are right, the core16 gadgets didn't get the firmware bump
<sil2100> ogra: since we only bumped the uboot version there
<ogra> right
<sil2100> ogra: let me do that then
<ogra> thanks !!
<sil2100> ogra: but the 18 ones are bumped if anything
<sil2100> ETOOMANYGADGETREPOS
<ogra> wried
<sil2100> Sorry about that!
<ogra> *weird even
<ogra> sil2100, i definitely tried the rpi3 UC18 images from /current
<ogra> (as well as the (totally pointless) cm3 ones ... why do we build them ?)
<ogra> sil2100, could it be that the fix hasnt made it to /current yet ? (i can surely try /pending too if needed)
<sil2100> hm hm hm, it looks correct, manifest shows having the latest pi gadget, and from what I see in the gadget's build log the right boot-firmware tag has been cloned
<sil2100> And I thought waveform checked if it's the right firmware version before submitting the PR
<ijohnson> mvo: thanks
<mvo> ijohnson: I pushed some bits, if you mind I can also push to a separate PR
<ijohnson> no, it's fine you can push to the same PR, thanks!
<mvo> ijohnson: mostly suggestions, probably need a critical eye from samuele as well but should make things a bit easier
<ijohnson> mvo: ack, thanks for that
<mvo> ijohnson: its mostly there now, something in the TestYesNetplanApply test is unhappy still, it hangs here
<mvo> ijohnson: not sure why, probably some mocking missing for something
<ijohnson> yeah I've seen it hang a few times I think it has something to do with locks
<ijohnson> err I've seen it hang in a few iterations I've done
<mvo> ijohnson: yeah, its probably not my changes :)
<mvo> ijohnson: aha, locks! good catch, let me check those
<ijohnson> the version I pushed up shouldn't hang, but maybe your changes are moving back to what I tried originally that was hanging
 * mvo nods
<ogra> sil2100, looking at https://github.com/snapcore/pi-gadget/blob/18-armhf/snapcraft.yaml i see a tag from feb 2019 ... perhaps thats still not new enough
<sil2100> ogra: maybe, but waveform selected that tag exactly because of cm3+ support
<sil2100> Let me poke him
<sil2100> ogra: anyway I'd expect it to work as we use the exact same firmware tag for disco and eoan classic raspi3 images, and I'm sure those work on the cm3+
<sil2100> (also, per Dave's original commit message: https://github.com/snapcore/pi-gadget/commit/b8a16cb1e1d9a2c0419da8fef0bffc12e3c914fb )
<ogra> very weird ...
<sil2100> I asked him to test again
<sil2100> Maybe there's something weird going on somewhere
<sil2100> I'll wait for this to be resolved before I update the 16 gadgets, since I'd like it all to use the same firmware
<om26er> When a new hook is added to a snap package (e.g. interface connection/disconnection hook), does that need to be approved by the store guys ?
<ijohnson> om26er: I'm not sure that the store review tools have been updated to take into account interface connection/disconnection plugs
<ijohnson> jdstrand and roadmr should be able to help you with that when they get time
<ogra> sil2100, well https://github.com/snapcore/pi-gadget/commits/18-armhf shows that all travis checks have failed ... not sure if that tree is gated by travis though
<ogra> (for both last commits)
<sil2100> ogra: well, it passed on the PRs
<sil2100> ogra: (when you check the failed travis checks, those are issues with git clone and I also experienced that during the snap builds)
<sil2100> And even locally
<sil2100> There was a period of time where the default git repo url of uboot that we use was not usable
<sil2100> Anyway, basically the travis checks are build-checks, so if LP was able to build the end snap, that means it passed all the tests
<om26er> ijohnson thanks, I'll wait
<ogra> ok ... as long as the sync to LP isnt blocked by these travis checks i guess it is fine
<ogra> just looked like a potential reason for not having the change in these images
<sil2100> ogra: I checked the snap build logs, and I saw that the git clone of the firmware branch printed "Note: checking out '98997f363e3683ead4f50c37902169248628303a'.", which is a commit from feb 2019
<ogra> ok
<ogra> very strange then
<sil2100> cwayne: hey! Do you guys have cm3+'s in the lab?
<ogra> they do
<roadmr> om26er: can you show me (snapcraft.yaml) what you added?
<cwayne> They're on the way sil2100
<cwayne> plars has one at home
<sil2100> cwayne: awesome \o/
<plars> sil2100: have a new image I need to try?
<om26er> roadmr https://github.com/deskconn/deskconn-server/blob/master/snap/snapcraft.yaml
<roadmr> om26er: hm this looks reasonable; I think the best way would be for you to change what you need, upload the snap, and the review tools will tell you if it needs manual approval
<sil2100> plars: could you check the current one? Since Dave seems to be AFK - just so that someone else also tries booting it http://cdimage.ubuntu.com/ubuntu-core/18/current/ <-
<roadmr> om26er: typically what we do is approve that in general, and subsequent uploads won't need the same thing
<plars> sil2100: will do
<sil2100> plars: thank you!
<ogra> plars, i couldnt get that one to boot on my CM3+ ...
<om26er> roadmr https://dashboard.snapcraft.io/snaps/deskconn/revisions/84/
<ogra> would be good to have another datapoint
<om26er> I think revision 82 is the one that needs approval
<sil2100> This will be some good input, since I at least hope he did test that gadget change before submitting the PR
<sil2100> (Dave that is)
<cwayne> sil2100: we had tried an image with a gadget using Dave's pr and were able to boot core18 but not core16
<sil2100> cwayne: yeah, the core16 is expected, because of uh, my mistake
<sil2100> Too many repos of those gadgets
<sil2100> cwayne: but the 18 gadget booted fine on the cm3+?
<cwayne> plars: ^
<cwayne> Yeah that was my understanding
<plars> yes, still setting up to try this one though - I'm also trying to boot it with a regular cm3 in the lab
<sil2100> The regular ones should be good, since I saw those being tested in the automated testing
<ogra> yeah, very unlikely that they could have regressed
<plars> ogra: did that rpiboot from edge work for you at least? seems to be working on my cm3+
<plars> it's writing the image now
<ogra> sil2100, oh ... note that i tested http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/  is that different from http://cdimage.ubuntu.com/ubuntu-core/18/current/ ?
<sil2100> ogra: yes!
<ogra> oh man
<ogra> can we clean up that directory mess ?
<sil2100> ogra: we don't daily-build stable images, only during point releases
<sil2100> ogra: you need to check the timestamps, we only daily build edge and beta images right now
<ogra> oh my ... ok
<sil2100> ogra: stable is like the stable ones we want to brand and 'release', which only happens on every point release
<sil2100> ;)
<ogra> then sorry for the noise ... i followed some download link (that i have lost now :( ... )
<ogra> from our main website somewhere
<sil2100> http://cdimage.ubuntu.com/ubuntu-core/18/current/ are for edge and http://cdimage.ubuntu.com/ubuntu-core/18/beta/current/ are for beta - and I guess for a daily stable image you'd have to build one locally with ubuntu-image --channel=stable
<sil2100> It might be a decent idea to build some stable images before point releases
<sil2100> But doing it daily wouldn't make much sense, there's not enough velocity there
<ogra> well, yeah, dail stable (or daily in general) is nonsense anyway ... the images shoudl simply be built change-triggered
<sil2100> So we'd probably switch some stable images built on every stable snap change, but that's still not there
<sil2100> Yeah, that's the plan
<sil2100> But we still don't have that
<sil2100> plars, cwayne: issue has been resolved, sorry for the commotion o/
<ogra> http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/ doesnt really suggest it is anything thats daily though ... if i navigate from the toplevel of cdimage i indeed want the "stable " release ... and then go to the most current image of that by using the "current" link
<ogra> so even if i had not follwed a download link originally,m i would have ended up in the exact same place to get the latest stable image
<sil2100> Well, the header of the stable images mentions 'Ubuntu Core 18', where others explicitly say 'Daily Builds' - but indeed, we might want to make this a bit more intuitive
<sil2100> ogra: well, this is the 'latest stable image' ;)
<ogra> right ... but there are no headers at http://cdimage.ubuntu.com/ubuntu-core/18/ :)
<sil2100> ogra: as mentioned, we will only promote to 'current stable' on point releases, so people following download links will always get only the image we blessed during point release preparation
<sil2100> True
<sil2100> cdimage is a confusing place
<sil2100> ;p
<ogra> and when i finally enter the site i have to search for the right image between the gazillio pi images on that page (is there any reason why we do not have one pi image per arch /armhf/amd64 ?)
<plars> sil2100: this boots on both my cm3 and cm3+, but it has edge snaps for everything. Is that expected?
<plars> ah, just saw the backlog
 * ogra hands plars some https://www.youtube.com/watch?v=7nqcL0mjMjw
<ogra> :)
<plars> hah
<plars> sil2100: so we are waiting on a different image to test now I guess?
<sil2100> plars: no no, it's all good - I mean, I'll be pushing new cm3 16 gadgets out soon, but other than that we're good
<plars> ack
<ogra> sil2100, but in all seriousness, why do we have pi2, pi3 and cm3 images there ? supposedly all using the universal pi gadget and the same kernel, so in the end they are all the same image
<ogra> this smells like a massive waste of built/test time and server space
<ogra> (i originally developed the universal pi gadget to exactly not have three images anymore :) )
<sil2100> ogra: well, it is a waste, yes, that was some leftover of the 16 times, no reason for it - guess when the first 18 models have been created and signed we simply cloned what we had for 16
<sil2100> So we got pi2, pi3 and cm3 models, thus a separate image for each model
<sil2100> oh well
<ogra> sil2100, yeah, for 16 we couldnt change ... i had hoped for 18 it would though
<ogra> i guess i'll send some expensive tea to bribe xnox to make sure core20 gets better here ;)
<sil2100> ogra: a missed opportunity I guess! There was a bit too much going on so I also didn't notice it's unneeded until it was already all released ;)
<ogra> yeah
<mvo> ijohnson: please check netplan-apply - should be mostly good now, feel free to fix anything I missed and there is also a spread test missing iirc
<ijohnson> mvo: thanks I just saw your push I was waiting to push up my spread test until you were done
<ogra> well, who knows ... i'm not sure we can actually support the pi4 with the same kernel snaps in the end ... perhaps it was a clever thing to keep them separate
<ogra> until we can go to a new enough kernel that supports all of them in core20
<mvo> ijohnson: yeah, I think I'm finished with what I wanted to do :) feel free to tweak/adjust as needed, its your PR afterall, I feel slightly bad for being so pushy in it :/
<mvo> ijohnson: but it was also fun so I couldn't stop myself
<ijohnson> mvo: no problem, I appreciate the help in the tests that was what I was blocked on so you have unblocked me :-)
<mvo> ijohnson: great! happy to help and to be fair the testing was a bit delicate (but hopefulyl we can make things better/easier :)
<ijohnson> +1
<pedronis> 7083 needs a bit more work, there or in a follow up
<pedronis> it has 2 +1 but I should probably look at it as well
<pedronis> I commented about the work
<jdstrand> hmm, om26er is gone. ijohnson> fyi, so long as the hook is known to the review-tools at all, then there is no problem. if a new hook is added to snapd, then the review-tools need to learn it
<pedronis> ijohnson: I was discussing with mvo, a smallish thing that we might need sooner rather than later, related to remodeling is this:  https://forum.snapcraft.io/t/remodeling-to-a-new-model/10477/2
<ijohnson> jdstrand: does the store tools know how to handle interface hooks? IIUC, those hooks could be named anything in the patterns shown on https://docs.snapcraft.io/interface-hooks
<ijohnson> pedronis: looking
<jdstrand> pedronis: I'm not up on remodeling and I don't see anything in that forum that references hooks (am I blind?)
<pedronis> jdstrand: not related to the discussion, but ijohnson has progress quite a bit on his current task, so I was discussing with mvo what he can pick up next
<pedronis> *progressed
<pedronis> *can or could
<jdstrand> oh, heh, I copied the wrong link. durr
<ijohnson> pedronis: okay this seems straight forward, but actually like jdstrand I'm not familiar with the current plan on remodeling :-)
<ijohnson> pedronis: is that forum post all we have for the plan for remodeling ? I see you also have quite a few PR's open with remodelling label
<pedronis> ijohnson: we progressed quite a bit
<pedronis> that forum topic is mostly concerened with reregistration, switching model
<pedronis> ijohnson: I'm close to eod but we can chat more tomorrow
<jdstrand> ijohnson: the tools already handle those, yes
<jdstrand> ijohnson: (https://docs.snapcraft.io/interface-hooks)
<ijohnson> pedronis: okay sure I will try to schedule a meeting tomorrow to discuss more
<ijohnson> jdstrand: hmm okay well it looked like using an interface hook was the problem that om26er was running into
<jdstrand> ijohnson: ah, the tools know about connect-*, prepare-* but not disconnect-*
<jdstrand> I see that r82 uses disconnect-plug-...
 * jdstrand adjusts tools
<jdstrand> roadmr: hi! can you pull 20190716-1700UTC? not urgent. fixes om2er's issue (cc ijohnson)
<roadmr> jdstrand: sure thing, I'll queue it up
#snappy 2019-07-17
<pedronis> mvo: hi, you did a full pass on 7020 now?  I will address comments today or tomorrow
<mvo> pedronis: yes
<ackk> hi, we (maas) currently have some scripts that scan /sys to find info about the system (both ardware and configuration/modules/...). this currently doesn't work in the snap, it doesn't seem there is an interfaces that lets you read the whole /sys. Would it be possible to do that?
<sparkiegeek> to add some flavour, and as a non-exhaustive example; we currently have `find /sys/devices/ -name sriov_numvfs`
<ackk> sparkiegeek, that does't actually cause errors AFAICT, the main one that's failing is  'find /sys -name modalias'
<ackk> but also we're using lshw/lscpu/lsusb/... and those don't work
<sparkiegeek> pedronis: ^ thoughts?
<Chipaca> doesn't hardware-observe give you those?
<Chipaca> ackk, sparkiegeek?
<ackk> Chipaca, so, for the find -name modalias I can see the files but the whole /sys is nobody:nogroup so I can't read them as root
<ackk> Chipaca, https://paste.ubuntu.com/p/mkQprpncMQ/
<ackk> (I assume that's the issue, at least)
<ackk> Chipaca, (that snap does have hardware-observe connected)
<Chipaca> why's it getting nobody'd?
<Chipaca> it's root:root outside
<Chipaca> on 1604 at least
<Chipaca> it's root:root inside as well, in 1604
<ackk> Chipaca, I wonder if it's because I'm using the daemon-enabled snapd from jdstrand?
<Chipaca> ackk: is it also nobody:nogroup outside on the system you're looking at?
<ackk> Chipaca, oh, it is
<ackk> wth
<ackk> (I'm in a lxd)
 * ackk tries rebooting 
<ackk> nope, also /dev files are nobody:nogroup
<ackk> somethin is messed up here, I guess
<pedronis> Chipaca: thanks for the review
<Chipaca> pedronis: thanks for the code
<Chipaca> pedronis: what do you mean in https://github.com/snapcore/snapd/pull/7083#issuecomment-511885260 ?
<jibel> Hi, I just reported https://forum.snapcraft.io/t/cannot-launch-snaps-on-eoan/12341, is it known?
<pedronis> Chipaca: mvo is looking into that. Now that what we check is the type, we need to make there's only one snap installed with that type (and called snapd)
<pedronis> same logic we have/ad for core
<pedronis> *make sure
<pedronis> *have/had
<Chipaca> easy way would be to enforce the name in install
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> jibel: I don't know if it's known. I've asked for more info. Please do use preformatted-text for the output of commands (i've edited your post)
<pedronis> Chipaca: that's what the check does
<Chipaca> pedronis: :)
<pedronis> I mean coreNameCheck is that check for core
<jibel> Chipaca, done.
<Chipaca> jibel: something is very broken
<jibel> indeed :)
<Chipaca> jibel: was there a new systemd since you booted last
<Chipaca> I seem to remember somebody saying something about the latest systemd + kernel combo breaking mounts
<Chipaca> not sure that was in eoan though, might've been fedora
<jibel> Chipaca, list of updates before last reboot https://paste.ubuntu.com/p/wSvJmy4r3w/. There is no update of systemd
<Chipaca> jibel: what do you get from zgrep systemd.*running.in.system.mode /var/log/syslog* ?
<pedronis> Chipaca: it was arch, https://forum.snapcraft.io/t/snap-mounts-broken-with-kernel-5-2-and-systemd-242/12272
<Chipaca> (hoping that still works in eoan)
<Chipaca> things we should add to 'snap version': systemd version, and machine architecture
<jibel> Chipaca, nothing, just very old stuff
<Chipaca> jibel: what systemd version are you on _now_?
<jibel> Chipaca, 240-6ubuntu9
<Chipaca> jibel: it does look very similar to the thing on arch, but the systemd version is older so i dunno
<Chipaca> maybe the problem is linux 5.2
<jibel> I can boot on previous kernel
<Chipaca> jibel: systemctl --all --failed |grep snapd
<Chipaca> plz
<jibel> Chipaca, nothing if I grep snapd however if I grep snap I get https://paste.ubuntu.com/p/hdr5qKQrh7/
 * jibel reboots brb
<Chipaca> yeah that's bad
<jibel> Chipaca, it works with 5.0 and it's broken with 5.2
<Chipaca> huzzah
 * Chipaca hugs his 1604 to his chest
<Chipaca> jibel: please add that to the forum topic
<jibel> I did it
<Chipaca> jibel: awesom
<Chipaca> jibel: I've linked to your topic from the arch one
<Chipaca> jibel: can you work with somebody from the kernel team to bisect this?
<jibel> sure
 * jibel moves -> #ubuntu-kernel
<Chipaca> jibel: thank you!
 * Chipaca hops on to that # also, out of curiosity
 * Chipaca breaks a take
<ogra> sil2100, hey ho, do you know if the CM3+ fix also made it into the classic images (if not, what does it take to update their FW ?)
<sil2100> ogra: hey, it did, but only for disco and eoan, we didn't SRU it to bionic yet
<ogra> sil2100, i assume thats planned ?
<sil2100> It might be a good idea, but I don't think we explicitly talked about it - might be that we'd want that before the point release
<sil2100> I'll poke Dave today
<ogra> thanks !
<ackk> jdstrand, hi, fwiw instructions on  https://people.canonical.com/~jamie/snapd-daemon-user/README don't seem to work anymore for me. the test snap doesn't work, but my maas snap does. also the reported version is 2.39.3
<pedronis> mvo: I did a pass over 7107, there's more work needed
<ackk> Chipaca, fwiw https://paste.ubuntu.com/p/jKyKBmT4Jc/ is what I see
<ackk> that's probably still ok since I think we could just search for modalias under /sys/devices
<ackk> but not entirely sure
 * diddledan pops it in here too for people to have a nosey: https://sc-jsonnet.readthedocs.io/
<diddledan> err
<diddledan> wrong url
<diddledan> https://forum.snapcraft.io/t/yaml-code-sharing-and-reuse/12342
<diddledan> (it was a related url anyway, but I wanted to share my forum post)
<Chipaca> jibel: out of curiosity, what's 'snap list --all | wc -l' for you?
<Chipaca> with 20+ snaps installed, on 5.2.x, with systemd 240, can't repro the issue
<jibel> Chipaca, 22
<jibel> Chipaca, 41
<Chipaca> ah
<Chipaca> small difference :)
<jibel> Chipaca, https://paste.ubuntu.com/p/RnkKVNStZX/
<Chipaca> ok, i'll ramp things up to that level and see
<Chipaca> yess
<Chipaca> at 42 snaps installed, i got a broken mount
<diddledan> nobody needs more than 42 - that's the perfect number
 * roadmr hands 42 bytes of RAM to diddledan
<roadmr> ah, snaps - sorry, was missing context :)
<diddledan> hmm
<diddledan> :-p
<roadmr> yes, 42 is ideal
 * dot-tobias says hi
<sparkiegeek> diddledan: https://en.wikipedia.org/wiki/Perfect_number no it's not! :P
<ackk> https://youtu.be/RyFr279K9TE?t=33
<dot-tobias> zyga: I'm suddenly getting store rejections from failed layout target lintings. The previous revisions went through review just fine, I was mapping $SNAP/some/path to $SNAP_DATA/some/path. Is this expected?
<Chipaca> YESSS i can reproduce the issue without snaps
<Chipaca> wooo woo wo w
 * Chipaca goes to sell it on the black market
<diddledan> is it a kernel bug?
<Chipaca> no, it's...
<Chipaca> Mail server hit by UniSpammer.
<Chipaca> no wait, it's
<Chipaca> The file system is full of it
 * Chipaca puts away the BOFH snap before it does any real harm
<mvo> Chipaca: \o/
<mvo> Chipaca: where can I read more? bugrport? forum?
<Chipaca> mvo: i'm in the progress of writing the reproducer into a script, and then will add it to the forum, and then a bug
<Chipaca> mvo: i'll let you know when it's a script you can run :-)
<mvo> Chipaca: thank you!
<seb128> mvo, Chipaca, is there any workaround atm? Till was asking because he uses chromium as his browser which was made into a snap by defualt in eoan and he's without a working webbrowser now which is a bit of an issue for work
<jibel> boot with kernel 5.0
<diddledan> eep
<Chipaca> mvo: https://paste.ubuntu.com/p/VCpzGxvy6h/
<Chipaca> seb128: snap list --all, for any broken snaps, if disabled remove, if enabled (== current) disable and enable
<Chipaca> seb128: but beware dependencies
<diddledan> worth checking if earlier systems have any problems running that reproducer, too
<Chipaca> seb128: not sure if the bug is in the kernel or in util-linux, but it's in one of them two
<Chipaca> so it could be a lot worse
<dot-tobias> I'm trying to define a content interface for my snaps. Upon installation, I get this error: âINFO snap <snap-name> has bad plugs or slots: my-slot-name (unknown interface "my-slot-name")â I gathered from https://docs.snapcraft.io/content-interface that the slot name can be arbitrary?
<diddledan> dot-tobias: you need to do two things: add a top-level slots: block which defines your slot, and then an app-level slots: block that ties your slot name to an app
<dot-tobias> diddledan: Ok, thanks. Do you happen to have an example how the app-level stanza looks like? Just slots: [my-slot-name]?
<Chipaca> #1836914
<dot-tobias> diddledan: Hm, followed this example https://github.com/anbox/anbox/blob/cd829e9ccd3a5d654c8aa5e16e32f0d3915d54a8/snap/snapcraft.yaml#L34 but still getting the same error.
<seb128> Chipaca, thx
<diddledan> dot-tobias: did you also add the top-level item? https://github.com/anbox/anbox/blob/cd829e9ccd3a5d654c8aa5e16e32f0d3915d54a8/snap/snapcraft.yaml#L18
<ijohnson> is there a clean way to do a type assertion with go-check? I want to check that an error is of a certain type
<diddledan> ijohnson: https://tour.golang.org/methods/15?
<ijohnson> diddledan: specifically with the go-check package: https://godoc.org/gopkg.in/check.v1
<pedronis> ijohnson: look for FitsTypeOf
<ijohnson> pedronis: ah perfect thanks
 * diddledan goes back to lurkioing
 * Chipaca would like FitsTypeOf to raise a TooLarge error :-p
<ijohnson> pedronis: I was going to break out a small PR from netplan apply to make it easy to create hidden commands in snapctl
<diddledan> Chipaca: what about returning Almost?
<pedronis> ijohnson: sounds good
<Chipaca> diddledan: you get it :)
<diddledan> TryHarer?
<diddledan> TryHarder**
<Chipaca> MoreLubricant
<Chipaca> GetAHammer
<diddledan> haha
<pedronis> ijohnson: otherwise of course you can also use a go type assertion, _, ok := x.(T) and check for ok
<pedronis> depends a bit exactly what you need
<diddledan> or IGuessItWorks
<ijohnson> yeah I was hoping there was a go-check thing to use, and there is so that seems more "idiomatic snapd tests"
<pedronis> yes
<ackk> sergiusens, hi, around?
<pedronis> ijohnson: forgot to mention, have you looked how adding hidden commands works in cmd/snap, we probably want the same
<pedronis> or sameish
<ijohnson> pedronis: I did not, is it different than using go-flags Command.Hidden flag?
<pedronis> it's the same
<pedronis> but there's a pattern there
<pedronis> please look :)
<ijohnson> sure, is there a hidden command off the top of your head you could point me to?
<pedronis> ijohnson: interfaces nowadays
<ijohnson> pedronis: ack, this actually looks very similar to what I have now
<sergiusens> ackk: nope, travelling and packing with the family today
<ackk> sergiusens, ah cool, enjoy then
<pedronis> mvo: thanks for adding checkSnapdName. I reviewed 7086 , just one odd thing there (cc Chipaca)
<pedronis> oops, I meant 7084
<pedronis> heh, fail
<pedronis> mvo: Chipaca: I meant actually really 7083 (3/4)
<mvo> pedronis: no worries, I will check the feedback (either today or tomorrow morning)
<pedronis> thx, I can tweak as well tomorrow if nobody gets to it before
 * pedronis going to eod
<pedronis> Chipaca: https://forum.snapcraft.io/t/snap-layouts/7207/21 this looks like it should be its own topic
<pedronis> (it's not about the docs but a issue of usage/review tools)
<ijohnson> pedronis: fyi I filed to do hidden snapctl cmds in https://github.com/snapcore/snapd/pull/7119
<ijohnson> pedronis: I'm now working on another PR for passing through the exit code, etc. from the snapd daemon to the snapctl client as requested
<ijohnson> may or may not get that PR finished today
<pedronis> ijohnson: thx
<jdstrand> ackk: ok, I needed to modify test-snapd-daemon-user and made it not work with the deb I gave you. let me update the deb and README
<ackk> jdstrand, thanks!
<jdstrand> ackk: ok, new deb and updated README are uploaded
<jdstrand> ackk: you'll need to use 'system-usernames: [ snap_daemon ]' in your snap now after all
<jdstrand> ackk: 'system-usernames' is subject to change still (should have a decision tomorrow), but 'snap_daemon' shouldn't change
<jdstrand> (and it may not be a list, but the yaml is the easy part, you can be reasonably confident that changing the rest of your snap to use 'snap_daemon' will mean you're ready when the feature lands
<jdstrand> )
<jdstrand> roadmr: hey, I know this was a quick one, but can you pull 20190717-1931UTC?
<roadmr> jdstrand: oh hehe :) sure
<jdstrand> roadmr: thanks! :)
<ackk> jdstrand, thanks!
<diddledan> wanna see some voodoo? https://forum.snapcraft.io/t/yaml-code-sharing-and-reuse/12342
#snappy 2019-07-18
<pedronis> mvo: hi, I reworked 7020
<mvo> pedronis: nice, thank you. I have a look
<Chipaca> pedronis: do you remember offhand if aliases can have underscores in them?
 * Chipaca has the silliest doubts
<pedronis> Chipaca: they can
<Chipaca> (this is related to a user question)
<pedronis> they allow quite a bit more latitude than app names
<pedronis> because one of their goals is to support a reasonable range
<pedronis> of upstream binary names
<Chipaca> good good :-)
<Chipaca> somebody i swanting to package a jenkins plugin
<Chipaca> and it seems those use underscores
<Chipaca> so aliases ftw
<Chipaca> (and a snapped jenkins would be yuge)
<pedronis> ^[a-zA-Z0-9][-_.a-zA-Z0-9]* is their regexp
<pedronis> oops with a $
<Chipaca> whoa, england remembered how to rain
<pedronis> mvo: mmh, we did this experimentally:  cmd/snapd: ensure GOMAXPROCS is at least 2
<pedronis>  but it didn't help. did we remove it ?
<mvo> pedronis: we did not remove it, there is a card, I can do thi snow
<Chipaca> something weird just happened
<Chipaca> or maybe not i'm not sure
<Chipaca> I merged #7083
<Chipaca> and #7086 also merged
<Chipaca> were those two the same thing?
<Chipaca> (that would explain github showing no diff â¦ i thought it was just confused)
<Chipaca> those are 3/4 and 4/4 of the snapd type work
<Chipaca> truly I don't see a commit in 4/4 that is about what 4/4 claims to be about
<Chipaca> Â¯\_(ã)_/Â¯
<Wimpress> Morning o/
<pedronis> Chipaca: yes, seems there is no actual renaming there (??)
<Chipaca> yeah, probably a mis-push
<Chipaca> made a note about it
<Wimpress> I just upgrade from 19.04 to 19.10 daily and more than half my installed snaps are showing a "broken" in `snap list`.
<Chipaca> Wimpress: kernel 5.2
<Chipaca> Wimpress: buggy mc bug
<Wimpress> Awesome.
<Wimpress> "mc bug" being?
<Chipaca> Wimpress: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836914
<Wimpress> Thanks.
<Chipaca> niets te danken
<Chipaca> clearly it's suse's fault
<ogra> Chipaca, leave my girlfriend out of the discussion please !
<Chipaca> ogra: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836914/comments/5
<Chipaca> ogra: i have iferrutable evidence
<Chipaca> or is that iferrutable edivence
<mvo> the two ubuntu-core-18 prs from sergio need a second review and should be easy wins
<ogra> lol
<ogra> damn ... i'll talk to her then to not do such stuff in the future
<Wimpress> Chipaca: Anyway to manual remount the "broken" snaps?
<Chipaca> Wimpress: if you're brave, yes
<Chipaca> Wimpress: snap list --all
<Chipaca> Wimpress: remove disabled,broken snaps
<Chipaca> (just to make things easier)
<Chipaca> Wimpress: then, disable+enable broken snaps
<Chipaca> Wimpress: should do it
<Chipaca> Wimpress: let me know, as i haven't heard back from anybody that's done this
 * Wimpress drinks brave juice
 * Chipaca spikes Wimpress's juice
<Wimpress> Remove the disabled snaps firs?
<Chipaca> Wimpress: in --all, yes, ie old revisions that just happened to not mount
<Chipaca> somebody let popey know not to jump to 5.2 because this'd be a nightmare for him
<Wimpress> I have done
<Chipaca> it starts hitting people at ~40 snaps mounted
<Wimpress> He is on vacation.
 * Wimpress has 287 snaps installed
<Chipaca> i know, thank you for letting him know
 * Chipaca hugs Wimpress 
<Chipaca> Wimpress: i didn't have you on my list of people with a lot of snaps, i do now
<mvo> Chipaca: any tl;dr updates on the mount issue?
<Chipaca> mvo: kernel bug
<Chipaca> mvo: don't use 5.2 for a bit
<Chipaca> mvo: https://github.com/torvalds/linux/commit/33ec3e53e7b1869d7851e59e126bdb0fe0bd1982
<Chipaca> (if you're curious)
<Chipaca> mvo: it's very much a race, hits once you're at ~40 snaps mounted (counting old revisions etc, so ~13 snaps is enough if you've got the usual 3x)
<popey> Chipaca: thanks. I'm on vacation nowhere near snaps :)
<Chipaca> popey: i didn't intend for that to reach you synchronously on vacation
<popey> I have 287 snaps at the last count
<popey> It's cool :)
<Wimpress> Snap
<popey> Good to know!
<Wimpress> I had 287 until I started sorting this out.
<popey> Haha
<popey> That's 287 X 3 here :)
<popey> Anyway, have fun. Bye!
 * Chipaca has fun as instructed
 * Chipaca ensures to always have a company-approved amount of fun
 * Chipaca sets up N+2 sources of fun to accommodate network issues and demand surges
<Wimpress> Chipaca: The disable/enable trick doesn't work :-(
<Wimpress> `- Setup snap "mumble" (463) security profiles (cannot find installed snap "mumble" at revision 463: missing file /snap/mumble/463/meta/snap.yaml)`
<Chipaca> ah
<Wimpress> Get something like that during the enable ^
<Chipaca> Wimpress: so
<Chipaca> Wimpress: the issue is more complicated probably
<Chipaca> Wimpress: try disabling/enabling *everything*
 * Wimpress decides to get coffee...
<Chipaca> the problem is the kernel gets the loop devices discombobulated with their backing file
<Chipaca> so maybe snap A shows up as broken but it's snap B that needs to be disabled to release the device
<Chipaca> I don't know
 * Chipaca weeps
 * Chipaca remembers having fun
<Chipaca> mvo: is this affecting people not on the bleeding edge?
<Wimpress> Chipaca: I'm down to 25 snaps.
<Wimpress> 5 are broken.
<Chipaca> Wimpress: at this point a reboot might be easier
<Wimpress> I am remove a couple of snaps. Rebooting. See how many are broken.
<Chipaca> Wimpress: ah
<Chipaca> :-/
<Wimpress> I am starting to suspect there is not alower limit on the number of snaps installed.
<Chipaca> Wimpress: you can see more info about the breakage if you look at the failing mount units
<Wimpress> At this point I am interested to know if there is a lower limit.
<Chipaca> Wimpress: systemctl --all --failed |grep snap
<Chipaca> Wimpress: ok
<Chipaca> Wimpress: the number i was quoting was how many i had had to add before getting a solid reproducer
<Chipaca> Wimpress: it's a race, though, so it's certainly possible to lose it with just two snaps :-/
<Wimpress> So, enable/disable does not get a "broken" snap working.
<Wimpress> Refreshing from a different channel doesn't get a "broken" snap working.
<Wimpress> But remove then install a "broken" snap does get you a working snap.
<Wimpress> I have 19 snaps installed. 1 (random on each boot) will always be in a broken state.
<ackk> hi, should one use SNAP_NAME or SNAP_INSTANCE_NAME for prefixed names like abstract unix sockets or SHM prefixing?
<ackk> I see snapcraft-preload uses $SNAP_NAME at the moment, but won't that cause collisions if you have multiple instances?
<Chipaca> ackk: depends :-) but probably SNAP_INSTANCE_NAME
<Chipaca> ackk: if you use SNAP_NAME, you risk trying to talk to some other instance of yourself
<Chipaca> ackk: and we all know that's when the world ends
<ackk> Chipaca, yeah but snapd check those names, right? so maybe snap.foo_bar won't be allowed for snap "foo" if snapd uses SNAP_NAME
<ackk> Chipaca, ISTR it's SNAP_NAME for abstract sockets for socket activation
<ackk> but that was before SNAP_INSTANCE
<Chipaca> ackk: it _should_ get blocked, yes
<Chipaca> ackk: i'm pretty sure it will get blocked, even :)
<ackk> Chipaca, which case should?
<Chipaca> ackk: using SNAP_NAME for SHM and dbus things
<Chipaca> ackk: abstract unix sockets, it's more a free-for-all
<Chipaca> whoever gets there first will probably win
<Chipaca> and then things'd be weird
<ackk> Chipaca, uhm, no, SNAP_NAME is what snapcraft-preload uses for /dev/shm/
<Chipaca> (but i'm not sure we mediate them properly)
<Chipaca> ackk: ?
<ackk> <Chipaca> ackk: using SNAP_NAME for SHM and dbus things
<Chipaca> ackk: well that probably won't work for an instance'd snap, then
<jamesh> ackk: I don't think dbus slots are going to work with instanced snaps
<jamesh> in general, applications hard code the bus names they try to acquire, and clients hard code the bus names they want to talk to.
<ackk> jamesh, I'm not talking about dbus slots. mainly /dev/shm files and abstract sockets for socket activation
<ackk> it doesn't seem ValidateSocket does any filtering
<Chipaca> ackk: i don't think we look at abstract socket names in any way
<Chipaca> might be wrong, but i don't think so
<Chipaca> ackk: i mean: snap foo can create and use an abstract socket that claimed it was from snap bar in some way, and it'd work
<ackk> ok
<Chipaca> ackk: it shouldn't be able to talk to a socket from snap bar though
<Chipaca> ackk: so if it uses SNAP_NAME, it'll work for itself if it's instanced and the non-instanced snap didn't create the socket (yet)
<Chipaca> makes sense?
<Chipaca> ackk: much like with regular ports, snapd does no arbitration
<Chipaca> you can have N snaps trying to grab port 80
<ackk> right
<Chipaca> only one will 'win' :)
<ackk> I see the apparmor template is for /dev/shm/snap.$SNAP_INSTANCE_NAME
<ackk> so snapcraft-preload should use that too
<Chipaca> yes, shm should use instance name, yes
<Chipaca> which is why i said that if snapcraft-preload doesn't use that, it won't work for instanced snaps
<Chipaca> instance-named snaps? instancedated?
 * Chipaca gives up
<ackk> instanced? :)
<ackk> instant snaps!
<jamesh> ackk: https://github.com/snapcore/snapd/blob/master/snap/validate.go#L211-L219 <- there's the validation for abstract sockets for socket activated services.
 * Chipaca gets extra whimsical just before mealtime
<ackk> jamesh, ah, right
<Chipaca> oh, neat, i'd forgotten that bit
<Chipaca> jamesh: nice
<ackk> jamesh, so that shuld be the instance instead?
 * ackk forgot he wrote that
<ackk> I did have a memory that some validation was in place
<Chipaca> huh, i wonder what maciej meant about it coming from the snap decl
<jamesh> ackk: as the socket name comes from meta/snap.yaml, and already has the snap name in place, it doesn't really fit with instanced names
<Chipaca> ah probably that :-)
<Chipaca> s/snap declaration/snap yaml/ i guess
<jamesh> ackk: if you want instance friendly unix domain sockets, consider putting them in $SNAP_COMMON (i.e. not abstract)
<ackk> jamesh, ah, you have a point
<Chipaca> non-abstract are safer anyway :-p
<ogra> pfft ... just pipe into netcat :P
<ogra> sockets ... pfft
<jamesh> it'd be nice if there was a system level area under /run for a snap to use for this kind of thing
<ogra> you could use /tmp which is transparently overlayed
<jamesh> ogra: the validation code requires it start with $SNAP_DATA, $SNAP_COMMON, or $XDG_RUNTIME_DIR (the last of which doesn't make sense until we've got user session daemons)
<ogra> oh, why is that ? /tmp should be as safe as these dirs are since it is fully confined
<jamesh> it's systemd that binds the socket
<jamesh> not something within the sandbox
<Chipaca> meaning that the path needs to be the same outside and inside
<ogra> ah
<ogra> sorry, i missed that part ... ignore me then :)
<Chipaca> now that there's no random component in the tmp path we _could_ possibly make it work
<jamesh> would systemd create the parent directories with the right permissions though?
<Chipaca> jamesh: Â¯\_(ã)_/Â¯ no idea
<Chipaca> anyway, lunch
<Chipaca> jamesh: don't forget to sleep sometime
<jamesh> Chipaca: good idea.  It's past 7pm
<Chipaca> ah, i figured it'd be even later
<Chipaca> even so, go get some life in that work/life balance thing
<Chipaca> :)
<Chipaca> wait, that sounded dangerously close to 'get a life'
 * Chipaca backs away from the whole thing
<jamesh> https://www.youtube.com/watch?v=PrVSHa_5Tw4
<Chipaca> mvo: #7102 is green, has two +1's, your call if you merge or address the indent question
<Chipaca> mvo: #7100 is also green and has two +1's and I'd merge it but dunno :-)
<diddledan> dang, wimpress has me beat by a long way: I only have 83 snaps installed
<Chipaca> diddledan: try 'snap list --all | wc -l' :-)
<diddledan> 154
<diddledan> that's better :-)
<Chipaca> -1 for the header line, fwiw
<ogra> yeah
<diddledan> d'oh
<Chipaca> no cheating
<mvo> Chipaca: sorry, was in a meeting, let me read backlog
<pedronis> Chipaca: thanks for the review
<mvo> Chipaca: I tweak 7102 now
<mvo> pedronis: thanks for the updates to 7020, not quite finished reading but looks very nice so far
<mvo> Chipaca: what was the bugnumber of the kernel losetup issue again?
<Chipaca> mvo: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836914
<mvo> Chipaca: thank you
<pedronis> Chipaca: mvo: btw now that snapd having a type has landed I think 6923 and 6950 are also unblocked
<geodb27> People : hi ! snap is stuck on one of my lxd machine : it refuses to launch "snap restart lxd" complaining that snap "lxd" has "refresh-snap" change in progress.
<geodb27> I've tried many things, including "snap abord" with the task list, but things remains the same. What can I do to have things up and running again without losing any data ?
<Chipaca> geodb27: hi, sorry you're having trouble
<Chipaca> geodb27: can you pastebin the output of 'snap changes'?
<geodb27> Thanks for your help Chipaca. Here it is : https://pastebin.com/6PmTm0Lx
<Chipaca> geodb27: and the output of 'snap tasks 20' ?
<geodb27> https://pastebin.com/frhzSbwq Here it is.
<Chipaca> looks like stopping the lxd services is struggling
<Chipaca> geodb27: what's the output of snap logs lxd ?
<geodb27> there is not that amount of informations in "snap logs lxd". It lists the kernel modules in use (I'd guess) and only one warning concerning swap accounting.
<Chipaca> geodb27: and what does 'systemctl status snap.lxd.activate.service snap.lxd.daemon.service' think?
<Chipaca> geodb27: also the output of 'snap services lxd' please
<geodb27> https://pastebin.com/6qkSrTCi I included the latest even if it complains about an error concerning the snapd socket.
<Chipaca> geodb27: can you retry it?
<Chipaca> doesn't look good though
<geodb27> Yes, got it.
<geodb27> lxd.activate  activÃ©   inactif  -
<Chipaca> geodb27: 'journalctl -u snapd' might be revealing also
<geodb27> lxd.daemon    activÃ©   actif    socket-activated
<geodb27> Oh, hang on... Don't know what really helped out there, but "snap restart lxd" seems to be working, at last...
<Chipaca> hah, i was about to suggest stopping them manually, but that might also work
<Chipaca> in fact, i'd written this:
<Chipaca> geodb27: let's try this: sudo systemctl stop snap.lxd.* snapd && sudo systemctl start snapd
<geodb27> Well it failed, but I know why : the revert to 3.14 went through, after a long while. But since now this machine is the only one of the lxd cluster with version 3.14, it can't start. I'll have to install latest 3.15 on this machine.
<Chipaca> geodb27: sounds like you're unblocked, at least
<Chipaca> i need to set aside some time to figure this one out though
<Chipaca> suspect socket activation is breaking things for us
<Chipaca> geodb27: good luck! and do reach out if it gets stuck again
<geodb27> Indeed. In parallel, while you guided me to find a solution, I issued in another terminal "apt-get update && apt-get upgrade -y && apt dist-upgrade -y && apt autoremove -y".
<geodb27> Could be that there was something not up-to-date that led to this "dead-lock'. snap refresh lxd is in progress now. I'll let it go.
<geodb27> Thanks a lot for your kind help !
 * diddledan moans at jdstrand "too many defined layouts (18 > 10) lint-snap-v2_layout"
<diddledan> guess I need to trim them
<jdstrand> diddledan: this was actually not only my decision. zyga and I decided on 10, but then I saw one with 8 so just upped it to 15 yesterday (not in prod yet)
<diddledan> hah!
<jdstrand> but layouts take resources so with a system with hundreds of snaps...
<diddledan> aye
<diddledan> I put so many as an attempt to reduce "magic" in my launcher script:
<diddledan> https://www.irccloud.com/pastebin/snNh71xP/layout.yaml
<diddledan> I prefer declarative rather than imperative so I felt declaring the layout as a better solution than shoving the world into LD_LIBRARY_PATH
<ackk> jdstrand, hi, tested your latest snap package w/snap_daemon, works fine. just one note, the test snap still doesn't
<Chipaca> diddledan: https://www.youtube.com/watch?v=tljyCX8-Hw8
<ackk> jdstrand, not an issue for our testing though
<jdstrand> ackk: that is puzzling, I both tested it and use it in spread tests. can you paste what you did?
<ackk> jdstrand, I followed the readme, one sec
<ackk> jdstrand, odd, I tried again and was getting:
<ackk> $ sudo test-snapd-daemon-user.drop snap_daemon
<ackk> execv failed: No such file or directory
<ackk> jdstrand, then i removed and re-added the snap and it worked
<jdstrand> the combination of deb and disabling reexec and installing a snap can be delicate
<ackk> jdstrand, do you need to export SNAP_REEXEC=0 every time in the shell?
 * jdstrand chalks it up to that
<jdstrand> ackk: yes
<ackk> jdstrand, ah so maybe that's whyt
<ackk> *why
<jdstrand> for 'snap'
<ackk> jdstrand, is there an ETA for 2.40 release?
<jdstrand> modifying /etc/environment is good for snapd and it you log out
<ackk> right
<jdstrand> ackk: idk, but fyi, this is now 2.41 material
<ackk> jdstrand, so snap_daemon is 2.41 ?
<jdstrand> yes
<ackk> ok
<diddledan> hopefully 2.41 will enable me to get the much requested makemkv out to stable
<jdstrand> ackk: have a meeting today on a final detail for snap.yaml, then it is just finishing a couple small details and iterating on PRs
<ackk> jdstrand, nice, thanks
<jdstrand> ackk: ie, I don't foresee it later than 2.41
<ackk> jdstrand, btw, posted https://forum.snapcraft.io/t/request-for-auto-connection-of-interfaces-for-maas/12367
<cachio> mvo, hey, any idea who created the snap test-snapd-with-configure ?
<cachio> I need to create test-snapd-with-configure-core18
<oSoMoN> jdstrand, hey, I'd love to have your opinion on https://forum.snapcraft.io/t/auto-connecting-the-cups-control-and-password-manager-service-interfaces-for-the-chromium-snap/4592/7
<mvo> cachio: in a meeting but let me check
<cachio> mvo, np, I'll upload the new one
<mvo> cachio: cool, go for it
<pedronis> mvo: I reviewed 7122, have a nitpick but maybe it doesn't make sense completely
<pedronis> not sure
<jdstrand> oSoMoN: on my todo (thinking)
<oSoMoN> thanks!
<mvo> pedronis: thanks, let me see
 * cachio lunch
<pedronis> mvo: let me know if what I had in mind isn't clear
<pedronis> anyway I gave a +1, it's really nitpick, I suppose I'm slightly allergic to GlobalRootDir (I know why it exists)
<pedronis> jdstrand: I gave my general +1 (but not details) to gpio-control and packagekit-control, though the former still needs to be locked down to be superprivileged
<pedronis> afaict
<jdstrand> pedronis: ack, thanks
<mvo> pedronis: hm, how would boot/kernel_os_test.go pick up this bootdir in the test suites?
<mvo> pedronis: happy to change it but not fully sure what you have in mind, but we can have a quick HO tomorrow, I'm almost eod
<pedronis> mvo: I might not have been very clear
<mvo> pedronis: or (more likely) I'm just a bit slow this evening, I will look at it with fresh eyes in the morning and if I doN't figure it out we can have a chat, does that sound good?
<jdstrand> pedronis: curious if you have an opinion on when to create the (shared) snap_daemon user. I'm of two minds: a) at the time a snap uses it and b) after snapd finishing fetching declarations, add any users that don't already exist). 'a' is easy but feels at the wrong level and means inconsistency between systems that have snaps that use the user and ones that don't. if 'b', I'm thinking in daemon.go-- is
<jdstrand> there an area I should be looking at?
<jdstrand> pedronis: err s/at the time the snap user it/at the time a snap that specifies it is installed/
<jdstrand> finishes*
<jdstrand> meh, so many typos. hope you can wade through them :)
<pedronis> jdstrand: I'm not quite sure about the worry related the inconsistency, why would we have the user on a system without snaps using it?
<pedronis> I'm probably missing something
<jdstrand> pedronis: the question is whether to have the shared users unconditionally there or only as needed
<jdstrand> pedronis: unconditionally gives consistency for all systems running a snapd that supports the feature (and eventually the snap declarations in the store)
<jdstrand> pedronis: which may make sense for snap_daemon, but probably does not make sense for snap_other or scope: private
<jdstrand> pedronis: so in that light, I think I answered my own question (at install)
<jdstrand> which is cool, cause that is easy :)
<pedronis> jdstrand: yes, that seems easier and sensible
<jdstrand> pedronis: thanks for being my sounding board :)
<pedronis> heh, np
<pedronis> mvo: did you re-review 7020, or not quite yet?
<pedronis> Chipaca: I think I never noticed it, but the error handling code in client is a bit strange (from a HTTP POV)
 * zyga sends greetings from the eastern part of Italy 
<zyga> crossing over to Slovenia soon
<mvo> pedronis: I did not :( sorry ! in my morning or later tonight
<pedronis> np, just wondered
<pedronis> Chipaca: could you quickly double check the changes related to context I had to do to fix conflicts in the rereg PR: https://github.com/snapcore/snapd/pull/7007/commits/d904093cc19e1d13ce6b474bec7cdc5220711a82
 * cachio afk
<Chipaca> pedronis: LGTM
<roadmr> jdstrand: review-tools 20190717somethingsomething are now in prod \o/
<jdstrand> roadmr: yeah! thanks :)
<sergiusens> mvo: hey, any reason the bare base is not on stable?
#snappy 2019-07-19
<ackk> hi, I'm getting a weird error when testing the maas snap. In logs for various processes I see "mkdir: cannot create directory â/var/snap/maasâ: Read-only file system"
<ackk> I tried both restarting the snap and the whole system
<pedronis> mvo: thanks for reviewing again verify-boot, I merged it now
<ackk> anyone might have an idea on how to debug this issue?
<ackk> I'm using the non-root-user enabled snapd 2.40
<mvo> pedronis: cool, thank you!
<pedronis> Chipaca: hi
<Chipaca> pedronis: hiya
<Chipaca> pedronis: not ready for you yet i'm afraid
<Chipaca> :-|
<pedronis> Chipaca: late today, or are we talking monday?
<Chipaca> pedronis: hmm. I might make it for late today, but monday is safer -- what'd you rather?
<pedronis> Chipaca: monday is easier
<pedronis> Chipaca: can you put an actual meeting in the calendar for monday when it works for you
<Chipaca> pedronis: monday it is then
<Chipaca> i'll probably sneak in some time on this over the weekend to make up for this week which has been less than productive
<Chipaca> hopefully school being out and the boys wanting to spud out for a while will be conducive
<Chipaca> pedronis: calendaered
<Chipaca> pedronis: you've got Edit, so you can move it if you need/want to
<pedronis> Chipaca: you picked the wrong monday I think
<pedronis> 29 vs 22
<Chipaca> pedronis: augh
<Chipaca> moved
<Chipaca> oh wait now it conflicts with my 1:1
<Chipaca> moving again
<Chipaca> done
<pedronis> Chipaca: thanks
<pedronis> btw my other PRs are ready for reviews,  and 6923 from pawel is unblocked and needs a 2nd review
<Chipaca> pedronis: +1 to both of yours, and +1 to pawel's even though I hate Â«for _, cstrs1 := range cstrsÂ»
<Chipaca> casters? coasters? castraters?
<Chipaca> and with that, i'm out for a few hours
<Chipaca> should be back in ~4h modulo everything
<pedronis> mvo: https://forum.snapcraft.io/t/broken-dependency-of-content-snaps-during-seeding/11566/18 you meant (classic) image builds instead of deb packages ?
<mvo> pedronis: eh, yes, let me fix htis
<mvo> pedronis: thanks
<pedronis> np
<ogra> gra@pi4:~$ grep PRETTY /etc/os-release
<ogra> PRETTY_NAME="Ubuntu Core 18"
<ogra> ogra@pi4:~$ ps ax|grep unattended
<ogra>  2209 ?        Ssl    0:00 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal
<ogra> mvo, ^^^^ ??????
<mvo> ogra: check with rbalint
<mvo> ogra: but it seems thats the only reliable way these days to hook into the shutdown
<ogra> mvo, oh, so the name is misleading ?
<mvo> ogra: eh, uh - this is on core18
<ogra> yes
<mvo> ogra: sorry, missed that - that is - unexpected
<mvo> ogra: and unwanted :/
<mvo> ogra: I wonder when this sneaked in :(
<ogra> right ... that package shoundt be there at all
<mvo> (and why)
<mvo> ogra: totally
<mvo> ogra: there should also be a big dependency issue, like apt is removed during the build
<ogra> note that i have a few lxd containers running ... i wonder if that makes it sneak in
<mvo> ogra: that could be, let me look at the build logs
<ogra> ogra@pi4:~$ lxc stop xenial
<ogra> ogra@pi4:~$ ps ax|grep unattended
<ogra> 16700 pts/0    S+     0:00 grep --color=auto unattended
<ogra> there we go !
<mvo> ogra: aha, ok
<mvo> ogra: thats fine then
<ogra> mvo, sorry, false alarm then
<ogra> yeah
<zyga> pre-last day of driving home, see you all on Monday
<mvo> ogra: no worries
<ogra> jdstrand, hmm, i'm trying to snap a script that reads /proc/diskstats and blinks one of the RPi LED's based n changes there but i cant seem to find any interface that allows me to write to /sys/class/leds/led1/trigger and /sys/class/leds/led1/brightness
<ogra> (seems only display-control allows access to the kbd LED's)
<ogra> ... but nothing for generic system ones
<abeato> zyga, hey, do you know which is the current status for snaps in yocto?
<ogra> abeato, https://forum.snapcraft.io/t/yocto-rocko-core-snap-panic/3261 perhaps ?
<ogra> hmm, there are newer threads too ...
<ogra> https://forum.snapcraft.io/t/question-about-meta-snappy-layer-for-yocto/10315
<abeato> ogra, thanks, I see there are links to intructions in snapd repo
<ogra> apparently you want https://github.com/morphis/meta-snappy
<abeato> ha, nice
<mup> Bug #1837209 opened: Splash screen fails to display on recent pi core18 images <Snappy:New> <https://launchpad.net/bugs/1837209>
<mup> PR snapcraft#2632 closed: pluginhandler, repo: find stage-packages from DT_NEEDED on host <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2632>
<jdstrand> ogra: hey, bool-file can do leds. you need a gadget like with gpio
<ogra> jdstrand, ah, thanks ! will look into that (we should have something by default in the pi gadget then)
<jdstrand> ogra: that said, it is quite old and doesn't operate exactly like gpio. it looks like the slot is expected to do the export/unexport
<ogra> /usr/share/subiquity/console-conf-wrapper: line 13: snap: command not found
<ogra> Press enter to configure.
<ogra> HRM !
<diddledan> HRM?
<ogra> yeah
<diddledan> I know not of this acronym
<ogra> no snap command on current core18 pi images ... or my SD is screwed up
<diddledan> oh dear :-(
<diddledan> is it because snapd was originally in core?
<ogra> might be .. let me re-try
 * ogra flashes afresh
<diddledan> need netboot on these pis
<diddledan> I don't suppose uboot can do network booting so you can save the root image on a server someplace and just have uboot on the sdcard?
<diddledan> might speed up development if you can do that
<ogra> ok ... it was the SD ... (i was debugging boot stuff and had pulled it out in former boots so i guess something got corrupted ... fresh flash works fine)
<diddledan> oops :-p
<diddledan> the sdcard is the main issue I have with pis
<ogra> well ... i run my pi4 off an USB3 SSD ...
<ogra> a lot more fun !
<diddledan> ooh
<diddledan> I got one of those that I pulled from my old mac
<ogra> still using the SD for the boot partition indeed
<diddledan> it's a USB3-SATA enclosure thingy
<ogra> yeah, that should work well
<ogra> nopw if u-boot would only allow using the full 4GB
<diddledan> is that a hardcoded limit in it's pi support that we can reconfigure?
<ogra> thats the only missing bit to have an awesom build machine
<diddledan> or is it more systemic?
<ogra> its missing code in the u-boot port for pi4
<ogra> it isnt fully done yet
<ogra> the pi4 port is based on pi3 code so it uses whats currently there to init the RAM
<diddledan> ogra: if you're working on u-boot https://github.com/raspberrypi/firmware/issues/1191
<mup> PR snapd#7125 opened: snapstate: make progress reporting less granular <Created by mvo5> <https://github.com/snapcore/snapd/pull/7125>
<diddledan> that might be the same person as wrote the port you're using, https://github.com/agherzan/u-boot
<diddledan> (I don't know whether that's the same port you're working with or not)
<mup> PR snapd#7126 opened: tests: part3 making tests work on ubuntu-core-18 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7126>
<ogra> diddledan, yes, thats the one
<diddledan> ogra: it looks like this is calling into videocore rather than relying on the dtb: https://github.com/agherzan/u-boot/blob/ag/rpi4/board/raspberrypi/rpi/rpi.c#L296
<diddledan> prolly needs a separate branch for pi4
<diddledan> something #ifdef'd
<ogra> diddledan, well, u-boot never actually loads the dtb but reads the dtb values from memor ... the proprietary bootloader needs to load the dtb else the overlays and confi.txt stuff for configuring the HW doesnt work
<ogra> diddledan, https://github.com/agherzan/u-boot/blob/ag/rpi4/arch/arm/dts/bcm2838-rpi-4-b.dts#L9 is the issue i think
<diddledan> aah good find
<diddledan> so that's a devicetree file, right? shouldn't the pi firmware be populating the devicetree memory, not uboot?
<ogra> uboot needs a small devicetree to know about the HW
<ogra> it gets merged into the binary
<diddledan> aah ok
 * diddledan learning
<ogra> hmm, but blindly patching the dts file doesnt help
<ogra> still only 1GB
<ogra> well, agherzan seems to work on it already ... we'll just need to wait
<mup> PR snapd#7127 opened: tests: removing support for ubuntu cosmic on spread test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7127>
 * cachio afk
<ackk> jdstrand, hi, around?
<ackk> mvo, a while ago you merged this https://github.com/snapcore/snapd/pull/6943 to allow adjtimex, but I still see it failing here with the time-control interface
<mup> PR #6943: interfaces: add missing adjtimex to time-control <Simple ð> <Created by mvo5> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/6943>
<ackk> Jul 19 14:46:37 maas audit[13116]: SECCOMP auid=4294967295 uid=0 gid=0 ses=4294967295 pid=13116 comm="chronyd" exe="/snap/maas/x1/usr/sbin/chronyd" sig=0 arch=c000003e syscall=159 compat=0 ip=0x7f4eb1d700c7 code=0x50000 is the error I see
<popey_> https://forum.snapcraft.io/t/refresh-failing-after-some-days-of-downtime/12384
<popey_> :(
<ChipAway> popey_: you have a snap named 's'?
<popey_> ChipAway: i can't "snap info s" to confirm or deny that
<popey_> but it's possible, yes
<Chipaca> popey_: can you 'snap list s'?
<popey_> no
<popey_> no snap commands work
<Chipaca> popey_: Jul 19 15:51:43 KinkPad-K450 systemd[1]: snapd.service: Found left-over process 978 (apparmor_parser) in control group while starting unit. Ignoring.
<Chipaca> popey_: looks suspicious to me
<popey_> i see apparmor_parser eating cpu repeatedly
<Chipaca> popey_: can you systemctl stop snapd.*
<popey_> and snapd eating 100%
<popey_> done
<Chipaca> popey_: and now sudo SNAPD_DEBUG=1 /usr/lib/snapd/snapd
<popey_> Chipaca: added to thread on forum
<Chipaca> popey_: â¦ and then?
<popey_> thats it
<Chipaca> D:
<pedronis> mvo: I have the fix for the download in remodel OTOH I discover we still send ancient headers with downloads
<pedronis> but that's a different issue
<pedronis> for another time
<pedronis> I put some FIXME in though
<popey_> ooh, now it moved
<mvo> ackk: oh no - I wonder what is going on. is this happening with the core from edge?
<mvo> pedronis: thank you \o/
<popey_> it seems to be moving now :(
<ackk> mvo, no. but ifit's just snapd, I'm using the 2.40-based build jdstrand gave us for the snap_daemon user
<mvo> ackk: let me double check 2.40
<Chipaca> popey_: can you paste a bit more of the output?
<Chipaca> ah
 * Chipaca reads
<Chipaca> right
<Chipaca> so that's the problem
<Chipaca> 2+ minutes between starting and done
<Chipaca> meaning, probably, systemd started freaking out
<mvo> ackk: it should be in the 2.40 branch, do you know what branch jdstrand build your daemon from? maybe he branched before this got merged (his PR was wip for a while)
<Chipaca> we need to do something about that
<ackk> mvo, version reports 2.40+git227.g5ce5ff1f0
<mvo> ackk: you could workaround by just adding "adjtimex" to the seccomp profile and recompile it but I'm not sure that is what you want
<popey_> and now yes, i can tell you i do have a snap called 's' installed
<Chipaca> popey_: :)
<jdstrand> ackk: time-control is connected?
<ackk> jdstrand, yes
<jdstrand> ackk: note that you will have to stop/start the process after connected with seccomp
<jdstrand> ackk: apparmor can reload the policy for a running process, seccomp cannot
<jdstrand> ackk: so, if you verify it is connected (grep adjtimex /var/lib/snapd/seccomp/bpf/snap.maas.yourcommand.src) and then stop chrony, then start it, do you see the denial?
<Chipaca> popey_: if you stop snapd and start it again in the terminal does it still wait a long time like that?
<popey_> will try when this refresh finishes
<Chipaca> thank you
<mup> PR snapd#7128 opened: overlord: DeviceCtx must find the remodel context for a remodel change <Created by pedronis> <https://github.com/snapcore/snapd/pull/7128>
<Chipaca> pedronis: mvo: I suspect we're doing too much initialisation before starting the watchdog, and it's making systemd kill us
<pedronis> Chipaca: I suspect is loading the state
<pedronis> anyway we can find out now
<Chipaca> pedronis: 2+ minutes of it?
<pedronis> snap debug timings --startup=load-state
<pedronis> snap debug timings --starup=ifacemgr
<pedronis> should give some info about that
<mvo> Chipaca: are we maybe re-generating security profiles?
<Chipaca> mvo: probably
<pedronis> that would go under ifacemgr
<Chipaca> popey_: can you do those debug commands? ^^
<pedronis> there I think
<pedronis> Chipaca: mvo: I proposed 7128 (part of remodeling stuff)
<pedronis> it will conflict with the kernel branch (less things to do there though)
<popey_> Chipaca: seems a little faster to start this time
<Chipaca> popey_: can you stop it, and remove the system key, and start it again?
<popey_> the second debug command seems malformed
<pedronis> yea, is startup, sorry
<popey_> i dont know what system key is
<popey_> error: cannot find startup: ifacemgr
<Chipaca> popey_: the key for the system, DUH
<popey_> no, that didnt work either
<Chipaca> :-P
<pedronis> Chipaca: you can pass --all
<pedronis> to those commands
<pedronis> it will find all the timings (still kept) instead of the last one
<Chipaca> pedronis: /var/lib/snapd/system-key
<pedronis> only
<Chipaca> er
<Chipaca> popey_: /var/lib/snapd/system-key
<pedronis> Chipaca: :)
<popey_> sorry, to be clear, snap debug timings --startup=ifacemgr is not valid
<pedronis> mmh,
<Chipaca> popey_: 'cannot find'?
<pedronis> maybe it's only in 2.41
<ackk> jdstrand, ok that's weird. I grepp'd, it was there. stopped and started the snap, now it works
<Chipaca> popey_: "cannot find" means it doesn't have any
<popey_> i am on 2.40
<Chipaca> popey_: if it's wrong it says "ALlowed values are: ..."
<popey_> your error messages are weird
<pedronis> it might be that systemd is killing us too fast
 * Chipaca covers his error messages' ears
<pedronis> we would need to increase the timeout in the service file
<pedronis> and try again
<popey_> so am i safe to remove /var/lib/snapd/system-key ?
<Chipaca> pedronis: or we can tell systemd what's going on so we're not playing whack-a-mole with it
<pedronis> ?
<Chipaca> popey_: if you could stop snapd, remove that file, and start it again, that'd be good
<pedronis> Chipaca: you mean the real fix?
<Chipaca> pedronis: yeah
<pedronis> we still don't know where we are spending time
<Chipaca> pedronis: i mean there's a protocol to tell systemd to wait a bit more afaik
<pedronis> yes
<pedronis> there is
<pedronis> doesn't make it a fix
<pedronis> I mean I suspect this is not trivial to fix
<pedronis> without shuffling things around
<pedronis> somewhat
<popey_> ok
<popey_> yes, 2 mins delay
<popey_> see forum
<Chipaca> popey_: nice
<Chipaca> popey_: and now do you have ahnything in the ifacestate timings?
<Chipaca> ifacemgr*
<ackk> jdstrand, could it be that for some reason that profile didn't get applied right way?
<pedronis> Chipaca: anyway I think the issue is that we should reorg things so that we don't do slow things inside a New function, it's a bit misleading
<Chipaca> pedronis: mhmm
<Chipaca> pedronis: but even if we did it in Init or Start it'd still be before the watchdog started
<pedronis> Chipaca: ?
<pedronis> we decide when to do what
<Chipaca> pedronis: snapd does d := daemon.New(); d.Init(); d.Start(); runWatchdog()
<pedronis> anyway my main point is that this is not a 5 line fix
<Chipaca> ok
<Chipaca> popey_: so you should be ok to let systemd start snapd again, at least until you run some development version again
<Chipaca> popey_: as long as it's not re-doing the system key (which happens on upgrade)
<jdstrand> ackk: yes, that was what I was trying to say. with a snap declaration, the interface is not auto-connected. therefore on install, chronyd starts with the interface disconnected and has the denial. you connect the interface. it will continue to get a denial until you restart it
<Chipaca> popey_: as a workaround until we sort this you can bump the start timeout in a config file snippet
<ackk> jdstrand, well chrony is not started on install
<ackk> jdstrand, I install the snap, connect  the interfaces, then run maas init which configures stuff and starts everythin
<ackk> jdstrand, at least it shuoldn't be, lemme confirm :)
<jdstrand> ackk: you could use connection hook to deal with that
<jdstrand> ackk: (not your last two comments, the fact that something is starting before a connection)
<popey_> Chipaca: added timings to forum
<popey_> Chipaca: thanks for the help
<ackk> jdstrand, yeah it's a bit tricky at the moment as we only have one service, which is supervisord, which manages everything else
<Chipaca> popey_: i'll try to reproduce your issue here so we don't have to guinea pig you
<jdstrand> ackk: it can take a little while for snapd to compile the new security policies (work is planned this cycle to make that faster), so it is possible you connected, then ran maas init before it was done connecting
 * jdstrand shrugs
<ackk> jdstrand, so I guess the reason is that supervisord is started before connections are made, so children inherit the profile without connections?
<jdstrand> ackk: I can say that snapd will not restart services when connecting interfaces, but on install won't start services until everything is connected
<jdstrand> ackk: yes
<ackk> jdstrand, so if the service starts before connecting and spawns other processes, they won't get the connection right?
<jdstrand> mvo: fyi ^ tldr; chronyd started before the interface was connected
<jdstrand> ackk: that is correct
<ackk> jdstrand, would autoconnect fix this?
<jdstrand> ackk: yes
<jdstrand> ac
<jdstrand> ackk: so would be smart wrt a connection hook
<jdstrand> being*
<jdstrand> supervisord (or something else) could detect that the interface isn't connected. I believe there is a mechanism to restart a service on interface connection
<ackk> jdstrand, yeah but if you connect 5/6 interfaces one after another then you get a restart storm
<jdstrand> if maas is known to break if all interfaces aren't connected, you probably want some smarts to make sure everything is connected and fail to start if not (with some appropriate log message that tells the user what to do)
<ackk> jdstrand, is there a way to get interfaces status in snapctl?
<jdstrand> ackk: I thought so, I'm not the best to answer that. perhaps ask in #snapcraft? these are the sorts of things snap publishers deal with all the time...
<jdstrand> ackk: they may be able to advise on your storm comment, etc
<pedronis> no, it's a request but we haven't worked on it yet
<mup> PR core-build#47 opened: initramfs: restore wait-for-root calls <Created by cmatsuoka> <https://github.com/snapcore/core-build/pull/47>
<cachio> mvo, any idea about how to create a fat fs on core 18?
<cachio> I need it for the assertrions disk
<cachio> do you know if that could work using a differet fs?
<mvo> cachio: we could create a snap with mtools
<cachio> mvo, seems to work using ext3
<mvo> cachio: yes it does
<cachio> mvo, is any special reason why we use vfat  on the tests?
<cachio> mkfs.vfat
<mvo> cachio: not really, just to test if it works with that, its the most common format on usb sticks
<cachio> mvo, ah ok, I'll leave some tests using vfat and others using ext3
<cachio> so we can test also core18
<cachio> mvo, should be ok?
<mvo> cachio: should be ok, yes
<cachio> mvo, tx
<mup> PR snapcraft#2635 opened: Legacy errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2635>
 * mvo declares victory over swtpm
<mup> PR snapd#7129 opened: Allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
<mup> PR snapcraft#2633 closed: remote-build: increase number of launchpad start_build request attempts <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2633>
#snappy 2019-07-20
<mup> PR # closed: snapd#5644, snapd#5822, snapd#6108, snapd#6258, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6666, snapd#6697, snapd#6705, snapd#6708, snapd#6714, snapd#6767, snapd#6839, snapd#6891, snapd#6923, snapd#6950, snapd#6954, snapd#6959, snapd#6972,
<mup> snapd#7005, snapd#7010, snapd#7031, snapd#7042, snapd#7054, snapd#7066, snapd#7067, snapd#7073, snapd#7074, snapd#7079, snapd#7081, snapd#7087, snapd#7088, snapd#7091,
<mup> snapd#7092, snapd#7107, snapd#7109, snapd#7110, snapd#7111, snapd#7112, snapd#7121, snapd#7124, snapd#7125, snapd#7126, snapd#7127, snapd#7128, snapd#7129
<mup> PR # opened: snapd#5644, snapd#5822, snapd#6108, snapd#6258, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6666, snapd#6697, snapd#6705, snapd#6708, snapd#6714, snapd#6767, snapd#6839, snapd#6891, snapd#6923, snapd#6950, snapd#6954, snapd#6959, snapd#6972,
<mup> snapd#7005, snapd#7010, snapd#7031, snapd#7042, snapd#7054, snapd#7066, snapd#7067, snapd#7073, snapd#7074, snapd#7079, snapd#7081, snapd#7087, snapd#7088, snapd#7091,
<mup> snapd#7092, snapd#7107, snapd#7109, snapd#7110, snapd#7111, snapd#7112, snapd#7121, snapd#7124, snapd#7125, snapd#7126, snapd#7127, snapd#7128, snapd#7129
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#19 closed: UC20 spike changes <Created by cmatsuoka> <https://github.com/snapcore/pc-amd64-gadget/pull/19>
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#19 opened: UC20 spike changes <Created by cmatsuoka> <https://github.com/snapcore/pc-amd64-gadget/pull/19>
<benfrancis> Moved my question to the forum https://forum.snapcraft.io/t/electron-kiosk-snap-wont-run/12394
<popey_> Emailed chihchun to ask them to fix their connection
<diddledan> popey being a power-wielding dictator again I see ;-p
<popey_> Only on Saturdays
<diddledan> phew
<diddledan> like me being Barbera then
#snappy 2019-07-21
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129
<mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129
<mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134
<mup> PR snapd#7130 opened: overlord/devicestate: support seeding a classic system with the snapd snap and no core <Created by pedronis> <https://github.com/snapcore/snapd/pull/7130>
<mup> PR snapd#7131 opened: overlord/devicestate: detect clashing concurrent (ongoing, just finished) remodels <Created by pedronis> <https://github.com/snapcore/snapd/pull/7131>
<mup> PR snapd#7132 opened: ovelorrd,daemond,cmd/snapd:  move expensive startup to dedicated StartUp methods <Created by pedronis> <https://github.com/snapcore/snapd/pull/7132>
<mup> PR snapd#7133 opened: overlord,daemon: adjust startup timeout via EXTEND_TIMEOUT_USEC using an estimate <Created by pedronis> <https://github.com/snapcore/snapd/pull/7133>
<mup> PR snapd#7134 opened: image: clean up the validateSuite <Created by pedronis> <https://github.com/snapcore/snapd/pull/7134>
<mup> PR snapd#7135 opened: image: support prepare-image --classic for snapd snap only images <Created by pedronis> <https://github.com/snapcore/snapd/pull/7135>
#snappy 2020-07-13
<murthy> gwenview snap app doesn't open webp
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> hey mborzecki !
<mvo> mborzecki: anything I can help with before my first cup of tea :) ?
<mborzecki> mvo: are you grumpy before or after your cup of tea? :P
<mvo> all the time!
<mborzecki> haha
<mborzecki> mvo: maybe this one: https://github.com/snapcore/snapd/pull/8999 if github does not 500 on you like it does on me
<mup> PR #8999: strutil: add a helper for parsing kernel command line <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8999>
<mvo> mborzecki: ok
<mborzecki> mvo: thanks!
<pstolowski> morning
<mvo> good morning pstolowski
<pstolowski> o/
<mborzecki> pstolowski: heya
<mvo> hey pstolowski
<zyga> hmm
<zyga> it's not a good sing
<zyga> sign*
<zyga> when github is down on Monday morning
<pstolowski> oh
<zyga> oh well
<zyga> how are you guys feeling?
<mvo> feeling good (a bit tired) but GH down is a bummer
<zyga> mvo same feeling, though for different reasons
<mvo> zyga: i can imagine
 * mvo hugs zyga
<zyga> painkillers wear off pretty quickly so mornings are a bit so-so
<zyga> I will ask for replacements if possible today
<zyga> but I think I slept better than yesterday which was again awful
<zyga> so I'm not that tired
<pstolowski> i didn't sleep too well last night (woke up at 2.00 to check news re elections)
<pstolowski> and then couldn't sleep
<pstolowski> was such a bummer
<mborzecki> meh, github still down
<mborzecki> get an angry unicorn or 500 octocat :/
<jamesh> it seems to be slightly functional: https://www.githubstatus.com/
<jamesh> it let me create a pull request moments ago
<mup> PR snapcraft#3211 opened: pluginhandler: fix stage-snaps for v2 plugins <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/3211>
<pstolowski> just started working here
<mborzecki> yay
<mborzecki> tbh funny how github become a single point of failure ;)
<jamesh> Switch to a distributed bug tracker?
<zyga-mbp> re
<zyga-mbp> if only distributed bug trackers came with nice usable UX
<zyga-mbp> oh well
<mborzecki> zyga-mbp: can you take a look at https://github.com/snapcore/snapd/pull/8996 ?
<mup> PR #8996: packaging, cmd/snap-mgmt, tests: remove modules files on purge <Bug> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8996>
<zyga-mbp> trying
<zyga-mbp> yeah, loads now
<zyga-mbp> ah that
<zyga-mbp> I really think we should remove snaps for real
<zyga-mbp> did you see the comment from jamie?
<zyga-mbp> +1
<mborzecki> yup, i think we got everything he listed covered now
<zyga-mbp> mborzecki including the udev rules?
<zyga-mbp> if so that's great
<mborzecki> zyga-mbp:             find /etc/udev/rules.d -name "*-snap.${snap}.rules" -execdir rm -f "{}" \;
<zyga-mbp> ok
<mup> PR snapd#8996 closed: packaging, cmd/snap-mgmt, tests: remove modules files on purge <Bug> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8996>
<zyga-mbp> woah, thank you for the review on https://github.com/snapcore/snapd/pull/8977 guys!
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<mvo> zyga-mbp: do you think you could review 8949 and 8950 again? it looks like sergio addressed the comments
<zyga-mbp> sure
<mvo> mborzecki: 8959 looks like something for you :)
<mborzecki> mvo: yeah, high time for me to go over it
<mborzecki> pstolowski: https://github.com/snapcore/snapd/pull/8995#discussion_r453497664 snapd is running as root, so we'd take up the space reserved for root too
<mup> PR #8995: osutil: add CheckFreeSpace helper (1/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8995>
<mup> PR snapd#8978 closed: secboot: update tpm connection error handling <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8978>
<zyga-mbp> reviewed https://github.com/snapcore/snapd/pull/8949#pullrequestreview-447087507
<mup> PR #8949: tests: new fs-state which replaces the files.sh helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8949>
<mup> PR snapd#9000 opened: postrm, snap-mgmt: cleanup modules and other cherry-picks (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9000>
<mborzecki> ha, next one is over 9000
<zyga-mbp> https://github.com/snapcore/snapd/pull/8950#pullrequestreview-447098901
<mup> PR #8950: tests: new to-one-line tool which replaces the strings.sh helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8950>
<zyga-mbp> mborzecki can you review https://github.com/snapcore/snapd/pull/8949 please
<mup> PR #8949: tests: new fs-state which replaces the files.sh helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8949>
<zyga-mbp> mainly to see how you feel about the helpers
<zyga-mbp> I'm happy to see most of them, but one
<mborzecki> whis this be some snap declaration related thing? https://forum.snapcraft.io/t/finding-reason-for-stopped-snap-service-at-bootup/18785/8
<zyga-mbp> yeah
<zyga-mbp> commented
<zyga-mbp> small break for coffee and back to branches
<zyga-mbp> pstolowski https://github.com/snapcore/snapd/pull/8995#pullrequestreview-447118858
<mup> PR #8995: osutil: add CheckFreeSpace helper (1/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8995>
<zyga-mbp> pstolowski including https://github.com/snapcore/snapd/pull/8995#discussion_r453545090
<pstolowski> zyga-mbp: thank you!
<pstolowski> thanks for the reviews, i'll land this and push next one
<zyga-mbp> ok
<mborzecki> hmm unit tests in 2.45 branch aren't passing
<mborzecki> oh, w8, that's soem directory that's not going away when i switch branches
<zyga> huh?
<mup> PR snapcraft#3212 opened: tests: expand spread coverage for stage-snaps <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3212>
<mup> PR snapd#8995 closed: osutil: add CheckFreeSpace helper (1/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8995>
<mup> PR snapd#9001 opened: o/snapshotstate: helpers for calculating disk space needed for an automatic snapshot (2/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9001>
<mup> PR snapd#9002 opened: o/snapstate: integrate free space checks with install/refresh and remove (3/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9002>
<mborzecki> zyga: have you looked at the failures on centos-8 maybe? i'm trying to reproduce them, but the failing tests pass in isolation
<mborzecki> zyga: and the problems seem to be related to user sessions
<mborzecki> zyga: eg. this one https://github.com/snapcore/snapd/runs/864831282
<zyga> I have not
<zyga> mborzecki 2020-07-13T11:32:11.5181452Z Failed to create bus connection: No such file or directory
<zyga> mborzecki I saw this a few times
<zyga> mborzecki perhaps test history is useful
<zyga> long so I won't paste it here
<mborzecki> zyga: trying to run the same set of tests as the one that failed
<zyga> mborzecki try -seed
<mborzecki> zyga: i'm using cachio's spread build :P
<zyga> aha
<mborzecki> cmatsuoka: hi, can you take a look at https://github.com/snapcore/snapd/pull/8999 ?
<mup> PR #8999: strutil: add a helper for parsing kernel command line <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8999>
<cmatsuoka> mborzecki: sure, will do it as soon as I finish some fixes here
<mborzecki> cmatsuoka: cool, thanks!
<mborzecki> heh, adding some tests to bootloader, noticed we have no covarge of GetRecoverySystemEnv
<zyga> omw
<zyga> sorry about all the yawning
<zyga> I need more coffee
<zyga> elections elections elections
<mup> Bug #1887238 changed: snap fails to reload udev rules in docker <docker> <udev> <Snappy:Won't Fix> <https://launchpad.net/bugs/1887238>
 * zyga lunch
<mup> PR snapd#9003 opened: bootloader: add helper for getting recovery system environment variables <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9003>
<mborzecki> cmatsuoka: if you could also take a look at ^^ this is for the tweaks in 8993
<cmatsuoka> mborzecki: ok!
<mborzecki> cmatsuoka: it's super simple and hopefully can land easily
<mborzecki> cmatsuoka: thanks
<mup> PR snapd#8999 closed: strutil: add a helper for parsing kernel command line <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8999>
<mup> PR snapd#9000 closed: postrm, snap-mgmt: cleanup modules and other cherry-picks (2.45) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9000>
<cachio> zyga, hey, is it ok #8991 now?
<mup> PR #8991: tests: preinstall shellcheck and run tests on focal <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8991>
<zyga> yes :)
<mup> PR snapd#8991 closed: tests: preinstall shellcheck and run tests on focal <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8991>
 * cachio lunch
<mup> PR snapd#9003 closed: bootloader: add helper for getting recovery system environment variables <Simple ð> <UC20> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9003>
<mup> PR snapd#9004 opened: bootloader/bootloadertest: fix comment typo <Simple ð> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9004>
<mup> PR snapd#9004 closed: bootloader/bootloadertest: fix comment typo <Simple ð> <Skip spread> <UC20> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9004>
<mup> PR snapcraft#3097 closed: colcon v2 plugin + ros2 extension <do-not-merge> <enhancement> <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3097>
#snappy 2020-07-14
<mup> Bug #1868620 changed: Snaps based on Wine fail with nvidia driver 440  <Snappy:Expired> <https://launchpad.net/bugs/1868620>
<mup> Bug #1868620 opened: Snaps based on Wine fail with nvidia driver 440  <Snappy:Expired> <https://launchpad.net/bugs/1868620>
<mup> Bug #1868620 changed: Snaps based on Wine fail with nvidia driver 440  <Snappy:Expired> <https://launchpad.net/bugs/1868620>
<mborzecki> morning
<mup> PR snapd#8993 closed: bootloader, boot: compose kernel command line passed by grub bootloader <UC20> <â Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/8993>
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> phew, rebased and restiched all the patches
<mup> PR snapd#9005 opened: boot: support setting extra command line argument, bootloader interface tweaks <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9005>
<mborzecki> pstolowski: need to take a short break from coding, do you need any reviews?
<pstolowski> mborzecki: sure, ty! #9001 ?
<mup> PR #9001: o/snapshotstate: helpers for calculating disk space needed for an automatic snapshot (2/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9001>
<mborzecki> pstolowski: ok, will do
<pstolowski> thanks!
<pstolowski> i'll do the same; anything in particular you want reviewed?
<pstolowski> mborzecki: ^
<mborzecki> pstolowski: got some uc20 PRs if you're interested
<mup> PR snapd#9006 opened: bootloader: compose command line with mode and extra arguments <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<mborzecki> pstolowski: but nothing in particular, perhaps there's some PRs from claudio
<pstolowski> ack
<pstolowski> zyga is off today?
<mborzecki> pstolowski: iirc he said he has a doctor appointment?
<mborzecki> pstolowski: mvo too
<pstolowski> same doctor? ;)
<pstolowski> ok, got it
<mborzecki> pretty sure a different one ;P
<zyga-mbp> good morning
<zyga-mbp> sorry for starting late, the night was pretty rough
<pstolowski> zyga-mbp: hi! sorry to hear that
<zyga-mbp> I got some sleep after 6AM and woke up around 10 again
<zyga-mbp> I'll be back shortly, just making some tea and coffee for the day
<pstolowski> zyga: will have some questions for you re some bugs
<zyga-mbp> sure
<pstolowski> zyga: is this fixed? https://bugs.launchpad.net/snapd/+bug/1867193
<mup> Bug #1867193: failure refreshing snap with content interface <snapd:In Progress by zyga> <https://launchpad.net/bugs/1867193>
<pstolowski> zyga-mbp: and this looks like something for you? https://bugs.launchpad.net/snapd/+bug/1887255
<mup> Bug #1887255: all snaps won't start suddenly with permission denied errors <Snapcraft:Invalid> <snapd:Triaged> <https://launchpad.net/bugs/1887255>
<zyga-mbp> hmmm
<zyga-mbp> weird stuff, maybe mint broke snapd somehow?
<mborzecki> zyga-mbp: heya
<zyga-mbp> o/
<zyga-mbp> replied there
<zyga-mbp> though launchpad is still spinning
<zyga-mbp> well, let me make that coffee now
<pstolowski> zyga-mbp: didn't we similar case between ubuntu upgrades?
<pstolowski> thanks
<zyga-mbp> pstolowski I don't recall so, we had a different issue that resulted in the .real suffix
<zyga-mbp> but since then it was all quiet
<jamesh> could it have got that far if the setuid bit had been removed from snap-confine?
<zyga-mbp> jamesh oh, interesting
<zyga-mbp> hey :)
<zyga-mbp> perhaps
<zyga-mbp> but I don't know how that would happen, apart from mint package alterations
<jamesh> it's weird that it isn't the same error from each snap
<murthy> gwenview snap can't display webp images
<murthy> the normally packaged one on ubuntu uses the package qt5-image-formats-plugins package to get the webp support
<murthy> show can i install that specific plugin/package or how to get gwenview snap app to display webp images
<jamesh> murthy: it might need to be fixed in the snap itself.  The contact info for that snap directs you to https://bugs.kde.org/enter_bug.cgi?product=neon&component=Snaps
<murthy> jamesh: ok will try to file a bug report
<murthy> jamesh: ty
<pstolowski> zyga-mbp: should https://bugs.launchpad.net/snapd/+bug/1866855 be set back to confirmed (not in progress)?
<mup> Bug #1866855: nvidia driver integration is incompatible with Debian <snapd:In Progress by zyga> <https://launchpad.net/bugs/1866855>
<zyga-mbp> yes please, I cannot do anything about that now
<mborzecki> pstolowski: would simplifying a bit make sense there? https://github.com/snapcore/snapd/pull/9001#pullrequestreview-447919000
<mup> PR #9001: o/snapshotstate: helpers for calculating disk space needed for an automatic snapshot (2/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9001>
<murthy> bug report filed for gwenview's missing webp capability https://bugs.kde.org/show_bug.cgi?id=424185
<pstolowski> mborzecki: thanks, i need to think. i was following the logic of snapshot save method, which was a little bit convoluted ;)
<mborzecki> pstolowski: added some comments https://github.com/snapcore/snapd/pull/9002#pullrequestreview-447923236
<mup> PR #9002: o/snapstate: integrate free space checks with install/refresh and remove (3/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9002>
<mborzecki> pstolowski: there's snapshot.automatic.retention=no which one can set to disable snapshots, imo we should not fail when there's not enough space for snapshots in such case
<pstolowski> mborzecki: yep, +1, thanks
<mborzecki> omg, arch switched the default compression alg for built pacakges
<mborzecki> so now all spread jobs are failing
<mborzecki> heh and the change did not hit my mirror yet, so I had not noticed it earlier
<mborzecki> zyga-mbp: pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/9007 ?
<mup> PR #9007: tests/lib: account for changes in arch package file name extention <Simple ð> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9007>
<zyga-mbp> sure
<mborzecki> mvo: we'll need to cherry-pick that to 2.45 ^^
<mborzecki> thanks!
<mvo> mborzecki: sure, will do
<mup> PR snapd#9007 opened: tests/lib: account for changes in arch package file name extention <Simple ð> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9007>
<mborzecki> huh, static checks failed? wth?
<mvo> mborzecki: probably an apt error, I had that yesterday too
<mborzecki> mvo: nah, a silly typo i did :/
<zyga-mbp> brb
<mborzecki> mvo: can you cherry pick https://github.com/snapcore/snapd/pull/9007 to 2.45?
<mup> PR #9007: tests/lib: account for changes in arch package file name extension <Simple ð> <Test Robustness> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9007>
<mup> PR snapd#9007 closed: tests/lib: account for changes in arch package file name extension <Simple ð> <Test Robustness> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9007>
<mvo> mborzecki: sure, done
<mborzecki> mvo: thanks
<mvo> thank *you*
 * zyga-mbp lunch break
<zyga-mbp> uh
<zyga-mbp> darn pain
<zyga-mbp> one hour for next round
<mup> PR snapcraft#3210 closed: docker: install snapd dependency <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3210>
 * cachio lunch
<ijohnson> jamesh: just an FYI since I saw your desktop team update about having difficulty building core20 or snaps that use device nodes with lxd, you can use the same trick from my PR here to get across that: https://github.com/snapcore/core20/pull/74
<mup> PR core20#74: .travis.yml: use snapcraft w/ lxd to build the snap <Created by anonymouse64> <https://github.com/snapcore/core20/pull/74>
<ijohnson> jamesh: it's not great, but it works well enough in CI, so I figured I would share
<ijohnson> jamesh: also re: checking for an interface connected from inside snapctl code for the theme work, I implemented something like that for a PR that wasn't merged if you are curious about an example of how to do that (but perhaps Samuele has already explained that aspect to you)
<mup> PR snapcraft#3212 closed: tests: expand spread coverage for stage-snaps <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3212>
<zyga-mbp> mvo I wrote some more code for cerberus and I found a bug that made asynchronous notifications fail, they work correctly now!
<mvo> zyga-mbp: aha, nice
<mvo> zyga-mbp: that is good to know
<zyga-mbp> I pushed all the fixes now
 * zyga-mbp -> meds & break
<mup> PR snapd#9008 opened: boot/initramfs_test.go: add Commentf to more Assert()'s <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9008>
<mup> PR snapcraft#3211 closed: pluginhandler: fix stage-snaps for v2 plugins <bug> <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3211>
<mup> PR snapcraft#3209 closed: extensions/desktop/common: add snapd gl vdpau dir to LD_LIBRARY_PATH <maintenance> <Created by anonymouse64> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3209>
<kyrofa> Hey ogra_, is there a way to take an existing ubuntu core image and make SSO NOT required? Somehow seed it with an account after I write it to disk, maybe?
<ijohnson> kyrofa: the only way to do that would be with cloud-init, you cannot create a normal snap user the way you would with console-conf except by using console-conf or a snap that uses snapd-control
<ijohnson> kyrofa: look at ubuntu-image --help there is a cloud-init option IIRC
<kyrofa> ijohnson, yeah that involves actually creating a new image, was wondering if there was a way to do that on an existing image
<ijohnson> kyrofa: what ubuntu-image does can be done on an existing image
<kyrofa> Oh? I didn't realize ubuntu-image could operate on an image
<ijohnson> kyrofa: it involves writing the cloud-init stuff you would pass to ubuntu-image somewhere in like /var/lib/cloud/seed/nocloud-net I think
<ijohnson> kyrofa: no sorry I mispoke
<kyrofa> Oh oh, I got it now
<ijohnson> kyrofa: you can do that yourself by mounting the image and copying files, ubuntu-image will not do that for you
<kyrofa> I can do what it does on my OWN
<ijohnson> yes precisely
<ijohnson> kyrofa: out of curiosity what's the use case here?
<kyrofa> Okay so all I need to do is whatever cloud-init needs me to do to make it run
<kyrofa> Someone asked me how they can use an ubuntu appliance without an SSO account. I wanted to be able to give them an answer
<kyrofa> An answer that wasn't "build your own image"
<ijohnson> kyrofa: yes setup some kind of cloud-init configuration that creates the user you want, but note that I would strongly suggest that this is erm a bit hackish since they are modifying the image
<ijohnson> just a small disclaimer
<kyrofa> Of course, I agree
<ijohnson> cool
<ijohnson> kyrofa: is this on a forum or something or just PM?
<kyrofa> But hacking up an existing image might be a bit easier than figuring out what's in there and how to use ubuntu-image to duplicate it
<kyrofa> Twitter, the messaging platform of professionals, of course
<ijohnson> haha fair enough
<ogra_> kyrofa, you can surely put a system-user assertion onto a USB key to crate the user
<ogra_> but beyond that i dont know how you would do anything like that with an *existing* image ... for core16 and 18 images you can use the --disable-consoleconf option to ubuntu-image ... but that indeed means you need to roll your own
<ogra_> kyrofa, oh, wait ... you *can* create a user by simply using the account control interface too ... take a look at the connect-plug-account-control hook in this snap https://github.com/ogra1/config-snap
<ogra_> but that also means you somehow need to seed that snap into an image ... (and need to do the interface connection)
<ogra_> (beyond the fact that you hardcode username and password in the snap indeed)
<zyga> I've update cerberus one more time and will EOD now
 * zyga EODs for real now
<zyga> bye everyone!
<mup> PR snapcraft#3213 opened: cli: use prefix in store name registration hint <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3213>
<mup> PR snapcraft#3214 opened: snap: specify 'libxslt1-dev' than virtual 'libxslt-dev' build-package <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3214>
<mup> PR snapcraft#3215 opened: build providers: use PEP-440 compliant version comparison operator <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3215>
<mup> PR snapcraft#3216 opened: build providers: tweak environment clean detection and logging <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3216>
<mup> PR snapd#9009 opened: tests/cmd/snap-bootstrap/initramfs-mounts: rm duplicated env ref kernel tests <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9009>
<mup> PR snapcraft#3213 closed: cli: use prefix in store name registration hint <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3213>
<mup> PR snapd#9010 opened: cmd/snap-bootstrap/initramfs-mounts: call systemd-mount instead of the-tool <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9010>
<mup> PR snapcraft#3214 closed: snap: specify 'libxslt1-dev' than virtual 'libxslt-dev' build-package <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3214>
<mup> PR snapcraft#3215 closed: build providers: use PEP-440 compliant version comparison operator <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3215>
<mup> PR snapcraft#3217 opened: cmake v2 plugin: add stage to CMAKE_PREFIX_PATH <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3217>
#snappy 2020-07-15
<jamesh> ijohnson: thanks for the suggestion.  It looks like security.syscalls.intercept.mknod was enough for my use case, so I might try getting that upstream into Snapcraft
<jamesh> ijohnson: might be worth seeing if that works for you in CI too
<ijohnson> jamesh: interesting, how did you use that with lxc ?
<jamesh> ijohnson: I failed to build my project, stopped the container and ran "lxc config set snapcraft-core20-gdm security.syscalls.intercept.mknod=true"
<jamesh> and tried again
<jamesh> ijohnson: with this configuration, LXD allows a few mknod syscalls it considers safe
<jamesh> enough for the small number of bootstrap device files I needed in the base snap
<ijohnson> nice, yeah I'll give that a try then
<jamesh> ijohnson: more details at https://linuxcontainers.org/lxd/docs/master/syscall-interception#mknod-mknodat
<jamesh> it will let you create /dev/null, but not /dev/sda1 :-)
<ijohnson> right :-)
<mup> PR snapcraft#3218 opened: WIP: support some mknod calls in LXD builds <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/3218>
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/9006 ?
<mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<mvo> mborzecki: yeah, need to work a bit on packaging but will look while things are building etc
<mborzecki> mvo: thanks!
<pstolowski> morning
<mvo> good morning pstolowski
<mborzecki> pstolowski: heya
<pstolowski> o/
<zyga> good morning
<mvo> zyga: good morning
<zyga> somewhat better night
<zyga> still 4AM-7AM hole is not great
<zyga> today will be the more traditional snapd hacking day
<mup> PR snapd#9008 closed: boot/initramfs_test.go: add Commentf to more Assert()'s <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9008>
<mvo> ijohnson: should we ask dimitri to review 9010 ?
<mborzecki> mvo: pushed your suggestion from https://github.com/snapcore/snapd/pull/9006#discussion_r454847330 with some tweaks, please take a look, it's a regex so extra pair of eyes won'thurt
<mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<ogra_> ogra@pi4:~$ snap connect node-red-rpi:gpio  pi4-develðcm-gpio-14
<ogra_> error: cannot perform the following tasks:
<ogra_> - Connect node-red-rpi:gpio to pi4-develðcm-gpio-14 (cannot obtain systemd services for snap "pi4-devel": interface requires conflicting system needs)
<zyga> ogra_: nice error message you have there
<ogra_> hrm ... emojis ...
<ogra_> yeah, my hexchat emoji plugin is a bit dumb
<ogra_> zyga, so what is that ? what am i missing ? (my pi3 image works, my locally built pi4 one doesnt anymore)
<zyga> it's a very specific error, it means that more than one thing would like to export the same GPIO IIRC
<ogra_> seems that's new with yesterdays core release
<zyga> are the GPIO slots defined correctly?
 * zyga looks at snapd source 
<zyga> so
<zyga> it's when an interface defines a systemd service
<zyga> like we do for GPIO
<ogra_> https://paste.ubuntu.com/p/yXCtRqP6QJ/
<ogra_> thats my snap.yaml ...
<zyga> and there's a service with a name but different definition
<ogra_> shoudl eb identical to our std ones
<mvo> mborzecki: heh, nice - sure, I have a look. don't get me wrong, I'm usually not a let's-use-regex type but this seemed appropriate
<zyga> ogra_: weird, I mean the error does look valid unless we are missing something
<ogra_> zyga, well i was indeed trying to get multiple apps read info from the same GPIO ... one is managing it, the other is monitoring it ...
<mvo> mborzecki: looks great
<mborzecki> mvo: heh, i still think adding regex is adding yet another problem, but yeah, this one seemed ok
<zyga> ogra_: look at /etc/systmed/system/
<ogra_> but since that error started occuring i cant connect/disconnect *and* GPIO interfaces anymore
<ogra_> *any
<zyga> for .service files named after the slot snap name (gadget here)
<zyga> and gpio-NNN
<zyga> maybe there's some bug there
<ogra_> gra@pi4:~$ ls -l /etc/systemd/system/|grep gpio
<ogra_> -rw-r--r-- 1 root root  264 Jun 20 10:41 snap.pi4-devel.interface.gpio-14.service
<ogra_> -rw-r--r-- 1 root root  260 Jul 13 13:25 snap.pi4-devel.interface.gpio-4.service
<zyga> this error is reported when the same file name has two differing definitions
<ogra_> interestingly i'm pretty sure i have never connected gpio-4
<ogra_> ogra@pi4:~$ snap connections node-red-rpi|grep gpio
<ogra_> gpio                     node-red-rpi:gpio                     pi4-develðcm-gpio-4    manual
<ogra_> gpio-memory-control      node-red-rpi:gpio-memory-control      :gpio-memory-control    manual
<ogra_> and ...
<ogra_> ogra@pi4:~$ snap disconnect node-red-rpi:gpio  pi4-develðcm-gpio-4
<ogra_> error: cannot perform the following tasks:
<ogra_> - Disconnect node-red-rpi:gpio from pi4-develðcm-gpio-4 (cannot obtain systemd services for snap "pi4-devel": interface requires conflicting system needs)
<ogra_> (sorry for the smileys)
<ogra_> oh, WOW
<ogra_> ogra@pi4:~$ snap stop node-red-rpi
<ogra_> Stopped.
<ogra_> ogra@pi4:~$ snap disconnect node-red-rpi:gpio  pi4-develðcm-gpio-4
<ogra_> error: cannot disconnect node-red-rpi:gpio from pi4-develðcm-gpio-4, it is not connected
<ogra_> ogra@pi4:~$ snap connections |grep gpio
<ogra_> gpio                   node-red-rpi:gpio                   pi4-develðcm-gpio-4    manual
<ogra_> what a mess
<zyga> pstolowski: ^^ hmm
<pstolowski> could be the undo bug i fixed recently
<ogra_> and funnily enough, the app can read the gpio state now
<ogra_> (along with the other app managing it )
<pstolowski> there were 2 bugs around this area where under certain circumstances security profile wouldn't reflect disconnected state
<pstolowski> ogra_: can you restart snapd and re-try?
<ogra_> pstolowski, funny ... that works ... i had rebooted inbetween
<ogra_> i mean i had rebooted anmd it still did not work ...
<ogra_> the manual snapd restart lets me disconnect now
<pstolowski> ogra_: weird.. restart (reboot as well) would work around that bug
<ogra_> yes, very curious ...
<pstolowski> the problem was caused by inconsistent in-memory state of snapd after undo of a failed operation
<ogra_> i can still not connect two apps to the same gpio interface though
<pstolowski> ogra_: because of that "interface requires conflicting system .." error?
<ogra_> yep
 * ogra_ arghs ... i forgot i have a meeting in 10min ... 
<pstolowski> ok, i don't know about that, would need investigation
<pstolowski> ogra_: perhaps report a bug with all the details of these snaps
<ogra_> will do
<pstolowski> thanks\
 * zyga is really close to putting his x240 into the bin
<zyga> linux runs well on thinkpads my ass
<pstolowski> hmm
<mborzecki> zyga: what's the problem?
<zyga> suspend resume is broken
<zyga> input stops working
<zyga> past my level of accepting broken stuff
<zyga> too tired
<zyga> as much as I like native linux stuff like that makes me question sensibility of spending $$$ on new linux portables
<mvo> zyga: my x250 is doing fine since forever and my t460s too
<zyga> oh well
<zyga> draw a lottery
<mvo> zyga: and the x220 in the house too, the t400 too, they all suspend/resume all the time
<zyga> it suspends allright ;)
<mvo> zyga: yeah, looks like you got a bad lot :(
<zyga> just on resume there's no input
<zyga> and the log is full of errors
<ijohnson> mvo: morning! yes we will want dimitri to look at it eventually I'm pretty sure, not sure if that point is now or not
<mvo> +1
<mvo> ta
<mborzecki> ijohnson: hey, looking at your feedback in #9005, bootloader.Options is too confusing :/
<mup> PR #9005: boot: support setting extra command line argument, bootloader interface tweaks <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9005>
<pedronis> mborzecki: I asked a question there
<pedronis> and hi
<mborzecki> pedronis: hey
<zyga> hey, welcome back pedronis :)
<ijohnson> Welcome back pedronis
<ijohnson> mborzecki: mmm you mean my feedback is confusing or it's too confusing to pass Options there?
<mborzecki> pedronis: yeah, that's why i used InitramfsUbuntuBootDir there, should give us ubuntu-boot in install mode and run mode
<mborzecki> ijohnson: options has become a bit confusing
<pedronis> we need to fix the names of things
<ijohnson> ah yes options is rather confusing now with all the different names and implications
<mborzecki> ijohnson: pedronis: anyways i did not add a helper for setting extra args in recovery mode, as we can do it directly in makeBootable20
<mborzecki> s/in/for/
<pedronis> I I have updated my review queue, but not started on reviews yet, maybe this afternoon, I still have some catch up to do and also quite a few meetings in the afternoon
 * pedronis but lunch first
<zyga> uh, some annoying pain
<mborzecki> uhh, managers tests are mocking/state setup heavy
<ijohnson> mborzecki: haha yes indeed they are :-)
<ijohnson> mborzecki: so I'm reviewing your code for setting up the cmdline for grub.cfg when managed by snapd PR's and I just want to take a step back and wonder why we need to have the static cmdline args inside the grub.cfg inside snapd at all? Why don't we have some other kind of internal asset setting which is just a list of strings (or a map[string]string) for the static / extra cmdline parameters separate from the grub.cfg
<ijohnson> then we would not need to parse out the grub.cfg's setting of the cmdline from the grub.cfg at all, we would just compose it easily using go list of strings (or again a map) and then paste it into the grub.cfg when it is generated and written out to disk
<ijohnson> that also seems like what we will end up doing when the gadget.yaml grows language to tell snapd about what kernel command line should be used
<pedronis> ijohnson: the last part is horrible
<ijohnson> woah sorry what is horrible
<pedronis> composing grub.cfg
<pedronis> doesn't seem we need to parse it
<pedronis> I don't have a preference on that
<ijohnson> it's literally just fmt.Sprintf with `cmdline=%s` ?
<ijohnson> well seems it's slightly more complicated than that
<pedronis> ijohnson: yes, but the edition inside it loses any meaning
<pedronis> that's why I used the word horrible
<ijohnson> so how will this work when the gadget.yaml wants to tell snapd what kernel command line to use ?
<mborzecki> pedronis: ijohnson: maybe we should ahve another chat about cmdline wrt the doc that we discussed?
<ijohnson> maybe I need to read your doc again
<pedronis> ijohnson: the plan is to use the envs to convey that
<pedronis> not the cfg
<pedronis> maybe that isn't clear from the current code
<mborzecki> ijohnson: hence snapd_extra_cmdline_args
<pedronis> anyway none of this particularly means we should parse something out of the cfgs, I don't have a strong peference there
<pedronis> given how actually this is used is slightly misleading
<pedronis> in fact
<pedronis> mborzecki: ijohnson: yes, I think another chat might be appropriate
<pedronis> not sure we can fit it today though
<ijohnson> sure I think a chat would be good
<mborzecki> pedronis: maybe right before/after the standup?
<pedronis> before could work
<ijohnson> works for me
<ijohnson> but in case it is an easy answer, which direction is snapd_extra_cmdline_args used? is that set by the gadget on image build time into the bootenv and then read by install mode snapd to then be used in writing the run mode bootloader config / env ?
<pedronis> ijohnson: it's never read, it meant to be only written to
<ijohnson> oh actually now I've gone and confused myself between the extra and static args
<pedronis> I mean is read by the cfg but snapd code should always only write it
<ijohnson> pedronis: so extra is always written by snapd out of thin air, and static is always coming entirely from the bootenv / gadget ?
<mborzecki> pedronis: it's read when we want to compose what the command line will look like
<pedronis> mborzecki: ?
<pedronis> sorry something is very wrong then
<ijohnson> mborzecki: but it's "read" from inside snapd though right ?
<ijohnson> it's not read from the system / bootloader
<ijohnson> iiuc
<pedronis> ijohnson: mborzecki: it should be read from the gadget, never from the env by snapd
<ijohnson> pedronis: when you say "it" just now, which one do you mean ?
<pedronis> the extra args
<pedronis> if I remember what was discussed
<pedronis> I haven't looked at the code
<pedronis> maybe we need pseudo code hre
<ijohnson> yes what's confusing me is the ownership / reading direction of the env vars
<pedronis> it should be very clear when you consider the security implication what should and shouldn't happen
<pedronis> but I don't know what the current code is doing
<ijohnson> yes, let's ignore the current code for now (sorry mborzecki :-) )
<mborzecki> pedronis: hmm right, but we don't have the gadget part yet because it was not discussed, so the code is reading it from the env until we figure out the gadget.yaml
<pedronis> mborzecki: it shouldn't do anything
<pedronis> then
<pedronis> this has all security implications
<pedronis> we cannot half build pieces
<pedronis> without thinking through the consequences
<mborzecki> pedronis: yes, the same as reading static from disk, ok, let me drop that for now and leave a todo about gadget there
<ijohnson> iiuc snapd should own the "static" env var and that should be entirely written by snapd for run/recover mode, and the gadget should own the "extra" part by writing into it's default bootenv for install mode, which snapd then just copy pastes from install bootenv into the run/recover boot env
<ijohnson> is that understanding what you expect pedronis?
<pedronis> sounds about right
<ijohnson> ok
<ijohnson> I think I understand what the design is then
<mborzecki> and i need to update the doc then
<pedronis> ijohnson: actually, no, the copy from install bootenv sounds wronng
<ijohnson> oh
<pedronis> snapd should read this info out of the gadget
<pedronis> never the env
<ijohnson> ah yes that was what I thought the original design was supposed to be
<ijohnson> by read out of the gadget, do you mean read the bootenv out of the gadget snap, or do you mean read something like the gadget.yaml ?
<pedronis> it then should write to env and use the pieces it built to know what to put as expectzed in the fde policy
<pedronis> ijohnson: there's not bootenv in the gadget
<pedronis> afair
<pedronis> not for grub
<pedronis> or maybe there is
<pedronis> anyway, some info out of gadget.yaml or a .txt file
<mborzecki> iirc we discussed gadget.yaml the last time
<ijohnson> pedronis: for grub there is not
<ijohnson> alright that all makes more sense and is closer to what I expected
<mborzecki> fwiw, whether gadget or txt file is fetching it should be trivial
<ijohnson> right
<pedronis> ijohnson: mborzecki: do we still need a meeting?
<ijohnson> I think it would still be nice even if just for 10-15 minutes
<mborzecki> pedronis: ijohnson: 5-10 minute one right before the standup maybe? so that we're on the same page
<pedronis> ok
<ijohnson> sounds good to me
<pedronis> let's do 10 mins
<ijohnson> k
<mup> PR snapd#9011 opened: release: merge 2.45.2 into release/2.45 <Created by mvo5> <https://github.com/snapcore/snapd/pull/9011>
<sdhd-sascha> Is "MicroStack" worth a look? Or should i go another way?
<sdhd-sascha> okay,
<sdhd-sascha> ```
<sdhd-sascha> error: cannot install "microstack": cannot query the store for updates: got unexpected HTTP status
<sdhd-sascha>        code 503 via POST to "https://api.snapcraft.io/v2/snaps/refresh"
<sdhd-sascha> ```
<sdhd-sascha> I think is not you ;-) Is my LAN ;-)
<mup> PR snapcraft#3216 closed: build providers: tweak environment clean detection and logging <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3216>
<mup> PR snapcraft#3217 closed: cmake v2 plugin: add stage to CMAKE_PREFIX_PATH <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3217>
 * zyga breaks for 15 minutes and then back to branches
<mup> PR snapcraft#3218 closed: lxd: enable security.syscalls.intercept.mknod if supported to allow snaps to create some device nodes <bug> <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3218>
<ijohnson> sdhd-sascha: the snap store is a bit under load right now, you might have difficulty installing snaps for a little bit today, but give it an hour or two and itshould be back to normal I think
<ijohnson> cmatsuoka: regarding your comment here https://github.com/snapcore/snapd/pull/9010#discussion_r455026520, what do you mean archive and snap versions? of govendor?
<mup> PR #9010: cmd/snap-bootstrap/initramfs-mounts: call systemd-mount instead of the-tool <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9010>
<cmatsuoka> ijohnson: govendor, I remember I had a problem with mismatched hashes some time ago and I think it was caused by using a different govendor version
<ijohnson> mmm I only have govendor from $GOBIN
<cmatsuoka> ijohnson: now I'm using the focal deb which seems to be working well
<ijohnson> mmm, perhaps I could try that, seems the focal version is 1.0.9 which is the same as my local $GOBIN, but I will look at what happens with the deb to see if that explains the SHA difference
<cmatsuoka> or your new hash is right and the previous one was computed with a different version?
<mborzecki> mvo: there's a conflict in https://github.com/snapcore/snapd/pull/9011
<mup> PR #9011: release: merge 2.45.2 into release/2.45 <Created by mvo5> <https://github.com/snapcore/snapd/pull/9011>
<mvo> mborzecki: will fix after the meeting
<ijohnson> cmatsuoka: actually with the focal version of govendor I see the same diff, I did a clean checkout of snapd into a separate GOPATH, and only had govendor from apt on my $PATH and running get-deps still makes that checksumSHA1 change
<ijohnson> cmatsuoka: so I'm really confused what's up here
<ijohnson> cmatsuoka: are you on focal and using the deb ?
<cmatsuoka> let me double check here
<cmatsuoka> mm, yes, version 1.0.9+ds1-1
<ijohnson> yeah same here
<cmatsuoka> perhaps the previous hash is old, and the one you're computing now is what it should be?
<zyga> isn't govendor using the stuff from your gopath?
<zyga> (as in, it can put stuff from gopath into vendor)
<mup> PR snapd#9011 closed: release: merge 2.45.2 into release/2.45 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/9011>
<ijohnson> zyga: yes but I have a new clean gopath with nothing in it except a fresh snapd master clone
<zyga> ah
<zyga> hmmmm
<zyga> no idea then
<zyga> could it be looking at more than gopath?
<zyga> e.g. goroot?
<ijohnson> cmatsuoka: are you using go from the snap or from the debian package ?
 * ijohnson only uses go from snap
<cmatsuoka> mm, mine is from the deb, 2:1.13~1ubuntu2
<ijohnson> cmatsuoka: what is `go version` for you ?
<cmatsuoka> go version go1.13.8 linux/amd64
<ijohnson> mine is `go version go1.14.4 linux/amd64`
<cmatsuoka> I used to use the snap version then switched to the deb version at some point
<mup> PR snapd#9012 opened: release: merge 2.45.2 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/9012>
<zyga> that's one unusual diff ;)
<mup> PR snapd#9013 opened: many: merge 2.45.2 fixes back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/9013>
 * cachio lunch
<ijohnson> cachio: when you are back can you explain to me the early config test failure ?
<mborzecki> store seems to be under load, spread jobs are failing
<ijohnson> yes
<mborzecki> hmm something odd happening with github, i've pushed changes to a branch, but the PR was not updated
<ijohnson> github under load too ?
<mborzecki> ijohnson: can you take a look at https://github.com/snapcore/snapd/pull/9006 later during your day? i've pushed the changes but the PR was not updated yet (hopefully it will be soon)
<mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<ijohnson> sure
<mup> PR snapd#9014 opened: [RFC] snapshotstate: move sizer to osutil.Sizer() <Created by mvo5> <https://github.com/snapcore/snapd/pull/9014>
<mborzecki> ijohnson: thanks
<mborzecki> closed and reopened, and now the commits show up, wtf
 * ijohnson afk little bit
<mup> PR snapd#9015 opened: cmd/snap-preseed: handle relative chroot path <Bug> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9015>
<cachio> ijohnson, hi
<ijohnson> hi
<cachio> ijohnson, so, the problem is that when we create the image and tehn try to connect the user created through cloud init is not sudoer
<ijohnson> mmm
<cachio> this is the log I got from the cloud init https://paste.ubuntu.com/p/McnFjkHBVh/
<ijohnson> cachio: what specific test failed with what backend ?
<cachio> ijohnson, it is happening 100% of the time
<cachio> just sometimes
<cachio> spread -debug google-nested:ubuntu-20.04-64:tests/nested/manual/core20-early-confi
<ijohnson> cachio: sorry you mean that it is _not_ happening 100% ?
<cachio> ijohnson, sometimes works well
<cachio> but sometimes it doesn't
<cachio> this is the weird part
<cachio> so if you run this test 3/4 times you will reproduce it for sure
<zyga> cachio what's the username you were expecting to see?
<cachio> user1
<zyga> do you have a log from a successful run?
<cachio> zyga, no
<cachio> zyga, I can generate one
<zyga> maybe if we compare them something will show up
<zyga> 18:00, time for meds
<cachio> zyga, yes
<cachio> agree
<zyga> ouch, brb
<ijohnson> cachio: ah now I can't reproduce that because store woes
<ijohnson> cachio: I will try to reproduce again in a bit
<cachio> ijohnson, this is the log when it works well https://paste.ubuntu.com/p/zWdn8kjb8Q/
<cachio> perhaps it contains usefull data
<cachio> I am taking a loog
<cachio> look
<ijohnson> cachio: looking
<cachio> take a lok to line 460
<cachio> the it adds the user
<cachio> but in the other one that line does not appear
<cachio> ijohnson, the weird part is that in both cases the user is created
<cachio> ijohnson, could you reproduce it?
<cachio> I triggered it again
<cachio> I'll give you access if it fails
<ijohnson> cachio I'll try again this morning the store was acting up for me
<ijohnson> Err rather, I'll try again right now
<mup> PR snapd#8972 closed: gadget/install,secboot: use snapcore/secboot luks2 api <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8972>
 * cachio -> kinesiologist
<ijohnson> diddledan: when you tried etrace and it didn't automatically close the window, were you using wayland ?
<mup> PR snapd#9016 opened: secboot: improve key sealing tests <Test Robustness> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9016>
<mup> PR snapd#9009 closed: tests/cmd/snap-bootstrap/initramfs-mounts: rm duplicated env ref kernel tests <Simple ð> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9009>
<cachio> ijohnson, hi
<cachio> there?
<cachio> ijohnson, could be affecting that rsyslog configuration in cloud init?
<cachio> stages.py[DEBUG]: Running module rsyslog (<module 'cloudinit.config.cc_rsyslog' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_rsyslog.py'>) with frequency once-per-instance
<cachio> in this test we update the gadget configuration and disable rsyslog by default
<cachio> I see that when it fails to created the user1 is when this line "Running module rsyslog" is executed early
<cachio> before than the user
<cachio> could that be affecting?
<cachio> cmatsuoka, hey
<cmatsuoka> cachio: hi
<cachio> could you give me the details about the test on uc20?
<cachio> so I add that
<cachio> I was a bit delayed today with other stuff and couldnt start yet
<cmatsuoka> cachio: no worries, I'm testing my updates manually. The idea is to start with a beta system, update snapd, and it should still work after rebooting
<cmatsuoka> because something can break in the TPM parameters
<cmatsuoka> until now it worked normally after the update
<cachio> cmatsuoka, ok, so snapd from beta to edge
<cachio> right?
<cachio> cmatsuoka, so I could run that when we have a new instance on edge
<cmatsuoka> yes, but on the beta image
<cmatsuoka> with only snapd being updated
<cmatsuoka> it's not exactly from beta to edge, it's from beta to the current branch being tested
<cmatsuoka> (which is not edge because it's not published yet)
<cachio> cmatsuoka, so, from beta to master
<cachio> right?
<cachio> this should be executed on each pr?
<cachio> or nightly is ok?
<cmatsuoka> hm, I think nightly could be ok because very few PRs will touch TPM
<ijohnson> cachio I don't think rsyslog would affect sudo user from cloud-init but unfortunately I've already EOD'd so I'll have to look tomorrow
<cachio> cmatsuoka, nice, I'll do it
<cmatsuoka> cachio: is it costly to do for every PR? if it's not so costly, maybe we could do it
<cmatsuoka> we'll have changes in boot and bootloader too
<cmatsuoka> so maybe it could be interesting to have it for every PR
<cachio> cmatsuoka, I think initially I would add it to the nightly suite
<cmatsuoka> cachio: ok!
<cachio> and then to the regular
<cachio> because we need a new system with tpm and uc20 on each pr
<cachio> and this could be a bit more complicated
<cmatsuoka> cachio: thanks! it will help us to ensure that beta can be upgraded
<cachio> cmatsuoka, sure
<cmatsuoka> cachio: ah ok, then nighly is fine
<cachio> tomorrow I'll give you the update
<cmatsuoka> cachio: thanks!
<cachio> cmatsuoka, yaw
#snappy 2020-07-16
<jamesh> ijohnson: edge Snapcraft might let you create device files under LXD now: https://github.com/snapcore/snapcraft/pull/3218
<mup> PR snapcraft#3218: lxd: enable security.syscalls.intercept.mknod if supported to allow snaps to create some device nodes <bug> <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3218>
<mborzecki> morning
<mborzecki> ayy store is down?
<mborzecki> mvo: hey
<mborzecki> mvo: snap downloads fail, store is down apparently https://status.snapcraft.io/
<mborzecki> mvo: how does one add 2.45.3 milestone to lp?
<mvo> mborzecki: there is a crate milestone button on "https://launchpad.net/snapd/trunk"
<mvo> mborzecki: uh, store down not great
<mborzecki> mvo: cool, added 2.45.3 now
<mvo> mborzecki: thank you
<pstolowski> morning
<mvo> good morning pstolowski
<mborzecki> pstolowski: hey
<mup> Bug #1887760 opened: Installing snap app is not updating required content snap <Snappy:New> <https://launchpad.net/bugs/1887760>
<mborzecki> mvo: interesting question in the forum https://forum.snapcraft.io/t/minimum-hw-requirements-for-running-ubuntu-core/18892/3
<mborzecki> mvo: aiui storage requirements are higher due to recovery, but not sure about ram, guessing it's roughly the same
<mvo> mborzecki: yeah, should be the same size for ram
<mvo> mborzecki: we always wanted to create a nested spread test that runs with e.g. 256mb to see if it survives our testsuite
<mborzecki> mvo:  hmm didn't claudio try that and then he hit the grub problem?
<mborzecki> (for uc20)
<mvo> mborzecki: yeah, I mean for uc16/uc18
<mvo> mborzecki: would still be nice to have such a nested test to ensure we don't regress
<mup> Bug #1887760 changed: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>
<mup> Bug #1887760 opened: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>
<mborzecki> mvo: we don't have an official ballpark number for storage though?
<mup> Bug #1887760 changed: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>
<mborzecki> hmm wonder whether there is liek a reference gadget that's within the minimal requirements range
<mup> Bug #1887760 opened: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>
<mvo> mborzecki: it depends a bit on the kernel size
<mvo> mborzecki: like you can have custom kernels that are smaller
<mborzecki> ehh, can't build an image, because snapd can't fetch any assertions :/
<mvo> mborzecki: otherwise it's 2*(55Mb+31Mb+1Mb+kernel-size)
<mvo> mborzecki: the reference kernel is very big (168mb)  but no real device is using that
<mvo> mborzecki: well, not *no* but most have a custom optimized kernel
<mborzecki> mhm
<mborzecki> need to run an errand, back in 1h or so
<pstolowski> hmm i store unhappy? even https://api.snapcraft.io times out
<pstolowski> okay, it works but super slow here
<mvo> pstolowski: yes, unhappy
<pstolowski> mhm
<mborzecki> re
<mborzecki> the store is back, yay
<pstolowski> good
<mborzecki> is pedronis off today?
<mup> PR snapd#9017 opened: o/snapstate: disk space check in Ensure (4/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9017>
<pstolowski> pedronis: hi! can we discuss preseed debug after the standup today?
<mup> PR snapd#9018 opened: cmd/snap-preseed: check that target path exists and is a directory on --reset <Preseeding ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9018>
<pedronis> mvo: what is the fix-preseed branch for?
<mvo> pedronis: this looks like a mistake
<pstolowski> yes, was my mistake
<pstolowski> sorry
<pedronis> ah
<mvo> no worries, I will just delete it
<pstolowski> github confused me yesterday
<mvo> removed
<pstolowski> ty
<pedronis> pstolowski: yes, I'll try to write something down beforehand as well
<pstolowski> pedronis: ok, great, thank you
<pedronis> pstolowski: I shared a doc
<pstolowski> pedronis: yes, got it, thanks
<mup> PR snapd#9019 opened: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9019>
<pedronis> pstolowski: I did a pass on #8960
<mup> PR #8960: o/snapstate,servicestate: use service-control task for service actions (9/9) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8960>
<pstolowski> pedronis: ty!
<mup> PR snapd#9020 opened: cmd: add new "snap recovery" command <Created by mvo5> <https://github.com/snapcore/snapd/pull/9020>
<mborzecki> cachio: switching to test/main/manual now, i'll push a patch soon
<cachio> mborzecki, nice, thanks
<ijohnson> mborzecki: do you mean tests/nested/manual ?
<mborzecki> ijohnson: yeah, silly typo ;)
<mborzecki> cachio: i've updated #9019
<mup> PR #9019: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9019>
<cachio> mborzecki, nice, thanks, I'll take a look
<ijohnson> cachio: I've run the core20-early-config nested spread test 3 times now and it hasn't failed yet, I'm running this on master:
<ijohnson> spread -debug google-nested:ubuntu-20.04-64:tests/nested/manual/core20-early-config
<ijohnson> is that the right test ?
<mborzecki> ijohnson: so it booted then, hmm
<ijohnson> mborzecki: I was trying to reproduce the issue cachio explained about the nested test with cloud-init users not being sudoers
<mborzecki> ijohnson: can you try running google-nested:ubuntu-20.04-64:tests/nested/manual/minimal-smoke from 9019 too?
<ijohnson> mborzecki: sure I can give it a try
<mborzecki> ijohnson: thanks
<mup> PR snapcraft#3219 opened: meta: detailed warnings for resolution of commands <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3219>
<cachio> ijohnson, yes, it is ok
<cachio> sometimes it works 5 times
<cachio> and then fails
<ijohnson> cachio: ack I'll keep trying then
<mborzecki> ijohnson: cachio: ha, so i'm starting the vm manually with -serial stdio, and i'm getting `error: invalid signature` (probably coming from grub) and then it gets back to the prompt
<ijohnson> mborzecki: are you using google-nested or qemu-nested ?
<mborzecki> ijohnson: google-nested
<ijohnson> ah then you start a uc20 nested vm right ?
<mborzecki> yes
<ijohnson> yeah that will need the special spread version with mvo's patches to support specifying the -bios option from an env var
<ijohnson> I don't know if the spread that is downloaded from that s3 link has support for that env var or not
<mborzecki> do we use that spread binry in any of the tests arleady?
<ijohnson> good question, I don't know
<ijohnson> I have a locally built version I use
<mborzecki> cachio: ^^ do you know where i can get it from?
<mborzecki> ijohnson: but.. the test is running qemu directly
<cachio> mborzecki, I think you need to build it
<mborzecki> ijohnson: as in calling qemu-system-x86_64 arg arg ..
<ijohnson> mborzecki: ah hmm good point and you're using external backend
<ijohnson> mborzecki: maybe you're missing some of the special nested env vars to make booting uc20 work
<cachio> mborzecki, spread pr not merged yet
<mborzecki> hmmm i think the test is doing something wrong, we're supposed to boot with efi always
<cachio> spread2 does not included that yet
<cachio> I could add that
<mborzecki> i mean, start_nested_core_vm_unit, it's not setting -bios unless secure boot is enabled
<mborzecki> yeah, now it's booting all right
<mborzecki> need to run an errand, i'll push the fix when i get back
<mborzecki> cachio: ijohnson: afaict we're always expecting efi for uc20, so we need to pass -bios /usr/share/ovmf/OVMF.fd even if secure boot is not enabled in the test
<pedronis> mborzecki: should I review 9005 first or 9006 ?
<mborzecki> pedronis: i 9005 probably first, then 9006 implements the bootloader bits for grub
<cachio> mborzecki, I'll try that after lunch
 * cachio lunch
<pedronis> mborzecki: is 9006 ready for review, it doesn't seem to match our last discussion?
<pedronis> I marked it blocked for now
<pedronis> pstolowski: I think #9002 should be split (it's smallish now, but the install case likely needs more tests)
<mup> PR #9002: o/snapstate: integrate free space checks with install/refresh and remove (3/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9002>
<pstolowski> pedronis: sure, will do, thanks
<mup> PR snapd#9014 closed: snapshotstate: move sizer to osutil.Sizer() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9014>
<pedronis> pstolowski: thx
<ijohnson> pedronis: I'm confused as I thought 9006 does implement what we agreed on
<pedronis> ijohnson: is there a mapping between edition and command line?
<pedronis> I undersand it has one element atm but there isn't
<ijohnson> yes, see my comment it's through the assets registration
<ijohnson> i.e.
<ijohnson> 	registerInternal("grub.cfg:edition=1:static_cmdline", []byte(grubBootConfigStaticCmdline))
<pedronis> heh
<ijohnson> it's a little odd using the edition=1 in that, but I think it works fine
<pedronis> it's fairly odd
<pedronis> ijohnson: mborzecki: I made some more punctual comments
<mborzecki> re
<mup> PR snapd#9021 opened: snap: implement new `snap reboot` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/9021>
<pedronis> ijohnson: I expect the command line and the cfg to change at different pace, hopefully cfg will change more often for a while
<pedronis> mborzecki: sorry to have turned a bit more prescriptive in 9006, I'm happy to have a chat tomorrow but I think I explained what I think is a workable approach, that doesn't get annoying the first time we need to change one of the two things
<mborzecki> pedronis: thanks for the comments, i see what you mean now, i'll tweak how per edition assets are stored internally the, the current string->[]byte would be cumbersome without coming up with a key like i did now
<ijohnson> pedronis: yes that makes sense
<pedronis> mborzecki: to be clear I think it fine to store the assets as we do now, and have a different storage
<pedronis> for the snippets (as I called them)
<mborzecki> pedronis: as for 9005, i think that having some code to consume the api would make it clear how SetExtraCommandLineArgs should work (i.e. reseal internally or not?), maybe i should split out the bits that fix the command line and just leave a PR with the setter?
<pedronis> mborzecki: ijohnson: also about 9006, does it make sense to change the commandline without bumping the edition (this is not supported by my approach either) ?
<pedronis> mborzecki: 9005, you mean *without* the setter?
<mborzecki> pedronis: yes, without, there's bits that make it clear that the order is <mode> <static> <extra> and a tweak to bootloader.ManagedAssetsBootloader.CommandLine()
<ijohnson> pedronis: mmm so in that case we would be changing the static portion of the kernel command line. tbh I don't think that will change much if at all for amd64/grub, so I don't think it's imperative we have that accounted for right now, what I think would change more likely over the lifetime of a device is the gadget defined extras
<pedronis> mborzecki: sounds ok for now
<pedronis> mborzecki: I meand 9005 without the setter
<mborzecki> pedronis: yup, the chats interleave, but that's what i understood
<pedronis> ijohnson: yea, anyway to support changing the commandline without bumping the edition, we would need both edition (that controls the updating) and some kind of version to track variation
<pedronis> we can retrofit it in I suppose if we end up there
<ijohnson> pedronis: you could synthetically create an edition from the asset version + kernel cmdline version
<ijohnson> I think it is probably fine to retrofit something later on
<pedronis> ijohnson: by definition edition is not synthetic, it's way to say I think old devices should get this
<pedronis> it's a decision we make
<pedronis> like for gadget asserts
<pedronis> *assets
<ijohnson> sorry all I meant is that the decision on whether devices get an update is a function of both edition + cmd line
<pedronis> that's why we reused the term edition
<pedronis> ijohnson: yea, but I don't see the static command line as separate from the asset
<ijohnson> I think we are in agreement that it's probably fine to not support that right now internally
<pedronis> anyway I think we can retrofit things if needed, as long as we are conscious if we stumble on trying to do that
<mup> PR snapcraft#3220 opened: review tools: link or copy snap to snap common <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3220>
<pedronis> anyway it's another reason why I don't like templating in the commandline
<pedronis> it's prone to confusion
<pedronis> it's a case were repetition is feature
<pedronis> where
<ijohnson> well repetition is also prone to bugs using different things in different places
<pedronis> well that's why I said we need a test
<pedronis> ijohnson: the risk here is doing a change without understanding the consequences
<ijohnson> agreed on a test
<ijohnson> I don't disagree that there are many risks in this area
<pedronis> mborzecki: also one of my comments is that it's probably time to do use "go generate" or similar
<mborzecki> pedronis: yeah, i'm not a fan of go generate, but perhaps it is the time indeed
<mborzecki> pedronis: we'd still commit the artifacts to git right? otherwise the build process gets weird
<pedronis> mborzecki: we can yes, I don't we do for other things though
<pedronis> I mean I don't have a strong opinion either way, as long as it works
<pedronis> with the packaging
<pedronis> this shouldn't change that often (at least after a while)
<mborzecki> pedronis: there's some strutil helpers that were committed, but the versiontool/version.go gets generated  iirc
<pedronis> yea
<mborzecki> hmm why does ssh start in install mode?
<pedronis> we don't turn it off unless it's turned off in all modes I think
<pedronis> (not saying we shouldn't change that)
<mborzecki> ijohnson: cachio: pushed a tweak to #9019
<mup> PR #9019: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9019>
<pedronis> mborzecki: for clarity: https://github.com/snapcore/snapd/pull/9006#discussion_r455922181
<mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<mborzecki> ijohnson: hmm i see both /usr/share/ovmf/OVMF.fd and /usr/share/OVMF/OVMF_CODE.fd, i've always used the first one, so what's the difference? :)
<ijohnson> ah I don't know what's the difference haha
<mborzecki> ijohnson: to make it more interesting, botha re owned by ovmf package
<ijohnson> they also are slightly different sizes with different hashes :-/
<mborzecki> ijohnson: https://github.com/tianocore/edk2/commit/1c50db8adaf9d5ce071e27a518a46cd363ac5efe
<ijohnson> ah so the lowercase dir one is the combined vars and code ?
<mborzecki> ijohnson: that'd make OVMF.fd all-in-one package
<mborzecki> ijohnson: probably makes sense given that you can use your own file to store vars?
<ijohnson> yes so in this context it's probably fine for CI to use a single file
<mborzecki> ijohnson: force pushed a little note
<mup> PR snapd#9022 opened: usersession/userd: do not modify XDG_DATA_DIRS when calling xdg-open <Created by mvo5> <https://github.com/snapcore/snapd/pull/9022>
<mup> PR snapd#9023 opened: sysconfig/cloudinit: add CloudInitStatus func + CloudInitState type <Created by mvo5> <https://github.com/snapcore/snapd/pull/9023>
<mup> PR snapd#9024 opened: sysconfig/cloudinit: add RestrictCloudInit <Created by mvo5> <https://github.com/snapcore/snapd/pull/9024>
<mup> PR snapd#9025 opened: overlord,o/devicestate: restrict cloud-init on Ubuntu Core <Created by mvo5> <https://github.com/snapcore/snapd/pull/9025>
<mup> PR snapd#9026 opened: tests/nested/manual: add spread tests for cloud-init vuln <Created by mvo5> <https://github.com/snapcore/snapd/pull/9026>
<cachio> ijohnson, I could reproduce the error also in another test
<cachio> the cloud init one
<cachio> and using an image downloaded from cdimage
<cachio> so it is not related to that test
<ijohnson> cachio: yeah that's what I kinda expected
<ijohnson> cachio: I have now run that other test 6 times and couldn't reproduce it, if you get a debug shell let me know I would love to take a look at the system
<cachio> ijohnson, yes, I'll try to reproduce it here
<cachio> ijohnson, quick question
<ijohnson> yeah sure
<cachio> I refresh snapd snap from beta to edge and it reboots the systems
<ijohnson> uhhh
<cachio> then I revert and the reboot does not happen
<cachio> is it expected?
<cachio> on uc20
<ijohnson> why does it reboot when you refresh the snapd snap ?
<ijohnson> afaik we shouldn't reboot with snapd snap refreshes
<cachio> well, I expected the same
<ijohnson> cachio: was that just a one time thing or does it always happen ?
<cachio> ijohnson, I am trying to finish the test to refresh/revert snandp
<cachio> and this happened last time
<cachio> now I am running again
<cachio> ijohnson, so, the only which requires reboot is the kernel?
<ijohnson> cachio: the kernel, the base snap (core20 for uc20, core18 for uc18, core for uc16), and the gadget snap if and only if there are gadget updates
<cachio> ijohnson, ok
<cachio> so I need to update the gadget scenario beause I am waiting the reboot
<ijohnson> ð
#snappy 2020-07-17
<mup> PR snapd#9027 opened: tests: refresh/revert snapd in uc20 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9027>
<mborzecki> morning
<mborzecki> heh, looks our spread images don't have moreutils by default
<mborzecki> mvo: hey
<mborzecki> mvo: snap downloads don't work
<jamesh> is there any way to get ubuntu-image to include a system-user assertion in the resulting image?
<mvo> mborzecki: wut?
<mvo> mborzecki: what exactly is broken?
<mvo> mborzecki: store again?
<mborzecki> mvo: yes, the status page lists the search api and downlaods as down
<mvo> :/
<mvo> ok
<mborzecki> mvo: and they do appear down
<mup> PR snapd#9015 closed: cmd/snap-preseed: handle relative chroot path <Bug> <Preseeding ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9015>
<pstolowski> morning
<mvo> good morning pstolowski
<mborzecki> pstolowski: hey
<mup> PR snapd#9028 opened: interfaces: new helpers to get and compare system key, for use with seeding debug api (1/N) <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9028>
<pedronis> pstolowski: small remarks there
<pstolowski> ty
<mborzecki> quick errand, back in 30
<jamesh> pedronis: I had a chat with wgrant earlier today.  His main concerns about the theme API was that it was specific to the theme use case rather than being something more generic.
<mborzecki> re
<zyga> hello
<mvo> zyga: hey, how are you today?
<zyga> mvo hey
<zyga> mvo, like shit in the human centipede, I think
<zyga> not well at all
<zyga> mvo, tired
<mvo> zyga: :( oh no
<zyga> yesterday was incredibly painful, sleeping a little here and there and otherwise just trying to find a position with least pain
<zyga> today morning was similar but it's somewhat better now so I grabbed the laptop
<zyga> I will try to push forward with PRs
<mvo> zyga: thanks! and good luck that the meds help a bit more
<zyga> 28th is the day
<zyga> not that far away now
<jamesh> xnox: fyi, you should now be able to build core20 using "snapcraft --use-lxd" for edge Snapcraft
<jamesh> might be useful to you
<pedronis> jamesh: thanks, let's discuss next week, what it means if anything
<pedronis> zyga: hi, do you remember why in the system-key we list only the top directories in /sys/kernel/security/apparmor/features, for some directories, it makes sense like file or ptrace, the level below has a lot detail that isn't that variable, but something like the policy dir has versions which has supported ABIs I think, so there "policy" alone is not very informative/significative
<zyga> let me think
<zyga> I don't recall why we did this - thinking about it now perhaps because the combinations that actually exists are limited but that's a stretch
<zyga> offtopic: I get a change to vendor.json after get-deps.sh
<zyga> -                       "checksumSHA1": "UUnaKjQAEIclOm5Aqe2VmrMiQJY=",
<zyga> +                       "checksumSHA1": "jK98PjsZS3gPOZfc+pqIQaz6r1A=",
<zyga> that's secboot
<zyga> is that known?
<pedronis> yes, but I have different diff there
<pedronis> have you got the latest of both masters?
<pedronis> my diff is like this:
<pedronis> -                       "checksumSHA1": "fqejS2llZXw3gLnOYhg7pcSlY+Q=",
<pedronis> +                       "checksumSHA1": "Yfj2ZrgRrklXrshCM1RxH5pvUY8="
<zyga> re, sorry I was taking meds
<zyga> I have latest master, I just pulled
<zyga> as for both masters, I don't have secboot checked out separately
<zyga> weird
<mup> PR snapd#9029 opened: api: seeding debug api (2/N) <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9029>
<mborzecki> again quick errand, back in 30
<mup> PR snapd#9030 opened: bootloader/assets: helpers for registering per-edition snippets, register snippets for grub <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9030>
<mup> PR snapd#9022 closed: usersession/userd: do not modify XDG_DATA_DIRS when calling xdg-open <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9022>
<zyga> hmm, we don't have a debian 10 image?
<mborzecki> re
<mborzecki> zyga: but we have sid :P
<mborzecki> and oldstable :/
<zyga> mborzecki we actually have 10
<zyga> it's just not used
<zyga> anyway, I have what I needed
<xnox> jamesh:  horay!
<jamesh> xnox: this is the relevant change: https://github.com/snapcore/snapcraft/pull/3218 -- Snapcraft will now enable security.syscalls.intercept.mknod on the container if there is kernel support, which allows the few mknod calls to succeed.
<mup> PR snapcraft#3218: lxd: enable security.syscalls.intercept.mknod if supported to allow snaps to create some device nodes <bug> <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3218>
<zyga> we should get the new leap image
<mborzecki> zyga: 15.2?
<zyga> new leap version, yeah
<zyga> we seem to have the image? (not sure if cachio made this ahead of time or if we are inheriting one somehow)
<ijohnson> morning folks
<zyga> hello Ian
<ijohnson> hey zyga
<zyga> curious, even leap 15.2 has relatively old systemd
<zyga> 234
<zyga> mborzecki took a while but I updated https://github.com/snapcore/snapd/pull/8977 - not much change but I think it's ready for another look
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<mborzecki> zyga: k, will take a look
<zyga> thanks!
 * zyga afk for 10 minutes
<ijohnson> I have now officially hit the same problem as popey, where I have too many snaps installed and no longer get refreshes :-/
<ijohnson> pedronis: did the bulk refresh stuff you worked on already land in edge ?
<pedronis> ijohnson: no, it's blocked on the store fixing perf issues
<ijohnson> ah ok
 * ijohnson snap removes many things in the meantime
<popey> I worked around this by wiping my laptop
<popey> I now only have 68 snaps
<ijohnson> I just realized I had 98 snaps this morning
<popey> I had 300 at one point
<ijohnson> oh wow that's impressive you could even get to that point :-D
<popey> Not wishing to brag :)
<popey> Ikr
<popey> Also 2x all of them
<ijohnson> ah right, also I have 207 .snap files in my /var/lib/snapd/snaps
<ijohnson> although also I did manually set snapd to keep 5 revisions
<mup> PR snapd#9031 opened: interfaces/audio-playback: let pulseaudio own org.pulseaudio.Server <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/9031>
<mup> PR snapd#9032 opened: secboot: add call to reseal an existing key <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9032>
<mup> PR snapcraft#3220 closed: review tools: link or copy snap to snap common <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3220>
<mup> PR snapd#9033 opened: osutil, many: add helper for checking whether the process is a go test binary  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9033>
<mup> PR snapd#9034 opened: cmd/snap-seccomp/syscalls: add faccessat2 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9034>
<zyga> mborzecki, so about https://github.com/snapcore/snapd/pull/8977
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<zyga> mborzecki apart from failures in master I think it looks good
<zyga> I played with it it some more and ran some more tests in a loop to be sure
<zyga> btw, who is looking at the seccomp test failure?
<mborzecki> zyga: #9034
<mup> PR #9034: cmd/snap-seccomp/syscalls: add faccessat2 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9034>
<zyga> ah, thanks!
<zyga> merge it already :)
<zyga> hmm, interfaces-pulseaudio is failing
 * zyga lunch
<cachio> zyga, could you please take a look to #8973
<mup> PR #8973: tests: moving journalctl.sh to a new journal-state tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8973>
<zyga> sure
<cachio> zyga, and this #8903
<mup> PR #8903: tests: new core config helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8903>
<cachio> zyga, thanks a lot
<zyga> sure, one it
<zyga> on it*
<mup> PR snapcraft#3221 opened: repo: install requested build-package versions <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3221>
<zyga> cachio first done, please look
<zyga> +1 assuming the two comments are adjusted
<zyga> uh, one hour till next pill
<zyga> I hate this time
<zyga> afk for a while
<ijohnson> mvo: looks like https://github.com/snapcore/snapd/pull/9024 is ready, the only failed tests look like store failures
<mup> PR #9024: sysconfig/cloudinit: add RestrictCloudInit <Created by mvo5> <https://github.com/snapcore/snapd/pull/9024>
<mup> PR snapd#9035 opened: o/devicestate: save seeding/preseeding times for use with debug seeding api (3/N) <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9035>
<ijohnson> mvo: if you're still around, if you could close and re-open #9026, I added the "Run nested" label, so all the nested spread tests in that PR will actually run so we should be able to see those pass in Github which would be cool
<mup> PR #9026: tests/nested/manual: add spread tests for cloud-init vuln <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9026>
<ijohnson> cachio: if you have time could you take a look at the nested spread tests in #9026 ?
<mup> PR #9026: tests/nested/manual: add spread tests for cloud-init vuln <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9026>
<mup> PR snapd#9036 opened: snapshots: import of a snapshot set <Created by slimjim777> <https://github.com/snapcore/snapd/pull/9036>
<zyga> mvo https://github.com/snapcore/snapd/pull/9037
<mup> PR #9037: tests: adjust xdg-open after launcher changes <Simple ð> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9037>
<mup> PR snapd#9037 opened: tests: adjust xdg-open after launcher changes <Simple ð> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9037>
<zyga> brb
<pedronis> we have 80 open pull requests
<pedronis> there's some practical reasons for that, but we'll probably need to go back to mostly reviewing soon
<zyga> pedronis ^ that one is easy and fixes (partially) master
<ijohnson> zyga: approved your xdg-open PR
<zyga> thanks :)
<zyga> this will need force-merge or merge into the other fix branch from maciek
<zyga> (for seccomp)
<ijohnson> zyga: ah right, yeah I added critical label to the other one and will check in on that to merge
<ijohnson> ah but wait that one will also break on xdg-open too
<zyga> ack
<ijohnson> and there goes mvo with sudo git merge powers
<zyga> vader: noooooo
<cachio> ijohnson, hey, if you have time could you please take a look to #8903?
<mup> PR #8903: tests: new core config helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8903>
<ijohnson> cachio: sure, did you see my ping about the nested cloud-init PR?
<cachio> ijohnson, no
<cachio> checking now
<ijohnson> thanks
<ijohnson> those tests were what we landed for the cloud-init CVE
<cachio> ijohnson, I'll need to change how we run the nested tests because we are creating many nested/manual tests
<ijohnson> cachio: yes that PR adds 8 more nested tests
<ijohnson> cachio: is it a workers issue ?
<cachio> yes
<cachio> I'll split the nightly suite in 2 jobs
<cachio> 1 for nightly
<cachio> and 1 nested
<cachio> and perhaps 1 manual
<ijohnson> ok, makes sense
<cachio> also because those use different spread params
<cachio> spread env vars
<cachio> you are taking the #9026 when mvo is on vacations?
<mup> PR #9026: tests/nested/manual: add spread tests for cloud-init vuln <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9026>
<ijohnson> cachio: I'd prefer if we could land 9026 as-is first if that's okay with you and then yes I will work on any follow-ups needed
<ijohnson> it would be good to make sure that master gets the fix for the CVE asap, in case there are devices that are only following edge, they will not get the fix yet since the fix is only on stable
<ijohnson> granted that's a very small number of devices I think, but still
<cachio> ijohnson, ok, I think the only important is to avoind installing/removing genisoimage
<cachio> this could break the following tests
<ijohnson> cachio: sure I think I can push a change, what's the issue with genisoimage ?
<ijohnson> ah is that package already installed ?
<cachio> yes
<cachio> we do that inthe spread.yaml
<cachio> while the suite is preapred
<ijohnson> cachio: let me push up a change for that then to mvo's pr
<cachio> ijohnson,  then there are some other cosmetic stuff that can wait
<ijohnson> ok
<ijohnson> cachio: pushed up a change to not install/remove genisoimage
<cachio> ijohnson, thanks
<cachio> let me check a bit more and I'll approve it
<ijohnson> cachio: I'd like to close and re-open 9026 actually, so that we can have the nested spread runs run too, do you know if it works to add the label to the pr after it is opened ? I seem to recall it doesn't work to add the label afterwards
<ijohnson> but I also don't know if I can re-open the PR if I close it since mvo is the one who opened it
<ijohnson> I suppose I could re-open it with a new PR number myself
<cachio> ijohnson, I can also run the tests here and paste hte result
<ijohnson> okay that works too
<cachio> ijohnson, +1
<cachio> attached all the logs
<ijohnson> Thanks cachio
<cachio> ijohnson, yaw
<mup> PR snapd#8903 closed: tests: new core config helper <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8903>
 * sdhd-sascha damn, just going backing back to SuSE... But the Kubic Distro didn't work with Rancher.... Hmm... (Then i look for an channel to talk... couldn't find some...
<sdhd-sascha> I wonder, what is really "open"source...
<sdhd-sascha> ohOh, i talk .... But ... ;-)
<sdhd-sascha> ijohnson: you, can't slowly me?
<sdhd-sascha> oh, i hope you know, that i just mean it with "words"
<sdhd-sascha> ijohnson: i'm already repeatly read my text... and nothind is true!!!
<sdhd-sascha> ijohnson: i'm sorry ;-)
<sdhd-sascha> ijohnson: i'm damn fucking angry, about our wourld!!! ...
<sdhd-sascha> if i had a problem, whit to much beer.. i know where "ubuntu" is... but i didn't know where i can distorquer them .... ?  hmmm.... (me ...)
<sdhd-sascha> i want to say, that other ompanys are not here...
<sdhd-sascha> ijohnson: how are you ? i'm not angry?
<sdhd-sascha> (dont now) I can learn.
#snappy 2020-07-18
<mup> PR snapcraft#3222 opened: fix typo <Created by snshn> <https://github.com/snapcore/snapcraft/pull/3222>
