#snappy 2015-09-07
<fgimenez> good morning
<dholbach> good morning
<JamesTait> Good morning all; happy Monday, and happy Buy a Book Day! ð
 * Chipaca buys a book
<JamesTait> Which book, Chipaca?
<Chipaca> http://www.amazon.co.uk/gp/product/0356502422
<Chipaca> JamesTait: although some would call it the promise of a book
<JamesTait> Chipaca, isn't that true any time you order something for delivery?
<Chipaca> JamesTait: get off with you and your logical thinking
<JamesTait> "Take my money, and promise me you'll post the item to me."
<asac> how can i get a core dump on snappy? e.g. how to set where it will write it etc?
<sergiusens> asac, I think we want to set /proc/sys/kernel/core_pattern to something more useful than 'core'
<sergiusens> but that as far as my knowledge goes, maybe pitti or ogra_ can chime in
<sergiusens> on desktop (and I guess phone), it's piped to apport
<ogra_> well, we dont ship apport ...
<ogra_> so i'm not sure
<ogra_> you might be able to trigger a core dump but i dont think it would be processed
<sergiusens> ogra_, the pattern is set to 'core', maybe we want a fixed path
<ogra_> yeah
<sergiusens> ogra_, since the working dir would be the snapdir in most cases
<ogra_> sergiusens, well, i'd dump it to /run or /tmp (in the respective snap subdir)
<ogra_> not sure if thats possible though, /proc/sys/kernel/core_pattern is a global thing, nt sure it takes variables
<ogra_> (beyond tthe defined ones)
<sergiusens> ogra_, we can pipe it into somehting that would understand the variables, but yeah, would be complicated
<ogra_> ah, right ... we could call that thing we pipe into "apport" :)
<ogra_> or probably better "snapport" :)
<sergiusens> ;-)
<sergiusens> mvo, did you have any time to check my MP?
<asac> ogra_: sergiusens: i am sure it wouldnt be processed, but if we know how to enable to dump it that would already help
<ogra_> echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern
<ogra_> as root
<asac> how much space do we have in /tmp usually? enough for any reasonable dump:
<ogra_> that would dump it to /tmp/core.$executable.$pid
<asac> ?
<ogra_> dunno, else point to somewhere in /writable
<ogra_> the kernel wont care
<ogra_> asac, /tmp is a tmpfs ... so limited to ram size indeed
<asac> ogra_: is there another presistent directory that also has the /tmp properties of getting wiped from time to time?
<mvo> sergiusens: not yet, sorry, I do that now
<miken> Hi mvo o/
<miken> If anyone has time for a quick review, I wrote this doc update last week - https://code.launchpad.net/~michael.nelson/snapcraft/fix-golang-tutorial-to-match-changes-from-r132/+merge/270131
<mvo> hey miken
<ogra_> asac, /var/log ? and a logrotate rule ?
<ogra_> i.e. /var/log/core ... and have files wiped regulary ...
<ogra_> ... or by size or whatever
<asac> ogra_: how are we doing logrotate?
<sergiusens> elopio, hey, how do you feel about rebasing your symlinks branches on top of the repo one?
<elopio> sergiusens: no problem.
<elopio> fgimenez: lets meet tomorrow.
<fgimenez> elopio, ok np
<sergiusens> elopio, thanks!
<elopio> ogra_: how do I generate the init img from this initramfs-tools-ubuntu-core branch?
<dholbach> hey hey sergiusens, do you remember if there was any discussion about allowing packages being pulled from PPAs for snapcraft?
<beuno> dholbach, hi
<dholbach> hey beuno
<sergiusens> dholbach, yes there was; not sure how to cleanly do this yet
<dholbach> sergiusens, should I file a bug for it?
<sergiusens> dholbach, I think there is a task for it already on trello
<dholbach> hum.......is there a separate trello board for snapcraft?
<sergiusens> dholbach, no, it has it's own lane
<dholbach> ah yes, found
<guest42315> uuu mycroft kicks a$$ :P http://i.imgur.com/cCrM6Nj.png
<ogra_> :D
<sergiusens> elopio, this mp has your name all over it :-P https://code.launchpad.net/~sergiusens/snapcraft/yaml_init/+merge/270325
<elopio> sergiusens: I'm already looking at it. I'm too fast for you :p
<sergiusens> elopio, \o/
<sergiusens> elopio, slow Monday I guess ;-)
<sergiusens> elopio, https://code.launchpad.net/~sergiusens/snapcraft/yaml-tabs/+merge/270331
#snappy 2015-09-08
<vmayoral> Morning!
<vmayoral> Some might be interested on https://www.indiegogo.com/projects/erle-spider-the-ubuntu-drone-with-legs.
<dholbach> good morning
<fgimenez> good morning
<dholbach> https://code.launchpad.net/~dholbach/snapcraft/1491303/+merge/270363
<ogra_> mvo_, hmm, vivid images stopped building, seems the ubuntu-snappy source doesnt build the ubuntu-snappy binary anymore
<ogra_> resulting in:
<ogra_> The following packages have unmet dependencies:
<ogra_>  ubuntu-snappy : Depends: ubuntu-snappy-cli (= 1.0.1-1+467~ubuntu15.04.1) but it is not going to be installed
<ogra_> E: Unable to correct problems, you have held broken packages.
<ogra_> P: Begin unmounting filesystems...
<ogra_> oh, failed on amd64 ...
<ogra_>    dh_install -O--buildsystem=golang -O--fail-missing
<ogra_> cp: cannot stat 'debian/tmp//usr/bin/xgettext-go': No such file or directory
<ogra_> dh_install: cp -a debian/tmp//usr/bin/xgettext-go debian/golang-snappy-dev///usr/bin/ returned exit code 1
<ogra_> make: *** [binary] Error 2
<ogra_> Chipaca, any idea about the above ? seems it comes from backporting https://code.launchpad.net/~chipaca/snappy/delayed-service-start into 15.04 (why is there xettext in that merge at all ?)
<ogra_> *xgettext
<JamesTait> Good morning all; happy Tuesday, and happy Physical Therapy Day! ð
<Chipaca> ogra_: not entirely sure, no; mvo patched up the xgettext thing for it to work
<livcd> Hi what exactly is ubuntu Core ? I have obviously read the description page but still fail to understand the purpose
<livcd> is it meant to be a "container OS" for a docker like environment
<livcd> or a base system running docker images ? :3
<livcd> or both
<ogra_> it is meant to be a core of any kind of OS
<ogra_> (even a desktop install is planned)
<livcd> ok so what do you think about a base host for docker and docker containers ? :D
<Chipaca> whither mvo?
<Chipaca> livcd: grab snappy ubuntu core, then "sudo snappy install docker"
<ogra_> pitti, is there an easy way to find that sysvinit scripts are in use via systemctl ?
<ogra_> s/that/which/
<pitti> ogra_: you mean that a unit was generated from a sysvinit script?
<ogra_> yep
<ogra_> (we just seeded ppp in the image and that doesnt ship any systemd stuff)
<pitti> $ systemctl show -p SourcePath networking.service
<pitti> SourcePath=/etc/init.d/networking
<pitti> something like that?
<ogra_> ah, perfect
<ogra_> event works with a wildcard :D
<pitti> ogra_: I assume this is for a script -- as a human, looking at systemctl status foo is a bit more obvious, and simpler to remember
<pitti> â networking.service - LSB: Raise network interfaces.
<pitti>    Loaded: loaded (/etc/init.d/networking)
<ogra_> pitti, well, i was not sure if snappy ships the sysvinit generator at all
<pitti> ogra_: oh, ambitious :)
<pitti> (but indeed that does sound achievable)
<ogra_> and pppd ships a /etc/init.d/pppd-dns script ... we need to be sure this still works (ppp doesnt seem to have any kind of native systemd integration)
<ogra_> ricmm, seems watchdog is completely configured via /etc/default/watchdog that should be easy
<ogra_> and its is already shipping proper systemd service files too ...
<ricmm> ogra_: perfecto
 * ogra_ guesses there is nothing to do for watchdog except adding writability for the confi
<ogra_> g
<Chipaca> ogra_: arch seems to have pppd systemd scripts :)
<Chipaca> ogra_: otoh, systemd was working on pppd support
<Chipaca> as part of networkd though
<ogra_> yeah, but thats for later
<ogra_> the sysvinit script it ships is a one liner:
<ogra_> [ -x /etc/ppp/ip-down.d/0000usepeerdns ] \
<ogra_>         && exec /etc/ppp/ip-down.d/0000usepeerdns
<Chipaca> ah. meh :)
<ogra_> also pretty debian/ubuntu specific too
<ogra_> i think we're fine shipping it as is for now ... just need /etc/ppp/ writable
<ogra_> (and if needed have snappy config modify/add/remove files in there)
<sergiusens> good morning from the americas!
<ogra_> yo yo!
 * ogra_ sees that ubuntu-snappy has finally built and triggers a new 15.04 image
<livcd> is there a generic image i can get ?
<livcd> i plan to use it with vbox
 * Chipaca shakes his fist at classes that use private globals for configuration you should change for testing use of the class
<Chipaca> livcd: yes, you probably want the amd64 15.04 stable image
<guest42315> livcd,  wget http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz ?
<Chipaca> livcd: https://developer.ubuntu.com/en/snappy/start/
<livcd> Chipaca: is that the one ?
<livcd> is not that the one for KVM ?
<Chipaca> livcd: the url guest42315 pointed at works with kvm, yes
<Chipaca> livcd: i assume vbox is virtualbox, in which case I understand it also can work with that image, but I haven't tested this myself
<livcd> oh i think i have to convert that one first
<livcd> i have seen on the page a "larger" multipurpose image for vmware,vbox,etc
<Chipaca> livcd: get the OVA file
<Chipaca> livcd: from the page i pointed you at
<Chipaca> livcd: probably the easiest way
<livcd> the ova file
<livcd> yeah that's the one
<livcd> ok
<livcd> though i wanted the smallest image possible :D
<yashi_> hello
<rickspencer3> jdstrand, I noticed that I am getting this error when I try to use certain pins on my bbb
<rickspencer3> Sep 08 13:25:36 localhost.localdomain ubuntu-core-launcher[1090]: open /sys/class/gpio/gpio44/direction: permission denied
<Chipaca> yashi_: hello
<yashi_> just tried to run ubuntu-device-flash under systemd-nspawn container and found out that oem handler runs `udevadmin control --reload` which is not possible under nspawn containers.  installOemHardwareUdevRules seems to assume that environment it's called is runtime env, but not a host with u-d-f
<Chipaca> rickspencer3: https://bugs.launchpad.net/snappy/+bug/1488618 ?
<ubottu> Launchpad bug 1488618 in Snappy trunk "cannot specify /sys/class/gpio/export with hw-assign" [Critical,Fix released]
<rickspencer3> I added this to my apparmor profile to try to hack around it, but it didn't work
<rickspencer3>   /sys/class/gpio/gpio44/direction rw,
<rickspencer3> Chipaca, well, that is another bug I found perviously
<rickspencer3> not sure if this is the same or related
<Chipaca> ah
<Chipaca> me neither :)
<rickspencer3> is there a way for me to tell my bbb to update to the latest daily image?
<ogra_> sudo snappy update ubuntu-core
<ogra_> shoudl work
<rickspencer3> arg, ogra_ maybe I didn't get onto rolling when I made the image :(
<ogra_> ah, thats the hacked channel image ?
<yashi_> it seems to me that what u-d-f want is to install udev rules but not activation.  does anyone know around this?
<rickspencer3> is says I am on version 4
<ogra_> yeah, that might not just work
<rickspencer3> aaarg
<ogra_> you can force it in the bootloader config to switch to the other partition
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ fw_printenv |grep ^snappy_ab
<ogra_> snappy_ab=a
<Chipaca> yashi_: sorry, what?
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo fw_setenv snappy_ab b
<ogra_> then reboot
<ogra_> ((unless your image is really really old ... in which case you dont have the right bootloader setup and actually need to re-flash)
<yashi_> Chipaca: have you run ubuntu-device-flash under systemd nspawn containers?
<Chipaca> yashi_: I have not. What for?
<yashi_> Chipaca: using a container for lightweight vm, nothing more.
 * ogra_ guesses the typical ubuntu user uses lxc instead of nspawn :)
<Chipaca> yashi_: and you run u-d-f _inside_ the container, and ... something about udev?
<yashi_> ogra_: oh
 * Chipaca isn't getting where udev comes into it
<ogra_> yeah, sounds weird
<ogra_> is that when you are executing it ?
<Chipaca> at first i thought you were trying to use the output of u-d-f inside an nspawn (which wouldn't work) :)
<yashi_> Chipaca: yeah, in short u-d-f does not work inside the container.  reason: no access to systemd-udevd
<ogra_> or do you refer to the u-d-f package shipping rules
<ogra_> ah
<jdstrand> rickspencer3: let me look at the bug again
<yashi_> but i thought u-d-f does not need to / should not access systemd-udevd via udevadm.
<jdstrand> sigh
<ogra_> well, it creates partitioned images ... i havent seen the source but it might talk to udevd to determine loop devices and whatnot
<ogra_> sergiusens, ^^^^ ?
<Chipaca> that's probably the oem setup?
<jdstrand> it is related but the fix isn't broad enough. unfortunately, I've never done gpio so not sure of all the paths. I am going to suggest going broader to cover this
<ogra_> Chipaca, yeah
<yashi_> ogra_: hmm.  I'l check about loop device
<yashi_> Chipaca: yes, it's activateOemHardwareUdevRules() in oem.go
<Chipaca> yup
<Chipaca> oh. lunch.
 * Chipaca ~> lunch
<jdstrand> mvo_: hey, I just filed bug #1493389 on rickspencer3's behalf. it is essentially the same bug as the one you fixed before but for a different path. In the bug, the fix I suggested should prevent this bug in the future for any path in /sys/class/gpio
<nothal> Bug #1493389: cannot specify /sys/class/gpio/*/direction with hw-assign <Snappy:New> <Snappy 15.04:New> <Snappy trunk:New> <http://launchpad.net/bugs/1493389>
<ubottu> bug 1493389 in Snappy trunk "cannot specify /sys/class/gpio/*/direction with hw-assign" [Critical,New] https://launchpad.net/bugs/1493389
<jdstrand> mvo_: I took the liberty of triaging it to match bug #1488618 (without assigning you)
<nothal> Bug #1488618: cannot specify /sys/class/gpio/export with hw-assign  <http://launchpad.net/bugs/1488618>
<ubottu> bug 1488618 in Snappy trunk "cannot specify /sys/class/gpio/export with hw-assign" [Critical,Fix released] https://launchpad.net/bugs/1488618
<sergiusens> yashi_, ogra_ what u-d-f are you using, the udev rules are not supposed to be triggered, just layed out
<ogra_> sergiusens, well, it seems to actually try to call udevd
<sergiusens> yashi_, that is inhibited from u-d-f (activateOemHardwareUdevRules)
<mvo_> thanks jdstrand
<yashi_> sergiusens: do you mean u-d-f shouldn't call activateOemHardwareUdevRules() ?
<sergiusens> yashi_, it shouldn't and I'm sure I added code for that
<sergiusens> yashi_, I'm checking now
<ogra_> yashi_, are you actually using the latest u-d-f from the snappy-tools PPA =
<ogra_> ?
<ogra_> just to make sure :)
<yashi_> sergiusens: i've checked the u-d-f from the snappy official ppa and bzr
<yashi_> ogra_: I noticed errro with the official binary so did `go get` and built u-d-f myself
<yashi_> ogra_: i'm not bzr guy so not sure which branch is the tip, but i've built the one in goget-ubuntu-touch revno 61
<yashi_> sergiusens: which branch should I checkout to see your change?
<Chipaca> yashi_: i suspect the change has gotten lost, as I don't see code in tip to not do the activate
<sergiusens> yashi_, I was looking at bzr logs to figure out where the change went
 * Chipaca hugs sergiusens 
<sergiusens> seems I did something similar, but not to this
<ogra_> and on a sidenote https://code.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk is trunk :)
<sergiusens> Chipaca, seems it's not there, we need to either split write and install or pass in inhibitHooks
<Chipaca> mhmm
 * Chipaca runs back to his own code
<yashi_> ogra_: thanks!
<sergiusens> Chipaca, no, please stay ;-)
<rickspencer3> jdstrand, I applied your work around, but I am still getting denied
<rickspencer3> maybe I need a different hw-assign?
<rickspencer3> Sep  8 14:14:58 localhost kernel: [   69.578787] audit: type=1400 audit(1441721698.017:10): apparmor="DENIED" operation="open" profile="ssh-ready.sideload_ssh-ready_0.1" name="/sys/devices/platform/ocp/4804c000.gpio/gpio/gpio44/direction" pid=1098 comm="ssh-ready" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
<jdstrand> rickspencer3: yes, you need an additional hardware assign
<rickspencer3> jdstrand, so, weird that it always works fine on pin 67 and 68
<jdstrand> rickspencer3: do remember that if you do hw-assign again, you'll have to re-add the workaround rule
<Chipaca> mvo_: ogra_: hadn't we fixed the thing where we create vmlinuz-$version and initrd-$version?
<Chipaca> because wily edge 166 still has it, right now
<ogra_> Chipaca, i think sergio did the u-d-f side to ssuport the versioned binaries ... and i think mvo_ recently added code that makes sure everything is removed from /boot
<sergiusens> Chipaca, the part missing is that system-image would need to generate the yaml
<mvo_> Chipaca: I have a branch for this up for review right now
<rickspencer3> jdstrand, ack
<ogra_> it might be that we still have unversioned duplicates in the oem snap
<Chipaca> mvo_: you have a lot of branches waiting on the integration test runner, it seems
<Chipaca> mvo_: is that thing working?
<mvo_> Chipaca: I think so, I tested it on some kernel change image iirc
<zyga> hey everyone
<zyga> tedg: I'd like to sync with your on python support
<Chipaca> mvo_: i meant the integration test runner thing
<tedg> zyga: Morning, I have a branch, but it needs to get updated with sergiusens' fixes.
<zyga> tedg: can I have a look?
<zyga> tedg: maybe your approach is easier to land than mine :)
<mvo_> Chipaca: it seems its not right now, we probably should ask fgimenez :)
<tedg> zyga: No, it is a secret. What ever you do, don't click on this link! https://code.launchpad.net/~ted/snapcraft/python-pip
<zyga> tedg: thanks
<fgimenez> mvo_, you mean this branch https://code.launchpad.net/~mvo/snappy/snappy-lp1476129-boot-ok/+merge/269224 right? we can keep the rc local failover test commented
<Chipaca> fgimenez: there are a number of branches that are waiting for the integration test +1
<Chipaca> fgimenez: is that working? because it's been a week for some of them
<Chipaca> fgimenez: so if you think it's working, you think wrong :)
<yashi_> sergiusens: gotta go, it's late here.  let me know if you need a tester for it,  i have some time tomorrow
<fgimenez> Chipaca, it's not enabled yet afaic, probably some of the jenkins instances kept requesting the review, while the jobs weren't triggered
<Chipaca> mvo_: top approve 'em all!
<Chipaca> go go go
<ogra_> shell shell shell
<sergiusens> yashi_, sure, just remind me tomorrow
<sergiusens> thanks
<mvo_> Chipaca: :) yay
<elopio> ogra_: how do I generate the init img from this initramfs-tools-ubuntu-core branch?
<Chipaca> elopio: first, you take a black rooster on a full moon
<mvo_> elopio: the initrd.img  ? find .|cpio -o -H newc|xz -c -9 --check=crc32
<mvo_> elopio: after you unpacked it to "." of course
<mvo_> elopio: and yes, full moon also helps ;)
<elopio> Chipaca: that's easy to get.
<ogra_> elopio, make a chroot ... install initramfs-tools and initramfs-tools-ubuntu-core in it ... chroot into it ... sudo update-initramfs -kfoo -c
<Chipaca> elopio: your neck of the woods, sure
<mvo_> oh, what ogra_ said works too to build it afresh, my suggestion works when modifying a existing one
<ogra_> right, you can as well unpack and re-pack
<ogra_> and replace the right bits
<elopio> fgimenez: do you have ssh access to that instance that failed on the free space test?
<fgimenez> elopio, yep, let me add your key
<fgimenez> elopio, the jenkins container is running at 10.55.32.36, you should be able to access now, sudo docker exec -ti snappy-jenkins bash to enter the container
<elopio> fgimenez: I meant to the snappy instance.
<elopio> sorry for not being clear.
<fgimenez> elopio, the instance itself where the tests run is deleted, but you can spin it up again with nova
<fgimenez> yep, np :)
<elopio> fgimenez: I have started a couple of instances and can't reproduce it.
<elopio> I think this will help, for sure: https://code.launchpad.net/~elopio/snappy/parted_script/+merge/270421
<elopio> but I'm not sure if it will fix your problem. Does it happen on all the runs from jenkins?
<fgimenez> elopio, these are the results http://10.55.32.36:8080/job/snappy-daily-1504-canonistack/, fails with each execution
<elopio> fgimenez: great, so let me try with this branch from a jenkins instance. Thanks.
<fgimenez> elopio, maybe it's because it's running against 15.04?
<fgimenez> let me try rolling too
<elopio> fgimenez: if ogra has not backported this, then the image doesn't have parted installed. Let me check.
<ogra_> elopio, right, not backported yet
<ogra_> i was waiting for test feedback first ...
<elopio> fgimenez: ^ so the test is rolling only.
<fgimenez> elopio, ogra_ ok thanks, now running it
<tedg> Uhg, this sucks. bug 1306991
<ubottu> bug 1306991 in python-pip (Ubuntu) "pip stops with ImportError for request-Modul" [Undecided,Confirmed] https://launchpad.net/bugs/1306991
<tedg> Finally found the issue, but not sure how to work around it.
<tedg> Frustrating, but ironic, to run into the issue that people have working with Ubuntu packages while trying to build Snappy
<sergiusens> tedg, maybe just easy_install pip and forget the ubuntu package?
<elopio> ogra_ or sergiusens: when do we need the dtbs? only for uboot?
<sergiusens> elopio, yes; for arm
<ogra_> elopio, what sergiusens said ... depneding on the device you need them earlier or later
<ogra_> (BBB only needs them in uboot, RPi already in the first stage loader)
<tedg> sergiusens: Yeah, working through that... directories become fun.
<mhall119> hi everyone, is there a way yet to use snapcraft on my (x86) laptop to build a package for (armhf) RPi2?
<mhall119> using a .deb from the archives
<beuno> mhall119, are you subscribed to snappy-app-devel?
<mhall119> probably not
<beuno> mhall119, if you do, and if you look at the latest thread
<beuno> you will get your answer!
 * beuno doesn't want to spoil the ending
<tedg> beuno: You're such a tease!
<tedg> Ha, I think it works.
<rickspencer3> jdstrand, does this mean I need to do hw-assign /sys/devices/ ?
<rickspencer3> Sep  8 20:03:12 localhost kernel: [19340.684890] audit: type=1400 audit(1441742592.719:445): apparmor="DENIED" operation="open" profile="pan-tilt-camera.sideload_pan-tilt-camera_0.1" name="/sys/devices/" pid=1852 comm="pan-tilt-camera" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<jdstrand> rickspencer3: that one is annoying. does the app not work correctly without that access?
<rickspencer3> jdstrand, well, it threw that error constantly in a loop
<rickspencer3> then, I granted the app access to /sys/devices
<rickspencer3> not more error, but the app is not working
<rickspencer3> also, I just burned out a servo by plugging it into the wrong pin
<jdstrand> right. if it wants /sys/devices/ it is perhaps looking for something
<jdstrand> ouchie
<rickspencer3> jdstrand, I think it is a pwd port
<rickspencer3> as in, I think the port support pwd
 * rickspencer3 notes to be more careful with servos
<rickspencer3> there's $3 I'll never see again
<jdstrand> hehe
<rickspencer3> jdstrand, so I am not seeing any denials or errors
<rickspencer3> it's just not working
<rickspencer3> and I have no idea where to start
<rickspencer3> nothing in pwm
<jdstrand> hrm
 * rickspencer3 goes to google
<jdstrand> I'm going to allow access to /sys/devices/ so you won't have to worry about that
<rickspencer3> h man, I plugged it into the totally wrong pin
<rickspencer3> criminy
<rickspencer3> ogra_, anything I need to know before using pwm on my bbb?
<rickspencer3> for example, "how to make it work" ;)
<sergiusens> tedg, can you peek at https://code.launchpad.net/~sergiusens/snapcraft/filesets/+merge/270455 (work in progress) and get some initial thoughts in? I'd also appreciate if you can look at all the prereqs to this which are under actual review :-)
<tedg> sergiusens: Not a fan of "!include"
<sergiusens> tedg, well, that is part of the spec ;-)
<tedg> sergiusens: Means that you have two "languages" in the same file. YAML and a string lang.
 * sergiusens wasn't there
<tedg> Eh :-/
<sergiusens> tedg, also, ! means something in yaml so you have to explicitly cast the string with quotes :-/
<tedg> Nice.
<tedg> What does "!" mean in YAML?
<sergiusens> tedg, ready for the irony...?
<sergiusens> tedg, it is some form of 'include'
<sergiusens> :-P
<tedg> Oh, an it seems !! allows for typing.
<sergiusens> tedg, I'll be writing an email about this
<tedg> Wow, YAML is kinda crazy on this.
 * tedg had no idea
<tedg> sergiusens: Not sure I have useful comments... it matches the spec :-) The spec is a bit odd in this case.
<tedg> It feels like we're real close to needing regular expressions.
<tedg> Which I don't think is a good place to be.
<sergiusens> tedg, ;-) well you can review the prereqs I guess :-P
<tedg> We effectively have sets of globs which use to generate sets of files.
<tedg> I can't figure out a way to resolve it, but it feel yucky.
<tedg> sergiusens: Didn't we have something autobuilding the MRs?
 * tedg doesn't see a comment
<sergiusens> tedg, after approval iirc
<sergiusens> elopio, ^ ?
<tedg> sergiusens: Why can't tabs be in a snapcraft.yaml?
<tedg> sergiusens: It seems like valid YAML.
<sergiusens> tedg, It is not; tabs can't start a line like that
<sergiusens> tedg, http://www.yaml.org/faq.html
<sergiusens> tedg, it made it to the two question faq :-P
<tedg> sergiusens: Hmm, I think that Juju allows them atleast, I'm sure I've used them :-)
<tedg> sergiusens: Interestingly they can be used for spacing values but not indentation.
<sergiusens> tedg, the golang based parser doesn't care; snappy doesn't care either
<sergiusens> tedg, it is just not following the spec, that's all
<sergiusens> tedg, I would rather ont patch python3-yaml to not follow the spec :-P
<sergiusens> seems to be the wrong direction :-)
<tedg> sergiusens: You could patch the YAML spec ;-)
 * tedg wants to move things the right direction
 * sergiusens would make all code just use tabs
 * sergiusens walks away for a bit
<tedg> I like tabs for YAML files because you can just set your tabstop to 10 and see what the indentation really is.
<tedg> I'm going to have to go soon.
#snappy 2015-09-09
<fgimenez> good morning
<dholbach> good morning
<JamesTait> Good morning all; happy Wonderful Weirdos Day! ð
<fgimenez> hi Chipaca, can you please take a look at https://code.launchpad.net/~fgimenez/snappy/comment-rc-local-crash-test/+merge/270485 ?
 * Chipaca looks
<Chipaca> fgimenez: ouch
<fgimenez> Chipaca, yep :) commenting it again should be enough by now
<fgimenez> Chipaca, thx, trying elopio's serve_daemon_test now
<Chipaca> wily edge update just jammed with â[    7.021077] FAT-fs (sda2): IO charset iso8859-1 not foundâ
<Chipaca> (dunno if that's what jammed it, but that's the last thing on console)
<ogra_> ppisati, ^^^^ i thought we compile that in nowadays ?
<ppisati> Chipaca: BBB?
<Chipaca> ppisati: kvm
<Chipaca> amd64
<ppisati> and why the kernel can't load the module?
<ppisati> Chipaca: ^
<Chipaca> ppisati: how would i know? :)
<Chipaca> it might be a download problem though
<Chipaca> as now it seems to be working, modulo the space problem
<Chipaca> which is strange -- it should notice the download failed and not try to run with it
<ppisati> Chipaca: ls -la /lib/modules/`uname -r` - you get something, right?
<mvo_> Chipaca: reviewing your branch right now and just noticed the backlog, is this a fresh image or a upgrade?
<Chipaca> ppisati: I got the error twice in a row (that is: booted an image from yesterday with -snapshot, sudo snappy update succeeded, got the error above on reboot), but now i'm getting a different error
<Chipaca> ppisati: i'll answer your question in a moment though
<Chipaca> mvo_: upgrade
<mvo_> Chipaca: anything unusual in the upgrade, i.e. out-of-space on boot or something like this
 * ppisati -> out for lunch, biab
<Chipaca> nope
<Chipaca> well
<mvo_> Chipaca: hrm, thats alarming
<mvo_> Chipaca: what is the new error you get?
<Chipaca> right now I *do* get the out-of-space error
<Chipaca> because it's still creating the versioned boot files
<Chipaca> however it didn't happen when i then went on to get the other
<Chipaca> hence why i suspect it's a download problem (or perhaps something else, but resulting in an empty or smaller initrd)
<ogra_> currently the module (if it isnt compiled in) should live in the initrd
<Chipaca> does that make sense?
<ogra_> so you should get it loaded in any case ... unless your initrd didnt get loaded
<Chipaca> now rebooting after doing the upgrade dance (which involves cleaning up /boot/b before upgrade, and then moving the versioned boot files to their unversioned place)
<ogra_> do you have a full boot log/dmesg output ?
<Chipaca> and it booted fine
<Chipaca> from when it failed?
<Chipaca> as it happens, i do
<ogra_> i guess it loaded the wrong initrd or no initrd at all
<mvo_> Chipaca: hm, I think it just failed to load the right inird.img, i.e. syncbootfiles copied the old one and the new (and correct) one was not renamed by the upgrade. I though I pushed a branch with a fix for this a while ago
<Chipaca> ogra_: mvo_: http://pastebin.ubuntu.com/12320079/
<mvo_> it will be a glorious day when we get rid of syncbootfiles
<mvo_> hopefuly soon
<ogra_> hmm, it definitely loads an initrd there
<ogra_> doesnt seem corupt either
<mvo_> it could just be the old one
<ogra_> Chipaca, so i guess it simply loaded the wrong initrd ...
<ogra_> did it properly reboot after the error ?
<Chipaca> no, stuck there
<ogra_> that should definitely not happen indeed
<ogra_> i guess we'd need to teach systemd to panic in such a moment
<Chipaca> "systemd now eats kernel panic generator"
<ogra_> heh
<ogra_> hmm
<ogra_> [    0.000000] Command line: BOOT_IMAGE=(hd0,gpt2)/EFI/ubuntu/grub/a/vmlinuz root=LABEL=system-a ro init=/lib/systemd/systemd console=ttyS0 console=tty1 panic=-1
<ogra_> [    0.000000] KERNEL supported cpus:
<ogra_> shouldnt there be an initrd on the line as well
<Chipaca> ogra_: apparently not
<ogra_> grub.cfg doesnt set it by default ?
<Chipaca> it does have an initrd stanza
<Chipaca> but the cmdline doesn't mention it -- even on a successfully booted image
<ogra_> ok
<ogra_> well, it finds one ... so we're fine ... as long as it is the right one
<ogra_> in any case the system shouldnt hang in such situations but reboot back into the other partition
<Chipaca> mvo_: replied to your comments
<mvo_> Chipaca: heh, looks like we should include the link to gustavos blog post as a comment when tomb is included :)
<mvo_> Chipaca: thanks for the reply! lets wait with the top-approve until the dependencies are there, I will have a look after lunch
<Chipaca> mvo_: mucho thank you
<Chipaca> mvo_: wrt tomb, the blogpost is referenced from the package documentation which is in the standard place :)
<mvo_> Chipaca: uh, ok. lalalala
<Chipaca> added a nice long comment to the api checker test
<ogra_> hmm
<ogra_> do we have the ability to have a snap ship services and not start them by default ? (thinking of a snap that will come with default config we not necessarily want to run before it is configured)
<ogra_> (beyond hacking something in via snappy config)
<ogra_> mvo_, is there a reason that the wily versions of packages are uploaded in parallel in the image build PPA ?
<ogra_> (vs just using the archive)
<mvo_> ogra_: the turnaround time of the ppa is better than the archive, thats the only reason
<ogra_> ah, k
<ogra_> no general policy or some such
<mvo_> no, just me being impatient
<sergiusens> mvo_, did you do a release of snappy into wily?
 * sergiusens wants to rebuild u-d-f with it
<mvo_> sergiusens: not yet, can do so in a bit
<sergiusens> mvo_, sounds good
<mvo_> sergiusens: uploaded
<Chipaca> tests pass \o/
<Chipaca> ~> lunch
<ogra_> grmbl ... the out of space thing is really annoying
 * ogra_ spent the last 30min trying to update his rolling image 
 * ogra_ sees a plano-amd64 package announced by the store to G+
<Chipaca> ogra_: it's easy to update rolling!
<Chipaca> ogra_: first, determine whether the next one will be a or b
<ogra_> Chipaca, until it tells you there is no space for the kernel/initrd :P
<Chipaca> ogra_: then, rm a-or-b/initrd.img* a-or-b/vmlinuz*
<Chipaca> ogra_: then, update
<Chipaca> ogra_: then, mv initrd and vmlinuz to be versionless
<Chipaca> ogra_: easy peasy
<ogra_> yeah, i mv'ed them to the generic ones
<ogra_> this time :P
<ogra_> but it took a few attempts
<ogra_> (and it is super annoying that it downloads the rootfs every time )
<ogra_> (we might have devices that only use GSM for networking ... might take them a week to download :P )
<ogra_> heh
 * ogra_ notes that rickspencer3 found out that devicetree sucks 
<rickspencer3> omg
<rickspencer3> please, someone, fix this for me!
 * Chipaca hides
<ogra_> i doubt it is fixable
<ogra_> it is the alternative to compile your own kernel for each and every use-case
<mvo_> ogra_: the fix went in yesterday it seems, so sorry, hopefully the last time
<ogra_> mvo_, yeah
<sergiusens> rickspencer3, just noticed I replied privately
<rickspencer3> sergiusens, I assumed that was so you didn't embarrass my because my question was so silly
<rickspencer3> :)
<Chipaca> the last time i answered that kind of plea from rick i spent three months crunching numbers for academia
<ogra_> rickspencer3, its not silly, but likely not solvable easily
<sergiusens> rickspencer3, nah, I haven't installed a proper email client yet :-P
<rickspencer3> really? we can't just make a custom overlay to include by default in the image?
<mvo_> sergiusens: mutt is small
<ogra_> rickspencer3, we could, but then people would have to remove it before loading theirs
<ogra_> the usage of the setup is usually mutually exclusive
<rickspencer3> that doesn't seem too bad
<rickspencer3> right
<rickspencer3> maybe we could have one image set up nicely for hackers
<ogra_> and typically on a BBB you dont have any cape config by default for a generic image
<rickspencer3> and then you take a different image if you want to do an overlay
<rickspencer3> maybe we make an image that is on rolling and has the pins laid out for hacking
<ogra_> i'm also not sure how far we are with capemgr support in our kernel
<ogra_> ppisati, ?
<rickspencer3> well, not being able use pwm is a killer for a lot of applications
<rickspencer3> I have a multi-colored led, for example
<ogra_> rickspencer3, you need to create your own oem snap anyway if you use any cap currently
<rickspencer3> not to mention the servo
<ogra_> *cape
<rickspencer3> ogra_, well, these aren't capes, these are jumper cables and pieces
<rickspencer3> on a breadboard
<ogra_> they use the cape interface
<rickspencer3> right
<rickspencer3> so, maybe we make a "breadboard" image, that is set up like I said?
<rickspencer3> a list of digital pins, a list of pwms, etc...
<ogra_> well, your setup for the breadboard might completely differ from my setup ...
<ogra_> while you use a servo and emit the right voltage/current, i might want to run a relais on the very same pin
<sergiusens> right, pinouts can be completely different
<ogra_> with a totally different voltage and curremt
<rickspencer3> so?
<rickspencer3> there are like 60 pins
<rickspencer3> certainly there is a more sensible default than "nothing works"
<ogra_> you would potentially blow up my HW with your cape setup
<ogra_> this is like serial ports ...
<rickspencer3> I find it strange that every other board seems to have a sensible set of default pins where I can use my gizmos
<rickspencer3> but it's not possible on bbb?
<rickspencer3> that doesn't ring true
<sergiusens> ogra_, we could arguably create an alterante oem snap configured with a pinout that has a couple of everything
<ogra_> while you coould make it default to be a mouse port ... there might be 3D controllers for $$$$$$$ that blow up completely if you attach it to such a port
<rickspencer3> right
<ogra_> so setting a default for that pinout can be very dangerous
<rickspencer3> but, I am just talking about saying that hackers can use their breadboards without having to do this complicated overlay stuff
<rickspencer3> ogra_, again, that sounds specious
<ogra_> but they cant
<ogra_> they could only use exactly your setup
<ogra_> not theirs
<rickspencer3> right
<rickspencer3> but that set up for most people hacking with breadboards would be fine, right?
<rickspencer3> what do they need?
<rickspencer3> some digital pins
<rickspencer3> some pwms
<ogra_> especially for a breadboard that seems suboptimal
<Chipaca> mvo_: E: golang-snappy-dev: arch-independent-package-contains-binary-or-object usr/bin/xgettext-go
<rickspencer3> some analog ins
<ogra_> since a breadboard is 100% freely usable/configurable
<rickspencer3> sure, but most people just need a few pins to work
<rickspencer3> if the hacker knew which 10 digitial pins will work, which 4 pwms will work, etc...
<rickspencer3> then they could do most stuff
<ogra_> right, they would need an overlay then ... and we should make it easier to use them, no doubt
<ogra_> but we shouldnt ship a default overlay that potentially blows up stuff
<mvo_> Chipaca: oh, that needs fixing, we should probably simply not install that at all, I wonder why its in the package
<mvo_> Chipaca: I can do a seperate branch for this
<ricmm> this is my original spec for kernel and gadget snap
<rickspencer3> ricmm, do you think what I am proposing is going to blow stuff up?
<ogra_> ricmm, right, is anything left from that ?
<ricmm> ogra_: ashes
<rickspencer3> It just seems simple that we make an image that "works"
<ricmm> rickspencer3: if there is pin multiplexing involved, we cant have generic usage of pins
<Chipaca> mvo_: k :)
<ricmm> something will get fried, a garage door might crush a kid, someone might get sued
<Chipaca> mvo_: anyway, top-approvernated
<ricmm> Chipaca: you mean happrovernated
<ricmm> miissing an h
<rickspencer3> ricmm, then how come other boards have that?
<rickspencer3> for example, on Arduino, the pins are the pins
<rickspencer3> I plug stuff into the right pins, and good to go
<ricmm> rickspencer3: that is because on arduino there is no pin multiplexing for other physical wire protocols
<ricmm> they are all 5V TTL GPIO
<ricmm> sergiusens: mvo_ ogra_ call time
<mvo_> ricmm: I'm in the hangout
<sergiusens> ricmm, what a pain :-P
<rickspencer3> hmmm, it still seems to me that we could roll and image that "works" and document what the pins are
<ogra_> rickspencer3, oops
<ogra_> err
<ogra_> ricmm,
 * ogra_ moves to office, sorry 
<yashi_> hmm..., when an amd64 snappy image created with u-d-f does not boot with qemu, where should I look?
<Guest30312> uh new toy https://uappexplorer.com/app/plano-amd64.canonical
<Chipaca> Guest30312: you forgot to set your nick :)
<Guest30312> Chipaca, this is my nick :))
<ogra_> yashi_, how does it not boot ?
<ogra_> (errors etc ? )
<o> oOoOOo
<yashi_> ogra_: no errors, cpu temp up, no output.  I must have done something wrong.
<yashi_> ogra_: it should work with qemu, right?
<ogra_> well, it definitely works with kvm here
<yashi_> something like: qemu-system-x86_64 -enable-kvm -m 512 my.img
<ogra_> kvm -m 512 -redir :8022::22 my.img
<ogra_> thats what i use
<yashi_> ogra_: yeah, that's a wrapper provided by qemu-kvm; just oneliner to wrap qemu-system...
<yashi_> in fact, the official image of amd64 I downloaded from ubuntu is working fine
<yashi_> I just can't re-create it here on wily
<Chipaca> mvo_: seems we need to throw some packages at tarmac
<mvo_> Chipaca: yeah, elopio or fgimenez can probably help, I have the info how to access tarmac somewhere too but already forgot where :/
<fgimenez> mvo_, Chipaca np, the ip is in the trello board https://trello.com/c/nFPZb4AL/192-automated-testing-and-continuous-integration
<fgimenez> you should be able to ssh, let me know if not
<mvo_> fgimenez: neat
<ogra_> mvo_, so my rolling image finally upgraded ... i see watchdog installed but i dont see any systemd units created for it
<ogra_> (there is a sysvinit script)
<ogra_> pitti, do i need to do anything spethial to trigger the generator ?
<pitti> ogra_: generators are called at boot and with systemctl daemon-reload
<ogra_> hmm, calling systemctl daemon-reload ... and then systemctl|grep watch doesnt return anything
<ogra_> same goes for the ppp-dns sysvinit script
<ogra_> would it be named the same in systemctl ? (or at least contain the old sysvinit name ?)
 * ogra_ is a bit lost here 
<ogra_> pitti, would the generator  print anything in syslog ?
<pitti> systemctl | grep watch? you mean "sudo journalctl -f" perhaps?
<pitti> ogra_: most generators don't, unless you enable debugging
<pitti> systemd-analyze set-log-level debug
<ogra_> no, i mean systemctl |grep watch ... to find athe unit for watchdog
<ogra_> ok,, that prints more into syslog ... still no trace of watchdog though
<ogra_> Sep  9 14:17:10 localhost systemd[1]: Looking for SysV init scripts in:
<ogra_> Sep  9 14:17:10 localhost systemd[1]: #011/etc/init.d
<ogra_> nothing else
<ogra_> i see /etc/rc2.d/S03watchdog when looking in the dirs
 * ogra_ sighs
<ogra_> does the sysvinit job need a special format or something to be picked up ?
<pitti> ogra_: sorry, no context -- what do you actually try to do? you have your own generator, or look at the sysv one?
<ogra_> pitti, i added a new package to the readonly rootfs ... it has a sysvinit job
<pitti> ogra_: not really, just an LSB header; if you want you can run the gnerator manually (even as user), to see what it does
<ogra_> namely the watchdog package
<ogra_> as i understand systemd should generate a unit for it on first boot ... but it doesnt seem to
<pitti> mkdir /tmp/x; SYSTEMD_LOG_LEVEL=debug /lib/systemd/system-generators/systemd-sysv-generator /tmp/x /tmp/x /tmp/x
<pitti> ogra_: right, as long as it's enabled and has some working LSB header it should work
<ogra_> Ignoring S03watchdog symlink in rc2.d, not generating watchdog.service.
<ogra_> aha
<ogra_> oh
<pitti> ogra_: is there maybe already a watchdog.service?
<ogra_> Native unit for watchdog.service already exists, skipping
<ogra_> Native unit for pppd-dns.service already exists, skipping
<pitti> :)
<ogra_> so why doesnt systemctl list it then ?
<pitti> perhaps it's not running? it should be in "systemctl --all" at least, is it not?
<pitti> or systemctl status watchdog
<ogra_> (amd64)ubuntu@localhost:~$ sudo systemctl start watchdog
<ogra_> (amd64)ubuntu@localhost:~$ ps ax|grep watchdog
<ogra_> ...
<ogra_>  1001 ?        SLs    0:00 /usr/sbin/watchdog
<ogra_> ...
<ogra_> all good it seems
<ogra_> after i start it manually
<ogra_> pitti, thanks !
<pitti> ogra_: ok, so what whas the root of the confusion here? the already existing native job?
<ogra_> no, that i missed --all apparently :P
<pitti> ah, ok
<ogra_> systemctl --all |grep watchdog lists it just fine
<ogra_> hmm
<ogra_> watchdog doesnt start automatically though ... even though it is enabled in /etc/default/watchdog
<ogra_> Sep 09 14:37:01 localhost.localdomain systemd[1]: [/lib/systemd/system/watchdog.service:10] Unbalanced quoting in command line, ignoring: "/bin/sh -c '[ -z "${watchdog_module}" ] || [ "${watchdog_module}" = "none" ] || /sbin/modprobe $watchdog_module"
<ogra_> hmm
<ogra_> yeah, /lib/systemd/system/watchdog.service has cleraly messed up qquoting
<ogra_> http://paste.ubuntu.com/12321213/
<ogra_> now it would be good to know where systemd gets that line from
<ogra_> it is definitely not just copying it from the sysvinit script
<ogra_> pitti, that smells a bit like a bug in the generator
<ogra_> the sysvinit script has : [ "${watchdog_module:-none}" != "none" ] && /sbin/modprobe $watchdog_module
<ogra_> the generate seems to turn that into:
<ogra_> ExecStartPre=/bin/sh -c '[ -z "${watchdog_module}" ] || [ "${watchdog_module}" = "none" ] || /sbin/modprobe $watchdog_module
<sergiusens> mvo_, https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/modprobe/+merge/270545
<Chipaca> mvo_: what ubuntu is tarmac running in? :-/
<ogra_> (note the missing single quote ...)
<sergiusens> Chipaca, a cloud one; but fgimenez is the right person to ask ;-)
<Chipaca> fgimenez: ^
<Chipaca> because it's got a go that doesn't have os.Unsetenv
<Chipaca> um
<Chipaca> mvo_: and that's the main difference between stgraber's activation and the coreos one, i guess
<ogra_> ricmm, so with the above watchdog will never auto-start ... i can run it manually though, do you think thats ok for now ?
<stgraber> Chipaca: right, the only difference is mine works with Go 1.3
<Chipaca> stgraber: and that's what's in 15.04, right?
<Chipaca> stgraber: we're so far mostly building from golang-*-dev instead of vendoring
<stgraber> Chipaca: correct
<Chipaca> anyway. big sigh. :)
<Chipaca> mvo_: so we need to switch back to stgraber's, or ship go 1.5 to 15.04
<stgraber> Chipaca: we briefly tried using golang-*-dev, then noticed that to be able to build we'd have to update a whole bunch of them which would break docker as it was requiring an older version of some of them... I don't see this model working until the Go community learns to version their APIs and that seems difficult for those guys :(
<ricmm> ogra_: that is ok
<ogra_> ok ... still, there is a bug somewhere indeed
<ricmm> ogra_: if its not autostarting, we can just ask them to use a config file
<stgraber> Chipaca: if you've got a packaged version of upstream go-systemd, you can also just cherry-pick my change on top of that, it's tiny.
<Chipaca> stgraber: a large chunk of github seems to ignore the idea of versioning entirely
<ogra_> seems the generator tries to be clever with shell script ... and isnt
<fgimenez> Chipaca, sergiusens i think elopio set up tarmac, he can confirm
<Chipaca> fgimenez: 's ok, 15.04 is already too old for what my question was
<stgraber> oh, also, since we're talking Go and snappy. I seem to remember seeing you guys using go-gettext too. How are you extracting your strings?
<stgraber> there isn't a go xgettext filter that I know of, I believe for LXD we're using the c++ one but it's not picking up some multi-line strings which makes it less than ideal
<Chipaca> stgraber: ooooh!
<Chipaca> stgraber: we wrote our own xgettext
<Chipaca> stgraber: mvo_ did in fact
<Chipaca> mvo_: see? we should totally package that binary :)
<stgraber> any pointer to that xgettext? We totally need it!
<mvo_> Chipaca: uh, hrrrm
<Chipaca> stgraber: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/files/head:/i18n/xgettext-go/
<stgraber> nice!
<mvo_> Chipaca: I send a pull-request to the upstream go-gettext guys
<mvo_> Chipaca: I had hoped it would be adopted there
<mvo_> stgraber: happy to package it on its own if its useful for you
<Chipaca> mvo_: any response?
<mvo_> I will ping upstream again
<mvo_> no :(
<mvo_> not even a "we hate you"
<mvo_> (or your code, but isn't that the same ;)
<ogra_> pitti, do you want a bug for the above ?
<stgraber> mvo_: that'd probably be useful at some point, until then I can change our makefile to just go get it from your branch
<Chipaca> oh man, sometimes it's hard to remember that no, it isn't the same :)
<mvo_> Chipaca: what are you talking about, it's not the same ?!?!?!
<pitti> ogra_: re
<ogra_> ah, you were out
<pitti> ogra_: please, with the original sysvinit script to reproduce
<pitti> ogra_: yeah, mowing the lawn
<ogra_> yep, will add that .... and the unit it generated
<ogra_> hah, i got that ahead too today :)
<pitti> ogra_: if it's not just a copy&paste error when someone created /lib/systemd/system/watchdog.service :)
<ogra_> "brothers in mow"
 * pitti ^5s ogra_
 * ogra_ ^5s back
<ogra_> pitti, i didnt touch it ... all automatic
<ogra_> but i re-ran the generator manually when digging
<ogra_> (as you know)
<pitti> ogra_: right, but that didn't rewrite it because it was already there in /lib
<ogra_> yeah
<davmor2> ogra_: is this how you ^5 backs? https://xrixterweb.wordpress.com/2013/04/07/ncis-the-agent-gibbs-slapgif-images/
<pitti> davmor2: oh gawd, you read too much internet! :-)
<davmor2> pitti: :)
<davmor2> pitti: also only the bits you can make fun :)
<pitti> oh crap, missed the 17:00 confcall for Anand's  presentation
<pitti> will that be recorded?
<Chipaca> ogra_: http://www.jann.cc/2013/02/02/linux_watchdog.html has things form a guy using a hardware watchdog under systemd
<zyga> Chipaca, ogra_: what are your plans for the watchdog?
<davmor2> pitti: 17:00 your time or UTC
<pitti> davmor2: mine
<pitti> i. e. 1500 UTC
<davmor2> pitti: nevermind then :)
<ogra_> zyga, no plans
<ogra_> we need to include it and it needs to work ... thats all
<rickspencer3> hey, is pwm supported by snappy on raspberry pi 2?
<elopio> Chipaca: still having problems with tarmac?
<ogra_> rickspencer3, perhaps not /me cant tell ... i2c was the main focus fro 15.04.2
<rickspencer3> ug
<rickspencer3> no servos for Rick
<ogra_> did you try ?
<ogra_> perhaps it works
<ogra_> there was just no specific focus to that ... main focus was making dtb overlays loadable at all and i2c
<davmor2> rickspencer3: not after the moon on a stick again are you ;)
<rickspencer3> ogra_, I did try, yes
<Chipaca> elopio: my problems are not with tarmac :)
<rickspencer3> and I got this ... panic: gpio: pwm not supported on this host
<rickspencer3> at least I got a normal GPIO pin to work ;)
<ogra_> rickspencer3, might be thats missing in the kernel then
<ogra_> ask ppisati
<rickspencer3> ppisati, can I do pwm on rpi2?
<rickspencer3> with snappy, of course ;)
<ogra_> i dont see any special option in config.txt that would switch it on/off
<fgimenez> elopio, i've added the card about splitting the common package
<ogra_> only some tuning option
<ppisati> rickspencer3: what did you do to get a "panic: gpio: pwm not supported on this host"?
<rickspencer3> ppisati, I run code from the embd library
<rickspencer3> also, I note that there is no "pwm" under /sys/class
<rickspencer3> so I can't do it manually
<ogra_> ppisati, http://lwn.net/Articles/596188/
<ogra_> seems thats the driver
<ppisati> rickspencer3: oh, it's the app then
<fgimenez> elopio, i've added another about writing godoc comments for generating the integration tests documentation, what do you thing about that?
<rickspencer3> ppisati, right, it's not kernel panic, if that's what you mean
<rickspencer3> it's a Go panic
<ppisati> rickspencer3: everytime i see the word "panic" i attach it to the kernel
<rickspencer3> ppisati, here is the code
<ogra_> and i dont see /sys/class/rpi-pwm on my 15.04.2 install
<rickspencer3> https://github.com/kidoman/embd/blob/master/samples/servo.go
<ogra_> which should be the respective sysfs node
<ppisati> right
<ppisati> PWM is off in 3.19, i just checkd the config
<elopio> fgimenez: thanks. I think it will be nice. I tend to hate docs, but will give this a try, is probably worth it :)
<ppisati> i'll fix it and push a new kernel
<ogra_> ppisati, thanks
<ogra_> rickspencer3, so 15.04.3 will have it :)
 * ppisati goes to pick up the car from the garage
<fgimenez> elopio, ok, leaving, see you tomorrow
<fgimenez> nice evening everyone o/
<Chipaca> ok, off to a parents' evening. Will bb(m)l.
<sergiusens> mvo_, here's another one https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/modprobe-orig-files/+merge/270579
<sergiusens> :-)
<stgraber> mvo_: hey, what am I doing wrong? http://paste.ubuntu.com/12322788/
<stgraber> mvo_: seems to fail on a particular file for some reason
<elopio> sergiusens: where do I get this?
<elopio> pkg-checkbuilddeps: Unmet build dependencies: golang-uboot-go-dev
<stgraber> mvo_: nevermind, it's our existing multi-line trick which fails, I'll just fix all of those to use the proper multi-line syntax instead
<mvo_> stgraber: if you could mail me the failing file I will inspect and fix tomorrow morning
<mvo_> sergiusens: I look at your two branches now
<stgraber> mvo_: the syntax which fails is string concatenation, e.g.:
<stgraber> gettext.Gettext("abc\n" +
<stgraber> "def\n")
<stgraber> which was our workaround to get the c++ xgettext parser to extract most of our strings
<stgraber> mvo_: also, your parser does extract all the strings, yay! but the produced gettext template looks odd, as in, I get literal \n in there rather than proper line breaks, is that expected?
<mvo_> stgraber: sort of, I was relying on LP to make it look nice, but thats certainly something I can fix too
<mvo_> stgraber: I will make a not about it (plus a note about the string concat) and look into fixing it tomorrow morning
<mvo_> sergiusens: https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/modprobe-orig-files/+merge/270579 I thought transitional would do a "merge" of original and writable path, am I misrembering this?
<stgraber> mvo_: awesome, thanks so much for that tool, it's going to make our use of getext useful at last!
<mvo_> stgraber: yay, happy to hear that
<sergiusens> mvo_, it does, but for that to work I need to write the modprobe.d file directly to system-a (instead of writable)
<mvo_> sergiusens: oh, ok
<sergiusens> mvo_, IOW, if the dir on writable exists, the transition is considered done
<mvo_> sergiusens: makes sense
<sergiusens> mvo_, I forgot about that too :-/
<sergiusens> mvo_, in any case we may not want to do this at all in the future
<stgraber> mvo_: another small bug, if a string contains a ", your tool doesn't escape it
<stgraber> mvo_: that leads to an invalid pot file
<mvo_> stgraber: thanks
<mvo_> that one at least is easy
<mvo_> :)
<stgraber> :)
<mvo_> stgraber: lp:~mvo/snappy/snappy-gettext-fixes should contain the fixes, please let me know by mail if you notice any regression(s)
#snappy 2015-09-10
<mvo> ogra_, ricmm: do you think we can remove the /etc/ppp example files? they make the snappy config ubuntu-core output pretty ugly
<fgimenez> good morning
<ogra_> mvo, sure, whatever suits :)
 * ogra_ likes sentences with the word "remove" if they refer to the image ;)
<ppisati> ogra_: i finally cracked pwm support on the rpi2
<ppisati> ogra_: it requires a new kernel with some config changes and a little atch
<ppisati> ogra_: and the pwm overlay must be loaded from config.txt
<ogra_> cool
<ppisati> http://pastebin.ubuntu.com/12327126/
<ogra_> 15.04.3 release should be around end of the month i think
<ppisati> ogra_: do you have your rpi2 with snappy installed?
<ogra_> indeed
<ppisati> ogra_: i'm using the newer linux-firmware here (i'm juggling betweeb 3.19 and 4.2)
<ppisati> ogra_: sudo cat /proc/device-tree/soc/pwm@7e20c000/compatible
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo cat /proc/device-tree/soc/pwm@7e20c000/compatible
<ogra_> cat: /proc/device-tree/soc/pwm@7e20c000/compatible: No such file or directory
<ogra_> only i2c, spi, gpio and leds
<ogra_> no pwm by default
<ppisati> ogra_: find /proc/device-tree/ | grep pwm
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ find /proc/device-tree/ | grep pwm
<ogra_> (RaspberryPi2)ubuntu@localhost:~$
<ppisati> ogra_: ok so, the device-tree there din't have the bindings for the pwm
<ppisati> ogra_: in vivid we need to update that too
<ogra_> well, thats the default dt
<ogra_> no overlays
<ppisati> ogra_: the pwm overlay just turn it on
<ppisati> ogra_: the pwm node must be there already
<ogra_> nope
<ppisati> ogra_: https://github.com/raspberrypi/linux/blob/rpi-4.1.y/arch/arm/boot/dts/overlays/pwm-overlay.dts
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ find /lib/modules/ | grep pwm
<ogra_> (RaspberryPi2)ubuntu@localhost:~$
<ogra_> there is no pwm support at all, so how would that work
<ppisati> ogra_: right
<ppisati> ogra_: but what i'm saying is that, evern with a kernel with the correct config
<ppisati> ogra_: the driver doesn't know where to attach
<JamesTait> Good morning all; happy Thursday, and happy Swap Ideas Day! ð
<ppisati> ogra_: because the DT doesn't export the hw
<ogra_> indeed, thats why you need to enable the overlay
<ogra_> and thats good
<ppisati> ogra_: but overlay support is already on
<ppisati> ogra_: and the pwm overlay, it just flips a value
<ogra_> we dont want pwm on while someone has plugged somethin into it that requires the pins configured completely different
<ppisati> ogra_: right
<ogra_> worst case that could blow up something
<ogra_> so changing config.txt for now is fine
<ppisati> ogra_: and indeed what the overlat does, is to just flip it from off to on
<ogra_> yeah
<ppisati> ogra_: yeah, but the DT has to have the node there
<ppisati> ogra_: let me show my DT without the pwm overlay
<ogra_> right, does that work with the bootloader ?
<ogra_> switching to our own dtb there i mean
<ppisati> ubuntu@raspy2:~$ grep pwm /mnt/config.txt
<ppisati> #dtoverlay=pwm-overlay
<ppisati> ubuntu@raspy2:~$ sudo cat /proc/device-tree/soc/pwm@7e20c000/compatible
<ppisati> brcm,bcm2835-pwmubuntu@raspy2:~$ sudo cat /proc/device-tree/soc/pwm@7e20c000/status
<ppisati> disabledubuntu@raspy2:~$
<ppisati> with no overlat loaded
<ppisati> but the node is already there
<ppisati> ogra_: the one provided with the kernel? don't know, i would just switch to the latest https://github.com/raspberrypi/firmware
<ogra_> yes, because your kernel config has it
<ppisati> let me try that
<ogra_> right, thats what i'll do with 15.04.3
<livcd> i have downloaded ova and imported it to vbox on mac but the whole thing gets stuck on booting somewhere in no valid rapl domains found
<ppisati> cat: /proc/device-tree/soc/pwm@7e20c000/status: No such file or directory
<ppisati> ogra_: it doesn't have that node
<ppisati> :(
<ogra_> yeah
<ppisati> ogra_: found the dtb patch
 * ppisati respins another kernel
<livcd> any help ?
<Chipaca> livcd: vbox is virtualbox?
<Chipaca> livcd: the "no valid rapl domains found" is not a blocker/crasher/etc, just an informational message
<livcd> Chipaca: yes...i know but the whole thing stops there
<livcd> and won't continue booting
<Chipaca> ogra_: at least here autopilot does reboot the machine
<ogra_> Chipaca, not if you disable it
<Chipaca> livcd: you're giving us zero information we can use to help you :-(
<Chipaca> ogra_: correct
<ogra_> it still does the download and installs it though
<ppisati> ogra_: so, you were already using the dtb provided by the kernel so far?
<ogra_> ppisati, nope
<ogra_> laways the one from upstream
<ogra_> *i always
<ppisati> uhm
<ppisati> i wonder if there's any difference between the one shipped by upstreamn (linux-firmware in the github/raspberry repo) and ours
<ogra_> well, given they get generated based on kernel config ...
<ogra_> if our config differs, the dt will differ i guess
<ppisati> ogra_: right, and we are switching from an upstream dtb to our dtb, right in the middle of a cycle
<ppisati> ogra_: i've to do some db-diff and see the difference
<ogra_> yeah, not ideal
<ppisati> ogra_: or we should simply bite the bullet, and move to wily
<ppisati> *wily's kernel
<ogra_> as long as we can do that without regressing anything
<ppisati> ogra_: ok so, i'm pushing a new kernel with owm and so to my ppa
<ppisati> ogra_: then i cehck that wily is ok
<ppisati> ogra_: and after all that, i'll do some db-dif to see if moving from upstream to vivid is ok
<ogra_> Chipaca, oh, i see, the context is missing because the text from the readme.md in that mail is all screenshots
<ogra_> the text in the inline image actually talks about the fact how the update applies if you disabled it
<Chipaca> popey: next time you want to point somebody at "their own page on launchpad", try https://launchpad.net/~
<Chipaca> :)
<popey> dammit, I was looking for that but couldn't find the thing
<popey> i thought it was +me
<Chipaca> popey: if only you knew people that knew launchpad better than you, such that you could ask them!
 * Chipaca is being mean
<popey> :(
<popey> Finding their own launchpad page is the least hard part of signing the CoC to be fair
<Chipaca> popey: good on you for noticing there are so many of us delinquent on that point
<livcd> bah how do i uncompress the xz img ?
<livcd> ah
<ogra_> usin unxz :)
<livcd> there's a unxz
<ogra_> ricmm, oh, forgot to tell you, the latest 15.04 edge has auto-resize
<ogra_> (still testing pending, working on it)
<livcd> i am starting to give up on snappy
<ogra_> whats your issue ?
<livcd> oh well the ova did not quiete work for me
<livcd> it would not boot on vbox
<ricmm> ogra_: sweetskies
<livcd> i plan to build a box using Packer.io but there seem to be too much hassle to get a working vbox img :SSS
<ogra_> livcd, did you try just converting the amd64 img ?
<livcd> not yet
<ogra_> wget http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz
<ogra_> unxz ubuntu-15.04-snappy-amd64-generic.img.xz
<ogra_> qemu-img convert -O vdi  ubuntu-15.04-snappy-amd64-generic.img ubuntu-15.04-snappy-amd64-generic.vdi
<ogra_> then just use the vdi
<livcd> yeah except i will have to get unxz and quemu-img first to my system (not on ubuntu)
<ogra_> ah
<ogra_> in vbox you need to use "Choose an Existing Virtual Hard Drive File" when creating the vm
<livcd> ogra_: ok ty
<josepht> aa
<yashi_> is it intended to put image cache under /root/.cache when I run u-d-f? because u-d-f needs to be run with sudo
<ogra_> no, it should use the $SUDOUSER
<ogra_> well the home of that user :)
<yashi_> ah, ubuntu sudo is special?
<ogra_> no
<ogra_> ogra@anubis:~/Devel/packages$ sudo -s sh -c "env|grep SUDO"
<ogra_> SUDO_GID=1000
<ogra_> SUDO_UID=1000
<ogra_> SUDO_COMMAND=/bin/bash -c sh -c env|grep\ SUDO
<ogra_> SUDO_USER=ogra
<ogra_> sorry ... should be SUDO_USER
<yashi_> sudo -s sh -c "env|grep HOME"
<yashi_> HOME=/home/yashi
<yashi_> under wily
<yashi_> but i get HOME=/root under sid
<ogra_> did debian change anything ?
<yashi_> did i?  not that i remember
<yashi_> /etc/sudoers seems the same
<ogra_> https://launchpad.net/ubuntu/+source/sudo/1.8.12-1ubuntu1
<yashi_> all debian machine around me returns /root
<yashi_> ah
<yashi_> thanks
<yashi_> keep_home_by_default.patch: Keep HOME in the default environment
<ogra_> there are a few changes ... nothing that points to an obvious mangling of HOME though
<ogra_> oh, i'm blind
<ogra_> :P
<ogra_> yeah, that would be it i guess
<yashi_> yup, thanks a lot
<yashi_> not sure it's planed to package for debian, but this needs to be remembered if it is
 * Chipaca just tried importing "path/timepath". Science fiction and coding mix quite well.
<ogra_> heh
<Chipaca> mvo: you around?
<Chipaca> ok, school run time for me
<yashi_> ok, some progress; no partitions are recognized grub seems to be working; but "error: invalid file name `root=LABEL=system-a'." after "Booting from hard Disk..."
<yashi_> this should be easy to fix
<yashi_> (hope)
<dduffey> since gotomeeting URL is non-functional, do we have call in info?
<dduffey> sorry, wrong channel
<mvo> Chipaca: yes, sorry for the delay
<ppisati> ogra_: so, i was looking at the snappy dtb
<ppisati> ogra_: and it looks very very similar to the one we are shipping with the 3.19 kernel
<ppisati> ogra_: actually, it's almost the same!
<ppisati> ogra_: the only difference are the naming of the leds (led0 vs ACT and led1 vs PWR and stuff like that)
<ppisati> ogra_: abnd the pwm node that i added
<ogra_> ppisati, ah, cool
<Chipaca> mvo: no worries, i was on a school run anyway. I'm wondering at the relation between oem packages, and LocalRepo(oemDir)
<Chipaca> mvo: ie, are all packages in an oemDir of type oem?
<Chipaca> and thus, unremovable
<mvo> Chipaca: yes
<Chipaca> or are there non-oem packages that could live in an oemDir, which we may then try to remove and fail
<Chipaca> there is duplication of information there :)
<mvo> Chipaca: well, unless the user manually copies stuff in there or something
<Chipaca> well, if they purposely break it, they can go ahead and keep all the bits
<Chipaca> :)
<mvo> Chipaca: yeah
<mvo> Chipaca: so if type == Oem -> installdir = /oem
<mvo> Chipaca: what duplication do you have in mind? the prefix?
<Chipaca> mvo: so conversely, a list of removed packages can skip the oem repo entirely
<Chipaca> mvo: type=oem, and oem repo
<mvo> Chipaca: yes
<Chipaca> anyway, the tiny bit of code that i'm working on is correct if that <-> is true
<Chipaca> mvo: so, installdir = /oem -> type==oem?
<mvo> Chipaca: yes
<Chipaca> \o/
<mvo> Chipaca: just out of curiosity, is this simpler than just checking the type and excluding it? (I assume the anwer is yes :)
<Chipaca> mvo: in answering the question "can i get a list of all packages that have been removed but not purged"
<mvo> ohhh
<mvo> ok
<Chipaca> quite
<Chipaca> mvo: so i'll just check the path of the repo, and if it's not the apps path, i'll return nil
<Chipaca> \o/ :)
<mvo> Chipaca: sounds reasonable, we will have data dirs for kernel/os at some pont though, but thats future
<mvo> (but its getting closer!)
<Chipaca> mvo: and are those SnapParts, or are they their own go type?
<Chipaca> because the problem here is because oem snaps and framework snaps and app snaps are the same go type
<Chipaca> which used to make sense, but is making less as we refine the business logic behind each
<mvo> Chipaca: yeah, I struggle(d) with that too
<mvo> Chipaca: I made them OsSnap, AppSnap, KernelSnap now
<mvo> Chipaca: but its not 100% great because of misisng dynamic binding of functions (we talked about this some days ago). but its a step forward :)
<fgimenez> Chipaca, a log of the error http://10.55.32.36:8080/job/snapd-test/34/console
<fgimenez> the code http://bazaar.launchpad.net/~fgimenez/snappy/snapd_integration_test/view/head:/_integration-tests/tests/snapd_test.go#L69
<fgimenez> Chipaca, i'm pretty sure it's working fine, i've been able to access it with curl from the laptop after adding a rule for the testing port
<Chipaca> fgimenez: what firewall is running on that host?
<fgimenez> Chipaca, it's managed by nova, the security group that we have been using so far only accepts incoming requests to port 22
<fgimenez> Chipaca, i think there's nothing else, it's a regular snappy image
<Chipaca> fgimenez: can you ask whether it's filtering access to 127.0.0.1:80?
<fgimenez> Chipaca, yes, there's no rule for that, i can add one
<Chipaca> fgimenez: tbh i wouldn't expect it to be blocked, but Â¯\_(ã)_/Â¯
<Chipaca> mvo: i think i'm going to leave this husk work to later
<mvo> Chipaca: what work specificially?
<elopio> ogra_: a micro branch, can you please review? https://code.launchpad.net/~elopio/snappy/parted_script/+merge/270421
<Chipaca> mvo: a Husk part that is a part representing a remove package
<Chipaca> mvo: so i get the "removed" state right
<Chipaca> removed*
<fgimenez> Chipaca, yes, we give them this restrictive security groups just for testing! :)
<fgimenez> Chipaca, if you want to have a look there's a running instance in 10.55.32.103 with the service up on 9999, you should be able to ssh
<fgimenez> now the security group has the 9999 port opened, curl -i -X GET http://10.55.32.103:9999 works for me
<Chipaca> fgimenez: 's ok, i'll believe you :)
<Chipaca> fgimenez: fwiw, note that you can ask to serve on port 0 and you'll be given a random available one
<fgimenez> Chipaca, mmm how could we do the get from the test if we don't know the port?
<Chipaca> ah! you're doing it via activate from the test too
<Chipaca> never mind then :)
<fgimenez> Chipaca, ok :) one question for you, how could we kill the service created by systemd-activate?
<Chipaca> fgimenez: from inside, or from outside?
<fgimenez> Chipaca, inside
<Chipaca> fgimenez: you call Stop()
<fgimenez> Chipaca, sorry, inside the testbed, not the code
<Chipaca> fgimenez: from outside, kill it with SIGINT SIGQUIT, or SIGTERM
<fgimenez> Chipaca, ok thx, i'll add it to the integration test
<Chipaca> fgimenez: e.g., cmd.Process.Kill()
<Chipaca> fgimenez: or cmd.Process.Signal(syscall.SIGINT)
<Chipaca> fgimenez: actually safer (non-panic'ing) code would be: proc := cmd.Process; if proc != nil {proc.Kill()}
<Chipaca> because cmd.Process can be nil
<Chipaca> if the universe has exploded or something
<Chipaca> which can happen in a racy end-of-test cleanup
<fgimenez> Chipaca, :) thanks, i'll put that in place
<tedg> mvo: Looking at python-apt and the sourceslist support. It seems like that's just for reading, is that true?
<mvo> tedg: if you use aptsources.SourceList there is a save() method
<mvo> tedg: that should work and also preserve order comments and all that
<tedg> mvo: Do you think it makes sense to import the system default?
<tedg> mvo: I'm wavering on that. Kinda looking now towards full replacement to make it more predictable.
<mvo> tedg: my gut feeling is yes
<mvo> tedg: but I have no strong opinion either way, not doing it is more predictable (no crazy ppas get pulled in by default) but might surprise people who expect their crazy ppas :)
<tedg> mvo: I'm okay surprising crazy people, the results are fun! ;-)
<mvo> the up-side of using the system ones is that you don't need a apt.Cache().update() run which might be expensive on slow networks. but then - you don't need it very often in any case
<tedg> Yeah, but I think I always need that with custom sources.
<tedg> So I think I can default to system if not set, but if anything custom, I think just replace.
<tedg> mvo: Also, I'm confused on why I need to do update() and then open(), will that work if memonly=True ?
<mvo> tedg: thats a long standing usability bug, update() really should open() internally again :/
<mvo> tedg: and memonly=true will work
<tedg> mvo: Cool, good to know as I build this up :-)
<mvo> tedg: I step away from the laptop for a bit, but I will read scrollback if you have any more questions, the software-properties code might also be a useful real-world example  of p-apt
<tedg> mvo: Cool, thanks! Enjoy your evening!
<mvo> thanks!
<elopio> ogra_: https://code.launchpad.net/~elopio/snappy/resize_test/+merge/270718
#snappy 2015-09-11
<fgimenez> good morning
<elopio> hey fgimenez, one review please :)
<elopio> https://github.com/elopio/subunit/pull/5
<fgimenez> hi elopio! sure, on it
<Chipaca> mo'in
<Chipaca> elopio: what're you doing up?!?
<elopio> Chipaca: hackin'
<elopio> going to bed now.
<elopio> _o/
<Chipaca> elopio: that last one sounds like an eminently sane idea
<mvo> ogra_: hi, so  - silly question. if I mount /writable in the inird read-only and then put it into the generated /etc/fstab as "LABEL=writable /writable ext4 remount,rw 0 0", should this work?
<ogra_> work for what exactly ?
<ogra_> (why do you want it in fstab ?)
<mvo> ogra_: work in the sense that it will remount it
<ogra_> sure
<mvo> ogra_: how to debug if it does not work :) ?
<ogra_> sudo touch /writable/foo ... after boot ?
<mvo> ogra_: readonly fs, I see it in mount as mounted ro, but fstab conains the remount,rw line and systemd tells me the writable.mount was run
<ogra_> (i guess your boot log and console  would be full of errors already by stuff that tries to write to it via a bind mount)
<mvo> ogra_: yeah, there are some errors, fortunately it keeps booting
<ogra_> i'm not sure if you can force an order of mounts
<ogra_> you definitely want it rw beofre anything tries to access one of the bind mounts
<mvo> pitti: is the fstab generated mounts ordered or will systemd try to mount it all at once? (context is my question above)
<mvo> ogra_: aha, that might be a issue indeed
<ogra_> well, you can influence how we generate the fstab (thats done in initrd)
<mvo> ogra_: hrm, hrm, I was hoping I could get back to read-only only in initramfs :/
<ogra_> so you could put /writable first in there
<mvo> ogra_: right, I did that
<ogra_> the question is if systemd will process it in the order it is in fstab or not
<ogra_> i still dont understand why you want this
<pitti> mvo: partially ordered, subdirs auto-depend on mounts of their parent dirs
<ogra_> (you could as well just remount it froma  local-bottom script instead)
<mvo> pitti: thanks
<pitti> mvo:$ systemctl show -p RequiresMountsFor proc-sys-fs-binfmt_misc.mount
<pitti> RequiresMountsFor=/proc/sys/fs
<pitti> mvo: ^ for example
<ogra_> pitti, heh, and for cross device bind mounts ?
<mvo> ogra_: right, I could just leave it as it is (rw), I had hoped to move all the rw logic out of initrd so that systemd can do the fsck, provide a better emergency etc
<pitti> mvo: and RequiresMountsFor= translates into something like Requrires/After=proc-sys-fs.mount for any parent mount
<mvo> pitti: aha, nice. let me see
<pitti> ogra_: shouldn't matter - a mount is a mount?
<ogra_> pitti, well, /writable/system-data/foobar might come from /readonly/foobar
<mvo> pitti: could it be that systemd paritial ordering does not work for bind mounts, i.e. it only looks at the second column of the bind mounts?
<pitti> mvo: could be; haven't read scrollback here yet (still talking to doko/fighting with puppet); can you pastebin systemctl show of that .mount?
<ogra_> right, the question is if it looks for /writable or for /readonly in the above case
<ogra_> if the latter then it wont consider it depending on having /writable mounted first
<pitti> mvo: ah, the case is "remount"?
<pitti> mvo: could very well be that it stumbles over that -- /writable is already mounted, after all
<pitti> (just not with the changed options)
<ogra_> yeah
<ogra_> i'D really keep that bit in initrd
<mvo> pitti: its hard for me to pastebin, this is a very hacked snappy VM, the dependencies look ok of my writable.mount
<ogra_> the whole basic assembly of the underlying setup at least (/writable plus system-a/b)
<mvo> pitti: is there a way to figure out if it actually ran anything
<mvo> ogra_: hm, so the initrd will mount /writable and /boot sure, but I wonder if it would make sense to mount it RO and do the RW later
<ogra_> mvo, yeah, from a local-bottom script
<mvo> ogra_: I'm not a initrd guy, so I may be totally off, but what I keep hearing is that this whole fsck in the initrd is bad
<ogra_> thats runs right before run-init
<ogra_> well, do we still need the fsck for vfat after the changes we made ?
<ogra_> i think we shoudl be fine without it nowadays
<pitti> mvo: there should be someting like "Mounting /writable..." ... "Mounted /writable" in the journal?
<ogra_> (snappy update should perhaps run it when/after writing instead, normally nothing writes to the vfat in a way that fs content changes otherwise)
<mvo> ogra_: we mount /writable RW in the initrd, part of that is that its is fscked before and I would like to avoid that (same for /boot fwiw). mount both RO and let the normal system startup do the RW and possible fsck dance
<mvo> ogra_: but keep in mind I may be totally wrong about that this is a worthwhile goal to persue :)
<pitti> mvo: I tested with a bind mount of /media -> /home/media, and I get RequiresMountsFor=/home /media
<ogra_> yippie ! my new alix board just arrived ... will be my first snappy server !
<pitti> mvo: i. e. at first sight it seems to take the "first column" into account as well for bind mounts -- I suppose it's rather because /writalbe is already mounted, so that the RequiresMountsFor= is satisfied?
<pitti> ogra_: new toys!
<ogra_> mvo, well, we might need to write to it from initrd
<mvo> pitti: yeah, the dependencies look ok
<pitti> mvo: so check the journal, I suppose it gets remounted too late?
<mvo> ogra_: maybe, but I don't see any writes currently (at least in the version that uses squashfs)
<ogra_> http://www.amazon.de/gp/product/B00JR6X0ZK
<mvo> pitti: I don't see anything about /writable in the journal from systemd
<pitti> mvo: there are ways around it, like adding a drop-in for systemd-remount-fs.service to also make /writable r/w instead of remounting it in the fstab; just a bit strange
<ogra_> mvo, yea, thats why i said "might" :)
<ogra_> we currently dont but that couold change
<mvo> ogra_: heh :) ok
<mvo> ogra_: well, we could simply reenable all of it once it changes?
<ogra_> imagine we'd move away from livecd-rootfs and put the /etc/timezone or /etc/hostname stuff in place during boot
<mvo> pitti: journalctl -u writable.mount says no entries
<mvo> pitti: systemctl status writable.mount tells me its active (mounted)
<ogra_> i guess we could have our own systemd unit that does the remount without using fstab
<ogra_> would be the same as a local-bottom script though
<mvo> ogra_: yeah
<mvo> ogra_: right, then we can just leave it as it is I guess
<mvo> I'm mostly curious at this point if I do something wrong or if there is a bug
<pitti> ogra_: then I'd just append it to systemd-remount-fs.service and get the ordering for free?
<ogra_> as long as we are ext4 fsck wont be a biggie anyway for /writable
<ogra_> it is rather cosmetic
<JamesTait> Good morning all; happy Friday, and happy No News is Good News Day! ð
<mvo> pitti: ok, so I think systemd simply not supports remount in fstab, it has systemd-remount-fs.service and it looks like this only looks for /, /usr
<pitti> mvo: right, what I suspected; so this could be come a systemd-remount-fs.service.d/writable.conf with an extra "ExecStartPost=/bin/mount -o remount" if you want that, then it'll inherit the same dependencies (i. e. it will be done before any other fstab entry)
<mvo> pitti: hrm, I think I will just leave it in the initramfs then
<ogra_> well, we should keep that possibility in mind in case we ever actually *need* to move it out
<ogra_> given that writable might be encrypted we'll likely need to keep it in initrd though
<ogra_> (hwo do we handle fsck with encrypted root on server/desktop today btw ? that should have a similar issue)
<pitti> ogra_: it hasn't really changed in ages -- the initramfs sets that up
<Chipaca> let's hear it for tests! wooo!
 * Chipaca just found a nasty bug before committing code :)
<ogra_> pitti, yes, but who does the fsck ?
<ogra_> is it mountall/systemd or the initrd
<pitti> ogra_: back in the days, the OS; with recent initramfs-tools it now fscks / (and /usr) by itself
<pitti> ogra_: "OS" -> mountall or systemd-fsck
<ogra_> ah
<pitti> I think the initramfs-tools maintainer's argument was that it's generally a bad idea to fsck the root partition with tools from the root partitions
<ogra_> so the decryption happens in readonly ?
<pitti> ogra_: yes AFAIUI
<ogra_> ah
<pitti> while that argument makes sense, it makes nice plymouth integration much harder, though
<pitti> i. e. we lost plymouthy fsck feedback for the root partition
<pitti> so, I'm not sure I actually like that change :)
<ogra_> heh, yeah
<pitti> pretty vs. robust, tough :)
<ogra_> wheee !
<ogra_> and my new snappy server is assembled, installed and running :D
<ogra_> that was exactly 20min of work :D
<ogra_> (including HW assembly)
<ogra_> hmmm
<ogra_> but the resizing didnt work
<ogra_> (partition is resized, the fs isnt :/ )
<ogra_> weird, worked on the second boot
<asac> ogra_: already have your mail stuff snapped?
<ogra_> asac, nope, thats weekend work ...
<asac> ogra_: if you make a nice bundle that i can easily configure i could also replace my mailserver
<ogra_> i also want the user setup to be a bit different
<asac> remember to include TLS for the MTA
<asac> then i am in
<asac> one snap delivering a great integrated solution
<asac> MTA, mail filtering, imap
<ogra_> (and i'm still waiting for the actual SSD, that will only come on monday)
<asac> in one bundle
<Chipaca> mvo: have you seen thomi's talk on connascence?
<asac> easy to configure :) ... done.
<ogra_> a 32G SDD as bundled doesnt really cut it ;)
<asac> ogra_: you can start with SD to hack on it :)
<mvo> Chipaca: not sure, what was the link again?
<asac> ogra_: 32G would be enough for my mail needs
<asac> send it my way :P
<ogra_> yeah, i have a kingston 32G SSD ... and an USB mSATA adapter here
<ogra_> you can have it when the new one is here :)
<asac> cool
<ogra_> it is enought for experimenting on the weekend though
<asac> with snappy home-mail product preinstalled... i am your first customer :P
<Chipaca> mvo: https://www.youtube.com/watch?v=iwADIlIgDNA
<asac> just plug and boot
<ogra_> haha
<ogra_> well, you dont want an ogra user preinstalled with my ssh key i guess ;)
<asac> snappy-mail-geek-ready
<Chipaca> a year from now I'm going to own a snappy-powered AI that will have the keys to my snappy-powered attack drone^W^Wspider bot
<Chipaca> I feel like i'm in the future already
<ogra_> Chipaca, lame ... you just install the AI snap on the drone directly :P
<Chipaca> ogra_: batteries will still be a problem a year from now
<Chipaca> ogra_: we won't solve that one for a bit yet :)
<ogra_> there are always solar panels you can stick onto it
<Chipaca> ogra_: and give whatever it chooses to attack an easy way to disable it?
<ogra_> ah, well ... you got a point there
<ogra_> Chipaca, did we change anything wrt snappy config ... nothing in bug 1472788 seems to work anymore for me
<ubottu> bug 1472788 in Snappy "snappy config does not work from stdin" [Critical,Triaged] https://launchpad.net/bugs/1472788
<ogra_> all variants just generate a go backtrace
<ogra_> (i'm on 15.04 edge here though)
<Chipaca> ogra_: can you show me the session?
<ogra_> http://paste.ubuntu.com/12334856/
<ogra_> that line used to work for me in the past
<Chipaca> ogra_: and if you add -- before the - ?
<ogra_> hangs
<Chipaca> mmm
<ogra_> why the heck to we even need to pass yaml into the command instead of having set/get for variable/value pairs
 * ogra_ still doesnt get whats the benefit of it 
<Chipaca> ogra_: what's "15.04 edge" ?
<Chipaca> ogra_: because that code doesn't seem to be what i have here
<ogra_> Chipaca, the daily 15.04 build
<ogra_> http://system-image.ubuntu.com/ubuntu-core/15.04/
<ogra_> ubuntu-snappy	1.0.1-1+472~ubuntu15.04.1
<ogra_> ubuntu-snappy-cli	1.0.1-1+472~ubuntu15.04.1
<ogra_> is what the manifest for that image says
<sergiusens> Chipaca, care to quickly look at https://code.launchpad.net/~sergiusens/snapcraft/filesets/+merge/270455 (the last commit only if you want)
 * sergiusens fought with raw strings in python sometimes not being  raw strings
<sergiusens> oh, and to keep the human touch going, good morning to all (applied retroactively as well)
<ogra_> moin moin
<asac> good morning sergiusens :)
<ogra_> hmm, if i use --enable-ssh will there still be an ubuntu user ? and will password auth be on ?
<Chipaca> umm
<Chipaca> ogra_: your yaml is bad and you should feel bad
 * ogra_ feels bad
<Chipaca> ogra_: add an extra space before timezone
<ogra_> same thing
<Chipaca> ogra_: python3 -c 'import sys,yaml; print(yaml.load(sys.stdin))'
<Chipaca> ogra_: and feed it your yaml
<ogra_> with the same redirect ?
<sergiusens> ogra_, add two spaces instead of one after config:\n
<sergiusens> and shift the inner ones accordingly
<ogra_> sergiusens, already tried
<Chipaca> ogra_: yes, with the same redirect
<ogra_> Chipaca, hangs
<ogra_> (amd64)ubuntu@localhost:~$ python3 -c 'import sys,yaml; print(yaml.load(sys.stdin))' <(echo 'config:\n ubuntu-core:\n  timezone: Europe/Berlin\n')
<sergiusens> ogra_, SIGABRT to see where :-)
<Chipaca> dude
<Chipaca> duude
<ogra_> (even with corrected space it hangs)
<Chipaca> ogra_:  < <(...)
<Chipaca> so many things wrong
<ogra_> geez
<Chipaca> for example, echo -e
<ogra_> how else would you force the backslash interpretation in non bash echo ?
<Chipaca> ah, if it's non-bash, then i think you don't need -e
<Chipaca> that is
<Chipaca> dash builtin echo does not need -e
<Chipaca> but /bin/echo does
<Chipaca> but
<Chipaca> on the other hand
<Chipaca> dash does not have <(), or does it?
<ogra_> -e is a no-op for all the others
<ogra_> POSIX knows <() i think
<Chipaca> nope
<ogra_> anyway ... not working ... (no error either though)
<sergiusens> am I seeing this right? ogra_ writing bashisms?
<ogra_> :P
 * Chipaca refers ogra_ to http://mywiki.wooledge.org/Bashism
<ogra_> i just want to set my timezone
<Chipaca> ogra_: show me again what you're doing please
<ogra_> this is really hard :(
<ogra_> snappy config ubuntu-core < <(echo 'config:\n  ubuntu-core:\n    timezone: Europe/Berlin\n')
<ogra_> the nicely prints the config ... using Etc/timezone
<Chipaca> ogra_: that should do nothing
<Chipaca> ogra_: right, that's "get"
<Chipaca> ogra_: "set" is with an argument
<Chipaca> ogra_: go with -- -
<ogra_> tried, same go traceback
<Chipaca> ogra_: yes, because -e
<Chipaca> ogra_: you can't use <() and not -e a the same time
<ogra_> doesnt matter if i add or remove -e
<ogra_> same error
<Chipaca> you're going to make me *try* this stuff
<ogra_> same behavior in all cases
 * Chipaca boots something that may or may not be 15.04 edge
<ogra_> oooh
<ogra_> new error !
<Chipaca> no, this is 15.04 stable. still, should be the same
<ogra_> (amd64)ubuntu@localhost:~$ sudo snappy config ubuntu-core -- <(echo -e 'config:\n  ubuntu-core:\n    timezone: Europe/Berlin\n')
<ogra_> open /dev/fd/63: no such file or directory
<Chipaca> ogra_: -- -
<Chipaca> and <
<ogra_> hanngs hard
<Chipaca> dammit
<ogra_> ha
<ogra_> < did it
<ogra_> seriously ... who came up with that insanity
<ogra_> can we please have proper set/get syntax alongside ?
<Chipaca> ogra_: http://pastebin.ubuntu.com/12335797/
<ogra_> Chipaca, right, thats what worked here too now
<Chipaca> ah
<Chipaca> missed that
<ogra_> still, how is an admin supposed to ever decypher that line ?
<Chipaca> ogra_: http://i.imgur.com/YsbKHg1.gifv
<ogra_> LOL
<ogra_> right
<ogra_> also setting the hostname should tell you that you need to reboot to make it take effect
<ogra_> (or at least to re-login)
<ogra_> (not sure, perhaps the timezone setting needs that too)
<Chipaca> ogra_: config can't communicate that kind of thing out :-/
<Chipaca> maybe it should be able to, but right now it can't
<ogra_> well, perhaps a generic message like "you might have changed config options that require a reboot"
<Chipaca> ogra_: i'd rather let config hooks tell you things
<ogra_> yeah, or that
<Chipaca> like "you can't tell me to only use three of the four propellers when i'm a fridge"
<Chipaca> or "this config is dangerous, ask for it again for it to take effect"
<Chipaca> or something, dunno
<Chipaca> just info/error messages
<ogra_> yeah
<Chipaca> if you want to go crazy, debug messages (logged, not shown), info messages (logged, shown), error messages (logged, shown, config fails)
<ogra_> yup
<ogra_> hmm
<ogra_> why does /var/lib/extrausers/subuid not exist on that image
<ogra_> i added that in livecd-rootfs
<ogra_> weird, not there
 * ogra_ uploads a fix 
<sergiusens> ogra_, Chipaca the config spec is not completely implemented, configs are supposed to return success or failure with reason
<Chipaca> sergiusens: also probably not panic on bad input
<Chipaca> :)
<ogra_> well, i think making the interface actually usable is more important than messages and feedback in the end
<ogra_> its a nice to have thing :)
<sergiusens> Chipaca, that is up to each hook
<Chipaca> sergiusens: yes, the ubuntu-core hook panics and brings snappy down with it, which shouldn't happen
<Chipaca> ok, lunch break for me
<stgraber> mvo: anyhing I can do to get your branch merged? I'd rather not have LXD use a private, temporary bzr branch if I can help it :)
<mvo> stgraber: absolutely agreed, I poked the gettext-go upstream again, no reaction though. to get it merge into trunk someone needs to review it, I need either sergiusens or Chipaca to look at https://code.launchpad.net/~mvo/snappy/snappy-gettext-fixes/+merge/270620. alternatively you (or someone from your team) can of course review it as well :)
<Chipaca> whoa, \" -> \\" ftw
<stgraber> mvo: looks like it's been reviewed now, thanks :)
<Chipaca> daemon/task.go:29:2: struct field Id should be ID
<Chipaca> whoever wrote golint did not know id was a word, not an acronym
<Chipaca> https://github.com/golang/lint/issues/89
<mvo> thanks Chipaca
<mvo> Chipaca: meh, the comment in this upstream bug is unhelpful, there should be at least a --ignore=E101 or something
<Chipaca> i'm coming to expect that kind of response from go upstream
<Chipaca> mvo: in other news, https://code.launchpad.net/~chipaca/snappy/tasks/+merge/270813 \o/
<Chipaca> hm, that diff is borked, 1 sec
<mvo> Chipaca: yay, I go and review now
<Chipaca> fixed now :)
<ogra_> ppisati, hmm, do you plan non snappy RPi images ?
 * ogra_ just saw bug 1494719
<ubottu> bug 1494719 in flash-kernel (Ubuntu) "Support for the RaspberryPi2 platform" [Undecided,New] https://launchpad.net/bugs/1494719
<ppisati> ogra_: i already vanilla ubuntu rpi2 images
<ppisati> *have
<ogra_> ppisati, well, i was just wondering if you plan actual isos/imgs
<tedg> mvo: Did you have a chance to look at the python-apt stuff? Seems like it's having trouble kicking the local system habit.
<mvo> tedg: ups, once sec
<tedg> np
<Chipaca> https://code.launchpad.net/~chipaca/snappy/daemon-daemon-please-add-a-task---no-by-the-chin-of-my-chinny-chin-chin/+merge/270821
<Chipaca> and school run for me
<tedg> Chipaca: Make sure to listen to the teachers and do your homework!
<sergiusens> tedg, btw, how is that pip plugin looking?
<tedg> sergiusens: Okay, I wanted to confirm with zyga that it works for checkbox before doing the MR.
<sergiusens> Chipaca, buffer overflow, branch name too long
<tedg> sergiusens: I think they may need an array of requirements text files.
<sergiusens> tedg, ah, so it is on the same branch as before and updated?
 * sergiusens checks
<tedg> sergiusens: Yup
 * tedg checks a push to make sure it's all up
<mvo> tedg: is "ros-jade-ros-core" a good example pkg? I will poke at the code
<tedg> mvo: Yeah, that's supposed to be a meta package for all the base stuff.
<tedg> mvo: It pulls in a lot though, lots and lots of boost.
<mvo> ta
<mvo> tedg: aha, fun, I blame sergiusens :P for the issue, python-apt is fine
<sergiusens> mvo, what did I do? :-)
<mvo> tedg, sergiusens: so the issue is that python-argparse is a virtual package but the depedency resolver in the ubuntu plugin will not deal with that
<mvo> tedg, sergiusens: give me some more minutes to poke at it and maybe there is a easy way out
<sergiusens> mvo, the ubuntu plugin replacement you mn?
<mvo> sergiusens: what replacement is that?
<sergiusens> in any case, that is all original code :-)
<tedg> sergiusens: Yes, I was adding arbitrary sources lists
<sergiusens> mvo, there is no more ubuntu plugin
<mvo> sergiusens: oh, then I blame the original code ;)
<mvo> the "class Ubuntu"
<sergiusens> mvo, yeah, that is mine, mine it is not a plugin ;-)
<mvo> ok, sorry, in any case, I blame $someone_else_that_is_not_me :P
 * mvo still looks into a fix
<sergiusens> mvo, but the dependency logic is all from the original plugin, I just used fetch_binares instead of dget
 * mvo nods
<mvo> tedg: you have a MP
<sergiusens> asac, rickspencer3 ricmm tedg mvo any all or some mind looking at https://code.launchpad.net/~sergiusens/snapcraft/docs/+merge/270830 ?
<tedg> Woot! /me looks
<sergiusens> I think I want rickspencer3 to go through it first as he's the outsider :-)
<mvo> sergiusens, tedg: the MP uses the python-apt resolver now and it will also skip priority (essential, important). that is a bit arbitrary, but it will prevent libc, passwd from getting pulled in. adjust as needed using whitelist/blacklist for pkgs or whatever if priority is not the best fit for this
<sergiusens> mvo, where is that MP?
 * sergiusens checks his queue
<mvo> sergiusens: https://code.launchpad.net/~mvo/snapcraft/more-python-apt/+merge/270831 <- this one probably not in your queue
<sergiusens> mvo, right, seems so from the target
<sergiusens> :-)
<sergiusens> mvo, commented with open questions :-)
<mvo> sergiusens: thanks, excellent point. why single quoes?
<elopio> fgimenez: try +	{TestID: "test-with-timestamp", Status: "success", Timestamp: time.Now().UTC().Round(time.Microsecond)},
<elopio> (adding the UTC call)
<mvo> sergiusens: it seems the python world has not really made up their mind when to use which
<sergiusens> mvo, because elopio said so; that we should use one and single dominated the code bases these days
<sergiusens> :-)
<mvo> sergiusens: fair enough, branch updated, thanks
<sergiusens> mvo, looks good, still missing an either or action on manifest.txt (remove or elif to skip too)
<mvo> sergiusens: aha, shows my ignorance with the code, yeah, let me look at this
<asac> sergiusens: i would love to look at it after merge
<asac> quick glance looks good, but want to go tipp to tail to feel how complete etc
<asac> sergiusens: i suggest to use example.tld
<asac> not com :)
<asac> j.k.
<ogra_> .onion is in fashin currently i heard
<ogra_> *fashion
<asac> hehe
<sergiusens> :-)
<BjornT> do i have to poke someone to get MPs reviewed for snapcraft, or will someone review it in a timely manner anyway? https://code.launchpad.net/~bjornt/snapcraft/setuptools/+merge/270733
<sergiusens> BjornT, I did not comment on that one since it had merge issues; I saw you based it out of mine or rebased yours out of that as well; might want to wait a bit for tedg's pip integration
<sergiusens> BjornT, but, to answer your question, tedg or myself ;-)
<mvo> sergiusens: I'm actually not quite sure what to do, I would love to just kill manifest.txt and see if that works, it only lists essential/important packages but then I don't know the rational for the list (debootstrap output maybe?)
<BjornT> sergiusens: ok :) fwiw, the merge issues should be fixed already.
<sergiusens> BjornT, ah, launchpad never notifies about those :-/
<sergiusens> BjornT, I'll look, but I'll lock on tedg as he is doing some pip work on that same plugin
<BjornT> sergiusens: thanks!
<elopio> fgimenez: so all green on subunit? should I merge?
<fgimenez> elopio, yup, go ahead!
<elopio> thanks.
<sergiusens> mvo, did you just add needs fixing to your own branch?
<ogra_> he's just honest :)
<mvo> sergiusens: yes, but tedg has merged it already (without merging it, not sure what he did)
<tedg> Ah, yeah. I merged it to my branch. I can do another merge with updates before things get into the main branch.
<tedg> I wouldn't want to have double quoted strings or something crazy like that.
<sergiusens> tedg, there is one minor fix wrt to explicitly installing package_names even if they are in essential or important
<sergiusens> which is what the original implementation already had
<elopio> ogra_: using xz seems to work on beagle, canonistack and kvm tests.
<elopio> do we care about somethinig else?
<ogra_> yes, Rpi
<ogra_> but then i guess i need to make sure it is xz there too
<elopio> let me flash it and try.
<ogra_> are you doing the repacking on the snappy system ?
<elopio> I would prefer to always use xz, because we would need a tool to unpack and a tool to repack. That becomes scary bash for me.
<elopio> but well, you can help me :)
<elopio> ogra_: yes, everything happens on local-premount on snappy.
<ogra_> well, the question is if we will ever provide the test tool to others
<elopio> oh wait, not everything.
<elopio> the unpack repack is when it's booted, of course.
<ogra_> if we give the suite to third parties they could use whatever compression they like for their initrd
<ogra_> for that it would be nice if the tool could cope with it
<ogra_> if it is only for use we can just make sure it is always xz everywhere
<ogra_> s/use/us/
<elopio> it would be nice indeed.
<elopio> but maybe we don't care here about how it is compressed. Linux takes care of that and we can assume it works well.
<elopio> we just want the option to add spy scripts. We could generate with mkinitramfs, and compress with whatever we like.
<ogra_> no, we couldnt ...
<ogra_> not withut making bits of the ro fs writable
<ogra_> (and i also plan to rip all initrd rebuild tools out of the rootfs since we dont support it on snappy anyway)
<elopio> I tried that way a couple of days ago, making it writable. But something went wrong, I now don't remember what.
<ogra_> your unxz and cpio is the best you can do ...
<ogra_> just keep that
<elopio> ogra_: ok, that makes sense.
<elopio> (stripping the init tools, I mean)
<ogra_> if we eveer give the tests to third parties we can adapt
<elopio> ogra_: I agree. Shouldn't be that hard. The script will get uglier with two cases and we might need to add file to the image, but let's worry about it later.
<ogra_> right
<elopio> ogra_: I can't merge this yet, because there's a bug in the test helpers on beagle. Will fix that now.
<ogra_> k
<mvo> sergiusens: thanks for your reviews, I think I have fixed them all, will get dinner now and check that the branches are merged after that
<sergiusens> mvo, k, was having lunch myself
<kyrofa> ogra_, did you see the "installing apps on snappy personal" email that just came across snappy-devel?
<sergiusens> kyrofa, I guess that email is probably thinking from a UI
<kyrofa> sergiusens, right. Is he talking about an image generated from the personal channel?
<kyrofa> I didn't know one was uploaded anywhere
<sergiusens> kyrofa, I think he is; notice it might not be ogra_ bu olli
<olli> nah, it must be ogra_ as olli is not building images
<rickspencer3> hehe
<rickspencer3> olli, I assumed it was in reference to one your blog posts or something
<olli> ogra_, is there such a thing like a personal image
 * olli thinks he should know
<kgunn> ogra_: can confirm, but afaik there's not a snappy personal image per se in a channel, it's just that you can use u-d-f to create one off the rolling edge
#snappy 2015-09-12
<Methaphetamine> :D
<Methaphetamine> Hi! everyone
<ogra_> kgunn, http://system-image.ubuntu.com/ubuntu-personal/rolling/edge/ and https://plus.google.com/u/0/+OliverGrawert/posts/Z8q7fDQac2r
<yashi_> ogra_: nice work :)
<ogra_> yashi_, not my work (i only answered a question from last night)
<yashi_> oh
<kgunn> ogra_: ah, so that's where they learned it
<ogra_> yeah
<yashi_> is there an instrcution how to create ubuntu-*.tar.xz u-d-f is using?
<yashi_> just watching uos 1505 video; is system image moving to snap?
<ogra_> yes, eventually
<yashi_> ogra_: is it in the time frame of, say, years? or next release?
<ogra_> monthas i'd guess
<ogra_> *months
<yashi_> sweet
<yashi_> so, it won't be ubuntu-*tar.xz at first of u-d-f, but one os snap and others, like kernel and oem.  am i understanding right?
<ogra_> right
#snappy 2015-09-13
<Chipaca> so ... yaml mappings can contain themselves as keys or values
<ogra_> geeez !!!!
<ogra_> snappy config just got unreadable
<ogra_> (i didnt know we'd actually print out all of /etc/ppp now)
<Chipaca> so I could do
<Chipaca> foo: &id
<Chipaca>   *id: *id
<Chipaca> and that's a mapping that, when you look for it in the keys, it gets itself as a value
<Chipaca> json can't serialize that
<Chipaca> ogra_: *all* of /etc/ppp?
<ogra_> yeah, run snappy config on a recent 15.04 edge image :)
<ogra_> oh, it doesnt print as much if you dont update a value
<ogra_> snappy config ubuntu-core that is  ... if i set hostname or timezone it prints the values afterwards ... and there it seems ot have all of /etc/ppp
<Chipaca> /etc/ppp wasn't that big, from memory
<Chipaca> unless you left all the comments in there
<Chipaca> oh, wait
<Chipaca> the directory?
<Chipaca> i was thinking of /etc/ppp/options
<ogra_> http://paste.ubuntu.com/12395367/
<ogra_> after i did set hostname to "testhost"
<ogra_> just running snappy config ubuntu-core doesnt show any of the ppp values though ... it is only after i changed something when it prints the changed values
<Chipaca> ogra_: and are they then "stuck"?
<ogra_> well, snappy config ubuntu-core only shows "ppp: []"
<ogra_> seems ot prints defaults when changing values ... but not when just printing from snappy config
<ogra_> http://paste.ubuntu.com/12395393/ thats plain "snappy config ubuntu-core"
<ogra_> we should make it omit the ppp values in the printout after changing any values as well
<Chipaca> yeah, not sure what's going on there
 * Chipaca wonders if he should look
<ogra_> nah, leave that to michael :)
<ogra_> just cosmetic
<ogra_> hmm
<ogra_> setting a static ip via the new snappy config interface leaves me without any DNS config
<Chipaca> DNS is for people who can't an ip address
<ogra_> tell that to webdm :P
<Chipaca> :)
<ogra_> ok, specifying dns-nameservers in the inerfaces file seems to work ...
 * ogra_ adds another variable to his setup script
 * Chipaca wonders what DNS - nameservers leaves
<ogra_> http://paste.ubuntu.com/12396598/
<ogra_> :)
 * Chipaca starts considering expensing a pizza
#snappy 2016-09-12
<liuxg> i have flashed ubuntu core to my SD card for QualComm 410c. I inserted the coard into my system. Can anyone tell me how to let it boot from the SD card instead of the built in android system? thanks
<qwas> What are some disadvantages to using snaps? would there be duplication of dependencies? Say, package X uses Y dependency. package Z uses Y dependency.  Both snaps include Y dependency.
<akash> SamYaple_: python3, and then in ubuntu 16.04 i call python3-pip, and python3-dev
<liuxg> for qualcomm snapdragon board, without network access, it cannot complete the installation. on the board, it does not have the Ethernet, how can I set up the WLAN network? thanks
<tzununbekov> Hi all. Is there a way to install and use Snappy Ubuntu 16.04 without having an account on ubuntu.com?
<liuxg> mvo, ping
<mup> PR snapd#1888 opened: interfaces: allow special casing for auto-connect until we have assertions <Created by mvo5> <https://github.com/snapcore/snapd/pull/1888>
<mvo> liuxg: pong
<liuxg> mvo, I just got a snapdragon 410c board. I have flashed the latetst software at http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/. however, I cannot get the netowork up so that I cannot complete the network config. Do you know how to do it? thanks
<mup> PR snapd#1884 closed: tests: get the gadget name from snap list <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1884>
<liuxg> mvo, the board only has a WLAN, but it does not have a ethernet interface for use. May I modify some part of the software to get my WLAM working so that I can connect to the device?
<dholbach> hery hey
<liuxg> mvo, ogra_, we are going to have a talk at Qualcom event. I am now trying to build some demos for the board :)
<mvo> liuxg: its a known issue, sorry that I did not write a followup on that to the list. the console-conf software does not yet support wlan, however mwhudson is working on this AFAIK. in the meantime the workaround is a usb network adapter
<mvo> liuxg: would the usb (lan) network adaper unblock you? we might also get mwhudson to release a early version of the new wlan code. when do you need this? i.e. when is the event?
<mup> PR snapd#1876 closed: cmd/snap: make "snap find" error nicer <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1876>
<liuxg> mvo, ok. in that case, we probably need to have a ethernet network adapter for it. good to know the workaround. thanks. I am not sure whether it is good to disable console-conf for development software. to developers, it may be a problem.
<mup> PR snapd#1889 opened: tests: add yakkety test host <Created by mvo5> <https://github.com/snapcore/snapd/pull/1889>
<tzununbekov> mvo, hey! Could you help me with Ubuntu Snappy 16.04? Trying to figure out if it is required now to have Ubuntu One account to use Snappy
<mvo> tzununbekov: this is the case right now, we are working on local users that are created differently, but the current image needs a u1 account  that is used to setup your local user. the upside is that this is super convinient, i.e. your ssh keys are on the device, your prefered username and we plan to sync the ssh keys in the future so that key update will be totally transparent
<tzununbekov> mvo, I see, thanks
<morphis> pitti: ping
<pitti> morphis: contentless pong :)
<tvoss> good morning
<morphis> tvoss, pitti: morning :-)
<morphis> pitti: have a question about systemd and how it sets up /sys/fs/cgroup
<pitti> morphis: good morning!
<morphis> pitti: we're running systemd on a 3.4 based kernel
<morphis> its kind of unsupported by upstream, but works
<morphis> it somehow fails to setup /sys/fs/cgroup on its own on startup so we have to workaround via https://paste.ubuntu.com/23168270/
<morphis> pitti: from what I read in the source it should actually do this on its owner so I am wondering if there might be some hidden thing I am missing in the picture
<morphis> pitti: as further context info, this is systemd 229 as it comes in xenial
<pitti> morphis: hm, I tried a reasonably modern systemd (~ 220 or so) on 3.4, back then this worked well enough
<morphis> pitti: yeah 219 works like a charm
<pitti> morphis: ah, is that your /sbin/init wrapper?
<morphis> yes
<pitti> it should also mount /proc and /sys etc. on its own
<morphis> right
<pitti> well, you need /sys if you manually mount /sys/fs/cgroup of course, but shouldn't need /proc and /dev
<morphis> if I don't put this wrapper in place it fails with error message like "too many symlinks on /sys/fs/cgroup"
<pitti> morphis: so, I can't say off the top of my head, do you have dmesg from a boot with init=/lib/systemd/systemd directly?
<pitti> that should have some error message
<morphis> yes
<morphis> pitti: it fails very early: https://paste.ubuntu.com/23168277/
<morphis> that are the relevant lines
<morphis> pitti: this somehow looks like its failing to mount a tmpfs on /sys/fs/cgroup
<morphis> but it doesn't print out any error message for this
<pitti> morphis: this might be related to 3.4 not supporting name_to_handle_at() or /proc/<pid>/fdinfo yet?
<morphis> hm, that could it be
<pitti> https://github.com/systemd/systemd/blob/master/src/basic/mount-util.c
<pitti> morphis: these are the helper functions that determine whether a path or a fd is a mount point
<morphis> then both fallbacks doesn't seem to work here
<pitti> it  normally uses name_to_handle_at() as that's the most robust/fastest, then falls back to fdinfo, then falls back to stat9)
<pitti> stat()
<pitti> morphis: maybe wrap it in strace, to get an idea what it does?
<morphis> yes, will check that
<morphis> pitti: thanks!
<pitti> morphis: src/core/mount-setup.c, mount_one() indeed uses path_is_mount_point(), and that matches the error message
<morphis> yeah
<akash> hello all im using python3 with pip. the snap creates properly, but when executing the script it says it cant find pip via python in the snap
<pitti> morphis: are there any actual symlinks involved in that environment?
<akash> can someone tell me how to inject pip into the snap its self for use?
<morphis> pitti: no
<mwhudson> mvo: hey, i guess now beta is done we should feed you a new console-conf release
<mwhudson> mvo: it has wlan support now :)
<ogra_> mwhudson, copy it over !
<mwhudson> ogra_: need to upload it first! (am editing changelog now)
<ogra_> \o/
<mwhudson> woo got my gpg passphrase right first time
<mwhudson> ogra_:  0.0.16~xenial in https://launchpad.net/~canonical-foundations/+archive/ubuntu/ubuntu-image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<ogra_> ah, the publisher ...
<ogra_> (might take a while)
<mup> PR snapd#1801 closed: snap: make snap download also download the assertions for the snap <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1801>
<ogra_> mvo, i think you need to re-do (xz) the pi3 image, seeme the xz step is corrupt (nothing to notice on the running image, so i guess only the zeroed parts are affected, but it is ugly)
<ogra_> *seems
<mwhudson> ogra_: it published now at last
<ogra_> do you have access to copy it to the image PPA ?
<mwhudson> ogra_: no
<ogra_> done ... waiting for the next publisher now :)
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<ogra_> i'll trigger an ubuntu-core build once it is done
<mwhudson> zyga: did you get your collab-maint access sorted?
<bzoltan> ogra_: as a snap app developer how can I know what system library I can expect to be on the core snap? Is there a minimal image I can see what packages the snap core is built from?
<mvo> ogra_: sure, lets redo it
<mvo> mwhudson: \o/ for wlan
<ogra_> bzoltan, since you shouldnt use anything except libc from the core snap thats a moot question .. beyond that there is bug 1608432
<mup> Bug #1608432: snaps with type: os should allow publishing of .manifest files <lp-snappy> <Launchpad itself:In Progress by cjwatson> <launchpad-buildd:In Progress by cjwatson> <Snapcraft:Incomplete> <https://launchpad.net/bugs/1608432>
<ogra_> libc and /bin/sh are the only guaranteed bits in ubuntu-core
<pstolowski> mvo, hey, you know a lot about systemd & deb packaging - any advice on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1622045 ? adding #DEBHELPER# didn't fix it. removing the symlinks in the postrm script "manually" caused the problem with these units after re-installing the deb
<mup> Bug #1622045: /etc/systemd/system/multi-user.target.wants/snapd.* symlinks not cleaned up when package is removed/purged <amd64> <apport-bug> <xenial> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1622045>
<pstolowski> mvo, i mean after reainstalling, the units are disabled
<ogra_> arent the units conffiles ?
<ogra_> you need to use the right tools for them if they are
<pstolowski> ogra_, there are debian/*.service & debian/*socket files for them if that's your question?
<mvo> pstolowski: the lack of #debhelper# looks like a bug in itself
<pstolowski> ogra_, ah, no i don't see any conffiles declared
<mup> PR snapd#1861 closed: tests: fixes to actually run the spread tests inside autopkgtest <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1861>
<ogra_> i think you want the deb-systemd-helper tool in your scripts
<ogra_> or dh_systemd_*
<ogra_> (afaik both should work)
<ogra_> err
<ogra_> **and* dh_systemd (in debian/rules)
<ogra_> new ubuntu-core building
<bzoltan> ogra_: thanks, that is clear
<ogra_> mvo, two things ... steve said we can drop grub from the amd64 rootfs ... i'll do that today ... and i uploaded https://myapps.developer.ubuntu.com/dev/click-apps/5912/ onn the weekend, could you approve it ?
<mvo> ogra_: grub-- ? cool, we still need grub-editenv for now, I can write it natively if we want to get rid of it fully
<mvo> ogra_: and linux-generic-bb +++ !
<ogra_> hah, thanks ... the mail was fast :)
<ogra_> (store mail)
<ogra_> mvo, yeah, i think it would be preferrable if we handle both bootloaders directly from snapd ... but i'll keep grub-common around for now
<ogra_> mwhudson, ubuntu-core done in case you still want to test (i imagine its EOD for you)
<mvo> ogra_: yeah, SMOP
<ogra_> yep
<TinoGuest> pitti: do you know / have an idea when / why would 'systemd' take over a serial console on the device, so that device, after it boots , doesn't have console (uart gpio's) to log in? virtual consoles show up...  any pointers to getty@tty*.service ? I was looking at http://0pointer.de/blog/projects/serial-console.html - but maybe I am missing something else ?
<zyga> mwhudson: not yet, I'll get it sorted out soon
<Pharma> Hello everybody
<Pharma> I have a question about snappy as a user, hope i will get answer here.
<Pharma> I'm using ubuntu 16.04 and working as a freelancer on upwork.com and i need to track my working hours. About 6 months ago, their app for tracking working hours failed to work on Linux
<Pharma> The problem is - they need this "libnss3_3.19.2.1-0ubuntu0.14.04.2_amd64.deb" so their app can send info about working hours to their server
<Pharma> So the question is, can close-sourced programs be packed in snappy too? If yes, can somebody ask/help upwork with snappy for linux users this will be very usefull. thank you guys for your work.
<ogra_> indeed you can package closed source apps ... snap doesnt care whats inside
<Pharma> Cool, so can somebody with @canonical.com e-mail contact upwork team?
<Pharma> if snappy supports all linux distros they would love to switch i guess
<ogra_> do they use some bug tracking system ? you could file an issuue there and ask them to offer a snap ... we'll happily help here if they drop by or ask on the mailing list
<Pharma> But who i'm to tell them about snappy, they will ignore my mail..
<Pharma> i will check this, if yes i will provide link here so ppl can upvote issue.
<ogra_> k
<Pharma> There is only community forum, users need to have account to write there.
<Pharma> If here are people from canonical, please contact upwork linux team >https://www.upwork.com/about/contact/ drop them a message from @canonical.com domain about snappy package for their app, and how this will help them fix their problems with their app for linux users partners@upwork.com
<zyga> Pharma: closed source software can be packed in a snap, just as it can be packed in debs
<Pharma> zyga, thanks, hope somebody from canonical will notice my message and will do something.
<mup> PR snapd#1890 opened: tests: add spread test for snap create-key/snap sign <Created by mvo5> <https://github.com/snapcore/snapd/pull/1890>
<mup> PR snapd#1891 opened: doscs: add create-user documentation <Created by mvo5> <https://github.com/snapcore/snapd/pull/1891>
<pitti> TinoGuest: this is usually controlled with the console= kernel cmdline argument; any consoles specified there will also get a getty and boot messages
<TinoGuest> pitti: is this happening "automatically"? getting getty. and enabling console ?
<TinoGuest> kernel cmd line is ok. i can boot non systemd rootfs, and keep using console on the device
<ogra_> pitti, seemingly systemd always creates tty1 regardless if we have console= pointing to serial (which is the default on the arm images ... x86 has two console= options
<TinoGuest> same kernel , same initramfs, cmd line
<ogra_> )
<pitti> TinoGuest: well, what is the actual problem -- you don't get a console on ttyS1, or an unwanted one on tty1, ..?
 * ogra_ understood the prob to be the latter
<ogra_> (but i might misunderstand)
<TinoGuest> pitti: issue is that console stops at some point of systemd initialisation
<ogra_> TinoGuest, which one
<TinoGuest> its actual, serial console on the device. not a virtual console
<ogra_> on what arch is that ?
<ogra_> on x86 ones this is expected ...
<pitti> ogra_: right, we statically enable getty on tty1
<TinoGuest> btw, virtual console is up....
<ogra_> since we use two console= args there
<pitti> ogra_: so provide a default if console= is not given, or for containers etc.
<TinoGuest> arch=armhf
<ogra_> so kernel adn bootloader messages go to the first defined console ... subsequent boot messages (userspace) go to the second defined console=
<TinoGuest>  that doc url talks about serial-getty and just getty
<ogra_> on armhf we dont really do that
<TinoGuest> ogra_: "we" means Ubuntu Core or Server or Classic?
<ogra_> i.e. the raspeberry pi images only have "console=ttyS0,115200"  on their cmdline ... so you wont see boot messages on the screen, but a tty will start there as pitti said above
<ogra_> i'm talking only about ubuntu core images here
<ogra_> no idea what server or classic do
<TinoGuest> ogra_: maybe changing kernel cmd line would help
<ogra_> no it wont, as pitti said above, there is a static default for tty1
<TinoGuest> ogra_: ttyS0 or tty1 - same serial console ? what is ttyHSL0 ?
<ogra_> a device name :)
<ogra_> the tty name really depends on your hardware
<ogra_> i.e. ... dragoboard (arm64) images use console=ttyMSM0,115200n8 ... rppi2/3 images use console=ttyS0,115200 ...
<ogra_> whatever your HW normally uses for serial needs to be defined there
<TinoGuest> ogra_: ok.... i got the impression that systemd somehow supressed serial console and kept virtual console (on the monitor attached)
<ogra_> if you defined the right values for the console= option you should have both
<TinoGuest> ogra_: console= has only one option... this somehow turned into virtual...
<ogra_> well, whoever ctreated your gadget snap needs to set the right option there ... based on the actual hardware used
<pitti> you can specify console= multiple times if you want multiple consoles, the boot output will be multiplexed then
<TinoGuest> so the difference in "serial-getty@...." and "getty@..."  is not relevant for this?
<pitti> not really; the latter gets auto-activated by logind when you Ctrl+Alt+Fn (VT switching), serial console don't
<pitti> that's the main difference AFAIK
<TinoGuest> ogra_: thats why i asked u if u referring to ubuntu core only :-)
<ogra_> pitti, nope, it wont be multiplexed ...
<ogra_> it will always only go to one
<ogra_> if you define two the first is kernel+bootloader, the second is usersapce messages
<popey> what's the equivalent to "snappy enable-classic" now?
<ogra_> popey, sudo snap install classic --devmode --edge
<ogra_> popey, sudo classic
<pitti> ogra_: it does get multiplexed
<ogra_> pitti, thats news to me and alll my installs here disagree :)
<pitti> at least the initial grub, kernel messages etc, until userspace kicks in
<ogra_> oh, right
<ogra_> initial bootloader stuff might ...
<popey> sweet, thanks ogra_
<ogra_> kernel messages then go to the first console= though
<ogra_> and userspace (initd, systemd boot log etc) go to the second
<ogra_> *initrd
<TinoGuest> pitti: so when userspace kicks in, u still get serial console msgs, and virtual terminal?
<ogra_> on that level there is no multiplexing
<ogra_> TinoGuest, yes, because tty1 is statically hardcoded
<ogra_> so you get a login prompt on both
<TinoGuest> yes! thats what i want.... hm somehow i lost it.... ok i will look more into rootfs ....
<pitti> I see the "Starting..." messages on both, too
<pitti> that is, in installs without "splash" -- plymouth is of course a wholly different story
<ogra_> on arm HW ?
<ogra_> i wonder if there is an arch specific difference here
<pitti> no, x86
<ogra_> aha
<ahayzen_> Hi, I've managed to get my code snapped by Launchpad, however when it tries to upload to the store it fails with "Click and Snap packages cannot be mixed."
<ahayzen_> Now, I already have a click in the store with the old style package name "com.ubuntu.developer.andrew-hayzen.volleyball2d" but the snap is configured to the package name "volleyball2d".
<ahayzen_> Is the problem that it thinks these two have the same name? Or is this a different issue?
 * ogra_ guesses thats a store question
<bzoltan> ogra_:  will snapcraft pull the recommended/suggested packages too for the packages listed in the stage-packages?
<ogra_> bzoltan, nope, it uses --no-install-recommends ... you need to list them
<ogra_> also note it doesnt run any maintainer scripts (so alternatives dont get set etc)
<bzoltan> ogra_: I will not do it :) I like it exactly this way .. skinny and light
<mup> PR snapd#1892 opened: snap,store: capture newest digest from the store, make it DownloadInfo only <Created by pedronis> <https://github.com/snapcore/snapd/pull/1892>
<pitti> bzoltan: note the definition of recommends -- "you can remove a recommended package if you know what you are doing" -- i. e. not a good default
<bzoltan> pitti: Of course
<bzoltan> pitti: I am working on to make our IDE package ligher and many of its dependencies pull lots of packages as recommendations what we do not really need... but of course heavy testing follows each removal :)
<ogra_> mvo, hrm, dropping grub from livecd-rootfs has no effect ...
 * ogra_ wonders where it comes from now 
<ogra_> oh man
<ogra_> cjwatson, do you have any hint for me how i can remove a package from a task in an already released release ? http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/view/head:/system-image defines grub binaries which means they get pulled in regardless
<cjwatson> ogra_: You can't unfortunately - this is why point releases tend to use metapackages
<cjwatson> It's an awkward deficiency that stems from the way tasks are implemented as fields in the Packages file, combined with the fact that we never republish the release suite after release
<ogra_> yeah, i remembered that, i just had hopes there is some secret trick
<cjwatson> I'm afraid metapackages are the best secret trick I have
<ogra_> well, except that we dont have them at all for core
<ogra_> that will be quite a set of changed to livecd-rootfs too
<ogra_> *changes
<ogra_> i wonder if i could push a grub package with ripped out task header to the PPA instead ... but that would forever bind us to the PPA
<mup> PR snapcraft#793 opened: Unify python plugin <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/793>
<arges> Hi. can somebody triage bug 1621525? I'm wondering how to fix this
<mup> Bug #1621525: classic environment variables for daemon snaps <Snappy:New> <https://launchpad.net/bugs/1621525>
<ogra_> arges, i think thats a duplicate of bug 1584811
<mup> Bug #1584811: Support a snapcraft environment keyword <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1584811>
<arges> ogra_: well i won't know them when I type snapcraft.
<arges> thing HTTP_PROXY, which may or may not exist
<arges> think
<popey> sergiusens: have you seen an issue with snapcraft (or the part) where, during make (make plugin) it copies things to stage but under stage followed by my home directory name.. e.g. i end up with /home/alan/Development/Snappy/foo/stage/home/alan/Development/Snappy/foo/parts/bar/build/...  ?
<popey> sergiusens: I don't understand what's doing that, looks like something is using `pwd`
<popey> sergiusens: build stage has the dir correctly, seems to fail going build -> stage
<cjwatson> ogra_: It's indeed not quite trivial but I think it's probably unfortunately what you have to do
<ogra_> yeah ... *sniff*
<ogra_> so silly that we picked a task at all for 49 packages (of which i'll drop 6 now)
<ogra_> cjwatson, oh, i just see there is grub-xen-bin in the list, i think i added it on your request ... is that still needed inside the rootfs ?
<ogra_> (technically all bootloaders moved to the gadget snap now ... )
<cjwatson> ogra_: I just wanted it to be available at all; I don't currently understand gadget snaps, so if that's a more appropriate place then fine
<ogra_> well, depends how you use it ... if you actually boot an img file the gadget is what you use ... if you'd do something like "kvm --kernel ... --initrd ... --hda ..." that wouldnt use the gadget
 * ogra_ has no clue about xen :)
<cjwatson> ogra_: You normally have a virtualised disk and boot that.
<ogra_> ok, then i guess you have a gadget in use
<cjwatson> ogra_: Except that Xen needs to get at the boot loader somehow; there's a protocol for figuring out the right path inside the guest
<ogra_> and that protocol support is provided by the grub-xen-bin package ?
<cjwatson> ogra_: It sounds closer to a gadget snap, provided that that can cause files to exist under /boot/xen/
<ogra_> oh, yeah ...
<cjwatson> (in the same way that grub-install does when told to install for a Xen target)
<ogra_> though we dont have that mountoint supported atm ...
<ogra_> mvo, ^^^
<cjwatson> The protocol in question is documented upstream as https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/x86-xenpv-bootloader.markdown;h=ec8854e6589bcc67e7043410a7157bb0bf481347;hb=HEAD
<cjwatson> (There are older methods as well - I'm ignoring those since they typically involve more manual work)
<ogra_> oh what a pain ...
<mup> PR snapd#1885 closed: tests: add upower-observe spread test <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1885>
<diddledan> o/
<sergiusens> popey what project? or is it one of our demos? Can I see snapcraft.yaml for it?
<diddledan> snapcraft cleanbuild just failed to access http://start.ubuntu.com/connectivity-check.html with "http.client.RemoteDisconnected: Remote end closed connection without response"
<popey> sergiusens: trying to repeat it
<diddledan> I'm wondering if it could be network conflict with docker
<popey> sergiusens: okay, reproduced it. http://paste.ubuntu.com/23169430/ - it's the ptex part which gets built incorrectly
<diddledan> my output with additional ifconfig and brctl show as extra info: http://paste.ubuntu.com/23169433/
<sergiusens> akash try snapcraft 2.17 (if you can from the master repo). It is in the process of being released.
<akash> sergiusens: thanks can you point me at where/how to get it for ubuntu 16.04, ill give it a shot
<sergiusens> akash f you are on 16.04; eiter wait for it to be released and it will show up as an update or git clone https://github.com/snapcore/snapcraft.git and look at the .md files in there
<zyga> tyhicks: asdasdaasdasda
<tyhicks> ?
<mup> PR snapd#1892 closed: snap,store: capture newest digest from the store, make it DownloadInfo only <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1892>
<zyga> tyhicks: sorry :)
<zyga> keyboard stuck
<tyhicks> heh :)
<zyga> tyhicks: would you mind lookign at https://github.com/snapcore/snap-confine/pull/135
<mup> PR snap-confine#135: Add snap-discard-ns <Created by zyga> <https://github.com/snapcore/snap-confine/pull/135>
<zyga> it's pretty short
<zyga> tyhicks: and it will unblock another pull request that actually enables this feature
<zyga> tyhicks: note, unlike snap-confine, snap-discard-ns is not setuid root
<tyhicks> zyga: looking
<mup> PR snapd#1893 opened: Remove symlinks for systemd units on apt-get purge <Created by stolowski> <https://github.com/snapcore/snapd/pull/1893>
<bzoltan> ogra_:  is there a way to create multi arch snaps?
<ogra_> bzoltan, you dont really want that ... just create one snap per arch with the same name and upload them
<bzoltan> ogra_: Okey, thanks
<ogra_> else you end up with a gigantic thing that shiops cruft you will never use
 * bzoltan likes poor i386 users
<ogra_> bzoltan, https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core ...
<ogra_> take a look at how we do that for ubuntu-core
<bzoltan> ogra_:  thanks, that is useful!
<zyga> tyhicks: thanks for the review, currently only snap-confine creates /run/snapd/
<tyhicks> zyga: ah, sc_initialize_ns_groups() creates it, doesn't it?
<zyga> tyhicks: correct
<tyhicks> zyga: nice - we're all good then
<tyhicks> zyga: I'll follow up in the PR
<zyga> tyhicks: thanks :)
<akash> sergiusens: thank you very much for the pointer that worked!! At least the app seems to have fired up in devmode, ill see if it functions is strict as well. In devmode it fires up on port 8123 just fine.
<mup> PR snapd#1894 opened: README.md: tweaks to the spread+qemu instructions <Created by chipaca> <https://github.com/snapcore/snapd/pull/1894>
<diddledan> I have no idea what I did wrong, but I'm getting "error: cannot find signatures with metadata for snap" when installing a snap I've just created
<mup> PR snapd#1894 closed: README.md: tweaks to the spread+qemu instructions <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1894>
<sergiusens> popey the readme for ptex mentions this: make prefix=$PWD/install
<sergiusens> in make-parameters you might want to add prefix=$SNAPCRAFT_PART_INSTALL
<diddledan> oh we're not allowed to install things we make without telling it we really really really want to install a thing we made (--force-dangerous)... o_O
 * diddledan pinkyswears that his snap won't be naughty
<diddledan> right. so corebird needs some new schemas installed into gsettings or it fails to start. how do I go about telling my snap about these settings?
<diddledan> ref: (corebird:26868): GLib-GIO-ERROR **: Settings schema 'org.baedert.corebird' is not installed
<seb128> diddledan, where is that schemas getting installed in your snap?
<diddledan> seb128: my point is I don't know how to install the settings, hence why they're not installed
<popey> sergiusens: will try, thanks
<seb128> diddledan, usually the upstream make install does that for you
<diddledan> seb128: the make install might have put the file at /snap/corebird/current/share/glib-2.0/schemas/org.baedert.corebird.gschema.xml ??
<diddledan> otherwise it's not installed at all
<diddledan> I think this is the file that should be somewhere: https://github.com/baedert/corebird/blob/master/corebird.gresource.xml
<zyga> tyhicks: this enables namespace sharing https://github.com/snapcore/snap-confine/pull/134/files
<mup> PR snap-confine#134:  Enable snap-confine namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/134>
<zyga> tyhicks: there's one thing that jdstrand suggested that I change (use change profile instead of change hat)
<zyga> tyhicks: I'm worried about interactions between device cgroup and the ns sharing feature though
<zyga> tyhicks, jdstrand: ^^ your review would be appreciated
<mhall119> zyga: what is the system-wide writable directory for a snap?
<popey> sergiusens: :( still does it even with that set
<zyga> mhall119: /var/snap/$SNAP_NAME/{common,$SNAP_REVISION} AFAIR
<zyga> tyhicks: and for you specifically; I could really use some insight into https://github.com/snapcore/snap-confine/pull/133
<mup> PR snap-confine#133: Adjust apparmor policy for compatibility with snap-exec <Blocked> <Created by zyga> <https://github.com/snapcore/snap-confine/pull/133>
<mhall119> zyga: that's $SNAP_DATA right?
<zyga> mhall119: that's correct
<seb128> diddledan, that seems about right, you might hit bug #1590831 if you use prefix=/usr and the desktop launcher it should work
<mup> Bug #1590831: having prefix='' by default is non standard and confusing <Snapcraft:New> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590831>
<mhall119> zyga: I'm getting some permission errors:
<mhall119> mhall@mhall-thinkpad:~/projects/Ubuntu/snaps/tomcat/snap$ snap run tomcat
<mhall119> cp: cannot create regular file '/var/snap/tomcat/x1/conf/jaspic-providers.xsd': Permission denied
<mhall119> cp: cannot create regular file '/var/snap/tomcat/x1/conf/catalina.policy': Permission denied
<mhall119> trying to copy files from $SNAP to $SNAP_DATA
<mhall119> what's odd is that it creates the 'conf' directory just fine, but as user 'root' and then fails to copy files into it
<zyga> mhall119: that directory is only designed for stuff that runs as root
<zyga> mhall119: it's not writable by all users
<diddledan> seb128: yeah that bug report does look like it might be relevant, thanks
<zyga> mhall119: to "services"
<mhall119> zyga: should webservices like Tomcat use that or use $SNAP_USER_DATA?
<seb128> diddledan, yw, comment on it maybe more people hitting the problem is going to convince the snapcraft team that it's an issue
<mhall119> it will eventually be running as a daemon
<mhall119> also, why does it allow creating a directory but not files?
<zyga> mhall119: if it's a service it runs as root and it cannot use $SNAP_USER_DATA, it must use $SNAP_DATA
<zyga> stgraber: FYI: https://github.com/snapcore/snap-confine/pull/134
<mup> PR snap-confine#134:  Enable snap-confine namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/134>
<zyga> stgraber: this enables namespace sharing
<zyga> stgraber: I hope it lands today
<sergiusens> popey as soon as I defeat my headache in a mental battle with my nemesis (myself) I will help you
<tyhicks> zyga: I'll look at the 'unsafe' change breaking tests and jdstrand will look at the PR where the ns sharing functions are put to use
<zyga> thank you, both of you!
<zyga> 1.0.41 is super close to release, those are the last two things
<popey> sergiusens: heh :) No worries.
<diddledan> seb128: that looks to have been that particular issue. now I'm onto dbus :-)
<seb128> great
<seb128> what dbus issue do you have?
<diddledan> GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.99" is not allowed to own the service "org.baedert.corebird" due to AppArmor policy
<seb128> that's currently being discussed on the list/being worked on
<popey> sergiusens: when you're around http://paste.ubuntu.com/23169756/ http://paste.ubuntu.com/23169757/
<seb128> you need to use devmode as a workaround meanwhile
<diddledan> aha
<diddledan> is it this thread?: Accessing dbus (KDE Application) (https://lists.ubuntu.com/archives/snapcraft/2016-September/001070.html)
<sergiusens> popey the Makefile seems like a wrapper for cmake, care to ty cmake instead?
<popey> sergiusens: yeah, it's a bit messy
<popey> i *think* i tried that, but will try again
<sergiusens> popey just tried, it worked fine
<sergiusens> well, built fine
<popey> sergiusens: thanks
<mhall119> zyga: http://paste.ubuntu.com/23169779/ is the journalctl output after trying to start my daemon snap service
<mhall119> any idea why it would be getting a permission denied on accessing it's own files?
<zyga> mhall119: can you look at apparmor denials please, it looks like the problem is $SNAP/conf
 * zyga goes to swap GPUs to test without nvidia 
<seb128> diddledan, yes
<kgunn> ok, i feel kinda dumb, i used to login to my ubuntu-core with login ubuntu/pswd ubuntu, i just created an image, and it says that's wrong...
<kgunn> did something change?
<seb128> kgunn, yes, they removed the static user, need to configure it on first boot now
<kgunn> ta
<seb128> kgunn, which means you need a serial access or a screen+keyboard
<mhall119> zyga: http://paste.ubuntu.com/23169941/
<mhall119> can I not run the cp command from my snap?
<zyga> mhall119: looking
<zyga> mhall119: cp is permitted by the default policy
<zyga> mhall119: this is a problem: 619:Sep 12 12:12:08 mhall-thinkpad kernel: [1078687.546925] audit: type=1400 audit(1473696728.358:458747): apparmor="DENIED" operation="capable" profile="snap.tomcat.tomcat" pid=18756 comm="run.sh" capability=1  capname="dac_override"
<mhall119> zyga: http://paste.ubuntu.com/23169959/ is my snap.yaml http://paste.ubuntu.com/23169799/ is my run.sh
<zyga> mhall119: as is this 638:Sep 12 12:12:08 mhall-thinkpad kernel: [1078688.048110] audit: type=1400 audit(1473696728.862:458748): apparmor="DENIED" operation="capable" profile="snap.tomcat.tomcat" pid=18769 comm="mkdir" capability=1  capname="dac_override"
<zyga> mhall119: looks good
<mhall119> zyga: note it works when I use $SNAP_USER_DATA but not $SNAP_DATA
<zyga> mhall119: interesting
<zyga> mhall119: I think the problem is that snap-confine is not creating $SNAP_DATA, it only creates snap-user-data
<zyga> er $SNAP_USER_DATA
<zyga> mhall119: what happens if you manually mkdir -p /var/snap/tomcat/{x1,common}
<zyga> mhall119: keep using $SNAP_DATA please
<mhall119> /var/snap/tomcat/x1/ and /var/snap/tomcat/common/ are both created when I "snap try ./prime"
<zyga> mhall119: ok
<zyga> mhall119: do you have any idea why tomcat might want dac_override capability
<zyga> mhall119: (we're not granting those!)
<mhall119> I don't even know what that is
<zyga> mhall119: and check if you have anything owned by root in $HOME/snap
<zyga> mhall119: you can ignore file permissions
<mhall119> zyga: my user's home?
<zyga> mhall119: yes
<mhall119> one, but it's not tomcat
<zyga> mhall119: is it /home/$LOGNAME/snap?
<mhall119> drwxr-xr-x   3 root  root  4.0K Aug 25 16:49 couchbase-beacon
<zyga> hm
<mhall119> $LOGNAME?
<ogra_> pitti, so i'm currently switching ubuntu-core from task to metapackage and notice that we still ship systemd-shim in the images ... is that still necessary ?
<zyga> mhall119: env
<zyga> mhall119: env | grep LOGNAME
<mhall119> ah, yes it is
<jdstrand> see CAP_DAC_OVERRIDE in 'man 7 capabilities'
<zyga> mhall119: does it work in devmode?
<mhall119> zyga: the cp that is failing is from the run.sh I created, before Tomcat's code is even started
<jdstrand> you typically see this when a root process is trying to copy files to a user-owned directory that doesn't allow 'other' writes
<zyga> ah, interesting
<zyga> mhall119: well, your run.sh should use $SNAP_DATA because it is a service
<mhall119> zyga: appears to run with --devmode
<zyga> mhall119: (in the pastebin above it uses $SNAP_USER_DATA)
<zyga> mhall119: change that and try again
<mhall119> zyga: the current version is http://paste.ubuntu.com/23169984/ which usees ${SNAP_DATA}
<zyga> mhall119: what happens when you run that version?
<mhall119> it runs with --devmode, but doesn't look like it copies the files to $SNAP_DATA
<zyga> mhall119: can you try without devmode and look at all the denials please
<mhall119> zyga: http://paste.ubuntu.com/23170006/ is from syslog without --devmode
<zyga> I think I know
<zyga> jdstrand: this probably fails because snap try and the fact that all of the files are owned by the user, not by root
<zyga> mhall119: can you try to build a real snap, remove the one with try and install the real one without devmode
<mhall119> yup, snapping it now
<zyga> if true this would imply that we need to do some tweaks to try
<mhall119> zyga: indeed it works this way, so 'try' is to blame
<zyga> mhall119: cool, can you please report a bug on snap try and tag it with snapd-interface
<zyga> mhall119: I don't have a solution in my head but perhaps there are ways to address this
<mhall119> zyga: there is still one apparmor denial http://paste.ubuntu.com/23170012/
<zyga> jdstrand: we might use a different base template for trymode snaps
<zyga> mhall119: we don't allow to run /usr/bin/tty
<zyga> mhall119: please report that as a separate bug
<mhall119> ok
<zyga> mhall119: alternatively bundle tty in your snap
<jdstrand> mhall119: I'll add /usr/bin/tty
<jdstrand> I'd really rather not use a different base template if we can at all help it
<kgunn> just checking, haven't tested, but in latest 16 ubuntu-core, should i still be expected to manually connect autoconnections?
<jdstrand> that would be confusing for triaging
<jdstrand> and diagnosing problems
<jdstrand> snap try should probably copy all the files and chown root:root all of them, just like how snapcraft snap uses -all-root
<elopio> lool: can we not merge the snapcraft revert yet? In your branch you are building for amd64 only anyway.
<elopio> if we solve the phantomjs thing, and do the download on pull, we could build in launchpad.
<lool> elopio: crap I committed that? that's a mistake
<lool> elopio: I dont want to fight phantomjs for each architecture
<ogra_> elopio, FYI, the linux-generic-bbb package is now approved and available in the store in the edge channel
<elopio> ogra_: \o/
<ogra_> next is gadget :)
<elopio> I left mine at home, sadly. I will try it on friday.
<ogra_> if i ever manage to get done with this switch from task to metapackage in ubuntu-core :/
<ogra_> such a pain ... why did we ever decide to not use metapackages but tasks
<mup> Bug #1622639 opened: Snap access to /dev/uinput <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1622639>
<lool> elopio: I've reverted the build.sh arch changes; that was just for local builds
<lool> elopio: I've pushed a rebased version
<elopio> lool: please also run go fmt
<lool> elopio: hmm it's a no-op
<lool> elopio: ah nevermind
<elopio> weird, the travis static check is failing.
<lool> elopio: ok fixed; was just a newline  :-(
<mup> Bug #1622685 opened: snap try fails on user ownership of files in the testing directory <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1622685>
<mhall119> woohoo! my tomcat snap is working
<mhall119> thanks for all the help zyga
<kyrofa> mhall119, who's in charge of the snapcraft.io text?
<kyrofa> And can I log bugs against it?
<zyga> kyrofa: it's a github project
<kyrofa> zyga, are bugs handled over there, then?
<zyga> kyrofa: don't remember which but I'd love to know
<kyrofa> Yeah okay, back to you mhall119 ;)
<zyga> mhall119: my pleasure thank you for doing the work :)
<kyrofa> davidcalle, you might know as well?
<mhall119> kyrofa: thibautr_ is I think
<mhall119> zyga: is there a way to do one-time setup on install?
<mhall119> or a snap
<mhall119> s/or/of/
<mhall119> basically I need to copy some files from $SNAP to $SNAP_DATA for tomcat to work, but it only needs to be done once
<thibautr_> Zyga bugs you can raise on snapcraft.io itaelf
<kyrofa> thibautr_, ah, the "report a bug on this site"?
<thibautr_> davidcalle can point you to the github repo for the doc otherwise
<thibautr_> That's the one
<thibautr_> I would if I wasn't on my mobile phone ð
<kyrofa> thibautr_, excellent, thank you!
<lool> elopio: I pushed a dependencies update
<zyga> mhall119: not at present
<lool> elopio: there seems to be another static test error with Init(); I dont have time to look into this tonight
<lool> elopio: also, coverage is down but that's because I removed a lot of code :-)
<mhall119> zyga: ok
<lool> elopio: keeping in mind the current version doesn't work at all, could we force this in and fix the remaining issues as an update?
<ogra_> cprov, hmm, what else beyond grade chnaged in the store recently ... if i try to install ubuntu core from edge (590) i get offered the version from beta (524) ...
<beowulf> hi, what is the app dev email list address for snappy?
<ogra_> there seems to be no way to actually get anything newer than what was released to beta
<cprov> ogra_: nothing specific, but let me check the publishing history.
<ogra_> bug 1621843 seems related
<mup> Bug #1621843: no way to switch ubuntu-core to --edge on images <Snappy:New> <https://launchpad.net/bugs/1621843>
<beowulf> can anyone tell me which plug to use for apparmor denials for "trace" http://pastebin.com/4RfBgPkp
<ogra_> (i thought it was an image issue ... but i noted that i cant even build any images from edge ... all ubuntu-image gets when setting -c edge is 524)
<ogra_> beowulf, snapcraft@lists.snapcraft.io is the ML address
<beowulf> ogra_: thanks
<jdstrand> beowulf: trace denial with ps is harmless. seems like you want to use 'system-observe' which will allow ps and silence the denial
<cprov> ogra_: 590 (amd64) should be published on edge, let me dig a little I have a suspicious (it's not related to new changes, but instead with publishing snaps with huge revisions history)
<beowulf> jdstrand: thanks
<ogra_> cprov, thanks fo checking !
<jdstrand> beowulf: seems you also want 'network'
<jdstrand> based on the resolvconf denial
<cprov> ogra_: can you please check if amd64 is working now ?
<ogra_> trying ... that takes a while though
<ogra_> hmm, well, now ubuntu-image exploded ... so i guess something store-side changed :)
<ogra_> cprov, sorry, i seem to get something else now but since ubuntu-image as well as ubuntu-device-flash explode now it is hard to tell which version i get ... none of them print it
<cprov> ogra_: np, amd64 should be ok now, r590. I will debug further ..
<ogra_> yeah, sudo snap install ubuntu-core --edge gets me 590 inside an old image now
<ogra_> seems to work for amd64
<ogra_> arm64 and armhf still dont though
<cprov> ogra_: all fixed now.
<ogra_> cprov, \o/
<ogra_> i get fresh snaps
<cprov> ogra_: sorry for the trouble, we will figure out how to prevent this hiccup :-/
<ogra_> cprov, i guess we can close 1621843 then :)
<cprov> ogra_: no, I will reassign it to sca, it is still a bug
<ogra_> ogra@dragonboard:~$ snap list ubuntu-core
<ogra_> Name         Version  Rev  Developer  Notes
<ogra_> ubuntu-core  16.04.1  593  canonical  -
<ogra_> yay
<ogra_> and it seems my hackery didnt break ubuntu-core :)
<ogra_> and armhf works too
<ogra_> ogra@pi3:~$ snap list ubuntu-core
<ogra_> Name         Version  Rev  Developer  Notes
<ogra_> ubuntu-core  16.04.1  591  canonical  -
<mup> Bug #1621843 changed: no way to switch ubuntu-core to --edge on images <Software Center Agent:Triaged by cprov> <https://launchpad.net/bugs/1621843>
<mup> PR snapd#1895 opened: store: refactor auth/refresh tests <Created by matiasb> <https://github.com/snapcore/snapd/pull/1895>
<ogra_> slangasek, so i dropped grub now ... (and had switch from task to metapackage etc etc ... horrid day, dont ask...) i note that /boot/grub/unicode.pf2 isnt there anymore with dropping of the binaries (along with /boot/grub for which i just uploaded a livecd-rootfs fix ... do you know if thats harmful ? and do we need to ship that fuile in the gadget then ?
<ogra_> *and had *to*
<jdstrand> zyga: hey, does 'retest this please' still work with snapd?
<pedronis> jdstrand: no, we have only travis now
<pedronis> that command was for the bot managed stuff
<jdstrand> I see
<jdstrand> ok, thanks
<elopio> lool: I'm grumpy everytime we land something with failing tests. Do we need this out today for some reason?
<nsg> Hello, started to play with snapcraft a day ago and I just packaged minecraft "just-for-fun" ... what do think, is is a good idea to share it? No software is bundled, it is just a download script. What do think, is a "minecraft-nsg" snap okay?
<nsg> (bash script that downloads the jar (launcher) and Oracle JDK, on the users computer)
<kyrofa> nsg, so it's a minecraft installer, not minecraft
<kyrofa> ?
<nsg> correct
<kyrofa> nsg, no downside to sharing, though I'm curious: why not just package minecraft itself?
<nsg> or, possible a oracle jdk and minecraft installer :)
<nsg> I do not think we are allowed to distribute the software, or?
<ogra_> slangasek, oh, i see where that file comes from (grub-common) ... i added code to livecd-rootfs that copies it in place now ... so ignore the above
<nsg> I was thinking, consider that oracle likes you to accept the license and that I have worked around that problem to download it with wget ... maybe some type of "do you accept the oracle license dialog" is needed? So the installing user has to agree.
<kyrofa> nsg, ah, of course
<kyrofa> nsg, yeah I'm not qualified to answer those questions at all :)
<kyrofa> Now I see where your original question is coming from
<kyrofa> In which case my real answer is: no idea :P
<nsg> hehe
<elopio> lool: I will land this one: https://github.com/snapcore/snapweb/pull/56
<mup> PR snapweb#56: Revert snapcraft <Created by elopio> <https://github.com/snapcore/snapweb/pull/56>
<elopio> then your diff will be smaller, and I removed one of the tests that were failing for you.
<jdstrand> zyga: hey, it you're still around, can you discuss the motivation behind https://github.com/snapcore/snapd/pull/1848?
<mup> PR snapd#1848: snap: ensure that plug and slot names are unique <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1848>
<jdstrand> zyga: it breaks the ongoing docker PR
<jdstrand> zyga: see https://github.com/snapcore/snapd/pull/1848#issuecomment-246482819
<mup> PR snapd#1848: snap: ensure that plug and slot names are unique <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1848>
<popey> sergiusens: why can I not do "cleanbuild" _and_ "--no-parallel-build" ?
<sergiusens> popey that's not supported, probably a bug, but --no-parallel-build is deprecated in favor of a per part switch to disable it
<popey> oh okay
<popey> that'll do :)
<qengho> What's the deal with X fonts from snaps these days?
<qengho> Including fonts in snap packages seems crazy.
<qengho> (Not to mention, the MSFT Core Fonts installer package doesn't get to run its postinst downloader, in a staged package.)
<sergiusens> popey add `disable-parallel: on` to the part that needs parallel disabled
<popey> ta
<sergiusens> qengho iirc zyga was working on an interface for that
<nsg> hum, I'm missing something? ... "sha256sum $SNAP_USER_DATA/my.file" is blocked by apparmor.
<nsg> ... name="/usr/bin/sha256sum" pid=3910 comm="launch" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<mwhudson> ogra_: hey, did the wifi stuff work?
<ogra_> mwhudson, dunno yet ... the woorld exploded when i trie to remove grub from x86 and found out that we only use tasks ... so i had to port everything to use a metapackage ... still dealing with the fallout here
<mwhudson> ogra_: no rest for the wicked
<ogra_> heh
<nsg> interesting, md5sum works but sha256sum and sha1sum was blocked by apparmor.
<jdstrand> nsg: that is just an omission. I've noted it and will get it fixed
<nsg> ah, thx!
<jdstrand> I'm seriously surprised that isn't there...
<nsg> got a little confused there for a while, assumed I did someting wrong :)
<jdstrand> anyhoo, I'll fix it
<jdstrand> nsg: in the meantime, you can just include them in your snap
<nsg> I will use good-old-broken md5 while I wait :)
<nsg> ah, that's a idea!
<jdstrand> nsg: I'll make sure it gets committed this week
<jdstrand> to trunk
<jdstrand> it'll float into Ubuntu or the distro of your choice some time after that
<nsg> sounds good, looking forward to that
<lool> jdstrand: hey I wanted to ask about the kernel_module_control interface; wouldn't that be enough for docker?
<lool> elopio: your pull request is not enough to get it to start on boot
<jdstrand> lool: that is an extremely privileged interface. yes, it would work, but we'd want to remove it immediately before GA. note, JamieBennett said in the bug the kernel module backend would be done for GA
<ogra_> oh man !
 * ogra_ wasted 2/3 of his workday because he didnt notice thet the ubuntu-image he used was the deb version 
<elopio> lool: I know. But now it will be easier to understand why yours is failing the unit tests
<ogra_> cprov, hmm, could you do that magic again ? i'm now stuck at 590 which had a bug despite there being 594 being published
<cprov> ogra_: sure, one sec
<cprov> ogra_: fixed
 * ogra_ hugs cprov 
<cprov> ogra_: ftr, it's just a matter of scrolling down the revision page and hit 'unpublish' then 'publish'. God, this is embarrassing and has to be fixed asap.
<ogra_> cprov, oh, if i know that then thats no issue for me to do that myself ...
<popey> hm, cleanbuild is barfing with a bizarre error
<popey> http://paste.ubuntu.com/23171253/
<popey> "error: not found (not a fingerprint, partial fingerprint (first 12 chars) or valid alias)
<popey> found https://github.com/lxc/lxd/issues/2094 from stgraber which indicates the error message *used* to be even more incomprehensible than it is now :)
<popey> sergiusens: is ^ this a snapcraft bug, not interpreting lxc errors nicely?
<stgraber> popey: any chance you can have it show you what it passed to "lxc launch"?
<SamYaple> hey guys. soooo i ran into a pretty funny problem https://github.com/snapcore/snapcraft/pull/793
<mup> PR snapcraft#793: Unify python plugin <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/793>
<popey> stgraber: no idea.
<SamYaple> total coverage has decreased in that commit.... but all the files are 100% converage'd
<qengho> Ick. I think a system snap broke my pi3. I think it was running pi2 version. Still sad.
<SamYaple> https://coveralls.io/builds/7852962
<SamYaple> look. all the changed files are 100% covered, but te total percentage droped :)
<popey> stgraber: repeatedly running ps shows me "lxc remote add pro-joey https://images.linuxcontainers.org:8443"
<qengho> On boot, I got a newfangled green and purple text-based configuration interface, and it doesn't make it past DHCPv4.
<popey> stgraber: happy to share my IP with you if you can see the other end logs
<stgraber> popey: well, I could until last week when that was moved to IS infrastructure :)
<popey> haha
<popey> bummer
<ogra_> qengho, ogt a network cable plugged in ?
<popey> stgraber: caught it... lxc launch -e chief-lynx:ubuntu/xenial/amd64 snapcraft-firmly-fond-ram
<ogra_> qengho, the screen is the new config UI ... now that the ubuntu user is gone ...
<ogra_> qengho, flowers go to mwhudson :)
<popey> stgraber: so it does a remote add then a launch with that name
<stgraber> popey: hmm, seems to be working fine here though
<stgraber> popey: so yeah, it seems to be adding a new remote with a random name using images.linuxcontainers.org:8443 and then fetch the ubuntu/xenial/amd64 image from it, but AFAICT this all works fine and that's a valid image name
<stgraber> popey: does it reliably fail for you?
<popey> yes
<popey> was working fine an hour or so ago
<stgraber> popey: oh, fun, looks like the uk server is busted somehow
<stgraber> stgraber@dakara:~$ lxc image info uk-images:ubuntu/xenial/amd64
<stgraber> error: not found (not a fingerprint, partial fingerprint (first 12 chars) or valid alias)
<stgraber> stgraber@dakara:~$ lxc image info us-images:ubuntu/xenial/amd64
<stgraber> Fingerprint: f18647f5280c3ca50ddec7a112bb4794b6b53f73d05c8c0a63316b77689a4249
<popey> \o/
<ogra_> must be because IS wears gloves all day ... they dont leave fingerprints
<ogra_> :P
<popey> stgraber: I do need to file an RT or something?
<stgraber> popey: ok, so I'm not 100% sure whether it's an actual problem on the IS side or if we just got very unlucky and they somehow rsynced right at the time where the aliases weren't on the disk on my end
<qengho> ogra_: I did have a cabling problem. My son unplugged the hub.
<ogra_> hah
<qengho> All better now.
<popey> still reliably failing here
 * qengho hangs head in shame.
<stgraber> popey: so I'm waiting for the next rsync from the UK frontend, then we can re-test, if it's still busted, it'll be an RT, if not, it'll be a bug on my end to reduce the update window even more
<popey> ok
<stgraber> popey: yeah, they sync once an hour, let me figure out when exactly
<qengho> That automatic user generation and ssh keying is BLOWING MY MIND.
<stgraber> popey: yup, logs on my end does show a lot of rsync errors from that UK server, next sync in 19 minutes, that will hopefully fix things
<popey> ok
<popey> thanks stgraber
<popey> thanks stgraber
<popey> oops
<ogra_> i wonder if there is something in general with the DC
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/10743027 ...
<ogra_> "Syncing the system clock with the buildd NTP service..."
<ogra_> since 12 min
<cjwatson> Other builders have proceeded since then.
<ogra_> ah, it moves now
<stgraber> popey: try now?
<popey> stgraber: that's better :)
<popey> thanks
<stgraber> cool
<stgraber> will have to see how to further shrink the race window, but it's below 1s already... best would be for the mirrors to be push mirrors instead of them pulling from me
<popey> I'll leave that with you then :)
<mup> Bug #1622782 opened: 'snap install' return code unhelpful <canonical-is> <Snappy:New> <https://launchpad.net/bugs/1622782>
#snappy 2016-09-13
<mwhudson> hm
<mwhudson> i guess i need to learn how to use ubuntu-image now then?
 * mwhudson has lunch instead
<mwhudson> how do i get ubuntu-image to use a code snap i just made?
<sergiusens> stgraber popey fwiw I have a pending task to move to your built-in `ubuntu:` shortcuts
<sergiusens> which is the only reason I went with random names, to not conflict with any image repo that might have been pre-existing
<deadlock> Hello, guys! I'm trying to run the snap on openSUSE Tumbleweed, but the daemon doesn't starts. Service status [# systemctl status snapd]: http://pastebin.com/cDtiHqVd Anybody knows how solve it?
<slangasek> ogra_: fonts, you're not making extensive use of font support and there's a built-in and honestly I'm not sure why we do what we do currently with grub menus on the snappy devices which is definitely different from the designed classic experience
<slangasek> ogra_: should be no problem losing unicode.pf2 - but anyway, snapd will need to depend on grub-common (I've filed a bug for this) which will pull some bits back into the image
<mwhudson> adsadadsa das
 * mwhudson stabs agetty with a spoon
<mwhudson> or something
<mwhudson> maybe UNIX
<mwhudson> why the heck is agetty leaving ICRNL off on the serial line?
<mwhudson> and why am i caring about this in 2016
<mup> PR snapcraft#794 opened: Improve lifecycle execution of steps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/794>
<pitti> ogra_: eww, no; kill shim with fire, please
<pitti> ogra_: I removed shim from yakkety; it was still necessary in xenial for upgrades from trusty
<mup> PR snapd#1893 closed: packaging: make sure debhelper-generated snippet is invoked on postrm <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1893>
<mup> PR snapd#1889 closed: tests: add yakkety test host <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1889>
<dholbach> hey hey
 * mwhudson waves
<liuxg> camera is not working on qualcom snapdragon 410c board. is there any way to enable it? I am now building a demo for a show.
<morphis> mvo, ogra_: are there any good options to debug when I can't configure a ethernet connection via console-conf and serial access isn't available?
<ogra_> i assume attaching a screen is also impossible ?
<liuxg> mvo, is camera working on 410c board? thanks I followed the example project at https://github.com/snapcore/snapcraft/tree/master/demos/webcam-webui, it is not working. thanks
<ogra_> liuxg, if you use a camera that has a supported module it should surely work
<abeato> mvo, ogra_ does anybody know how to give more permissions to enable dbus services? it looks like I cannot start a dbus service using dbus-launch in a script in ubuntu core?
<ogra_> abeato, do you ship dbus-launch ?
<liuxg> ogra_, what is a supported module? My current camera worked with pi2 and pi3 well, but it does not work with the 410c board.
<ogra_> and do you make it create sockets inside the confined space ?
<abeato> ogra_, yes
<abeato> yes
<ogra_> hmm, then it should work i imagine ... whats the error
<abeato> gimme permissions :p
<ogra_> well, syslog/dmesg journalctl ... etc
<abeato> ECONNREFUSED
<abeato> dmesg looks fine
<ogra_> no apparmor denial ?
<abeato> no
<ogra_> liuxg, dunno,. watch dmesg while you plug it in (dmesg -w)
<ogra_> it should tell you if it finds a driver
<liuxg> ogra_, http://paste.ubuntu.com/23172681/, is this the correct image?
<ogra_> liuxg, yeah, that sounds fine ... so it loads a module (uvcvideo) and also creates an input device for the button
<liuxg> ogra_, but it does not get the picture while I run the sample app. on the pi2 and pi3 device, the same camera works fine. it is a little weired.
<ogra_> liuxg, and you connected the interface ?
<ogra_> or ... rather ... is the interface connected ?
<liuxg> ogra_, on the 410c, there is no "camera" interface at all. I used devmode
<liuxg> ogra_, this is how it looks like http://paste.ubuntu.com/23172688/
<ogra_> zyga, ^^^ in which case would ubuntu-core on a device offer a camera interface ? does the device need to exist on startup ?
<liuxg> ogra_, maybe the camera service is not up yet in the ubuntu core?
<ogra_> liuxg, did you try rebooting with the camer plugged in ?
<ogra_> might be that the video device needs to exist when snapd start
<ogra_> s
<liuxg> ogra_, yes, I did it. anyway, I changed another camera and reboot to see what happens.
<seb128> zyga, hey, is bug #1622678 something for you?
<mup> Bug #1622678: /etc/profile.d/snapd.sh is overwriting PATH and XDG_DATA_DIRS <packaging> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1622678>
<seb128> zyga, it's a bug in the fedora package it seems
<liuxg> ogra_, , thanks. at your suggestion, after I changed one camera, and it worked. Interestly, the camera worked with p2 and pi3, but it does not work with 410c. it does not need to have driver at all.
<ogra_> liuxg, i guess there are bits missing in the dragonboard kernel to make it fully work ... file a bug against the linux-snapdragon package ... and attach the pastebin with the dmesg output
<ogra_> (the stuff you captured whenplugging in)
<liuxg> ogra_, could you please give me link for reporting the bug?
<morphis> ogra_, mvo: how are you guys debugging problems on Ubuntu Core and a console-conf which does not let you into the system and network configuration fails?
<ogra_> morphis, try asking mwhudson :) i havent really debugged console-conf issues apart from complaining to him :)
<morphis> hah :-)
<mwhudson> morphis: systemd debug shell, if you're in kvm
<morphis> mwhudson: I am not
<morphis> being on a device
<mwhudson> if you are stuck on serial, it's hard :/
<morphis> there is no login and no user :-)
<mwhudson> well indeed
<mwhudson> morphis: pull sd card, look at logs on your desktop?
<mwhudson> if it's on board flash, even less fun
<morphis> mwhudson: I have a serial console, so I have the whole log but nothing interesting in it so far
<mwhudson> morphis: console-conf logs stuff to /var/log/console-conf/something.log
<liuxg> ogra_, mvo, I have reported a bug for it https://bugs.launchpad.net/ubuntu/+source/linux-snapdragon/+bug/1622909
<mup> Bug #1622909: Camera is not fully working on snapdragon 410c board <linux-snapdragon (Ubuntu):New> <https://launchpad.net/bugs/1622909>
<ogra_> liuxg, right, thats for ppisati
<morphis> mwhudson: see PM
<liuxg> ogra_, alrightt :)
<ogra_> mwhudson, we need some kind of kernel/bootloader cmdline option that allows debugging i think
<ogra_> else porters wont get very far
<ogra_> some root shell or so
<mwhudson> ogra_: has to be something done at image creation time i think?
<mwhudson> or it's a bit of a security open door?
<ogra_> mwhudson, ??
<ogra_> what could i do at image creation time that makes console-conf give me a root shell instead of firing up the UI
<mwhudson> uh wait
<ogra_> i mean some internal path that can be taken in the code if there is a certain kernel cmdline option
<ogra_> since that comes from the gadget you would need a special debug gadget build
<mwhudson> ah ok
<ogra_> the assertions should keep you safe from someone abusing it then
<mwhudson> not something that you get at at boot time
<ogra_> heh, not a bootloader selection like we have on desktop, no :)
<ogra_> it is fine to make that a tad complex as long as we offer debug abilities at all :)
<zyga> ogra_: camera interface is created unconditionally for now
<ogra_> morphis, i think thats worth a ML discussion to get input from all deciders on that topic
<morphis> ogra_: absolutely
<ogra_> we dont really have a plan for people doing bringup ... currently its all just "lock down as much as possible"
<mwhudson> ogra_: i guess your best bet for now is to unsquashfs the core snap, chroot squashfs-root adduser ubuntu and remove the drop-in files that start console-conf
<ogra_> mwhudson, i doubt that will boot properly afterwards
<mwhudson> ogra_: why?
<ogra_> the snaps are signed ...
<morphis> yes
<morphis> you can resign them etc.
<mwhudson> ogra_: and make an image using UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 or whatever
<ogra_> we need something that gets put into writable from the initrd and that is understood by console-conf
<mwhudson> ogra_: i agree that's a better solution
<mwhudson> but not one that's going to arrive this evening :)
<zyga> seb128: yes, thank you
<seb128> zyga, yw!
<ogra_> consoleconf=rootshell cmdline option ... -> makes the wrapper script call a systemd debug shell instead of the UI ... or some such
<ogra_> mwhudson, yeah, i didnt mean today/night ... a proper implementation needs discussion and approval first ... i guess morphis needs to start a discussion on the ML describing the prob
 * mwhudson finds ConditionKernelCommandLine=
<ogra_> well, your wrapper is shell, isnt it ?
<morphis> ogra_, mwhudson: hm, I could bypass console-conf by creating the complete flag in /var and adding a user to extrausers
<mwhudson> yes
<mwhudson> morphis: ah yeah, that would work
<mwhudson> ogra_: something about starting a root shell makes me super paranoid, maybe i'm overdoing that
<ogra_>         for x in $(cat /proc/cmdline); do
<ogra_>             case "${x}" in
<ogra_>                 # new kernel/os snap vars
<ogra_>                 snappy_os=*)
<ogra_>                         snappy_os="${x#*=}"
<ogra_>                         ;;
<ogra_> ...
<ogra_> something like that should work
<ogra_> (+ esac and done ... )
<ogra_> mwhudson, that is why i want discussion and approval first ... including security people etc
<ogra_> wow
<ogra_> morphis, did you know that on big.Little the cores can have different cache sizes ... but the arch allows you to migrate processes aroudn from core to core ?
<ogra_> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/455679.html
<ogra_> how gross
<ogra_> slangasek, well, given that grub-common is 11MB installed i'd rather see us split grub-editenv into its own package and depend on that ... though long term mvo wants to include grub config handling into snapd itself like we do for uboot with uboot.go
<mwhudson> ogra_: hardware bug according to mark rutland on cross-distro
<ogra_> oh,. heh you are subscribed :)
<zyga> mwhudson: hey, still no update on collab-maint, still fighting some issues
<mwhudson> zyga: yay debian
<mwhudson> zyga: happy to pull anything you have off github or lp in the meantime
<zyga> mwhudson: I didn't do any downstream work lately, still doing upstream things
<pedronis> mwhudson: you can use a local snap  with ubuntu-image with --extra-snaps lOCAL.snap (it can even be one of those listed in the model assertion)
<pedronis> it will be installed unasserted
<mwhudson> pedronis: yeah i figured that out in the end
<mwhudson> (by reading the source)
<mvo> ogra_: its probably straightfowrad to write that code, might be quicker than to split the pkgs
<morphis> mwhudson: creating /var/lib/console-conf/complete should disable console-conf, right?
<ogra_> morphis, but wont give you any login ability
<mwhudson> morphis: yes
<ogra_> (you need a user too)
<morphis> ogra_: I've created a local user
<ogra_> ah
<ogra_> :)
<morphis> placing files manually in /var/lib/extrausers
<ogra_> that might soon be more complicated ... i'll have to at least add the adm group there as a default group ... so in the future you will have to add, not replace ...
<morphis> ogra_: so a >> rather than a > :-)
<ogra_> red: dont take for granted that these files are/stay empty
<ogra_> *read
<ogra_> yeah :)
<morphis> ogra_: empty passwords are not forbidden in the system?
<ogra_> we dont do anything special
<morphis> ok
<morphis> then a :: should just work
<mup> PR snapd#1856 closed: asserts: required account key name header <Created by emgee> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1856>
<ogra_> mvo, looks like i'm done with removing grub (i only actually kept the grub-editenv binary in place) ... amd64 went from 75+ to 66MB ! everything is still working fine (all tested)
 * ogra_ knows the above will make manik and zyga very happy :)
<mup> PR snapd#1896 opened: cmd/snap: match UX document for message when buying without login <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1896>
<liuxg> does anyone successful read data via bluetooth in ubuntu core? My snap app works well in the ubuntu classic (desktop and NUC). However, it does not work in the raspberry pi devices. thanks. I am not so sure whether the bluetooth device has been enabled or not.
<zyga> liuxg: I've seen successful data transfer with ubuntu-core and bluetooth stack from bluez but it was not on a rasberry pi
<liuxg> zyga, how did you set it up? did you have any special steps to set it up? For my case, https://github.com/liu-xiao-guo/sensortag-test, my project works well on classic ubuntu.
<zyga> liuxg: it was a while ago, we created a snap with bluez inside, the tests used bluetoothctl to pair and communicate with some devices
<zyga> liuxg: the goal was to automate bluetooth setup and testing
 * ogra_ guesses the kernel does not set u the device correctly yet on the pi 
<ogra_> s/u/up/
<liuxg> zyga, is it possibe to share me the source code? I have just packaged the bluetoothctl command.
<liuxg> zyga, when the command is run, I cannot input anything there. Is this a problem?
<zyga> liuxg: did you install the bluez snap?
<zyga> liuxg: I think all of that was public, I don't recall where it is
<zyga> liuxg: maybe ask morphis, I think he might know
<liuxg> zyga, the output is like http://imgur.com/a/3b7hr, yes, I have bluez inside the package.
<liuxg> zyga, this is my snapcraft.yaml file https://github.com/liu-xiao-guo/sensortag-test/blob/master/snapcraft.yaml
<liuxg> zyga, I packaged it into my package. I once installed the bluez package.
<liuxg> zyga, how did you make use of the bluez snap? I am currently using devmode to do that. I know bluez has a "bluez" slot.
<zyga> liuxg: do you use the bluez plug in your snap>
<zyga> liuxg: please report the mkdir error there, make sure to report which snap versio you had there
<liuxg> zyga, no, I am now using it . previously not.
<zyga> liuxg: check snapd sources as AFAIR we have a test that uses bluez plug/slot now
<zyga> liuxg: (or perhaps it was proposed recently)
<liuxg> zyga, do you mean here at https://github.com/snapcore/snapd/tree/master/tests/lib/snaps?
<zyga> liuxg: grep for the interface name in the tests directory
<liuxg> zyga, yes, thanks. I found it there in the main dir. I will take a look at it
<morphis> liuxg: you have to run bluetoothctl as root
<morphis> sudo /snap/bin/bluez.bluetoothctl
<morphis> the source of the snap is at https://code.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/bluez
<mup> PR snapcraft#795 opened: WIP: snap-build generation and pushing support <Created by caio1982> <https://github.com/snapcore/snapcraft/pull/795>
<liuxg> morphis, ok. thanks. how can I set it up? is the section in the doc enough? https://git.launchpad.net/~canonical-hwe-team/+git/artik_doc/tree/artik-guilde.txt
<morphis> liuxg: what do you mean by set it up?
<mup> PR snapd#1881 closed: cmd/snap: i18n option descriptions <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1881>
<mup> PR snapd#1880 closed: asserts: use gpg --fixed-list-mode to be compatible with both gpg1 and gpg2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1880>
<liuxg> morphis, how do I use bluetoothctl command? should I use it?
<morphis> liuxg: depends, what are you going to do?
<liuxg> morphis, ok. for my case, it scans (les) the sensortag. maybe not needed?
<morphis> liuxg: so you want to pair and connect the sensortag?
<liuxg> morphis, I think it does not need to pair, at least for the case of running on my desktop.
<liuxg> morphis, what is the correct command to make the connection? for my case, my app is "sensortag", and I have defined plug "bluez". snap connect bluez:sensortag bluez:service?
<morphis> snap connect sensortag:bluez bluez:service it is
<morphis> we just name the slot "service" on the bluez snap
<morphis> liuxg: next thing is, you can use bluetoothctl only as a user and not run it programmatically
<liuxg> morphis, then I think this document is a little bit confusing https://github.com/snapcore/snapd/blob/master/tests/main/interfaces-bluez/task.yaml
<zyga> tyhicks: should this happen?
<morphis> liuxg: why confusing?
<zyga>     signal (send) set=("int") peer=@LIBEXECDIR@//mount-namespace-capture-helper,
<zyga> Sep 13 14:47:48 autopkgtest kernel: audit: type=1400 audit(1473770868.312:13): apparmor="DENIED" operation="signal" profile="/usr/lib/snapd/snap-confine" pid=5532 comm="ubuntu-core-lau" requested_mask="send" denied_mask="send" signal=int peer="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper"
<liuxg> morphis, it says " bluez:client" instead of "client:bluez"
<zyga> tyhicks: ah, ignore me, I see the problem
<morphis> liuxg: as I said above, we're giving the plug and slot in the bluez snap names
<morphis> so we have
<morphis> plugs:
<morphis>   client:
<morphis>     interface: bluez
<morphis> and
<morphis> slots:
<morphis>    service:
<morphis>      interface: bluez
<morphis> and then this is totally correct :-)
<morphis> it ensures you connect just a single plug/slot within your snap
<morphis> otherwise you connect all which are using the interface bluez
<liuxg> morphis, ok.. I got it.  I thought " snap connect bluez:client bluez:service" was the command for use. I need to replace the "client" there.
<morphis> liuxg: in your case you need: snap connect sensortag:bluez bluez:service
<morphis> liuxg: next thing is, you can use bluetoothctl only as a user and not run it programmatically
<liuxg> morphis, got it. thanks
<morphis> liuxg: you can write a python client to talk to bluez, see https://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/ for examples
<morphis> liuxg: and https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc for the API documentation
<liuxg> morphis, thanks. I will read them
<morphis> liuxg: and regarding your question what you have to do to get the sensortag connected: discover it, pair it, connect it
<morphis> then all the GATT things become available
<liuxg> morphis, so, what should be command for use? bluetoothctl?
<mup> PR snapd#1897 opened: snap: run all tests with gpg2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/1897>
<liuxg> morphis, I still get some errors like http://paste.ubuntu.com/23173499/, I think the bluetooth is not set up correctly.
<morphis> liuxg: can you talk with bluez when using the bluetoothctl coming with the bluez snap?
<liuxg> morphis, strangely, in my place, when i run the command like "sudo /snap/bin/bluez.bluetoothctl", in the "[bluetooth]#" prmopt , I cannot type anything there.
<liuxg> morphis, no.
<ogra_>  is that a pi2 or a pi3 ?
<liuxg> morphis, ogra_, it is snapdragon device
<ogra_> note that we use the same kernel for both ... but if there is a special module used by pi3 it might not be enabled
<ogra_> oh, you said pi above
<liuxg> ogra_, morphis, I want to get this working for a demo in a qualcomm event. We do not have much to show.
<morphis> liuxg: what does journalctl --no-pager -u snap.bluez.bluez.service give you?
<ogra_> ogra@dragonboard:~$ dmesg |grep Blu
<ogra_> [   15.016483] Bluetooth: RFCOMM TTY layer initialized
<ogra_> [   15.017965] Bluetooth: RFCOMM socket layer initialized
<ogra_> [   15.022818] Bluetooth: RFCOMM ver 1.11
<ogra_> [   15.027751] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
<ogra_> [   15.031521] Bluetooth: HIDP socket layer initialized
<ogra_> dragon should definitely have BT enabled and running by default
<liuxg> morphis, http://paste.ubuntu.com/23173514/
<morphis> hm
<liuxg> morphis, ogra_ http://paste.ubuntu.com/23173518/
<morphis> liuxg: can you give the full journal --no-pager then?
<morphis> liuxg: you need to connect bluez:client too
<morphis> only then "sudo /snap/bin/bluez.bluetoothctl" is supposed to work
<liuxg> morphis, that is huge
<morphis> liuxg: do a: snap connect bluez:client bluez:service
<morphis> then: sudo /snap/bin/bluez.bluetoothctl
<liuxg> morphis, do I need to start the board? After I install the bluez, I did not reboot
<morphis> no
<liuxg> morphis, yes, this time, I see it works
<morphis> good
<morphis> liuxg: inside bluetoothctl
<morphis> power on
<morphis> scan on
<morphis> then it should starting finding your device
<liuxg> morphis, http://paste.ubuntu.com/23173542/ how can I pair the device?
<morphis> liuxg: agent on
<morphis> before you call pair <MAC>
<liuxg> morphis, http://paste.ubuntu.com/23173549/
<morphis> liuxg: try a: connect <MAC>
<liuxg> morphis, after I pair the device, I do not need to pair again, right?
<morphis> nope
<liuxg> morphis, http://paste.ubuntu.com/23173557/
<zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/137
<mup> PR snap-confine#137: chdir to original directory after setns <Created by zyga> <https://github.com/snapcore/snap-confine/pull/137>
<liuxg> morphis, can I quit this bluetoothctl? then run my app?
<morphis> liuxg: type "exit"
<liuxg> morphis, http://paste.ubuntu.com/23173562/
<liuxg> morphis, after exiting, my app still fails to connect to the device. the snap app works in the classic ubuntu
<morphis> what does it say?
<liuxg> morphis, after exiting the bluetoothctl, I run my app, the error message is like http://paste.ubuntu.com/23173571/, basically, it is the same as before.
<morphis> liuxg: so what does your app actually do?
<morphis> does it talk to bluez over dbus?
<liuxg> morphis, i reuse a project on the github. https://github.com/liu-xiao-guo/bluepy, I do not think it uses dbus
<morphis> liuxg: then bluez wont help you at all :-)
<morphis> if it doesn't use bluez
<morphis> liuxg: so how does it then talk with the bluetooth kernel stack?
<liuxg> morphis, oh, that is bad. this is just weird to me. it works on the classic ubuntu.  Previously, I thought the bluetooth was not set up correctly.
<morphis> liuxg: lets take a different view on this, what is the use case you actually want to demo?
<liuxg> morphis, it does use bluze https://github.com/liu-xiao-guo/bluepy/blob/master/bluez-5.29/src/log.c
<morphis> ok
<liuxg> morphis, from the ubuntu core, it uses bluetooth to connect to a sensortag device http://www.ti.com/tool/TIDC-CC2650STK-SENSORTAG, we can push the data to mobile or cloud.
<popey> Anyone packaged a desktop app which accepts keyboard input from arrows, enter key, escape, but _not_ from alphabetic characters?
<ogra_> isnt that aa matter of the app and what keycodes it accepts ?
<popey> the same app works fine when not in snap
<ogra_> https://github.com/ogra1/nethack/blob/master/snapcraft.yaml ...
<ogra_> console-setup ... ?
<popey> perhaps, lets see, thanks
<ogra_> (though there i added it for the font handling)
<jdstrand> zyga: ack
<popey> ogra_: that didn't do it :(
<ogra_> yeah, was just a wild guess
<sergiusens> fgimenez any update on our testing infra?
<sergiusens> elopio said you'd check
<fgimenez> sergiusens, yes, the provision scripts seem to be broken, it seems to be related to the way the nodes are being labeled
<fgimenez> sergiusens, but nothing yet, i'll ping you with any progress
<sergiusens> SamYaple the pip branch looks good, just added a simple comment in there
<jdstrand> ogra_: oh! linux-generic-bbb. is this a community kernel? should I update the review tools for it? (will it get autouploads based on -generic in the archive?)
<ogra_> jdstrand, well, it is knd of a community kernel ... effectively it is the same as all our others, just using linux-generic on armhf
<ogra_> i didnt want to grab the linux-generic name though ... assuming we might want to use it for something official later
<jdstrand> ogra_: on a personal note (I have two bbbs), is there scripting/whatever to just get what floats into -security or will you be doing that manually?
<ogra_> jdstrand, for now it is only for playing around with the BBB ...
<ogra_> jdstrand, i have some lp-lib scripting on my TODO
<ogra_> today i simply watch the -changes MLs and just bump the version (which triggers a rebuild) in the tree
<ogra_> every time i see a new -meta hist -proposed or -security
<jdstrand> ok thanks. until the snap declarations are in place, I'll leave this as manual review, but I'll add a note for other reviewers to approve so you aren't blocked on me
<jdstrand> ogra_: what is the recommended gadget snap? I have in my notes 'beagleblack', is that still up to date?
<ogra_> yeah, i doubt i'll need any new uploads soon though ... not before we have a working gadget at least
<ogra_> well, currently we have none
<ogra_> either beagleblack or we find a new name
 * ogra_ wouldnt mind calling it just bbb
<jdstrand> ogra_: to be clear, I was talking about https://myapps.developer.ubuntu.com/dev/click-apps/4014/rev/7/ ('beagleblack' from the store for series 16, from mvo), not me creating a gadget
<ogra_> jdstrand, yes, me too
<jdstrand> just wondering if that is still the right thing to use
<jdstrand> ok
<jdstrand> cool
<jdstrand> thanks
<ogra_> no, it isnt
<ogra_> it hasnt been ported for ubuntu-image
<ogra_> and u-d-f is now obsolete
<jdstrand> ogra_: I see. if you come up with a gadget snap to use and upload, if you remember, would you mind pinging me?
<ogra_> will do
<ogra_> if elopio doesnt get to it before me :)
<jdstrand> I'd like to move at least one of these to series 16
<ogra_> he was the one pushing for it :)
 * jdstrand thanks elopio :)
<ogra_> :)
<jdstrand> ogra_: and thank you too :)
<ogra_> np, doing a kernel is just a matter of changing a few lines in the existing scripts (as long as there is a package in the archive)
<SamYaple> sergiusens: it was not intentional to change the import order. please ignore
<ogra_> slangasek, so i'm trying to get an ubuntu-image that only creates a 500MB image ... i cloned https://github.com/CanonicalLtd/ubuntu-image, edited snapcraft.yaml to use "source: ." and changed all occurences of "4000000000" to "500000000" in ubuntu_image/builder.py ... yet it still produces a 4GB image :/
<ogra_> (interestingly it also forces me to use sudo for a loop mount, i thought that bit was gone with teh fixed mcopy)
<slangasek> ogra_: the sudo loop mount is because you're on xenial with old e2fsprogs
<ogra_> ah
<ogra_> well, i dont get that on my laptop
<ogra_> where i use the ubuntu-image from the store
<slangasek> ogra_: yes, because the snap has bundled newer e2fsprogs :)
<ogra_> ah, because i built it locally ... understood
<ogra_> so why dont i get a 500MB image with these changes ? i cant see "4000000000" being used anywhere else in the code
<slangasek> As for the image size, hmm.  I was going to be working on that today, tracking down all the hard-coded sizes and changing it to size the writable partition to the contents
<slangasek> maybe there's a 3.6G hard-coded somewhere also, don't know for sure
<slangasek> regardless, feel free to leave it to me to hack on todya
<ogra_> well, i wanted to test the new ubuntu-core ony my dragon and i actually only have a 3.9GB card spare :)
<ogra_> i find it more worrying that the card is trash after dding a to big image to it ... i dont understand why ... the end of the img should only be zeros
<liuxg> dholbach, do you know whether the classic server image at https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ works for pi3 device?
<dholbach> liuxg, sorry, I hvae no idea - I think they're different though - ogra_ ^ can you confirm?
<ogra_> liuxg, i dont think it does
<ogra_> pi3 needs its own uboot binary
<liuxg> dholbach, ogra_, but on the page, it says "Get started with a Raspberry Pi 2 (or 3)".
<ogra_> well, they try it
<liuxg> ogra_, so where can I find the image for the pi3?
<ogra_> *then try it
<ogra_> i have never used classic on a pi3
<liuxg> ogra_, it seems that it is not working. I got a color screen output. but the image works for pi2 for sure.
<ogra_> right
<ogra_> no idea about that
 * ogra_ only does snappy on pi3
<liuxg> ogra_, it is because another colleague got confirmation from didier, so I had a try.
<iliv> is there a way to define CFLAGS, LDFLAGS, etc. in snapcraft.yml?
<ogra_> slangasek, oh, bah ... i see why my hack doesnt get used ... obviously the snapcraft build does a git clone ... and then does a py3versions -d ... which does another git clone it seems
<ogra_> iliv, there surely is ... dont ask me how though :)
<iliv> how? :)
<ogra_> haha
<ogra_> liuxg, well, use the snappy images, they definitely work :)
<liuxg> ogra_, yeah, I just want to try whether the bluetooth works on classic :)
<ogra_> i doubt it
<ogra_> same kernel ... similar setup
<stgraber> zyga: any idea when we'll be getting a new snap-confine?
<liuxg> ogra_, ok.. I got it. thanks!
<zyga> stgraber: as soon as I can land ns sharing, I was aiming for last Friday but there were a few more things to polish
<stgraber> ok
<slangasek> ogra_: speaking of testing images, did you see the discussion about the pi3 not unxz'ing?  did you create this image or did mvo?
<ogra_> slangasek, mvo_ did and i pinged him about it yesterday morning
<ogra_> he wanted to re-do it
<ogra_> (i havent checks if he did though)
<mvo_> ogra_: uh, I did not, sorry
<mvo_> ogra_: let me do it now
 * zyga added some extra sanity checks to snap-confine and fires another spread run
<ogra_> mvo_, thanks
<mup> PR snapd#1895 closed: store: refactor auth/refresh tests <Created by matiasb> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1895>
<mvo_> ogra_, slangasek: how about a new set (not just pi3) that is still based on the snaps from the beta but has 3.8gb instead of 4gb (or even less) to ensure it fits on 4gb sd cards?
<ogra_> mvo_, that requires a new ubuntu-image first ... the size is hardcoded
<slangasek> mvo_: I'm going to fix that bug properly today, if you'd like to wait for it to land
<mvo_> ogra_: sure, but that it not hard to change
<slangasek> properly == autosizing the image based on the writable partition's content size
<ogra_> mvo_, thats what i thought ... i gave up after 1.5h trying :P
<mvo_> slangasek: aha, sure, depends a bit on "today" as your today is a bit longer than my today :)
<mvo_> ogra_: oh? hm
<slangasek> mvo_: yes, you'll be offline by the time I'm done
<mvo_> ogra_: in any case, looks like slangasek has it under control
<mvo_> slangasek: ok, I will just redo pi3 then
<ogra_> mvo_, though i'm trying with a local snap ... i think it still pulls to much remote stuff when i call snapcraft and overwrites my local hackery
<ogra_> [FAILED] Failed to start Run snappy firstboot setup.
<ogra_> See 'systemctl status snapd.firstboot.service' for details.
<ogra_> GRRRRRRRRR !!!!!
<ogra_> damned
<ogra_> mwhudson, sooo .... i finally managed to test the wlan config in console-conf ... it pretends to work, but does not give me the final info about IP and ssh login on the finish page ...
<ogra_> hrm ... so why does the firstboot service fail
<mvo_> ogra_, slangasek: pi3 updated
<mvo_> ogra_: if you have a pi3, wouldbe great if you could do a quick test
<ogra_> mvo_, oh, one FYI ... not sure you saw last nights backlog .. LP builds of ubuntu-core to edge do not get published, despite the store saying so in the UI ... you need to manually unpublish them all and re-publish via the UI to make it work
<ogra_> mvo_, i do have a pi3 buit cvurrently no spare SD big enough
<mvo_> ogra_: meh, how annoying, are the right people aware of this?
<ogra_> mvo_, yep ... the bug also got updated ... that was the reason why i couldnt snap refresh --edge on the released images
<ogra_> Feb 11 16:28:07 localhost snap[1623]: error: assertion is signed with expired public key "-CvQKAwRQ5h3Ffn10FILJoEZUXOv6km9FwA80-Rcj-f-6jadQ89VRswHNiEB9Lxk"
<ogra_> from "canonical"
<ogra_> Feb 11 16:28:07 localhost systemd[1]: snapd.firstboot.service: Main process exited, code=exited, status=1/FAILURE
<ogra_> hah !
<ogra_> so that is why my dragoboard image doesnt work
<ogra_> we really need such errors more prominent
<mvo_> ogra_: uh, Feb 11? what date is you dragonboard?
<ogra_> mvo_, just built right now
<ogra_> i'm testing the new ubuntu-core with dtropped tasks
<mvo_> ogra_: I mean, the log says its "Feb 11"
<mvo_> ogra_: what does "date" print on your dragonboard?
<ogra_> eb 11 16:30:29 localhost rsyslogd-2007: action 'action 11' suspended, next retry is Thu Feb 11 16:30:59 2016 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
<ogra_> Feb 11 16:30:29 localhost systemd[1]: Stopping Ubuntu Core Firstboot Configuration ttyMSM0...
<ogra_> Sep 13 16:00:47 localhost systemd-timesyncd[1627]: Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com).
<ogra_> Sep 13 16:00:47 localhost rsyslogd-2007: action 'action 11' suspended, next retry is Tue Sep 13 16:01:17 2016 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
<ogra_> Sep 13 16:00:47 localhost systemd[1]: Time has been changed
<ogra_> thats fixrtc ...
<ogra_> it uses some imaginary date thats not the epoch before it can sync the time
<ogra_> (well, actually it should use the last mount date of the SD ... but thats a first boot)
<mvo_> ogra_: what year is it imagining?
<ogra_> good question :)
<mup> PR snapd#1898 opened: many: clean out left over references to integration tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/1898>
<ogra_> Filesystem created:       Tue Sep 13 15:32:20 2016
<ogra_> Last mount time:          Thu Jan  1 00:00:25 1970
<ogra_> Last write time:          Thu Jan  1 00:00:25 1970
<ogra_> hmm, i wonder where that feb 11 comes from
<mvo_> ogra_: I think that is the issue, however that is a bit tricky, we probably need to make snapd not fuzzy about really old times
<mvo_> ogra_: right now its pretty strict about key valid times
<ogra_> http://paste.ubuntu.com/23174192/
<mvo_> aha
<ogra_> dumpe2fs -h "$ROOTDISK" 2>/dev/null|grep "Filesystem created"
<ogra_> thast what it uses to find a date
<ogra_> (if there is no last mount time)
 * zyga iterates on snap-confine
<zyga> I fixed a few more aa issues
<zyga> fingers corossed, maybe this time it will work
<ogra_> mvo_, but that means it should be fine on second boot and the firstboot job should run then
<ogra_> and as far as i can tell it doesnt
<ogra_> bah and the wlan setup doesnt persist over a reboot
<ogra_> Sep 13 15:33:30 localhost systemd[1]: Found device /sys/subsystem/net/devices/wlan0.
<ogra_> Sep 13 15:33:31 localhost sh[1497]: sed: can't read /run/systemd/netif/leases/*: No such file or directory
<ogra_> Sep 13 15:33:33 localhost sh[1497]: message repeated 2 times: [ sed: can't read /run/systemd/netif/leases/*: No such file or directory]
<ogra_> oh, lovely
<zyga> I need to patch spread restore in snap-confine to ensure there were no denials
<zyga> and then patch any tests that are designed to trigger denials to clean the buffer
<zyga> I found a few interesting issues just by accident
<ogra_> hmpf
<ogra_> Sep 13 15:33:29 localhost systemd[1]: snapd.firstboot.service: Main process exited, code=exited, status=1/FAILURE
<ogra_> Sep 13 15:33:29 localhost systemd[1]: Failed to start Run snappy firstboot setup.
<ogra_> Sep 13 15:33:29 localhost systemd[1]: snapd.firstboot.service: Unit entered failed state.
<ogra_> Sep 13 15:33:29 localhost systemd[1]: snapd.firstboot.service: Failed with result 'exit-code'.
<ogra_> this time it doesnt complain about the key
 * ogra_ sighs ... no way to get wlan up manually in the netplan world it seems
<ogra_> and no way to get a local user in the console-conf world anymore
<ogra_> this is annoying
<nacc> i thought the local user was tied to your lp id?
<nacc> ogra_: --^
<ogra_> nacc, its not local
<ogra_> its an ssh user
<nacc> ogra_: oh right
<ogra_> there is no password set
<nacc> using lp keys, makes sense
<nacc> and w/o network, you can't ssh in :)
<ogra_> without working network, no ssh
<ogra_> without password, no serial login
 * ogra_ sighs and starts another 20min dd 
<mup> PR snapd#1886 closed: tests: fix spread tests on yakkety <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1886>
<mup> Bug #1623119 opened: wlan setup done by console-conf not persistent <Snappy:New> <nplan (Ubuntu):New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1623119>
 * ogra_ files bug 1623119  so pitti and mwhudson can battle over it who is at fault
<mup> Bug #1623119: wlan setup done by console-conf not persistent <Snappy:New> <nplan (Ubuntu):New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1623119>
<ogra_> and another one for mwhudson
<ogra_> bug 1623120
<mup> Bug #1623120: console-conf does not show ssh credentials on last page when wlan is involved <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1623120>
<mup> Bug #1623120 opened: console-conf does not show ssh credentials on last page when wlan is involved <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1623120>
<kgunn> ogra_: just checking, is the dragonboard image "good'
<kgunn> here http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/
<kgunn> ?
<ogra_> yes
<kgunn> k
<kgunn> ogra_: is it still risky atm if you roll your own off edge?
<kgunn> like it eats itself or something :)
<ogra_> you will hit the issues i'm currenmtly hitting above see the backlog of the last 1h
<kgunn> ogra_: good enough...cool, i will use the beta image
<ogra_> sudo snap refresh ubuntu-core --edge
<ogra_> that should work
<kgunn> k
<kgunn> ogra_: yeah, i'm on ~aug 20 image i think
<kgunn> currently
<ogra_> yeah, you want the one from http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ as base
<ogra_> anything before that is dead beef
<SamYaple> the pip/url/glob thing is solved and tests are passed
<popey> ogra_: i think bug 1580463 might be what I'm hitting
<mup> Bug #1580463: Snap blocks access to system input methods (ibus, fcitx, ...) <snap-desktop-issue> <snapd-interface> <verification-failed> <apparmor (Ubuntu):Fix Released by tyhicks> <im-config (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu):Fix Released> <apparmor (Ubuntu Xenial):Fix Committed by
<mup> tyhicks> <im-config (Ubuntu Xenial):In Progress by jdstrand> <snapd (Ubuntu Xenial):Fix Released> <apparmor (Ubuntu Yakkety):Fix Released by tyhicks> <im-config (Ubuntu Yakkety):Fix Released by jdstrand> <snapd (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1580463>
<ogra_> popey, aha !
<ogra_> yeah, that makes sense
<mup> Bug #1623125 opened: fixrtc script does not catch "Last mount time: n/a" string <Snappy:Triaged by ogra> <initramfs-tools-ubuntu-core (Ubuntu):Triaged by ogra> <https://launchpad.net/bugs/1623125>
<popey> tyhicks: jdstrand is 1580463 perchance on your radar?
<mup> PR snapd#1899 opened: [store] don't discard error body from request device session call <Created by emgee> <https://github.com/snapcore/snapd/pull/1899>
<jdstrand> popey: I'm quite familiar with that bug. curious why you are asking about it?
<zyga> all snap-confine regression tests now pass
<zyga> that'
<jdstrand> zyga: nice! :)
<zyga> that's not all but it's encouraging
<zyga> there's still a bug there that I hit on main test suite
<zyga> and I still need to check a few things for the apparmor profile
<mup> PR snapd#1846 closed: overlord/auth,store: fix raciness in updating device/user in state through authcontext and other issues <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1846>
<mup> PR snapd#1898 closed: many: clean out left over references to integration tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1898>
<mup> PR snapcraft#796 opened: Only discover dependencies on files coming from that part <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/796>
<elopio> can I modify the frequence of the autoupdates?
<elopio> Chipaca: I think you might know this one ^
<popey> jdstrand: because I have packaged an app which we suspect may be hitting it
<popey> jdstrand: it's a game which accepts no keyboard input when snapped, but is fine when not snapped
<popey> jdstrand: http://popey.com/~alan/bussard_snap.tgz contains the snap, yaml etc
<mup> PR snapcraft#785 closed: Check if option is url for pip <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/785>
<mup> PR snapd#1900 opened: interfaces: miscellaneous policy updates for default, browser-support and camera <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1900>
<kyrofa> Yeesh, welcome back everyone
<kyrofa> Guest94770, might want to fix that
<dobey> uhm, how the heck am i supposed to know if i have to pass --dangerous, --force-dangerous, or nothing, for "snap install local.snap" to work?
<sergiusens> dobey !! I can't release snapcraft anymore due to this :-)
<dobey> sergiusens: the worst part about this is that i'm downloading a snap from the store and installing it, so it came from a trusted source!!
<kyrofa> dobey, then you shouldn't need the --[force-]dangerous flag
<kyrofa> dobey, that's just for local snaps
<dobey> kyrofa: right. i downloaded a snap from the store, and am installing it with "pkexec snap install foo.snap"
<kyrofa> Ah ha, then it's not fetching the assertions, so still a local snap
<kyrofa> So you DO need it
<dobey> but how do i know WHICH one i need?
<dobey> because it's changed three times now apparently
<kyrofa> dobey, try --dangerous, if that doesn't work, use the force one
<kyrofa> :P
<dobey> kyrofa: and what if --dangerous works but the install fails for some other reason?
<kyrofa> dobey, then I'd ask to see a pastebin
<dobey> this is in a script we ship
<dobey> kyrofa: what i mean is, i don't want to run "snap install" 3 different times just because the command line option changed, and now i can't tell if the error is because of that, or because of something else
<kyrofa> I agree that the churn is annoying, but the error you should get due to using --force-dangerous should be "unrecognized option" or some such
<kyrofa> Which should be obviously different from a failure deeper in the install process, no?
<dobey> kyrofa: well i presume they all exit with exit code 1
<kyrofa> dobey, ahh, "in a script" I see what you mean now
<dobey> i don't want to have get into parsing stderr/stdout too
<kyrofa> dobey, indeed, I see where you're coming from now
<dobey> kyrofa: yes, i'm trying to install snaps from the existing click scope, with the smallest changes possible. and i had it working two weeks ago before i went on vacation, but now this --force-dangerous is required, and apparently that will be --dangerous soon :(
<kyrofa> dobey, well this isn't ideal anyway, because like you said, you shouldn't need to use --dangerous if you know it's a signed snap, and the scope should only be installing those
<dobey> i was basically ready to land this, and then bam, new snappy broke it
<dobey> right
<kyrofa> dobey, the people I'd ask are EOD, but there much be a way to handle this case
<kyrofa> dobey, you should email the list
<kyrofa> s/much/must/
<kyrofa> dobey, some way to say "hey, grab the assertion from the store," or at least provide the ability for the scope to grab the assertion and provide it to the install command
<dobey> the latter would be quite complicated i think, if we'd have to then do two separate downloads
<dobey> but snap could clearly parse the filename as $snapid_$revision.snap and then grab the assertions for that
<kyrofa> Yeah. Though I suspect that's the more likely to happen since they probably want to enable self-signed assertions, etc.
<kyrofa> But yeah, shoot for that
<mwhudson> ogra_: still around?
<mwhudson> um, is it known that the snapd.firstboot job runs on every boot?
<dobey> oh it just makes the rev always be "x1" when you do --force-dangerous :(
<kyrofa> dobey, yeah, it's a local install: x1, x2, and so on
<kyrofa> dobey, it's been that way for a while. That's why you need the assertion
<tsimonq2> elopio: you might want to keep teward in the loop on your nginx snap
<elopio> sure. who's teward?
<tsimonq2> Ubuntu "maintainer"
<tsimonq2> Thomas Ward
<tsimonq2> he has upload access to nginx and might be interested in what you're doing
<tsimonq2> elopio: upstreaming, remember? ;)
<elopio> tsimonq2: yes. That's the kind of help I need to get it working strict. Thanks tsimonq2
<tsimonq2> no problem elopio :)
<tsimonq2> (there's a reason I subscribe to these emails :P)
<tsimonq2> elopio: he's always told me email is the best contact method
<tsimonq2> teward@ubuntu.com
<mup> Bug #1593407 opened: Guest session cannot run snaps <xenial> <Snappy:New> <lightdm (Ubuntu):Triaged> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1593407>
<mup> PR snapd#1901 opened: firstboot: do not overwrite any existing netplan config <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1901>
#snappy 2016-09-14
<robru> anybody around to help me troubleshoot a snap?
<mup> Bug #1623279 opened: [Errno 2] No such file or directory: '/home/robru/src/bileto.snap/stage/usr/share/locale/ku' <Snappy:New> <https://launchpad.net/bugs/1623279>
<mup> PR snapcraft#793 closed: Unify python plugin <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/793>
<mup> PR snapcraft#794 closed: Improve lifecycle execution of steps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/794>
<mup> PR snapcraft#797 opened: Use --dangerous when installing snaps in yakkety <Created by elopio> <https://github.com/snapcore/snapcraft/pull/797>
<mup> PR snapd#1902 opened: tests: add new SNAP_IGNORE_SUDO_USER and set it for the spread tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1902>
<zyga> mvo: oh, you closed that already
<zyga> mvo: quick question about qemu/spread, can we just use su instead?
<mvo> zyga: yeah, currently thinking about fixing it directly in spread
<mvo> zyga: sure, fire
<zyga> mvo: so that linode and qemu behave the same way
<mup> PR snapd#1902 closed: tests: add new SNAP_IGNORE_SUDO_USER and set it for the spread tests <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1902>
<mvo> zyga: qemu and linode should behave the same, its just adhoc that is different
<zyga> ah, I see
<zyga> how are we using adhoc today?
<mvo> zyga: inside the autopkgtest, its running the tests against localhost basicly
<zyga> ah, I see
<zyga> mvo: offtopic, do you know how can I get a yakkety image for the qemu backend easily?
<mvo> zyga: yes
<mvo> zyga: sudo apt install autopkgtest/xenial-backports
<mvo> zyga: and adt-buildvm-ubuntu-cloud -r yakkety
<zyga> ah, thanks
<mvo> yw
<dholbach> hey hey
 * zyga zeros on the test breaks the remainder of the testing cycle
<mup> PR snapd#1903 opened: tests: ensure SUDO_{USER,GID} is unset in the spread tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1903>
<mup> PR snapd#1904 opened: tests: add debug out put to ubuntu-core-update-rollback-stresstest: <Created by mvo5> <https://github.com/snapcore/snapd/pull/1904>
<mup> PR snapcraft#796 closed: Only discover dependencies once per file <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/796>
<mup> PR snapd#1905 opened: snap: (re)add --force-dangerous compat option <Created by mvo5> <https://github.com/snapcore/snapd/pull/1905>
<mup> PR snapd#1903 closed: tests: ensure SUDO_{USER,GID} is unset in the spread tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1903>
<mup> PR snapd#1906 opened: CONTRIBUTING.md: remove integration-tests, include spread <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1906>
<ogra_> mvo, ok... expired key error fixed ... what a silly thing
<ogra_> mvo, do we know how long assetrtion keys are actually valid, this could really bite us for released images given that fixrtc sets the clock to the image creation date while it can not sync to a timeserver
<ogra_> if the expiration time is to shart they key might be expired
<ogra_> *short
<mup> PR snapd#1907 opened: asserts: basic support for validation assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/1907>
<mup> PR snapd#1905 closed: snap: (re)add --force-dangerous compat option <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1905>
<ogra_> mwhudson, FYI, i just invalidated Bug #1623119
<mup> Bug #1623119: wlan setup done by console-conf not persistent <Snappy:Invalid> <nplan (Ubuntu):Invalid> <subiquity (Ubuntu):Invalid> <https://launchpad.net/bugs/1623119>
<mup> Bug #1623119 changed: wlan setup done by console-conf not persistent <Snappy:Invalid> <nplan (Ubuntu):Invalid> <subiquity (Ubuntu):Invalid> <https://launchpad.net/bugs/1623119>
<mwhudson> ogra_: ok, although i think the snapd behaviour is a bit unhelpful too
<ogra_> well, i dont think the job runs if it finished successfully
<mwhudson> ogra_: https://github.com/snapcore/snapd/pull/1901
<mup> PR snapd#1901: firstboot: do not overwrite any existing netplan config <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1901>
<mwhudson> ogra_: true, will leave it to mvo to decide :-)
<ogra_> but your fix at least looks like a good safety net
<mwhudson> ogra_: wow https://bugs.launchpad.net/snappy/+bug/1623125 looks like heaps of fun
<mup> Bug #1623125: fixrtc script does not catch "Last mount time: n/a" string <Snappy:Triaged by ogra> <initramfs-tools-ubuntu-core (Ubuntu):Triaged by ogra> <https://launchpad.net/bugs/1623125>
 * zyga finally figured out what is going on with snap-confine
<ogra_> mwhudson, yeah, who would have thought that the ext4 devs put some useful thing in that field one day :P
<ogra_> it used to be the epoch or empty in the past ... the script deals with both ... just not with a funny string
<ogra_> fun fact "n/a" translates to Feb 11 (no idea which year) if handed to that date command call :)
<mup> PR snapd#1908 opened: tests/lib/prepare.sh: test that classic does not setting bootvars <Created by mvo5> <https://github.com/snapcore/snapd/pull/1908>
<ogra_> BOOO !
<ogra_> console-conf doesnt see my wlan device on the pi3 !
<ogra_> yeah, even after a reboot ... :(
<ogra_> mvo, hmm, this is an interesting one: http://paste.ubuntu.com/23177205/ ... i'm greeted with a reboot message on first login ... there were no updates though
<mup> PR snapd#1748 closed: asserts: basic support for validation assertion <Created by ralsina> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1748>
<mup> PR snapcraft#798 opened: Replace uses of copy with dump <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/798>
<mup> PR snapd#1837 closed: asserts: add refresh-control header to snap-declaration assertion <Created by ralsina> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1837>
<mup> PR snapd#1909 opened: snap: fix SNAP* environment merging in `snap run` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1909>
<ogra_> hmpf
<ogra_> and this time i'm dropped into console-conf after reboot even though the system was already configured fine
<ogra_> lol ... and now i get wlan config as an option
<ogra_> wow this is buggy
<ogra_> oh man
<ogra_> and console-conf wants to re-create the already existing user ... no way to skip the user part
<mvo> ogra_: iz fine, just add me to your machine ,)
<ogra_> haha
<ogra_>     error: bad user result: cannot create user "ogra@ubuntu.com": Get
<ogra_>     https://login.ubuntu.com/api/v2/keys/ogra%40ubuntu.com: dial tcp: lookup
<ogra_>                          login.ubuntu.com: no such host
<ogra_> oh, lovely
<ogra_> and even though console-conf told me it configured the wlan it seems it didnt
<ogra_> ok, so i get a console-conf on second boot and cant get out of it anymore
<ogra_> heh
<ogra_> and i can log in with the user creasted at the former boot
<ogra_> seems console-conf really doesnt get along with two interfaces
<mup> PR snapd#1910 opened: spread.yaml: don't assume LANG is set <Created by chipaca> <https://github.com/snapcore/snapd/pull/1910>
<ogra_> now the network config constantly times out ... it seems to try to use the wired NIC even though that was set to "dont use"
<ogra_> ok, switching back to wired and completely turning off wlan now gets me to
<ogra_>  error: bad user result: cannot create user ogra: adduser failed with
<ogra_>              exit status 1: adduser: The user `ogra' already exists.
<ogra_> and no way to ever get out of it again
<ogra_> cancel just gets me back to the start page of console-conf
<ogra_> crazyly broken
 * ogra_ takes a break to go crying in a corner 
<mup> PR snapd#1900 closed: interfaces: miscellaneous policy updates for default, browser-support and camera <Created by jdstrand> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1900>
<mup> PR snapd#1897 closed: snap: run all tests with gpg2 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1897>
<mup> PR snapd#1907 closed: asserts: basic support for validation assertion and refresh-control <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1907>
<mup> PR snapd#1911 opened: snap: add additional checks for snap run symlinks <Created by mvo5> <https://github.com/snapcore/snapd/pull/1911>
<zyga> woooot
<zyga> \\o
<zyga> o//
<zyga> \o/
<mup> PR snapd#1908 closed: tests/lib/prepare.sh: test that classic does not setting bootvars <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1908>
<abeato> mvo, is there any reason for which a devmode snap would get ECONNREFUSED when trying to connect to a UNIX socket?
<popey> How would one snap an application which has both python requirements.txt, but is also a node app? have two parts referencing the same source, one python2 plugin, one nodejs plugin?
<mup> PR snapd#1904 closed: tests: add debug out put to ubuntu-core-update-rollback-stresstest: <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1904>
<zyga> mvo: https://github.com/snapcore/snap-confine/pull/141/files
<mup> PR snap-confine#141: Ensure that parent is alive after installing PR_SET_PDEATHSIG <Created by zyga> <https://github.com/snapcore/snap-confine/pull/141>
<zyga> mvo: I fixed ns-sharing to work in spread now, I'll propose a few separate fixes for review
<zyga> mvo: this is the first one, feedback welcome1
<zyga> jdstrand, tyhicks: ^^
<mup> PR snapd#1901 closed: firstboot: do not overwrite any existing netplan config <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1901>
<mup> PR snapd#1891 closed: doscs: add create-user documentation <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1891>
<mup> PR snapd#1896 closed: cmd/snap: match UX document for message when buying without login <Created by pete-woods> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1896>
<zyga> https://github.com/snapcore/snap-confine/pull/142
<mup> PR snap-confine#142: Add sanity timeouts <Created by zyga> <https://github.com/snapcore/snap-confine/pull/142>
<zyga> https://github.com/snapcore/snap-confine/pull/143
<mup> PR snap-confine#143: Don't assume /run/snapd/ns can be removed <Created by zyga> <https://github.com/snapcore/snap-confine/pull/143>
<zyga> https://github.com/snapcore/snap-confine/pull/144
<mup> PR snap-confine#144: Ensure that snap-confine is dead after each test terminates <Created by zyga> <https://github.com/snapcore/snap-confine/pull/144>
<zyga> tyhicks, jdstrand: around? :)
<zyga> spread-in-qemu and local http proxy saved me 7GB of traffic over the last 24 hours :)
<mup> PR snapd#1912 opened: cmd/snap: do runtime linting of descriptions <Created by chipaca> <https://github.com/snapcore/snapd/pull/1912>
<ogra_> mvo, ugh ...
<ogra_> mvo, just testing your re-compressed pi3 image here ...
<ogra_> mvo, did you actually only re-compress it or is this a complete new ubuntu-image build ?
<ogra_> mvo, regardless ... it seems broken
<jdstrand> zyga: hi!
<zyga> jdstrand: hey
<zyga> jdstrand: I managed to get ns-sharing to work on in spread now
<zyga> jdstrand: I posted some patches
<jdstrand> nice!
<jdstrand> I tried to respond to one of them when I was out. curous what github did with it :)
<jdstrand> curious even
<zyga> jdstrand: it did the right thing
<zyga> jdstrand: I saw that reply, github is pretty good at this stuff
<zyga> jdstrand: this is the essential one: https://github.com/snapcore/snap-confine/pull/141
<mup> PR snap-confine#141: Ensure that parent is alive after installing PR_SET_PDEATHSIG <Created by zyga> <https://github.com/snapcore/snap-confine/pull/141>
<zyga> jdstrand: if this lands I can propose the real thing and it should be green
<zyga> jdstrand: debugging this I also implemented https://github.com/snapcore/snap-confine/pull/142
<mup> PR snap-confine#142: Add sanity timeouts <Created by zyga> <https://github.com/snapcore/snap-confine/pull/142>
<zyga> jdstrand: though I don't believe the use of this patch (and a separate tiny patch that puts it arounf flock() is really required
<zyga> jdstrand: still it is a 'death man hand' kind of failsafe
<zyga> jdstrand: I added qemu spread support so if you have recent spread (not installed as a snap) this makes testing far better
<ogra_> cprov, the publishing bug in the store doesnt seem to actually be related to a long revision history, i did re-builds of pi2-kernel and dragonboard-kernel yesterday which both have only seen a few revisions yet (pi2 is at 14, dragonboard at 9) ... and had to do the unpublish/publish dance to make them seen
<cprov> ogra_: you are right, the problem is on the snap-release endpoint itself
<ogra_> ah, so already known by you ? then its fine ...
 * ogra_ just wanted to report the new data point
<cprov> ogra_: the fix is on its way, I've literally just isolated it
<mup> PR snapd#1899 closed: store: don't discard error body from request device session call <Created by emgee> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1899>
<ogra_> i just had not seen it on other packages before  ...
<cprov> ogra_: thanks for adding more info on this (what a nightmare bug!)
<ogra_> heh, yeah
<mup> PR snapd#1906 closed: CONTRIBUTING.md: remove integration-tests, include spread <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1906>
 * ogra_ points mvo to his ping from 30min ago ... 
<zyga> jdstrand: can I merge 141
 * ogra_ feels ignored today :(
<zyga> ogra_: o/
<ogra_> :D
<jdstrand> zyga: it's funny that I read 141 before your alarm branch and I came to the same conclusion :)
<zyga> jdstrand: :-) there is some nice tricky code around
<jdstrand> zyga: so, if you are going to do the alarm, what is the benefit of doing the pid check since it is slightly flawed?
<jdstrand> ie, why isn't the alarm check enough?
<zyga> jdstrand: it's an early warning system where the parent just dies right away, the timeout is 3 seconds
<mvo> ogra_: broken it what way?
<mvo> ogra_: its a new build but its still based on the same beta images
<zyga> jdstrand: it's not *so* flawed, AFAIR the pid namespace would have to overflow before the kernel would recycle process IDs
<ogra_> mvo, did you re-build it from scratch using a newer ubuntu-image ?
<mvo> ogra_: beta channel content
<zyga> jdstrand: so the check is immediate and good enough
<zyga> (as in, not broken totally, but not sufficient(
<jdstrand> zyga: I guess there is no harm if the pid is reused. that process won't send the signal and then the alarm will hit
<mvo> ogra_: its a fresh build
<zyga> jdstrand: I wonder if there's a way to avoid that altogether with a pipe, after all, we'd get EPIPE on the read instantly
<ogra_> mvo, right, but you used the new ubuntu-image for it ... so the rootfs doesnt get loop mounted and has now the same fixrtc bug that i fixed tonight
<zyga> jdstrand: (and eventfd had one task, make the use of the pipe obsolete, eh :-(
<jdstrand> pipe goes back farther too..
<mvo> ogra_: oh, I see, hm, hm. what is the fix? a new initramfs-tools in the beta channel?
<ogra_> mvo, either you re-build using an ubuntu-image from before the mtools fix landed or we promote the new kernel to beta and do a re-build ... the current image on cdimage will fall over
<fgimenez> zyga, could you please take a look at https://github.com/snapcore/snapd/pull/1640 when you have a minute? it seems that i'm approaching gsettings interface testing the wrong way
<mup> PR snapd#1640: tests: add gsettings interface spread test <Decaying> <Reviewed> <Created by fgimenez> <Conflict> <https://github.com/snapcore/snapd/pull/1640>
<zyga> fgimenez: I saw that but I didn't reply yet, I'll make sure to reply today
<ogra_> mvo, right, new initrd is in all the kernel snaps in edge already ... since thats the only change i think we can just promote them
<mvo> ogra_: lets do a new image with a new kernel then and we also reduce the image size
<fgimenez> zyga, cool thanks! :)
<jdstrand> zyga: I don't think you need to move to pipe, at least not for this and not today. I'll comment in the PR
<mvo> ogra_: yeah, lets do it, could you please delete the pi3 image from nusakan and trigger the mirror sync?
<ogra_> doing so
<ogra_> done
<ogra_> mvo, both kernels published to beta
<jdstrand> zyga: commented
<zyga> jdstrand: thank you, will do
<mup> PR snapcraft#799 opened: Load project information in one location <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/799>
<sitter> ahoy ahoy
<sitter> I am currently wondering how, if at all, one would share compiled artifacts across snaps at build time. example of the day: we make a kde-frameworks content snap, we'd then want to build an app using that snap. the problem is at build time we'd have to have access to the content to use headers and libraries.
<mhall119> zyga: kyrofa ^^ can you help sitter please?
 * zyga looks
<zyga> sitter: hey
<popey> sergiusens: do you have an ETA for snapcraft 2.17 in Xenial?
<zyga> sitter: I believe sergiusens has an idea about this, he was working on the design
<popey> (morning btw)
<popey> zyga: could sitter push his compiled artifacts to a ppa/repo and just pull that in as a build-package in snaps?
<popey> as an interim
<zyga> popey: there are many ideas that are possible, sergiusens spent a lot of time on the design of this (as it affects snapcraft) and I believe he's the right person to talk to
<popey> okay
<zyga> jdstrand: this is the key branch, if this lands I'll be supper happy: https://github.com/snapcore/snap-confine/pull/145
<mup> PR snap-confine#145: Enable snap-confine namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/145>
<mup> PR snapcraft#800 opened: LP: #1623509 fix to install of deps in package.json <Created by jonathon-love> <https://github.com/snapcore/snapcraft/pull/800>
<mup> Bug #1574851 changed: libgl not found on nvidia machines (so far) <Snappy:Triaged> <nvidia-graphics-drivers-361 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1574851>
<mhall119> popey: zyga: are build-packages copied into stage and prime directories?
<mhall119> if not, then that is a solution
<zyga> mhall119: stage-packages are copied, build-packages are just installed on the host AFAIR
<popey> indeed
<mhall119> sitter: ^^ would that work for you?
<mhall119> basically include your -dev packages from the archives or PPA in build-packages in your snapcraft.yaml, that way your application's build-time process can see them, but they won't put anything into  your snap
<sitter> mhall119, zyga: thanks that could work
<sitter> I'll give it a stab tomorrow
<zyga> jdstrand: refreshed https://github.com/snapcore/snap-confine/pull/142
<mup> PR snap-confine#142: Add sanity timeouts <Created by zyga> <https://github.com/snapcore/snap-confine/pull/142>
<zyga> jdstrand: if it goes green let's land and use it :)
<jdstrand> zyga: fyi, I've started looking at 145. I really want to tear it apart though and I have an appoint in 30 minutes, but I will be looking at this with top priority after that
<zyga> jdstrand: I need to leave in an hour
<zyga> jdstrand: if you can tighten the profile that would help me a lot
<zyga> jdstrand: I can propose a small branch on top of the sanity timeout branch that actually uses it in three places
<zyga> jdstrand: then I think we are good to seriously consider landing 145
<zyga> jdstrand: I'll be back in the evening (~5 hours from now) so I think we can still sync today
<jdstrand> zyga: in my tear-apart I'll look at the profile
<zyga> jdstrand: thank you
<zyga> jdstrand: as an extra thing to think about, what about cgroups (nothing tests that today)
<zyga> jdstrand: I'll add a pile of spread tests before this is relased but I didn't want to clutter the pull request with them
<jdstrand> zyga: I added spread tests for that some time ago? did you mean something else?
<zyga> jdstrand: I mean spread tests for ns sharing specifically
<zyga> jdstrand: I have one simple test and I have some more in the works (e.g. a stress test that runs lots of concurrent copies of snap confine and checks that they all finish with the same NS identifier
<jdstrand> I'm sorry, I'm having a hard time changing gears
<zyga> jdstrand: hmm?
<jdstrand> what is the interaction with cgroups you are concerned about?
<jdstrand> because the sysfs is mounted in there?
<dbarth> hey guys, i'm having issues doing a "snap login" without sudo (snapd from edge, running on xenial)
<zyga> jdstrand: I don't really know but my point is that there's little testing for ns sharing *and* cgroup usage, which is not default
<zyga> jdstrand: e.g. one process has a cgroup and another doesn't but they share the ns, does the order in which they start matter?
<jdstrand> I see. I'll take a look at that too
<kyrofa> sitter, zyga mhall119 indeed, I believe sergiusens's plan is to provide a way to make a "-dev" snap that can be used to build against
<kgunn> kyrofa: so i was reading up on
<kgunn> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1586465
<mup> Bug #1586465: Add support for hooks <Canonical Click Reviewers tools:New> <Snapcraft:New> <snapd (Ubuntu):Fix Committed by kyrofa> <https://launchpad.net/bugs/1586465>
<kgunn> kyrofa: do you consider that "done" enough that in next release u8 app folk could attempt to use for their own hooks?
<kyrofa> Hey kgunn!
<kyrofa> Yeah, the machinery is all there, add away!
<kyrofa> kgunn, that's what I'm working on at the moment, too
<kgunn> kyrofa: that==?
<kyrofa> Finally adding a hook
<kgunn> actually trying to use?
<kgunn> ah noice!
<kyrofa> kgunn, I'll see if I can add some documentation about adding hooks
<kgunn> tedg: ^
<kgunn> thanks kyrofa
<kyrofa> Good to know there's interest
<tedg> Cool, docs would be great.
<qengho> jdstrand: is there a bug report tracking the refresh-while-running problem?
<mup> PR snapd#1913 opened: daemon,store: move store login user logic to store <Created by matiasb> <https://github.com/snapcore/snapd/pull/1913>
<kyrofa> kgunn, tedg: pstolowski has been learning that as well
<tedg> kyrofa: Snapcraft support? I don't see anything in the snapcraft.yaml schema: https://github.com/snapcore/snapcraft/blob/master/schema/snapcraft.yaml
<kyrofa> tedg, yeah that's missing at the moment. Probably my next task
<kyrofa> tedg, but it's not too bad to get working without
<tedg> kyrofa: Sure without docs is harder than without snapcraft support ;-)
<kyrofa> tedg, yeah I'll make a PR with the spec as well as a tutorial today
<tedg> kyrofa: Great, thanks!
<kyrofa> Thanks for asking!
<mup> PR snapcraft#758 closed: Add an integration test for parts with filesets <Created by jocave> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/758>
<mup> PR snapcraft#797 closed: Use --dangerous when installing snaps in yakkety <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/797>
<pstolowski> kgunn, tedg yeah i'm learning that as well, working on my first hooks
<mup> Bug #1623279 changed: [Errno 2] No such file or directory: '/home/robru/src/bileto.snap/stage/debian/source' <Snapcraft:New> <https://launchpad.net/bugs/1623279>
<zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/146/files enables sanity timeouts
<mup> PR snap-confine#146: Use sanity timeouts around blocking operations <Created by zyga> <https://github.com/snapcore/snap-confine/pull/146>
<zyga> jdstrand: I need to leave now
<zyga> jdstrand: please ping me on telegram for urgent stuff
<zyga> jdstrand: I'll talk to you later :-)
<mup> PR snapd#1909 closed: snap: fix SNAP* environment merging in `snap run` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1909>
<kgunn> jdstrand: hey, are you free enough to have a discussion on something interesting i'm experiencing with denials and mir ?
<mup> PR snapd#1877 closed: many: maintain all snap configurations in state <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1877>
<mup> PR snapd#1910 closed: spread.yaml: don't assume LANG is set <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1910>
<kgunn> zyga: is it expected for devtools to have issue with arm64 ?
<kgunn> or is it just me lacking arm64 gcc path on my host...
<kgunn> ogra_: ^ ?
<kgunn> workflow on snapd hacking on dragon
<jdstrand> qengho: https://bugs.launchpad.net/snappy/+bug/1616650
<mup> Bug #1616650: snap refresh while command is running may cause issues <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1616650>
<jdstrand> kgunn: sorry, was afk
<jdstrand> kgunn: what's up?
<mup> PR snapcraft#799 closed: Load project information in one location <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/799>
<jdstrand> kgunn: hey, did you see:
<jdstrand> 12:30 < jdstrand> kgunn: sorry, was afk
<jdstrand> 12:31 < jdstrand> kgunn: what's up?
<mup> PR snapcraft#751 closed: python3 plugin: run setup.py in source subdir if such option exists <Created by yphus> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/751>
<pmcgowan_> if I fix one build dependency is there a way to avoid a full clean?
<sergiusens> pmcgowan_ build dependencies should go in `build-packages` and if they are, then you should be mostly good
<pmcgowan_> sergiusens, they are but if I change that, it doesnt pick up the change and says the pull already ran
<sergiusens> pmcgowan_ are you confusing `stage-packages` and `build-packages` by any chance?
<pmcgowan_> sergiusens, maybe
<pmcgowan_> the issue is the link doesnt find a lib it needs, and I am not sure why
<pmcgowan_> sergiusens, how do I see what libs are available
<sergiusens> pmcgowan_ I don't parse that, what do you mean?
<pmcgowan_> sergiusens, does stage/usr/lib/x86_64-linux-gnu/ contain the libs available for the linker
<pmcgowan_> sergiusens, essentially, the package I spec'd is in the download dir, but the lib it provides isnt being found, trying to understand why
<kgunn> jdstrand: hey, so here's my current experience....so we landed mir interface, all is well...
<kgunn> i recently tested the mir-server snap on dragonboard and it worked fine, circa aug15
<kgunn> even confined
<kgunn> however, i was testing in the last couple of days using the beta images
<kgunn> on amd64..still works as expected, i mean i do see a sys_admin denial in syslog, but mir-server and mir-client can be connected and work just fine
<kgunn> but on arm64...i now get denials when i install mir-server and it tries to run
<kgunn> jdstrand: this is the output
<kgunn> http://pastebin.ubuntu.com/23178449/
<kgunn> ...and yes, if i uninstall and re-install with devmode it works fine
<mup> PR snapcraft#801 opened: In the busybox test, use the last installed data dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/801>
<sergiusens> pmcgowan_ I might need to see your snapcraft.yaml; but yes stage/usr/lib/x86_64-linux-gnu/ is a library path available for the next part to build depending on it
<pmcgowan_> sergiusens, I think the qmake file may be wrong, but I still dont see the installed lib there
<sergiusens> oh, qmake, pmcgowan_ heh, jhodapp came by with a very similar qmake problem
<jhodapp> pmcgowan_, a qt-based app?
<pmcgowan_> jhodapp, yeah
<pmcgowan_> the build line doesnt look right to me
<mup> PR snapcraft#790 closed: Reduces download time of `git clone` fetching just a single branch <Created by ehbello> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/790>
<pmcgowan_> jhodapp, I cant find the libs I should have for my stage-packages
<jhodapp> pmcgowan_, have you seen the other qt-based examples out there?
<pmcgowan_> jhodapp, yeah some
<jhodapp> pmcgowan_, ok...let me point you to mediaplayer-app's snapcraft.yaml I just did last week: https://code.launchpad.net/~phablet-team/mediaplayer-app/snap-it-up/+merge/305045
<elopio> joc_: plainbox tries to write to ~/.cache, and that fails in yakkety. Could you take a look?
<elopio> https://bugs.launchpad.net/snapcraft/+bug/1623623
<mup> Bug #1623623: plainbox demo test fails in yakkety: Permission denied: '/home/ubuntu/.cache/plainbox/sessions' <Snapcraft:New> <https://launchpad.net/bugs/1623623>
<elopio> I don't really understand why that works in xenial, should fail too.
<jdstrand> kgunn: dac_override is almost always a result of a directory with incorrect permissions. eg, a root process trying to add a file to a non-root owned directory that doesn't have 'other' access (eg, 0755). ie, traditional unix permissions wouldn't allow it because the users don't match but because it's root and has CAP_DAC_OVERRIDE, the operation is allowed
<jdstrand> kgunn: but the LSMs (ie, apparmor) mediate it
<kgunn> jdstrand: so are you suggesting permissions changed on the fs between images?
<jdstrand> kgunn: simple answer-- make sure that the process is running as the user you expect it to be and make sure the directories/files are all setup right for mir. comparing amd64 and arm64 images and running the commands in parallel should show the problem. strace would get you right there
<jdstrand> kgunn: I am
<jdstrand> or maybe on the arm64 core snap it is wrong but it is right on amd64
<jdstrand> or something
<mup> Bug #1623626 opened: syslog messages include ubuntu-core-launcher instead of command name <Snappy:New> <https://launchpad.net/bugs/1623626>
<kgunn> kgunn> jdstrand: i plan to do the strace exercise with amd64 vs arm64....but just sharing another data point
<kgunn> so i added dac_override just to test on dragonboard, mir-server came up graphically...but mouse not responding
<kgunn> b/c i also get other/new denials
<kgunn> around run/udev/data
<kgunn> http://pastebin.ubuntu.com/23179211/
<jdstrand> kgunn: we'll need to add these rules to the PermanentSlot for apparmor:
<jdstrand> /run/udev/data/c13:[0-9]* r,
<jdstrand> /run/udev/data/+input:input[0-9]* r,
<kgunn> jdstrand: again, i'm just really surprised this worked a few weeks back
<jdstrand> it's interesting because the c13 udev accesses came up in another thread
<jdstrand> I wonder if something changed in one of the staged libraries
<dobey> how exactly do updates work for snaps? i don't see any way to list/install updates with snap cli
<awe> dobey, snap refresh?
<awe> not sure if there's a way to list available updates first though?
<dobey> ah
<dobey> i guess all the terms for snappy have to be different from every other thing that came before, just because
<pedronis> snap refresh --list
<pedronis> lists available updates
<mup> PR snapcraft#802 opened: Add the TEST_STORE environment variable to the travis script <Created by elopio> <https://github.com/snapcore/snapcraft/pull/802>
<mup> PR snapd#1914 opened: docs: add a little documentation on hooks <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1914>
<kyrofa> tedg, kgunn that ^^ is the basic spec
<kgunn> thanks!
<kyrofa> i.e. what you'd do from the snap developer perspective to take advantage of them
<kyrofa> tedg, kgunn still working on the snapd developer side tutorial
<tedg> kyrofa: By snapd, do you mean the slot or the plug side?
<tedg> I guess we need to be able to do each of those.
<tedg> Not sure there's a "snapd" side?
<kyrofa> tedg, by snapd, I mean adding support for new hooks within snapd
<kyrofa> tedg, as opposed to utilizing them within snaps
<kyrofa> tedg, I suspect you need both
<tedg> I don't think we need them in snapd, we just need them on both sides of the interface.
<tedg> So like one would be in unity8 snap, and one would be in teh app snap.
<kyrofa> tedg, ah, so all you care about are interface hooks? Then yeah, those are being worked on
<kyrofa> By pstolowski (not sure if I got that right without tab completion :P )
<kyrofa> He's adding support for them within snapd, so that doc ^^ is really what you need then. Nice
<tedg> Ah, okay, yeah that's more what we need.
<kyrofa> He's also adding snapctl subcommands to get interface attributes
<kyrofa> As he makes progress I'll make sure that document is updated
<tedg> kyrofa: Is there any doc on the lifecycle of the various hooks? Like when they run with regards to the snap being marked active, for instance.
<kyrofa> tedg, that's what I hope that document will be, once we actually have the hooks implemented in snapd
<tedg> kyrofa: Okay, cool.
<tedg> That's what I'm worried about, as that was really sadly missed in Juju
<kyrofa> tedg, yeah, the interface hooks are again still a work in progress
<tedg> kyrofa: Then on the snapcraft side I imagine we'll hook a command up to a hook in someway?
<kyrofa> brb, someone at the door
<awe> anybody know if there's a way to get snapcraft autotools to automatically use "-g" and "-O2" or do I need to hack my Makefile?
<tedg> awe: snapcraft help autotools, lists configureflags
<tedg> Sorry, configflags
<awe> yup
<awe> I need CFLAGS
<awe> ;)-
<awe> discussing on rocket atm
<tedg> awe: Usage: ./configure [OPTION]... [VAR=VALUE]...
<elopio> lool: these avahi tests need a lot of work.
<lool> elopio: well the new impl is much shorter, so the tests ought to be much shorter too; the initial impl knew too much about mdns
<mup> PR snapd#1915 opened: tests: add http_proxy to /etc/environment in the autopkgtest environment <Created by mvo5> <https://github.com/snapcore/snapd/pull/1915>
<lool> elopio: but yes, they need as much work as the original file unfortunately
<elopio> lool: yes, they were wrong to start with. But I don't know enough avahi to understand where to fake and what to check.
<lool> elopio: so personally, I would ditch them all and add just a test for the gethostname logic
<lool> elopio: to ensure localhost -> snapweb and .domain part is removed
<lool> elopio: ideally, we'd also have an *integration* test setting up the network and making sure mdns starts when no multicast and works when intf comes up
<lool> elopio: but frankly, if you look at avahi.go, you'll see we call two functions: mdns.NewMDNS() on startup, and _mdns.ScanInterfaces() regularly
<lool> essentially consuming the whole mdns impl
<lool> rather than knowing about 224., 127., ipv6 and what not
<elopio> ideally, it's the Init function the one we test. And either msdn is easy to replace with a fake, or it can be run safely in unit tests.
<elopio> I suppose we will go with a fake. Then that needs changes on the code.
<kyrofa> tedg, yeah, I figured snapcraft will treat hooks as just special apps
<awe> thanks tedg
<awe> that works!
<awe> ;D
<lool> elopio: why would we want to build a testsuite for third-party code?
<lool> oh you mean our Init?
<elopio> yes.
<tedg> np
<tedg> kyrofa: Yeah, I think that makes sense, we just don't want to have magic directories so that we can build them with the same tools and reference the paths.
<kyrofa> Yep
<tsimonq2> can you confirm with the lxqt package lynorian ?
<tsimonq2> whoops
<tsimonq2> sorry
<mup> PR snapd#1912 closed: cmd/snap: do runtime linting of descriptions <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1912>
<zyga> jdstrand: hey, did you have a chance to look at the namespace sharing branch?
<zyga> ohh, cool, I see a comment 14 minutes ago :)
<jdstrand> zyga: I've made a number of comments
<zyga> jdstrand: I'll reproduce your observations on "ip netns add testnet" but I was wondering if you know what is the source of the permission denied error; Is it the kernel refusing to do something (like we had with the unshare -U as non-root user) or the process not having permission to do something using regular DAC
<jdstrand> zyga: I don't know otoh, but I ran it as root and non-root. Note that 'ip netns add testnet' worked at one point. I just tried again here and see that it doesn't work with snap-confine 1.0.38-0ubuntu0.16.04.8 and snapd 2.14.2~16.04 on classic
<jdstrand> zyga: I updated my comment in the PR to reflect that ^
<zyga> thank you
<jdstrand> zyga: based on the dates in the bug, I'm going to guess this 'ip netns add testnet' stopped working when we switched to snap-confine
<jdstrand> zyga: would it help if I downgraded to ubuntu-core-launcher?
<jdstrand> zyga: test and let you know if it worked?
<zyga> jdstrand: hmmm, you'd have to downgrade quite a bit
<zyga> jdstrand: I guess it might be related to the particular directory
<zyga> jdstrand: and before the major difference was in lack of chroot/pivot_root
<jdstrand> yeah
<zyga> jdstrand: doesn't the netns thing simply create a new net namespace and saves it, just like we do, somewhere in the filesystem?
<jdstrand> that is what I was thinking might be it
<zyga> jdstrand: perhaps it is simply saving it in a read-only location
<zyga> jdstrand: a simple strace would answer that
<jdstrand> zyga: it is in /run
<jdstrand> zyga: /run/netns
<zyga> so that *should* be okay
<jdstrand> eg, on classic outside of any snaps
<zyga> right, but /run is bind-mounted
<jdstrand> sudo ip netns add testnet
<jdstrand> $ ls -l /run/netns/
<jdstrand> total 0
<jdstrand> -r--r--r-- 1 root root 0 Sep 14 16:54 testnet
<jdstrand> sorry, was just trying to show you what it does on classic
<jdstrand> note that if I run that command without sudo:
<zyga> right, I understand
<jdstrand> $ ip netns add testnet
<jdstrand> mount --make-shared /var/run/netns failed: Operation not permitted
<zyga> I will need to experiment to see what the root cause is
<zyga> jdstrand: could it be a capability that's missing?
<zyga> er
<zyga> jdstrand: is there any apparmor denial?
<zyga> (I assume this is in devmode shell)
<jdstrand> this is devmode
<zyga> curious
<zyga> ok, checking now
<jdstrand> the open("/proc/self/ns/net"): Permission denied I'm guessing is another kernel gotcha that we didn't see yet
<jdstrand> (ie, something non/under-documented)
<zyga> jdstrand: the namespaces(7) manual page gives a false sense of completeness
<jdstrand> yeah :(
<zyga> I see the same thing
<jdstrand> zyga: that said, I think there is a pretty solid clue in that without this PR, it still doesn't work with xenial-updates
<jdstrand> so maybe all the namespaces bits are ok and it is pivot_root/mount options/shared vs private/etc thing
<zyga> perhaps
<zyga> I'll read the kernel code for nsfs
<zyga> quick question: wrz 15 00:00:14 tower kernel: audit: type=1400 audit(1473890414.074:130): apparmor="ALLOWED" operation="file_mprotect" profile="snap.snapd-hacker-toolbelt.busybox//null-/usr/bin/unshare" name="/usr/bin/unshare" pid=13886 comm="unshare" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<zyga> what is ouid=0?
<jdstrand> owner uid
<jdstrand> zyga: it is the process uid used for comparing with fsuid which is the file owner
<tyhicks> jdstrand: fsuid is the fsuid of the current task
<tyhicks> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/tree/security/apparmor/file.c#n61
 * zyga hugs cscope
<jdstrand> mey, I flipped it around
<jdstrand> meh
<zyga>     if (!ns_capable(net->user_ns, CAP_SYS_ADMIN) ||
<zyga>         !ns_capable(current_user_ns(), CAP_SYS_ADMIN))
<zyga>         return -EPERM;
<jdstrand> ouid is object uid (the file), and fsuid is the the uid used to check access to the fs
<jdstrand> I've done that before. maybe this time it will stick :)
<tyhicks> ouid is hard to remember
<zyga> that's the only EPERM I can quickly see
<jdstrand> jeez, I downgraded ubuntu-core-launcher and it isn't working :\
 * zyga has an idea
<zyga> jdstrand: so I can "unshare -n" from devmode snapd-hacker-toolbelt.busybox
<zyga> (as root)
<zyga> jdstrand: but it fails if I try to preserve the ns
<jdstrand> zyga: fyi with ubuntu-core-launcher 1.0.27.1: http://paste.ubuntu.com/23179927/
<zyga> interesting
<zyga> I guess at this point the kernel is our manual
<jdstrand> I'm really surprised it isn't working with ubuntu-core-launcher since I very clearly had a working test case
<zyga> jdstrand: are you sure that this was the test case?
<zyga> jdstrand: hmm, I think I read something that may contain hints
<jdstrand> zyga: https://bugs.launchpad.net/snappy/+bug/1611444/comments/8
<mup> Bug #1611444: Cannot share a namespaces created with 'ip netns' between apps in a devmode SNAP <Snappy Launcher:In Progress by zyga> <Snappy:Triaged by zyga> <https://launchpad.net/bugs/1611444>
<zyga> hmm
<zyga> interesting
 * jdstrand reboots into an older kernel
 * zyga reads through util-linux source
<mup> PR snapcraft#803 opened: Do not run the bootstrap directory as a script (autotools plugin) <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/803>
<jdstrand> booting into the release kernel didn't do it
<jdstrand> (meaning, a kernel update didn't cause this)
<zyga> right
<zyga> jdstrand: is there any difference between "ip netns add testnet" and "unshare -n /run/$something/testnet"
<jdstrand> zyga: I don't understand that command. /run/$something/testnet isn't a program
<zyga> I mean "unshare -n /path/to/saved/net/ns"
<zyga>     if (!ns_capable(net->user_ns, CAP_SYS_ADMIN) ||
<zyga>         !ns_capable(current_user_ns(), CAP_SYS_ADMIN))
<zyga>         return -EPERM;
<zyga> er, sorry
<zyga>        -n, --net[=file]
<zyga>               Unshare the network namespace. If file is specified then persistent  namespace  is  created  by
<zyga>               bind mount.
<jdstrand> but the unshare program takes an program argument
<zyga> Is it anything fundamentally different?
<zyga> right but you can pass "true"
<jdstrand> ok, let me just do bash
<zyga> and it will just unshare that space and quit
<jdstrand> sure
<jdstrand> zyga: ok, so I did:
<zyga> jdstrand: then we can use nsenter/unshare instead of the (probably more complex) ip netns as a test tool
<jdstrand> sudo ip netns add testnet
<jdstrand> sudo hello-world.sh # installed in devmode
<jdstrand> unshare --net=/run/netns/testnet true || echo yes
<jdstrand> yes
<jdstrand> is that what you wanted to test?
<zyga> yes :-(
<zyga> do you have any theory or ideas as to why the kernel is rejecting this?
<jdstrand> no
<jdstrand> I'd like to identify the point at which things were working with my test case
<zyga> yes, that would be very useful
<zyga> jdstrand: I wonder if vanilla 16.04 install works
<zyga> that might be easy to test from a live media and a vm
<zyga> if it wasn't past midnight I'd check that
<jdstrand> yeah, you should go to bed
<jdstrand> I have a school thing in a few minutes anyway
<zyga> I'll catch you tomorrow; I'll keep experimenting tomorrow
<jdstrand> I wonder if I was doing this in an old all snaps vm
<zyga> hmm
<zyga> so no pivot root
<zyga> that's "easy" to check
<zyga> I wonder if pivot vs chroot matters as well
<jdstrand> I have a vm from june 24 here
 * jdstrand tries
<zyga> jdstrand: one thing that might be a factor is that /run is now a shared bind mount
<zyga> jdstrand: instead of the vanilla /run which is ...
<jdstrand> so, I'm totally not crazy: https://www.mail-archive.com/snapcraft@lists.ubuntu.com/msg00546.html
<jdstrand> yet, open("/proc/self/ns/net"): Permission denied
<zyga> did systemd change?
<zyga> 23 25 0:19 / /run rw,nosuid,noexec,relatime shared:5 - tmpfs tmpfs rw,size=818576k,mode=755
<zyga> so even on the "outside" /run is shared with something
<jdstrand> this is on an image from months ago
 * zyga never knows how to find *all* mount entries 
<zyga> (i.e. what is "5" from the quote above)
<wililupy> Question: Make sure I have this right for using ubuntu-image. If I need to build an image with a custom kernel snap, I can create a new assertion model .json, point the kernel parameter to that, sign it, and all is good?
<wililupy> Also, if I want to add other snaps to the image, is there a value for the assertion model for that?
<zyga> jdstrand: so at some point in time this worked
<jdstrand> zyga: I came across this the other day: findmnt  -o+PROPAGATION
<jdstrand> zyga: yes, and not just cause I remember it this way :)
<zyga> omg
<zyga> the things I find out :)
<zyga> jdstrand: but that still doesn't show me mount entry with id 5
<zyga> in fact, my current shell process doesn't have that entry
<zyga> but it still exists and perahs one of the processes has acess to it
<jdstrand> zyga: '5' is the peer group
<zyga> peer group or peer id?
<zyga> I mean, should I match this against the 1st column of mountinfo?
<jdstrand> no
<jdstrand> well, let me double check that
<jdstrand> https://www.kernel.org/doc/Documentation/filesystems/proc.txt
<zyga> jdstrand: this is also in mountinfo.h in snap-confine btw
<jdstrand> those are the mount ID and parent IDs
<jdstrand> that are different than the peer group in column 7
<jdstrand> https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt, section 5a
<zyga> ah, interesting
<jdstrand> I suspect the findmnt command is looking at the perr group to organize things
<kallisti5> so.. any timeline on being able to generate new snappy core images?
<kallisti5> last I checked the tool gave a neat "someday" response :P
<zyga> (*) X is the closest dominant peer group under the process's root.  If
<zyga> X is the immediate master of the mount, or if there's no dominant peer
<zyga> group under the same root, then only the "master:X" field is present
<zyga> and not the "propagate_from:X" field.
 * tsimonq2 bets elopio saw an nginx-related tweet and decided to snap it
<elopio> tsimonq2: even better, I met somebody that works at nginx.
<tsimonq2> gosh darnit
<tsimonq2> :P
 * zyga -> EOD
<jdstrand> bye zyga :)
<mup> PR snapcraft#801 closed: In the busybox test, use the last installed data dir <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/801>
<mup> PR snapcraft#798 closed: Replace uses of copy with dump <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/798>
<wililupy> How do I use snapcraft to delete a key I registered?
<wililupy> I'm getting a weird error when I sign my assertion, and I think its due that I forgot to branch 2.17 for snapcraft and used it to register my key... :/
<wililupy> snapcraft revoke-key default does not work
<wililupy> This is the error I'm getting: error: cannot assemble assertion model: "timestamp" header is not a RFC3339 date: parsing time "$(date -Iseconds --utc)" as "2006-01-02T15:04:05Z07:00": cannot parse "$(date -Iseconds --utc)" as "2006"
#snappy 2016-09-15
<stochastix> f i do,  snap find ,  is that supposed to list all of the snap available?  If I run snap find tele, I get telegram, but otherwise it is not in the long list?
<stochastix> I am trying to just get an exhaustive list of the snaps available to look at them.
<tsimonq2> elopio: do you use zsh? how did that idea get formed?
<elopio> tsimonq2: I met somebody who uses zsh.
<elopio> I have a lot of new friends today ^_^
<tsimonq2> elopio: :D
<tsimonq2> elopio: are you at a sprint or something? :P
<slangasek> ogra_: https://github.com/CanonicalLtd/ubuntu-image/pull/63 landed
<mup> PR CanonicalLtd/ubuntu-image#63: Don't build 4GB images, build images as big as the required contents <Created by vorlonofportland> <Merged by vorlonofportland> <https://github.com/CanonicalLtd/ubuntu-image/pull/63>
<sparkin> hello my fellow crafters!!!!!!!
<sparkin> crickets...
<mvo> ogra_: was just thinking about the recent change to ubuntu image to make the disk only as small as needed. this does mean that if you run it directly in kvm/qemu the first snap you download causes a disk-full error?
<dholbach> hey hey
<mup> Bug #1623802 opened: snapd does not properly detect service/mount unit status <Snappy:New> <https://launchpad.net/bugs/1623802>
<mvo> pitti: I'm curious why the autopkgtest test runs take so long after an upload, is it because the machines that do the testing are so busy? or is there another reason?
<mvo> pitti: (background is my snapd upload from 12h ago that did not yet get run inside adt)
<pitti> mvo: yeah, sorry -- look at http://autopkgtest.ubuntu.com/running
<pitti> mvo: queues got double-Qt'ed yesterday, and the backlog lasted until this morning; s390x and armhf are still catching up
<mvo> pitti: it says queue length is "-" for yakkety/amd64, does that mean the queue is empty?
 * pitti orders another Binford 6100 cloud  -- we need MORE POWER
<pitti> mvo: yes (some amd64 tests are stilll running, though
<mvo> pitti: hm, I don't see snapd on the page but there is a new version https://launchpad.net/ubuntu/+source/snapd/2.14.2+git.1.afda4fc-0ubuntu2
<mvo> pitti: what am I missing :) ?
<pitti> mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd ?
<pitti> mvo: you are missing the FTBFS on arm64
<mvo> pitti: oh, meh, ok. this got fixed this morning, but I guess that is too late
<mvo> pitti: ok, thank you!
<mvo> pitti: so that means it will be considered soon :) ?
<pitti> mvo: as soon as it builds, yes
<mvo> pitti: cool, thanks. it has build ~1h ago, but I guess it takes a bit until the script catches up (or does it need to get published first?)
<pitti> mvo: yes, britney only sees published packages
 * mvo nods
<zyga> quick noob question, how do I build our kernel in a way that lets me incrementally build / reinstall / reboot while tweaking some things?
<zyga> (where what I care about is identical config and initial source as packaged kernel and incremental build after any change)
<mup> PR snapd#1916 opened: backends: first bits of kernel-module security backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/1916>
<ogra_> mvo, yeah, we need a --size option
<ogra_> so you can define a minimal size
<ogra_> or allow to pre-create a target img (though thats more ugly)
<mvo> ogra_: indeed
<ogra_> mvo, i see steve added an image_size variable to builder.py, i guess we just need the option at the top level and hand the value over
<mvo> ogra_: yeah, I was thinking it would be pretty easy to add
<ogra_> as a quick hack: os.environ.get('IMAGESIZE') ... ;)
<ogra_> wouldnt even need an option
<ogra_> http://paste.ubuntu.com/23181304/
<ogra_> hrm
<ogra_> i get "Failed to mount /boot/grub." ... even with the beta channel
<ogra_> oh
<ogra_> FAT-fs (sda2): error, fat_get_cluster: invalid cluster chain ...
<ogra_> hmm, weird, steve didnt touch anything in the vfat creation
<bull> hello guys my app which is written in qt have a functionality like- when user click on open file with editor , it open the loaded file with system editor ex gedit , kwrite or whatever user having as per their configuration . after packaging my app with snap the functionality is broken, are you guys working in it ???
<bull> am sure there is nothing wrong with my code as you can see this feature in hundreds of other applications out there. snap need to fix this :D
<pitti> mvo: snapd tests are queued now
<ogra_> aha ... using mtools from proposed helps :)
 * ogra_ has a working 500MB kvm image
<pitti> mvo: oh, so it wasn't FTBFS, just finished building around that time
<ogra_> ogra@localhost:~$ df -h /writable
<ogra_> Filesystem      Size  Used Avail Use% Mounted on
<ogra_> /dev/sda3       542M  190M  313M  38% /writable
<ogra_> bull, for now you need to ship the editor you want and tell your app to use this one ... long term i think zyga works on a sensible-editor interface or some such
<bull> ogra_,  you mean gedit or kwrite inside snap as stage package ??
<bull> this will fill snap with almost all kde and gnome dependencies am sure :D
<ogra_> (i know he does something like this for browsers already, editors should just be a variant of that)
<bull> oh
<ogra_> bull, yes, i mean that ... just pich one with less deps then
<ogra_> *pick
<bull> ogra_, my app cant open url in external web browser
<ogra_> yes, same thing
<bull> ogra_, i have to add sensible- browser in snapcraft yaml ?
<mvo> pitti: neat, its running
<mvo> pitti: can't wait, I had it down to 1 test failure due to no (non-proxy) network
<ogra_> no, you would have to add the browser you want ... there is also work on making xdg-open work if your snap runs on a classic system ... not sure where that stands
<mvo> pitti: and in qemu its all working perfectly, so fingers crossed
<bull> ogra_,  you mean i have to add a browser inside my snap ??
<bull> damn
<bull> :D
<bull> like chrome or firefox ?
<ogra_> hypothetically ...
<ogra_> i'd just wait til the right interfaces are there for that one :)
<bull> thats really funny :P
<bull> and if my app wana talk with snapd installed on user's system ??
<bull> is there snapd interface coming ?
<ogra_> you can surely find a lightweight editor and seed that into your derfault config .... i wouldnt expect that for a browser
<bull> for that too  :/
<bull> come-on i don't want change the main aim of my feature
<ogra_> ogra@anubis:~/datengrab/images/snappy$ snap interfaces|grep snapd
<ogra_> :snapd-control           -
<ogra_> that is already there
<bull> aim of feature is to make user comfort by providing him an option to edit  file in his favorite editor not with editor of my choce
<bull> choice
<bull> :P
<ogra_> yes, that was clear f4rom your first question
<bull> okay
<ogra_> isnt there yet ... but there are workarounds i pointed out til this landed
<bull> ogra_,  if i will add snapd-control in my snapcraft's plugs will it make it work ?
<ogra_> mvo, so http://paste.ubuntu.com/23181304/ seems to work fine as a quick hack, unless you want to invest time into adding an actual option
<ogra_> bull, it allows your snap to talk to the REST api of snapd ... so if you implement the right protocol i imagine it will work ...
 * ogra_ has no first hand experience with that API
<bull> my app uses qprocess to call snap ,
<liuxg> ogra_,  I have changed my network setting in my p3 to http://paste.ubuntu.com/23181339/, however, after I disconnect my cable, my wifi on the pi3 still cannot get an IP. what could be the problem for it?
<ogra_> liuxg, sit0 isnt your wlan device :)
<ogra_> i think it just comes up as wlan0 on the pi
<liuxg> ogra_, what should be the wlan device? I could not find any other device there
<ogra_> cat /proc/net/dev ?
<liuxg> ogra_, yeah, you could be right. thanks. I will check it
<bull> snap looking for a web browser to open a folder what ??? QGenericUnixServices::openUrl(const QUrl&): Unable to detect a web browser to launch '/home/bull/github/'
<mup> PR snapd#1787 closed: overlord/snapstate, daemon, cmd/snap: more explicit revision support <Blocked> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1787>
<mup> PR snapd#1834 closed: many: mostly work to support ABA upgrades <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1834>
<pbek> I have a problem with updating my snap in the snapstore. `snap find qownnotes` and https://uappexplorer.com/app/qownnotes.pbek tells me the latest version is 16.09.3, but my package in my https://myapps.developer.ubuntu.com account is at 16.09.7 and all releases are published in the channel `stable` as they should be.
<pbek> All releases were published automatically by Launchpad.
<ogra_> pbek, there is an issue with the store ... go to the last releaseed snap in the UI, click unpublish and then click publish again
<bull> pbek,  which package you trying ?
<ogra_> that will make it show up
<ogra_> the fix for this should land today or tomorrow
<pbek> ogra_: I get a `504 Gateway Time-out` when I try that :)
<pbek> bull: qownnotes
<ogra_> uh
<pbek> ogra_: but it was unpublished
<bull> pbek, does it work out-of-box as a snap ?
<pbek> bull: what do you mean by that?
<bull> i will check that myself by installing it
<bull> ty
<pbek> ogra_: thank you, 16.09.7 is now visible
<ogra_> :)
 * ogra_ has to do the same every morning for all ubuntu-core snaps :)
<bull> pbek,  like most of apps dont seem to work fine with after packed in snap :D
 * ogra_ found that most apps do work fine ... 
<liuxg> ogra_, if I have this error "error: cannot install snap file: snap "piglow-app" has changes in progress". how can I correct this situation?
<ogra_> really depends how complex that app is :)
<pbek> ogra_: that explains why noone updated QOwnNotes for some time :)
<liuxg> ogra_, I have seen this kind of errors a number of times. but sometimes it disappears.
<ogra_> liuxg, snap changes ... find the change in progress ... snap abort $change_number
<pbek> bull: oh, I had to do quite some work to make it happen... and there are still some issues
<bull> ogra_,  a package management system should not worry about how developer made their app :D\
<ogra_> every package management system does that
<bull> they worry about what functionality developer providing ??
<bull> i think no
<mvo> pitti: interessting failure of adt on armhf - there is no sshd config there, is armhf driven via something else than ssh in adt?
<ogra_> they have to make integration work
<liuxg> ogra_, how to find the change number in the system?
<bull> they need to install packaged stuffs to place :D
<bull> nothing more then this
<ogra_> liuxg, ?
<pitti> mvo: yes, armhf and s390x run in lxc; we don't have these arches in scalingstack
<ogra_> liuxg, does snap changes not show it ?
<bull> snap is different case a sure :D
<ogra_> bull, how many deb or rpm packages have you built from scratch ?
<pitti> + sed -i s/\(PermitRootLogin\|PasswordAuthentication\)\>.*/\1 yes/ /etc/ssh/sshd_config
<pitti> o_O
<liuxg> ogra_, yeah, I cannot find anything about it. it seems that it is broken http://paste.ubuntu.com/23181393/
<ogra_> liuxg, thats snap list
<bull> ogra_, i made more then 20 debs
<bull> from scratch
<liuxg> ogra_, yeah, that is the list. I try to remove it, it refuses to do that.
<bull> and they all were in ubuntu software center
<ogra_> bull, from scratch ? into the official archive, matching all integration requirements to make then safely work ?
<mvo> pitti: ta
<ogra_> *them
<bull> not in official archives
<pbek> bull: just making debs for QOwnNotes drove me nuts :)
<ogra_> i.e. following the debian packaging policy ...
<liuxg> ogra_, is there anyway to find the changes, and cancel it?
<pitti> mvo: the tests want to ssh to localhost via password? 3v1l :)
<popey> With the git source-type, is it possible to pull a specific commit? I can use source-tag, and source-branch... but how do I get a commit?
<popey> (in snapcraft)
<bull> ogra_,  apps in store don't follow debian policies?
<ogra_> liuxg, again ... snap changes ... find the change in progress ... snap abort $change_number
<liuxg> ogra_, ok. thanks
<ogra_> bull, they get a security check ... thats all i think
<bull> ogra_,  snap abort change-id for a install process wont abort process until snap download the full package that is a bug
<ogra_> thiough support for this was dropped lng ago since the review was way to time consuming
<bull> hmm
<bull> ogra_,  snap abort change-id for a install process wont abort process until snap download the full package that is a bug !! plz check it
<popey> bull: we know, we know about the bug
<ogra_> yes, you complained about this for several days, several times a day ...
<ogra_> hard to not notice :P
<bull> several times a day ??
<bull> lol
<bull> i was just reminding :P liuxg
<bull> popey, yeah we tested it :P
<liuxg> bull, yeah, it takes 3 mins to remove a snap.
<bull> liuxg, not about removing snap man , it was about to kill a install process . snap wont kill install process untill it download the whole package
 * ogra_ sighs and goes for brakfast 
<liuxg> liuxg, I am still waiting for the completion of the command. I am sideload a snap. it is not downloading.
<bull> liuxg,  use snapcraft-gui
<bull> it has package manager to manage snaps
<liuxg> bull, snapgraft-gui is a desktop app, right? is it in the store already?
<bull> no
<bull> it is here https://github.com/snapcraft-gui/snapcraft-gui
<bull> repo coming soon
<bull> i developed it :P
<bull> with all convenience for snap user in mind
<bull> you can write recipes and make snaps , with clicks
<liuxg> bull, thanks for letting me know. I will try it later on.
<bull> okay
<bull> ii was having lp ppa but tsimonq2  said he will make new one with better sourcebuild features so we deleted old one
<ogra_> liuxg, so what does "snap changes" show you
<ogra_> (gimme a pastebin)
<bull> QSqlError("", "Driver not loaded", "Driver not loaded")
<bull> QSqlQuery::prepare: database not open
<bull> ogra_, can we have access to partitions  of hard disk ?? i cant see any such things in the file dialog
<ogra_> there is the home interface
<bull> home interface show partitions too ?
<ogra_> no, only files in home
<ogra_> there is no way to get such sensible info yet
<ogra_> like partitions ...
<bull> wow
<bull> thats why i cant load music from mymusic partition using vlc
<ogra_> bind mount it under your home somewhere ... i.e. into ~/Music
<bull> ogra_,  how :(
<ogra_> by bind mounting ?
<bull> yea
<bull> ogra_,  we have to do it manually before using vlc ?
<ogra_> fi you put your music into exotic places you have to make it available in a common place first, yes
<bull> :D
<ogra_> i have no probs with vlc here
<bull> exotic places :P ?
<ogra_> (and i think 90% of users wont)
<bull> you put music in home /music ?
<ogra_> yes
<bull> cool
<bull> some people do use partitions and external hd
<ogra_> good for them
<mup> PR snapd#1917 opened: tests: ensure openssh-server is installed in autopkgtest <Created by mvo5> <https://github.com/snapcore/snapd/pull/1917>
<bull> not good for them if they dont know how to load music in vlc
<bull> people will ditch whole ubuntu for vlc :D
<bull> if it will not fixed and snap will be default format :D
 * ogra_ goes away for a few hourst ... i really cant take it anymore
<bull> *some people
<bull> ogra_, LOL
<ogra_> not funny, really
<bull> yeah i have seen cases
<ogra_> if you have something constructive to tell me, fine ... if you find a bug, please file it ... but dont rave about it for hours
<bull> hi
<bull> tsimonq2, hi
<bull> with button icons is it looking sexy > https://raw.githubusercontent.com/snapcraft-gui/snapcraft-gui/master/screenshots/sc1.png
<mup> PR snapd#1918 opened: spread.yaml, tests: add adhoc-ubuntu-core spread backend <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1918>
<abeato> sergiusens, any idea why I can get this message when creating a snap? : "Copying needed target link from the system /dev/null"
<abeato> sergiusens, it created a prime/dev/null file
<abeato> which provoked some issues until I noticed
<ogra_> mvo, http://paste.ubuntu.com/23181669/ works (not actually more beautiful but i get an extra 500MB when i set WIGGLEROOM=500)
<mup> PR snapd#1919 opened: tests: make ubuntu-core tests more robust <Created by mvo5> <https://github.com/snapcore/snapd/pull/1919>
<mvo> ogra_: ok
<ogra_> mvo, oh, and ouch ... we build the core snap against proposed ...
<ogra_> mvo, but -proposed isnt in the sources.list ...
<ogra_> i currently can not install vim in classic due to that
<ogra_> (in the classic shell i mean)
<ogra_> mvo, should i stop using proposed during imagge build or should we add proposed to sources.list ?
<mvo> ogra_: I think stop using proposed is best
<ogra_> ok
<mvo> ogra_: we can also sed it out in classic.create
<mvo> (for now)
<ogra_> lets see if that builds :)
<mvo> but I think !-proposed is best
 * ogra_ drops it and does a test build
<mvo> pitti: hm, snapd (latest version)vanished from the running page for amd64 but it did not appear on the results page yet. is there a (cron) delay or something?
<pitti> mvo: wow, watching it like a hawk, aren't you :) -- there's ~ 5 minutes cron delay indeed
<pitti> mvo: still running on http://autopkgtest.ubuntu.com/running#pkg-snapd though on some arches
<pitti> mvo: could also be testbed failure, I'll check the logs in a minute
<mup> PR snapd#1920 opened: --lazy is only available with -l in trusty <Created by vosst> <https://github.com/snapcore/snapd/pull/1920>
<morphis__> pitti: can we configure netplan to generate wifi settings files via NetworkManager and ethernet ones via networkd depending on some flag we put somewhere?
<pitti> morphis__: that is the default mode indeed
<morphis__> oh really?
<pitti> morphis__: oh wait, actually not any more, default is networkd
<morphis__> can we change that somehow?
<pitti> morphis__: it used to be NM for wifi until I taught it to do wifi via networkd+wpasupplicant
<pitti> morphis__: anyway, you can select the backed for every individual definition, yes
<pitti> renderer: NetworkManager|networkd, see the manpage
<morphis__> pitti: and how can we change that on Ubuntu Core, not sure what configures this globally
<morphis__> or would that be a thing console-conf has to know about?
<ogra_> but please dont make NM a hard requirement
<pitti> you can specify the renderer globally, by device type, or by individual definition
<pitti> and you can put it into a separate yaml snippet
<ogra_> if it isnt installed on an image it netpplan needs to fall back to using wpa-supplicant
<pitti> it normally detects the availability
<ogra_> ok
<morphis__> ogra_: no :-)
<ogra_> :P
<pitti> but if you say "use NM" and NM is not installed, those definitions wil just fail
<morphis__> pitti: I see
<ogra_> right ...
<morphis__> pitti: where do I specify the renderer globally?
<pitti> morphis__: at the global yaml level, right under the top-level "network:" (again, see manpage)
<ogra_> pitti, btw, my network setup on the pi3 now goes really mad ... i'm not yet sure if thats netplan or console-conf that is at fault ... console-conf offers me both interfaces (wired and wireless) but i always end up with only wired usable
<ogra_> it works just fine on the dragonboard where i only have a wlan interface ... but having both makes something go mad
<morphis__> pitti: thanks
<mwhudson> ogra_: there is https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1623756 in this area
<mup> Bug #1623756: console-conf generates invalid config when wifi is not configured <subiquity (Ubuntu):In Progress> <https://launchpad.net/bugs/1623756>
<ogra_> mwhudson, oh, thanks !
<ogra_> yeah, i wanted to file that one but collect some more data ... just got distracted from it
<mwhudson> just sent a PR with a presumed fix, really need to get the repo made public now...
<ogra_> mwhudson, though mine is slightly different ... i actually configure it with ssid and it even obtains an IP
<mwhudson> ogra_: ah ok
<ogra_> it still tries to use wired though ... evven if i say "dont configure"
 * ogra_ will collect more data first ... perhaps it is the same cause, who knows
<mwhudson> ah hm
<mwhudson> yeah, that's certainly possible
<mwhudson> although if the wired interface is up, you remove it from the config entirely and run netplan apply, i don't know if the interface would be taken down
<mwhudson> pitti: would know
<ogra_> well, if there is no cable, it should not be tried at all
<pitti> no, apply doesn't currently down interfaces which are up
<mwhudson> oh
<ogra_> not sure if netplan takes mii state into account here
<pitti> seemed too dangerous to me
<pitti> if we want/need that, bug report please
<pitti> ogra_: you mean up, but no link beat?
<mwhudson> ogra_: how can you tell that it's being tried? sorry it's late here and i'm probably being dense
<pitti> I guess we can safely twiddle those too
<pitti> "netplan --debug apply" might be useful
<bull> Snapcraft GUI version 2.0 released with everything working :P download .deb here https://github.com/snapcraft-gui/snapcraft-gui/releases/tag/2.0
<ogra_> pitti, i mean when i boot i get offered to configure eth0 in console-conf even if there is no cable plugged in ... it shouldnt offer that i think
<pitti> hmm
<pitti> ogra_: there are routers with broken link beat
<pitti> or wifi devices have no link until you connect to an AP
<ogra_> hmm, yeah
<pitti> so I'm not sure if that's so obvious
<pitti> it coudl certainly tell you that
<pitti> en1 (disconnected)
<ogra_> yeah, i guess something like that in the UI would already help
<mup> PR snapd#1921 opened: Replace systemd-run with on-the-fly generation of units <Created by vosst> <https://github.com/snapcore/snapd/pull/1921>
<mwhudson> ogra_: sounds good, bug pls
<ogra_> yay ...
 * ogra_ can install vim again
<mup> Bug #1623897 opened: console-conf should show if wired interfaces are connected <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1623897>
<ogra_> mwhudson, ^^
<mwhudson> ogra_: thanks
 * mwhudson zzz
<ogra_> sleep well
<mup> PR snapd#1922 opened: Use apt in accordance with functionality available on trusty <Created by vosst> <https://github.com/snapcore/snapd/pull/1922>
<liuxg> is snapweb currently working already?
<mup> PR snapd#1923 opened: Replace realpath with readlink -f for trusty support <Created by vosst> <https://github.com/snapcore/snapd/pull/1923>
<bull> liuxg, checkout https://github.com/snapcraft-gui/snapcraft-gui/releases/tag/2.0
<liuxg> bull, it looks very nice. I will promote it in my place to the community :)
<bull> ty
<bull> liuxg, please create issue if you want any changes , and finds any bug
<liuxg> bull sure, I will do that. it is actually my strong point :)
<liuxg> bull, in fact, I had thought of doing this some time ago :) it is really a nice work.
<bull> thanks :) i hope you have found the project page already
<bull> hmm
<mup> PR snapd#1917 closed: tests: ensure openssh-server is installed in autopkgtest <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1917>
<mup> PR snapd#1919 closed: tests: make ubuntu-core tests more robust <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1919>
<mup> PR snapd#1915 closed: tests: add http_proxy to /etc/environment in the autopkgtest environment <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1915>
<mup> PR snapd#1916 closed: backends: first bits of kernel-module security backend <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1916>
<mup> PR snapd#1924 opened: tests: disable prepare-image-grub test in autopkgtest <Created by mvo5> <https://github.com/snapcore/snapd/pull/1924>
<mvo> mwhudson: do you happen to know what is the deal with govendor(ing) and gccgo? it seems to be not supported in 16.04 or am I just using it wrong?
<liuxg> may I know how to stop auto-update in the background? previously I could use config to disable it.
<pitti> mvo: you have a few i386 and amd64 logs now
<mvo> mwhudson: aha, I see you commented already, thank you!
<mvo> pitti: ha! close
<mvo> pitti: still one failure
<mup> PR snapd#1925 opened: Adjust regex to account for changes in stat output <Created by vosst> <https://github.com/snapcore/snapd/pull/1925>
<mup> PR snapcraft#803 closed: Do not run the bootstrap directory as a script (autotools plugin) <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/803>
<mup> PR snapd#1924 closed: tests: disable prepare-image-grub test in autopkgtest <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1924>
<mvo> pitti: hm, i386 is strange it says ppa:snappy-dev/image can not be added (it does not exist). this worked on the amd64 run
<sergiusens> abeato oh, neat! ldd for one of your elf files has that.
<sergiusens> abeato care to fgure out which one?
<abeato> sergiusens, lol
<mup> PR snapd#1926 opened: tests: add https_proxy into environment as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/1926>
<abeato> sergiusens, yes, let me look. Interestingly that happens only when building for ARM, but not for x86
<sergiusens> abeato if you can, find the offending lib and give me the ldd output for it
<abeato> ack
<abeato> sergiusens, anohter question: what does
<abeato> Issues while validating snapcraft.yaml: The '0' property does not match the required schema: ['usr/bin/Xorg'] is not of type 'string'
<abeato> mean?
<pitti> mvo: hm, that add-apt-repo call works in a i386 chroot
<sergiusens> abeato it means, remove the brackets :-)
<sergiusens> abeato is this `organize`?
<abeato> sergiusens, no brackets
<abeato> sergiusens, kind of, it works now after removing this line: "# organize: ??
<abeato> "# organize: ??"
<abeato> which I added to remind me to investigate something
<mup> PR snapd#1927 opened: Account for different PWD handling on trusty <Created by vosst> <https://github.com/snapcore/snapd/pull/1927>
<sergiusens> abeato let me get you an example
<abeato> sergiusens, a parsing error??
<sergiusens> abeato https://github.com/snapcore/snapcraft/blob/master/demos/mosquitto/snapcraft.yaml#L28
<sergiusens> abeato you are not matching the schema;; we use jsonschema that by default gives us those horrible errors and no easy way to compose our own
<abeato> sergiusens, hmm... but why does it complain for a line that is a comment?
<sergiusens> abeato oh, I see; give me the full yaml
<sergiusens> abeato the lines are off by one btw
<bull> sergiusens, can https://github.com/snapcraft-gui/snapcraft-gui/ be part of snapcraft source-code ?? please read this issue here https://github.com/snapcraft-gui/snapcraft-gui/issues/4
<abeato> sergiusens, off by one? some whitespace issue?
<abeato> sergiusens, I have found no references to something that migth pull /dev/null in the binaries... what kind of thing do you expect me to see?
<abeato> sergiusens, and why can this happen:
<abeato> Failed to clean step 'prime': Missing necessary state. This won't work until a complete clean has occurred.
<abeato> ??
<liuxg> ogra_, does Pi3 has a built-in bluetooth in it? thanks. I just try to make use of it, however, I cannot find it.
<liuxg> morphis__,  is bluetooth currently supported on pi3?
<ogra_> liuxg, pi3 has builtin BT ... but i dont know if we have all firmware and drivers yet
<ogra_> theoretically it should be the wlan firmware since i think it is the same device
<ogra_> practically i dont know though
<liuxg> ogra_, ok. thanks for your reply. I basically duplicate the same step as 410c, but it does not work. I have tried to use bluetoothctrl, but it seems that it is not working.
<bull> my bt dont work on ubuntu 16.04 :(  it was working on 14.04
<ogra_> liuxg, i'm not really sure if the kernel has all bits and pieces yet for the pi3 img
<liuxg> ogra_, yes, I see the wlan there http://paste.ubuntu.com/23182127/
<ogra_> yeah, that definiteely works
<liuxg> ogra_, currently, the bluetooth works on 410c board.
<abeato> ogra, an image on beta channel for rpi3 should work?
<ogra_> yup, i noticed that you got it working yesterday
<ogra_> abeato, yes
<abeato> ogra_, ack
<ogra_> we'll release new ones later today or tomorrow on cdimage
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/ has an interim one i just rolled for someone else
<ogra_> in case you need something to dd right now
<abeato> ogra_, thanks, will try to build one with u-d-f nonetheless
<ogra_> u-d-f is unsupported now
<ogra_> that will most likely not produce anything usable anymore
<abeato> what do we use now?
<ogra_> ubuntu-image ... and you need signed assertions
<ogra_> just grab mine from the above url
<abeato> yeah, that will be easier...
<bull> ogra_,  http://people.canonical.com/~ogra/2CAF65BCd01.jpg :D
 * zyga has a theory about what might be broken with ns sharing
<bull> bye friends :*
<morphis__> ogra_: why is HDMI output disabled on the official pi2 image?
<ogra_> morphis__, ?
<ogra_> works here
<morphis__> ogra_: I had to change the config file on the boot partition to get it
<morphis__> hdmi_safe=1
<ogra_> weird, i tested console-conf and login onn various monitors here
<ogra_> (well, two monitors and a TV)
<ogra_> hdmi_safe should only be needed if your monitor has issues with the spec i heard
<ogra_> "hdmi_safe Use "safe mode" settings to try to boot with maximum hdmi compatibility. This is the same as the combination of: hdmi_force_hotplug=1, hdmi_ignore_edid=0xa5000080, config_hdmi_boost=4, hdmi_group=2, hdmi_mode=4, disable_overscan=0, overscan_left=24, overscan_right=24, overscan_top=24, overscan_bottom=24 "
<ogra_> haha
<ogra_> "hdmi_ignore_edid Enables the ignoring of EDID/display data if your display is a crappy Chinese one "
<bull> ogra_,  bye
<bull> :Zzz
<ogra_> ciao
<ogra_> morphis__, so whats your monitor ... ?
<morphis__> ogra_: hm, it was working well before from what I remember
<ogra_> before what ?
<ogra_> i dot thinnk we have changed anything in config.txt since 6 months
<morphis__> ok
<morphis__> then its a local problem here
<ogra_> IIRC liuxg had probs as well and needed to use another HDMI port on his monitor, there it then jjust worked
<ogra_> but perhaps we should actually default to hdmi_safe to get the widest compatibility ... i'm just a bit reluctant to add display options at all since these are dev boards ... mainly used for embedded development
 * zyga -> coffee and food
<zyga> jdstrand: ping me when you are around please
<mectors> I am trying to upgrade a node-red snap to U16.04. The snap installs without problems. When I execute the snap/bin/nodered.red everything works fine but no .service is created. I am trying devmode. Don't see an error in syslog. What should I do?
<zyga> mectors: look at the apps declaration, does it define this is a deamon?
<mectors> No was a command. Will change to daemon
<qengho> mectors: You're not making that a service. You're making it an app that you can run.
<qengho> mectors: "daemon: OneOfTheDaemonTypes" underneath "command:".
<mectors> thanks
<zyga> jdstrand: http://pastebin.ubuntu.com/23182286/
<zyga> jdstrand: aka WTF?
<zyga> jdstrand: NOTE: ip in the core snap is not the one in classic
<zyga> jdstrand: not sure if this matters in what you did earlier
<zyga> jdstrand: I was also thinking if the way I pivot_root is buggy, I tweaked that locally but it has no observable effect
<zyga> jdstrand: what bugs me is that I *can* open ns/net but ip cannot
<mectors> fixed it. many thanks
<zyga> (ip the command)
<mup> PR snapd#1928 opened: hookstate,daemon: don't mock HookRunner, mock command <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1928>
<jdstrand> zyga: it is very puzzling. I mean, it worked at one point!! I downgraded kernels (even to 4.3-- pre-trusty), used a fresh install of xenial desktop without upgrading, built an image using udf with os, kernel and gadget snaps from June, etc, etc
<jdstrand> zyga: I even saw on the old xenial desktop that a new core snap was downloaded when installing hello-world so I replaced current symlink to use the old one. I think I have a few more things to play with there
<zyga> jdstrand: maybe the core snap updated?
<zyga> jdstrand: and old VMs may still have reeexec anbled
<zyga> jdstrand: as a quick exercise, I can run unshare --net=foo
<zyga> jdstrand: I can open /proc/self/ns/net from python
<zyga> jdstrand: I'm utterly lost as to what this might be
<zyga> jdstrand: quick question about pivot_root, does this change make sense: http://paste.ubuntu.com/23182323/
<zyga> jdstrand: I read what pivot_root does again and I suspect that either docs are wrong or pivot_root . . should not be used
<zyga> (this disabled nvidia binding because it's done in a way that needs the hostfs thing to be in place but I can move that to always happen after pivot root)
<jdstrand> zyga: I think tyhicks may be able to better answer that, or possibly an lxd dev
<jdstrand> (the pivot_root question)
<jdstrand> I can do it, but it'll take me a while to say for sure
<jdstrand> zyga: re the core snap updated-- it definitely did, which is why I tried to undo that. It's possible I didn't do that right and have a few more things to try there
<zyga> jdstrand: don't worry about pivot root; I'll keep digging
<tyhicks> zyga: what are you trying to achieve there?
<jdstrand> zyga: regarding the permission denied-- it is seriously puzzling
<zyga> tyhicks: use pivot_root correctly
<zyga> tyhicks: perhaps avoid one more bind mount
<zyga> tyhicks: ignore pivot_root unless you think it affects the big ns issue
<zyga> tyhicks: I don't know if you are in the loop
<zyga> tyhicks: if you want we can sync quickly
<jdstrand> I need to look at another PR and will circle back
<zyga> ok
<tyhicks> I'm probably not up on what you've been up to the last day or two
<tyhicks> the lxd devs will definitely have more real world experience w/ pivot_root than I do
<zyga> tyhicks: long story short: the kernel behaves in super odd ways wrt net namespace; with snap-confine built from pull request https://github.com/snapcore/snap-confine/pull/145 "ip netns" gets permission denied to open /proc/$pid/ns/net (as shown by strace on http://pastebin.ubuntu.com/23182286/) but nothing apparently prevents this if you just try to open it directy (see the pastebin)
<mup> PR snap-confine#145: Enable snap-confine namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/145>
<zyga> this is all with devmode
<zyga> tyhicks: and in that pastebin I also don't understand why this fails:
<zyga> fstat(4, 0x7fff7fe39650)                = -1 EACCES (Permission denied)
<zyga> 4 is stderr after dup()
<zyga> might that be some kernel memory corruption?
<tyhicks> I don't know much about network namespaces but that strace sure does look odd
<tyhicks> let me think about it a little more
<mup> PR snapd#1929 opened: Return proper icon URL for non-installed snaps <Created by jamiedbennett> <https://github.com/snapcore/snapd/pull/1929>
<tyhicks> zyga: I don't have any good ideas about what's going on there
<tyhicks> zyga: I'd have to spend quite a bit of time reading kernel code
<zyga> tyhicks: ok, thanks
<jdstrand> zyga: ok, I've circled back
<jdstrand> I'll keep plugging away at trying to see when this once worked and try other things that I think of along the way
<jdstrand> zyga: that said ^, there is perhaps something else to consider. the fact that this isn't working is odd to be sure, but this test (ip netns ...) working within a snap may not be as important if we think about the long term goal: a network-namespace-support interface that allows snaps to add network namespaces to the system and for other snaps to use
<zyga> jdstrand: hmm
<zyga> jdstrand: for that we'd have to solve the bi-directional mounting in general
<jdstrand> zyga: in other words, since we know that network-namespace-support is the desired goal, if we can figure out how to achieve that without fixing this oddity, maybe that's ok
<zyga> jdstrand: or do you plan snapd to create the namepaces centrally?
<jdstrand> that's up for discussion
<zyga> jdstrand: ok, so what shall we do
<jdstrand> it seems clear that people will want to use 'ip netns' to setup namespaces. lots of existing code does that
<jdstrand> our 'ip' command could be modified to talk to snapd
<zyga> jdstrand: I'm inclined to merge this, add more spread tests
<zyga> jdstrand: for both working and OMG/WTF broken cases
<zyga> jdstrand: and decide if we want to enable this for release or not
<mup> PR snapd#1924 opened: tests: disable prepare-image-grub test in autopkgtest <Created by mvo5> <https://github.com/snapcore/snapd/pull/1924>
<mectors> just uploaded nodered.mectors. Says it is published but can't see it in the uApp Explorer or install it via snap install.
<kyrofa> mectors, did you publish it in a specific channel?
<mectors> no just did snapcraft push
<kyrofa> mectors, are you familiar with channels?
<mectors> kyrofa pushing it to stable now
<kyrofa> mectors, ah very good, okay
<kyrofa> mectors, so yeah, you can snapcraft push to specific channels, or snapcraft release after the fact, or do it all in from the myapps site
<kyrofa> s/all in/all/
<kyrofa> But snapcraft push by default doesn't put it in any channels
<mectors> kyrofa I updated the channel to stable on myapps but nothing. it says it passed all 40 checks there
<mectors> kyrofa sorry my mistake was trying nodered.mectors but nodered works
<kyrofa> mectors, good deal!
<kyrofa> ev, I've been noticing numerous misunderstandings stemming from the fact that the store shows <snapname>.<publisher> in the header. Is there a reason for leaving it that way?
<ev> kyrofa: no, there isnât and as Iâve come across that myself Iâve considered it part of the task to switch from âshort namespacesâ to SSO usernames, but theyâre orthogonal.
<shuduo> matteo: hi, so you can see embedded wifi interface with your image/kernel, right? do you see it in console-conf phase?
<zyga> jdstrand: it is quite easy to crash the kernel with various mount calls
 * zyga hugs VMs
<sergiusens> mectors next time, you can do `snapcraft release <snap-name> <revno-from-store> <channel>`
<matteo> shuduo: hi
<sergiusens> kyrofa hey, you don't push to channels, you release to channels ;-)
<matteo> shuduo: you mean the web interface? yes
<shuduo> matteo: do you use pi2-kernel?
<matteo> let me check
<matteo> pi2-kernel   4.4.0-1021-3  14   canonical  -
<zyga> matteo: hey :)
<mup> PR snapd#1929 closed: Return proper icon URL for non-installed snaps <Created by jamiedbennett> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1929>
<matteo> hi zyga
<sergiusens> wow cjwatson, thanks for taking that macaroon task!
<cjwatson> sergiusens: np, it happened to hit me and I already have code in LP that does much the same thing
<shuduo> ogra_: hi, i'm following the doc "Ubuntu Core Image building" and generated an image for pi3. Now I see some issues like:
<shuduo> 1, it booting up time is very long if I plug ethernet cable. if no ethernet cable, it can boot up to console-conf soon. Is it a known issue?
<ogra_> nope, definitely not known
<shuduo> 2, I can't see integrated wireless interface, is it a known issue? I use pi2-kernel.
<matteo> shuduo: do you want my ubuntu core image and openwrt snap?
<ogra_> yes, the wifi interface is only seen in very recent console-conf versions ... in the edge channel
<ogra_> but it doesnt not work right yet
<matteo> I'm using ethernet to access internet, and the wifi as AP
<ogra_> shuduo, http://people.canonical.com/~ogra/snappy/all-snaps/u-image-pi3.img.xz
<shuduo> matteo: yes, pls.
<shuduo> ogra_: okay, let me try your image too.
<matteo> shuduo: I'm pushing everything here: https://people.canonical.com/~teknoraver/
<ogra_> shuduo, we'll release an image like that this week
<matteo> zyga: why this test fails, in your opinion= http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-yakkety-snaps-cloud/5/console
<shuduo> ogra_: good to know. we want to demo openwrt snap with pi3 at end of Sept. it would be great if later image do everything well. :)
<ogra_> well, there are still issues with wlan vs eth on the pi3 ... but these should surely be fixed before end of the month :)
<zyga> matteo: looking
<zyga> ah, vpn
<matteo> ping mvo
<mvo> matteo: pong (with some latency, but I will read/reply eventually)
<matteo> I have an unit test which fails in an odd way
<matteo> maybe it's not related to my commit
<matteo> so you may want to have a look
<matteo> mvo: http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-yakkety-snaps-cloud/5/console
<mvo> matteo: fix in git should actually be fixed in yakkety already
<matteo> so if I trigger a new test it will pass?
<kyrofa> sergiusens, I mean the push command supports releasing as well, no?
<sergiusens> kyrofa yes it does, `snapcraft push <snap-file> --release <channel>`
<sergiusens> kyrofa that's release on push, not push to a channel though ;-)
<kyrofa> sergiusens, meh :P
<sergiusens> stgraber any way to figure out what is going on here? http://paste.ubuntu.com/23183087/
<stgraber> sergiusens: hmm, well, LXD forks tar and tar got sigkilled, not sure why
<stgraber> sergiusens: out of memory maybe?
<stgraber> sergiusens: anything in dmesg?
<sergiusens> stgraber yeah, out of mem; strange
<sergiusens> I am on a fresh boot
<stgraber> oh, actually, that's unsquashfs not tar for that image I guess
<sergiusens> stgraber yup
<sergiusens> [  598.420356] Out of memory: Kill process 8056 (unsquashfs) score 506 or sacrifice child [  598.420664] Killed process 8056 (unsquashfs) total-vm:645224kB, anon-rss:260812kB, file-rss:0kB
<stgraber> how much memory do you have on that system?
<stgraber> unsquashfs using 260MB of RAM while not light doesn't seem entirely unreasonable to me
<sergiusens> stgraber ah, I have 512
<stgraber> how many CPUs in /proc/cpuinfo?
<sergiusens> stgraber just the one http://paste.ubuntu.com/23183119/ its a DO droplet
<stgraber> weird, not sure why unsquashfs would use more memory than the size of the whole image
<mup> PR snapd#1928 closed: hookstate,daemon: don't mock HookRunner, mock command <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1928>
<stgraber> sergiusens: I'm testing some unsquashfs options to work on low memory systems
<stgraber> sergiusens: running on a 64MB system now with 48 cores, so kinda worst case scenario :)
<sergiusens> stgraber yeah, this used to work before, I guess before the move to squash, more so, I have 3 containers here running fine
<stgraber> sergiusens: hmm, so I managed to launch a container using a squashfs image just fine on that crazy 64MB system...
<stgraber> sergiusens: unsquashfs memory use was showing at 40MB or so
 * stgraber pokes things harder
<mup> PR snapd#1914 closed: docs: add a little documentation on hooks <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1914>
<mup> PR snapd#1888 closed: interfaces: allow special casing for auto-connect until we have assertions <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1888>
<mup> PR snapd#1924 closed: tests: disable prepare-image-grub test in autopkgtest <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1924>
<kgunn> kyrofa: hey there, so i'm seeing something really interesting...
<kyrofa> kgunn, yeah what's up?
<kgunn> we've got a snap we're building that's pretty big admittedly...unity8...and it pulls in qtmir
<kgunn> so the qtmir pkgs are there in the snap on amd64
<kgunn> however, on arm64
<kgunn> they are missing....
<kgunn> this is true for a snap that was built with lp builders and then one built in a cross build chroot locallly
<kgunn> and...to boot...the one built locally
<kgunn> the files are in stage and prime!
<kgunn> but not in the snap
<kgunn> ....oh, and i just added qtmir pkgs specifically to part as stage (using nil plugin)
<kgunn> and they still didn't make the snap
<kgunn> any ideas?
<kyrofa> Hmm
<kgunn> AlbertA: ^
<kyrofa> If files are in prime, they should 100% definitely be in the snap
<kyrofa> Because making the snap is literally running mksquashfs on the prime dir
<kyrofa> kgunn, so something is weird here
<kgunn> kyrofa: don't suppose you know if you can verify what's in the prime from launchpad ?
<kyrofa> kgunn, unsquashfs the resulting snap. I can't think of a single way the prime dir could be different
<kgunn> AlbertA: wanna shoot me link for arm64 version one more time from the chroot that definitely had the qtmir stuff in prime?
<AlbertA> kgunn: yeah it's
<kgunn> just to make sure
<AlbertA> https://private-fileshare.canonical.com/~alberto/unity8-session_0_arm64.snap
<kyrofa> kgunn, when you say qtmir, are you talking about qtdeclarative5-qtmir-plugin? Or qtmir-desktop?
<kyrofa> kgunn, doesn't matter-- both of them are in there
<kgunn> right
<kyrofa> kgunn, so am I missing something?
<kgunn> kyrofa: one sec....got distracted lemme install and check
<kgunn> kyrofa: so upon install of that same snap on my dragonboard i get
<kgunn> ubuntu@localhost:/snap/unity8-session/current$ sudo find -iname qtdeclarative5-qtmir-plugin
<kgunn> ./usr/share/doc/qtdeclarative5-qtmir-plugin
<kgunn> ubuntu@localhost:/snap/unity8-session/current$
<kyrofa> kgunn, that makes sense, no?
<kyrofa> kgunn, find -iname libunityscreensplugin.so should find the lib contained within that package as well
<kgunn> kyrofa: sorry i meant this one
<kgunn> ubuntu@localhost:/snap/unity8-session/current$ sudo find libqpa-mirserver*
<kgunn> find: âlibqpa-mirserver*â: No such file or directory
<kgunn> ubuntu@localhost:/snap/unity8-session/current$
<kgunn> kyrofa: ah...yeah, i see it now
<kgunn> ubuntu@localhost:/snap/unity8-session/current$ sudo find -iname libqpa*
<kgunn> ./usr/lib/aarch64-linux-gnu/qt5/plugins/platforms/libqpa-mirserver.so
<kgunn> ./usr/lib/aarch64-linux-gnu/qt5/plugins/platforms/libqpa-ubuntumirclient.so
<kgunn> the damn "minus" sign i forgot find get's angry
<kyrofa> Hahaha
<kyrofa> So does that all look okay then?
<kgunn> kyrofa: yes....now i probably made a stink over nothing
<kgunn> i bet the lp built one is fine
<kgunn> kyrofa: fwiw, we did really have one at one point where it wasn't included....so it got us all amped
<kgunn> i think it was a fluke
<kgunn> ...and we verified the pkgs weren't there in the sstage/prime area...
<kyrofa> kgunn, heh, well if you run into it again, let me know!
<kgunn> yeah, see something once like that, makes you all paranoid...
<stgraber> sergiusens: https://github.com/lxc/lxd/pull/2383
<mup> PR lxc/lxd#2383: Tweak squashfs for low-memory systems <Created by stgraber> <https://github.com/lxc/lxd/pull/2383>
<stgraber> sergiusens: with that change in place, I could get LXD to mostly work on a system with just 64MB of RAM
<stgraber> sergiusens: mostly in the sense that container creation worked fine, but as soon as the container started, the OOM killer started killing everything :)
<stgraber> sergiusens: though that was when running a full Ubuntu in the container, something like busybox would have run without triggering OOM kills I expect
<sergiusens> stgraber great, in the meantime I upped the mem for my droplet :-)
<stgraber> sergiusens: ok, you could have put a simple wrapper around unsquashfs in /usr/local/bin setting the same options I set in that patch
<sergiusens> stgraber I will try your branch later tonight and get back to you to see how it went
<stgraber> sergiusens: ok. it should be fine since I got it to run on a system with just 64MB :)
<mup> PR snapd#1930 opened: many: support snapctl -h <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1930>
<chiluk> hey guys I'm still trying to learn snappy, and I'm trying ot snap up the file command, because I thought it would be simple
<chiluk> this is what I have so far http://paste.ubuntu.com/23183657/
<chiluk> but whenever I go to run file after installing my snap I get /etc/magic, 0: Warning: using regular magic file `/usr/share/misc/magic'
<chiluk> file: could not find any valid magic files!
<chiluk> I tried to explicitly copy the configs per https://github.com/owncloud/ubuntu-snap/wiki/Building-your-first-snap and got http://paste.ubuntu.com/23183708/   but I get the same results.
<chiluk> what am I missing here?
<chiluk> I guess I'll send mail to the mailing list.
<mup> PR snapcraft#804 opened: Adjust login to conform to UX specification <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/804>
<mwhudson> ogra_: https://github.com/CanonicalLtd/subiquity is public now fwiw
<jdstrand> morphis: fyi, I approved udisks2 but you need to press the publish button
<ahoneybun> was there a change in snapd that you can install a snap that is not signed?
<ahoneybun> *can't
<lpotter> ahoneybun: yes there was. add --force-dangerous
<ahoneybun> thanks lpotter
<ahoneybun> tried to install a inkscape snap from LP and it failed because of a missing signature
<ahoneybun> is it "snap install --force-dangerous?
<lpotter> yes
<sergiusens> stgraber that did the trick btw
<stgraber> sergiusens: cool
#snappy 2016-09-16
<mup> PR snapcraft#800 closed: LP: #1623509 nodejs: fix to install dev-deps in build phase <Created by jonathon-love> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/800>
<pbek> ogra_: I just wanted to report that the snap updates for QOwnNotes now work automatically after Launchpad published them to the Ubuntu Store, thanks a lot. I released 16.09.8 this morning...
<Sid_> Is there a way to automatically create a snap from a launchpad build recipie ... At the moment it's asking me to build the yaml ...I guess the information is there in the control file and make lists...
<mup> PR snapd#1931 opened: patch: fix patch4 transition <Created by mvo5> <https://github.com/snapcore/snapd/pull/1931>
<mup> PR snapd#1932 opened: add HACKING.md and move content from README.md over <Created by mvo5> <https://github.com/snapcore/snapd/pull/1932>
<mup> Bug #1571497 changed: snapd crashes on slot disconnection <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1571497>
<mup> Bug #1571497 opened: snapd crashes on slot disconnection <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1571497>
<mup> PR snapd#1931 closed: patch: fix patch4 transition <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1931>
<mup> Bug #1624265 opened: Ubuntu Core pi3 image booting up hang at 4 icons <Snappy:New> <https://launchpad.net/bugs/1624265>
<ogra_> mvo, so what about that release ? want me to do it ? we cant do a new ubuntu-core promotion anyway until console-conf behaves, so i guess waiting for the ARU wont get us much further anyway
<ogra_> s/ARU/SRU/
<mvo> ogra_: sru happend this morning
<ogra_> mvo, yes, but how would that help ?
<mvo> ogra_: new snapd 2.15 is in the ppa, so this part is ready
<mvo> ogra_: what is the issue with console-conf?
<ogra_> it doesnt generate a network config at all on the pi3 currently
<ogra_> (well, it does, but after reboot it is gone)
<mvo> ogra_: is that a regression?
<ogra_> well, it is there since wifi support was added
<ogra_> so yes and no
<mvo> hm, tricky
<ogra_> (regression in new feature)
<mvo> so with the old console-conf it was possible to get working wired networking on the pi3?
<ogra_> you get all the wifi stuff in the UI and it behaves just fine, but after reboot the config is gone
<mvo> if so and the new one does not manage that then I think its a regression and thats bad :/
<ogra_> yes
<mvo> so even wired network does not work on the pi3? or will that part work?
<mvo> ogra_: do you know what the status of that is? is mwhudson working on it?
<mvo> (or someone else?)
<ogra_> i have to check with todays edge, but i think its bogus all the way
<mvo> hm hm
<mwhudson> the non-persistence should be fixed with new snapd
<ogra_> he is looking into various wifi issues (last screen doesnt show teh IP for ssh)
<mvo> mwhudson: aha, cool
<ogra_> (some issue with SSIDs)
<mwhudson> https://github.com/CanonicalLtd/subiquity/pulls <- some fixes here
<ogra_> (and the persistence)
<mwhudson> i wanted cyphermox to review and land and do a release
<mwhudson> but if there's some urgency i can merge them anyway...
<mvo> ogra_: I would love to make a new beta image based on snapd 2.15 and with a new snapweb (that actually starts at boot), lool made some really nice fixes here
<ogra_> so the new snapd in the PPA should fix the persistence ? i'll do a quick image test ...
<mvo> ogra_: uploaded only some minutes ago, not sure if its published in the ppa yet
<mwhudson> ogra_: if it has https://github.com/snapcore/snapd/pull/1901 in it
<mup> PR snapd#1901: firstboot: do not overwrite any existing netplan config <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1901>
<mvo> ogra_: but please do and let me know, I go and work on snapweb now for a bit to see if I can make it releasable
<ogra_> ok
<mvo> mwhudson: that is in
<mwhudson> ok
<ogra_> mwhudson, what abotu the last screen not showing the login data
<mwhudson> ogra_: i think that's fixed by accident by https://github.com/CanonicalLtd/subiquity/pull/162
<mup> PR CanonicalLtd/subiquity#162: Indicate if a wired interface is connected or not <Created by mwhudson> <https://github.com/CanonicalLtd/subiquity/pull/162>
<mwhudson> ogra_: my theory is that console-conf doesn't re-probe to get the new addresses properly
<ogra_> hmm, ok
<ogra_> i guess thast not in the PPA package yet ?
<ogra_> heh, i didnt get tzo read bugmail yet ... i see you answered on all my bugs :)
<mwhudson> yeah, not in ppa yet
<mup> PR snapd#1933 opened: store: add "ready to buy" method <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1933>
<ogra_> mvo, snapd just published in the PPA ... i triggered a new ubuntu-core ...
<om26er> Hi! where does pip and npm fall in the snappy world, can I install pip packages today on a Ubuntu Core system ?
<ogra_> both are used by snapcraft when building a snap AFAIK
<popey> stgraber: broke lxc again... error: not found (not a fingerprint, partial fingerprint (first 12 chars) or valid alias)
<ogra_> you really need to stop beating it with a club all the time :)
<popey> :(
<cking> hi, I've got 3 snaps been waiting for review for ~1 week, eventstat, forkstat and powerstat, can they be looked at for me? thanks
<ogra_> if they went to review something is surely wrong ?
<cking> ogra_, like they exist in the main repo, so I have a name clash
<cking> s/repo/archive/
<ogra_> you mean you didnt claim the names before uploading ?
<cking> ogra_, I've claimed the names and it's now marked "pending review"
<ogra_> you mean the name request ?
<ogra_> weird
<cking> i'm even the upstream developer, so it should be easy to claim stuff I own and package ;-)
 * cking just keen to get the latest crack out
<ogra_> mvo, mwhudson, very weird, i dont get wlan offered at all on the pi3 with the latest edge image
<mup> PR snapd#1934 opened: many: refresh all snap decls <Created by pedronis> <https://github.com/snapcore/snapd/pull/1934>
<ogra_> hmm, and no credentials even for wired now ...
<ogra_> thats bad
 * ogra_ tries again 
<ogra_> same on the dragonboard ... no credentials on last screen
<ogra_> pi3 shows them on second try
<cjwatson> ~/wg 54
<cjwatson> sorry
<cking> ogra_, so I assume I just wait until somebody eventually allows me to upload my snaps oneday?!
<ogra_> well, i havent seen such issues with name registration ... and i dont knwo who our contact for EU timezone in the store team is
<cking> ah, OK :-/
<ogra_> i guess you need a store person ... are you actualyl sure the name isnt actually registered for you already ? if you try to register twice that might cause an issue
<cking> pretty sure I've not registered twice, well, it's not a big rush, just a nice to snap kinda thing
<ogra_> well, if you did, it would show that on the store page for your upload at the bottom i think
<ogra_> (teh store UI is really good hiding things at the bottom ... scrolled off the screen)
 * cking has a look
<cking> nah, it's not got a link to it, it's black, no link and "Pending review", so kinda stuck at that
<popey> cking: approved
<cking> popey, woot, my here
<cking> *hero
<cking> \o/
<ogra_> mvo, so there seems to be a race with console-conf on the pi3 now ... it doesnt show wlan0 at all ... another thing is, if you reset the board hard before console-conf did write anything, firestboot goes all mad and you can throw away the image
<ogra_> (wlan shows up in 7proc/net/dev after i configured wired network and rebooted)
<mup> Bug #1624322 opened: console-conf wlan race on pi3 <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1624322>
<ogra_> mvo, so bug 1623119 seems fixed at least ...
<mup> Bug #1623119: wlan setup done by console-conf not persistent <Snappy:Invalid> <nplan (Ubuntu):Invalid> <subiquity (Ubuntu):Invalid> <https://launchpad.net/bugs/1623119>
<ogra_> mvo, but bug 1623120 hits hard on the dragonboard
<mup> Bug #1623120: console-conf does not show ssh credentials on last page when wlan is involved <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1623120>
<ogra_> mvo, and bug 1624322 on the pi3 ... but here we can resort to recommend to only use wired networking
<mup> Bug #1624322: console-conf wlan race on pi3 <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1624322>
<mup> Bug #1624329 opened: snapd firstboot setup fails constantly when rebooting before console-conf has finished <Snappy:New> <snapd (Ubuntu):New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1624329>
<ogra_> mvo, so i'd say we can release but with a big fat hint that wifi config is still pretty much broken ... and with pointers to all these bugs above
<ogra_> OH !
<ogra_> thats a new one
<ogra_> ogra@pi3:~$ sudo snap install classic --devmode --edge
<ogra_> error: cannot install "classic": cannot get nonce from store: Post https://myapps.developer.ubuntu.com/identity/api/v1/nonces: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers
<ogra_> eeek ... seems there is no resolver set up :/
<ogra_> woah ... and i have two default routes ... thats gross
 * ogra_ takes a break
<mup> PR snapcraft#805 opened: Refresh discharge macaroon if necessary <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/805>
<mvo> ogra_: if core is build, I would like to promote it to "beta"
<mvo> ogra_: any concerns aobut this?
<ogra_> mvo, well, see my babbling in the last hour above :P
<ogra_> there are three serious bugs ... that we should mention in the announcement ... beyond that i think we are fine
<ogra_> and i think none of them affect an already installed system, so updates shoould be fine too
<mvo> ogra_: aha, so all wireless broken but the rest is ok(ish)?
<mvo> ogra_: I think thats ok, its still a beta (or even pre-beta) but it looks encouraging
<ogra_> well, wireless is semi broken ... on the dragonboard it works just fine but console-conf doesnt show the IP ....
<ogra_> on the pi3 there is some weird race between console-conf and the wlan device coming up
<ogra_> which makes everything else weird
<mvo> ogra_: ok
<ogra_> but yeah, i think we are good, but should mention the issues
<mvo> ogra_: if you have a running system, could you please "sudo snap refresh --edge snapweb" and reboot and check if snapweb:4200 comes up?
<mvo> ogra_: ++
<ogra_> mvo, btw, bug 1624329 is a really bad one ... it actually forces you to do a fresh dd if console-conf doesnt finish
<mup> Bug #1624329: snapd firstboot setup fails constantly when rebooting before console-conf has finished <Snappy:New> <snapd (Ubuntu):New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1624329>
<mvo> ogra_: oh, fun, I can only promote ubuntu-core to beta now, not stable, is there something with confinement: devmode somewhere?
<ogra_> sadly hard to debug without being able to log in
<ogra_> i dont have a running system from the last image, but i can snap install snapweb quickly ...
<mvo> ogra_: ta, I will also test
<ogra_> comes up right after install
 * ogra_ reboots to see if it comes up on boot too
<ogra_> uuh ... snapweb UI still allows me to remove the kernel
<mvo> ogra_: do we set "grade: devel" somewhere?
<ogra_> mvo, looks good ...
<mvo> ogra_: \o/
<ogra_> i have to check what we set in ubuntu-core ...
<ogra_> yeah
<ogra_> ubuntu-core has garde:devel atm
<mvo> ogra_: I think we want to not set this, we want ubuntu-core to be able to get to stable
<mvo> ogra_: not important right now, but probably soon(ish)
<ogra_> well, i can change it right now ... next build will ppick it up
<ogra_> we dont set grade at all for the kernels ... so whatever snapcraft puts in place is used there
<ogra_> mvo, long term we need to stop using the PPA built ubunt-core for anything else but the stable channel anyway ... we'll have multiple builds once i killed the PPA
<ogra_> err
<ogra_> for anything else but the edge channel ... indeed
<ogra_> the build coming only from the archvive will then be grade: stable
<mvo> ogra_: yeah
<qengho> I kept SSH running to my RPi3 last night so I could discover why it's dark and dead after many hours. I thought it was crashing somehow. But it's not. Last night I got a new "ubuntu-core" (634) from edge, and it set a 10-minute reboot timer, and then shut down. It never recovered. Network and console are dead until I unplug and re-plug.
<ogra_> mvo, snapweb on arm64 looks good too
<ogra_> qengho, file a bug (worked here)
<qengho> ogra_: file a bug on what?
<qengho> ubuntu-core?
<ogra_> qengho, dunno, snappy in general for a start
<qengho> Okay.
<ogra_> i.e. see topic :)
<qengho> I guess we don't have a bug tracker for snaps themselves. I wonder if we will.
<ogra_> well, having one for ubuntu-core would be nonsense ...
<ogra_> and others can define their bugtracker in the store
<ogra_> there is a "support url" you can set up
<ogra_> uappexplorer actually exposes it as a clickable link ... i hope one day snapweb will too
<mup> PR snapcraft#806 opened: Remove snapcraft.storeapi.common <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/806>
<ogra_> qengho, btw, an rpi without serial cable is useless ... get one and you can actually debug such issues ... ssh wont help
<ogra_> (it really needs to become company policy that people getting *any* devboard also get a matching serial cable)
<qengho> Canonical didn't pay for this. I'm just nice.
<ogra_> ah
<qengho> I have a keyboard and HDMI display directly attached.
<ogra_> yeah, wont help wither
<ogra_> *either
<qengho> Even after setting boot params?
<ogra_> embedded boards need serial if you want to do proper debugging ... they are ... well ... embedded ... and usually used headless ... even if people start abusing them in other ways (like running desktops)
<qengho> I guess so. I hadn't considered my retail Pi3 to be a development board.
<ogra_> on the pi the prob is that the console suspends at some point ... regardless ... so the above reboot prob can only really be debugged with serial attached ... unless you are sitting next to the board while it does the auto-reboot
<mup> Bug #1624371 opened: pi3 never recovers from ubuntu-core refresh <Snappy:New> <https://launchpad.net/bugs/1624371>
<ogra_> qengho, oooh ... you used an ancient all-snaps image ... yeah, thats not expected to work at all
<qengho> Dang.
<qengho> Okay, getting the ~mvo 10-day-old one.
<ogra_> qengho, no, wait a bit
<ogra_> we're in the middle of doing a release
<ogra_> (especially since we had to pull back the last pi3 one due to xz corruption)
<mup> Bug #1624265 changed: Ubuntu Core pi3 image booting up hang at 4 icons <Snappy:Invalid> <https://launchpad.net/bugs/1624265>
<mup> Bug #1624371 changed: pi3 never recovers from ubuntu-core refresh <Snappy:Invalid> <https://launchpad.net/bugs/1624371>
<mup> PR snapcraft#807 opened: Fix parts integration tests <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/807>
<sitter> I am having trouble with content sharing. I am trying to get my content interface under /kf5 in the consuming snap but have a permission error: cannot mount /snap/kde-frameworks-5/x8 at /snap/yomo/x13/kf5 with options bind,ro. errmsg: Permission denied
<sitter> https://paste.kde.org/pd8l5excq content interface https://paste.kde.org/puxumufie app
<mup> PR snapcraft#808 opened: Don't litter /tmp with test artifacts <Created by josepht> <https://github.com/snapcore/snapcraft/pull/808>
<zyga> jdstrand: hey
<zyga> jdstrand: around by any chance? :)
<jgdx> do I need to set XDG_DATA_DIRS manually to e.g. $SNAP/usr/share or does this happen automaticall?
<jdstrand> zyga: I am
<zyga> jdstrand: I'm chasing that kernel bug, I feel I get an idea what this may be about
<zyga> jdstrand: I'll know after the next reboot
<jdstrand> oh
<zyga> jdstrand: the tracking bug is https://bugs.launchpad.net/snap-confine/+bug/1624300
<mup> Bug #1624300: Cannot open /proc/self/ns/net <Snappy Launcher:Triaged> <https://launchpad.net/bugs/1624300>
<jdstrand> that's curious
<zyga> jdstrand: I'll update it with my findings
<jdstrand> yes, I saw your bug
<zyga> (I had a crash course in kernel development last night)
<jdstrand> nice :)
<zyga> jdstrand: the thing I know for sure is that this is *not* related to nsfs
<zyga> but to fs permissions actually
<zyga> well, more data after next reboot
<zyga> I got into the devel feedback cycle now
<jdstrand> if it is the kernel, I'm going to immediately wonder why it ever worked and why downgrading didn't help, but I'm definitely all ears
<zyga> jdstrand: that I cannot answer yet
<kyrofa> sitter, hey, have you tried sharing sub-directories rather than the entire snap? Do you get the same error?
<sitter> hm
<sitter> kyrofa: no error if I use expose read: [usr] rather than /
<zyga> kyrofa: there was a bug in older snap-confine
<zyga> kyrofa: use a subdirectory please
<sitter> zyga: can I wildcard instead?
<zyga> sitter: no
<sitter> meh
<zyga> dpb, jdstrand, mvo: https://github.com/snapcore/snapd/pull/1935
<mup> PR snapd#1935: interfaces/apparmor: allow reading /etc/environment <Created by zyga> <https://github.com/snapcore/snapd/pull/1935>
<sitter> mhall119: http://mhall119.com/2016/09/sharing-is-caring-with-snaps/ you may want to update that given exposing / doesn't work anymore :)
<zyga> sitter: I personally fixed that bug
<mup> PR snapd#1935 opened: interfaces/apparmor: allow reading /etc/environment <Created by zyga> <https://github.com/snapcore/snapd/pull/1935>
<zyga> sitter: I don't know if the fix got SRUd
<zyga> sitter: but it is fixed in master for sure
<zyga> sitter: or maybe it is another thing
<zyga> sitter: do you have a denial/error message or anything I can look at?
<sitter> all I get is permission error: cannot mount /snap/kde-frameworks-5/x8 at /snap/yomo/x13/kf5 with options bind,ro. errmsg: Permission denied
<sitter> I can get you more output if you tell me how ;)
<mhall119> sitter: can you link to your snapcraft.yaml for both?
<zyga> sitter: which version of snap-confine do you have?
<mhall119> sitter: it was fixed for the way I was using it
<sitter> zyga: Version: 1.0.38-0ubuntu0.16.04.8
<zyga> sitter: and look at dmesg/journalctl for the interesting apparmor denial
<ogra_> mhall119, see above, he pastebinned it already
 * mhall119 scrolls
<zyga> jdstrand: can you please review and merge https://github.com/snapcore/snapd/pull/1935
<mup> PR snapd#1935: interfaces/apparmor: allow reading /etc/environment <Created by zyga> <https://github.com/snapcore/snapd/pull/1935>
<mhall119> sitter: can you pastebin /etc/apparmor.d/usr.lib.snapd.snap-confine
<sitter> zyga: Sep 16 15:59:01 smith kernel: audit: type=1400 audit(1474034341.962:76): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/snap/yomo/x20/kf5/" pid=27361 comm="ubuntu-core-lau" srcname="/snap/kde-frameworks-5/x10/" flags="rw, bind"
<sitter> mhall119: https://paste.kde.org/pgou4aa9l
<mhall119> sitter: ah, you don't have that fix
 * sitter shakes fist
<mhall119> zyga: https://paste.kde.org/pgou4aa9l#line-120 he still has the older mount permissions that didn't work with a snap's root
<zyga> mhall119: correct
<zyga> sitter: you can fix this locally with a simple patch and one command run
 * zyga gets back to debugging the kernel
<mhall119> zyga: don't be a tease, tell him the patch and command :-P
 * mhall119 remembers the patch, but not the commant
<sitter> well. I'd rather have a fix :P
<sitter> I can't really sell a patch to my fellow lazydevs ^^
<zyga> sitter: use a subdirectory (even dummy) for now, I'll ensure the update is released
<mhall119> true, zyga do you know if there's an SRU in the works?
<zyga> mhall119: no, because I'm debugging kernel to make it releaseble
<sitter> I have another question though... http://snapcraft.io/docs/reference/interfaces suggests that the read property of the slot would be an array. the target property of the plug is a string though?
<zyga> sitter: they are both strings for now
<zyga> well
<zyga> each one is
<zyga> well, let me just look
<sitter> :)
<zyga> they are both arrays
<zyga> sorry for the confusion
<sitter> so the documentation probably needs a fix to indicate that :)
<mup> PR snapd#1936 opened: asserts: revert change that made the account-key's name mandatory <Created by emgee> <https://github.com/snapcore/snapd/pull/1936>
<sitter> I am going to roll with subdirs for now. thanks
<mup> PR snapd#1937 opened: image: ensure local snaps are put last in seed.yaml  <Created by mvo5> <https://github.com/snapcore/snapd/pull/1937>
<mup> PR snapd#1935 closed: interfaces/apparmor: allow reading /etc/environment <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1935>
<mthaddon> can anyone point me at a place to track support for snaps on trusty?
 * ogra_ hands mthaddon a cable with a plug to tvoss' brain interface
<mthaddon> haha - I was meaning is there a bug or feature request somewhere on it?
<tvoss> mthaddon: not really, we have a trello card but I do not know if that's publicly available
<mthaddon> ok thanks - is do you have a rough idea of when it might happen? Would it be worth me filing a bug about it?
<tvoss> mthaddon: I'm proposing required changes to snapd as we speak
<mthaddon> sweet
<tvoss> mthaddon: the ppa I'm using for testing purposes is here: https://launchpad.net/~thomas-voss/+archive/ubuntu/trusty
<mthaddon> thx muchly
<zyga> ogra_: ohh, brain interface
<zyga> I must connect that one next time I'm debugging things
<tvoss> zyga: bit painful in the beginning, but hey
<tvoss> mthaddon: http://pastebin.ubuntu.com/23186546/ should get you off the ground
<ogra_> :D
<zyga> tvoss: that looks like something snap-confine could do to test in soread
<zyga> spread*
<mthaddon> thx
<tvoss> zyga: wow, snap-confine can test brain interfaces? ;)
<zyga> tvoss: the test may fail on Friday though
<xnox> $ sudo snap install appx
<xnox> sudo: unable to resolve host repackappx
<xnox> 74.93 MB / 74.93 MB [===============================================================] 100.00 % 4.42 MB/s
<xnox> error: cannot perform the following tasks:
<xnox> - Mount snap "ubuntu-core" (423) ([start snap-ubuntu\x2dcore-423.mount] failed with exit status 1: Job for snap-ubuntu\x2dcore-423.mount failed. See "systemctl status "snap-ubuntu\\x2dcore-423.mount"" and "journalctl -xe" for details.
<xnox> )
<xnox> ..
<xnox> i can't install snaps inside a lxd container?
<SamYaple> jdstrand: has there been anymore developments behind 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>
<tvoss> xnox it certainly fails in chroot, systemd refuses to play along nicely
<tvoss> zyga: would certainly fail over here
<jdstrand> SamYaple: not to my knowledge. I think people have been focusing on GA (but I'm not assigned to it or doing the assigning)
<zyga> jdstrand: I traced the error we're seeing to apparmor
<SamYaple> jdstrand: thats about to be a real blocker to me in packaging openstack, do you know someone I could reach out to to have a chat about it?
<zyga> sforshee: o/
<sforshee> zyga: o/
<zyga> jdstrand, sforshee: so I think I wrapped my head around the bug now, I guess I'll need you and tyhicks to guide me further
<zyga> the root cause is apparmor and this ALLOWED (but really not) message:
<zyga> Sep 16 17:01:45 xenial-server audit[5944]: AVC apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="snap.snapd-hacker-toolbelt.busybox//null-/home/zyga2/snap-confine/spread-tests/xfail/lp-1623400/bug" name="" pid=5944 comm="bug" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<zyga> this is allowed but we really see -13, aka EACCES
<mup> PR snapd#1934 closed: many: refresh all snap decls <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1934>
<zyga> to confirm this you can use devmode snapd-hacker-toolbelt, run it with sudo and switch the profile to unconfined with aa-exec
<zyga> so I see two things here that are odd:
<zyga> 1) apparmor is in complain mode and says ALLOWED but we still get -13
<jdstrand> I wonder if it has something to do with nnp
<zyga> 2) how do we not get the disconnected path, I suspect I messed up pivot_root somehow
<zyga> nnp?
<jdstrand> NO_NEW_PRIVS
<zyga> mmm
<zyga> how can I quickly check that? is that in snap-confine's aa profile
 * zyga looks
<jdstrand> fyi, on 15.04 snappy vm I am able to open the file
<zyga> jdstrand: I'll try with snap-confine master
<zyga> to see if this is a new issue
<jdstrand> it shouldn't be new
<zyga> jdstrand: I'd love to get some advice as to where to look in apparmor kernel sources to see why issue 1) may happen (if my theory is right)
<jdstrand> ie, not introduced in the recent pr, but sure
<jdstrand> zyga: would needs tyhicks or jjohansen
<zyga> jdstrand: master is affected the same way
<zyga> jdstrand: I'll check back before we did pivot_root
<jdstrand> ok
<jdstrand> if I add 'file,' to the complain mode profile, it works
<zyga> hmm?
<zyga> I don't understand what that means, can you explain please
<tyhicks> it means there's probably a file access rule that needs to be added to the profile
<jdstrand> zyga: install hello-world snap in devmode. add to /var/lib/snapd/apparmor/profiles/snap.hello-world.sh 'file,'. apparmor_parser -r ... ; hello-world.sh, then ip netns list
<jdstrand> tyhicks: well, it is complain mode
<tyhicks> jdstrand: the attach-disconnected flag is already present on the profile?
<jdstrand> yes
<jdstrand> profile "snap.devmode.sh" (attach_disconnected,complain) {
<zyga> jdstrand: what is the meaning of the 'file,' rule?
<jdstrand> if I remove 'file,' and reload, ir fails. if I add it and load, it works
<jdstrand> zyga: allow all file access
<zyga> hmmm
<zyga> well, that's a big cannon
<jdstrand> well, sure
<jdstrand> the point is, I just narrowed it down to file rules in complain mode
<jdstrand> well, we did
<zyga> ok, I see now
<zyga> so what do you think we should do next,
<zyga> I'd like to understand why apparmor runs into this error, why is /proc disconnected
<mup> PR snapd#1936 closed: asserts: revert change that made the account-key's name mandatory <Created by emgee> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1936>
<zyga> (and is it /proc/self/ns/net or everything in proc/self/ns)
<tyhicks> how do you know that it is /proc?
<zyga> tyhicks: nothing else seems to fail, it just affects open() on that file
<tyhicks> zyga: ah, I misunderstood - what's the full path? /proc/self/ns/net?
<zyga> tyhicks: https://bugs.launchpad.net/snap-confine/+bug/1624300
<mup> Bug #1624300: Cannot open /proc/self/ns/net <Snappy Launcher:Triaged> <https://launchpad.net/bugs/1624300>
<jdstrand> /proc/** does not allow it
<tyhicks> zyga: ok, so /proc/ is probably not disconnected but the target of the ns symlink is
<tyhicks> zyga: which is some virtual "ns:[NNN]" reference
<zyga> tyhicks: snap-confine doesn't touch that
<zyga> tyhicks: and it happens even without the recent work towards namespace sharing
<jdstrand> we aren't getting good logging
<tyhicks> jdstrand: there's not much to log, unfortunately
<zyga> jdstrand: I printk'd my way around procfs, it is nothing there
<tyhicks> jdstrand: apparmor is asking the vfs to look up this path and the vfs is saying that it can't
<zyga> jdstrand: I'd like to look at apparmor next
<jdstrand> oh weird
<sforshee> tyhicks: in what sense? The kernel can resolve the path to an inode in nsfs
<jdstrand>  /** ix, allows it
<tvoss> mthaddon: let me know how it goes, I will grab dinner now but I'll be around later
<tyhicks> sforshee: I can't claim to know all the technical details of apparmor's disconnected path issues - we'll have to have jj here for that :/
<tyhicks> sforshee: it happens in aa_path_name() -> d_namespace_path()
<zyga> jjohansen: ^^
<mthaddon> tvoss: I won't have time to test just yet, but will let you know if I find time next week - thx
<zyga> jjohansen: if you are around we could use a hand
<tyhicks> zyga: he pulled an all nighter - he won't be around for a while
<sforshee> tyhicks: thx, I'll take a look
<zyga> I know the feeling
<jdstrand> /{bin,sbin}/ip ix,
<jdstrand> that allows it ^
<zyga> oh?
<tyhicks> wut
<zyga> jdstrand: so might it be that
<zyga> it is not the namespace
<zyga> it is the executable?
<zyga> wat?
<jdstrand> that also answers why the reporter had it working-- he was connecting the network-control interface even though it was in complain mode
<jdstrand> ok, that part of the mystery is solved
<zyga> but how come it fails for a simple reproducing C program?
<zyga> jdstrand: I still don't get it can you tell me how allowing ip fixes it?
<jdstrand> it has to do with the exec transition
<jdstrand> if we don't have the ix rule for the binary that is accessing /proc/self/ns/net, then it fails even in complain mode
<zyga> jdstrand: (I just checked that it doesn't fix it if another program, say "bug", compiled from bug.c somewhere in home tries to access it
<tyhicks> I have to step away for a little bit
<zyga> tyhicks: o/
<jdstrand> zyga: sure. add an ix rule for your bug program
<jdstrand> I'll do so now. I bet it will work
<zyga> jdstrand: sure but why does that fix it? is it becasue aa cannot find /home somehow?
 * zyga tries
<jdstrand> well, again, that is the mystery and the bug
<jdstrand> I'm just trying to narrow this down
<zyga> jdstrand: yes, confirmed!
<zyga> ah, ok, I thought you cracked that one :)
<zyga> ok
<zyga> so I think there are two consequences:
<jdstrand> @{HOME}/Desktop/open-proc-self-ns-net ix,
<nothal> jdstrand: No such command!
<zyga> 1) we can merge ns sharing without thinking it breaks something
<jdstrand> if I add that ^, it works. if I don't, it doesn't
<zyga> 2) we have to look at apparmor deeper to figure out what is broken
<jdstrand> zyga: do one '1'
<jdstrand> err
<jdstrand> do '1'
<zyga> :-)
<zyga> yep, that will be my pleasure
<jdstrand> we can say in the LP bug on namespace sharing that there is an apparmor bug which requires people to use and connect network-control even in --devmode
<zyga> jdstrand: btw, I managed to crash the stock xenial kernel with a few bind mounts yesterday, ran out of memory looping on something
<jdstrand> cool :)
<zyga> jdstrand: I'll look at /media sharing next so I'll try to reproduce and report it
<zyga> jdstrand: if you give me your blessing on https://github.com/snapcore/snap-confine/pull/146 I'll do a release
<mup> PR snap-confine#146: Use sanity timeouts around blocking operations <Created by zyga> <https://github.com/snapcore/snap-confine/pull/146>
<jdstrand> zyga, tyhicks: I'll file a bug on the exec transition issue, with a reduced test case
<zyga> jdstrand: thank you, please dupe the bug I reported
<tyhicks> ok, I'm back
<jdstrand> zyga: thank you for looking into this so much. that was a really weird bug. I'm glad that I thought to try on 15.04. cause 15.04 doesn't have devmode, I just added a bunch of rules (like 'file,') and saw it worked. then I was like-- "huh-- I wonder if it is just one of those..." :)
<zyga> jdstrand: there's only one thing left worrying me:
<tyhicks> jdstrand: I'm glad we have a workaround but, boy, I'm confused about it
<zyga> https://github.com/snapcore/snap-confine/pull/133
<mup> PR snap-confine#133: Adjust apparmor policy for compatibility with snap-exec <Created by zyga> <https://github.com/snapcore/snap-confine/pull/133>
<zyga> this doesn't fail for me in qemu (for sanity I just started another run)
<zyga> but fails all the time in linode
<zyga> and we cannot release without it as snapd now uses snap-run/snap-exec
<jdstrand> tyhicks: hopefully with the reduced test case it will get people to zero in quickly on the problematic code
<tyhicks> zyga: are we sure that the linode environment has an up-to-date Ubuntu xenial kernel and apparmor package?
<jdstrand> zyga: you are saying that on linode, if you unapply 133 that the tests pass with no problem, but when you apply it the fail undeterministically?
<zyga> tyhicks: great question, I bet it doesn't
<zyga> jdstrand: yes
<jdstrand> I bet some of the nodes are up to date and some aren't
<zyga> jdstrand: though test still "pass" because the snapd there is not using snap-run/exec I suspect
<zyga> jdstrand: they all share one image
<zyga> jdstrand: and my qemu image is 3 days old
<zyga> jdstrand: I'll see if I can get gustavo to refresh that next week
<zyga> if it works in qemu again I'll merge it with a note describing this
<tyhicks> the unsafe stuff requires apparmor 2.10.95-0ubuntu2.2 and it'll also behave differently from kernels prior to xenial to xenial kernels
<jdstrand> zyga: I can't explain why if what you are saying is correct (every node has the same kernel and apparmor) why it would sometimes pass
<zyga> jdstrand: no, it never passes
<zyga> jdstrand: it always fails in linode
<jdstrand> ah
<jdstrand> ok
<mup> PR snapcraft#807 closed: Fix parts integration tests <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/807>
<zyga> jdstrand: and always works in qemu
<jdstrand> yes, make sure those images are up to date
<jdstrand> that makes a lot more sense then
<zyga> tyhicks: I'll update dependency in the packaging
<tyhicks> something doesn't sound right about the linode env
<tyhicks> zyga: ok, let me double check that version before you do so
<zyga> thank you
<tyhicks> zyga: you should depend on 2.10.95-0ubuntu2.2 or newer
<qengho> jdstrand: refresh to get GPUness.
<jdstrand> \o/
<zyga> jdstrand: quick question, do we need to add anything to snapd's interfaces or base profile to unblock "ip netns" to work/
<zyga> mvo: did you do the 2nd release today yet?
<qengho> jdstrand: You know much about the "personality" syscall? I have a C-compiled regular snap that uses it (and thus gets an mightly slaying) on ARMHF only, and I don't know why, and I'm trying to decide if there's something wrong or if compiling differently would avoid it.
<jdstrand> zyga: I don't think so. network-control already use the ix rule for ip
<jdstrand> I'me going to double check that though
<mvo> zyga: no, still waiting for final tests
<zyga> mvo: ok, I think we're good :)
<zyga> jdstrand: I just confirmed too, woot
<zyga> what a fantastic way to finish the week friends :)
<jdstrand> yeah
<jdstrand> what a weird bug
<jdstrand> I'm really glad we figured out why it worked on the mailing list too. that was a very puzzling mystery
<zyga> btw, this is still a bug in apparmor, regardless of the disconnected path thing
<jdstrand> I literally couldn't stop thinking about how to get the original test case to work again
<jdstrand> oh yes
<jdstrand> totally
<zyga> as EACCES bleeds through apparmor complain mode
<jdstrand> and we can fix it
<zyga> I'll have a stab at this over weekend, maybe my printk-based deduction will lead me to it ;-)
<jdstrand> but much of the mystery is gone and we have a workaround that is fairly natural
<zyga> indeed, it's surprising it didn't hit us earlier though
<jdstrand> well, not really
<zyga> and I still don't understand how the location of the executable influences the problem
<jdstrand> no one is using namespaces within snaps much
<jdstrand> well, lxd
<jdstrand> hmm
<zyga> for instance it worked in python3 because that had the workaround you found naturally in the base template
<jdstrand> oh, they have a bare file rule
<jdstrand> and docker I think has the ip command
<zyga> but is it *just* for nsfs or is it a general issue?
<jdstrand> seems just nsfs
<jdstrand> I mean, you can open regular files all day long in complain mode
<jdstrand> that we would have definitely heard about
<zyga> well, still some mystery as to what is going on there :)
<jdstrand> well, perhaps it is a proc thing
<zyga> next week I'll work on media sharing and, perhaps, on live namespace updates
<jdstrand> no, not just proc. it does seem nsfs
<jdstrand> anyhoo
<zyga> feels great to move on :)
<jdstrand> a little bit, but jj will be able to see the problem I bet pretty quickly
<jdstrand> zyga: indeed! :)
<jdstrand> zyga: wrt 146, I was surprised about the alarm surronding the flock()s (not saying it is wrong). can you explain your thinking there>
<jdstrand> ?
<mup> Bug #1611444 changed: Cannot share a namespaces created with 'ip netns' between apps in a devmode SNAP <Snappy Launcher:Fix Committed by zyga> <Snappy:Invalid by zyga> <https://launchpad.net/bugs/1611444>
<zyga> yes, if the child process survives the parent for any reason
<zyga> it may lurk around forever holding the flock alive
<zyga> this just ensures that, for *whaever* reason, if there are bugs an the child doesn't die
<zyga> we don't hang forever but die
<zyga> I suspect we could just keep the timers in the child
<zyga> with the same effect
<jdstrand> I looked at 146 only a little bit the other day and had that question and thought I'd ask. I'll take a closer look
<plars> I asked on #juju but also asking here as I'm not sure if this is a juju or snapd problem, but I'm getting stuck deploying an instance on xenial. It appears it's stuck in the upgrade of snapd because it hasn't finished running 'snap booted' after a very long time.
<zyga> hmm, interesting, the unsafe transitions don't fail as before
<zyga> but now I see this:
<plars> Is there some known problem with this?
<zyga> cannot change apparmor hat of the support process for mount namespace capture. errmsg: Operation not permitted
<zyga> support process for mount namespace capture exited abnormally
<zyga> plars: I think mvo is the person you want
<zyga> plars: I think it might be
<jdstrand> zyga: there should be a denial for that
<zyga> jdstrand: I'm still mid way my run in qemu
<zyga> it hasn't reached that point yet
<zyga> jdstrand: do I need any unsafe transition markers for the child and the hat?
<mvo> plars: I think this is https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621336
<mup> Bug #1621336: snapd.boot-ok.service hangs eternally on cloud image upgrades <oil> <verification-needed> <cloud-init (Ubuntu):Fix Released> <snapd (Ubuntu):Triaged> <cloud-init (Ubuntu Xenial):Fix Committed> <snapd (Ubuntu Xenial):In Progress> <https://launchpad.net/bugs/1621336>
<jdstrand> have to see the log entry
<zyga> jdstrand: spread run in lindoe didn't have it, I hope qemu will
<plars> mvo: that looks like exactly what I'm seeing :(
<mvo> plars: looks like xenial-proposed has a fixed cloud-init
<zyga> ok, key test running now
<zyga> jdstrand: it's good in qemu, I'll ignore it and work on upgrading the linode kernels
<jdstrand> zyga: ok, cool
<zyga> ok
<zyga> I've merged everything but the timer
<zyga> I *need* a break now
<zyga> I will work on packaging and downstream testing to see if we're missing anything
<zyga> and if it all goes green I'll release it upstream tomorrow
<zyga> and start pushing updates to debian, ubuntu, arch, fedora and gentoo
 * zyga EODs (for once, on time)
<zyga> sforshee, jdstrand, tyhicks: thank you for your help!
<jdstrand> zyga: enjoy your weekend and go see your family! :)
<zyga> :-(
<zyga> I won't see them till november
<jdstrand> oh gosh
<jdstrand> I thought they were in the next roomn
<zyga> they are in spain and I stayed to sprint almost all october
 * jdstrand hugs zyga 
<jdstrand> go video chat with them then :)
<zyga> I'll go out and see some friends though
<zyga> I need to see real people, faces, not walls of my office
<jdstrand> zyga: have some fun! you deserve it :)
<mup> PR snapcraft#806 closed: Remove snapcraft.storeapi.common <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/806>
<mup> Bug #1624490 opened: Snap access to /dev/uinput <hardware> <snapd-interface> <uinput> <Snappy:New> <https://launchpad.net/bugs/1624490>
<arges> hi. I just upgraded snapd to 2.15, and installed a snap and got: cmd_run.go:179: WARNING: cannot create user data directory: cannot create "/home/ubuntu/snap
<arges> after this I tried upgrading ubuntu-core-launcher and then things worked correctly. So is this a known issue? Should snapd depend on a certain version of ubuntu-core-launcher?
<mup> PR snapcraft#804 closed: Adjust login to conform to UX specification <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/804>
<jdstrand> tyhicks (cc zyga and jjohansen): https://bugs.launchpad.net/apparmor/+bug/1624497
<mup> Bug #1624497: complain mode blocks access to nsfs (/proc/self/ns/*) without exec rule <AppArmor:New> <https://launchpad.net/bugs/1624497>
<tyhicks> jdstrand: thanks for the nice writeup
<tyhicks> jdstrand: jjohansen has some urgent work on his plate today so this is something that he'll probably have to wait until next week to triage
<jdstrand> tyhicks: thanks. totally understood. I tried to make it clear in the bug that there is a workaround available. also, the new snap-confine that fixes bug #1611444 (ie, the ns sharing pr) won't land in xenial til next week or so anyway
<mup> Bug #1611444: Cannot share a namespaces created with 'ip netns' between apps in a devmode SNAP <Snappy Launcher:Fix Committed by zyga> <Snappy:Invalid by zyga> <https://launchpad.net/bugs/1611444>
<mcphail> Hi. What plug do I give a snap for sound? I have tried "audio" and "sound". Would it be "alsa"?
<mcphail> That doesn't seem to work either. Is there a list of interfaces somewhere?
<lpotter> you can get a list of available interfaces that are on your system by doing snap interfaces
<mcphail> lpotter: thanks! I'll try "pulseaudio" :)
<mup> Bug #1624533 opened: app can't reach USB smart-card device <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1624533>
<mup> PR snapd#1938 opened: asserts: check that validation assertions are signed by the publisher of the gating snap <Created by pedronis> <https://github.com/snapcore/snapd/pull/1938>
<lool> ogra_: you wouldn't happen to have a recent image for rpi2?   O:-)
<ogra_> lool, gimme a bit ...
<ogra_> mvo wanted to release a set today, not sure why he didnt
 * mcphail has just packaged tombraider as a snap! If only it could be released to the store...
<lool> ogra_: last minute snapd bug preventing it
<lool> ogra_: fix is submitted
<lool> ogra_: IIUC, interfaces are not well connected on first boot
<ogra_> ah
<lool> so bad user experinece
<lool> I wouldn't care about it though
<ogra_> so ont image related
<ogra_> *not
<ogra_> i'm pushing to http://people.canonical.com/~ogra/snappy/all-snaps/ ... give it 5min
<lool> awesome
<ogra_> done ... enjoy
 * ogra_ is afk again ... 
<lool> mwhudson: FYI https://drive.google.com/a/canonical.com/file/d/0B5RxJIi-SaMdTVB3emo4SjNGUHM/view?usp=sharing when waiting for too long before entering email  :-)
<lool> ogra_: thanks a ton man!
<lool> ogra_: you rock  :)
<mhall119> is there a snappy ubuntu core image for the raspberry pi 3? I know the image for the rpi2 will work, but I'd like to get one that will get the wifi and bluetooth working ootb
<mhall119> actually, can anbody confirm that the rpi2 image works on the 3?
<lool> mhall119: yes, there's a pi3 image
<lool> mhall119: no the pi2 image shouldnt work there
<lool> mhall119: http://people.canonical.com/~ogra/snappy/all-snaps/ is best you can get until monday where beta images will be rerolled
<mhall119> thanks lool
#snappy 2016-09-17
<mwhudson> lool: yay
<mup> Bug #1624675 opened: Please add network-namespace interface <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1624675>
<mup> Bug #1624676 opened: ERROR cannot remove snap file "kicad-dev-snap", will retry in 3 mins: umount: /snap/kicad-dev-snap/x6: mountpoint not found <Snappy:New> <https://launchpad.net/bugs/1624676>
<SamYaple> im having a bit of trouble with getting something to work without the 'copy' plugin. What is the expected way to rearrage files when building? For example, I have one file in the wrong place, it installs to /etc/config.conf but i need ot move it to /etc/config/config.conf
<SamYaple> i did this with the copy plugin by doing ../../../parts/<blah> but I can't do that with the dump plugin. so im just wondering the best way to handle this
#snappy 2016-09-18
<FJKong> hi, when I am trying to run snapcraft push xxx.snap, I got the error message like Received 403: '{"error_list": [{"message": "Developer has not signed agreement.", "code": "user-not-ready"}]}'
<FJKong> what should I do next?
<shuduo> FJKong: i guess you need sign developer code of launchpad
<FJKong> shuduo: already done, still need wait for days?
<shuduo> FJKong: how about upload via web version snap store?
<mup> PR snapcraft#809 opened: make plugin: improve artifact copying (LP: #1624798) <Created by jaymell> <https://github.com/snapcore/snapcraft/pull/809>
<mup> PR snapcraft#810 opened: nodejs plugin: Add mechanism to run ânpm runâ commands <Created by RAOF> <https://github.com/snapcore/snapcraft/pull/810>
<arj> hello
<arj> anyone my friend here
<cjwatson> FJKong: go to https://myapps.developer.ubuntu.com/dev/agreements/new/
<cjwatson> shuduo: it's not a Launchpad thing
<FJKong> cjwatson: okay, I will check it , TNX
<FJKong> cjwatson: if I want to register a package which is reserved, what kind of situation will approve the request?
<cjwatson> FJKong: I think a store admin has to sort it out, but I don't really know the details, sorry
<cjwatson> (the fact that I answer one question doesn't mean I know the answer to all questions :-) )
<FJKong> cjwatson: thanks
<FJKong> at least the first question is sloved :)
<FJKong> s/sloved/solved
<ogra_> FJKong, would probably make sense to file a bug at https://bugs.launchpad.net/developer-portal/+filebug that the error message should include the link cjwatson gave you ...
<FJKong> ogra_: nice
<ogra_> (hmm, probably developer-portal is the wrong project, but the people working on the store should see it or get the bug in the end)
<shuduo> ogra_: hi, what's formal way to pack gadget snap now? does the command "snappy build" still work or something else?
<cjwatson> ogra_: I thought there was one already
<ogra_> shuduo, nope, a) the snappy command is gone and b) snap build doesnrt actually exist ... use "snapcraft snap $directory"
<ogra_> cjwatson, ah, i didnt check :)
<shuduo> ogra_: got it. thanks.
<ogra_> that is how we build the gadgets at http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
<Fl1nt> Hi guys, is there a way for a snap to retrieve HW informations without any manual/interactive step?
<wililupy> Hello. I am trying to install a snap on my new build of Ubuntu-Core 16 and I get the following error:
<wililupy> error: cannot find signatures with metatdata for snap "my.snap"
<wililupy> Is there a new way to build a snap where I have to sign it as part of the build process and if so, how do I do  that within snapcraft?
<mcphail> wililupy: just use the --force-dangerous flag on install
<wililupy> I tried --force-dangerous, but it downloads ubuntu-core and gives me an error saying: cannot set next boot: cannot determine bootloader
<wililupy> and fails
<wililupy> mcphail: I think this stems from a bigger issue where ubuntu-core doesn't think it's ubuntu-core on my device since it is not showing any installed snaps with snap list...
<mup> Bug #1624913 opened: Ubuntu-Core does not list any snaps on newly installed device <Snappy:New> <https://launchpad.net/bugs/1624913>
<zyga> mwhudson: hey
<zyga> mwhudson: I'm done with the upstream release work, I'll look at collab-maint now :)
<ogra_> wililupy, smells like your gadget isnt correct
<ogra_> or  the model assertion is wrong ...
<ogra_> (that causes the firstboot job to not run, so the image gets never properly initialized)
<mwhudson> zyga: morning
<mup> Bug #1624829 opened: There is no way to contact snap package developer <Snappy:New> <https://launchpad.net/bugs/1624829>
<mcphail> Hi. Is there an equivalent to the $SNAP_USER_DATA directory which doesn't change with every package revision? I need a constant place for my game's save files, which need to be accessible even if the snap updates
<liuxg> does anyone know how to access the snapweb?
#snappy 2017-09-11
<mup> PR snapcraft#1399 closed: ruby plugin: new plugin <Created by jamesbeedy> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1399>
<mup> PR snapcraft#1544 opened: plugins: add the ruby plugin <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1544>
<zyga-ubuntu> good morning
<zyga-ubuntu> mvo: hello
<mup> PR snapd#3888 closed: osutil: adjust StreamCommand tests for golang 1.9 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3888>
<mvo> hey zyga-ubuntu - good morning
<zyga-ubuntu> mvo: hey, I managed to solve my zesty problem. I added some details to https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716034
<mup> Bug #1716034: Network manager stops managing Ethernet links after upgrade <network-manager (Ubuntu):Confirmed> <https://launchpad.net/bugs/1716034>
<zyga-ubuntu> mvo: I'm curious if you have the file: /etc/NetworkManager/conf.d/10-globally-managed-devices.conf
<mvo> zyga-ubuntu: not on my laptop
<mvo> zyga-ubuntu: but on my workstation
<mup> PR snapd#3895 opened: osutil: adjust StreamCommand tests for golang 1.9 (2.28) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3895>
<zyga-ubuntu> mvo: interesting, I bet you have non-empty netplan config somewhere
<mvo> zyga-ubuntu: possible, but that file is empty on my workstation
<mvo> zyga-ubuntu: a second look at 3865 would be great, iirc this was something you suggested :)
 * zyga-ubuntu looks
<mup> PR snapd#3859 closed: packaging/fedora: Ensure vendor/ is empty for builds and fix spec to build current master <Created by Conan-Kudo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3859>
<abeato> hm, has anybody seen this:
<abeato> - Setup snap "se-test" (unset) security profiles (cannot setup seccomp for snap "se-test": error: cannot parse line: cannot parse token "u:root" (line "chown - u:root g:root"))
<abeato> ?
<mup> PR snapd#3896 opened: packaging/fedora: Ensure vendor/ is empty for builds and fix spec to build current master (2.28) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3896>
<mvo> abeato: can you tell me more about this please?
<mvo> abeato: the output of `snap version` and `snap list --all` would be great (pastebin)
<abeato> mvo, was using latest from master
<mvo> abeato: this looks like snap-seccomp and snapd got out of sync somehow but I wonder how that is possible nowdays
<abeato> mvo, quite weird output: http://paste.ubuntu.com/25513197/
<mvo> abeato: and `snap version` ?
<mvo> abeato: ohhh
<abeato> master
<mvo> abeato: are you running snapd from master in your local tree?
<abeato> yeah
<mvo> abeato: aha, I think that is the problem, you will need to build snapcore/snapd/cmd/snap-seccomp and copy that to /usr/lib/snapd/
<mvo> abeato: iirc there is a "make hack" command
<abeato> mvo, oh, I see, I have to update that
<abeato> mvo, ok, will try, thanks
<mvo> abeato: yeah, easiest might be: "cd cmd; make hack"
<mvo> abeato: there is no "make unhack" but "apt install --reinstall snapd" will take care of this
<abeato> core system, but no worries, will just backup old seccomp
<mvo> abeato: ok, good luck and let me know if I can help in any other way
<abeato> sure, thanks!
<zyga-ubuntu> mvo: done
<mup> PR snapd#3865 closed: many: provide systemd.MockSystemctl() helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3865>
<mvo> zyga-ubuntu: \o/ thank you
<mvo> zyga-ubuntu: 3892 is an easy win now that 3865 is merged
<zyga-ubuntu> ok
<zyga-ubuntu> mvo: done
<mvo> zyga-ubuntu: ta!
<zyga-ubuntu> mvo: I was thinking if any tests would need a systemd.Mock() that would call the two and install NOP functions
<zyga-ubuntu> mvo: that was my initial idea but now I see that the fine-grained mockers are useful as well
<zyga-ubuntu> mvo: thank you for doing this work!
 * zyga-ubuntu -> school again
<zyga-ubuntu> kissiel: hey :)
<kissiel> zyga-ubuntu: yo
<mup> PR snapd#3897 opened: systemd: do not run auto-import and repair services on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/3897>
<Chipaca> belated good morning all
<Chipaca> i was just reading the news and wanted to congratulate us on getting snapd running on android
<Chipaca> even though it's strange that autoimport on android only works on vfat and ext4
<Chipaca> /end sarcastic rant about the news getting the wrong end of circular sticks
<zyga-ubuntu> Chipaca: hello
<zyga-ubuntu> Chipaca: oh? where did you get that?
<Chipaca> zyga-ubuntu: http://news.softpedia.com/news/canonical-aims-to-bring-its-ubuntu-snappy-technologies-to-android-devices-517677.shtml
<Chipaca> and linkedin was the one that pointed me at that, with "your contact Gustavo Niemeyer is in the news" or sth like that
<pedronis> bootloaders are hard
<zyga-ubuntu> "The seccomp argument filtering was re-enabled in this release of Snapd, which renames the "snap change" command to "snap tasks," adds new "search" alias for the "snap find" command, adds support for displaying snap types under..."
<zyga-ubuntu> some weird sentence
 * mwhudson o/
<zyga-ubuntu> mwhudson: hey
<mup> PR snapd#3894 closed: many: fix TestSetConfNumber missing an Unlock and other fragility improvements <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3894>
<zyga-ubuntu> "Perhaps Snap has problems on other partition types: RTFS, EXT3, NTFS, ... ? This shows some of the difficulties with other operating systems: IOS, Windows, etc. The "competitors" to Snap should be facing similar problems: Pacman, Java, etc."
 * zyga-ubuntu stops reading comments
<itsfemme[m]> Can snapd update itself?
<ogra_> itsfemme[m], it does all the time
<ogra_> (when installing your first snap, snapd also installs the core snap ... the core snap ships snapd inside ... if the snapd in the core snap is newer than the ony installed from your distro package snapd will re-exec itself to the ne from core)
<ogra_> s/ony/one/
<ackk> hi, running snapd build from master I get errors like this: 2017/09/11 09:45:57.034353 helpers.go:152: cannot regenerate seccomp profile for snap "hello-world": error: cannot parse line: cannot parse token "u:root" (line "chown - u:root g:root")
<ackk> this happens both at snapd start and when I try to install a local snap (which makes the install fail)
<pedronis> Chipaca: #3884 is a cleanup you maybe can look at that when you are not otherwise busy
<mup> PR #3884: store: simplify api url config <Created by atomatt> <https://github.com/snapcore/snapd/pull/3884>
<ogra_> ackk, are you running from maste because you added a local patch ?
<ackk> ogra_, yes
<ackk> ogra_, fwiw http://paste.ubuntu.com/25513563/ is the error I get at install
<ogra_> ah, then i'll leave that to zyga-ubuntu :) (if you just wanted to run maste, refreshing your core snap to edge would be sufficient)
<ackk> ogra_, fwiw I'm quite confident my change has nothing to do with it
<mwhudson> anyone have any guesses what is happening here? https://launchpadlibrarian.net/336570963/buildlog_snap_ubuntu_xenial_amd64_subiquity_BUILDING.txt.gz
<mwhudson> it passes in a local cleanbuild
<ackk> zyga-ubuntu, hi, do you have any idea about the issue above?
<pedronis> mvo: core transition tests are again failing sometimes
<zyga-ubuntu> ackk: perhaps, where are you running this?
<pedronis> mvo: https://travis-ci.org/snapcore/snapd/builds/274077647?utm_source=github_status&utm_medium=notification
<zyga-ubuntu> (snap version is best output)
<Chipaca> pedronis: nice, thank you
<ogra_> mwhudson, tried adding lsb-release to your build-deps (just for laughs) ?
<mwhudson> ogra_: it's already there, i think it's that that's messing things up
<mwhudson> somehow
<ogra_> hmm
<ackk> zyga-ubuntu, http://paste.ubuntu.com/25513578/ in a xenial LXD
<mwhudson> ogra_: that's what i said :)
<ogra_> heh
<zyga-ubuntu> ackk: snapd unknown?
<ackk> zyga-ubuntu, well as said it's built from master
<zyga-ubuntu> which architecture is that?
<zyga-ubuntu> ackk: aha
<ackk> zyga-ubuntu, amd64
<zyga-ubuntu> ackk: I cannot context swap too much today, can you wait 30 minutes please?
<ackk> zyga-ubuntu, sure
<mwhudson> let's see if dropping lsb-release from deps helps...
<mwhudson> oh wait, no lsb-release is not in build-deps
<ogra_> mwhudson, note that we explicitlly remove lsb_release from core, so if this is supposed to run on core eventually you rather want to read /etc/os-release instead
<mwhudson> ogra_: this is subiquity so until/unless curtin can install core...
<mup> PR snapd#3898 opened: Add bcm type detection <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3898>
<mvo> pedronis: looking
<mvo> pedronis: some of the errors might be because the store had a HW issue recently
<pedronis> mvo: yes, a couple are 504  from the store, but wondering about the transition one
<pedronis> there's not a log there though
<pedronis> :/
<mwhudson> ogra_: ah, i had lsb-release in stage-packages but not build-packages, fixing that fixed the build
<mvo> pedronis: hm, not this one I assume https://travis-ci.org/snapcore/snapd/builds/274077647#L6046 (that is a 504)
<ogra_> :)
<mvo> pedronis: or am I looking at the wrong error log?
<pedronis> I was confused, the log is separate now?
<mvo> pedronis: not sure, I'm confused now too :) sorry, I thought I had clicked on the failure log that you mentioned earlier, but when I click that now I just see "Hang tight, the log cannot be shown until the build has started."
<mvo> pedronis: fwiw, master is also failing with some 504s
<pedronis> mvo: I squash merged #3894 btw, you marked it for 2.28 so IÂ suppose you want to make a cherry-pick ?
<mup> PR #3894: many: fix TestSetConfNumber missing an Unlock and other fragility improvements <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3894>
<mvo> pedronis: yes, thank you!
<pedronis> mvo: #3777 needs a master merge?
<mup> PR #3777: snap-repair: implement basic `snap-repair list` (with --verbose) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3777>
<mvo> pedronis: yes, let me do that
<mup> PR snapd#3899 opened: many: fix TestSetConfNumber missing an Unlock and other fragility improvements (2.28) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3899>
<pedronis> mvo: the store downloads have still some problems, so tests will be a bit more bumpy for a while more
<mvo> pedronis: yeah, thats ok. thanks for the heads up
<mvo> pedronis: I had to open 3899, the cherry pick did not apply cleanly
<pedronis> ok, will look
<mvo> pedronis: should be super trivial, but when it does not apply cleanly I cherry-pick, resolve and push as a new branch to get the benefit of the spread run
<pedronis> ah, the settle stuff
<mwhudson> uh why are store uploads not working
<mwhudson> eg https://code.launchpad.net/~canonical-foundations/+snap/subiquity/+build/79418
<mvo> mwhudson: it could be a side effect of a HW failure that happen recently in the datacenter
<ogra_> well, you have an oops
<ogra_> give it to wgrant or cjwatson :)
 * wgrant looks
<wgrant> Very probable that it's related to the hardware failure
<wgrant> mwhudson: Yeah, that'll be the hardware failure. A retry should work.
<wgrant> We have people in the DC now bringing up replacement hardware.
<mwhudson> wgrant: ok
<wgrant> I hadn't realised that was actually failing uploads, ugh.
<wgrant> Must be due to Swift communication.
<mwhudson> ah yes retry worked
<mwhudson> if i have to retry the upload i'll have to do the release-to-channel bit myself, right?
<wgrant> Sorry about that. It's the PS4.5 IR from 2017-09-09 FYI
<wgrant> Hm, shouldn't have to.
<wgrant> I'd expect it to still autorelease.
<mwhudson> ah ok
 * zyga-ubuntu waits for spread run to finish
<zyga-ubuntu> how do I publish this now...
<mwhudson> ah yes auto-release happened
<ackk> zyga-ubuntu, fwiw I also get this error at startup: "2017/09/11 10:40:29.655727 helpers.go:99: snap "lxd" has bad plugs or slots: lxd (lxd slots are reserved for the core snap)"
<zyga-ubuntu> ackk: did you self build that snap as well?
<ackk> zyga-ubuntu, yes
<zyga-ubuntu> ackk: then you probably lack the relevant assertion
<zyga-ubuntu> ackk: it's a bit hard to work with
<ackk> zyga-ubuntu, I only added a few options to the snapcraft.yaml, didn't change anything else
<zyga-ubuntu> ackk: right but you cannot sign it yourself
<zyga-ubuntu> ackk: and the assertion won't be in place
<zyga-ubuntu> ackk: so you won't get the right interface
<zyga-ubuntu> ackk: I honestly don't know what to do about that
<mwhudson> store uploads still seem a bit wonky, one of my retries failed
<ackk> zyga-ubuntu, so http://paste.ubuntu.com/25513886/ is release vs my build
<zyga-ubuntu> that u:{username} is a separate thing
<zyga-ubuntu> I'll look into that soon
<zyga-ubuntu> ackk: 2017/09/11 10:47:28.525309 helpers.go:152: cannot regenerate seccomp profile for snap "hello-world": error: cannot parse line: cannot parse token "u:root" (line "chown - u:root g:root") -- this looks like the wrong snap-confine/snap-seccomp pair
<ackk> zyga-ubuntu, ah, you mean because it's using those from the release rather than the locally built ones?
<zyga-ubuntu> ackk: yes
<ackk> zyga-ubuntu, I don't seem to  have a snap-confine binary
<ackk> zyga-ubuntu, will snapd look up snap-seccomp by $PATH ?
<wgrant> mwhudson: We're still bringing up the replacement hardware.
<zyga-ubuntu> ackk: no
<zyga-ubuntu> ackk: it knows exactly where to look
<ackk> oh
<zyga-ubuntu> ackk: it also may choose to re-execute from core snap
<zyga-ubuntu> ackk: if you don't know better yet please just rebuild snapd and install the whole package
<ackk> I see
<ackk> thanks
<zyga-ubuntu> ackk: you may also need to disable reexec by setting SNAP_REEXEC=0
<zyga-ubuntu> ackk: or use a wonky high version number
<ackk> zyga-ubuntu, disable it where?
<zyga-ubuntu> ackk: in the environment
<zyga-ubuntu> ackk: if you want to do globally (so that it affects snapd try /etc/environment)
<ackk> ok thanks
<mup> PR snapd#3892 closed: systemd: add systemd.MockJournalctl() <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3892>
<mup> PR snapd#3895 closed: osutil: adjust StreamCommand tests for golang 1.9 (2.28) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3895>
<mup> PR snapd#3899 closed: many: fix TestSetConfNumber missing an Unlock and other fragility improvements (2.28) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3899>
<mup> PR snapd#3896 closed: packaging/fedora: Ensure vendor/ is empty for builds and fix spec to build current master (2.28) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3896>
 * zyga-ubuntu -> lunch while https://github.com/snapcore/snapd/pull/3621 gets tested
<mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<zyga-ubuntu> jdstrand: I think that is ready for another review
<zyga-ubuntu> jdstrand: alternatively I can split and propose separate parts
<mwhudson> wgrant: ah so it was more "a retry will work eventually" than "a retry will work now"
<wgrant> mwhudson: Oh, yes, sorry.
<ackk> zyga-ubuntu, fwiw I get the error about the lxd snap even with a rebuilt package, but the u:/g: errors went away
<zyga-ubuntu> ackk: right, as I said you won't be able to rebuild lxd
<zyga-ubuntu> ackk: as lxd has superpowers the assertion is mandatory to get an interface connected
<ackk> I see
<zyga-ubuntu> ackk: or to even have a plug/slot present
<zyga-ubuntu> you must round trip through the store
<ackk> zyga-ubuntu, is that error fatal for the snap, or just an issue for the snap actually working?
<ackk> I guess i could build a simpler snap for my tests
<zyga-ubuntu> ackk: lxd is a bit special so if you can test with another snap, please
<ackk> zyga-ubuntu, ok, thanks
<pedronis> zyga-ubuntu: you can rebuild lxd but then you need to install with --dangerous, and connect everything manually
<sborovkov> ogra_: yay https://drive.google.com/file/d/0B5xwucQA3JSJOTEzdkwySy04TUU/view?usp=sharing
<ogra_> WOHOOO!
<pedronis> zyga-ubuntu: that's a for  develpoment approach though
<ogra_> sborovkov, any changes that i should merge ?
<zyga-ubuntu> pedronis: can you? I think the base declaration will kill the slots
<sborovkov> ogra_: not sure if I did it clean... and there is extra stuff I commented out that does not matter... https://hastebin.com/werawoyiji.diff (i.e. define changes).... I commented out drawing text since we don't do that. And used the path for drawing full screen images
<pedronis> zyga-ubuntu: no because --dangerous
<Chipaca> i'm off for a walk (need to take something to the boys' school) and lunch; bbiab
<zyga-ubuntu> o/
<pedronis> zyga-ubuntu: with --dangerous we ignore all decls, that's why it's --dangerous, otoh you can develop your snap
<ogra_> sborovkov, i'll try with your changed patch later today .... if it doesnt break the default setup we use i think it is fine to merge ... (not sure about the psplash_fb_draw_image though)
<pedronis> zyga-ubuntu: look around ./overlord/ifacestate/ifacestate.go:196
 * zyga-ubuntu nods
 * zyga-ubuntu is worried about his son and goes to school 
<zyga-ubuntu> ah wait
<zyga-ubuntu> I was looking at the calendar wrong, it's not time yet
<ogra_> you have a claendar entry "worry about son" ?
<ogra_> sborovkov, hmm, do you know what i think ? ... my splash uses a white bg .... i think one of your white bars is simply the default bg color for the text, if we set that to your actual bg color this might work
<ogra_> (whitour commenting out the function)
<ogra_> *without
<ogra_> (you might eventually want to use text to show a message or so ... so lets see that we dont kill that feature completely)
<sborovkov> ogra_: you can just undefine #define PSPLASH_STARTUP_MSG "" I think if there is no message then it won't be called
<sborovkov> draw_text
<sborovkov> and yeah same bg color should solve the issue
<ogra_> ah, right
<sborovkov> because it tries to draw it even if there is no text now
<ogra_> the other "bar" might be the bg for the progressbar
<sborovkov> yup
<ogra_> right, but if you take away that UI element completely the psplash-write command will likely not work
<sborovkov> not sure if this is going to center stuff (fb->width  - CORE_IMG_WIDTH)/2, - if we start at lower resoluttion x and y will be negative
<ogra_> so we should definitely keep the message part but make it default to the bg color
<ogra_> well, not if your image isnt smaller than the most minimal resolution you use
<sborovkov> yeah but for rpi3 1080p is default one, everything else is edge case when something is not detected I guess
<sborovkov> ogra_: who is maintaining cm3 gadget snap btw? it's now quite far behind
<ogra_> sborovkov, ondra and i ... since i dont have the HW i'm waiting for ondra to test the "build  from source" PR https://github.com/snapcore/cm3-gadget/pull/1
<mup> PR cm3-gadget#1: build uboot from source, pull blobs from upstream, use dtbs from archive <Created by ogra1> <https://github.com/snapcore/cm3-gadget/pull/1>
<ogra_> once thats there i'll also add the splash PR for it
<ogra_> it is on our both TODOs ... no worries ;)
<sborovkov> alright :-)
<Son_Goku> mvo, zyga-ubuntu, well, at least right now 2.28 builds on Fedora
<Son_Goku> :)
<Son_Goku> so once you've made the first RC, it can be tested
<mvo> Son_Goku: \o/
<mvo> Son_Goku: thats great news
<Son_Goku> and now, when people change the dependencies, Travis should fail when they don't do the right thing
<mvo> excellent!
 * mvo hugs Son_Goku
<Son_Goku> I'm still furious that this was a thing for the longest time, though :(
<mvo> Son_Goku: :( sorry
<Son_Goku> but at least it can't happen anymore unless someone deliberately modifies the spec to prevent vendor leaking in
<Son_Goku> it's a pain to read Travis logs though
<abeato> mvo, is there any way one can download account/account-key assertions for a user from the store?
<ogra_> abeato, did you check "snap known --help" `
<ogra_> ?
<mvo> abeato: snap known --remote account should work, you will need the account-id
<mvo> abeato: e.g. "snap known --remote account account-id=canonical
<mvo> "
<Son_Goku> zyga-suse, zyga-ubuntu, you need to convert the os-release blacklist into a whitelist
<zyga-ubuntu> Son_Goku: I saw your post, replied on the forum, I don't know how one is better than the other
<abeato> mvo, ogra_ yayh, that works, thanks :)
<zyga-ubuntu> Son_Goku: I'd like to remove the list altogether
<zyga-ubuntu> Son_Goku: it's just that we cannot detect everything yet
<abeato> I did not know about that --remote thing, nice
<Son_Goku> zyga-ubuntu, yes, but you're never going to be able to
<zyga-ubuntu> Son_Goku: but white vs black list is not any different
<ogra_> mvo, abeato note though that only canonical has a cleatext alias fo account-id it seems ... if i want to pull my own assertioon i cant use account-id=ogra
<ogra_> it needs the hex string from https://dashboard.snapcraft.io/dev/account/
<Son_Goku> zyga-ubuntu: the underlying assumption is what's broken
<Son_Goku> a blacklist implies you know it works until it doesn't
<Son_Goku> when we both know the opposite is the case
<abeato> yeah, it would be great to have some sort of alias ;)
<zyga-suse> Son_Goku: let's chat on the fourm
<zyga-suse> Son_Goku: two conversations are harder to keep track
<zyga-suse> of
<ogra_> abeato, yeah, simply the snap namespace would do i guess (afaik thats unique too)
<jdstrand> nessita_: hi! if I go to https://dashboard.snapcraft.io/dev/snaps/8338/rev/3/, click 'Run automated review again' I'm getting a 504
<jdstrand> nessita_: tried several times
<sborovkov> ogra_, why can't splash be used for showing different splash on the first boot btw? Can't we just bundle 2 images. And check if some file exists to make sure it's first boot (or however that's possible to check). Does not look very complex to implement
<nessita_> jdstrand, checking!
<nessita_> wgrant, can the above (504 on firing the review checks again) be related to the network issues from PS45?
<nessita_> wgrant, as in our celery workers are not reachable
<wgrant> nessita_: Hm, does that hit CUD during the request?
<ogra_> sborovkov, well ... patches accepted ;)
<wgrant> nessita_: CUD is behind the bad router.
<wgrant> And packet loss is getting fairly bad
<ogra_> sborovkov, i think it would need quite some changes though since psplash actually compiles the image into the binary
<ogra_> (it cnverts it to a header and then includes the image data)
<ogra_> this is the reason why it is so small
<sborovkov> ogra_, yeah so the change would be to compile 2 images. Or, we can show text actually
<sborovkov> Do you know how I can check if it's first boot from inside psplash?
<ogra_> well, the splash gets loaded and started fom the initrd ...
<ogra_> so this would be a bit tricky
<ogra_> (since we load it before anything of the rootfs is mounted ...)
<sborovkov> Yeah that's the main question. Because at least drawing text that it's first boot and configuration is in progress would be trivial and require almost no changes then
<ogra_> sborovkov, well, as i said before you should use psplash-write to draw text ...
<nessita_> wgrant, yeah, it has to redownload the snap
<ogra_> sborovkov, but that would still need changes to snapd to use psplash-write for printing some "setting up the system..." message or some such ...
<nessita_> jdstrand, wgrant so after a few retries, the action finally worked. There are some issues with hardware going on.
<sborovkov> ogra_ you mean function inside psplash?
<ogra_> no, i mean the psplash-write tool it builds
<sborovkov> Ah ok
<sborovkov> The main question is still how to figure out how to know if it's first boot then
<ogra_> it wuld have to live in the core snap ...
<ogra_> the only thing actually knowing reliably that it is first boot is snapd
<ogra_> you can indeed have some script that toouches a flag file or some such ... but if you i.e. pwer off the board while snapd's firstbooot setup runs you might have it re-run so this isnt super reliable
<ogra_> sborovkov, what you can do is to change the psplash snapcraft.yaml part, include psplash-write alongside psplash itself, create an initrd/scripts/init-bottom script that looks on the rootfs and prints a message if a certain condition isnt fulfilled or so
<ogra_> (the build actually creates psplash-write anyway, we just dont install it in the initrd case)
<ogra_> if you use an initr-bottom script, the writable partition is mounted under /root so you can have your script do some checks
<ogra_> (the good thing with that setup is that you can actually do everything from the gadget without needing changes in core or any additional snap)
<jdstrand> mvo: hi! did you have time to look at https://github.com/snapcore/snapd/pull/3850#pullrequestreview-60647180?
<mup> PR #3850: tests: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3850>
<mvo> jdstrand: yes
<mvo> jdstrand: I just updated the bug and work on a fix
<jdstrand> oh nice
<mvo> jdstrand: its a regression in libseccomp2
<mvo> jdstrand: LP 1576066
<jdstrand> \o/
<jdstrand> mvo: thanks for trackcing that down :)
<mvo> jdstrand: I hope to be able to provide something useful in ~1-2h or so (most of the time is testing)
<mvo> jdstrand: your welcome! next I plan to build secondary-arch binaries to test that with the build-in bpf machine as well, but first things first. I am having fun :)
<jdstrand> :)
<ogra_> sborovkov, quickly hacked together ... http://paste.ubuntu.com/25514581/ something like this
<sborovkov> ogra_ cool I will try it
<ogra_> well, you still need to work out the check
<ogra_> this will simply show the message on every boot
<sborovkov> What about your example?
<ogra_> see line 20-23 in that pastebin
<sborovkov> Yeah that's what I meant can't I just check for that?
<ogra_> for what ?
<ogra_> i'm not sure if we ship oor not ship the state.jsn on a virgin image ... you need to find a condition thats unique only on first boot
<sborovkov> Ok understood
<ogra_> but for the rest this script should work to display a message
<ogra_> (well, perhaps not in your psplash because you removed the print text stuff  ... )
<ogra_> (might need to add it back)
<zyga-ubuntu> and I'm back
<zyga-ubuntu> paperwork done, she can now *return* by herself too
<Chipaca> zyga-ubuntu: shocking
<zyga-ubuntu> Chipaca: those async protocols
<zyga-ubuntu> walk yes, but return no
<zyga-ubuntu> ;-)
<mup> PR snapd#3900 opened: snap-seccomp: manually resolve socket() call in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3900>
<zyga-ubuntu> mvo: I'm seeing failures that look like
<zyga-ubuntu> + systemd-detect-virt -c
<zyga-ubuntu> /bin/bash: line 58: systemd-detect-virt: command not found
<ackk> zyga-ubuntu, is there a workaround for https://bugs.launchpad.net/snapd/+bug/1712930 to get the snap removed? sometimes reboot + killing squashfuse seems to work, other times the snap is left disabled,broken for a long time, then it disappears
<mup> Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:In Progress by zyga> <https://launchpad.net/bugs/1712930>
<zyga-ubuntu> mvo: have you seen this? is this fixed in master?
<zyga-ubuntu> ackk: not yet, it's on the top of my plate though
<mvo> zyga-ubuntu: no to both, slightly strange systemd-detect-virt should be available, where exactlxy do you see this?
<ackk> zyga-ubuntu, cool, thanks
<zyga-ubuntu> mvo: on 14.04 and 16.04
<zyga-ubuntu> ah, sorry on 14.04 only
<zyga-ubuntu> https://s3.amazonaws.com/archive.travis-ci.org/jobs/274125373/log.txt?X-Amz-Expires=30&X-Amz-Date=20170911T145438Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20170911/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=2a17a16eaf9f3fae7891d7842d7da85772bdbc14821fefb8643a9a2a3d6217c6
<mvo> zyga-ubuntu: aha, that makes (some) sense, but super strange that it starts to failing now. in what pr is that?
<zyga-ubuntu> mvo: the long standing one about snap-update-ns
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3621
<mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<zyga-ubuntu> the comments that landed on top are just small changes that have no chance to cause this
<zyga-ubuntu> hmm, store still wonky
<zyga-ubuntu> error: received an unexpected http response code (504) when trying to download https://068ed04f23.site.internapcdn.net/download-snap/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_1797.snap?t=2017-09-11T16:00:00Z&h=27f39e227e74faf690363d527e7cbbf0d92bb7fd
<sborovkov> ogra_ hmm if I use psplash-write then I'd have to draw line for text every time I guess :-( We gave gradient on splash screen so that's not very nice, hmm.
<noise][> zyga-ubuntu: downloads should be stabilizing now
<mvo> zyga-ubuntu: I have a look, still puzzling
<zyga-ubuntu> noise][: thank you
<zyga-ubuntu> mvo: no worries, I'll inveatigate too, I just wanted to know if this is a known issue
<mup> PR snapd#3901 opened: snap-seccomp: run secondary-arch tests via gcc-multilib <Created by mvo5> <https://github.com/snapcore/snapd/pull/3901>
<ogra_> sborovkov, hmm, prehaps move it to the very top or bottom ?
<sborovkov> Still ugly though
<ogra_> yeah :/
<ogra_> build two psplash binaries  ?
<sborovkov> hmm, so that one draws that row if it's called?
<ogra_> (then you can also bake the message into the png)
<ogra_> yeah, or even without psplash-write completely ... just have one psplash with the message and one without and show them conditionally
<ogra_> though you might need to show it later then since you need the mounted writable partition in /root
<sborovkov> hmm, how does psplash-write work though? Does it call that binary again? With text parameter?
<sborovkov> I mean if there is no text is passed I don't have to draw border
<ogra_> it talks to psplash ... not sure how ... perhaps through a socket
 * ogra_ isnt near the code atm
<sborovkov> Hmm then I can check what text we are getting
<sborovkov> If there is no text I don't have to draw the row for it
<ogra_> yeah
<ogra_> well, thanks to being in the gadget you have all the freedom to hack it up to your liking :)
<mup> PR snapd#3902 opened: tests: try to fix staging tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/3902>
<pedronis> cachio: this ^ should help with staging tests IÂ think, but I haven't tried a full run
<cachio> pedronis, great, thanks
<cachio> pedronis, I'll make a run
<ackk> does anyone know what can cause this error: Mount snap "sleep" (unset) (internal error: could not unmarshal state entry "snap-type": invalid snap type: "") ?
<ackk> (at "snap install" time with a local snap)
<pedronis> ackk: what snap --version is this?
<ackk> pedronis, master
<pedronis> I haven't seen something like that in a long time
<ackk> pedronis, I'm not sure what changed, it used to work earlier today
<ackk> I just rebuilt the package to see if something was messed up, but I still get the error
<zyga-ubuntu> jdstrand: hey
<ackk> pedronis, where should snap-type be set?
<pedronis> is set during mount itself
<pedronis> after reading it from the snap
<mvo> cachio: do you have fixes pending for 2.28 btw ? iirc you mentioned there are two failing tests currently? anything I could look at?
<ogra_> do we actually set it in non kernel/gadget/os ones ? i always through unset falls back to a defautl value
<pedronis> ackk: how it this snap build?
<ackk> pedronis, so the snap should have that value in snap.yaml?
<ackk> pedronis, from snapcraft
<ogra_> (was that "app" ?)
<pedronis> something is weird
<pedronis> ogra_: correct
<pedronis> but something is confused there
<ogra_> hah, i'm not *that* old :)
 * ogra_ still remembers things from a year ago :)
<ackk> pedronis, the snap installs on my machine (it's failing in a xenial LXD)
<zyga-ubuntu> jdstrand: not sure if you are around, if you have a moment please have a look at the update-ns PR again, I did a round of fixes as requested
<cachio> mvo, this https://paste.ubuntu.com/25515142/
<zyga-ubuntu> jdstrand: ignore the test failures there, we're going to address them, not related to what this PR is about
<cachio> mvo, not sure why it is happening
<pedronis> ackk: a xenial ldx with snapd master?
<ogra_> ackk, and other snaps work in that container ? (did you test)
<ackk> pedronis, correct
<ackk> ogra_, they used to, lemme try installing one
<ogra_> +1
<cachio> mvo, not sure if it is a test issue or a minor bug
<ackk> ogra_, they do
<ogra_> k, jst to be sure :)
 * zyga-ubuntu sits at a parent's meeting at school
<ogra_> *just
<zyga-ubuntu> so far nobody minds me working on snapd
<mvo> cachio: thanks, looking
<cachio> mvo, but in some cases it is leaving an end of line at the end of the file and other cases it is not leaving it, not sure why
<ogra_> zyga-ubuntu, chatting while the teacher talks to you ?
<ogra_> how rude :)
<mvo> cachio_lunch: oh, interessting
<ackk> ogra_, fwiw http://paste.ubuntu.com/25515151/ is my snap definition
<ogra_> hmm
<mvo> cachio_lunch: that does look like a bug (but minor), I wonder why its not determinist. I have a look, is that the only known issue  right now?
<zyga-ubuntu> ogra_: no, the teachers are not here yet
<ogra_> i wonder if due to the new socket stuff some validation simply falls over
<zyga-ubuntu> ogra_: so far observing the "parents sit in the back" is very similar to "kids sit in the back"
<ogra_> haha
<zyga-ubuntu> people age but behaviors don't change
<ogra_> yeah
<ackk> ogra_, so that's the stuff i'm working on. i changed the snapcraft schema do accept that
<ackk> ogra_, and snapd too
<ogra_> right, seems snapd misses something then
<ogra_> (just guessing here ... i'm not a snapd dev :) )
<ackk> ogra_, it used to work, but I'll dig more...
<jdstrand> zyga-ubuntu: I saw, thanks!
<ackk> ogra_, do you know if snap-type should be set anywhere in the snap? grep doesn't find anything
<ogra_> only for kernel, gadget and os usually ...
<ogra_> not for normal app snaps
<pedronis> acck: there's code in snap/  that should be happy to default to app when type: is not in the snap.yaml
<pedronis> why is not working for your snap IÂ don't know
<pedronis> or your snapd
<pedronis> can you look at the produced snap.yaml?
<zyga-ubuntu> jdstrand: thanks :)
<mup> Issue snapcraft#1442 closed: `build-snaps` <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1442>
<zyga-suse> re
<zyga-suse> boy, that was one long school meeting :/
<zyga-suse> three hours
<zyga-suse> noise][: hey, I was asked if snappy store will get any web presence and I recall there were some plans to have a public website for all the store snaps
<zyga-suse> noise][: can you tell me more about it?
<noise][> zyga-suse: yes, there is work in progress now
<zyga-suse> noise][: is there any rough estimate as to when that may be visible to the public?
<noise][> that's being done by the web team (with API support from us) - I don't have an ETA at the moment
<zyga-suse> noise][: thanks,
<zyga-suse> noise][: one more thing, is there any public roadmap for the store, such as the one recently made for snapd?
<mup> PR snapcraft#1545 opened: pluginhandler: error out on scriptlet errors <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1545>
<noise][> not at this time
<ogra_> hmm, so on edge xdg-open is completely borked for all my apps
<ogra_> Error org.freedesktop.DBus.Error.ServiceUnknown: The name io.snapcraft.Launcher was not provided by any .service files
<ogra_> Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonial.SafeLauncher was not provided by any .service files
<ogra_> great ... even on stable i cant open any links from any snap anymore
<zyga-suse> ogra_: you probably need the edge version of the debian package
<zyga-suse> ogra_: to get the service defintion
<ogra_> so we leave all users broken til the next release ?
<ogra_> (i'm no the stable core now)
<ogra_> *on
<ogra_> ogra@styx:~$ snap version
<ogra_> snap    2.27.5
<ogra_> snapd   2.27.5
<zyga-suse> ogra_: you need master version of the package (just get the deb from the ppa)
<ogra_> zyga-suse, why ?
<zyga-suse> ogra_: as the snap userd is not started otherwise
<zyga-suse> ogra_: alternatively try to start it yourself from master build
<zyga-suse> ogra_: because it needs a new systemd / upstart service file
<ogra_> why ?
<ogra_> so we tell our stable users they need to pull some stuff from master ?
<zyga-suse> no, I mean this should not have been done in master
<zyga-suse> er
<zyga-suse> in stable
<zyga-suse> if this broke in stable we need a new core release to synchronize this with userd work
<ogra_> i *had* edge installed, but switched to stable
<zyga-suse> mvo: ^
<zyga-suse> right
<zyga-suse> so if stable is behaving this way then we have a problem
<ogra_> and restarted the snap where the error shows up after switching to stable
<zyga-suse> maybe userd work landed in core snap before the snapd code was released
<zyga-suse> ogra_: so far it was still depending on snapd-xdg-open
<zyga-suse> do you have that installed?
<ogra_> if nothing secretly removed it ...
<ogra_> ogra@styx:~$ dpkg -l |grep xdg-open
<ogra_> ii  snapd-xdg-open                              0.0.0~16.04                                  amd64        Opens URLs via D-Bus
<ogra_> ogra@styx:~$
<ogra_> but that wouldnt produce such an error anyway
<ogra_> that it was broken in edge is fine ...
<ogra_> but that it doesnt fix itself when i switch to stable is not
<ogra_> and i dont think 2.27.5 should have it yet
<kwmonroe> anyone know how to handle /usr/bin/nohup in a strict snap?  i'm snapping hadoop and one of the daemon scripts calls out to /usr/bin/nohup, which greets me like this:
<kwmonroe> $ sudo hadoop.hadoop-daemon start namenode
<kwmonroe> starting namenode, logging to /var/snap/hadoop/x1/var/log/hadoop-hdfs/hadoop-root-namenode-permbox-xenial.out
<kwmonroe> /snap/hadoop/x1/usr/lib/hadoop/sbin/hadoop-daemon.sh: line 159: /usr/bin/nohup: Permission denied
<kwmonroe> jdstrand: remember in warsaw when you were all like "dude, i'll help you do all things strict!".  ^^ halp ;)
<jdstrand> kwmonroe: nohup is missing from the template. I've taken a todo to add it. in the meantime, you can ship it yourself
<SuperJonotron> with ubuntu core 16, network-manager snap is installed and really the only stable way to do anything with the network since netplan has issues but I need to use the nmcli command within another snap (docker) but really in a container in that docker snap, anybody know if this is even possible?
<kwmonroe> +1 jdstrand- thanks!
<kwmonroe> wait jdstrand, before i +1 you... by "ship it yourself", you mean stage-packages: coreutils?  or make a wrapper for just the nohup command?
<jdstrand> kwmonroe: you could stage-packages it, sure. or just grab the binary and shove it into your package. whichever you prefer
<kwmonroe> ack jdstrand.. i'll stage it.  this is a multi-arch snap, so i don't want the hassle of getting the right arch bin in place.  thanks again!
<jdstrand> kwmonroe: np. I'll get it upstream this week for sure
 * mwhudson is confused
<mwhudson> i have a project with source-type: git, source: .
<mwhudson> and i seem to have to snapcraft clean between builds to get any changes i made to be noticed?
<mwhudson> maybe i'm holding it wrong but this doesn'
<mwhudson> t seem ideal
<mwhudson> oh wait, obviously i need to commit changes in this setup
<nacc> mwhudson: why wouldn't you use dump plugin with . ?
<nacc> mwhudson: yeah, i'm assuming it's becasue git doesn't see the changes
<mwhudson> nacc: because it's a python thing, i need to use the python plugin i think?
<nacc> mwhudson: you don't *have* to :)
<nacc> mwhudson: but the source != plugin
<mwhudson> when i didn't specify source-type: i got lots of apparently unrelated crap in my snap
<nacc> mwhudson: oh wait
<nacc> mwhudson: sorry, confusing myself
<mwhudson> heh heh
<nacc> mwhudson: yeah, if you're using the python plugin, then i think you're right
<mup> Issue snapcraft#1439 closed: target arch default for containers <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1439>
<mup> PR snapcraft#1493 closed: lxd: only pass target arch if specified explicitly <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1493>
<mup> PR snapcraft#1522 closed: catkin plugin: only append PYTHONPATH if set <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1522>
<mup> PR snapcraft#1545 closed: pluginhandler: error out on scriptlet errors <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1545>
<mup> PR snapd#3903 opened: tests: change regex used to validate installed ubuntu core snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3903>
#snappy 2017-09-12
<mup> Issue snapcraft#1466 closed: scriptlets erroring behavior <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1466>
<mup> PR snapcraft#1537 closed: project_loader: aliases are deprecated <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1537>
<mup> PR snapcraft#1526 closed: catkin plugin: don't assume catkin is in underlay <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1526>
<mup> PR snapcraft#1525 closed: typo: replace occured with occurred <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1525>
<mup> PR core#57 opened: fix typo in 500-create-xdg-wrapper.binary <Created by mvo5> <https://github.com/snapcore/core/pull/57>
<mup> PR snapd#3904 opened: tests: test the real "xdg-open" from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/3904>
<mup> PR snapd#3905 opened: tests: add new test that checks that the compat snapd-xdg-open works <Created by mvo5> <https://github.com/snapcore/snapd/pull/3905>
<mup> PR core#58 opened: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58>
<mvo> meh, we are at 26 open PRs again, code reviews for the rescue please!
<mvo> to the rescue even
<Chipaca> ouch
<mvo> 3880 is probably an easy win
<Chipaca> how's #3777 ?
<mup> PR #3777: snap-repair: implement basic `snap-repair list` (with --verbose) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3777>
<mvo> Chipaca: I think I need to address some bits from samuele first
<Chipaca> pstolowski: what's up with #3810 ?
<mup> PR #3810: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <https://github.com/snapcore/snapd/pull/3810>
<pstolowski> Chipaca, working on it
<pstolowski> will push soon
<Chipaca> pstolowski: thank you for the tweaks to #3852
<mup> PR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>
<pstolowski> Chipaca, no, thank YOU!
<Chipaca> zyga-ubuntu: #3860 had spread failures that looked like network issues; i kicked it off again
<mup> PR #3860: packaging: don't include any macros in comments <Created by zyga> <https://github.com/snapcore/snapd/pull/3860>
<zyga-ubuntu> Chipaca: thank you
<Chipaca> mwhudson: conflicts in #3872
<mup> PR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3872>
<mwhudson> Chipaca: hooray
<Chipaca> i wonder if you can use non-ascii chars in env var names
<zyga-ubuntu> Chipaca: prooobably not want to ;)
<Chipaca>        EINVAL name is NULL, points to a string of length 0, or contains an '=' character.
<Chipaca> nothing about having bittiness
<Chipaca> zyga-ubuntu: agreed :-)
<mup> PR snapd#3906 opened: many: use snapcore/snapd/i18n instead of i18n/dumb <Created by mvo5> <https://github.com/snapcore/snapd/pull/3906>
<sitter> is there a best practice way of running snapd in an isolated env (docker/vm/lxd)?
<pedronis> Chipaca: #3890 is an easy one OTOH it seems that always fails spread tests for unrelated reasons :/
<mup> PR #3890: overlord: use overlord.Mock in more tests, make sure we check the outcome of Settle <Created by pedronis> <https://github.com/snapcore/snapd/pull/3890>
<Chipaca> pedronis: i just reviewed that one
<Chipaca> pedronis: :-D
<Chipaca> it'll probably conflict my PR though
 * Chipaca thinks the unverse is unfair every time that older PRs get conflicts from newer ones
<zyga-ubuntu> Chipaca: universe was never meant to be fair but maybe that's just fair to discover the hard way :)
<Chipaca> zyga-ubuntu: knowing it is unfair, and being reminded it's unfair, are completely separate
<pedronis> Chipaca: well, my branch might never land if spread tests continues like that, notice it changes only unit test so apart from that it should affect tests at all
<pedronis> *not affect
<mup> PR snapd#3884 closed: store: simplify api url config <Created by atomatt> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3884>
<mup> PR snapd#3902 closed: tests: try to fix staging tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3902>
<mup> PR snapd#3897 closed: systemd: do not run auto-import and repair services on classic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3897>
 * Chipaca finishes a review pass
 * Chipaca thinks he deserves a gold star
 * zyga-ubuntu hands Chipaca a gold star 
<zyga-ubuntu> (insert mario chime)
<Chipaca> zyga-ubuntu: thank you :-D
<Chipaca> zyga-ubuntu: also, finish your review of #3835 plz
<mup> PR #3835: packaging: bring down the delta between 14.04 and 16.04 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3835>
<mvo> zyga-ubuntu: what is the magic again to clean a mount namespace for a snap? context is https://forum.snapcraft.io/t/xdg-open-regression/2085/5 and I suspect that for him the fix does not work because his core snap is still the older version(?)
<zyga-ubuntu> mvo: I replied on the forum
<zyga-ubuntu> mvo: sorry, I saw the forum notification, no notification for irssi here
<zyga-ubuntu> mvo: are you on gnome shell now?
<mvo> zyga-ubuntu: not yet but I plan to move my workstation "soon"
<mvo> zyga-ubuntu: ish :)
<zyga-ubuntu> I cannot stand the idiotic alt-tab
<zyga-ubuntu> when I have two apps and dozens of windows open it's useless
<zyga-ubuntu> browser + terminal, on various workspaces
<zyga-ubuntu> alt-tab flies me across the workspaces
<zyga-ubuntu> sigh
<ogra_> zyga-ubuntu, you want alt+^
<pedronis> my Mock branch failed again, something somewhere doesn't want it in
<zyga-ubuntu> ogra_: I think gnome shell designers want that
<ogra_> well, yes
<zyga-ubuntu> ogra_: the problem with alt~ is that I now need to differentiate apps and windows
<zyga-ubuntu> and I much more prefer not to
<ogra_> yep, same here
<zyga-ubuntu> and in fact, I suspect users may not even grok the difference much
<zyga-ubuntu> "new is shiny" eh :/
<ogra_> i was ranting against that since unity implemented it years ago
<ogra_> (unity has a way to switch back to the ld behaviour though ... i dont think gnome-shhell does)
<ogra_> *old
<mvo> zyga-ubuntu: silly question about the discard-ns, should we run htis automatically, i.e. why did this user not get the updated xdg-open without manual work?
<zyga-ubuntu> mvo: this is https://bugs.launchpad.net/snapd/+bug/1667479
<mup> Bug #1667479: mount namespace is not discarded when core snap changes revision <snapd:In Progress by zyga> <https://launchpad.net/bugs/1667479>
<zyga-ubuntu> mvo: I should update that bug
<zyga-ubuntu> mvo: I'll add a comment shortly
<zyga-ubuntu> mvo: updated
<Chipaca> hah! systemd's "job for snapd.service canceled" error in real life!
<Chipaca> https://launchpadlibrarian.net/336695206/DpkgTerminalLog.txt
<Chipaca> (from bug#1716641)
<Chipaca> (from bug 1716641)
<mup> Bug #1716641: package snapd 2.26.10 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1 <amd64> <apport-package> <xenial> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1716641>
<mvo> zyga-ubuntu: aha, thank you
 * mvo hugs Chipaca for all his reviews
 * Chipaca hugs mvo back
<zyga-ubuntu> Chipaca: i wonder what does that mean in systemd-speak
<zyga-ubuntu> stop after start but before started?
<Chipaca> zyga-ubuntu: a daemon-reload hit during a 'stop'
<zyga-ubuntu> aha
<Chipaca> zyga-ubuntu: this might be because of our roll-our-own systemd overrides
<Chipaca> zyga-ubuntu: but it might also be just dh_systemd
<ogra_> ondra, https://forum.snapcraft.io/t/sources-of-snap-find-macaddr0/2089 ... why would /run/macaddr0 not be created when the dargonboard runs from eMMC ? (sounds really weird)
<ondra> ogra_ yeah sounds very strange
<ogra_> ondra, can you check this n a board that runs from eMMC ?
<ogra_> (i dont want to taint my board here and keep it in original state)
<ondra> ogra_ just testing some other bits on dragoboard so I can have a look here
<ogra_> thanks
<ogra_> i wonder if he uses his own kenel snap or so
<ondra> ogra_ yeah,something looks strange
 * zyga-ubuntu looks outside at the shimmering rain
<zyga-ubuntu> Chipaca: can rain shimmer? is that a good way to say this?
<ogra_> it surely shimmers if there is enough oil in the drops :P
<Chipaca> zyga-ubuntu: well, there's a song about it
<Chipaca> zyga-ubuntu: but it's from final fantasy
<joc> mvo: hi, do you know if/why there was a rebuild of 2.27.6?
<mvo> joc: yes, see https://forum.snapcraft.io/t/xdg-open-regression/2085
<joc> mvo: ah, thank you
<ogra_> (shouldnt really matter for non-desktop )
<zyga-ubuntu> Chipaca: I mean it, I'm inclined to learn the rain terminology
<zyga-ubuntu> and UK is the best place to learn
<zyga-ubuntu> mvo: do I undestand correctly that we only need a core rebuild and we don't need a new snapd
<zyga-ubuntu> mvo: regarding the xdg-open regression
<mvo> zyga-ubuntu: correct, the core change has already happend
<Chipaca> zyga-ubuntu: well, i've never heard rain described as shimmering, and google also thinks it's a proper name and not just an adjective
<zyga-ubuntu> Chipaca: how would you describe a rain that falls steadily, with no wind
<zyga-ubuntu> Chipaca: with rather large but not huge droplets
<Chipaca> zyga-ubuntu: steady rain?
<Chipaca> also ps just because i live in the uk doesn't make me rainman
<Chipaca> :-D
<mvo> Chipaca: quick sanity check about i18n coming from the client. we would need some sort of context/thread-local-storage per request. so quite a change compared to how we do i18n right now (and how gettext traditionally does it). or do you have an idea about something smart we could do?
<Chipaca> mvo: we're needing a context for other things, but yes
<Chipaca> it's not a minor change
<mvo> Chipaca: it looks like a gigant change right now but maybe I'm missing something. every place that calls i18n.G() would have to have access to this context
<Chipaca> mvo: in my minid at least it's part of the same refactor of daemon to get rid of gorilla
<Chipaca> yes, major
<Chipaca> 'have a daemon2 package and transition things' major
<mvo> Chipaca: but it would be more, no? i mean, we would have to pass the context even into e.g. snapstate.Install() and similar? as those generate i18n.G() messages?
<zyga-ubuntu> Chipaca: "rainman" sounds like a nice song title
<mvo> Chipaca: don't get me wrong, not asking how it could be done, just if I have a thinko somewhere
<Chipaca> mvo: everything needs a context
<mvo> Chipaca: ok, thanks
<itsfemme[m]> I tried to install the edge core snap and got the following error: - Setup snap "core" (2894) security profiles (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": fork/exec /usr/lib/snapd/snap-update-ns: no such file or directory)
<itsfemme[m]> cmd.go:140: exe doesn't have snap mount dir prefix: "/usr/lib/snapd/snapd" vs "/snap"     and      handlers.go:208: Reported install problem for "core" as 95e9cec8-97a9-11e7-9958-fa163e192766 OOPSID
<itsfemme[m]> are the only things I found from journalctl
<zyga-ubuntu> itsfemme[m]: hey, can you tell me which distribution are you on
<itsfemme[m]> subgraph os, which is a derivative of debian stretch
<mup> PR snapd#3907 opened: cmd/snapctl: allow snapctl -h without a context (regression fix) <Created by stolowski> <https://github.com/snapcore/snapd/pull/3907>
<zyga-ubuntu> itsfemme[m]: does subgraph os rebuild packages from source?
<zyga-ubuntu> itsfemme[m]: personally, would you mind contriuting to http://github.com/zyga/os-release-zoo
<zyga-ubuntu> itsfemme[m]: can you show me the source package of snapd from subgraph os? it looks curious
<mvo> Chipaca: a (slightly) crazy idea https://github.com/mvo5/snappy/commit/029f38be38ff9c634cb21d10e30ff6dba094ca34
<itsfemme[m]> Not all packages, it uses the debian repo with its own repo for kernels and additional apps
 * mvo lunches
<zyga-ubuntu> itsfemme[m]: is snapd rebuild or reused?
<itsfemme[m]> reused
<zyga-ubuntu> itsfemme[m]: which version do you have in the package?
<itsfemme[m]> this is the repo https://devrepo.subgraph.com/subgraph/
 * itsfemme[m] sent a long message: itsfemme[m]_2017-09-12_11:23:59.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/PxsNVKydOHgxYYkZgVpJKhQS>
<itsfemme[m]> I have PaX (from grsecurity) enabled but I didn't see anything from that in journalctl
<zyga-ubuntu> interesting
<zyga-ubuntu> so snapd restarted into 2.27.6
<zyga-ubuntu> but snap (the client) did not
<pedronis> what does snap restarting means?
<zyga-ubuntu> pedronis: I mean re-exec
<zyga-ubuntu> itsfemme[m]: for now, can you please open a forum topic
<pedronis> that's a super confusing way to call that :)
<zyga-ubuntu> itsfemme[m]: this will be eaier to track
<zyga-ubuntu> pedronis: sorry, I didn't mean that
<zyga-ubuntu> itsfemme[m]: I guess someone should try subgraph and see what's going on
 * ogra_ wouldnt be surprised if  gsecurity patches had influence on seccomp, apparmor and cgroups behaviour
<zyga-ubuntu> yes, that's possible
<itsfemme[m]> I mean I use all those things daily
<ogra_> (sadly its is closed source so you wont easily find out :P )
<zyga-ubuntu> itsfemme[m]: what's the kernel version you are on?
<itsfemme[m]> it's not closed source you can go to the repo and get the kernel source
<itsfemme[m]> 4.9.33-subgraph
<zyga-ubuntu> thank you
<itsfemme[m]> But as I said, I use apparmor, namespaces and seccomp to sandbox my daily applications so I know those work
<zyga-ubuntu> itsfemme[m]: thank you for the report, I'm pulling the release to see how it looks like
<zyga-ubuntu> itsfemme[m]: I would appreciate if you could open a thread on the snapcraft forum
<zyga-ubuntu> I will also check out debian stable and sid to see if this affects the parent
<ogra_> itsfemme[m], i thought the current source is only available against money (only a subset is public) ?
 * ogra_ only knows what he read in linus rants about GPL violations actually ... ICBW for sure :)
<ogra_> it would definitely be good to make sure it all works though (regardless of licenses, politics or rants :) )...
<Chipaca> mvo: I don't think we can use gls for this; there is AFAIK no connection between a request and the goroutine the handlers run on
 * Chipaca ~> lunch
<pedronis> mvo: I'm not sure IÂ want to look what gls does
<pedronis> mvo: what's the inpulse to work on those? gnome software?
<Chipaca> mvo: also: Accept-Language is the header to use :-)
<Chipaca> pedronis: the i18n pr up right now
<Chipaca> pedronis: snapd#3906
<mup> PR #3906: many: use snapcore/snapd/i18n instead of i18n/dumb <Created by mvo5> <https://github.com/snapcore/snapd/pull/3906>
 * Chipaca ~> really lunch
<pedronis> Chipaca: sounds like a huge distraction to me right now
<pedronis> even worse if instead of that we make a hackish exercise
<pedronis> Chipaca: given we have async stuff and global bits it's all a bit unclear how this should be properly designed
<pedronis> Chipaca: there's a lot going in snapd that is not tied to a request, or only indirectly, or could be potentially visited from different locales (think snap changes)
<mup> PR snapd#3890 closed: overlord: use overlord.Mock in more tests, make sure we check the outcome of Settle <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3890>
<mvo> pedronis: yeah, not saying we should do  any of this gls stuff, just thinking aloud as it seems to be a bit difficult right now to get a handle on this per-connection i18n
<zyga-ubuntu> mvo: I'd vote for explicit, context-based i18n since traditional approach to implicit (thread local state) is harder in go
<zyga-ubuntu> Found unused ./vendor packages:
<zyga-ubuntu>  vu github.com/mvo5/net/bpf
<mvo> zyga-ubuntu: yes, update your vendor dir, thats fine
<pedronis> mvo: as I said I feart apart the tech expect, there are interesting conceptual questions if we start having per request i18n
<pedronis> it's probably weeks of work to get that right
<mvo> pedronis: yes
<mvo> zyga-ubuntu: re context-based i18n> seems like everyone agrees with this
<mvo> anyway, I won't persuse this, it was just a short explore round
<pedronis> mvo: its seems we would need to do i18n very close to where we build the response
<pedronis> not all over the place as we do now
<mup> PR snapcraft#1523 closed: node plugin: record installed node packages in manifest <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1523>
<zyga-ubuntu> pedronis: yes
<zyga-ubuntu> pedronis: or pass the context deeply everywhere which seems insane-ish
<pedronis> that doesn't help
<pedronis> some strings have not direct request
<mvo> pedronis: right, which is tricky once you have format strings in the i18n, e.g. something in snapstate: fmt.Errorf(i18n.G("cannot install %q snap"), snapName)
<pedronis> like all the stuff in changes
<zyga-ubuntu> pedronis: yes, I agree
<pedronis> and tasks
<pedronis> mvo: we would need complex ways to pass strings around
<pedronis> as I said
<pedronis> weeks of work
<mvo> pedronis: yes
<mvo> pedronis: we are in agreement :)
<zyga-ubuntu> I wonder if we can start with some common problems and come up with a cheaper solution for that
<zyga-ubuntu> so _some_ errors could get context-sensitive i18n
<pedronis> we need to mark them but translate them late
<zyga-ubuntu> but not all
<zyga-ubuntu> N_(...)
<pedronis> and keep the info of what needs translating
<pedronis> etc etc
<zyga-ubuntu> pedronis: and also store interpolation
<pedronis> yes
<pedronis> lots of fun
<pedronis> seems a bit the wrong time to dive into that
<pedronis> too much other stuff
<mvo> +1
<zyga-ubuntu> yes
<zyga-ubuntu> I agree
<mvo> speaking of other stuff> arm/armhf/powerpc fail to build in master right now :/
<zyga-ubuntu> unless someone external goes to explore and then works on this exclusively without breaking everything for a while
<zyga-ubuntu> mvo: fun
<Son_Goku> mvo: wut?
<pedronis> "fun"
<zyga-ubuntu> mvo: let's raise a glass to unpopular architectures
<pedronis> at least IÂ could merge  my Mock branch, I think IÂ had to retry 5+ times (or more, I really don't remember)
<ikey> lol "unpopular"
<zyga-ubuntu> ikey: heh
<zyga-ubuntu> ikey: good to see you
<ikey> ta, you too
<pedronis> it's all relative
<zyga-ubuntu> ikey: I've installed solus and I loved the experience :)
<zyga-ubuntu> ikey: I played with the build tools a little
<ikey> oh im so sorry
<ikey> xD
<zyga-ubuntu> ikey: but I could not find the snapd package (I cloned everything using the helper make)
<mvo> cachio: hey, can I get commit access to spread-cron please :)
<zyga-ubuntu> ikey: I wanted to help with co-maintenance
<ikey> oh you legend
<zyga-ubuntu> ikey: and to update snapd to 2.27.6
<ikey> https://dev.solus-project.com/source/snapd/
<ikey> everything is nested on our dev portal
<ikey> the "main" file is https://dev.solus-project.com/source/snapd/browse/master/package.yml
<ikey> its basically bash script decorated with sexy yaml
<ikey> omg zygaception
<zyga-ubuntu> ikey: should this have been cloned by make pull?
<ikey> uhm so the "make pull" thing relies on the old common/packages notion
<Son_Goku> you can clearly see the pisi influence :)
<zyga-ubuntu> ah
<zyga-ubuntu> :)
<ikey> no you can't Son_Goku
<zyga-ubuntu> some stale docs I ran into then
<ikey> pisi is XML.
<zyga-ubuntu> what is pisi
<Son_Goku> the changelog is still in pisi format :)
<ikey> eopkg is forked from pisi
<ikey> Son_Goku, what?
<ikey> what changelog..?
<ikey> zyga-ubuntu, pisi is what eopkg is forked from
<Son_Goku> err, pspec
<Son_Goku> pspec_x86_64.xml
<ikey> thats automatically generated for introspection
<ikey> its not actually used by the build
<ikey> ypkg emits the eopkg itself
<Son_Goku> ah, so you're not writing it :)
<ikey> in the old days we used to rely on the machine files
<ikey> oh god no
<Son_Goku> haha
<ikey> ypkg was to get us away from that old crap
 * Son_Goku remembers rpmxmlbuild
<ikey> and make packaging sane
<zyga-ubuntu> ikey: got it
<ikey> zyga-ubuntu, so yeah we infra-changed and some things broke â¢
<Son_Goku> ikey, there was a point where rpm spec files could be written as XML :P
<ikey> Son_Goku, intentionally?!
<zyga-ubuntu> ikey: how do I send patches to that packaging?
<Son_Goku> yep, back in the early rpm 4.0.x ~ 4.3.x days
<ikey> zyga-ubuntu, you're gonna want to install "arcanist"
<Son_Goku> jbj implemented it to make people back off about wanting a schema for rpm spec
<ikey> https://solus-project.com/articles/packaging/submitting-a-package/en/
<ikey> see the arcanist links down below
<ikey> basically you mangle and alter your clone of our repo
<ikey> get your commit in order
<ikey> and send it with "arc diff" (once arc is setup)
<ikey> then it creates a new patch against snapd in our infra
<Son_Goku> ikey: probably the next go around, there will be an rpmyamlbuild :)
<ikey> Son_Goku, yeah yaml is "so hot right now" :P
<cachio> mvo, let me check
<zyga-ubuntu> ikey: I'll try
<ikey> you gotta have a dev site account fwiw
 * zyga-ubuntu needs to clean his desk
<ikey> you can log in with github anyway
<zyga-ubuntu> ikey: how do I get that?
<Son_Goku> ikey: someone is already working on making rpm output yaml in addition to xml
<zyga-ubuntu> ah
<zyga-ubuntu> I did log in
<ikey> saves farting about
<ikey> ok so do the "Setting up Arcanist bit"
<ikey> er. misquoting but ya
<ikey> basically it sets up arcanist globally for the solus instance
<ikey> fwiw if you have a proper checkout with $dir/common $dir/snapd, etc, you can do "make" to actually build the package
<ikey> i assume you've got solbuild setup at this point?
<ikey> (because it wouldn't be solus without a shedload of badly named tools.)
<zyga-ubuntu> ikey: I do
<ikey> suhweet
<ikey> you can `sudo solbuild update -p unstable-x86_64` to keep the base image updated fwiw
<ikey> makes subsequent builds faster
<ikey> (if you install `solbuild-config-unstable` you can skip the -p parameter nonsense)
<ikey> always amazes me that solus users have never questioned why i opted to include the architecture field in everything for an x86_64 distro
<ogra_> mvo, seriously, kill powerpc ... we never supported it, you cant even build snaps for it so it is totally pointless to have it
<ogra_> there is so much time and energy wasted on it ...
<zyga-solus> ikey: hmm, what did I do wrong? zyga@lambert ~/packaging/snapd $ make
<zyga-solus> make build
<zyga-solus> make[1]: Entering directory '/home/zyga/packaging/snapd'
<zyga-solus> sudo solbuild build package.yml -p unstable-x86_64;
<zyga-solus> Profile is not installed: Did you forget to init?
<zyga-solus> make[1]: Leaving directory '/home/zyga/packaging/snapd'
<zyga-solus> make abireport
<zyga-solus> make[1]: Entering directory '/home/zyga/packaging/snapd'
<zyga-solus> abireport -p abi_ -D `dirname package.yml` scan-packages `dirname package.yml`
<zyga-solus> Error locating packages: No packages in directory .
<zyga-solus> make[1]: *** [../Makefile.common:15: abireport] Error 1
<cachio> mvo, I think niemeyer can give you permissions
<zyga-solus> make[1]: Leaving directory '/home/zyga/packaging/snapd'
<zyga-solus> make: *** [../Makefile.common:12: complete] Error 2
<zyga-solus> oh, darn, sorry, hexchat doesn't auto-pastebin
<mvo> cachio: ok, if you could merge my PR on spread-cron, that would be great
<mvo> pedronis: does http://paste.ubuntu.com/25520782/ ring any bell(s)? its the failure on arm/arm64
<mup> PR snapd#3860 closed: packaging: don't include any macros in comments <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3860>
<cachio> mvo, done
<mvo> cachio: \o/
<mvo> cachio: I trigger a test run now
 * zyga-ubuntu needs to clean his desk *really* 
<zyga-ubuntu> omg, fedora mail storm :)
<pedronis> mvo: no, seems weird
<mvo> pedronis: yeah, also why just arm? probably some race but looks very strange, I see if I can reproduce it
<ikey> zyga-ubuntu, sorry had to run downstairs
<zyga-ubuntu> ikey: no worries
<pedronis> mvo: doesn't seem like a race, more an issue with mocking hooks
<ikey> zyga-ubuntu, did you init unstable?
<ikey> unstable and main correlate to the two main solus repos
<zyga-ubuntu> ikey: ... I think I don't know
<ikey> typically package developers target unstable, as we don't explicitly build for main
<ikey> alright well, easiest way to do this
<mvo> pedronis: I wonder why its just manifesting itself on arm (this is why I suspected a race)
<ikey> sudo eopkg it solbuild-config-unstable
<ikey> sudo solbuild init -u
<zyga-ubuntu> initializing
<ikey> that'll initialise solbuild and update the base image
<ikey> solbuild-config-unstable installs a global config file that pins you to unstable by default
<ikey> (in /usr/share because /etc is wrong. :P)
<pedronis> mvo: that stuff should be determinstic
<zyga-ubuntu> ikey: writable /usr/share? curious
<ikey> nope, read-only
<ikey> we use layered configuration
<ikey> https://github.com/solus-project/solbuild/blob/master/src/builder/config.go#L34
<ikey> /etc/solbuild takes precedence
<mvo> pedronis: yeah, I'm trying this on my pi now
<ikey> we have image + profile definitions
<pedronis> mvo: ah, those tests don't check chg.Err, you probably need to start there
<mvo> pedronis: aha!
<pedronis> sorry
<pedronis> they do
<pedronis> but don't check ready
<ikey> zyga-ubuntu, basically at solus we're weird and very opinionated about how to build a distro. :p
<pedronis> mvo: not sure what is going on there
<zyga-ubuntu> ikey: I think you just described snapd project :)
<ikey> :D
<zyga-ubuntu> ikey: we're also opinionated and some people find some things weird
<ikey> good architecture usually is
<zyga-ubuntu> ikey: ok, now it works!
<ikey> and it has to be opinionated to be enforced
<ikey> suhweet
<ikey> so do you have common/ setup?
<zyga-ubuntu> yes
<ikey> with the symlinks and such
<zyga-ubuntu> well
<zyga-ubuntu> make works
<ikey> if you step into snapd directory, a simple "make" should suffice
<zyga-ubuntu> and I see a few symlinks for makefiles
<zyga-ubuntu> yes,
<zyga-ubuntu> I think I'm good now
<ikey> if make works and it spits out eopkgs, you're golden
<zyga-ubuntu> I'll let it build cleanly
<zyga-ubuntu> then do my changes
<ikey> aye
<zyga-ubuntu> and then bug you to figure out how to send that :)
<ikey> in solus the release number is more important than the version number
<ikey> its the thing we actually track and says "this is an update"
<zyga-ubuntu> ikey: ahhh
<zyga-ubuntu> ikey: so like snap revision
<ikey> (Even if its a downgrade)
<ikey> right
<zyga-ubuntu> ikey: so I should not reset it after changing version?
<ikey> so all updates include a relno bump
<zyga-ubuntu> ikey: interesting :)
<ikey> nah bump by 1
<zyga-ubuntu> ack, will do
<ikey> numbers are free so .. yknow. :)
<mvo> pedronis: no worries, thanks, I try to reproduce now on my pi
<zyga-ubuntu> yes, and much nicer and simpler conceptually than debian -~4-fork5
<ikey> you also have "make clean" to nuke the local eopkgs, just because
<ikey> right
<ikey> we didn't want epochs and such
<zyga-ubuntu> ikey: and revisions are nice because versions can match upstream
<ikey> exactly
<zyga-ubuntu> build completed
<ikey> well, fwiw eopkg having pisi heritage has some gimped notion of version fields
<zyga-ubuntu> ok, let's just bump the release and the version
<zyga-ubuntu> and see what happens
<ikey> in that it tries to be clever and interpret them
<ikey> when we replace it with 'sol', we'll make it not care what the version field means
<zyga-ubuntu> ikey: after building I have a changed tree
<ikey> right, pspec changed
<ikey> thats fine
<pedronis> mvo: ah, it might just be too slow
<zyga-ubuntu> the xml changed
<ikey> you see what i mean about pspec being machine generated
<zyga-ubuntu> ikey: shall I commit or ignore
<pedronis> mvo: IÂ just merged checking for Settle error
<ikey> just ignore it
<ikey> in your final change you include your pspec diff
<mvo> pedronis: oh, that sounds reasonable
<ikey> as its the build record
<ikey> its generated on the fly, its not sourced
<zyga-ubuntu> ok
<pedronis> mvo: IÂ don't know if with master you mean with my last landing or not
<ikey> it includes basic stuff to indicate the subpackages and file layout
<ikey> that way we can quickly glance to make sure its half sane
<mvo> pedronis: master as of ~1h or so ago
<mvo> pedronis: but let me double check, the builds are always a bit delayed
<pedronis> I merged it around there
<pedronis> but from the failure mode
<ikey> zyga-ubuntu, fwiw ypkg/solbuild does support git builds but snapd repo is set up odd without git submodules
<pedronis> it probably doesn't have that code yet
<ikey> so you'd need to set `networking: yes` to bypass some of the confinement we set
<ikey> (we nuke networking in solbuild)
<ikey> it really is a glorified container at this point..
 * zyga-solus goes for the daily standup
<zyga-solus> ikey: what's the hash in packaging?
<ikey> sha256sum
<ikey> if you're using git sources its the commit or branch
<zyga-solus> yep
<ikey> i.e. git|someSource/.git : commit
<ikey> i typically look at git show in head and take the tip commit
<zyga-solus> ok, building with 2.27.6
<ikey> gl!
<zyga-solus> ikey: is it typical to run tests during the build
<ikey> so i mean if you *want* to run tests, you can
<ikey> you can just nuke it
<ikey> and run tests yourself
<ikey> its not always appropriate for a make check
<ikey> (and solbuild lacks x11/dbus isolation atm)
<zyga-solus> ok
<zyga-solus> I'll try locally
<ikey> we're doing those in the next major version so we can have PGO on x11 apps
<ikey> like firefox ^^
<pedronis> this is a weird failure mode:  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170912_124213_dfd96@/log.gz
<pedronis> a panic with fatal error: runtime: address space conflict
 * ikey takes `unsafe` away from golang
<zyga-solus> Sep 12 11:50:55 autopkgtest snapd[6307]: runtime: address space conflict: map(0xc820100000) = 0x7f01da1d7000
<zyga-solus> Sep 12 11:50:55 autopkgtest snapd[6307]: fatal error: runtime: address space conflict
<zyga-solus> woah
<greyback> ogra_: hey, were you playing with the vc4 driver on the rpi3 recently? I'm seeing rendering failures with Qt and GL, Qt is unable to allocate its atlas texture, breaking all images
<ogra_> greyback, nope, havent touched it ...
<greyback> ogra_: ok. I'll see what I can figure out so. thanks!
<ogra_> greyback, ppisati recently added a fix to make /dev/fb0 work again (some malloc stuff afaik) ... perhaps that has some influence ?
<pedronis> mvo: zyga-solus: that panic is interesting, not sure it something we control though
<greyback> ogra_: hmm I'll keep that in mind. I don't see how that would impact it, but I've been surprised before
<ogra_> right
<ogra_> i wouldnt expect it to break anything either
<cachio> mvo, have you ever seen this error https://travis-ci.org/snapcore/spread-cron/builds/274589912?utm_source=email&utm_medium=notification ?
<mvo> cachio: I saw it but can't make sense of it, I think my other PR needs to be revert :/ I prepare a PR
<cachio> mvo, ok
<mvo> cachio: I opened a revert PR for this
<ackk> hi, if I run "go test github.com/snapcore/snapd/cmd/snap-seccomp" in snapd master, tests seem to hang, any idea what could it be?
<mvo> ackk: they are slow for me (~15sec on a fast machine). you can try "go test -check.vv github.com/snapcore/snapd/cmd/snap-seccomp"
<mvo> ackk: that should give you some idea where its slow at least
<mvo> ackk: what is your hardware?
<ackk> mvo: can't load package: package github.com/snapcore/snapd: no buildable Go source files in /home/ack/go/src/github.com/snapcore/snapd
<mvo> pedronis: 3893 looks ready (spread is green)
<ackk> mvo, Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
<ackk> mvo, if I run the full suite tests pass, but running this package alone seems to hang
<mvo> ackk: heh, that is a fast machine, it really should not hang, strange
<mvo> ackk: aha, let me try this
 * zyga-ubuntu -> tea
<ackk> mvo, do tests require a minimum kernel version (thinking about seccomp/apparmor stuff)?
<cachio> mvo, when you have a minute, please could you take a look to this one
<cachio> https://github.com/snapcore/spread-cron/pull/43
<mup> PR spread-cron#43: Skip manual branches <Created by sergiocazzolato> <https://github.com/snapcore/spread-cron/pull/43>
<mvo> ackk: maybe, what is puzzling is that you say that the test works when you run it as part of the entire unit tests of snapd but not when run in isolation
<mvo> cachio: sure
<ackk> mvo, the whole suite takes a lot of time, though
<mvo> ackk: yes, no disputing this :) I'm just confused that it works there but not when run in isolation and scratching my head what might be causing this
<mvo> ackk: if you "cd $GOPATH/src/github.com/snapcore/snap/cmd/snap-seccmp && go test", does that work?
 * ackk tries
<mvo> ackk: and curious, are you hunting a bug in this package? anything not working for you?
<ackk> mvo, i'm on go 1.6.3 if that matters
<mvo> ackk: that should be ok. anything unusual about your kernel/libc/seccomp version maybe?
<ackk> mvo, no, I was running tests in a brnach of mine (for adding socket activation support), tests were hanging and eventually timing out, so I was trying to get a baseline on master
<ackk> mvo, I'm on yakkety, nothing special
<mvo> ackk: hm, indeed, sounds all quite normal
<mvo> ackk: so generally speaking this should work, so lets try to figure out why its not in your case :) - does it make a difference if you run"cd $GOPATH/src/github.com/snapcore/snap/cmd/snap-seccmp && go test" ?:
<ackk> mvo, still runnning, but I suspect it's stuck
<ackk> mvo, strace tells me it's stuck on a FUTEX_WAIT
<ackk> weird
<ackk> mvo, so, no, no change
<mvo> ackk: what does "go test -check.vv" tell you now? it should print each test
<mup> PR snapcraft#1546 opened: cli: update parts cache in the container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1546>
<ondra> ogra_ dragonboard booting from emmc and I have there /run/macaddr0
<ackk> mvo, running, but I see some "cannot use non-native in runBpfInKernel" messages
<ackk> not sure if they're relevant
<mvo> ackk: thats harmless
<mvo> ackk: and reminds me that I should fix those :/ thanks, I will do that in a wee bit
<ackk> mvo, it's still running fwiw
<mvo> ackk: can you see the last START?
<mvo> ackk: i.e. in which of the tests is it hanging?
<mup> PR core#57 closed: fix typo in 500-create-xdg-wrapper.binary <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/57>
<ackk> mvo, snapSeccompSuite.TestRestrictionsWorkingArgsPrctl is the last one
<ackk> it seems stuck there
<mvo> ackk: ohh, interessting, let me look
<ackk> mvo, oh, it just moved on, but 93s on that one
<mvo> ackk: geeeh, that is a long time
<mvo> ackk: this is master, right? I mean, its (reasonable) up-to-date with master?
<ackk> mvo, yeah, I updated 2hrs ago tops
<mvo> ackk: that should be fine
 * mvo scratches head
<ackk> mvo, is snapd secretly written in enteprise java? :)
<mvo> ackk: *cough*
<mvo> ackk: lalallaa
<mvo> ackk: ;)
<ackk> :)
<mvo> ackk: so these tests do a lot of fork/exec, the way it works is that it creates a small C helper that runs all our  syscalls that we care about in sandboxes to ensure the code that generates the sandboxes works correctly. so its expensive but on your HW it should really not take so long
<mvo> ackk: btw, socket activation support sounds awesome!
<mup> PR snapd#3893 closed: many: introduce asserts.NotFoundError replacing both ErrNotFound and store.AssertionNotFoundError <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3893>
<ackk> mvo, the problem seems locking-related, cpu is free
<ackk> mvo, yeah I hope to be done soon with at least the basic stuff
<mvo> cachio: https://github.com/snapcore/spread-cron/pull/43 has my +1, I can't merge currently. but if niemeyer gives me write access to the spread-cron repo I can do it
<mup> PR spread-cron#43: Skip manual branches <Created by sergiocazzolato> <https://github.com/snapcore/spread-cron/pull/43>
<niemeyer> mvo: on it
<pedronis> mvo: thanks, merged
<mvo> ackk: strange that the cpu is idle, there are no locks in these tests, its just running a bunch of binaries (and producing the right seccomp confinement). very puzzling. still hanging? I can give you a diff that springles some debug prints so that at least we get some idea what is doing on, i.e. if compile of the seccomp code is slow or if execution is slow etc
<jdstrand> mvo: fyi, https://dashboard.snapcraft.io/dev/snaps/6021/rev/2902/ got hung up so I requested to rerun the review. it passed, but needs to be released
<ackk> mvo, yeah still running
<mvo> jdstrand: thank you, released now
<niemeyer> mvo: Done, now the committers team has rw there
<mvo> ackk: I need to take a short break but I will read backlog if you find anything interessting
<ackk> mvo, ok. thanks for the help
<ogra_> ondra, yeah, see the forum ...
<cachio> mvo, the revert didn't fix it
<cachio> mvo, the problem is not related to that :(
<ogra_> ondra, thanks fo testing though
<ondra> ogra_ no prob, I just needed to sort my dragonboard as I was testing one thing and it was messed up
<ackk> mvo, fwiw that tests seems to hang in a trusty container and my (artful) laptop too
<ackk> mvo, those tests are definitely i/o-bound for me
<ackk> no idea why
<ackk> mvo, ~40Mb/s disk write
<zyga-ubuntu> jdstrand: hey
<zyga-ubuntu> jdstrand: do you have a chance to re-review the snap-update-ns PR
<zyga-ubuntu> jdstrand: I'm still blocked on your request for changes
<ryebot> Is there any way to set StartLimitIntervalSec=0 for snap-created services?
<ryebot> Or otherwise force them to continue restarting forever?
<ackk> mvo, ok      github.com/snapcore/snapd/cmd/snap-seccomp      420.994s FTR
<zyga-ubuntu> ackk: FYI on my opensuse laptop with btrfs this takes way too long to test and golang always kills it with 10 minute timeout
<zyga-ubuntu> I wonder if we could somehow compile one huge executable and then fork each helper test process of it
<zyga-ubuntu> as I strongly believe it is io bound on gcc for whatever reason
<ackk> zyga-ubuntu, I suspected btrfs too, but it hangs even if I move $GOPATH under tmpfs
<zyga-ubuntu> ackk: well that test comples an awful lot of binaries
<ackk> zyga-ubuntu, can't the be compiled upfront?
<ackk> *they
<zyga-ubuntu> ackk: each one is compiled once
<zyga-ubuntu> ackk: there are generated test programs
<ackk> zyga-ubuntu, then why the IO ?
<zyga-ubuntu> ackk: I assumed it was gcc but perhaps I'm missing something
<mvo> ackk: hm, it should pre-generate the helpers, let me try to figure out what is going on, maybe a bug
 * ackk updates master
<zyga-ubuntu> mvo: set up test vs set up test case?
<zyga-ubuntu> just guessing,
<mvo> zyga-ubuntu: could be something stupi dlike this
<mvo> zyga-ubuntu, ackk: checking in any case
<zyga-ubuntu> mvo: add a print and see :)
<mvo> cachio: meh, thats nasty, wonder why the sync breaks just when the other branch gets merged, almost too much of a conicidence
<mvo> ackk: just to double check, your are on btrfs?
<ackk> mvo, yes, but as said I tried moving my GOPATH to tmpfs
<mvo> ackk: it is definitely writing a gazillion of small files and callnig fsync and dirsync for each.
<mvo> ackk: does it make a difference if /tmp is tmpfs?
<zyga-ubuntu> mvo: that's super odd, what would call fsync and dirsync?
<mvo> ackk: I bet it does
<ackk> mvo, doesn't seem to
<mvo> ackk: :/
<zyga-ubuntu> I don't think we do that outselves
<ackk> mvo, but is it slow for you?
<mvo> zyga-ubuntu: we do, the test writes out small bpf programs into files in /tmp/check-NNNN/bpf
<zyga-ubuntu> mvo: but that should not include any of the sync calls
<zyga-ubuntu> those are exception, not the norm
<mvo> ackk: its certainly not fast
<mvo> zyga-ubuntu: its our "normal" atomic write pattern
<zyga-ubuntu> ah
<zyga-ubuntu> try SNAPD_UNSAFE_IO please
<mvo> zyga-ubuntu: its not using osutil - let me look why
<zyga-ubuntu> that should make a difference if this is really io bound fsync
<zyga-ubuntu> ahhh
<mvo> zyga-ubuntu: I think it can now actually because we have atomicwrite to fds now
<mvo> ackk: I think we are getting closer! thanks for your patience
<ackk> thank you guys for digging into this
<ackk> I'm trying SNAPD_UNSAFE_IO fwiw
<ackk> oh, but you said it's not using osutil
<ackk> so it shouldn't make a difference?
<zyga-ubuntu> not yet
 * zyga-ubuntu plays with a snap that uses content interface in $SNAP_DATA/subdir
<ogra_> dont the most do that ?
<zyga-ubuntu> ogra_: no
<zyga-ubuntu> ogra_: because making that subdirectory is hard
<zyga-ubuntu> well, no more
<zyga-ubuntu> that's why I'm fixing it :)
<ogra_> i thought mir actually uses it like that
<ogra_> (thats the content snap i use most)
<zyga-ubuntu> there are hacks
<zyga-ubuntu> I'm making it easy
<ogra_> having the interface actually create it ?
<zyga-ubuntu> yes
<ogra_> col
<ogra_> +o
<ogra_> hah popey beats me :)
<popey> Reply twins! :D
<ogra_> :D
<popey> Whee, he's getting all the love.
<ogra_> hahaha
<ackk> mvo, oddly, if I run those tests in a container, they succeed in ~400s, on the actual machine they get killed after 10m
<zyga-ubuntu> ackk: different mount laout
<zyga-ubuntu> ackk: so proof that they are really io bound
<ackk> zyga-ubuntu, yeah, but both on btrfs
<zyga-ubuntu> ackk: but /tmp in container is probably tmpfs
<zyga-ubuntu> not your real tmp
<ackk> ah, good point
<mvo> ackk: this http://paste.ubuntu.com/25521498/ with SNAPD_UNSAFE_IO=1 gives me test runs of 2s vs 14s on ext4. let me iterate a bit on this, I'm not quite happy yet
<mvo> ackk: with the code and also I think there should be no need to set an environment, the test can test it itself
<ackk> mvo, awesome, that worked
<ackk> 2.3s
<mvo> nice
<mvo> ackk: I clean it up and will propose something shortly
<ackk> mvo, thanks!
<zyga-ubuntu> mvo: suggestion
<mvo> thank you for raising it
<zyga-ubuntu> mvo: make unsafe io default=1 in tests
<zyga-ubuntu> mvo: I use that in opensuse packaging but it should not be hand-held that much
<ackk> zyga-ubuntu, +1 :)
<zyga-ubuntu> mvo: everything will benefit
<mvo> zyga-ubuntu: yeah, I was thinking this
<zyga-ubuntu> mvo: setting it to =0 should still do the real thing
<zyga-ubuntu> mvo: and we should test that, ahem
<mvo> zyga-ubuntu: yeah, I was about to ask why its controlled by the evnrionment
<mvo> zyga-ubuntu: sounds good
<zyga-ubuntu> mvo: just so that it's controllable
<zyga-ubuntu> mvo: but then it was constrained to just tests
<zyga-ubuntu> mvo: and then it made less sense as a knob that needs to be set in the "fast" position manually
<ackk> like the "turbo" button on old PCs :)
<mvo> Chipaca: quick question, I have a thing in seccomp that needs to write atomically to *os.File, seccomp.ExportBPF(file). do you think its reasonable to extend AtomicWriter to have a BackingFile() that would expose the "tmp" *os.File?
<mvo> Chipaca: this would allow me to kill my code duplication there
<Chipaca> mvo: it needs an *os.File, not an io.Writer?
<mvo> Chipaca: unfortuantely
<pedronis> is it historical or fundamental?
<mvo> Chipaca: its talking to libseccomp and that expects an fd (int)
<pedronis> ah
<Chipaca> mvo: I was this >< close to making AtomicWriter be an actual struct that embedded *os.File :-)
<pedronis> fundamental
<mvo> pedronis: I'm afraid so
<Chipaca> so
<Chipaca> one thing that would be less and more than *os.File
<Chipaca> is to expsoe the Fd :-)
<mvo> Chipaca: export it via an Fd() call?
<Chipaca> (if that's complete nonesense then tell me so -- my pressur dropped and i ended up on the floor a few minutes ago so brain isn't fully engaged yet)
<Chipaca> yeah, add âFd() intâ to the interface
<pedronis> Chipaca: os.File has a a Fd() uintptr
<Chipaca> eh, i don't mind which
<pedronis> mostly, didn't understand the more than *os.File bit of your comment
<Chipaca> it's rather silly, Fd() uintptr feels all low levelly, but then low level things take ints
<pedronis> it's because of multi-platform
<Chipaca> pedronis: from one point of view it's more generic, as many things have fds, not just files (and not just *os.Files)
<mvo> Chipaca: I actually just need *os.File, but I can do the Fd() uint thing
<Chipaca> eh, BackingFile works
<pedronis> Chipaca: os.File is not for files
<Chipaca> mvo: want me to whip it up?
<pedronis> onyl
<pedronis> it has a strange name tbh
<mvo> Chipaca: if its BackingFile() *os.File I have it almost ready,
<Chipaca> one thing we could do if we were feeling pedantic is make it a separate interface
<Chipaca> and check the interface
<mvo> Chipaca: but you are welcome of course, I will do the change in snap-secomp then and merge your commit there
<Chipaca> but... feels too complicated :-)
<Chipaca> mvo: nah, go for it
<mvo> Chipaca, pedronis: thanks for your input
<Chipaca> i'm going to take 10 and lie down for a bit
<ogra_> jdstrand, hmm, where did our mpris interface go ? (i seem to remember snap interfaces shoowing mpris before ... now i dont)
<ogra_> *now i dont see it
<pedronis> Chipaca: get well!
<mvo> Chipaca: yeah, get well!
<zyga-ubuntu> hmmmm
<zyga-ubuntu> for whatever reason "mc" broke on me, all the keyboard navigation is broken and does odd things
<zyga-ubuntu> like printing ".." all the time
 * zyga-ubuntu uses this as a sign to reboot 
<pedronis> mvo: did you find out more about those arm issues ?
<zyga-ubuntu> oddly this worked
<mvo> pedronis: not yet, snapd-vendor-sync broke on us :( and that triggers those builds
<pedronis> :/
<pedronis> mvo: do you want me to just bump those timeouts in #3991, it might be enough ?
 * zyga-ubuntu -> break
<mvo> pedronis: yeah, lets try that
<ogra_> i bet you will find that the AI on arm is strong and that it knows that in Ubuntu you can not combine foo with 128 ... you can only combine seb with 128 here ...
<zyga-ubuntu> will be back to content and layouts soon
<ogra_> :)
<pedronis> mvo: it also needs reviews btw
<mvo> pedronis: ok, will do either next or first thing in my morning
<pedronis> np
<pedronis> I'll try to push some timeout bump there
<jdstrand> ogra_: mpris is not an implicit slot so you eed to have an application installed that slots mpris
<ogra_> jdstrand, ah
<ogra_> irritating (given it shows up as interface in the interface docs)
<jdstrand> eg, vlc, gradio
<ogra_> yeah, i was looking at the gradio thread when asking :)
<mup> PR snapd#3908 opened: snap-seccomp, osutil: use osutil.AtomicFile in snap-seecomp <Created by mvo5> <https://github.com/snapcore/snapd/pull/3908>
<pedronis> mvo: pushed the timeout bump
<mvo> ackk: -^ this is the final PR
<mvo> pedronis: thanks a lot
<ackk> mvo cool
<cachio> mvo, there?
<cachio> I see this issue in the dragonboard v
<cachio> https://paste.ubuntu.com/25521952/
<cachio> mvo, it is breaking the whole test suite on db
<cachio> I'll skip that test
<cachio> and rerun
 * zyga-ubuntu cleans his desk
<zyga-ubuntu> most laptops off
<mup> Issue snapcraft#1453 closed: nodejs plugin recording <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1453>
<mup> PR snapcraft#1524 closed: node plugin: record the yarn.lock file <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1524>
<bschaefer> if im on an sbuild amd64-armhf schroot how to i tell snapcraft to build an armhf package vs an amd64 one?
 * bschaefer sees --target-arch ARCH and tests that
<mup> Issue snapcraft#1457 closed: remote per-project container <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1457>
<mup> PR snapcraft#1302 closed: lxd: mount project folder via sshfs in case of a remote <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1302>
<sergiusens> tyhicks hey there! Mind taking a look at https://forum.snapcraft.io/t/record-machine-information-in-the-manifest/1961/2 ?
<tyhicks> sergiusens: hey! I'll try to have a look a little later this afternoon
<sergiusens> thank tyhicks!
<tyhicks> np
<tyhicks> ratliff: ^ fyi
<ratliff> thanks, tyhicks!
<mvo> cachio: hrm, hrm, so on the db network-manager did never stop?
<mup> PR snapd#3906 closed: many: use snapcore/snapd/i18n instead of i18n/dumb <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3906>
<mup> PR snapd#3907 closed: cmd/snapctl: allow snapctl -h without a context (regression fix) <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3907>
<cory_fu> Are there any known issues with the "home" interface and trusty?  The strictly confined charm snap works fine on xenial, but on trusty I get a "bad system call" or "permission denied" when trying to access files under $HOME
<zyga-solus> cory_fu: hey
<zyga-solus> cory_fu: please tell me more, I'm cleaning my desk but I want do debug/fix this ASAP
<zyga-solus> cory_fu: is your HOME on NFS?
<cory_fu> stokachu: ^
<cory_fu> zyga-solus: It's on a MAAS cluster managed by stokachu, so looping him in
<zyga-solus> stokachu: hey
<stokachu> cory_fu: zyga-solus they are local disks
 * zyga-solus will gladly help
<stokachu> not NFS
<zyga-solus> ok
<zyga-solus> can you please show "snap version" and journalctl or the audit log actually
<zyga-solus> (feel free to send to canonical pastebin)
<cory_fu> zyga-solus: snap version: https://pastebin.ubuntu.com/25522377/
<zyga-solus> woah
<zyga-solus> snapd   2.27.5~14.04
<zyga-solus> what happened here?
<zyga-solus> mvo: ^
<zyga-solus> snapd doesn't reexec on 14.04 for some reason
<zyga-solus> cory_fu: can you collect the system logs as well, most importantly audit log for the actual denial
<zyga-solus> cory_fu: and snapd service logs for the lack or reexec please
<cory_fu> zyga-solus: I'm not super familiar with debugging snaps.  What are the commands for the audit log?
<zyga-ubuntu> cory_fu: the system audit log should be ok (/var/log/syslog)
<zyga-ubuntu> (well audit is logged there directly)
<zyga-ubuntu> (on other distros it gets logged elsewhere)
<cory_fu> zyga-solus: audit: https://pastebin.ubuntu.com/25522445/
<cachio> mvo, it is a tests that was modified in master
<zyga-ubuntu> cory_fu: is this when you reproduce the error?
<cachio> mvo, I think it was fixed for some reason
<cachio> mvo, we should add all the test improvements for next beta on 2.28 if possible
<kyrofa> What is the UI status on Ubuntu Core? Do we support wayland there yet?
<cory_fu> zyga-solus: Well, that was just the lines that matched snap.charm.  If I tail -F the syslog and run the snap commands that fail (`charm create`, `charm build`, etc), nothing new shows up in the log despite the errors
<cory_fu> zyga-solus: Also, how do I get the snapd service log?  I can't seem to find the proper service name
<zyga-ubuntu> cory_fu: hmm, not sure on 14.04 honestly
<zyga-ubuntu> cory_fu: since I'm EOD anyway please open a forum topic, I'll reproduce this first thing tomorrow
<zyga-ubuntu> cory_fu: just one more question
<cory_fu> Ok
<zyga-ubuntu> cory_fu: is this in the ephermeral environment
<zyga-ubuntu> cory_fu: or after installation?
<cory_fu> zyga-solus: Not sure what you mean
<zyga-ubuntu> cory_fu: was the maas note netbooted
<cory_fu> But it's after I install the snap.  Then the charm commands from the snap don't work as they should
<zyga-ubuntu> cory_fu: is is this a vanilla 14.04 install on the disk
<cory_fu> stokachu: ^?
<zyga-ubuntu> cory_fu: I don't have maas at home so if I need to reproduce this, can I just use regular 14.04 system
<cory_fu> zyga-solus: I believe so
<cory_fu> zyga-solus: AFAIK it should just be a regular trusty system
<stokachu> zyga-ubuntu: cory_fu yea these are cloud images
<zyga-ubuntu> OK, thank you
<cory_fu> Ok
<zyga-ubuntu> stokachu: if you can add a link to the forum post, it will help me reproduce
<stokachu> whats the link to the forum post again?
<zyga-ubuntu> forum.snapcraft.io
<stokachu> oh i thought there was a post already
<cory_fu> zyga-solus: Oh, I just realized I was watching the syslog on the wrong machine.  >_<
<zyga-ubuntu> ^_^
 * zyga-ubuntu stays tuned for more logs
<cory_fu> zyga-solus: https://pastebin.ubuntu.com/25522507/
<zyga-ubuntu> hmm, sadly the bad system call is not logged on 14.04
<zyga-ubuntu> I'll reproduce and check
<zyga-ubuntu> can you please include simple instructions about the snaps you've used?
<jdstrand> roadmr: hey, can you sync r930 of the review tools? I've tested it a lot and expanded my local blackbox testing to include --json
<roadmr> jdstrand: sure! will do
<jdstrand> roadmr: but you may want to test a snap or two on staging. this has the change to put error()s into the error json when --json is specified
<zyga-ubuntu> jdstrand: I, for one, cannot wait for seccomp logging
<roadmr> jdstrand: ok, thanks, I'll do more thorough than usual testing
<jdstrand> roadmr: that should get rid of (almost) all cases of 'unexpected output'. there are a couple of other places in bin/click-review that could conceivably create non-json
<cory_fu> zyga-solus, stokachu: https://forum.snapcraft.io/t/issues-with-strictly-confined-snap-charm-on-trusty/2098
<zyga-ubuntu> thank you
<jdstrand> roadmr: but those cases are quite unlikely
<cory_fu> zyga-solus: Thanks for your help.  Have a good evening!
<jdstrand> zyga-ubuntu: we have seccomp logging today. what we don't have is not killing plus logging
<jdstrand> zyga-ubuntu: you're probably seeing kernel rate limiting.
<jdstrand> zyga-ubuntu: I've been using this: alias tail_journalctl='sudo sysctl -w kernel.printk_ratelimit=0 ; journalctl --follow'
<zyga-ubuntu> jdstrand: I think it's not working at all on 1404
<zyga-ubuntu> jdstrand: logging (journald) is just absent there entirely
<jdstrand> the first disables rate limiting (though it can still happen...) and the latter seems to not have things drop as often. maybe I'm imagining things there
<zyga-ubuntu> jdstrand: I'm familiar with rate limiting, though I don't think we've hit it here
<jdstrand> zyga-ubuntu: the 1404 lts kernel is (nearly?) identical to xenial
<zyga-ubuntu> jdstrand: it's identical but userspace parts are not
<jdstrand> zyga-ubuntu: perhaps rsyslog stopped logging altogether. I've seen that. try logger
<zyga-ubuntu> jdstrand: AFAIK we're not loggged at all on 14.04
<zyga-ubuntu> jdstrand: systemd starts snapd
<zyga-ubuntu> jdstrand: but it's not integrated with regular syslog
<zyga-ubuntu> jdstrand: so on 14.04 logs are just lost (from snaps and snapd)
<jdstrand> I see
<jdstrand> well, that is different than 'seccomp logging' of course :)
<jdstrand> seems need to wire that all up
<jdstrand> I have to believe that the snapd systemd is getting the messages-- just need to shove them into rsyslog
<jdstrand> but, apparmor and seccomp should log cause that is coming from the kernel, not snapd
<roadmr> jdstrand: so with these latest changes - if there's a stray /tmp/blahblah, what'll be the exit code? will it exit with 1?
<roadmr> (or is that considered a non-fatal condition and exits with whatever the actual review outcome was?)
<jdstrand> and if they aren't, either it is rate limiting or rsyslog isn't logging (again, I've witnessed that)
<jdstrand> roadmr: are you talking about the reaping code?
<roadmr> jdstrand: yes, which I think is the one spitting out those "error can't find /tmp/whatever" which is what was confusing sca
<jdstrand> roadmr: if so, it try's to remove the dir, if there is any exception, it logs via syslog
<roadmr> nice
<jdstrand> roadmr: but that is unchanged from r922 that is in prod now
<jdstrand> roadmr: I thought you said before that that issue was resolved for a week or more?
<roadmr> jdstrand: yes, we haven't seen that recently
<jdstrand> roadmr: we had that one snap that had 'unexpected output' a few times, but no other issues (the sync today is meant to give us insight into what happened with that snap)
<jdstrand> roadmr: ok, cool
<roadmr> yep, that's what I meant :) thanks!
<zyga-ubuntu> jdstrand: thank you for checking that systemd thing in my PR, looks like (oddly) a regression in master
<zyga-ubuntu> jdstrand: did you have a chance to look at the changes I made since your previous review?
<om26er> Hi! with snapd-control interface connected, can I talk to the snapd unix socket ?
<om26er> currently even checking if that path exists (with snapd-control) says permission denied
<om26er> zyga-ubuntu: ^
<om26er> my snap will install/remove/refresh/list snaps remotely, so need to talk to the snapd daemon.
<om26er> s/daemon/unix-socket
<jdstrand> zyga-ubuntu: dude
<jdstrand> zyga-ubuntu: :)
<jdstrand> zyga-ubuntu: I'm moving to it now. note, it still needs a deep audit of bootstrap.c
<kyrofa> jdstrand, do you know the current status of wayland on Ubuntu Core?
<kyrofa> Or is mir still the one used there?
<jdstrand> kyrofa: mir-kiosk. no slot side policy for wayland yet (and thus no wayland snap)
<kyrofa> jdstrand, okay, thank you
<jdstrand> kyrofa: note, nobody afaik is assigned to create a wayland slot implementation
<kyrofa> jdstrand, exactly the info I needed
<kyrofa> ogra_, any chance you're around?
<zyga-ubuntu> om26er: yes, you must just connect to it
<kyrofa> jdstrand, we don't have a can bus interface, right?
<zyga-ubuntu> jdstrand: thank you :)
<jdstrand> kyrofa: correct. I'll note apparmor and snap-seccomp understand AF_CAN so an interface shouldn't be terribly difficult
<kyrofa> jdstrand, good, just checking. No LIN interface either? I'm not very familiar with that one: my research says no, but I want to make sure it's not covered by something else
<jdstrand> kyrofa: I'm going to say 'no' since I've never heard of LIN :P
<kyrofa> Sounds about right! Thanks jdstrand :)
<jdstrand> kyrofa: more seriously. no, no LIN yet
<zyga-ubuntu> jdstrand: corrected the two remarks
<zyga-ubuntu> kyrofa: wow, can and lin
<zyga-ubuntu> kyrofa: are you making a car?
<zyga-ubuntu> snap install wheel
<kyrofa> zyga-ubuntu, responding to someone who is
<jdstrand> kyrofa: seems that might be lumped in with CAN if one was doing it, but of course would have to research/review the implementation
<bschaefer> hmm seems a new core update 2913 and im getting:
<bschaefer> Sep 12 08:43:53 localhost kernel: [    5.209208] vc4-drm soc:gpu: failed to bind 3f902000.hdmi (ops vc4_hdmi_ops [vc4]): -517
<bschaefer> Sep 12 08:43:53 localhost kernel: [    5.217788] vc4-drm soc:gpu: master bind failed: -517
<zyga-ubuntu> I should take a break
<bschaefer> ogra_, ping if you're around :) (seems to be some vc4/kernel issues)
<bschaefer> no /dev/dri
<zyga-ubuntu> bschaefer: is this a stable core snap?
<bschaefer> i was on an edge image
<bschaefer> http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/
<bschaefer> and core just bumped up to core        16-2.27.6+git365.f5f40b0  2913  canonical  core
<bschaefer> (or so it seemed to have updated where it wasnt before as ive been reflashing that image all day)
<bschaefer> just reflashed before core updates
<bschaefer> core        16-2.27.6+git363.8fc1b40  2897  canonical  core
<bschaefer> seems happy with vc4
<zyga-ubuntu> exit
<niemeyer> jdstrand: Still around?
<mup> PR snapd#3903 closed: tests: change regex used to validate installed ubuntu core snap <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3903>
<jdstrand> niemeyer: only for a moment. still working through 3621 (should be done tomorrow, got sidetracked by some high priority stuff, but back to 3621)
<niemeyer> jdstrand: Yo
<niemeyer> jdstrand: Any chance of a quick review for a name req?
<jdstrand> niemeyer: I don't usually do name requests... /me would have to look up how to do that
<niemeyer> jdstrand: Was hoping to have a call with zyga and you today, but we can do that tmorrow
<jdstrand> niemeyer: what is the name and what do you want done with it?
<niemeyer> jdstrand: Ah, sorry, np
<jdstrand> ok
<jdstrand> niemeyer: is the call about 3621?
<niemeyer> jdstrand: Yeah, I think so
<jdstrand> (snap-update-ns)
<niemeyer> Yeah
<niemeyer> jdstrand: Who usually approves names?
<jdstrand> if the call is about the status, I'll have my final review done tomorrow. there won't be any blockers, but will have requested changes
<niemeyer> jdstrand: Super, thanks
<jdstrand> niemeyer: I feel like it's the store team or possibly advocacy. noise][ and nessita or ev would be who I personally would go to
<niemeyer> jdstrand: Ack, thanks
#snappy 2017-09-13
<zyga-ubuntu> good morning
<zyga-ubuntu> hey mvo :)
<mvo> pedronis: fwiw, the errors during build are "settle is not converging" so your theory about the time being too low seems to be correct (for the armhf build failure)
<mvo> hey zyga-ubuntu
<mup> PR snapd#3909 opened: daemon: remove unused installSnap var <Created by mvo5> <https://github.com/snapcore/snapd/pull/3909>
<mup> PR snapd#3910 opened: snap-repair: fix test failure in TestRepairHitsTimeout <Created by mvo5> <https://github.com/snapcore/snapd/pull/3910>
<mup> PR snapd#3911 opened: many: add logger.MockLogger() and use it in the tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3911>
 * mwhudson o/
<zyga-ubuntu> hey mwhudson
 * zyga-ubuntu has a sad face at ext4 corruption on his artful box
<zyga-ubuntu> in other news seagate disks are still seagate
<zyga-ubuntu> hey pstolowski
<pstolowski> zyga-ubuntu, morning!
<mup> PR snapd#3900 closed: snap-seccomp: manually resolve socket() call in tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3900>
<mup> PR snapd#3891 closed: daemon: reach for Overlord.Loop less thanks to overlord.Mock <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3891>
 * zyga-ubuntu -> quick walk
<pstolowski> pedronis, zyga-ubuntu hey guys, do you have a moment for quick HO?
<om26er> popey: Hi! Mind taking a look at https://dashboard.snapcraft.io/dev/snaps/8349/rev/1/ ?
<om26er> it just uses the snapd-control interface
<pedronis> pstolowski: yes
<pstolowski> let's wait for zyga-ubuntu
<zyga-ubuntu> pstolowski: yes
<pstolowski> pedronis, zyga-ubuntu https://hangouts.google.com/call/IDjZPuXPNW1dCKRuMO8sAAkI
<mup> PR core#59 opened: fix object path used by usr/bin/xdg-open in core <Created by mvo5> <https://github.com/snapcore/core/pull/59>
 * Son_Goku gurgles awake
<Son_Goku> zyga-ubuntu, can you *please* test the new snapd in Fedora?
<Son_Goku> https://bodhi.fedoraproject.org/updates/FEDORA-2017-4546b9dd38 (F27)
<Son_Goku> https://bodhi.fedoraproject.org/updates/FEDORA-2017-8ef8c9e6c2 (F26)
<Son_Goku> https://bodhi.fedoraproject.org/updates/FEDORA-2017-d699df2619 (F25)
<Son_Goku> zyga-ubuntu: I've got the docs update waiting for it: https://github.com/CanonicalLtd/snappy-docs/pull/103
<mup> PR CanonicalLtd/snappy-docs#103: Update Fedora snapd to 2.27.6 <Created by Conan-Kudo> <https://github.com/CanonicalLtd/snappy-docs/pull/103>
<zyga-ubuntu> Son_Goku: hey
<Son_Goku> zyga-ubuntu: I've also got hughsie waiting for it because GNOME Software things
<zyga-ubuntu> Son_Goku: yes, I'll test them immediately
<zyga-ubuntu> Son_Goku: I also saw the golang import was changed in the repos
<zyga-ubuntu> Son_Goku: so we might be able to test that and land your other branch
<Son_Goku> it's in updates-testing, yes
<Son_Goku> well, my current stuff is landed
<Son_Goku> because the CI was going to fail going forward anyway :)
<Chipaca> niemeyer: thank you for the review on #3866! good stuff
<mup> PR #3866: many: implement fetching sections and package names periodically <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3866>
<zyga-ubuntu> Son_Goku: updating F26 now, I'll test it when it is ready
<mup> PR snapd#3912 opened: asserts: add empty values check in HeadersFromPrimaryKey <Created by pedronis> <https://github.com/snapcore/snapd/pull/3912>
<ackk> mvo, hi, any chance your PR can be merged today? :)
<zyga-ubuntu> Son_Goku: ok, testing F26 now
<mvo> ackk: #3908 has one review already, if e.g. Chipaca does another one it can go in. there is an open question about a small detail raised by niemeyer but I think the overall direction is good so hopefully it lands today
<mup> PR #3908: snap-seccomp, osutil: use osutil.AtomicFile in snap-seccomp <Created by mvo5> <https://github.com/snapcore/snapd/pull/3908>
<ackk> nice, thanks
<pedronis> Chipaca: hi, #3908 seems something you could review
<mup> PR #3908: snap-seccomp, osutil: use osutil.AtomicFile in snap-seccomp <Created by mvo5> <https://github.com/snapcore/snapd/pull/3908>
<Chipaca> pedronis: sorry, can't review things twice :-p
<Chipaca> (i _just_ did it)
<mup> PR snapd#3909 closed: daemon: remove unused installSnap var <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3909>
<pedronis> mvo: are we sure in #3910 that 100ms is enough ?
<mup> PR #3910: snap-repair: fix test failure in TestRepairHitsTimeout <Created by mvo5> <https://github.com/snapcore/snapd/pull/3910>
<mvo> pedronis: no, this is just a guestimate, I figured 10x than before is hopefullyok
<mvo> hopefully ok even
<zyga-ubuntu> hmm, gnome shell crashes sometimes :/
<mup> PR snapd#3912 closed: asserts: add empty values check in HeadersFromPrimaryKey <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3912>
 * ogra_ gllares at https://github.com/snapcore/core/pull/59 and wonders why it works for him even without that change
<mup> PR core#59: fix object path used by usr/bin/xdg-open in core <Created by mvo5> <https://github.com/snapcore/core/pull/59>
<ogra_> mvo, seeing that, it shouldnt work at all for me, should it ?
 * ogra_ is confused
<mvo> ogra_: yes, it should not work if you have the 2.28 debs
<mvo> ogra_: does it work with those?
<ogra_> it wrks with the 2.27 debs and yoour test core from candidate
<mvo> ogra_: the fallback (snapd-xdg-open) launcher will work
<ogra_> ah !
<ogra_> ok
<mvo> ogra_: yeah, that is ok, then you are using the fallback
<ogra_> thats clears my cooonfusion :)
<mvo> ogra_: tests ftw :)
 * mvo will write some more today
<ogra_> :)
<zyga-ubuntu> wrz 13 12:37:26 fyke gnome-shell[1591]: Failed to apply DRM plane transform 0: Brak dostÄpu
<zyga-ubuntu> hmmm
<zyga-ubuntu> Brak dostÄpu = no access/permission denied
<zyga-ubuntu> is repowerd nuts?
<zyga-ubuntu> wrz 13 12:44:21 fyke sudo[24161]: pam_unix(sudo:session): session opened for user root by (uid=0)
<zyga-ubuntu> wrz 13 12:44:38 fyke repowerd[940]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(c1,/org/freedesktop/login1/session/c1)
<zyga-ubuntu> wrz 13 12:44:38 fyke repowerd[940]: LogindSessionTracker: activate_session(c1)
<zyga-ubuntu> wrz 13 12:44:38 fyke sudo[24161]: pam_unix(sudo:session): session closed for user root
<zyga-ubuntu> wrz 13 12:44:38 fyke repowerd[940]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(13,/org/freedesktop/login1/session/_313)
<ackk> uhm, I'm getting "AttributeError: /home/ack/virtualenv/snapcraft/bin/python: undefined symbol: archive_errno" in snapcraft master
<zyga-ubuntu> wrz 13 12:44:38 fyke repowerd[940]: LogindSessionTracker: activate_session(13)
<zyga-ubuntu> every time I close my root shell it does this
<zyga-ubuntu> Son_Goku: send F26 feedback
<mup> PR snapd#3910 closed: snap-repair: fix test failure in TestRepairHitsTimeout <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3910>
<morphis_> mvo, popey: can you have a look at https://forum.snapcraft.io/t/auto-connecting-interfaces-for-easy-openvpn-snap/2029/3 and give +1 if you're fine? saw you're listed as store reviewer
 * popey looks
<zyga-ubuntu> mvo: on zesty with wayland I don't get gnome shell to find any snap desktop files
<zyga-ubuntu> mvo: not sure if regression but annoying
<zyga-ubuntu> mvo: /home/zyga/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/
<zyga-ubuntu> this is XDG_DATA_DIRS
<pedronis> zyga-ubuntu: is it this, or related?   https://forum.snapcraft.io/t/desktop-file-names/2096/2
<ogra_> zyga-ubuntu, isnt the PR fr that still open ?
<zyga-ubuntu> how come flatpak is there but snapd is not
<ogra_> hmm https://github.com/snapcore/snapd/pull/3398 says merged
<mup> PR #3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3398>
<zyga-ubuntu> pedronis: also annoying but does not seem related
<pedronis> ah, zesty though?Â  not artful?
<pedronis> does it work on artful?
<pedronis> do we even support walyand officially on zesty?
<zyga-ubuntu> pedronis: yes
<zyga-ubuntu> pedronis: it works but I'm on xorg there due to GPU
<zyga-ubuntu> pedronis: so s/yes/maybe/
<zyga-ubuntu> it's in the environment for sure but I'm running xorg, not wayland
<ogra_> well, the above PR fixes it ... but i'm not sure it is anywhere else but master yet
<zyga-ubuntu> ogra_: I'm running master
<zyga-ubuntu> ogra_: maybe I need to tweak something
 * zyga-ubuntu looks
<zyga-ubuntu> I probably didn't install data files
<ogra_> well, you should have a snapd.sh in /etc/profile.d
<ogra_> (are you running the master *deb* ?)
<zyga-ubuntu> I have apps-bin-path.sh
<zyga-ubuntu> ogra_: no, that's the problem
<ogra_> :)
<ogra_> just create the .sh file from the PR
<ogra_> (and re-login indeed)
<zyga-ubuntu> ok, tweaked
<zyga-ubuntu> yep
<zyga-ubuntu> brb
<zyga-ubuntu> my open terminals :'((
<ogra_> yeah ... we should really have a "save session per terminal" feature :)
<zyga-ubuntu> I used :mks in vim
<zyga-ubuntu> but not other places
<zyga-ubuntu> gnome used to have this but then nobody did it correctly so it was removed
<ogra_> that still only gives you one bash histroy :)
<zyga-ubuntu> (and ironically then apple did it)
<zyga-ubuntu> so maybe gnome will do it now again
<zyga-ubuntu> well
<zyga-ubuntu> brb
<ogra_> i want each term pop up where it closed ... with the same histry it had
<zyga-ubuntu> well, that worked
<ogra_> :)
<ogra_> heh ... https://massdrop-s3.imgix.net/product-images/massdrop-x-oblotzky-sa-oblivion-custom-keycap-set/sa_oblivion_kit_04_git_modifiers_20170828131112.png?auto=format&fm=jpg&fit=crop&w=924&dpr=1
<zyga-ubuntu> Chipaca: what did I do wrong: "snap refresh -> all snaps are up to date"; "snap refresh core -> working on core refresh"
<zyga-ubuntu> Chipaca: bug? feature?
<ogra_> stop using core in devmode ? :P
<Chipaca> what ogra_ said
<zyga-ubuntu> Chipaca: and core was in devmode for ? reasons
<zyga-ubuntu> how is that possible
<ogra_> (i was joking ! )
<Chipaca> zyga-ubuntu: wasn't it?
<zyga-ubuntu> (this is on debian)
<Chipaca> zyga-ubuntu: without seeing what we told the store and what the store replied i have no idea
<zyga-ubuntu> Chipaca: where is devmode listed
<ogra_> snap list
<zyga-ubuntu> Chipaca: I bet this is local and the fact that core was in devmode
<Chipaca> zyga-ubuntu: you have debug logs on, right?
<Chipaca> zyga-ubuntu: if core is in devmode it's because you installed it in devmode
<zyga-ubuntu> core was auto-pulled on 1st snap
<Chipaca> then it shouldn't be in devmode
<Chipaca> zyga-ubuntu: show me the logs
<zyga> Chipaca: https://paste.gnome.org/paaya4wqy
<ogra_> (does core in devmode even make any sense ?)
<zyga-ubuntu> I haven't got more than this so far
<Chipaca> zyga-ubuntu: journalctl -u snapd ?
<zyga> https://paste.gnome.org/psr27grjj
<Chipaca> zyga: zyga-ubuntu: why aren't you running with debug :-(
<zyga> hold on, https://paste.gnome.org/pjorsj5aj
<zyga> Chipaca: because I just booted that, sorry,
<Chipaca> zyga: turn on debug and try to reproduce?
<Chipaca> zyga: in particular i need the SNAPD_DEBUG_HTTP=7 as well as SNAPD_DEBUG=1
<Chipaca> while you do that, i'm going to lunch
<zyga-ubuntu> Chipaca: reproduced
<zyga> https://paste.gnome.org/pbsnaw5lx
<zyga> I reverted, set the environment, restarted snapd, did refresh (all) again
<Chipaca> zyga: so that's just for 'snap refresh', right?
<ackk> does network-bind also allow to create unix sockets?
<Chipaca> zyga: what revision of core do you have?
<Chipaca> zyga: nm, i see it in the other paste
<Chipaca> zyga: so, the store is very clearly telling us to refresh core
<Chipaca> zyga: we're saying we have rev 2774, it's saying there's 2844 available, and here is the delta for going from 2774 to 2844
<Chipaca> now for real, i need to go make lunch
<Chipaca> zyga: (just in case i wasn't clear: BUG IN SNAPD)
<Chipaca> :-)
 * Chipaca lunch
<zyga-ubuntu> Chipaca: thank you!
 * zyga-ubuntu -> lunch
<mup> PR snapd#3913 opened: tests: add test that ensures that all core services are working <Created by mvo5> <https://github.com/snapcore/snapd/pull/3913>
<zyga-ubuntu> Pharaoh_Atem: https://taskotron.fedoraproject.org/artifacts/all/f04e1f84-9873-11e7-89a8-525400817a8f/task_output/snapd-2.27.6-1.fc26.log ?
<jdstrand_> exit
<jdstrand_> meh
<zyga-ubuntu> jdstrand: :)
<ogra_> jdstrand, have you seen https://forum.snapcraft.io/t/hdmi-audio-on-db410c-not-working/2106 ? (i wonder if the alsa interface needs to support sockets or if alsa-utils needs network interface support ... though i'm not sure if that has any influence on the functionality)
<Son_Goku> zyga-ubuntu: the f27 update needs karma: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4546b9dd38
<zyga> aha
<zyga> I'll try to test it too
<Son_Goku> f25 has the same problem: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d699df2619 :)
<zyga> yep, I have that too
<glitsj16> Hi all, after noticing an error in systemd journal about snap-repair, I looked at https://git.launchpad.net/snapd/tree/data/systemd/snapd.snap-repair.service.in and noticed that is already fixed in git by adding ConditionKernelCommandLine=snap_core to the unit file. So all good in that respect. Just wanted to report a possible typo in the same file. Last line (10) mentions "Environment=SNAP_REAPIR_FROM_TIMER=1", which I assume is meant t
<glitsj16> o be "Environment=SNAP_REPAIR_FROM_TIMER=1" instead?
<zyga> oh
<zyga> glimcoil: yes that looks like a typo
<zyga> mvo, pedronis: ^
<glitsj16> seemed a bit silly to file a bug report on a typo, thought I would mention it here first
<ikey> unless its a super hidden acronym
<ikey> like.. Rest Easy As Paddy Invokes Republicanism
 * ikey had little to go on. :P
<glitsj16> ikey: possibly, I'm not at all familiar with the code
<ikey> looks typo-y
<glitsj16> nor with Republicanism :p .. but that's a minefield I'm not getting into
<ikey> xD
<ogra_> we'll just fix the oxford dictionary and add an alias !
<mvo> cachio: if you have a working aarch64 sysstem, could you please paste me the output of "SNAP_SECCOMP_DEBUG=1 /usr/lib/snapd/snap-seccomp compile <(echo mknod) /tmp/xxx" (or anyone else with an arm64 system)
<cachio> mvo, one minute
<mvo> cachio: no rush, thanks a lot!
<pedronis> pstolowski: btw, I was thinking that maybe it's easier to split switching from PlugInfo to PlugData, in two parts, first part Plug/SlotData has the same definition as Plug/SlotInfo (only difference is we make a deep copy of attrs when we make PlugData),  so in a lot of places is just a rename, 2nd phase we give PlugData its real interface
<cachio> mvo, https://paste.ubuntu.com/25527599/
<mvo> cachio: \o/ thank you so much
<cachio> mvo,  np
<mvo> cachio: oh, this is amd64, right? I need it for arm - aarch64, the dragonboard
<cachio> ahh, one minute
<niemeyer> mvo: I thought we had fixed the issue of quoting on "snap info"
<mvo> niemeyer: I thought so too, let me look
<niemeyer> mvo: But it seems that 2.27.6 is still quoting all summaries..
<mvo> niemeyer: that was pr 3610
<mup> PR #3610: snap: do not always quote the snap info summary <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3610>
<mvo> niemeyer: let me check what is going on
<roadmr> mvo: hi! hey so - check an api response to https://api.snapcraft.io/api/v1/snaps/details/$SOME_SNAP. We're now exposing "contact" - the field was renamed in the web UI to "Contact URL" (can be either http{,s} or mailto url)
<mvo> roadmr: nice!
<roadmr> mvo: so for now and for backward-compatiblity it has the same info as support_url, but that'll eventually be deprecated
<mvo> roadmr: sounds good, thanks for adding this
<roadmr> note though the API response's field is called simply "contact", not "contact_url"
<roadmr> mvo: thank matiasb_, he did it all :)
 * mvo thanks matiasb_
<niemeyer> mvo: Yeah, clearly recall discussing this in the sprint and looking at that code
<niemeyer> It's even tested.. wtf
<mvo> niemeyer: I have exactly the same feeling
<mvo> niemeyer: looks like 2.27 does not have it yet
<mvo> niemeyer: if you switch to edge it seems to be ok
<niemeyer> mvo: Wow.. wat
<mvo> niemeyer: yeah, huge latency :(
<mvo> ogra_: do you know if we have a git branch for initramfs-tools-ubuntu-core?
<niemeyer> mvo: Yeah, I hadn't realized (or internalized) that the dots were not really catching up
<ogra_> mvo, under core-build
<mvo> niemeyer: I am surprised about the delay too, we need to get to 2.28 to be vaguely back on track
<mvo> ogra_: ta
<cachio> mvo, https://paste.ubuntu.com/25527679/
<cachio> mvo, on my db
<mvo> cachio: thank you, that is very interessting
<cachio> mvo, yaw
<zyga-ubuntu> re
<zyga-ubuntu> Chipaca: FYI the debug logs above were not useful because we had reverted, earlier change where the core did not refresh is real but we don't have a case for reproducing that yet
<zyga-ubuntu> jdstrand: hey, just a quick note, I'm still going through the review, using code from libsnap-confine-private in snap-update-ns bootstrap.go is rather painful because of how linking in go build works
<zyga-ubuntu> jdstrand: any code sharing between is in general a global pain
<mup> PR core-build#20 opened: ubuntu-core-rootfs: deal with (broken) symlink in sync_dirs <Created by mvo5> <https://github.com/snapcore/core-build/pull/20>
<ogra_> mvo, approved ... (needs a manual deb build and PPA upload)
<ogra_> oh ... and a kernel snap rebuild too indeed
<zyga-ubuntu> mvo: for testing, you _might_ explore the initramfs test tools I wrote
<zyga-ubuntu> mvo: but it could be time consuming to learn how to use it initially
 * ogra_ looks forward to split-initrd ... that will save so much timt
<ogra_> *time
<ogra_> (just waiting to get my splash PRs all approved before landing that one)
<zyga-ubuntu> mvo: let me know if you want to try that and need a hand
<pstolowski> pedronis, that could make things a little bit easier, but I'm not too keen on that. anyway, thanks for the suggestion
 * zyga-ubuntu is hungry-ish and considers breaking now, doing some office manintenance and then sitting with jdstrand for a quick chat about bootstrap.c
<zyga-ubuntu> jdstrand: would you have some time to discuss those points?
<jdstrand> zyga-ubuntu: I have an appt and about to step out
<zyga-ubuntu> jdstrand: are you going to be back today?
<jdstrand> zyga-ubuntu: yes, in ~3 hours
<mup> PR snapd#3914 opened: snap-seccomp: skip mknod syscall on arm64 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3914>
<jdstrand> zyga-ubuntu: was there a contentious point in my feedback?
<zyga-ubuntu> jdstrand: not sure, I think I just want to chat about each and explain what happened
<zyga-ubuntu> jdstrand: and discuss possible approaches
<zyga-ubuntu> jdstrand: mainly that reusing code from other parts is hard
<zyga-ubuntu> jdstrand: but anyway
<zyga-ubuntu> jdstrand: my wife just called me and I need to break for ~3 hours too
<zyga-ubuntu> so let's talk later :)
<jdstrand> zyga-ubuntu: note, I wasn't blocking on that
<jdstrand> but sure, 3 hours
<zyga-ubuntu> jdstrand: if those are not blocking can we land and iterate?
<jdstrand> there was a lot more to my comments than code factoring
<jdstrand> but if you do those things, sure
 * jdstrand -> appt
<zyga-ubuntu> k
<kyrofa> niemeyer, it seems ubuntu.rocket.com has an expired cert
<kyrofa> Err, other way... you get the idea. No coffee yet
<niemeyer> kyrofa: :)
<niemeyer> kyrofa: I can't fix that one I think.. but let me look
<kyrofa> Since we use HSTS, I can't even add an exception for it
<ogra_> i just clicked on "yes" when the question about the cert popped up
<ogra_> didnt you get that popup ?
<ogra_> (that should add the exception client side)
<ogra_> (/me notes that kyrofa perhaps doesnt use the rocket client snap though)
<kyrofa> ogra_, no, firefox
<ogra_> ah
<ogra_> yeah, that might treat it different indeed
<kyrofa> The fact that the client doesn't obey HSTS probably isn't a good thing
<ogra_> yeah
<niemeyer> kyrofa: Yeah, I can't do much about it
<kyrofa> niemeyer, is that IS?
<niemeyer> kyrofa: I have only admin access to the software, but not to the system, and I think the cert is done via nginx
<niemeyer> kyrofa: yeah, I would try there first..
<niemeyer> kyrofa: They will at least know how runs it
<niemeyer> who
<niemeyer> It was sabdfl originally, but I'd be surprised if it was still there
<ogra_> oh, actually, the rocket desktop client only works half now after restarting it
<ogra_> no graphics at all
<kyrofa> Interesting
<ogra_> hmm, a second restart fixed it
<ogra_> weird
<sergiusens> ogra_ retrying enough made it work for me
<sergiusens> and yes, the cert expired at ~noon utc today
<ogra_> yeah, it works here as well again
<sborovkov_> ogra_, in the gadget snap would not it make sense to pin down specific revisions for the components that are built from source?
<ogra_> sborovkov_, we do that ...
<ogra_>  git clone --depth=1 https://github.com/raspberrypi/firmware.git -b "1.20170515" ....
<ogra_>     source: git://git.denx.de/u-boot.git
<ogra_> +    source-branch: v2017.05
<ogra_> in https://github.com/snapcore/cm3-gadget/pull/1/files
<mup> PR cm3-gadget#1: build uboot from source, pull blobs from upstream, use dtbs from archive <Created by ogra1> <https://github.com/snapcore/cm3-gadget/pull/1>
<sborovkov_> ogra_, not for psplash though?
<ogra_> well, psplash doesnt really change in the tree we pull it from (and i'm not sure they even use tags or branches)
<ogra_> but yeah, one could do that
<ogra_> the prob is that psplash doesnt really have any upstream anymore ... poky itself is dead and got merged into yocto
<ogra_> we could as well, just fork it into a GH tree
<sborovkov_> Ah ok. Just to make sure it does not actually point to something else
<sborovkov_> as it uses master
<ogra_> http://git.yoctoproject.org/cgit/cgit.cgi/psplash
<ogra_> there are hHEAD and master ... but they are identical
<sborovkov_> ogra_ yeah but repo is alive, last commit from 12 days ago. So something might get broken at one point
<ogra_> long term it probably makes sense to carry our own tree but i dont think it is super important
<ogra_> did you have any issues building ?
<sborovkov_> no :-) I am just being bothered by people on code review who want to pin every possible thing down to specific version :-(
<Chipaca> zyga-suse: how does arch define what files get removed when you remove a package?
<ogra_> sborovkov_, https://github.com/ogra1/psplash ... i promise i wont change it :P
<ogra_> sborovkov_, you can use the 09.2017 tag in your gadget now
<Chipaca> zyga-suse: also, is %dir documented anywhere? i guess it does what i want but i'm just guessing
<sborovkov_> ogra_ ok thanks
<Chipaca> zyga-suse: o/
<Chipaca> zyga-ubuntu: or you :-) o/
<mvo> 2.28~rc3 in the beta channel  now and rc3 builds in xenial,zesty,artful,trusty everywhere so yay progress
<niemeyer> \o/
<niemeyer> mvo: Thanks!
<Pharaoh_Atem> zyga-suse: karma for Fedora updates?
<Pharaoh_Atem> I only see F26
<Pharaoh_Atem> I need some for F25 and F27
<cachio> mvo, did you add the fixes for failover and install-store tests?
<mvo> cachio: if there were tagged with 2.28 then yes, if not then no :) if there were not tagged, could you please give me the PR numbers and I can look at this in my morning
<cachio> sure
<cachio> mvo, let me search forthem
<zyga-ubuntu> Chipaca: hey
<Chipaca> zyga-ubuntu: dunno if you saw my questions to your alter ego
<zyga-ubuntu> Pharaoh_Atem: soon, I had to go out
<Chipaca> zyga-ubuntu: does arch have a way of saying what needs to be done to remove the package? I can't see it
<zyga-ubuntu> Chipaca: no, but if you sent them to zyga-suse then I can see them in 2 minutes
<zyga-ubuntu> Chipaca: just pulling over now
<Chipaca> zyga-ubuntu: and the second question was whether opensuse's %dir was documented anywhere
<zyga-ubuntu> Chipaca: I suspect so
<zyga-ubuntu> one sec
<Chipaca> i'm guessing at opensuse needing a "%dir /var/cache/snapd"
<zyga-ubuntu> Chipaca: https://en.opensuse.org/openSUSE:Packaging_guidelines
<zyga-ubuntu> look for %dir
<Chipaca> zyga-ubuntu: yeah, i'd gotten to this page on my own, but it doens't really tell me if %dir means the directory will be cleaned up on remove
<zyga-suse> Chipaca: I think so but let me do an experiment
<zyga-suse> Chipaca: I just need to put the groceries where they belong
<Chipaca> zyga-suse: and i need to get the fish to hug the broccoli
<Chipaca> zyga-suse: but i'll leave this on and read it when i get back
<Pharaoh_Atem> if the directory is created by snapd package, it'll be removed by it, if there's no contents inside
<Pharaoh_Atem> http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-DIR-DIRECTIVE
<Chipaca> Pharaoh_Atem: and if it has contents?
<zyga-ubuntu> Chipaca: fine
<mup> PR snapd#3911 closed: many: add logger.MockLogger() and use it in the tests <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3911>
<Pharaoh_Atem> Chipaca: I think it will not remove it
<Pharaoh_Atem> though I'm not sure
<Pharaoh_Atem> it may choose to delete it since it doesn't know what's in it
<mup> PR snapd#3915 opened: cmd/snap: return empty document if snap has no configuration <Created by stolowski> <https://github.com/snapcore/snapd/pull/3915>
<kwmonroe> hey snappers, should i be able to share $SNAP_USER_foo with the content interface?  my slot can define "read: $SNAP" and a plug works as expected.. but when i use "read: $SNAP_USER_COMMON", i get this, as if $SNAP_USER_COMMON is being taken literally:
<kwmonroe> $ snap run --shell pig
<kwmonroe> cannot perform operation: mount --bind -o ro,nosuid,nodev /snap/hadoop/x1/$SNAP_USER_COMMON /snap/pig/x1/hadoop: No such file or directory
<ogra_> just use the home interface, it should have access to all non dot dirs in your home already
<ogra_> (SNAP_USER_COMMON in the above case is ~/snap/pig/common )
<kwmonroe> oooh!  gotcha ogra_.  /snap/hadoop/x1/$SNAP_USER_COMMON  threw me off, but it makes sense that it's USER_blah in the context of the pig snap.
<kwmonroe> thanks!
<ogra_> if you have a hadoop snap and want to access the user specific data, the home interface should give you access to ~/snap/hadoop/current (or ~/snap/hadoop/common) as long as no hidden dir is involved
<kwmonroe> yup, +1
<mup> PR snapcraft#1540 closed: plugins: extract python finder functions <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1540>
<mup> PR snapd#3913 closed: tests: add test that ensures that all core services are working <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3913>
<mup> PR snapcraft#1547 opened: plugins: extract sitecustomize logic from python <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1547>
<om26er> does Ubuntu Core have dbus ?
<roadmr> jdstrand: howdy, click-reviewer-tools r930 is now live
<kyrofa> niemeyer, in the configure hook, is there any way to compare new values to old? Or is it still always new?
<niemeyer> kyrofa: Still always new..
<niemeyer> kyrofa: Really want to do something about that
<niemeyer> Ideally with deltas rather than just what's new and what's old
<niemeyer> Config has a lot of love to receive still
<kyrofa> Indeed
<kyrofa> Alright, thanks!
<jdstrand> roadmr: woo, thanks!
<jdstrand> roadmr: kenvandine fyi, that has the desktop and desktop-legacy interfaces ^
<roadmr> jdstrand: hehe you lucked out as usual, not many changes to deploy
<mup> PR snapd#3880 closed: tests: add trivial canonical-livepatch test to ensure we do not break it <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3880>
<jdstrand> roadmr: I'm curious now what we'll see with those occasional unexpected outputs
<roadmr> \o/
<roadmr> jdstrand: yeah... not sure :( if it doesn't have the thing in the json that causes the store to consider it failed, it'll likely just be noted as another test and stored in the output
<kenvandine> jdstrand, woot
<jdstrand> roadmr: it will show up as an error, which will flag manual review, so I'll see it
<jdstrand> roadmr: that is for anything that calls error(). if we see 'unexpected output' after this, there are only a couple of things it could be
<roadmr> jdstrand: ah! I get it now.
<tvansteenburgh> kyrofa: anything i can do to help move along https://bugs.launchpad.net/snapcraft/+bug/1686481 ?
<mup> Bug #1686481: stage-packages doesn't respect architectures <kubernetes> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1686481>
<tvansteenburgh> this bug prevents us from getting snap builds in upstream kubernetes
<kyrofa> Not directly, we've been revamping that part of the codebase, I need to test again with the new changes
<cachio> om26er, you have a dbus interface, see https://snapcraft.io/docs/reference/interfaces
<cachio> om26er, does it work for you?
<kyrofa> tvansteenburgh, it would be helpful if you're able to test with the newest snapcraft, if you're able, v2.34. It's in artful, and -proposed for z and x
<kyrofa> Huh, I don't think I could have written that sentence worse
<kyrofa> Changed gears partway through apparently
<tvansteenburgh> kyrofa: okay thanks
<om26er> cachio: yes that interface does work. My need was only related to getting the machine-id
<om26er> and it seems I can just read /etc/machine-id even in a confined snap.
<mup> PR snapcraft#1541 closed: tests: fix the TEST_STORE environment variable  <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1541>
#snappy 2017-09-14
<mup> PR snapcraft#1547 closed: plugins: extract sitecustomize logic from python <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1547>
<zyga-ubuntu> good morning
<mvo> hey zyga-ubuntu!
<mvo> zyga-ubuntu: do you want me to do the reshuffle for 3814? looks like gustavo reviewed it last night
<zyga-ubuntu> mvo: looking
<zyga-ubuntu> mvo: yeah, go for it, thank you
<mvo> zyga-ubuntu: sure thing, happy to help
<zyga-ubuntu> mvo: thank you, I'm trying to go over https://github.com/snapcore/snapd/pull/3621
<mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<mvo> zyga-ubuntu: ok
<Chipaca> good morning all
<zyga-ubuntu> hey Chipaca
<Chipaca> today's going to be less Chipacaful than usual: i've got physio in about an hour, and then i need to hop on a train to london, and then race back for a school run. I'll be working on the train, but connectivity is very spotty (and nonexistent in the underground portions of it)
<zyga-ubuntu> Chipaca: I made that package with %dir to ensure I understand what's going on
<zyga-ubuntu> Chipaca: ouch, sounds like a hard-to-focus day :(
<Chipaca> zyga-ubuntu: thank you!
<Chipaca> zyga-ubuntu: how did it go?
<zyga-ubuntu> Chipaca: I built it and didn't install it :') I was exhausted and collapsed sleeping :)
<zyga-ubuntu> Chipaca: I can try it and share it now
<Chipaca> heh
<Chipaca> no worries
<zyga-ubuntu> one sec
<Chipaca> zyga-ubuntu: so the question is whether it gets cleaned up on removal
<zyga-ubuntu> right
<zyga-ubuntu> installing
<Chipaca> and if not, how to make it do that
<Chipaca> zyga-ubuntu: opensuse, right?
<zyga-ubuntu> yes
<zyga-ubuntu> Chipaca: ok, removing the package removes the directory
<zyga-ubuntu> it was empty
<Chipaca> zyga-ubuntu: but it won't be
<Chipaca> zyga-ubuntu: what happens if you drop a file in it?
<zyga-ubuntu> Chipaca: trying with some hand-made files
<Chipaca> yeah
<zyga-suse> Chipaca: it stays behind
<zyga-suse> Chipaca: you need a %postun section then
<zyga-suse> https://fedoraproject.org/wiki/Packaging:Scriptlets
<zyga-ubuntu> Chipaca: note that there are two "variants", one on remove and one on purge
<zyga-ubuntu> or actually, one on upgrade and one on uninstall
<zyga-ubuntu> Chipaca: look at the "Syntax" section there, then at the table inside it
<zyga-ubuntu> yes, the values are actually $1 == 0 or $1 == 1
<zyga-ubuntu> because words are long and rpm is old
<Chipaca> we already have a %postun
<Chipaca> in fact it has a preun and a postun and both are the same (?)
<zyga-ubuntu> so it needs to work on the cache dir
<zyga-ubuntu> hmm? that's odd
<Chipaca> zyga-ubuntu: it's 0, 1, or more because it's âthe number of packages of this name which will be left on the system when the action completesâ
<zyga-ubuntu> Chipaca: aha, curious
<Chipaca> zyga-ubuntu: sorry, i misread
<Chipaca> they're very similar but different
<Chipaca> service_del_preun and service_del_postun
<Chipaca> zyga-ubuntu: do you know if service stopping happens in preun or postun?
<zyga-ubuntu> I suspect in preun, but I don't know
<zyga-ubuntu> it's not automatic
<zyga-ubuntu> it must be done by our code explicitly
 * zyga-ubuntu notices he was off wifi all day
<pedronis> this continues to happen relatively often:Â Error: Failed to synchronize cache for repo 'updates' in fedora prepare
<Chipaca> zyga-ubuntu: the service_del_preun/_postun say they stop it (unless asked not to), but don't say _which_ stop it
<zyga-ubu1tu> 10:19 < zyga-ubuntu> I suspect in preun, but I don't know
<zyga-ubu1tu> 10:19 < zyga-ubuntu> it's not automatic
<zyga-ubu1tu> 10:19 < zyga-ubuntu> it must be done by our code explicitly
<zyga-ubu1tu> 10:19  * zyga-ubuntu notices he was off wifi all day
<zyga-ubu1tu> 10:19 < pedronis> this continues to happen relatively often:Â Error: Failed to synchronize cache for repo 'updates' in fedora prepare
<zyga-ubu1tu> 10:20 < zyga-ubuntu> pedronis: aha, thank you
<zyga-ubu1tu> 10:20 < zyga-ubuntu> pedronis: maybe fedora has some auto-mirror system and we choose a bad mirror
<zyga-ubu1tu> 10:20 < zyga-ubuntu> pedronis: I'll try to see what's the case there
<Chipaca> <Chipaca> zyga-ubuntu: the service_del_preun/_postun say they stop it (unless asked not to), but don't say _which_ stop it
<zyga-ubu1tu> which stop it?
 * zyga-ubu1tu looks
<zyga-ubu1tu> Chipaca: sorry, can you rephrase?
<Chipaca> zyga-ubu1tu: in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines
<Chipaca> zyga-ubu1tu: it says that using "these macros" (%service_add_pre/_add_post/_del_preun/_del_postun) the default is to restart on upgrade and stop on removal
<Chipaca> zyga-ubu1tu: it doesn't say which macro actually does it
<zyga-ubu1tu> ah, I see
<zyga-ubu1tu> let me expand them
<zyga-suse> service_add_pre: https://paste.gnome.org/prvbogtlc
<zyga-suse> service_add_post: https://paste.gnome.org/pbub2ldyo
<zyga-suse> service_del_preun: https://paste.gnome.org/p2aogqht0
<zyga-suse> service_del_postun: https://paste.gnome.org/p6nylwgov
<zyga-ubu1tu> Chipaca: I think it's clear from those macros now
<zyga-ubu1tu> Chipaca: service_del_preun is stopping stuff
<zyga-ubu1tu> (disable then optionally stop)
<zyga-ubu1tu> (but optionally is actually on by default
<zyga-ubu1tu> then service_del_postun just removes any sysv migrated service files and reloads systemd
<mup> PR snapd#3914 closed: snap-seccomp: skip mknod syscall on arm64 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3914>
<zyga-ubu1tu> Chipaca: note that this is tumbleweed, leap _may_ use different macros
<zyga-ubu1tu> but I think the spirit is the same
<Chipaca> 's fine. I remove the files in preun if $1=0, but after service_del_preun
<mup> PR snapd#3908 closed: snap-seccomp, osutil: use osutil.AtomicFile in snap-seccomp <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3908>
 * Chipaca made a mess of things, but won a half hour back (?)
<zyga-ubu1tu> error: cannot refresh []: cannot refresh snap-declaration for "classic": Get https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/QbSFwGGAgvG8zHl9nWLY7vEee8lhgFsp?max-format=2: x509: certificate has expired or is not yet valid
<zyga-ubu1tu> this is from a dragonboard that is on core 1166
<Chipaca> zyga-ubu1tu: check system time
<zyga-ubu1tu> Chipaca: it's up-to-date now
<zyga-ubu1tu> core syncs
<zyga-ubu1tu> thanks!
<zyga-ubu1tu> so, now I have a ppc box, an aarch64 box and an armhf box (with HDD) all available in case people want to log in
<Chipaca> zyga-ubu1tu: Pharaoh_Atem: how do you say "/var/cache" in rpmspeak?
<Chipaca> i'm guessing %{_sharedstatedir} is /var/lib
<Chipaca> or is it /usr/lib
<zyga-ubu1tu> Chipaca: one sec
<Chipaca> definitely /var/lib. But what's /var/cache :-)
<zyga-ubu1tu> juse use /var/cache
<zyga-ubu1tu> or %{_localstatedir}/cache but YUCK
<zyga-ubu1tu> when I see a distro that uses /smurfs for /var I'll regret
<zyga-ubu1tu> but I don't regret not using those silly variables
<Chipaca> zyga-ubu1tu: and how does arch handle uninstall?
<zyga-suse> Chipaca: users do it
<zyga-suse> Chipaca: it's all on the wiki typically
<zyga-suse> Chipaca: there are scripts but they just mention "look at the wiki" I think
<zyga-suse> though ...
<zyga-suse> maybe not
<zyga-suse> le me recheck
<zyga-ubu1tu> Chipaca: confirmed, hand made
<Chipaca> zyga-ubu1tu: can you edit the arch wiki so https://wiki.archlinux.org/index.php/Snapd doesn't talk about the ubuntu-core snap?
<zyga-ubu1tu> checking
<zyga-ubu1tu> Chipaca: ok, shall I just rename that to 'core'
<Chipaca> :-)
<zyga-ubu1tu> done
<zyga-ubu1tu> Chipaca: note that anyone can sign up and edit
<Chipaca> noted
<zyga-ubu1tu> though it will ask you a pacman question when you try to make an account :D
<zyga-ubu1tu> so :D
<Chipaca> zyga-ubu1tu: but i'm racing to get a reasonable commit to #3866 in <5 minutes i have left before i need to run
<mup> PR #3866: many: implement fetching sections and package names periodically <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3866>
<zyga-ubu1tu> o/
<Chipaca> there, that should do it
<zyga-ubuntu> sigh
<zyga-ubuntu> so gnome-shell sometimes crashes/logs-me-out when I exit my terminal
<Chipaca> zyga-ubuntu: also, it says to use --devmode to sideload stuff
<Chipaca> zyga-ubuntu: ouch
<popey> ogra_:
<popey> oops, ogra_ did you make any progress on nano pi ssh over usb?
<ogra_> popey, not really
<ogra_> i didnt forget about it :)
<popey> ok. was hoping to take my nano pi to nyc, but not sure how to get it on the wifi there
<ogra_> (there is no kernel driver fix yet )
<ogra_> the only kernel were it wks is the 3.x BSP kernel
<popey> cani re-run the network config thing over serial?
<ogra_> sure
<popey> what's the command?
<ogra_> sudo consoole-conf
<ogra_> -o
<ogra_> alternative you can edit /etc/netplan/00-snapd-config.yaml
<popey> perfecto! thanks
<ogra_> and run "netplan generate" and "netplan apply"
<popey> i love these console ui things. the conjure-up one is so pretty
<ogra_> never tried it :)
<popey> i tried it at ubucon paris after dustin did a quick talk of it
<ogra_> is it of any use in non-cloud ?
<popey> lulz
<popey> Sure, if there's something complex you want to deploy locally
<popey> (I tried kubernetes and killed my laptop - it's a bit of a monster)
<ogra_> heh
<popey> oddly console-conf has no exit option
<ogra_> yeah, you need to run through it completely
<popey> strange, should have a [quit] option imo
<ogra_> (it skips the use creation if a user exists)
<ogra_> well, if invoked from a tty it should
<ogra_> if invked on first boot we want to avoid that
<ogra_> file a feature request at mwhudson's desk ;)
<popey> will do :)
<ogra_> hrm
<ogra_> running gradio on my desktop ends up in a constantly popping up notification
<ogra_> and yuo cant actually stop it ... urgh
<ogra_> (i mean the whole app ... it keeps playing when closing it)
<popey> https://github.com/haecker-felix/gradio/issues
<popey> best place to file issues
<ogra_> well, i see edge is 4 versions ahead
 * ogra_ tries that
<ogra_> k, the notification only shows once with that
<mup> PR snapd#3916 opened: add support for socket activation in apps <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
<mwhudson> ogra_: i was looking at console-conf bugs today, they've been kinda neglected recently :(
<mwhudson> popey: there is an old plan around using console-conf for fixing your network config only
<ogra_> mwhudson, well, it works fine already
<ogra_> properly skips user stuff if a user exists
<ogra_> i use it all the time to reconfigure network stuff on my boards
<ogra_> the prob is really that it has no exit option when invoked manually
<ogra_> so in case there is an actual network issue you can never get back to your tty because it will not exit on its own nor can you stop it manually
<mup> PR snapd#3898 closed: interfaces/network: allow using netcat as client <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3898>
 * ogra_ glares at that PR ... huh ? i ave been using netcat in snaps since 15.04 without probs 
<ogra_> ah, but abeato doesnt ship it in his snap ... k
<abeato> ogra_, the MP is just to avoid having to do that... in the end nc is part of core, and that should be something stable
<ogra_> yeah
<ackk> where should I look for stuff that's failing in https://travis-ci.org/snapcore/snapd/builds/275400722 ?
<zyga-ubuntu>        lookup api.snapcraft.io on [::1]:53: read udp [::1]:39352->[::1]:53: looks like a store issue
<ackk> zyga-ubuntu, where did you see that?
<zyga-ubuntu> ackk: in the log you provided
<zyga-ubuntu> ackk: there are "folds" that can be expanded
<zyga-ubuntu> ackk: a qucik tip is to look for "error preparing" or "error executing"
<ackk> zyga-ubuntu, ah yeah, found it in the raw log
<ackk> zyga-ubuntu, gotcha, thanks
<ackk> zyga-ubuntu, is it possible to kick the travis job again?
<zyga-ubuntu> yes, let me do that for you
<ackk> zyga-ubuntu, thanks
<mup> PR snapd#3917 opened: cmd,dirs: treat manjaro the same as arch <Created by zyga> <https://github.com/snapcore/snapd/pull/3917>
 * zyga-ubuntu thinks about lunch now
<mup> PR snapd#3918 opened: hooks: substitute env vars when executing hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3918>
<niemeyer> Hey folks
<niemeyer> Won't be on the stand up today, apparently.. power outage here for a while
<zyga-ubuntu> niemeyer: ok
<niemeyer> Actually, I can join from the phone.. still enough battery.. hold on
<Dmitrii-Sh> ogra_: I'll try the /snap/bin fix with a wayland session
<ogra_> cool
<diddledan> ikey: you about?
<ikey> ish
<ikey> sup?
<diddledan> :-)
<diddledan> can I pm a sec?
<ikey> sure
<zyga-ubuntu> mvo: gustavo just joined the main one
<mvo> zyga-ubuntu: ok
<ogra_> Dmitrii-Sh, oh, wit ... switching core to edge wont help since the profile.d snippet from the PR actually needs to come from the deb (it needs to live outside of the core snap in your session login setup)
<ogra_> s/wit/wait/
<Dmitrii-Sh> ogra_: hmm, shall I revert back?
<ogra_> but 2.28 will have it ... https://forum.snapcraft.io/t/2-28-release-cycle-started/2026
<Dmitrii-Sh> ogra_: I haven't tried yet, multi-tasking at the moment
<ogra_> Dmitrii-Sh, well, check the black window issue ... thats unrealted to the PATH stuff
<bloodearnest> Heya folks. From within a strictly confined snap, I'd like to find out my system's default dns resolver, but I can't read /etc/resolv.conf. Any ideas?
<ogra_> bloodearnest, add the network interface to your snap
<niemeyer> Sorry.. nevermind.. my phone reboots every time I join the hangout /o\
<ogra_> (i think network is enough, perhaps network-bind though, if network alone doesnt help)
<niemeyer> mvo: Thanks, please move on without me
<bloodearnest> ogra_: thx, snap already has network and network-bind. Should that allow it to read /etc/resolv.conf?
<bloodearnest> ogra_: ah, the app doing the configuration doesn't have those plugs. Will try that, thanks
<ogra_> bloodearnest, hmm, actually ... grepping for resolv in the source only reveals network-control ...
<ogra_> and network-manager ...
<ogra_> but that kind of binds your app to desktop only
<bloodearnest> ogra_: is read access to /etc/resolv.conf a security issue?
<bloodearnest> feels like network plug ought to give read access, at least?
<ogra_> bloodearnest, yeah, it should ... ask jdstrand :)
<zyga-ubuntu> bloodearnest: let me check
<zyga-ubuntu> bloodearnest: nothing allows it explicitly, let me check abstractions
<__chip__> hey all
<__chip__> sorry i dropped :-/
<zyga-ubuntu> bloodearnest: it is provided through the nameservice abstraction that is used by a number of interfaces, including network
<zyga-ubuntu> bloodearnest: but because /etc/ is shared from the host, cna you please tell me if /etc/resolv.conf is a symlink?
<bloodearnest> zyga-ubuntu: it is a symlink
<zyga-ubuntu> bloodearnest: and also tell me which distribution are you on ("snap version" output helps)
<zyga-ubuntu> bloodearnest: right, what's the target?
<bloodearnest> to ../run/resolvconf/resolv.conf
<zyga-ubuntu> ok, let me check one thing
<zyga-ubuntu> bloodearnest: ok
<bloodearnest> https://www.irccloud.com/pastebin/Ru1Xgwu4
<zyga-ubuntu> bloodearnest: it should still work because of the nameservice abstraction
<zyga-ubuntu> aha, you are on 16.04
<zyga-ubuntu> can you show me "dmesg | grep DENIED" please
<bloodearnest> zyga-ubuntu: one possibly important detail: this inside a xenial lxd
 * ogra_ thinks read access to /etc/resolv.conf should be a basic part of the network interface ... its not like that could be harmful or significantly security relevant
<bloodearnest> zyga-ubuntu: audit: type=1400 audit(1505394898.461:17247): apparmor="DENIED" operation="create" namespace="root//lxd-estore_<var-lib-lxd>" profile="snap.snapstore.hook.install" pid=4122 comm="snap-exec" family="inet6" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
<ogra_> thats just some ipv6 noise
<zyga-ubuntu> aha
<zyga-ubuntu> ogra_: it is
<ogra_> what ? security relevant ?
<zyga-ubuntu> bloodearnest: in that case we may have a bug in lxd+snapd
<zyga-ubuntu> ogra_: is is allowed
<ogra_> ah
<ogra_> where ?
<ogra_> grepping for esolv in te interfaces subdir reveals nothing in network.go
<ogra_> *resolv
<ogra_> is it allowed internally somehow ?
<__chip__> hhmmm, the opensuse linode tests block on a prompt?
 * __chip__ goes to school run while pondering this
<sergiusens> ogra_ problem is /etc/resolv.conf is a symlink, so you will need access to what it points to too
<bloodearnest> zyga-ubuntu: I still get permission denied when installing the snap on my host, with both the network and network-bind plugs
<bloodearnest> so lxd probably red herring?
<mvo> zyga-ubuntu, ogra_: could you please check https://github.com/snapcore/core/pull/59 ?
<mup> PR core#59: fix object path used by usr/bin/xdg-open in core <Created by mvo5> <https://github.com/snapcore/core/pull/59>
<mup> PR snapd#3917 closed: cmd,dirs: treat manjaro the same as arch linux <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3917>
<zyga-ubuntu> mvo: re, sorry
<zyga-ubuntu> checking
<matiasb_> sergiusens, o/ hey, just checking... any updates on the metadata thing?
<mup> PR core#59 closed: fix object path used by usr/bin/xdg-open in core <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/59>
<jdstrand> bloodearnest, ogra_: the network interface includes the nameservice apparmor abstraction and it has this rule: /etc/resolv.conf r,
<GNUtoo-lede> Hi, with "Debian GNU/Linux 9.1 (stretch)", after doing apt install snapd I get: "Setup snap "core" (2849) security profiles (cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": fork/exec /usr/lib/snapd/snap-update-ns: no such file or directory)" when doing snap install hello-world
<jdstrand> bloodearnest: is /etc/resolv.conf a symlink to somewhere? do you have security denials in the logs?
<GNUtoo-lede> *snap install hello
<bloodearnest> jdstrand: /etc/resolvf.conf is a symlink to ../run/resolvconf/resolv.conf
<jdstrand> bloodearnest: that is also allowed by said abstraction. do you have a security denial in the logs? 'grep audit /var/log/syslog'
<ogra_> jdstrand, aha, thanks !
<mup> PR snapcraft#1542 closed: tests: add integration tests for build snaps <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1542>
<jdstrand> ogra_: fyi, you might be interested in 'apparmor_parser -p /path/to/profile' to see if a particular rule is in a profile (the -p is a preprocessor and will dump all rules, including those that are added by abstractions, to stdout)
<bloodearnest> jdstrand: just rebuilding the snap in strict mode to try again
<jdstrand> handy for grepping
 * ogra_ notes down 
<ogra_> thanks once more !
<jdstrand> np :)
<mup> PR core-build#20 closed: ubuntu-core-rootfs: deal with (broken) symlink in sync_dirs <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/20>
<Pharaoh_Atem> zyga-ubuntu: %{_var}/cache works too :)
<Pharaoh_Atem> %_var points to %_localstatedir
<Pharaoh_Atem> which, of course, points to /var
<Pharaoh_Atem> likewise, %_usr points to %_prefix, which points to /usr
<bloodearnest> https://www.irccloud.com/pastebin/U6OrCnvV
<bloodearnest> jdstrand: ^^
<bloodearnest> jdstrand: hmm, it's the configure hook that's trying to read /etc/resolv.conf
<bloodearnest> can I give that network plugs?
<bloodearnest> I currently grant them on each app as needed
<bloodearnest> or, from the configure hook, can I invoke an app that has network plug?
<mup> PR core-build#21 opened: Release 0.7.43+ppa23 <Created by mvo5> <https://github.com/snapcore/core-build/pull/21>
<__chip__> Pharaoh_Atem: tell me about %{_var}
<__chip__> Pharaoh_Atem: or better: tell me where i can read about all things %{}
<__chip__> Pharaoh_Atem: ah, i see _var in https://fedoraproject.org/wiki/Packaging:RPMMacros?rd=Packaging/RPMMacros
<mvo> ogra_: so I pushed the initramfs fix to the ppa, I will build a new core now. who should I ping to update the kernel snap so that it includes the updated initramfs? or can I just trigger the pc-kenrel snap build?
<ogra_> mvo, talk to ppisati
<ogra_> just a no-change rebuild
<ogra_> preferably for all of pc-kernel, pi2-kernel and dragonboard-kernel
<mvo> ogra_: yeah, we need the core in edge published first, right?
<ogra_> not for the official kenels
<ogra_> they use the deb directly during build
<mvo> ogra_: using our ppa:snappy-dev/image ?
<ogra_> all kernels that use the snapcraft kernel plugin need the fix in core though
<ogra_> mvo, yep
<mvo> ogra_: great
<ogra_> after new-york split-initrd should be ready, then we wont need that mess anymore
<ogra_> :)
<jdstrand> bloodearnest: it is possibly to specify plugs for configure hooks iirc. let me look that up
<jdstrand> bloodearnest: yeah, https://snapcraft.io/docs/build-snaps/hooks
<davidcalle> jdstrand: bloodearnest you might want this version: https://github.com/CanonicalLtd/snappy-docs/pull/98
<mup> PR CanonicalLtd/snappy-docs#98: Refresh the whole page, add install and remove hooks <Created by caldav> <https://github.com/CanonicalLtd/snappy-docs/pull/98>
<pstolowski> niemeyer, hey, added https://forum.snapcraft.io/t/install-and-remove-hooks/2120 ; can you proof-read?
<mup> PR snapcraft#1548 opened: meta: ensure main keys are ordered in snap.yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1548>
<jdstrand> davidcalle: thanks
<bloodearnest> jdstrand: davidcalle: \o/ great success. Thanks!
<jdstrand> cool
<pstolowski> davidcalle, ^ might also be interesting for you, although I believe you captured all the important aspects already
<davidcalle> pstolowski: looking in a min, evilnick raised a fair point on the PR review: install hook only during initial install or subsequent revisions as well?
 * ogra_ finds the forum text pretty clear " it gets executed ... when the snap is installed for the first time "
<davidcalle> ogra_: ty ogra :)
<pstolowski> davidcalle, only initial. but you had that before: "The install hook is called upon initial install.", did you remove it since?
<davidcalle> pstolowski: was missing from the top summary
<pstolowski> ah
<sergiusens> davidcalle hey, mind updating the deprecations part of the site?
<sergiusens> ogra_ split initrd would be grand!
<sergiusens> my two year wait will be over ;-)
<ogra_> sergiusens, i'm already using it for the splash screens ;) for actual modules and te like there are a few minor snapd changes missing that we'll solve in NY
<davidcalle> sergiusens: deploying in a moment, when ^ gets merged (pstolowski, please give a final ack)
<niemeyer> pstolowski: It's a good base, thanks! I will tune it a bit further once I have a keyboard again
<pstolowski> davidcalle, I suggest tweaking the example yaml.. it's confusing with the extra plugs which will not work anyway
<davidcalle> pstolowski: it's fixed, I think, I switched to upower-observe
<pstolowski> davidcalle, ah, right, missed that, thanks
<pstolowski> davidcalle, lgtm, approved
<pstolowski> davidcalle, + a note about more advanced config got future consideration/updates
<pstolowski> s/got/for/
<oSoMoN> when will the wayland interface be available for consumption?
<ogra_> oSoMoN, https://forum.snapcraft.io/t/the-desktop-interfaces/2042 says 2.28
<davidcalle> pstolowski: noted, thanks
<oSoMoN> ogra_, indeed, I read that post on Monday but my brain is a colanderâ¦
<oSoMoN> thanks!
<ogra_> oSoMoN, just wait til you are my age !
 * ogra_ waves with his cane
<pstolowski> davidcalle, when will your update go live? also, is it going to be https://github.com/snapcore/snapd/wiki/hooks ?
<davidcalle> pstolowski: here https://snapcraft.io/docs/build-snaps/hooks , when Juju let me... Deployment of snapcraft.io is stuck right now because of some juju workers being down
<davidcalle> So, at some point in the next hour :)
<ogra_> can you still call them workers if they dont wok ?
<ogra_> *work
<pstolowski> davidcalle, cool. and I confused the wiki pages again ;)
<pstolowski> ogra_, you don't stop calling someone a worker if he goes on vacation ;)
<ogra_> yeah, but they went on strike !
<ogra_> :)
<pstolowski> ogra_, still a worker! union laws!
<ogra_> haha
<ogra_> hmm
<ogra_> snaps arent really happy if you call pulseaudio -k to have pulse restart
<sergiusens> ogra_ we should propose the removal of `-k` from pulseaudio's cli options ;-)
<ogra_> well, i can also killall o pkill it :)
<mup> PR snapcraft#1549 opened: plugins: extract pip from python plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1549>
<mup> PR snapcraft#1548 closed: meta: ensure main keys are ordered in snap.yaml <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1548>
<mup> PR core-build#22 opened: Simple tests <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<cachio> niemeyer, is it possible to exclude 1 test from the spread execution'
<cachio> ?
<cachio> I mean to run a whole suite but skip 1 test?
<niemeyer> cachio: Only if you mark it as manual at the moment
<cachio> niemeyer, ok, that could work, thanks
<ryebot> Is there a problem with the core snap on s390x? I keep getting this: https://gist.github.com/wwwtyro/a37bb84db21e84723eeb70d3d2c6719e
<ryebot> fwiw, this is under lxd.
<ryebot> snap download works just fine
<ryebot> er - `snap download core`
<mup> PR snapcraft#1550 opened: demos: remove the py?-project demos <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1550>
<Dmitrii-Sh> ogra_: irccloud-desktop runs fine http://paste.ubuntu.com/25535844/ - no black windows (--edge core + apt update as of
<Dmitrii-Sh>  date +%s
<Dmitrii-Sh> 1505418240)
<Dmitrii-Sh> couldn't check brave though:
<Dmitrii-Sh> â  ~ type brave
<Dmitrii-Sh> brave is /snap/bin/brave
<Dmitrii-Sh> â  ~ brave
<Dmitrii-Sh> ln: failed to create symbolic link '/home/dima/snap/brave/5/.config/gtk-2.0/gtkfilechooser.ini': File exists
<Dmitrii-Sh> that's wayland btw
<bschaefer> ogra_, hey, soo if /dev/dri didnt mount on my raspi3 ... i would assume somethings wrong with the vc4 driver?
<bschaefer> though the strange this is this was happening the other day, but downloading the new image fixed it (seems like w/e is upgrading snap core seems to be causing issues?)
<bschaefer> ... hoping i dont need to download the edge image each day to avoid the core upgrading and causing vc4 issues ... though not sure why else dri wouldnt be there :)
<mup> PR snapd#3919 opened: interfaces: updates for default, browser-support, desktop, opengl, upower and stub-resolv.conf <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3919>
<ogra_> bschaefer, very weird, this doesnt happen for me at all, i can have my pi3 running for days (with daily refreshes of edge) and always have mir-kiosk on screen
<bschaefer> happened 2 days ago ... and today but i just downloaded the new iage
<bschaefer> where core doesnt upgrade
<bschaefer> all i see is strange binding errors for vc4 but that seems common
<bschaefer> (looks like it tries to bind until it can bind)
<mup> PR snapcraft#1528 closed: recording: record the machine information collected by uname <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1528>
<bschaefer> ogra_, hmm its happened again
<bschaefer> on the newest edge image
<bschaefer> core            16-2.27.6+git374.6f26821  2935  canonical  core
<bschaefer> and no dri folder
<ogra_> very weird ...
 * ogra_ will monitor thaat the next days ... but i usually have my pi running in the office 24/7 and the mouse cursor is always up there ... 
<ogra_> do you have HDMI constantly plugged in ?
<ogra_> (perhaps the driver falls over when not getting EDID data or some such)
<ogra_> (i'm also sure screenly would have told me if they ever observed something like this, we worked together a lot the last two/three weeks)
<bschaefer> ogra_, yeah its plugged in, ill give you a pastebin of syslog if you feel like digging through it
<ogra_> well, not at this time, but yeah, i'll dig into it tomorrow (my pi is in the office, i'm not near it atm)
<bschaefer> ogra_, http://paste.ubuntu.com/25536380/
<ogra_> dmesg would be good
<bschaefer> alright! Yeah its only 2:37pm here
<bschaefer> soo still pretty early in the day
<bschaefer> ogra_, and dmesg for tomorrow: http://paste.ubuntu.com/25536382/
<ogra_> heh, 11:37pm  here ...
<bschaefer> it seems multiple reboots messes it up
<bschaefer> o geez haha, have a good night!
<ogra_> grepping for vc4 i dont see any unusual messages
<bschaefer> yeah ... the only thing that looked strange was the bind = -517 but seems to happen wehn dri is mapped anyway
<xnox> ryebot, it should work i don't think there is one in the stable channel though.
<xnox> ogra_, is core snap available in the stable channel for s390x yet?
<ryebot> I'm getting different behavior across different machines, so whatever the problem is, I think it's on my end right now.
<mup> Bug #1717375 opened: snap find behaviour? <Snappy:New> <https://launchpad.net/bugs/1717375>
<mup> PR snapcraft#1551 opened: dirs: set plugin, schema, and library dir for snap <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1551>
<mup> PR snapcraft#1550 closed: demos: remove the py?-project demos <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1550>
#snappy 2017-09-15
<mup> Bug #1652262 changed: subiquitycore exception in controller.run <snappy> <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1652262>
<mup> PR snapcraft#1552 opened: tests: replace the mosquitto demo test with a snapd integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1552>
<mvo> ppisati: could you please trigger a new kernel build for edge? I pushed a bugfix for ubuntu-core-initramfs-tools recently
<mvo> ogra_: you showed me a bunch of empty revision dirs under /snap/core some days ago (iirc). could you pastebin that again? I was looking into this this morning but I haven't managed to reproduce it yet (and the code seems to be doing the right thing). so I'm curious to learn more how this is happening
<mvo> zyga-ubuntu: I wonder if we need to look at the issue that we need to make /snap shared again for lxd. iirc there was this issue that the mounts happen before we run snap-confine for the first time to do the shared mount magic
<mvo> zyga-ubuntu: you wanted to look if we can do something with namespace, we may need a brute force approach with an early mount unit
<zyga-ubuntu> mvo: right, I was thinking about it last night; I wanted to mention that it also happens on 14.04 so it's relateively easy and painless to interate on
<zyga-ubuntu> mvo: I haven't had the time to try though, I'm iterating on the feedback from jamie now
<mvo> zyga-ubuntu: ok - my approach would be a mount unit similar to the one we have in 14.04 - but that is very heavy handed and may get tricky as we need to run it after /snap is mounted but before anything under /snap/* is squashfs mounted, so the right before= is tricky
<mvo> zyga-ubuntu: also please check https://github.com/snapcore/core-build/pull/21 and https://github.com/snapcore/core-build/pull/22 if you have a moment, should be painless
<mup> PR core-build#21: Release 0.7.43+ppa23 <Created by mvo5> <https://github.com/snapcore/core-build/pull/21>
<mup> PR core-build#22: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<zyga-ubuntu> mvo: maybe we need After on actual units?
<zyga-ubuntu> (mount units we create)
<zyga-ubuntu> mvo: ok
<mvo> zyga-ubuntu: yeah, that would work I think, we just need to make sure we rewrite existing ones (I don't think we do this currently)
<zyga-ubuntu> mvo: no, we don't
<zyga-ubuntu> mvo: I'd strongly enourage us to try SyncDir thing for that
<davidcalle> sergiusens: hey, so you know, we are still following up on the deployment of the latest dn, I'll ping you when it's resolved
<mup> PR core-build#21 closed: Release 0.7.43+ppa23 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/21>
<zyga-ubuntu> mvo: as it has the "ensure" property of patching up broken state
 * mvo nods
<zyga-ubuntu> mvo: the tests look ok, I'm wondering if you tried using the VM-based tests that would run this in the real initrd
<mvo> zyga-ubuntu: I did, but got stuck seting up the right environment for this
<zyga-ubuntu> mvo: I see, what was the main difficulty?
<mvo> zyga-ubuntu: also travis is broken since the VM based tests got merged, I'm looking at this right now
<zyga-ubuntu> mvo: oh? It passed earlier
<zyga-ubuntu> mvo: (I mean, it did go green before this was merged)
<mvo> zyga-ubuntu: maybe I did not try hard enough, but I need to simulate the /writable and core snap changes so that sync dir can be tested, setting up changes in the core snap in /etc was were I got stuck
<zyga-ubuntu> test init process did not signal boot-ok
<mvo> zyga-ubuntu: please check https://travis-ci.org/snapcore/core-build/builds
<mvo> zyga-ubuntu: maybe coincidence, I just started looking at this
<mvo> zyga-ubuntu: aha, did you retrigger it?
<mvo> zyga-ubuntu: the first actual failure is much later in #41
<mup> PR #41: add X-Ubuntu-Wire-Protocol to the headers <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/41>
<pedronis> core#41
<mup> PR core#41: limit the version string to 32chars (this is what the store allows) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/41>
<zyga-ubuntu> mvo: I re-started older test jobs that got cancelled
<mvo> zyga-ubuntu: and please don't get me wrong, the iqemu tests are nice, just seems to be not nice for my particular test
<zyga-ubuntu> mvo: we'll see when it stated failing (hopefully)
<mvo> zyga-ubuntu: aha, nice
<mvo> core-build#41
<zyga-ubuntu> mvo: no worries, I just wanted to understand what was hard. I agree that it would be easier to do some of those tests with more of the system around (writable disk or SD card)
<mvo> thanks pedronis, looks like mup does not know about core-build
<mvo> zyga-ubuntu: I also looked briefly at the gpt regression bug and how to test that but that looks really tricky to unit test :(
<mvo> zyga-ubuntu: *but* I think we should have a spread test for this, I will ponder a bit how to test it
<zyga-ubuntu> mvo: yes
<zyga-ubuntu> mvo: I think both would not hurt :)
<mvo> +1
<mvo> zyga-ubuntu: silly question, but do you know why the tests did not run on core-build?
<mvo> (or why they were canceled)
<zyga-ubuntu> mvo: no, no idea
<zyga-ubuntu> mvo: I just did a test on my machine, clean tree, VM tests passed
<zyga-ubuntu> mvo: everything does fail with: test init process did not signal boot-ok
<zyga-ubuntu> mvo: let me push a pr that runs tests in verbose mode
<zyga-ubuntu> mvo: hmmmm, why there's no travis here: https://github.com/snapcore/core-build/pull/23 ?
<mup> PR core-build#23: tests: treat --verbose as -v <Created by zyga> <https://github.com/snapcore/core-build/pull/23>
<mup> PR core-build#23 opened: tests: treat --verbose as -v <Created by zyga> <https://github.com/snapcore/core-build/pull/23>
<zyga-ubuntu> ah, it just showed up
<mvo> zyga-ubuntu: interessting
<ppisati> mvo: i guess, every kernel
<zyga-ubuntu> mvo: https://travis-ci.org/snapcore/core-build/builds/275784391?utm_source=github_status&utm_medium=notification ??!
<mvo> zyga-ubuntu: "test init process did not signal boot-ok" - at least it is concistent, ie #27 also failed with the same error
<mvo> zyga-ubuntu: is it supposed to show more output? maybe its just slow? how much time does it have for this signal?
<zyga-ubuntu> mvo: I found the issue
<mvo> ppisati: thank you, please let me know when new edge kernel is available and I will test right away
<zyga-ubuntu> https://travis-ci.org/snapcore/core-build/builds/275784391#L2178
<zyga-ubuntu> mvo: fixing that now
<zyga-ubuntu> mvo: cpio was in the middle of a pipe so the erorr was silent
<ppisati> mvo: ack
<zyga-ubuntu> mvo: I pushed it back to my PR
<zyga-ubuntu> mvo: it passed now
<zyga-ubuntu> mvo: so whatever caused cpio to get yanked from the image we chroot into won't affect us anymore
<zyga-ubuntu> mvo: please merge https://github.com/snapcore/core-build/pull/23 for happiness
<mup> PR core-build#23: tests: treat --verbose as -v <Created by zyga> <https://github.com/snapcore/core-build/pull/23>
<phil_m> @zyga-suse, @zyga-ubuntu, @zyga: great accomplishment with Manjaro and Snappy
<nothal> phil_m: No such command!
<zyga-suse> phil_m: I'm still working on opengl support but snapd proper works ok
<phil_m> ok, so what was the problem?
<phil_m> if some is needed to be changed within the kernel, we can do that also
<zyga-suse> phil_m: so far none, the patch I cherry picked had different sum than the one from the URL, maybe it was corrupt there?
<zyga-suse> phil_m: would you be interested in cherry-picking apparmor support into the manjaro kernel like solus did?
<phil_m> ah ok.
<zyga-suse> phil_m: this would give you apparmor confinement
<phil_m> I've to see about appamor
<zyga-suse> phil_m: the patch against 4.14 should be small now, 4.15 will have everything but I think we missed the window with some patches
<zyga-suse> phil_m: do you have the apparmor userspace tools packaged?
<phil_m> well, we had apparmor in our distro but removed it: https://github.com/manjaro/packages-core/issues/49
<mvo> zyga-suse: ta
<zyga-suse> phil_m: I see I have to add one more patch to cmd.go,
<mup> PR core-build#23 closed: tests: treat --verbose as -v <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/23>
<phil_m> since you have full write access to our community packages git repo you can also add the needed patches directly if you like.
<zyga-suse> phil_m: thank you, should I discuss this with other manjaro developers before proposing PRs?
<phil_m> na, not needed
<zyga-suse> phil_m: thank you, I'll plan what is the best course of action
<phil_m> we are open and since you know better about snapd you can push it directly
<phil_m> however one of our maintainers has to package it.
<zyga-suse> phil_m: please stick around and let's chat periodically about what else might be needed
<phil_m> sure, no problem in that.
<zyga-suse> phil_m: that's great, I'd love to co-maintain the package if that's okay
<phil_m> sure, why not. we have to see how we can do that properly.
<zyga-suse> phil_m: and if the main packager could be here or on the forum (or both) for release coordination, that would be perfect
<phil_m> you can always ping me via email if needed or write in github that a new release needs to be packaged
<zyga-suse> phil_m: thank you! I'll definitely stay in touch
<phil_m> it should be packaged then on the same day with a small delay
<phil_m> since we are not Arch we are more open for new packages if they make sense.
<zyga-suse> yes, we have a release cycle that has a moment when the package is in testing and once we are happy across the spectrum of systems we mark it as stable
<zyga-suse> thank you :-)
<phil_m> we also have some kind of release cylce with each package. we use branches and move them when ready to the next one.
<zyga-suse> where can I read about that?
<pedronis> IÂ noticed we never marked this  https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/1431 as backlog, fixed now
<phil_m> more or less in our forum or wiki
<phil_m> https://wiki.manjaro.org/index.php?title=Repositories_and_Servers
<phil_m> testing gets updated mostly every second day.
<phil_m> unstable daily and stable in weekly basis
<zyga-suse> phil_m: I think this matches snapd release cycle well, we are trying to (still trying though) make a reliable mothly cycle
<phil_m> https://manjaro.github.io/homepage/public/features/background/
<phil_m> this is a simply page explaining how we manage our packages
<pedronis> mvo: let me when you want to chat about what's left for repairs
<mvo> pedronis: I'm finishing a small branch, then I should be ready so ~30min or so (depending a bit on how tests look)
<phil_m> zyga-suse: looking good so far according to your screens ;)
<pedronis> mvo: ok
<zyga-suse> yes :)
<zyga-suse> phil_m: though I need to investigate two things before I call it good
<phil_m> na, no pressure
<phil_m> take all the time you need
<ogra_> mvo, http://paste.ubuntu.com/25539231/
<mvo> ogra_: and all empty except the last ~3 ones, right?
<mup> PR snapd#3920 opened: snap-confine: improve error message if core/u-core cannot be found <Created by mvo5> <https://github.com/snapcore/snapd/pull/3920>
<zyga-ubuntu> mvo: nice, thank you
<mvo> zyga-ubuntu: thanks for the quick review!
<zyga-ubuntu> darn
<ackk> mvo, hi, I'm not really  sure what failed on https://github.com/snapcore/snapd/pull/3916, is it just flakiness in tests setup?
<mup> PR #3916: add support for socket activation in apps <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
<zyga-ubuntu> a bird just landed next to my window and I even have a camera standing by for that occasion but it ... flew away before I got the shot
<mvo> ackk: yeah, the test failure looks not related to your code
<ackk> mvo, can you restart just that build? or it doesn't matter for the review?
<mup> PR snapcraft#1553 opened: lxd: instructions for /etc/sub{u,g}id after failed start <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1553>
<ashwind> Hey, I see that GPIO pins cannot be accessed via a snap. Is this correct? I have a sensehat (https://www.raspberrypi.org/products/sense-hat/) connected a Pi3 via GPIO pins. I would like to obtain readings from those sensors via a python application. If this possible with a python app captured in a snap?
<zyga-ubuntu> ashwind: hey, is your snap using the right interfaces? is it a service running as root or a command running as your user?
<ashwind> I haven't fully implemented to snap yet.
<ashwind> I just saw that gpio pin access is restrcted
<ashwind> https://snapcraft.io/docs/reference/interfaces
<zyga-ubuntu> ashwind: using the right interface you can definitely use GPIOs
<ashwind> oh awesome, please advise
<zyga-ubuntu> ashwind: the way this works is that a given snap can be given rights to use a restricted interface
<zyga-ubuntu> ashwind: implement your snap as you would normally
<ashwind> ok done
<zyga-ubuntu> ashwind: installation instructions for a given device should show how to connect the right GPIO pins correctly
<zyga-ubuntu> ashwind: for specific devices this will be available as a gadget feature (the gadget can pre-connect things correctly)
<zyga-ubuntu> ashwind: auto-connect is not that useful for GPIOs because there are typically plenty of them
<zyga-ubuntu> (and you get access to specific pins, not to all of them in general)
<zyga-ubuntu> and because this differs from device to device and auto-connect logic is not smart enough to know which one is the right one
<ogra_> mvo, yeah
<ogra_> mvo, well, actually *all* empty ...
<mvo> ogra_: hm? even current?
<ogra_> yes
<ogra_> ogra@anubis:~/datengrab/pi3$ sudo ls -l /root/snap/core/current
<ogra_> lrwxrwxrwx 1 root root 4 Sep 13 22:59 /root/snap/core/current -> 2925
<ogra_> ogra@anubis:~/datengrab/pi3$ sudo ls -l /root/snap/core/current/
<ogra_> insgesamt 0
<mvo> ogra_: ok, so there is something else going on, that explains why I can't reproduce it probably
<ogra_> thhis system has been usinng snaps since day one, but there is no ubuntu-core dir theer
<mvo> ogra_: and this is on the running system?
<ogra_> thats my desktop macine
<ogra_> *machine
<mvo> ogra_: ohhhh, these are your data dirs
<ogra_> (so yes)
<mvo> ogra_: sorry, I misunderstood
<ogra_> right
<ogra_> well ... roots data dirs
<pedronis> didn't we have a complicated discussion about removing those
<ogra_> not hamful, just wasting inodes ... but still ugly
<pedronis> they are not easy to find across distros
<pedronis> and root indeed in a special case
<pedronis> IÂ think we look only for /home/* atm
<ogra_> you mean /root isnt root in soome distros ?
<pedronis> no that homedirs are not quite in the same place
<ogra_> (why do we even create them ?)
<ogra_> are they relevant for anything ?
<pedronis> probably they get created when we run the configure hook?
<ashwind> zyga-ubuntu: so i implemented my snap to be of type "app", do i need to change it to "gadget"? I see a pi3-gadget git repo https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml, how does this relate?
<ogra_> i dont think core would ever wite to them
<pedronis> or maybe we are not lazy at all
<pedronis> don't remember
<pedronis> mvo: I'm around if you want to chat btw, let me know
<ogra_> looking at /root/snap core os the only snap with that behaviur
<ogra_> *core is
<mvo> pedronis: yeah, one minute and I'm ready
<pedronis> ogra_: I suspect it's a consquence of running the configure hook
<ogra_> all other packages remove the dirs on uninstall/refresh
<pedronis> atm
<ogra_> might be that this is what creates them ... but the bug seems to be in te emove code
<ogra_> *remove
<pedronis> as I said  the remove code does only /home/*/snap/...
<pedronis> afaik
<pedronis> we discussed improving it
<pedronis> but IÂ think it was postponed
<pedronis> and root ends up like this
<ogra_> yeah, it isnt critical or anything
<mvo> pedronis: I have a look, looks trivial to include /root as a speical case
<mvo> even if not perfect
<ashwind> zyga-ubuntu: hmm let me read up, thanks!
<phil_m> zyga-suse: I'd to go. Keep me updated via email on the snappy progress on Manjaro. If needed I can package it, when done.
<zyga-ubuntu> re
<zyga-ubuntu> ashwind: no, you should keep your snap as "app"
<zyga-ubuntu> sorry i was on the phone
<ogra_> hmm, do we have any dir in /run that a dameon can write to and that i can see as normal user ?
<zyga-ubuntu> ogra_: $XDG_RUNTIME_DIR perhaps but not sure
<ogra_> zyga-ubuntu, well, that seems tio be hidden from the otside world (or being deleted when i exist "snap run --shell"
<ogra_> )
<ogra_> but i found a solution ...
<ogra_> zyga-ubuntu, your initrd tests make everything in core-build explode ...
<ogra_> $ $CHROOT_RUN sh -c 'cd build/initramfs/testing; LC_ALL=C.UTF-8 ./aaa-tests.py --verbose'
<ogra_> warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
<ogra_> test init process did not signal boot-ok
<ackk> mvo, so one thing I'm not totally sure about that PR for socket activation is whether it's better to keep the socket-mode as a string or an integer
<mvo> ogra_, pedronis: fwiw, I am poking a bit at the user data thing for root/ and I think I'm on a good course
<ogra_> yay
<ackk> mvo, declaring it as an int in the snapcraft schema makes it render in the snap as decimal, not octal
<mvo> ackk: yeah, I would prefer a string for this reason, unless there is yaml magic to make it render in the natural 0xxx notation
<ackk> mvo, ok, then I can just revert the last commit (I had initially it as a string)
<mvo> ogra_: I think its even buggy in the forward-data copy case for root :/ anyway, I am looking
 * zyga-ubuntu -> lunch
<mvo> ackk: sounds good, we will also need input from niemeyer on your socket activation PR as it touches the yaml and we need sign off for that :)
<zyga-ubuntu> ogra_: pull master
<zyga-ubuntu> ogra_: it was fixed now
<ackk> mvo, ok
<ogra_> zyga-ubuntu, well, i'm looking at master tests ... but if it is fixed now it is fine
<ogra_> zyga-ubuntu, mvo how did you guys get travis to do anything again ? it hasnt even started tests for a while
<zyga-suse> ogra_: it started instantly for me
<zyga-suse> ogra_: no idea
<zyga-suse> ogra_: maybe it hasn't been merged, there should be a PR open
<zyga-suse> ogra_: please look, I'm trying not to starve today
<ogra_> well it timed uot waiting fr starting the tests fr like 2 months now
<ogra_> unrealated to the tests ... travis never started at all
<ogra_> so someone has done something too make travis actually start again
<zyga-suse> ogra_: I started about a dozen jobs on core-build today
<ogra_> zyga-suse, right i did that nce a week for the last few weeks but travis only timed uot before even starting
<ogra_> something has changed that suddenly allows it to run tests again ... did we pay extra $$$ ?
<zyga-suse> nope, perhaps just smaller load
<ogra_> well, then better watch snapd now ... if it is load related we migth steal cycles from other snapcore trees
<ogra_> :)
<ogra_> (this is not what i understand as reliable CI :P )
<zyga-suse> free, reliable, nice,
<zyga-suse> pick two
<ogra_> haha
<mup> PR snapd#3866 closed: many: implement fetching sections and package names periodically <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3866>
 * Chipaca dances
<Chipaca> also, glad to have been into london yesterday and not today
 * Chipaca dances a bit more
 * zyga-ubuntu hugs Chipaca 
<zyga-ubuntu> barbaric times we live in
 * zyga-ubuntu resumes coding
<ackk> mvo, updated that PR, fwiw
<pedronis> mvo:  added a couple comments, some we already discused to the snap-repair list/show PR
<ogra_> zyga-ubuntu, mvo, can we agree that "release" PRs in core-build simply get merged (i saw you guys did an actual review, i think this is pointless given it is only a changelog entry, the actual changes have been reviewed before anyway)
<ogra_> (and if the changelog is broken the loacla dpkg-buildpackage would error anyway and you couldnt upload)
<ogra_> *local
<ogra_> i.e. https://github.com/snapcore/core-build/pull/21
<mup> PR core-build#21: Release 0.7.43+ppa23 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/21>
<ogra_> (reviews just waste time here IMHO)
<ogra_> indeed only if it is just the changelog bump :)
<zyga-ubuntu> ogra_: well, I think it's good for spotting typos but I agree in general; given that those should be reviewed very quickly I wouldn't change much thoug
<ogra_> well, lets say they are "optional" then :)
<cachio> mvo, hi
<cachio> in rc3 it is failing to uninstall the network-manager
<cachio> for db and pi3
<cachio> I can reproduce it running test tests/regression/lp-1606277 and then any other test
<mvo> cachio: thanks, what is the error output?
<cachio> mvo, https://paste.ubuntu.com/25540183/
<cachio> it works fine for example on pi2
<cachio> but for pi3 and db we get the same error
<ogra_> well, both have wlan
<ogra_> while pi2 doesnt
<ogra_> the log isnt really helpful since it only shows the final timeout after snap remove n-m
<ogra_> did you check what happens when you manually install/configure/remove n-m on such a device ?
<mvo> cachio: hm, I would bet syscall filtering related, could you paste the dmesg output?
<cachio> mvo, give me 5 please
<mvo> cachio: oh, hold on, its dying on rmeove, right?
<cachio> mvo, yes
<mvo> cachio: in this case ogra_ may have a better theory, still the dmesg/syslog output will be helpful
<ogra_> i guess it cant deconfigure the wlan device properly
<mvo> cachio: also, does reverting core fix it? wonder if it might be n-m related but the last stable is ~5 weeks old it seems so that is unlikely
<cachio> mvo, give me 5 please, I am running the tests with -debug
<mvo> cachio: thank you, no rush :)
<mup> PR snapd#3921 opened: interfaces: updates for default, browser-support, desktop, opengl, upower and stub-resolv.conf <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3921>
<jdstrand> mvo: fyi, ^
<jdstrand> mvo: and hi! :)
<mvo> jdstrand: nice, thank you. and good morning!
<cachio> mvo, dmesg https://paste.ubuntu.com/25540261/
<cachio> ogra_, for you too :)
<cachio> this is the syslog when the error happened https://paste.ubuntu.com/25540285/
<ogra_> cachio_, can we get the full syslog without the tail -50 ?
<cachio_> yes
<ogra_> "Failed to initialize control interface '/run/wpa_supplicant'.#012You may have another wpa_supplicant process already running or the file was#012left by an unclean termination of wpa_supplicant"
<mup> PR #12: Bugfix/lp1480248 test reenable <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/12>
<ogra_> that looks suspicious
<ogra_> boo ... mup
<mup> PR snapd#3922 opened: snapstate: deal with snap user data in the /root/ directory <Created by mvo5> <https://github.com/snapcore/snapd/pull/3922>
 * Chipaca reads http://schd.ws/hosted_files/ossna2017/91/Linuxcon%202017%20NERF.pdf and doesn't know if he should show it to ogra_, or hide him from it
<cachio_> ogra_, https://paste.ubuntu.com/25540337/
<mvo> zyga-ubuntu: the error in 3920 is very confusing
<mvo> zyga-ubuntu: no /snap/core/current on core
<Chipaca> sergiusens: http://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/
<ogra_> cachio_, there you go ... the wlan got configured by systemd-networkd already (via some netplan setup i guess) ... i assume that is why n-m gets confused
<Chipaca> sergiusens: could/should snapcraft warn about that?
<mup> PR snapd#3923 opened: asserts,cmd/snap-repair: represent RepairID internally as an int <Created by pedronis> <https://github.com/snapcore/snapd/pull/3923>
<pedronis> mvo: ^
<zyga-ubuntu> mvo: are we hit by a bad build of core?
<mvo> pedronis: nice
<mvo> zyga-ubuntu: not sure, I try to reproduce now
<sergiusens> Chipaca about what?
 * sergiusens doesn't know who anyone is with lacking avatars ;-)
<ackk> it is at all possible to install a lxd local snap? I get permission denied messages when it starts about reading /proc/self/attr/current and running aa-exec
<ackk> (I did connect the lxd-support plug)
<cachio_> ogra_, that could be the reason, do you need any other log'
<cachio_> ''
<cachio_> ?
<ogra_> cachio_, well, not sure what to do here ... did your testing change that it leaves the wlan netplan config in place before installing nm where it didnt do that before or some such ?
<ogra_> nothing should have changed on core or in n-m in that area in ages
<Chipaca> sergiusens: about a list of evil fake/typo packages in pypi
<cachio_> ogra_, no
<Son_Goku> zyga-ubuntu: base-ish snaps for Fedora, openSUSE, and Mageia on demand: https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap/pipelines/11803392 :D
 * zyga-ubuntu hugs Son_Goku 
<zyga-ubuntu> one small step for snap
<Son_Goku> I need to rewrite the tool to use the DNF API instead of the CLI (better control over the solver)
<Son_Goku> but it's a doing it
<sergiusens> Chipaca oh, I think pip and PyPI itself should warn about that!
<Son_Goku> zyga-ubuntu: note that it won't produce bootable core snaps either :(
<ogra_> cachio_, as a hack/workaround you could simply try to remove the file in /run or kill wpa_supplicant before installing n-m or some such
<ogra_> this is clearly not a use case we support (having two config mechanisms manage the same device)
<ogra_> mvo, ^^^ ?
<ogra_> it is either netplan or network-manager ... (netplan has a specific config option for this to hand off management of the device to n-m)
<ogra_> https://wiki.ubuntu.com/Netplan has info about this
<ogra_> you will need to switch the renderer option before installing n-m
<mvo> ogra_: thanks, I was in a meeting. btw, PR with the fix for your /root/snap/ stuff is up. unfortunately it will not cleanup the past but at least it should stop doing so from now on (well, $now==when-it-gets-merged)
<ogra_> mvo, well, it is just cosmetic anyway
<mvo> ogra_: sort of, there is a real bug there too, the userdata of /root does not get copied forward on refresh - so its good that you brought it up
<ogra_> heh, great
<pedronis> mvo: I'm super confused,  in my branch go vet seems to think the RepairID() is still a string in some places but test pass
<cachio_> ogra_, ok, i'll see how to rewrite that test in this case
<cachio_> thanks
<ogra_> cachio_, well, it shouold have failed before, interesting that it did not
<ogra_> also ... the n-m snap should probably be fixed to not steal an already otherwise managed interface
<cachio_> ogra_, perhaps it is a new test
<cachio_> i'll research a bit on that
<ogra_> ah
<zyga-ubuntu> Son_Goku: bootable snaps are further down the line
<zyga-ubuntu> Son_Goku: I would be happy with a working base
<pedronis> mvo: niemeyer: I'm getting this (stalled run/no ouput):  https://travis-ci.org/snapcore/snapd/builds/275875794?utm_source=github_status&utm_medium=notification
<pedronis> there is nothing super interesting in the PR
<pedronis> afaict
<mup> PR snapd#3924 opened: asserts,cmd/snap-repair: introduce a mandatory summary for repairs <Created by pedronis> <https://github.com/snapcore/snapd/pull/3924>
<mvo> pedronis: strange, I saw this in some other PR recently too but it seems to be very rare
<pedronis> mvo: I got it twice in a row
<niemeyer> pedronis: Can't think of any reasonable reason
<niemeyer> pedronis: Ah, now I can
<niemeyer> pedronis: We have 100% utilization right now
<niemeyer> pedronis: On Linode
<niemeyer> Interestingly, a lot of machines are running for ~1h
<niemeyer> Every machine I click, actually
<niemeyer> This is below the halt timeout
<niemeyer> And above what Travis would accept
<niemeyer> Something strange happening with Travis...
<niemeyer> "Ran for 5 hrs 29 min 42 sec"
<niemeyer> I don't think that's true, somehow :)
<ogra_> niemeyer, i have that since weeks for the less frequently changing trees like core-build and core ... it will eventually time out with no results
<ogra_> (the tests dont even start)
<niemeyer> https://usercontent.irccloud-cdn.com/file/wHpSvg9Y/image.png
<ogra_> pedronis, see my discussion with zyga-ubuntu above (around 12:50)
<ogra_> the verdict was:
<ogra_> zyga-suse> free, reliable, nice,
<ogra_> <zyga-suse> pick two
<ogra_> <ogra_> haha
<ogra_> :P
<niemeyer> Definitely something bogus happening there.. look at this screenshot
<niemeyer> It merged two independent runs together
<ogra_> oh
<ogra_> thats definitely more than i get
<ogra_> it doesnt even produce a log
<niemeyer> ogra_: These cases are generally Travis being busy
<ogra_> looks more like a hang with the test itself somehow
<niemeyer> ogra_: Either in general, or with our own project (too much activity, long queues)
<ogra_> yeah
<ogra_> one can usually work around by pulling the tree and PR into a user fork and have the tests run there then
<ogra_> i guess it is because it is tied to the snapcore organization
 * zyga-ubuntu -> coffee
<niemeyer> pedronis: Something else is wrong.. found machines allocated by those stale Travis jobs.. they are there, allocated and sitting idle
<niemeyer> I'm finding evidence that the machine was updating too
<niemeyer> Installing things that spread requested, likely
<niemeyer> Yeah..
<niemeyer> The best theory at the moment is that there was overutilization, machines were taking a while to actually allocate, and that cause them to go over the 10 mins without output of Travis, which meant they were killed while the machines were allocated, which caused more overutilization, and the problem cycles
<niemeyer> In a few minutes we'll over our 2h halt timeout threshold.. let's see what happens
<ogra_> is anyone living close to the github datacenter so he could watch out for an atomic cloud ?
<mup> PR snapd#3925 opened: snap-repair: implement `snap-repair {done,skip,retry}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3925>
<niemeyer> If the theory above is confirmed, I think we should lower the halt timeout
<niemeyer> No, something else must be causing those issues:
<niemeyer> https://usercontent.irccloud-cdn.com/file/n6Bkt5zj/image.png
<niemeyer> It froze mid-way through.. the only thing that might justify that is a bug in spread, or a bug in Travis
<niemeyer> Spread would definitely display a warning if it was taking too long, and it's hard to believe that would happen in all 20 machines anyway, after they're already allocated
<niemeyer> The fact we're getting this issue across multiple runs just now would hint at a problem on the infra side instead of Spread
<mup> PR snapd#3926 opened: snap: implement `snap {repair,repairs}` and pass-through to snap-repair <Created by mvo5> <https://github.com/snapcore/snapd/pull/3926>
<mup> PR snapd#3921 closed: interfaces: updates for default, browser-support, desktop, opengl, upower and stub-resolv.conf for 2.28 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3921>
<mvo> cachio_: any news about the network-manager issue ? mostly curious
<cachio_> mvo, no, ogra has a theory
<cachio_> mvo, seems to be a conflict between network-manager and netplan
<cachio_> mvo, if it is true, we should see what to do with those tests on pi3 and db
<cachio_> because when it fails, it breaks the wifi connection so i loose the conectivity
<mvo> cachio_: aha, do we have a newer netplan in the newer core, could this be the reason? and does the problem go away with an older go?
<cachio_lunch> mvo, not sure
<cachio_lunch> we could try to create an image with the old one
<mvo> hm, looks like the last netplan upload happend a while ago so not super likely
<mvo> or just snap refresh --stable core
<mvo> and run the particular test again
<ogra_> mvo, that test should have never been un like it does atm
<cachio_lunch> mvo, is this network-manager test old? perhaps there was a  change in the snap that is affecting the tests
<ogra_> mvo, if nplan manages the interface n-m can not ... if you want nplan and n-m to work together yu need a special nplan config that sets the renderer to n-m
<ogra_> mvo, see the renderer stuff at https://wiki.ubuntu.com/Netplan
<ogra_> mvo, the point here is though that n-m should ignore ine interface if nplan manages it, but it doesnt ... or that nplan needs a changed config that actually switches too the rigtht renderer ... now dont ask me why it only fails now
<mvo> ogra_: well, that may well be, but why are things failing now and not before?
<ogra_> i have no idea really ... was that est always there ?
<ogra_> *test
<ogra_> or was it just recently added
<mvo> ogra_: the test is old, but the test does not deal with n-m, something in prepare is dealing with it and the question is also why
<ogra_> all i can say is that it is completely wroong as it is now
<mvo> cachio_lunch: the full test output might be nice, i.e. what tests ran before this one
<ogra_> mvo, well, the interface is aleady configured by systemd-networkd at the point the n-m install runs
<ogra_> so what prepare does seems to be to generate a nplan systemd-networkd config
<ogra_> and then blindly install n-m on top
<ogra_> which results in having two tools wrangle over the ownership
<ogra_> and n-m uninstall n-m tries to stop wpa_supplicant but does not own the file in /run so it cant really stooop it and hanfs
<ogra_> *hangs
<mvo> ogra_: hm, that is interessting - is there a way to make this work, i.e. telling nm to not ouch the already-managed interfaces?
<ogra_> not anymore, but nplan can swirtch to the n-m renderer and reconfigure the device
<ogra_> n-m used too have an ignore thing in the past for ifupdown ... but i think thats gone
<mvo> ogra_: hm, that sounds not ideal, I think I will switch the test to not run on the db then
<ogra_> yeah
<ogra_> same for the pi3
<ogra_> the prob is that you need an interface at all to actually install n-m ... so there needs to be an initial configuration
<ogra_> and you can only switch the config once n-m is there ... by then they are already fighting over ownership though
<mvo> ok
<mup> PR snapd#3927 opened: tests: only run tests/regression/nmcli on amd64 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3927>
<ogra_> mvo, is the same test unning on x86 ?
<ogra_> (i wonder why it doesnt fails therer if it gets run there)
 * ogra_ goes and loks up where he can get single chery MX switches to fix his o and r on the kbd
<pedronis> mvo:  did you see my small comments in the snap-repair list/show PRÂ ?
<niemeyer> I don't know what to take from this Travis issue..
<bschaefer> ogra_, so fun work around, manually unpack the overlayfs into system-boot (AlbertA found this)
<niemeyer> I'll take the kid to school and be back to investigate more
<ogra_> bschaefer, overlayfs ? you mean overlays.tgz ?
<bschaefer> yeah
<ogra_> bschaefer, that kind of points to a discrepancy between gadget and kernel snap on your device then
<ogra_> which is weird
<bschaefer> yeah AlbertA hit the same issue as well after a core upgrade
<ogra_> can you paste me the "snap list" output from your pi ?
<bschaefer> ogra_, http://paste.ubuntu.com/25541086/
<AlbertA> ogra_: it seems somehow after core upgrade
<bschaefer> ive not seen kernel or gadget update for this last week
<bschaefer> but core upgrades everyday
<AlbertA> that partition gets corrupted and you get a bunch of fsck record files
<AlbertA> and "overlays" folder disappears
<ogra_> AlbertA, well, the gadget carries the original overlays and the kernel carries the verlays.tgz
<ogra_> URGH!
<ogra_> now thats completely different
<ogra_> so your system-boot partition gets trashed
<bschaefer> yeah i had a bunch of *.rec files
<ogra_> well, i can reproduce it here now but i dont have a trashed partition
<ogra_> ogra@localhost:~$ ls -l /dev/dri
<ogra_> ls: cannot access '/dev/dri': No such file or directory
<bschaefer> ogra_, this started umm
 * bschaefer gets version
<ogra_> ogra@localhost:~$ ls -l /boot/uboot/overlays/|grep -v dtb
<ogra_> total 172
<ogra_> ogra@localhost:~$
<ogra_> i only have dtb files in there ... and als no other trace of fsck issue
<bschaefer> the upgrade to 22913
<bschaefer> 2913*
<bschaefer> a few days ago
<ogra_> well, it is unrelated t cre itself
<ogra_> *core
<bschaefer> o hmm seemed like the only thing changing
<ogra_> a core update updates your bootlader config
<mup> PR snapd#3919 closed: interfaces: updates for default, browser-support, desktop, opengl, upower and stub-resolv.conf <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3919>
<ogra_> the fsck might be related t that update ... but not to any content of core
<AlbertA> ogra_: yeah it doesn't look like the whole partition is trashed...
<ogra_> but the other thing is that i can properly repro it here but without any corruption or fsck issues
<AlbertA> only "overlays" dir for some reason
<ogra_> theer must be some difference between kernel and gadget dtbs if extracting the overlays helps
<bschaefer> i could still boot/ssh into it and move around
<bschaefer> and install snaps etc
<bschaefer> didnt see anything else wrong with the fs
<AlbertA> bschaefer: ogra_: right I can still boot up the device just no VC4 is available (as expected since "overlays" dissapears)
<AlbertA> and this was without installing any snaps...simply flashed a fresh image (the one from yesterday), booted, core upgraded, rebooted. Then after a second reboot
<AlbertA> I see the issue
<ogra_> right ... me too
<ogra_> but without any corruption in my case
<AlbertA> oh interesting
<ogra_> ogra@localhost:~$ tar xf /snap/pi2-kernel/current/dtbs/overlays.tgz
<ogra_> ogra@localhost:~$ diff -ruN /boot/uboot/overlays/vc4-kms-v3d-overlay.dtb overlays/vc4-kms-v3d-overlay.dtb
<ogra_> ogra@localhost:~$ md5sum /boot/uboot/overlays/vc4-kms-v3d-overlay.dtb
<ogra_> 43ee3abf64b77fc3ba837817a7eb51f8  /boot/uboot/overlays/vc4-kms-v3d-overlay.dtb
<ogra_> ogra@localhost:~$ md5sum overlays/vc4-kms-v3d-overlay.dtb
<ogra_> 43ee3abf64b77fc3ba837817a7eb51f8  overlays/vc4-kms-v3d-overlay.dtb
<ogra_> ogra@localhost:~$
<ogra_> and the files are identical ...
<ogra_> yet ...
<phil_m> zyga-suse, zyga-ubuntu: and some progress made within Manjaro?
<ogra_> ogra@localhost:~$ ls -l /dev/dri
<ogra_> ls: cannot access '/dev/dri': No such file or directory
<ogra_> ogra@localhost:~$
<ogra_> oh
<ogra_> one sec
<ogra_> i'm using a special gadget here
<ogra_> ogra@localhost:~$ grep vc4-kms-v3d-overlay.dtb /boot/uboot/config.txt
<ogra_> ogra@localhost:~$
<ogra_> ok
<ogra_> ah, grepping for the wrong thing wont help
<mvo> pedronis: I have not checked in detail, I will either address them later today or monday morning. but thanks for them in any case !
<ogra_> ogra@localhost:~$ grep vc4-kms-v3d /boot/uboot/config.txt
<ogra_> #dtoverlay=vc4-kms-v3d
<ogra_> ogra@localhost:~$
<mvo> ogra_: yes, tests run on amd64 VM, however that does not have wifi
<ogra_> mvo, ah ! yeah, then they wont wrangle over wpa_supplicant files indeed
<ogra_> AlbertA, bschaefer, well, ok, i cant repro it *'yet* but will turn my bard back to use the vc4 driver now and check tomorrown after the next core update
<ogra_> *board
<AlbertA> ogra_: thanks!
<ogra_> i definitely dont get any corruption here though ... and havent in a long time
<ogra_> are your SD cards old ?
<bschaefer> ogra_, nope i just got my this last week
<bschaefer> since my old one was ... bad
<bschaefer> though i have reflashed it ... ~20 times this week
<AlbertA> ogra_: I have a sandisk 32GB maybe about a year old now
<ogra_> (when runnign edge, every core update will write to the same spot on the card, so running edge can wear them out faster)
<ogra_> (that is ... for the bootloader config update ...)
<AlbertA> ogra_: oh interesting idea.. yeah maybe those particular blocks are going bad, seems plausible
<ogra_> AlbertA, but that doesnt explain why bschaefer woould see it ...
<mup> PR snapd#3928 opened: interfaces/system-observe: allow clients to enumerate DBus connection names <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3928>
<noChance> We need to stop China from killing Bitcoin. The more people use BTCs the harder it will be for China to snuff it... https://freebitco.in/?r=7247637 -> get your own free Bitcoins.
<ogra_> also ... my 4GB card that i have currently in use is rather in the 3-5y ealm and running edge daily sincer abut a yea now
<bschaefer> well that would suck, ive 32GB
<ogra_> i have only one out of like 30 cards here that i ave yet managed to wear out
<bschaefer> same as AlbertA but yeah i got these over last weekend
<ogra_> so wear levelling is always my last guess after all ...
<bschaefer> ogra_, i do like that /writable seems to resize now to the fullsize of the SD card now
 * bschaefer use to run out of room a bunch due to the image size
<ogra_> yeah, there was a bug for a short time ... but thats fixed now
<ogra_> the build did pull in the wrong initamfs-tools
<bschaefer> ogra_, so future testing of this sort of thing, checking the dtbs in /boot?
<ogra_> bschaefer, welll, finding the reason why yu both get that breakage ...
<ogra_> the whole overlays stuff will change soon with the ability to upgrrade gadgets
<bschaefer> o nice
<bschaefer> yeah we do happen to have the same SD card IIRC
<ogra_> it isnt ... by chance listed with a red marker in teh table at http://elinux.org/RPi_SD_cards ?
<ogra_> (seems theer are a bunch of snadisk cards that dont play well with the Pi contoller)
<bschaefer> ogra_, all the sandisk 32GB class 10 are green
<ogra_> ok
<bschaefer> yeah i bet my older SD 8 GB was red on this...
<bschaefer> class 2 or 4
<ogra_> well, let me see whyt my system des here with the next update
<ogra_> also ... please bring the cards to NY ... i'lll have a Pi with me to play with
<bschaefer> o yeah good idea
<ogra_> (in case i dont find the cause til then indeed)
<bschaefer> ill bring my rapi3 + sd cards as well
<bschaefer> dont have a monitor though :)
<ogra_> cool
<bschaefer> there should be something about
<ogra_> the hotel room will ;)
<bschaefer> o yeah haha
<ogra_> worst case
<niemeyer> More unrelated Travis issues...
<niemeyer> https://travis-ci.org/snapcore/spread-cron/builds/274621786
<zyga-suse> phil_m: yes and no. I fixed all the other issues but at least inside vmware I cannot get opengl to work. I plan to investigate on real hardware tomorrow.
<zyga-suse> phil_m: and in any case send a PR to github so that the package can be added in the initial version,
<cachio> mvo, https://paste.ubuntu.com/25535960/
<cachio> https://paste.ubuntu.com/25536062/
<cachio> https://paste.ubuntu.com/25540165
<cachio> mvo, it failed in those 3 runs
<cachio> for db and pi3
<mvo> cachio: yeah, i pushed a "fix"
<cachio> pr'
<cachio> ?
<mvo> cachio: yeah
<mvo> cachio: I say "fix" because the test is just skipped
<phil_m> zyga-suse: ok. we will see. thx for the effort so far.
<mvo> cachio: but thats ok, we cannot install n-m and netplan for wifi at the same time currently
<cachio> mvo, good :) it is a way to fix it
<ogra_> well, we can surely work on a real fix and have netplan use the n-m renderer
<ogra_> but thats some wrk
<ogra_> *work
<zyga-suse> mvo: all good?
<mvo> zyga-suse: yes, no?
 * zyga-suse is worried we all work on Fridays so late
<mup> PR snapd#3904 closed: tests: test the real "xdg-open" from the core snap <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3904>
<ogra_> zyga-suse, thats all just the bad weather and stuff :P
<lutostag_> the xdg-open was working for me on gnome until an update today (on artful/gnome-wayland), now it isnt... :/
<zyga-ubuntu> lutostag_: I think this is a known issue that mvo is addressing with another release
<mvo> lutostag_: as a workaround "snap refresh --candidate core" should bring it back
<lutostag_> mvo: no joy on the refresh, https://paste.ubuntu.com/25541837/ but I am just glad someone is looking into it, thanks guys ;)
 * zyga-suse takes a break to do something non-coding
<mvo> lutostag_: hm, that lxd error rings a bell, maybe zyga-ubuntu remembers the details once he is back
<zyga-suse> hmmm, holly molly
<zyga-suse> no idea
<zyga-suse> is that inside lxd?
<niemeyer> Travis is out of the equation, btw.. I can reproduce the problem locally too. It's either a bug in Spread or something in the Linode API..
<niemeyer> I'm guessing Linode needs to be involved somehow, since this has shown up without Spread changing
<mvo> lutostag_: iirc we had this issue with older version of lxd, iirc when snap was run inside lxd. if that is the case, what version of lxd do you use (inside and outside?)
<lutostag_> mvo: outside, then inside https://paste.ubuntu.com/25542158/
<lutostag_> although I was running the snap refresh core --candidate on the outside
<mvo> lutostag_: thanks, I wonder if lxd 2.17 would help
#snappy 2017-09-16
<mup> PR snapd#3929 opened: Correct typo in test <Created by gliptak> <https://github.com/snapcore/snapd/pull/3929>
<mup> PR snapcraft#1544 closed: plugins: add the ruby plugin <enhancement> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1544>
<mup> PR snapd#3923 closed: asserts,cmd/snap-repair: represent RepairID internally as an int <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3923>
<mup> PR snapd#3924 closed: asserts,cmd/snap-repair: introduce a mandatory summary for repairs <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3924>
<phil_m> Hi zyga-ubuntu
<vindows18> hey, can anyone help me with getting connected to wlan on snappy ?
#snappy 2018-09-10
<mborzecki> morning
<mup> PR snapd#5761 closed: store: use stable instance key in store refresh requests <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5761>
<mborzecki> mvo: hi
<mvo> mborzecki: hey, good morning
<mborzecki> mvo: could you take a look at https://github.com/snapcore/snapd/pull/5758 ?
<mup> PR #5758: overlord/snapstate, snap: handle shared snap directories when installing/remove snaps with instance key <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5758>
<mvo> mborzecki: sure, I'm just looking into the 18.10 upgrade hang, I will check this one in parallel
<mborzecki> mvo: thank you
<mborzecki> wrz 10 08:11:10 galeon snapd[9337]: retry.go:52: DEBUG: The retry loop for https://api.snapcraft.io/api/v1/snaps/names?confinement=strict%2Cclassic finished after 1 retries, elapsed time=303.098089ms, status: cannot decode new commands catalog: got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/names?confinement=strict%2Cclassic"
<mborzecki> 403?
<zyga> good morning
<mborzecki> zyga: hey
<zyga> ok, breakfast done, time to get to work
<mvo> zyga: hey
<zyga> hey
<zyga> I didn't do much work over weekend
<zyga> I'm snapshotting now, going to upgrade to cosmic
<zyga> mvo: is this expected?
<zyga> Upgrades to the development release are only
<zyga> available from the latest supported release.
<zyga> I can update manually but I was expecting do-release-upgrade -d to work
<mvo> zyga: yes, this should work. you could try change /etc/update-manager/release-upgrades from "Prompt=lts" to "prompt=normal"
<zyga> mmm, let's try
<zyga> indeed, thanks!
<mvo> zyga: I'm confused, why is mkdirAllChown racy? it is that we create mkdirAllChown(/prefix/foo) and mkdirAllChown(/prefix/bar) with different users?
<zyga> mvo: two concurrently running instances will eventually race with each other to mv a file over
<zyga> (well, a directory)
<mvo> zyga: aha, thats the one
<zyga> mvo: and only one will win
<mvo> zyga: and the other one will get a EEXITS?
<zyga> yes
<zyga> mvo: the version in snap-update-ns is not racy because it chooses to construct the directory in-place and chown it split second later
<zyga> as such it already handles EEXIST
<zyga> as a normal operation
<zyga> it's a trade-off
<zyga> trading temporary visibility of incorrect owner
<zyga> for robustness
<mvo> zyga: ok
<mvo> zyga: thanks, that makes sense now
<zyga> E:Problem executing scripts APT::Update::Post-Invoke-Success 'if
<zyga> /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli;
<zyga> then appstreamcli refresh-cache > /dev/null; fi', E:Sub-process
<zyga> returned an error code
<zyga> mvo: I saw that before but I don't know how I fixed that
<zyga> let me just upgrade manually
<mvo> zyga: the appastream thing is harmless
<mvo> zyga: just ignore it
<zyga> it broke the upgrade
<zyga> as in, do-release-upgrade failed
<zyga> upgrading the old way now
<zyga> that appstream thing is not very robust
<mvo> zyga: ok
<mvo> zyga: I'm surprised that the appstream thing prevented the upgrade
<zyga> apt hook magic
<mvo> zyga: but yeah, not super important, I'm keen to learn what you find
<mup> PR snapd#5787 closed: tests: update the listing expression to support core from different channels <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5787>
<zyga> mvo: upgrade complete
<zyga> no issues
<zyga> do you know if the upgrade was headless/
<zyga> perhaps that's the key ingredient
<pstolowski> heyas
<zyga> hey pawel
<zyga> cosmic has new looks!
<zyga> I was expecting to stay on bionic but ubuntu is like drugs, you just want more and more and more fresh software
<zyga> mvo: do you want me to repeat the test under different conditions?
<mvo> zyga: hm hm, I had no luck reproducing the issue myself earlier too
<mvo> zyga: I think there is soemthing missing no need for you too keep trying
<zyga> OK
<zyga> hmm, it seems gnome-shell in 18.10 no longer logs errors whenever some window activity happens
<Dmitrii-Sh> https://bugs.launchpad.net/snapd/+bug/1791587
<mup> Bug #1791587: [2.34.2] snapd ignores proxy settings <cpe-onsite> <snapd:New> <https://launchpad.net/bugs/1791587>
<mborzecki> zyga: cannot be, wonder if they finally fixed it upstream
<mborzecki> anyways, super annoying
<zyga> mborzecki: I'm much happier now, it was always annoying to watch journal output with gnome-shell spamming everything
<mvo> mborzecki: I left a bunch of comments in the PR, tl;dr its fine but I have quibbles with some of the naming (yay bike-sheed!)
<mvo> mborzecki: hope its still useful
<mborzecki> mvo: thanks, will look in a minute once i'm done with the autotools madness
<mvo> mborzecki: no rush, I'm back at apt upgrade madness
<mup> PR snapd#5800 opened: cmd: use systemdsystemgeneratorsdir, cleanup automake complaints, tweaks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5800>
<mvo> mborzecki: nice one
<mborzecki> mvo: duh, i need coffee now, i'm still shaking :P
 * mvo hugs mborzecki 
<zyga> mborzecki: "Not it's at the right place to begin with" ?
<zyga> s/Not/Now/ ?
<mup> PR core18#70 opened: hooks: add rfkill <Created by mvo5> <https://github.com/snapcore/core18/pull/70>
<mborzecki> heh, right :)
<mborzecki> zyga: fixed the description
<zyga> mborzecki: very nice
<Chipaca> zyga: o/
<zyga> hey
<Chipaca> zyga: one question i had left over from friday was: do we really need to loadmountinfo of /proc/self/mountinfo so many times (in quick succession)? if these are all part of the same operation, can't we load it once and pass it around?
<zyga> Chipaca: yeah, we could; it's somewhat "tricky" because interface backends have no state across invocations
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5801 <- last of the removal PRs
<mup> PR snapd#5801 opened: cmd/snap-update-ns: remove the unused Secure type <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5801>
<mup> PR #5801: cmd/snap-update-ns: remove the unused Secure type <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5801>
<zyga> mborzecki: after that it's just the additions; hopefully with a way that lets us decide if the names are ok and if the way they are passed around is ok
<Chipaca> zyga: these 2k+ calls a re all from separate interface backend invocations?
<diddledan> is forum.snapcraft.com failing for anyone else right now?
<zyga> yes
<diddledan> err .io
<zyga> Chipaca: if we had a "mount manager" that could keep a representative state and share it
<zyga> Chipaca: (e.g. use inotify)
<mvo> diddledan: yes for me as well
<zyga> Chipaca: we could just call it once per mount op
<mborzecki> diddledan: same here
<zyga> Chipaca: there's a not well known fact that you can poll on /proc/self/mountinfo
<zyga> and get events when it changes :)
<mborzecki> diddledan: and it's back
<Chipaca> diddledan: so _that_'s why the morning was nice and quiet
<diddledan> :-)
<mvo> hrm, its back and it ate the reply I was typing
<mvo> *grumpf*
<diddledan> nomnomnom
<Chipaca> mvo: i thought those were in cookies
<Chipaca> or, well, local state in any case
<Chipaca> boo
<Chipaca> zyga: hmmm
<mvo> Chipaca: maybe I had a bad cookie
<Chipaca> or not enough milk
<Chipaca> Â¯\_(ã)_/Â¯ computers are hard, let's go do something easy like rocket surgery
<zyga> Chipaca: do you think we can sit down and work on this at the sprint?
<Chipaca> zyga: yes
<Chipaca> zyga: if it's all interfaces, then we probably can do the cache+dnotify from interface manager
<zyga> yes, I think so
<Chipaca> zyga: before stopping myself and going off on friday i had it down to where the biggest single memory chunk was bolt
<Chipaca> zyga: this was via a hackish have-a-global-mountinfo that expired after a second, and changing asserts/findwildcard to not load the whole directory every  time
<zyga> Chipaca: so after mountinfo bolt is the biggest heavyweight?
<diddledan> did someone say rocket surgery? https://youtu.be/fg58hVEY5Og?t=36
<Chipaca> zyga: on my machine, the asserts db is the next one, after that it's  bolt
<Chipaca> diddledan: â¦ no, nobody. You must be having bad dreams again.
<Chipaca> zyga: bah. There's a json.Unmarshal of *json.RawMessage in there
<Chipaca> but I ignored that because I'd have to dig into upgrading our go
<Chipaca> and i'd rather not dream
<Chipaca> :-)
<pedronis> Chipaca: I probably missed context, what are you looking into? memory usage?
<Chipaca> pedronis: on friday i idlye looked at a memory profile of my snapd after it started up and did 5 things (refresh, find, list, changes, info)
<Chipaca> pedronis: and two things stood out: osutil's strings.Split, and asserts's directory reading
<Chipaca> pedronis: osutil's  is just because it's called eleventy billion times in quick succession and re-reads the whole thing every time
<pedronis> Chipaca: yea,  I would expect snap-revision directory to be growing over time, we will need to do something about it
<Chipaca> pedronis: that one's an easy and clean refactor actually, i could split it out
<Chipaca> at least if i understood the code correctly -- the tests were green :-)
<diddledan> ship it
<Chipaca> diddledan: no because then mvo gets nasty emails to his personal inbox
<diddledan> test green means everything is perfect. right?
<Chipaca> diddledan: they _should_ though :-)
<diddledan> :-p
<pedronis> Chipaca: will need to gc snap-revisions as well at some point, but that can wait a bit longer
<Chipaca> er
<Chipaca> pedronis: directory lookup will become an issue before space, i fear
<mborzecki> any idea what issue may this guy have with the CLA? https://github.com/snapcore/snapd/pull/5799
<mup> PR #5799: Install snap-failure binary on Fedora <Created by eyusupov> <https://github.com/snapcore/snapd/pull/5799>
<pedronis> Chipaca: ?
<pedronis> isn't what I said
<pedronis> that gc can wait longer
<Chipaca> pedronis: i meant kernel performance of finding things in a yuge directory
<Chipaca> pedronis: this is separate from go's memory usage from reading a whole big directory into memory
<pedronis> Chipaca: we scan them no
<pedronis> anyway
<pedronis> Chipaca: are you saying we need to sue a real index?
<pedronis> sooner or later
<Chipaca> pedronis: I'll push the refactor in a bit
<pedronis> Chipaca: we already too many PRs :)
<Chipaca> pedronis: I'm saying if we delay gc a lot more, we should think of moving to a two-level directory layout
<mvo> so the hang on 18.10 is caused by incomplete seeding. the gtk-common-themes is seeded after the snaps that use it
 * mvo scratches head
<pedronis> mvo: yes,  they dediced that we should fix it in snapd
<pedronis> they only fixed 18.04
<mvo> pedronis: oh, looks like I did not get the memo
<pedronis> but are waiting for our fix for 18.10
<mvo> ok
<pedronis> it's in the bug
<pedronis> mvo: we discussed a  fix IÂ think
<pedronis> it's not a matter of sorting, we need to add some logic to autoconnect in ifacestate
<mvo> pedronis: well, I think its a terrible choice to let users suffer when there is a trivial workaround availalbe but *shrug*. let me dive into the issue
<mvo> pedronis: yeah
<Chipaca> mvo: quick workaround: on cosmic, ignore the seed
<pedronis> Chipaca: ?
<Chipaca> pedronis: a joke
<pedronis> heh
<Chipaca> pedronis: calling out the cavalier attitude towards breaking users
<mvo> Chipaca: I was actually thinking to have a preinst to reoder things, I
<mvo> Chipaca: anyway, looking into the real fix now
<pedronis> Chipaca: is your comment  about lookup still relevant with ext4 dir_index, I see here that firefox cache is flat and ext4 is uses a hash directory for it
<pedronis> Chipaca: yea, same for /var/lib/snapd/assertions/asserts-v0/snap-revision/
<Chipaca> pedronis: I think the hashe dir made it fine until ~100k entries, but I'd have to look that up
<pedronis> Chipaca: bit unclear if space will become a problem before or after then, it's not only the size of directory, there is the size of the assertions too
<pedronis> though snap-revisions are small
<pedronis> also each asssertion is a dir
<zyga> mvo: apt hooks test unhappy?
<zyga> the test runs forever (49 minutes and times out)
<zyga> https://api.travis-ci.org/v3/job/426565106/log.txt
<pedronis> mvo: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1772844/comments/21 is the comment
<mup> Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <iso-testing> <package-from-proposed> <third-party-packages> <verification-needed> <verification-needed-bionic> <OEM Priority Project:Fix Released by swem> <snapd:New> <livecd-rootfs (Ubuntu):Won't Fix>
<mup> <ubuntu-meta (Ubuntu):Fix Released> <livecd-rootfs (Ubuntu Bionic):Fix Released> <ubuntu-meta (Ubuntu Bionic):Fix Released> <https://launchpad.net/bugs/1772844>
<mvo> zyga: not sure
<pedronis> Chipaca: anyway playing with debug2fs wasn't actually my morning plan
<mvo> pedronis: thanks, I remembered and found it, I still disagree but it seems like the intended effect was reached
<Chipaca> pedronis: sary
<pedronis> Chipaca: anyway 100000 dirs with 4k blocks are 400 mb ?
<Chipaca> mvo: does this mean #1776622 is a dupe of #1772844 ?
<mup> Bug #1776622: snapd on cosmic never finishes installing/updating. Can't install any other updates. <amd64> <apport-bug> <cosmic> <regression> <snapd:Confirmed> <snapd (Ubuntu):In Progress> <systemd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1776622>
<mup> Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <iso-testing> <package-from-proposed> <third-party-packages> <verification-needed> <verification-needed-bionic> <OEM Priority Project:Fix Released by swem> <snapd:New> <livecd-rootfs (Ubuntu):Won't Fix>
<mup> <ubuntu-meta (Ubuntu):Fix Released> <livecd-rootfs (Ubuntu Bionic):Fix Released> <ubuntu-meta (Ubuntu Bionic):Fix Released> <https://launchpad.net/bugs/1772844>
<pedronis> Chipaca: too much stuff is too much stuff (tm)
<mvo> Chipaca: yes
<mvo> Chipaca: well sort of but if the ordering in the seed or our code would be fixed then the bug would be fixed
<mvo> Chipaca: I mean the bug that users see the hang on an upgrade
<pedronis> mvo: we order bases now, but we don't want to order  content providers (also because that's too specific for seed code)
<mvo> pedronis: yeah, I'm building a unit test right now
<mvo> pedronis: once that is done iirc you suggested to fix doAutoConnect in ifstate:handlers.go
<mvo> pedronis: so that it would check the wait chain
<pedronis> yes
<pedronis> correct
<pedronis> but tests is the first order of things
<mvo> pedronis: and if there is a install of the content provider in the wait chain just do nothing (indead of retrying)
<pedronis> yes
<mborzecki> wtf, on arch .dirstamp is created in the $(builddir)/snap-mgmt, on ubuntu it's in $(srcdir)/snap-mgmt and generating snap-mgmt obviously fails
<mvo> pedronis: great, yeah, working on a test now that models the current cosmmic problem closely and once that is done I look at the other bits
<mvo> (s/other bits/fix/
<mvo> )
<pedronis> mvo: then the other related  issue (but not related to the bug) would be to teach image to at least warn if there are missing content providers
<pedronis> like it does for bases now
 * mvo nods
<Chipaca> mvo: #5797 green after adding comment as requested; can i merge?
<mup> PR #5797: osutil, o/snapshotstate, o/sss/backend: quick fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/5797>
<mvo> Chipaca: nice! out of curiosity, why does runuser fail as root? pardon my ignorance on this
<Chipaca> mvo: because the user doesn't exist
<Chipaca> it's faked
<mvo> Chipaca: ok
<Chipaca> mvo: if you're not root, runuser doesn't come into the picture so it's not an issue
<mvo> aha, now I get it
<Chipaca> mvo: the test could be changed to fake runuser
<mup> PR snapd#5797 closed: osutil, o/snapshotstate, o/sss/backend: quick fixes <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5797>
<Chipaca> mvo: but it's diminishing returns land
<mvo> Chipaca: no worries, just wanted to understand it better, thats fine
<pedronis> Chipaca: do we run  our unit tests as root in spread?  or do we use a test user there
<pedronis> spread tests default to root
<Chipaca> pedronis: the unit tests are run as the test user afaik
<Chipaca> pedronis: yep
<Chipaca> pedronis: su -l -c "[...] ./run-checks --unit" test
<zyga> mborzecki: the meat
<pedronis> Chipaca: good
<Chipaca> pedronis: the gccgo tests are run differently, but still as test user: su - -c "cd $GOHOME/src/github.com/snapcore/snapd && dpkg-buildpackage -tc -Zgzip" test
<mvo> we run the tests as root during package build
<Chipaca> mvo: is that actual root, or fake root? (both would confuse runuser)
<mvo> fakeroot
<mvo> well
<mvo> usually
<mvo> but iirc in pbuilder it will be real root
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5802
<mup> PR #5802: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/5802>
<zyga> mborzecki: I staged it so that we can review the algorithm without discussing how the assumptions/restrictions are passed around
<mup> PR snapd#5802 opened: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/5802>
<zyga> mborzecki: so that we can separately make that decision in the next branch, either as a new argument or as a helper that holds the state and has MkDir... methods
<zyga> mborzecki: but all of the essential new bits are here now
<zyga> mborzecki: have a look please and let me know, after this I will have the RFC branch that just passes Restrictions as an optional argument (as in the code you read last week)
<zyga> mborzecki: and keeps tracks of Assumptions in main and in a few places below
<mborzecki> ok
<zyga> mborzecki: I made unit tests 100% cover the new module
<zyga> mborzecki: and moved a pair of helpers there (and made them private since they only exist to fix trespassing issues)
<zyga> mborzecki: one more thing to ask is if we should move this to osutils now
<zyga> mborzecki: or not
<mborzecki> zyga: iirc there was some concern if we move security sensitive code to osutils, changes tehre may go under the radar or sth
<zyga> mborzecki: yeah but as I said on Friday during the call, I think we're past that and we just need to be mindful about it; we use mount code from osutil already because keeping two copies was less useful
<mborzecki> zyga: aha, in that case i'm all for it
<zyga> mborzecki: thanks, I'd like Chipaca to weigh in as well (and mvo)
<mup> PR snapd#5801 closed: cmd/snap-update-ns: remove the unused Secure type <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5801>
<thresh> seems like the automated review failed again for VLC, "
<thresh> Task a7261f59-ffc0-4a32-b732-3e9d16f8457b failed.
<zyga> brb, break
 * zyga never does breaks 
<zyga> mborzecki: https://github.com/zyga/snapd/commit/7ab0f9f3344e2306779695aba0c355c767d8b0ee
<zyga> that's the final cherry on top
<zyga> mvo: ^ CC that's what I mentioned
<zyga> mborzecki: now the question is, is that sensible or is there an easier way to pass the required state around
<zyga> actually https://github.com/zyga/snapd/commit/75f47d017634159b6415246901a088e308c54cc2 is the better link
<zyga> anyway
<zyga> break for real now :)
<zyga> coffee and dog
<zyga> ttyl
<mup> PR snapd#5803 opened: ifacestate: fix hang when retrying content providers <Created by mvo5> <https://github.com/snapcore/snapd/pull/5803>
<pstolowski> mvo: ^ nice, thanks for that
<mvo> pstolowski: thanks, my pleasure
<pedronis> mvo: thank you, couple initial comments
<mvo> pedronis: aha, good one, will address right after lunch
<mvo> pedronis: thank you!
<mup> PR snapd#5804 opened: ifacestate: fix hang when retrying content providers (2.35) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5804>
<mborzecki> off to pick up the kids
<Son_Goku> zyga: need karma: https://bodhi.fedoraproject.org/updates/snapd-2.35-1.fc29
<zyga> Son_Goku: I'll test on my box today
<zyga> thanks!
<mup> PR snapd#5800 closed: cmd: use systemdsystemgeneratorsdir, cleanup automake complaints, tweaks <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5800>
<Son_Goku> zyga, mborzecki, also one of you guys should package the new deps added to snapd
<Son_Goku> for Fedora
<Saviq> is there a way to order services across snaps? like start my service after another snap's service?
<zyga> mborzecki: I'll incorporate your review of 5760 into the last branch and close it, ok?
<zyga> Saviq: no, there is no such feature
<mup> PR snapcraft#2252 closed: build providers: shell in provider if debug is used <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2252>
<mup> PR snapd#5760 closed: cmd/snap-update-ns: don't trespass on host filesystem in /etc and other places <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5760>
<mup> PR snapd#5788 closed: tests: add publisher regex to fix the snap-info test pass on sru <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5788>
<mup> PR snapd#5514 closed: daemon, overlord/state: warnings pipeline <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5514>
<mborzecki> re
<mborzecki> Son_Goku: which new deps? juju/ratelimit?
<Son_Goku> mborzecki, yes
<mborzecki> Son_Goku: iirc it's already packaged
<Son_Goku> in Fedora?
<Son_Goku> well, then
<Son_Goku> apparently it is
<mborzecki> Son_Goku: https://src.fedoraproject.org/rpms/golang-github-juju-ratelimit
 * Son_Goku wonders what other canonical project is in Fedora...
<zyga> mborzecki: oh, nice, it's already packaged!
<Chipaca> Son_Goku: simple-scan?
<Son_Goku> Chipaca, is that written in go?
<Chipaca> Son_Goku: no
<mborzecki> lxd?
<Son_Goku> iirc, it's in glibified C
<Son_Goku> mborzecki, not in fedora yet, iirc
<Chipaca> Son_Goku: you didn't ask about go :-D
<Son_Goku> Chipaca, I figured that was implied :P
<Chipaca> Son_Goku: to a nitpicker like me? heck no
<Chipaca> Son_Goku: I'd say jhbuild but I think that predates canonical by a couple of years
<cjwatson> well I mean there are going to be a bunch of things whose upstreams happen to be Canonical employees but wearing different hats
<cjwatson> I'd have put jhbuild in that category
<Chipaca> cjwatson: :-) yes
<Chipaca> cjwatson: I was just pulling Son_Goku's leg
<Chipaca> also, I went to the wiki only to found it gone :-(
<Chipaca> we used to have a wiki page of all our free software contributions and can't find it now
<Chipaca> anyhoo
<Son_Goku> Chipaca, that's... depressing
<Chipaca> Son_Goku: the wiki? yes
<Chipaca> Son_Goku: too big, not very good search
<Son_Goku> anyway, the fedora package review gives me no clues,
<Son_Goku> whatever it was may not be in the distro anymore
<Son_Goku> the reverse dep query brings nothing
<Chipaca> Son_Goku: about what?
<cjwatson> Chipaca: you might be thinking of the one on the internal wiki - https://wiki.canonical.com/UbuntuEngineering/UpstreamContributions
<Son_Goku> what led to golang-github-juju-ratelimit being in Fedora
<Son_Goku> the only projects I know of that use juju libraries are lxd and juju itself
<cjwatson> it's the sort of thing that is just about manageable when you're 50 people and completely unmanageable when you're 500 or whatever
<Son_Goku> (and obviously now snapd)
<Chipaca> cjwatson: I thought there was a more project-level one hanging off of https://wiki.canonical.com/OpenSource (but my memory is only slightly worse than the wiki's search)
<cjwatson> maybe, not sure
<Chipaca> Son_Goku: there's a what-uses-this-go-lib thing online
<Chipaca> where was it
<Son_Goku> cjwatson, Red Hat recently changed their list to a GitHub thing, that Red Hatters can send PRs for: https://redhatofficial.github.io/#!/main
<Chipaca> Son_Goku: https://godoc.org/github.com/juju/ratelimit?importers
<Son_Goku> it's nowhere near complete, but it's a start
<Son_Goku> Chipaca, so k8s requires it
<Son_Goku> and thus openshift, too
<Chipaca> Son_Goku: openshift is still a thing?
<Son_Goku> yes
<Son_Goku> the upstream project is OpenShift Origin / OKD
<Son_Goku> https://www.okd.io/
<Chipaca> I've got an openshift pint glass and was thinking how funny it was that it'd survived longer than the thing it was promoting
<Chipaca> guess I was wrong, for now :-)
<Son_Goku> OpenShift 3 rebased on top of k8s
<Son_Goku> as a consequence, OpenShift devs are now contributing to k8s
<Chipaca> Son_Goku: the glass 404s now though; http://openshift.com/beershift is no longer a thing
<Son_Goku> yeah, that's gone now
<Dmitrii-Sh> mvo: seems like the proxy stuff is working with the core snap from the edge channel
<mvo> Dmitrii-Sh: cool
<mvo> Dmitrii-Sh: this will be in beta soon
<mvo> Dmitrii-Sh: and ~4-5 weeks until it hits stable
<Dmitrii-Sh> mvo: thanks for the info
<Dmitrii-Sh> mvo: quick question about the overall design: I can see that /etc/environment is not affected (which is good). Neither do http_proxy/https_proxy/no-proxy of snaps themselves (also good in my view). Am I right to assume that core snap settings will only affect the snapd behavior and not apps themselves?
<mvo> Dmitrii-Sh: sorry, at least that is the current design
<Dmitrii-Sh> i.e. we'd rather configure proxy settings in application-specific ways because they may have multiple network destinations (Internet and local DC network)
<Dmitrii-Sh> mvo: what I mean is that the current design is good :^)
<mvo> Dmitrii-Sh: excellent :)
<mvo> Dmitrii-Sh: (in a meeting right now so a bit slow maybe when reading/replying)
<Dmitrii-Sh> mvo: np, thanks for the quick response
<dot-tobias> Can somebody give me a hint why my install hook is failing to find bundled binaries (`/usr/bin/env ruby`: no such file or directory), but when I run the exact same script as an app command after installation, everything works fine? I know that hooks run as root, but they should have access to the snap's binaries nonetheless?
<Dmitrii-Sh> dot-tobias: if you are talking about ruby from stage-packages this is similar to what we had to do with staged python2 https://github.com/lolwww/fcbtest/blob/master/snapcraft.yaml#L16 PATH: $SNAP/bin:$SNAP/usr/bin:$PATH
<sergiusens> dot-tobias: snapd expects all binaries to be called to live inside the snap
<sergiusens> for hooks and apps
<sergiusens> the difference for apps, is that we write a wrapper around those that satisfies snapd's requirement
<sergiusens> hooks do not get wrappers if they are just created by adding them to "snap/hooks" but iirc do get them if driven through a part installation
<dot-tobias> It's a ruby bundled by the ruby plugin, so I think it should be in the snap, but I'll investigate and test Dmitrii-Sh 's PATH extension example. Thanks!
<pstolowski> mvo: do you remember that occasional unit test failure related to default providers, where the number of tasks is off by one?
<zyga> abeato: hey, just FYI, I'm taking over https://github.com/snapcore/snapd/pull/5469 so that it can land
<mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
<mvo> pstolowski: I just noticed it in one of the ppa builds
<mvo> pstolowski: do you have a theory about it?
<Dmitrii-Sh> Wimpress: around?
<pstolowski> mvo: no, i just hit it on travis and was going to ask the same ;). if no one is looking at it, i'll nvestigate
<mvo> pstolowski: noone is looking at this yet afaik
<mup> PR snapcraft#2253 closed: build-providers: add support for --shell-after  <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2253>
<pstolowski> mvo: good, will see if i can find anytthing
<abeato> zyga, ah, saw that, thanks!
<pstolowski> niemeyer: the PR we talked about that needs your re-review is https://github.com/snapcore/snapd/pull/5632
<mup> PR #5632: overlord: integrate device enumeration with udev monitor <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5632>
<niemeyer> pstolowski: Ack, thanks
<dot-tobias> sergiusens / Dmitrii-Sh : Adding $SNAP/bin to $PATH worked to have /usr/bin/env ruby find the bundled ruby binary. Thank you!
 * zyga returns from lunch 
<mup> PR snapd#5805 opened: cmd/snap-update-ns: enforce trespassing checks <Created by zyga> <https://github.com/snapcore/snapd/pull/5805>
<Odd_Bloke> mvo: I _suspect_ the latest snapd in cosmic has broken PATH generation for systemd units: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1791691
<mup> Bug #1791691: PATH broken in systemd units <cloud-images:Confirmed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1791691>
<Odd_Bloke> Could you take a look?
<T_X> I'm currently trying to start an application installed via snap within an unprivileged LX container. The host is running Debian Stretch, now with a 4.17 kernel from Debian backports
<T_X> the error I'm still having is the following though:
<T_X> Sep 10 14:13:54 rocketchat2 snapd[150]: AppArmor status: apparmor is enabled but some features are missing: dbus, network
<T_X> Sep 10 14:13:54 rocketchat2 snapd[150]: error: cannot start snapd: cannot mount squashfs image using "fuse.squashfuse": mount: /tmp/selftest-mountpoint-278537339: permission denied.
<zyga> T_X that is just a comment, it should be harmless in practice
<zyga> T_X: the part about fuse.squashfuse is the real issue
<T_X> hm, okay. I do get the following "DENIED" messages in dmesg of the host though:
<zyga> but having said that, I _don't_ know if this will work for you; mvo  ^ is that part of the unsupported scenarios?
<T_X> [   70.019332] audit: type=1400 audit(1536588822.918:39): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-rocketchat2_</var/snap/lxd/common/lxd>" name="/sys/fs/cgroup/unified/" pid=2048 comm="systemd" fstype="cgroup2" srcname="cgroup" flags="rw, nosuid, nodev, noexec"
<T_X> [   70.019405] audit: type=1400 audit(1536588822.918:40): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-rocketchat2_</var/snap/lxd/common/lxd>" name="/sys/fs/cgroup/unified/" pid=2048 comm="systemd" fstype="cgroup2" srcname="cgroup" flags="rw, nosuid, nodev, noexec"
<T_X> [   74.560221] audit: type=1400 audit(1536588827.462:42): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-rocketchat2_</var/snap/lxd/common/lxd>" name="/run/systemd/unit-root/run/" pid=2247 comm="(networkd)" flags="ro, nosuid, nodev, remount, bind"
<T_X> [   78.724518] audit: type=1400 audit(1536588831.626:49): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-seafile_</var/snap/lxd/common/lxd>" name="/home/" pid=2393 comm="(networkd)" flags="ro, nosuid, nodev, remount, bind"
<zyga> T_X: are you using v2 cgroups?
<zyga> or is that a part of LXD somehow?
<T_X> zyga: not sure, would I need to enable that explicitly?
<zyga> not sure,
<T_X> cgroups v2 came with one of the more recent kernels, rights
<T_X> *right?
<zyga> v2 is not supported widely AFAIK (not in snapd for sure)
<T_X> I was under the impression that snapd within an unprivileged container should in theory be possible: https://blog.ubuntu.com/2016/02/16/running-snaps-in-lxd-containers
<Chipaca> T_X: it is
<zyga> T_X: I'm not an LXD expert
<Chipaca> T_X: but, there a _lot_ of variables :-)
<T_X> I'm wondering whether he was using a kernel provided by Ubuntu on the container host, though. with some non-upstream patches
<Chipaca> T_X: what  os is the guest running?
<T_X> and whether that might be creating these issues for me
<T_X> the guest is running Ubuntu
<T_X> with a Debian Stretch in the container I had even more issues
<T_X> Ubuntu 18.04 that is
<Chipaca> T_X: at this point I'd ask stgraber
<Chipaca> I hope they don't mind
<T_X> also, within the Ubuntu 18.04 container the squashfuse package, version 0.1.100-0ubuntu2 is installed as suggested by stgraber's excellent blog post
<cachio> mvo, hey
<xnox> mvo, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1791691 is critical
<mup> Bug #1791691: PATH broken in systemd units <block-proposed> <cloud-images:Confirmed> <snapd (Ubuntu):New> <snapd (Ubuntu Bionic):New> <snapd (Ubuntu Cosmic):New> <https://launchpad.net/bugs/1791691>
<xnox> mvo, do you want me to write a patch for handing empty or unset PATH?
<xnox> mvo, cause current behaviour is broken =))) i've blocked release of snapd into bionic-updates.
<cachio> mvo, zyga, should we make this for the other test suites #5806 ?
<mup> PR snapd#5806 opened: tests: fix install snaps test by adding link to /snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5806>
<mup> PR #5806: tests: fix install snaps test by adding link to /snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5806>
<cachio> mvo, zyga or is something we should fix on the installer/setup
<mvo> xnox: thanks, feel free to write a patch, otherwise I will fix it in my morning
<xnox> mvo, well, it is fairly straight forward, and it can wait until tomorrow. plus we'd want a fix-up uploads into bionic-proposed and cosmic =/ and i don't know how you do those right, to comply with sru process etc.
<xnox> mvo, the writting fix is the smallest piece here.
<mvo> xnox: yes, will do either now (if I manage before I need to leave for hockey) or tomorrow
<mvo> xnox: first thing
<xnox> mvo, i did not test, to see if actually a simple "#!/bin/bin/printf PATH=/snap/bin\n" is actually enough to cover all cases with and without PATH set in systemd.
<mvo> xnox: I'm slightly puzzled, I thought systemd always sets a PATH if none is set
<xnox> mvo, hockey is more important =)
<xnox> mvo, it does.... after generators are run
<xnox> as i have now found out and confirmed.
<Chipaca> are we aiming to have /snap/bin prepended, or appended to path?
<xnox> but it does 'gather' envrionment in perculiar ways w.r.t. substitution and expansions
<ogra> appended
<mvo> xnox: interessting, sounds like the test we added was inadequate :/
<xnox> Chipaca, always appended.
<xnox> mvo, it was fine for initramfs-full boots which have PATH set when /sbin/init is execed; but that's not true in lxd case, or initrmafs-less boots
<mvo> xnox: what will happen if the generator sets the path to "/snap/bin" only - will systemd still add sensible defaults?
<xnox> mvo, it does
<mvo> xnox: whats the logic then? will it append the default path?
<xnox> for the no-path set in LXD. and i did not feel like rebooting my machine. actually let me test these combos in a vm quickly
<xnox> default path appears to be prepended
<mvo> xnox: nice
<mvo> xnox: that sounds like the fix will be trivial, thats good to know
<mup> PR snapd#5807 opened: interfaces: extra argument for static attrs in NewConnectedPlug/NewConnectedSlot <Created by stolowski> <https://github.com/snapcore/snapd/pull/5807>
 * cachio lunch
<mvo> xnox: https://github.com/snapcore/snapd/pull/5808/files
<mup> PR #5808: snapd-env-generator: fix when PATH is empty or unset <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5808>
<mup> PR snapd#5808 opened: snapd-env-generator: fix when PATH is empty or unset <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5808>
<kyrofa> roadmr, I once again have an inbox full of "manual review requested for version ..." for nextcloud's uploads. They seem to have been resolved (perhaps that was you) but now I have tons of revs that aren't in a chanel. I have to be honest, this is getting very frustrating
<niemeyer> pstolowski: Just one final detail and looks okay, thanks for the changes!
<kyrofa> I assume those are reviews timing out again. And the fact that pushes don't remember the channel they're supposed to go to is maddening
<pstolowski> niemeyer: thanks, looking
<cjwatson> kyrofa: One of my bits of upcoming planned work will have the side-effect of helping with that (see comment on https://docs.google.com/document/d/1vabN2wBNtGdBqShN1xi9a-osfGPtmA8EARdXfs2kfDI/edit#heading=h.l2jjh07gbn3p)
<cjwatson> (Only specced so far, not yet started and won't be for a while)
<Wimpress> Dmitrii-Sh: Sorry, I missed your earlier ping. Can I help?
<cjwatson> It would still need rephrasing the push/release API in some way; but it would avoid the obvious negative side-effects of doing that in the current system
<roadmr> kyrofa: I have a merge proposal to increase that timeout, hmm perhaps I'll ask for it to be cowboyed now so you don't face so much pain and frustration
<roadmr> kyrofa: the "don't remember the channel they're supposed to go to" thing is https://bugs.launchpad.net/snapstore/+bug/1684529 but it's not as straightforward as "just remember this"
<mup> Bug #1684529: Need for manual review loses intent to release to channel <Snap Store:New> <https://launchpad.net/bugs/1684529>
<xnox> mvo, that looks good to me.
<xnox> mvo, it testing things are weird, if PATH is set in the environment, and one doesn't expand it, it looks like it does override things and than initramfs-full boots fail to come up
<kyrofa> cjwatson, that's a helpful doc, thank you. I look forward to those improvements. Are they actually on the store roadmap?
<xnox> mvo, so this fix for empty or unset path looks good to me.
<xnox> mvo, please upload in all the places =)
<cjwatson> kyrofa: yes
<cjwatson> well, modulo unresolved disagreement about the expiry thing, but the rest are
<mborzecki> niemeyer: could you take a look at https://github.com/snapcore/snapd/pull/5713 ? i think all outstanding issues have been addressed
<mup> PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5713>
<niemeyer> mborzecki: Will do later today
<mborzecki> niemeyer: thanks
<zyga> cachio: looking
<niemeyer> mborzecki: Now I'll take a break and head outside for a while
<niemeyer> mborzecki: Sorry, that wasn't to you specifically :)
<zyga> cachio: that's a tricky question, I think it depends on what you want t o test
<niemeyer> See you all later or tomorrow
<cjwatson> advocacy basically said "iz broken, pls fix" so it's kind of a pile of things that improve the situation in various ways :)
<kyrofa> cjwatson, this cycle's roadmap, or next?
<zyga> cachio: I think it's okay to setup the symlink on prepare.sh but then again, it's not really testing what people will otherwise see so it may hide bugs
<cjwatson> kyrofa: depends how quickly we finish with git per-branch permissions.  realistically probably early next cycle
<kyrofa> cjwatson, fair enough, thanks for the info :)
<Dmitrii-Sh> Wimpress: we are trying to get this snap into the store for field engineering purposes https://forum.snapcraft.io/t/classic-confinement-review-request/7226 It's a test runner (rally) + a tempest plugin for openstack. It's an MVP for now as it allows us to run openstack validation tests. We called it fcbtesting on purpose because the way we implement it may be team-specific
<Dmitrii-Sh> the point of having it in the snap store is that we can download it from it in proxied environments where we cannot bring all the pip deps along with us
<Dmitrii-Sh> so, I just wanted to know what would be the review procedure and how could we move it forward
<zyga> Dmitrii-Sh: hey, I think you just need two votes that approve it
<Dmitrii-Sh> we tried working around the python multiprocessing (shmem) issue via a preload but did not have any luck with building the preload on bionic. We'd probably have to ship a patched python2 version with the snap otherwise that allows using custom paths
<cachio> zyga, so, we should do it as part the the installer?
<cachio> create that symlink?
<Dmitrii-Sh> zyga: from the snapcrafters org or? https://github.com/orgs/snapcrafters/people
<cachio> that should be the best solution
<cachio> ?
<zyga> cachio: installer?
<cachio> zyga, when we buidl the deb or rpm
<zyga> Dmitrii-Sh: no, from select group of people on the forum
<zyga> cachio: no, I thonk think we can do that
<mborzecki> cachio: i see a bunch of failures on amazon linux z with 'no space left'
<zyga> cachio: I mean, the package cannot ship the symlink
<cachio> zyga, but we can create it when installing the package
<cachio> mborzecki, do you have a link?
<mborzecki> cachio: https://travis-ci.org/snapcore/snapd/builds/426715967?utm_source=github_status&utm_medium=notification
<zyga> cachio: maybe let me ask this way, why do you want to change that? is it for a specific test?
<zyga> cachio: I think we could have a helper that installs a locally built snap
<zyga> cachio: that uses classic confinement
<zyga> cachio: and also creates the symlink if it is missing
<zyga> cachio: but again, I don't have the full context
<cachio> zyga, agree on that}
<cachio> zyga, I ask if a user could face this problem trying to install a classic snap
<zyga> cachio: yes, that's unfortunately how this is
<mborzecki> cachio: i'm going to restart that job
<cachio> mborzecki, go ahead
 * zyga focuses on Fedora for now
 * zyga hugs Pharaoh_Atem for his tireless packaging effort :)
 * Pharaoh_Atem raises eyebrow
<cachio> mborzecki, it is really weird because that image has not changed
<cachio> and it is 25GB
<Pharaoh_Atem> zyga: technically, the package can ship the symlink
<Pharaoh_Atem> in rpm land, symlinks can be shipped
<Pharaoh_Atem> they're just files like any other
<cachio> zyga, https://paste.ubuntu.com/p/RZnddCXszt/
<Pharaoh_Atem> you just have to be careful on how you create them
<cachio> this is happening on fedora right now
<cachio> zyga, is that an issue?
<zyga> cachio: right, that's is expected
<zyga> cachio: the users have to create the /snap symlink to install snaps using classic confinement
<zyga> Pharaoh_Atem: can we ship /snap -> /var/lib/snapd/snap?
<Pharaoh_Atem> no
<Pharaoh_Atem> but not because rpm can't do it
<Pharaoh_Atem> but because we shouldn't have that by default
<mup> PR snapcraft#2255 opened: catkin plugin: use SnapcraftException <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2255>
<Pharaoh_Atem> people should create the symlink themselves, because we don't know how their systems are going to be set up
<zyga> Pharaoh_Atem: could we create the symlink from snapd iff /snap doesn't exist?
<Pharaoh_Atem> that would be a scriptlet, but yes
<Pharaoh_Atem> the issue with that is that it makes behavior a bit less predictable
<zyga> not from a script let, just from snapd's bootstrap phase
<Pharaoh_Atem> ah
<Pharaoh_Atem> people would murder you for that
<mborzecki> zyga: cachio: we have a tests/main/classic-confinement wchich also runs on fedora and creates the symlink on demand
<Pharaoh_Atem> I'd have to disable it to prevent it being removed from Fedora
<zyga> installing classic snap, /snap absent, create symlink
<zyga> eh, ok :)
<zyga> cachio: ^ there's your answer :)
<zyga> it's just a policy, not a technical limitation
<Pharaoh_Atem> correct
<cachio> zyga, :(
<cachio> Pharaoh_Atem, zyga thanks for the answer
<zyga> Pharaoh_Atem: where do you need karma? I only see F29
<Pharaoh_Atem> zyga: F29 is the only one
<Pharaoh_Atem> all the others are already pushed through
<zyga> Pharaoh_Atem: btw, fix-info-dir problem is back
<Pharaoh_Atem> eh?
<Pharaoh_Atem> really? blech
<zyga> as is the cache hash checksum issue
<zyga> I'm ignoring that, just a curiosity on the side
<mup> PR snapcraft#2256 opened: local source: don't include .snapcraft directory <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2256>
<pedronis> mvo: is there a reason most call of MockModel*  in snapstate_test.go don't restore?
<om26er> can a snap, that uses layout feature be released to "stable" ?
<zyga> om26er: I actually don't know but I believe it should be
<zyga> om26er: layouts should be out of beta very soon now
<zyga> om26er: 2.36 IMO
<om26er> zyga: I had a snap with "grade: devel" and it got published to store after manual review (using layout). Today I changed that to "grade: stable" and seems my upload requires another review as well.
<zyga> I think store has no "memory" about the past approval
<om26er> so I was wondering if the problem is because I changed it to "stable"
<zyga> I don't think so
<om26er> hmm, I'll wait for the review then.
<om26er> in case anyone is interested https://dashboard.snapcraft.io/snaps/xbr-dashboard/revisions/23/
<zyga> om26er: how have layouts worked for you?
<om26er> zyga: well, my Qt based app wouldn't start if layouts were not there, so it definitely worked pretty great.
<zyga> did you see the new documentation page for them?
<om26er> no, I was probably given a working example from _ogra_
<zyga> om26er: check out https://forum.snapcraft.io/t/snap-layouts/7207
 * cachio afk
<mup> PR snapcraft#2257 opened: meta: take charge of environment used to run commands <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2257>
<zyga> hm, selinux, ...
<marcoceppi> Need some help with snaps an apparmor
<zyga> hello marcoceppi
<marcoceppi> My system's apparmor is crashing after a snap refresh
<zyga> can you please tell me more
<zyga> do you have logs? is the kernel crashing? which system are you using? can you provide the output of "snap version"
<marcoceppi> zyga: snap daemons aren't starting, which lead me to logs, which lead me to a bug, which lead me to apparmor https://paste.ubuntu.com/p/57ZSCCDVp4/
<marcoceppi> zyga: https://paste.ubuntu.com/p/BsvKCkjzY6/
<marcoceppi> kernel is up, but lxd daemon isn't running, complains about File not found, lead me to this bug, but I'm unable to remedy with restarting apparmor https://github.com/lxc/lxd/issues/4402
<zyga> apparmor is not a daemon, the service just loads the profiles into the kernel
<zyga> can you tell me more about your setup please
<zyga> this is a lxd container or is the issue on the host?
<marcoceppi> 14.04 with HWE kernel, bare metal server in OVH
<marcoceppi> issue with the host
<zyga> OVH?
<marcoceppi> server provider, ovh.com
<zyga> a, I see
<zyga> when has this issue started to show up?
<marcoceppi> It's been running a long time, moved from apt lxd -> snap lxd about 10 months ago, issue appeared this morning after a container got stuck
<zyga> can you show me "snap changes" from the host?
<zyga> maybe some snap refreshed and started causing issues (somehow)
<zyga> also, what does systemctl status apparmor.service say?
<zyga> hmm
<zyga> no such file or directory?
<marcoceppi> It's in my first pastebin
<marcoceppi> yes
<zyga> did you by any chance remove apparmor userspace package from the system?
<marcoceppi> error: no changes found
<zyga> what does dpkg -L apparmor say?
<marcoceppi> you want big L or little l?
<zyga> -L
<marcoceppi> https://paste.ubuntu.com/p/NSZHyKnJzH/
<zyga> ah, wait, 14.04 you say?
<marcoceppi> correct
 * zyga doesn't remember if on 14.04 + snapd apparmor is managed by upstart or by systemd
<marcoceppi> systemd is on here
<zyga> what does /etc/init.d/apparmor status say?
<zyga> yes but that's a special copy of systemd for snapd
<zyga> I don't believe it actually manages apparmor
<marcoceppi> https://paste.ubuntu.com/p/knJxXZGkjg/
<zyga> ok, so you have a number of apparmor profiles loaded
<zyga> so what's the issue that you observe? is lxd broken?
<marcoceppi> I suppose, the daemon isn't starting
<zyga> what does systemctl status snapd.service say?
<marcoceppi> active, running
<zyga> and sytemctl status snap.lxd.lxd
<marcoceppi> systemctl status snap.lxd.server snap.lxd.server.service    Loaded: error (Reason: No such file or directory)    Active: inactive (dead)
<zyga> it's not lxd.servcer, it's lxd.lxd.service
<zyga> or lxd.daemon.service
<zyga> the app names are the same as apparmor profile names
<stgraber> snap.lxd.daemon
<zyga> hey stgraber, thanks for that! :)
<marcoceppi> initctl: Unknown job: snap.lxd.daemon
<marcoceppi> sorry,
<stgraber> yeah, that's going to be a systemd one
<marcoceppi> https://paste.ubuntu.com/p/fTfpC9qf52/
<zyga> marcoceppi: probably not related, "dpkg --configure  -a" (just to rule out dpkg aspects)
<stgraber> marcoceppi: journalctl -u snap.lxd.daemon -n 300
<zyga> marcoceppi: what happens when you "systemctl start snap.lxd.daemon.service" ?
<marcoceppi> Sep 10 15:47:57 notaws.com lxd.daemon[1038]: cannot change profile for the next exec call: No such file or directory
<zyga> now we are getting somewhere!
<stgraber> ok, so that's a snap-exec thing then
<stgraber> *snap-confine
<zyga> too bad that's a generic apparmor error, not sure if it coming from snap-confine or lxd
<marcoceppi> apparently, when I ran start just now
<zyga> stgraber: note that one of the other pastebins show that the profiles are loaded
<marcoceppi> lxd woke up
<zyga> stgraber: how does lxd apply apparmor on exec or immediately?
<stgraber> zyga: LXD only plays with apparmor when containers start, the failure here is much much before that
<zyga> ack
<stgraber> zyga: what it could be is that our "aa-exec" wrapper which passes "-p unconfined" is somehow failing in this case, but that'd be pretty weird given that unconfined is guaranteed to always exist
<stgraber> marcoceppi: uname -a
<marcoceppi> So, could this just be that 14.04 + lxd + apparmor profile loading ordering issue?
<marcoceppi> Linux notaws 4.4.0-134-generic #160~14.04.1-Ubuntu SMP Fri Aug 17 11:07:07 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
<mup> PR #160: Trivial fix for the output of "snappy list" <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/160>
<zyga> marcoceppi: I don't know yet
<zyga> that looks like a vanilla ubuntu kernel
<stgraber> yeah, kernel is good, that matches our test system for LXD on 14.04
<marcoceppi> aye, hwe, but just what comes from the archive
<marcoceppi> happy to just shove this machine to xenial if that's a plausible fix, now that lxd is run from the snap I'm less worried about a system update
<zyga> marcoceppi: please describe this on the forum -- it's late anyway so I will EOD soon
<zyga> I'm looking at a selinux issue now
<mup> PR snapcraft#2258 opened: build providers: snapcraft images for multipass <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2258>
<mup> PR snapcraft#2259 opened: cli: show trace if no tty <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2259>
<mup> PR snapcraft#2251 closed: pluginhandler: stop using alias for snapcraftctl <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2251>
<mup> PR snapd#5809 opened: tests: using single sh snap in interface tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5809>
<mup> PR snapcraft#2254 closed: build providers: add support for --shell <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2254>
#snappy 2018-09-11
<mup> PR snapcraft#2258 closed: build providers: snapcraft images for multipass <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2258>
<mup> PR snapcraft#2256 closed: local source: don't include .snapcraft directory <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2256>
<Doctor_Nick> leeloo dallas multipass
<Doctor_Nick> one of the posts on the forum says that fine-grained network mediation is on the snapcraft roadmap; does anyone know where the proprosal for this is?
<Doctor_Nick> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/796588
 * Doctor_Nick shakes head sadly
<mup> Bug #796588: Fine-grained network mediation <aa-feature> <aa-kernel> <kernel-net> <AppArmor:In Progress> <apparmor (Ubuntu):Triaged> <linux (Ubuntu):Triaged> <https://launchpad.net/bugs/796588>
<zyga> Good morning
<zyga> There is a power outage here. I only have my laptop and phone
<zyga> Some phases are being turned on and off so Iâll leave my desktop off for now
<zyga> Some phases are being turned on and off so Iâll leave my desktop off for now
<mborzecki> morning
<zyga> Hey
<mborzecki> zyga: wow, got +1 on mount mappings PR, would you like to do another pass there?
<zyga> yeah
<zyga> just breakfasting
<mborzecki> zyga: wonder if i should pester jdstrand for review there as well
<zyga> mborzecki: I think Jamie will be back today or perhaps tomorrow
<zyga> mborzecki: I'll be back soon, there was a power outage last night and I'll work from my laptop doing reviews more than anything
<mborzecki> zyga: oh, was there a thunderstorm or sth?
<zyga> no idea
<zyga> whole street went dark
<zyga> around after 1AM
<zyga> I was brushing my teeth when it happened
<zyga> some parts of AC returned at 3-4AM
<mborzecki> zyga: maybe it was planned shutdown :)
<zyga> it broke my print :(
<zyga> it's going to be another 9 hours
<mborzecki> zyga: printing weapons of mass destruction?
<zyga> companion cubes :)
<mborzecki> hahah
<mborzecki> damn, don't remember the last time i played portal
<zyga> I was printing calibration cubes
<zyga> of increasing size
<zyga> oh and power is out again
<zyga> I just switched to LTE from my laptop
<zyga> man...
<zyga> I want to see if Z axis is stable
<zyga> and if there is any wobbling on the printer bed that causes layer misalignment as the print continues
<mborzecki> heh, some PRs failed yesterday either getting go packages from github or poking the snap store, must have been an outage at some cloud provider
<mborzecki> zyga: shoud i review #5802 or #5805 first?
<mup> PR #5802: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/5802>
<mup> PR #5805: cmd/snap-update-ns: enforce trespassing checks <Created by zyga> <https://github.com/snapcore/snapd/pull/5805>
<zyga> Mmmm
<zyga> 5802 please
<zyga> Iâll get to reviews in a moment, my wife forgot her phone to work
<Doctor_Nick> yeah, that'll be handy for debugging
<zyga> re, still on LTE but some phases are back so my computer is up :)
<zyga> mborzecki: which PRs are best to review first?
<mborzecki> zyga: mine?
<mvo> heh - s/mine?/mine!!!/ ;)
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mvo> for me github is super slow and right now timing out :/
<mborzecki> mvo: that's about right :)
<zyga> mborzecki: yes
<zyga> hey mvo :)
<zyga> mvo: at least you have power :D
<mborzecki> mvo: had 5570 stuck in build pending status, but the travis job was already green
<zyga> I spent way too much time last night on selinux
<zyga> but I think I'm making progress
<zyga> I'll do reviews today and respond to feedback
<mvo> mborzecki: aha, let me look (or try to :)
<zyga> but I will try to fix some selinux issues
<mborzecki> mvo: restarted it already
<mvo> mborzecki: if its green I can override it
<mborzecki> zyga: i only have 2 other prs, #5770, #5785, independent of each other, pick whichever
<mup> PR #5770: many: provide salt for generating instance-key in store requests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5770>
<mup> PR #5785: tests,interfaces: run interfaces-account-control on UC18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5785>
<mup> PR snapd#5632 closed: overlord: integrate device enumeration with udev monitor <Hotplug> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5632>
<mborzecki> mvo: #5808 also failed because of github/store connectivity issues, i've restarted it earlier
<mup> PR #5808: snapd-env-generator: fix when PATH is empty or unset <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5808>
<mvo> mborzecki: cool, thanks for this
<zyga> mborzecki: thanks
<mborzecki> mvo: since you commented on both 5770, 5785, could you take another look?
<mborzecki> btw. snap list --all bails with parallel installed snaps :P
<zyga> mborzecki: bails?
<zyga> what does it do
<mborzecki> zyga: probably some bad globbing, all you get is https://paste.ubuntu.com/p/TqWXGDFNrJ/
<zyga> ah
<zyga> it tries to find snap by name
<mborzecki> it's actually poking an incorrect path
<zyga> but ignoring the instance name
<zyga> that's ... odd :)
<zyga> well
<mborzecki> yup
<zyga> power is back!
<mborzecki> fix coming up soon
<zyga> I restarted my printer, 9 hours left :(
<mvo> mborzecki: 5785 looks like its not from you
<mborzecki> mvo: 5758, sorry :)
<mvo> mborzecki: sure, looking
<pstolowski> morning
<mborzecki> all right, the parallel installs integration branch has been update with all the PRs so far, the travis job should still be green
<mborzecki> pstolowski: hey
<zyga> mborzecki: sorry for making the 2nd branch so big btw
<zyga> mborzecki: it's tad scary at 1K2
<zyga> mborzecki: but at the same time it shows what it takes to lug that state around; maybe there is a better way?
<mborzecki> zyga: once 5802 lands the other one should 'appear' smaller, right?
<zyga> yes
<mborzecki> wish there was a mode in gh where you can view the diff against some other PR
<mborzecki> i suppose you can fiddle with the url directly, but that's quite inconvenient
<zyga> yeah
<zyga> LP had that feature
<zyga> https://github.com/snapcore/snapd/pull/5808 doesn't want to get geen
<zyga> green*
<mup> PR #5808: snapd-env-generator: fix when PATH is empty or unset <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5808>
<pedronis> mborzecki: some small comment to #5770
<mup> PR #5770: many: provide salt for generating instance-key in store requests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5770>
<mborzecki> pedronis: thanks, looking
<mvo> mborzecki: yeah, I like the suggestion of pedronis. its probably me overthinking things, but the fact that we added "salt" felt to me like we make a strong promise about the "strength" of the hash we send to the store. i.e. before it was just a way to sort things, now we protect it actively. I did some back of the envelope calculations and I think we should be fine with the 16 char secret, for peace of mind I would even up
<mvo>  it to 32 but then we should be really fine
<mborzecki> mvo: refresh-privacy-key sounds good to me too, naming is hard heh :)
<mvo> mborzecki: it totally is
<mvo> mborzecki: thank you, I like this name too
<mvo> pedronis: if you could re-review 5803 that would be great (its the content provider hang fix)
<pedronis> in a sec
<mvo> pedronis: no rush, the tests are unhappy anyway :/
<pstolowski> zyga: going over your tresspassing PR and asking some naive questions
<zyga> sure
<zyga> thank you!
<zyga> hmmm
<zyga> go crashes on "go build"
<zyga> not something I wanted to see in the morning
<zyga> it crashes in osutil
<zyga> on golang 1.11
<zyga> ah, wait on 1.10.1
<niemeyer> Mornings
<zyga> hey :)
<niemeyer> mborzecki: Something is not quite right with the "system" alias on the interfaces command
<niemeyer> mborzecki: "snap info core" stopped working on my machine
<niemeyer> Sorry, not info
<niemeyer> interfaecs
<pstolowski> niemeyer: o/
<niemeyer> pstolowski, zyga: Heyas
<zyga> niemeyer: we're discussing that just now
<mborzecki> niemeyer: my hunch is that's the remapping that was added in 2.35 and daemon now knowing if client is aware of the change
<mborzecki> zyga: ^^
<niemeyer> zyga: Where?
<niemeyer> zyga: Don't see it
<zyga> the "snap interface core" stopped working beause the response is "system:..." and the filtering is done client side
<zyga> niemeyer: in the internal channel
<pstolowski> mvo: got FAIL: snapstate_test.go:10921: snapmgrTestSuite.TestInstallDefaultProviderRunThrough after running the tests in a loop for ~1h locally
<niemeyer> mborzecki: So, we need to do something about this..
<pstolowski> mvo: investigating it this morning
<pedronis> mvo: +1 with some nitpicks
<niemeyer> mborzecki: We should probably wait until tomorrow as I have a call with them in my late afternoon, so will be able to tell in more detail what else we need, but we definitely need to fix the behavior of "snap interfaces core"
<mvo> pstolowski: nice, thanks for finding this
<pstolowski> mvo: well, i haven't found the cause yet :)
<niemeyer> We originally had some logic that would detect whether the query was made for core, and if so keep the name untouched
<mvo> pstolowski: heh, thanks for "almost-finding" this then ,)
<Chipaca> niemeyer: we could make snap interfaces always show the actual snap
<Chipaca> ie not do the core/core18/fedoracore/snapd -> system translation on the way out
<Chipaca> core-fedora? fedore?
<niemeyer> Chipaca: Yeah, I think we should always present the actual name if people requested for that specific name
<niemeyer> Chipaca: Not sure if that's their issue, though.. that's why I'd like to talk to them first
<Chipaca> niemeyer: i meant in /v2/interfaces directly
<Chipaca> niemeyer: agreed, totally
<Chipaca> we've had too much run-around-and-fix-it due to chinese whispers
<niemeyer> Chipaca: Right, also mean /v2/interfaces directly
<Chipaca> niemeyer: in /v2/interfaces, without specifying any select parameter, you get a list of stuff that talks about "system"
<Chipaca> (this is the legacy interfaces listing)
<diddledan> eeenteresting: https://code.visualstudio.com/blogs/2018/09/10/introducing-github-pullrequests
<niemeyer> Chipaca: Ah, okay.. so you mean having interfaces never return the alias
<niemeyer> Chipaca: Sure, that's the revert option
<niemeyer> Chipaca: We may need to do that  depending on how bad their issue is
<Chipaca> niemeyer: â¦ at least the legacy one
<niemeyer> Yeah
<Chipaca> niemeyer: so if we find out they're not using select=, we can do that and not touch the new
<Chipaca> anyhow, back to coding for me
<Chipaca> (shout for reviews)
<niemeyer> Chipaca: Or we just finish that new command
<niemeyer> ("connections")
<Chipaca> niemeyer: I suspect they're talking to the socket
<niemeyer> gopkg.in is down, btw
<niemeyer> Well, it's not down..
<niemeyer> GitHub is blocking it
<niemeyer> So if anyone has a good contact there, please let me know
<Chipaca> niemeyer: you could say Microsoft is blocking it, to make it sound more ominous (to me)
<niemeyer> Chipaca: It's a bit ironic indeed, to be honest
<niemeyer> It's running for 4 years now
<diddledan> the empire is blockading it?
<diddledan> we need rogue one
<Saviq> hey all, while working on the mir-kiosk tutorials we stepped on a mine of sorts, we have a race between mir-kiosk starting and creating the wayland socket and the app starting and being able to connect to it, what would you say would be the right solution across snaps? obvious one is a loop+timeout in a wrapper, but every app out there would need to include one, is there anything better do you think?
<Saviq> both mir-kiosk and the kiosk app are snap daemons with restart-condition: always, but systemd bails on the app if it restarts too quickly anyway
<mup> PR snapd#5810 opened: rfc: restore "core" as the API-level host for implicit slots <Created by zyga> <https://github.com/snapcore/snapd/pull/5810>
<Chipaca> Saviq: hmm!
<zyga> Saviq: socket activation :)
<Chipaca> zyga: are they in the same snap?
<zyga> but it's tricky unless the socket is in a public space like /var/lib/snapd/$SNAP_NAME/common
<Chipaca> um
<Chipaca> Saviq: are they in the same snap?
<zyga> Chipaca: socket activation would work in all cases
<Saviq> no, separate snaps
<Chipaca> zyga: if they were in the same snap, Before= would do the trick
<Saviq> but we'd need to make mir-kiosk socket-activatable... but you're right that does sound like the right approach
<zyga> Chipaca: perhaps, only if the snaps also use sd notify
<zyga> Chipaca: otherwise the socket may not be ready for real
<Chipaca> zyga: yup
<Chipaca> Saviq: another thing we could do
<Chipaca> Saviq: is expose RestartSec
<Chipaca> Saviq: you could try to see if that'd do the trick; it's how long to sleep before actually restarting
<Saviq> yeah that would work, but the "we could expose" part is a bit scary in terms of timelines ;)
<Chipaca> Saviq: agreed :-)
<Saviq> I think it might actually be easier to make mir-kiosk socket-activatable
<Chipaca> Saviq: you can fake restartsec by adding 'sleep 1' to the top of your wrapper script though
<Chipaca> Saviq: which is a lot easier than checking the socket in there :-)
<Saviq> indeed :)
<Chipaca> Saviq: the default sleep is 100ms which is probably too low for anything involved, anyway
<Chipaca> Saviq: mir-kiosk is c++, yes?
<Saviq> Chipaca: yes
<Saviq> well, *mir* is, mir-kiosk is just a wrapper around it
<mborzecki> does gopkg.in has issues or is it github?
<Chipaca> /o\ it's wrappers all the way down
<Saviq> :D
<zyga> mborzecki: I see gopkg.in down
<Chipaca> mborzecki: https://mobile.twitter.com/gniemeyer/status/1039433916019613696
<Saviq> Chipaca: really it's just startup scripts
<Saviq> that don't really fit in mir proper
<Chipaca> Saviq: but to make it socket-activatable you'd have to make mir itself be socket-activatable
<Chipaca> ?
<Saviq> yes
<mborzecki> Chipaca: zyga: thx
<Saviq> which should be easy, as far I can tell
<Saviq> just "if systemd gives you a socket, use it; otherwise create your own"
<Chipaca> Saviq: yep, there's example code (in C) for how to cover some corner cases well
<Chipaca> Saviq: http://0pointer.de/blog/projects/socket-activation.html
<Chipaca> Saviq: example 3 (at the bottom)
<Saviq> yeah that's what I was looking at
<zyga> Chipaca: we just have to use de-vendorized packages while github and gopkg.in is down ;)
<Chipaca> zyga: brb devendorizing self
<zyga> chipa.ca/internal/organs ;)
 * Chipaca cannot get chipa.ca
<zyga> I don't understand myself either sometimes
<Chipaca> zyga: no, i mean, i need to be a canadian business to buy chipa.ca
<Chipaca> mvo: dunno if you saw https://forum.snapcraft.io/t/snapctl-not-found-in-base-core18-snaps-hooks/7297
<zyga> launchpad is not responding to post requests for me
<mvo> Chipaca: I saw it but it not fully read it yet
<mvo> Chipaca: I suspect this is a problem with stable
<mvo> Chipaca: stable core18
<Chipaca> mvo: I checked on edge
<mvo> Chipaca: oh, you did - ok
<Chipaca> mvo: no snapd installed, snapctl is dangling
<Chipaca> no snapd snap i mean
<pedronis> how does that work, a symlink ?
<Chipaca> yep
<mvo> Chipaca: oh course
<pedronis> did we break snap-confine binding
<pedronis> of those things?
<Chipaca> mvo: in fact i can't install snapd :-)
<Chipaca> because i'm not a gadget with a model or sth
<pedronis> ah
<pedronis> core18 expects them to come from snapd
<Chipaca> pedronis: dunno
<pedronis> but here it's core and core18
<pedronis> fun
<Chipaca> ye
<pedronis> (too many moving parts problem)
<mvo> yes
<pedronis> (not enough tests)
<Chipaca> it's bind-mountingn the directory from core (i assume) and that's missing snapctl
<mvo> Chipaca: which is odd, we move it there a while ago
<mvo> Chipaca: when I ls /usr/lib/snapd/snapctl I see it
<mvo> Chipaca: but nevermind, I will write a spread test
<mvo> Chipaca: for this case and that will give us a) an answer b) a regression test
<mvo> pedronis: about the missing restores in snapstate, I'm working on a PR for this
<niemeyer> pedronis, pstolowski: This is repeating ad-infinitum here:
<pedronis> mvo: I'm not sure they are needed to be honest
<niemeyer> 2018-09-11T09:21:52Z INFO auto-connect of snap "gopkg" will be retried because of "gopkg" - "core" conflict
<Chipaca> mvo: true, I can see it there in core
<Chipaca> dunno what's going on
<niemeyer> Command was
<niemeyer> snap install ~niemeyer/gopkg_2018.03.27_amd64.snap --dangerous
<mvo> pedronis: oh, right - we may set on in SetUpTest
<mvo> pedronis: let me double check that
<pedronis> the mock is strange
<pedronis> because the style is a bit different around those tests
<pedronis> niemeyer: is that pulling in core as well?
<niemeyer> pedronis: Yeah
<pedronis> is not sorted
<niemeyer> gopkg was scheduled before core
<niemeyer> Yeah
<niemeyer> pedronis: The strange thing is that core did finish
<pedronis> ah
<pedronis> then it's bizarre
<niemeyer> pedronis: and even then gopkg couldn't get installed
<niemeyer> Just kept retrying
<niemeyer> pedronis: We really need those conflict improvements :(
<niemeyer> installing core independently works of course
<pedronis> a bit unclear why if core finished is still waiting
<pedronis> that seems trange
<mvo> pedronis: happy to make it less strange, I just need some more details what concerns you (not urgent)
<cjwatson> Anyone familiar with core18 kind of stuff?  Does https://bugs.launchpad.net/launchpad-buildd/+bug/1791907 sound like a plausible diagnosis from me?
<mup> Bug #1791907: Cannot build base snaps <launchpad-buildd:New> <https://launchpad.net/bugs/1791907>
<pedronis> mvo: just that having a full mock function seems overkill
<pedronis> if we never restore anway
<niemeyer> pedronis: Yeah, and it retried every 5 secs
<mvo> pedronis: I just looked and I think we should restore, we don't mock in SetUpTest so this is currently leaking
<niemeyer> Suspect that's easy to reproduce
<pedronis> mvo: no, the problem is that the style is mixed
<mvo> pedronis: otoh I can do a "SetModel" and use that in SetupTest and in the tests without a restore
<pedronis> mvo: really mockModel are th odd ones
<niemeyer> pstolowski: Can you dig into that please? It's closely related to the bits you're touching, and worked fine until recently
<niemeyer> pstolowski: SHould be easy to reproduce.. the local snap file just had network and network-bind plugs
<niemeyer> No other interfaces
<pstolowski> niemeyer: yes, looking
<pedronis> mvo: yes, SetModel would be more in style
<mvo> pedronis: ok, so SetModel() and no restore? happy to do that
<pedronis> mvo: again snapstate_test.go is probably getting too big
<mvo> pedronis: what can we do about it? splitting it into more logical chunks?
<pedronis> maybe
<mvo> but yeah, its gigantic :/
<pedronis> it's doing odd things
<mvo> pedronis: I will attack the snapctl on core18 issue now, then look at missing content provider warnings and then I should have time for the SetModel cleanup
<pedronis> like having a suite in the middle of another for example
<mvo> pedronis: what odd things in particular?
<zyga> pstolowski: hey, I replied to your comments on the PR
<mvo> pedronis: right
<pedronis> just a sign it's hard to navigate in it
<pstolowski> zyga: k thx
<mvo> pedronis: +1
<pedronis> mvo: anyway, I think the style  there atm is no Mock if the value is a function that is originally nil, just put it back to nil in TearDown
<mvo> pedronis: +1
<pedronis> mvo: this is fun:   grep "Suite)" snapstate_test.go,  you can see the suites mixed
<mvo> :/ indeed
<pedronis> mvo: snapstate_test.go  api_test.go and store_test.go  are the largest files
<pedronis> in that order (descending)
<mborzecki> niemeyer: should this guy put your name in that field? https://github.com/snapcore/snapd/pull/5799#issuecomment-420201428
<mup> PR #5799: Install snap-failure binary on Fedora <Created by eyusupov> <https://github.com/snapcore/snapd/pull/5799>
<niemeyer> mborzecki: Yeah, that's fine
<niemeyer> mborzecki: Eldar just signed it
<mborzecki> niemeyer: yup, he posted a note in github too
<mup> PR snapd#5811 opened: tests: add test that runs snapctl with a core18 snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/5811>
 * Chipaca wonders why the rabbits look so tasty, down their rabbitholes
<diddledan> who's in charge of building the docker images?
<diddledan> snapcraft*
<diddledan> snapcraft docker images*
<zyga> diddledan: no idea
<diddledan> hmm, I don't know what I can do to help this person then: https://forum.snapcraft.io/t/permission-denied-when-building-with-snapcore-snapcraft/7186/20
<diddledan> seems the :stable tagged image can't build desktop app snaps (cannot find the desktop-launch script when it has definitely been placed into prime) and the :latest image doesn't include a fix that the person is needing
<mup> PR snapd#5812 opened: snapstate: refactor tests to use SetModel* <Created by mvo5> <https://github.com/snapcore/snapd/pull/5812>
<niemeyer> Phew..
<niemeyer> gopkg.in is back up now.. GH debugged the issue on their end and deployed changes to fix it
<niemeyer> It doesn't look like it was actual firewalling
<diddledan> niemeyer: go forth and pkg in!
<niemeyer> diddledan: Forth is a bit strange, but quite a unique and interesting language :)
<diddledan> haha
<diddledan> I've never seen forth code I think
<Chipaca> niemeyer: sometime, when you're needinig a break, give Wizard's Bane a read
<zyga> mborzecki: doing one more pass on https://github.com/snapcore/snapd/pull/5713/files
<mup> PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Squash-merge> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5713>
<zyga> but first, more coffee - I'm feeling awake now
<mborzecki> zyga: thanks
<pstolowski> niemeyer: so far unsuccessful in reproducing the issue you observed - i tested on a clean xenial with custom snapd (current trunk) and no core, then snap install --dangerous mytestsnap (it has network and network-bind plugs; core gets installed, they get autoconnected). were you testing this on cosmic?
<mborzecki> zyga: left you some comments in 5802
<zyga> thank you!
<niemeyer> pstolowski: No, 16.04
<niemeyer> pstolowski: It was a brand new system
<zyga> mborzecki: I'll apply all, thanks!
<niemeyer> pstolowski: And it was the current stable
<niemeyer> pstolowski: I think mvo landed something recently about sorting which might have affected this issue
<niemeyer> Chipaca: What's that about? /me googles
<pstolowski> niemeyer: i think mvo has a fix for hang on content-providers, but it hasn't landed yet
<niemeyer> Chipaca: Sounds interesting :)
<niemeyer> Chipaca: I love this review.. "This is what happens when a computer programmer and D&D player attempts to write a book. The result is not pretty."
<niemeyer> How to blame the book *and* the author *and* every programmer *and* every D&D player, at once!
<Chipaca> niemeyer: Cook is not a good writer
<Chipaca> niemeyer: but the story is good
<mvo> Chipaca: do you know the charles stross laundry series?
<Chipaca> mvo: nope
<mvo> Chipaca: the description of the other one sounds like you might like those too https://www.goodreads.com/series/50764-laundry-files
<tomwardill> they get pretty dark
<mvo> tomwardill: yeah, especially the later ones
<tomwardill> the first few are pastiches of various genres, some people hate that
<tomwardill> but they're good books
<tomwardill> mvo: reminds me, I think I'm a book behind
<pstolowski> pedronis: hey, i've accidently stumbled on https://pastebin.ubuntu.com/p/gSjHnr77KX/ - note the return nil; was this intended? assert tests don't seem to excercise this sceneario, snap setup is always there
<pedronis> pstolowski: no, seems a typo
<mvo> tomwardill: I'm looking forward to book9 which will happen in some weeks. I like book7 quite a bit
<pstolowski> pedronis: ok, i'll fix it
 * mvo goes back to the non-magical coding
<Chipaca> mvo: nice. I could get book 1 from a library... but getting to the library costs me more than the amazon book :-)
<mvo> Chipaca: haha, you could try a excerpt first
<mvo> Chipaca: (eh, whatever it is called in english to get the first few pages as a sample for free)
<Chipaca> :-)
<mvo> what is it actually called?
<oSoMoN> jdstrand, hi! when you have a moment could you please comment on https://forum.snapcraft.io/t/fido-u2f-authentication-fails-in-chromium-snap-build/6130/4 ?
<cjwatson> "excerpt" or "sample" sounds fine
<cjwatson> Amazon calls it a sample I think
<mvo> thanks cjwatson
<mborzecki> mvo: pedronis: refresh-privacy-key it is, pushed everything to #5770
<mup> PR #5770: many: provide salt for generating instance-key in store requests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5770>
<mup> PR snapd#5813 opened: image: warn on missing default-providers <Created by mvo5> <https://github.com/snapcore/snapd/pull/5813>
<mvo> mborzecki: nice
<mup> PR snapd#5814 opened: daemon: fix snap list --all with parallel snap instances <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5814>
<mup> PR snapd#5815 opened: client: catch and expose logs errors <Simple> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5815>
<pedronis> pstolowski: the issue wit core and gopkg is confusing,  the code is relatively straighforward, go over all tasks that are no ready, but core was done
<pstolowski> pedronis: yes; i couldn't spot anything in the code, will try some more to reproduce although afaiu it needs a core refresh to be triggered at the same time, so a bit hard. starting from a clean slate (no core installed) pulls core as expected and everything works
<pedronis> pstolowski: but even a core refresh from another task would hit the find symmetric logic, no?
<pstolowski> pedronis: that's correct, we don't care about same changes
<pstolowski> pedronis: are you suggesting to manually invoke core refresh, then install the snap at the same time?
<pedronis> maybe, but still don't undestarnd, to hit that logging we need to  not have a pending autoconnect task on gopkg or core,  and have a pending task on core
<pedronis> of link-snap or setup-profiles kind
<pedronis> pstolowski: also if they were installed together and there was not core,  a core refresh would conflict (those conflicts are based on the entire change not a part/lane)
<mup> PR snapd#5816 opened: overlord/assertstate: propagate TaskSnapSetup error <Created by stolowski> <https://github.com/snapcore/snapd/pull/5816>
<pedronis> pstolowski: what I fear more is that something added installing core twice ?
<pstolowski> pedronis: ^ can you take a look?
<pstolowski> oh
<pedronis> we had a bug like that at some point
<pedronis> I think John fixed it
<pstolowski> we would see something in snap changes right?
<pedronis> yes
<pedronis> snap changes would be good to have
<pstolowski> niemeyer ^ can you grab a copy of state.json and share?
<pedronis> pstolowski: there might also be a silly bug about checking from the wrong name/snap somewhere
<pedronis> that we don't see
<pedronis> or core/system confusion
<Chipaca> gah
 * Chipaca ~> lunch
 * zyga experiments with snap instances for review
<Chipaca> zyga: can we talk about 'snap interfaces potato'?
<mup> PR snapcraft#2260 opened: build providers: allow setting ram and disk size <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2260>
<zyga> Chipaca: yes
<zyga> wanna HO?
<Chipaca> zyga: having lunch, so not really :-)
<Chipaca> bah
<zyga> sure
<Chipaca> i'm happier typing with my mouf full
<zyga> anytime after standup unless clashing meeting
<zyga> :D
<zyga> :[%#]
<Chipaca> zyga: my problem is that "snap interfaces some-rando-string" does not error
<zyga> :[%#]   &
<zyga> drat!
<zyga> mmm
<zyga> indeed, that's counter intuitive
<Chipaca> you pick that up sir, i didn't spend all morning cleaning for you to through your food all over the place
<zyga> maybe "error: cannot find interfaces matching some-random-string"
<Chipaca> zyga: ok
<Chipaca> zyga: which takes me to problem #2
<ahasenack> mvo: hi, should this sru be stopped? https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1786438
<mup> Bug #1786438: [SRU] 2.35 <verification-needed> <verification-needed-bionic> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Trusty):New> <snapd (Ubuntu Xenial):New> <snapd (Ubuntu Bionic):Fix Committed> <https://launchpad.net/bugs/1786438>
<Chipaca> zyga: it starts printing stuff before knowing :-)
<ahasenack> because of https://bugs.launchpad.net/cloud-images/+bug/1791691
<mup> Bug #1791691: PATH broken in systemd units <block-proposed> <cloud-images:Confirmed> <snapd (Ubuntu):In Progress> <snapd (Ubuntu Bionic):In Progress> <snapd (Ubuntu Cosmic):In Progress> <https://launchpad.net/bugs/1791691>
<zyga> Chipaca: that's easy to fix
<mvo> ahasenack: yes, we will do a .2 hopefully today. we had some trouble with github being down though but still hopefully today
<Chipaca> zyga: which takes me to problem #3
<Chipaca> zyga: that thing's messy :-)
<zyga> oh boy
<zyga> allice is still falling
<zyga> you tell me that :D
<zyga> but please be specific, messy how/
<Chipaca> zyga: what's your easy fix for #2?
<Chipaca> zyga: the easy fix is usually either, accumulate into an array, check length of array before printing the header, *or*, have a flag and check before printing whether you'd printed the headers
<zyga> Chipaca: I think we can just print once we fully know, that should be easy
<Chipaca> zyga: both of those are made harder because of #3 :-) it's not a simple loop-check-print thing, it does lots of little decisions
<Chipaca> zyga: so
<Chipaca> zyga: can i refactor it to accumulate? it'll probably change quite a bit
<zyga> may I just say that we want to kill that thing entirely
<zyga> and do snap connections?
<zyga> that may be nicer
<zyga> and less magic
<zyga> so what's 3? :)
<Chipaca> zyga: er, we can't kill it, it's already depended on by people :-)
<zyga> we can deprecate it
<zyga> it would be a new API call for sure
<Chipaca> even deprecated, i'd still want to address this
<zyga> I cannot wait for warnings to say "you used a deprecated command, use ... instead"
<zyga> sure
<abeato> sergiusens, hey, I dug more into that issue I mentioned about debug info in binaries, it turns out this is what is happening: https://bugs.launchpad.net/snapcraft/+bug/1791946
<mup> Bug #1791946: Default autotools CFLAGS are overriden in some cases <Snapcraft:New> <https://launchpad.net/bugs/1791946>
<ahasenack> mvo: any quick workaround available for cosmic lxd containers? Some file to edit?
<Chipaca> zyga: ok, i'll refactor it (in a bit)
<zyga> Chipaca: are you changing it?
<Chipaca> zyga: unless you'd rather do it yourself, yes
<zyga> Chipaca: let's talk at the standup, it should be easy
<zyga> I just want to agree on what we want :)
<zyga> mborzecki: I'm back to sorting
<zyga> doing it more scientifically than before
<mvo> ahasenack: you can probably just rm the generator
<ahasenack> mvo: which file is it?
<mvo> ahasenack: one sec, let me find it
<mborzecki> zyga: can't tell if that's good or a bad thing
<ahasenack> ok
<mborzecki> zyga: what are you sorting?
<zyga> mborzecki: it's good, we want to be correct
<zyga> mborzecki: the fstab entries
<mborzecki> aah
<zyga> mborzecki: a sorting algorithm that understands both source -and- target
<mvo> ahasenack: /usr/lib/systemd/system-environment-generators/*snapd*
<ahasenack> thanks, will give it a try
<mvo> snapd-env-generator is the exact filename
<mvo> ahasenack: sorry for the trouble, if github stops acting up and tests are back I can do the upload so hopefully later today things should be good again
<ahasenack> mvo: ok, then tomorrow's cloud image should have the fix
<ahasenack> mvo: I think it worked, after the rm and a reboot, the container seems to have started up correctly
<ahasenack> | c1                            | RUNNING | 10.0.100.248 (eth0) |      | PERSISTENT | 0         |
<ahasenack> yep, ssh is working, etc
<ahasenack> thanks!
<mvo> ahasenack: good! and sorry for the trouble
<Saviq> jdstrand: hey, one question about the x11 plug/slot situation for XWayland (https://github.com/snapcore/snapd/pull/4545) - any idea why it's not necessary to connect them (as a reminder, the same snap provides the slot and connects back to itself)? is it that the slot itself has the required permissions and those get applied without connection?
<mup> PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4545>
<zyga> pstolowski: reviewing that huge PR now
<zyga> well, after HO
<pstolowski> zyga: thx
<sergiusens> thanks abeato
<abeato> yw
<zyga> pstolowski: have a look
<niemeyer> pstolowski: Just sent the state.json to your email
<pstolowski> niemeyer: got it, thanks
 * zyga -> meal (unfair to call lunch now)
<ogra> linner (thats like an afternoon brunch)
<ogra> (or lupper if you are british ;) )
<mvo> 5803 needs a second review please
<pstolowski> mvo: looking
<mup> PR snapcraft#2261 opened: build providers: inject the base for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2261>
<mvo> thanks pstolowski
<stevenm> hey what can I do about this stupid 'snap' directory in my $HOME
<stevenm> it just sits there looking all very stupid and lowercase
<stevenm> essentially out of place
<stevenm> can I reconfigure so it is at least .snap or something?
<popey> stevenm: not currently
<zyga> stevenm: hey, we are working towards being able to move it but this is not possible yet
<ogra> stevenm, echo "snap" >~/.hidden
<ogra> stevenm, that will a least hide it from the file manager
<ogra> (you might to re-login afterwards to make it take effect ... or restart nautilus or whatnot)
<MattJ> >> rather?
<zyga> niemeyer: gopkg.in /github are acting up again
<ogra> MattJ, indeed, thats safer in case the file exists already (it rarely does though)
 * cachio afk
<Dmitrii-Sh> hi, is there any specific list of people who should be @mentioned on the forum to get a review for a classic snap?
<Chipaca> Dmitrii-Sh: not really, as long as it's followed the process it should be picked up
<Chipaca> Dmitrii-Sh: why?
<popey> Dmitrii-Sh: do link us to it, in case we missed it
<Dmitrii-Sh> Chipaca, popey: https://forum.snapcraft.io/t/classic-confinement-review-request/7226/2
<Dmitrii-Sh> We're basically doing a rally + tempest snap for field engineering purposes
<Dmitrii-Sh> popey, Chipaca: the classic side of it is there because of python multiprocessing
<Dmitrii-Sh> SHM paths are inaccessible because of apparmor
<Chipaca> Dmitrii-Sh: snaps have access to (namespaced) shm
<ogra> isnt there @reviewers ?
<popey> That's unfortunate
<Dmitrii-Sh> Chipaca: yes, but python2 multiprocessing doesn't use that (the cpython lib itself)
<popey> I see there's a suggestion to use a patched python. I don't know it well enough to know the impact of that
<ogra> (to ping the review team)
<Chipaca> ogra: yes, but it's rude to do so unless they've been dragging their feet :-)
<Dmitrii-Sh> popey: the patch is not upstream yet. Do you suggest building cpython2 and adding that to the snap?
<ogra> :)
<Dmitrii-Sh> that'll take some time we do not have currently unless there is a well-defined path
<pstolowski> pedronis: ok, i think i understand what happened with that issue that niemeyer hit
<popey> Sorry, I don't know python enough.
<Dmitrii-Sh> popey: I see that python3.4 has the right patch https://github.com/python/cpython/commit/e943697750a5828c0b4937ab28a301001700ad84 . The problem is that we have to stick to python2 for this snap as rally itself has some python3 support issues
<ogra> just rewrite it in go ;)
<Dmitrii-Sh> I tried to make it work and even patched it in the snap after pulling but during test runs some errors come up which do not on python2
<Dmitrii-Sh> hah!
<Dmitrii-Sh> yes
<ogra> :)
<mvo> xnox: the fix for the env generator got reviews and we will land it as soon as github is back to being normal
 * ogra always has the helpful comments ... especially after long workdays
<mvo> xnox: sorry for the delay, my plan was to get this done in my morning but then gitub exploded
<xnox> ha
<mup> PR snapd#5817 opened: snapstate/tests: serialize all appeneds in fake backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/5817>
<Dmitrii-Sh> popey: I could move the repo under https://github.com/openstack-snaps and have it there for our specific use-case
<pstolowski> mvo: ^ run it for 2 hours, 4 instances, didn't fail
<pedronis> pstolowski: yes?
<pstolowski> pedronis: it's two things: we're dealing with "old" state and injecting "auto-connect" task for gopkg from doLink() snap handler. but we also have "setup-profiles" with core-phase-2 for gopkg. it's arranged to be run after "link-snap" and "auto-connect". In the autoconnect conflict check we conflict with ourselves because of that setup-profiles phase 2. The message about conflict with core is bogus, it's just resulting
<pstolowski> from iterating over candidates (and trusting that we don't conflict with own link/unlink/setupprofiles tasks)
<pstolowski> normally we would never conflict with self because link-snap and setup-profiles run before auto-connect, so they are Done
<pedronis> pstolowski: ah, is the old  fallback logic for old snapd ?
<pstolowski> pedronis: yes
<pedronis> s/old/ first
<pedronis> pstolowski: why do we have the 2nd setup-profiles for gopkg though? it's not a core
<pstolowski> I guess I couldn't reproduce because I was running snapd from trunk
<pstolowski> pedronis: yeah. https://paste.ubuntu.com/p/Bxd4sZyNJt/
<pstolowski> pedronis: and i see most (if not all) of the phase-2 logic is gone now
<pstolowski> (but that's a side note)
<pedronis> ah,  this is dangerous ?
<pstolowski> pedronis: yes
<pedronis> that's why,  old snapd didn't detect the type for dangerous
<pstolowski> ah
<pedronis> so the 2nd setup-profiles
<pedronis> but iÂ thought we would inject auto-connect from the 2nd setup-profile if there are two
<pedronis> are we injecting auto-connect twice ?
<pedronis> in that case
<pstolowski> pedronis: no. we only inject from doLinkSnap (and we inject only if we see unlink-snap and setup-profiles in same change)
<pstolowski> (and if we don't see auto-connect in the change already)
<pedronis> pstolowski: yes, but the question is where we inject it if there are two setup-profiles ?
<pedronis> after the first, after the 2nd ?
<pedronis> the issue is that we inject after the first ?
<pstolowski> pedronis: we always inject from doLinkSnap, after link-snap task (so, after first setup-profiles, but before 2nd setup-profiles)
<pedronis> I see
<pstolowski> we basically ignore the fact that there might be 2nd setup-profiles
<pedronis> it's not the best placement
<pedronis> for core or this corner case
<pedronis> pstolowski: why can core finish though?
<pedronis> it would have the same problem no?
<pedronis> ah, because there's no old core tasks
<pedronis> no
<pedronis> mmh
<pedronis> pstolowski: how does core itself avoid getting stuck ?
<pstolowski> pedronis: that's a good question. i see everything is undone, so it's hard to say what happened. I only see repeated 'retry' messages on gopkg auto-connect task
<pedronis> pstolowski: because core hits the find symmetric logic ?
<pedronis> anyway
<pstolowski> pedronis: for core i only get " "2018-09-11T09:21:48Z INFO Requested daemon restart.",
<pstolowski>             "2018-09-11T09:23:40Z INFO Requested daemon restart (undo classic initial core install)"
<pstolowski> "
<pstolowski> from link-snap
<pstolowski> pedronis: right, probably that
<pedronis> pstolowski: anyway,  it seems we need to make the logic robust against  self-blocking but we also need to rethink whether we can move where we put the auto-connect
<pedronis> in these cases
<pstolowski> pedronis: indeed, i'll work on the latter tomorrow morning
<pstolowski> and probably conflict/retry messages should be tweaked to actually point at the real cause
<ijohnson> It seems like this is the case, but the github issue is what's affecting gopkg.in, correct? (I can't run snapd unit tests cause I need to update the dependencies, which fails on gopkg.in packages)
<mvo> pstolowski|afk: nice one, thank you
<Chipaca> $ snap list bofh
<Chipaca> Name  Version  Rev  Tracking  Publisher  Notes
<Chipaca> bofh  0.1      1    latest    chipaca    -
<Chipaca> WARNING: There are 1 new warnings. See 'snap warnings'
<zyga> oh, my :)
<Chipaca> and with that, I EOD
<zyga> watch out Chipaca  ;)
 * zyga hugs Chipaca 
<zyga> Chipaca: and ngettext :/
<Chipaca> obvs
<mup> PR snapcraft#2260 closed: build providers: allow setting ram and disk size <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2260>
<mup> PR snapcraft#2257 closed: meta: take charge of environment used to run commands <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2257>
<zyga> mvo: https://github.com/snapcore/snapd/pull/5818/files
<mup> PR #5818: cmd/snap: handle "snap interfaces core" better <Created by zyga> <https://github.com/snapcore/snapd/pull/5818>
<mup> PR snapd#5818 opened: cmd/snap: handle "snap interfaces core" better <Created by zyga> <https://github.com/snapcore/snapd/pull/5818>
<mup> PR snapd#5810 closed: rfc: restore "core" as the API-level host for implicit slots <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5810>
<xnox> mvo, hey
<xnox> mvo, i think implementing that generator in C is all nice and dandy
<xnox> mvo, but clearly no worky
<xnox> mvo, my examples are were in shell..... and i'm got tricked by this
<xnox> # unset PATH; echo $PATH; echo ${PATH}; /bin/sh -c 'echo ${PATH}'
<mup> PR snapcraft#2262 opened: schema: add "legacy" adapter type <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2262>
<xnox> mvo, so i think we need to make generator to print nothing if PATH is not set
<xnox> mvo, cause otherwise it cleans it.
<xnox> mvo, /bin/sh has a built-in PATH which may or may not be right ( https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1792004 )
<mup> Bug #1792004: built-in PATH seems to have sbin and bin out of order; and inconsistent <apt (Ubuntu):New> <bash (Ubuntu):New> <busybox (Ubuntu):New> <dash (Ubuntu):New> <dpkg (Ubuntu):New> <pam (Ubuntu):New> <systemd (Ubuntu):New> <bash (Debian):Unknown> <https://launchpad.net/bugs/1792004>
<xnox> mvo, and i.e. built-in paths are broken in /bin/sh on e.g. suse.
<xnox> mvo, and i need to fix systemd, to pass manager->environmnet and call envrionment generators with execve rather than just execv
<mvo> xnox: ok, thats fine
<mvo> xnox: so the advice is - no PATH if path is unset? thats also not ideal because then the aim of the generator is not reached
<mvo> xnox: shouldn't we make it use a default path in that case (maybe the one from /etc/environment)? but I guess the problem is then that not all distros agree on the default path
<mup> PR snapcraft#2261 closed: build providers: inject the base for classic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2261>
<mvo> xnox: anyway, this is a can of worms, I guess the safest option for now is to not print anything is PATH is unset and wait until the dust settles. but I need to call it a day, lets talk tomorrow
<xnox> mvo, yeah, talk tomorrow
<xnox> mvo, i hope to fix systemd....
<mvo> xnox: so the plan is: fix systemd, until then our generator just does nothing on an unset path?
<xnox> mvo, yeap
<mvo> xnox: sounds good to me
<mvo> xnox: is there a open systemd bug that I can refer to in my commit?
<xnox> mvo, not yet
<mvo> xnox: ok, I updated the pending PR with the suggested fix (to print nothing) we can sync up further tomorrow but that should fix the worst damage and on non-lxd systems things should be improving with that
<mvo> xnox: but need to gtg now, see you tomorrow
<xnox> hahahhaha
<xnox> * mvo has quit (Quit: Ex-Chat)
<xnox> * smoser (~smoser@23.28.108.176) has joined #snappy
<smoser> :-(
<xnox> just missed him
<NickZ> kyrofa: hey, we are using snaps in production now and all of our backend is snapped and is being orchestrated through juju
<kyrofa> NickZ, hey, that's amazing!
<kyrofa> Sounds like case-study material!
<NickZ> kyrofa: yeah, we'd be down for that when we launch
<NickZ> snapcraft is still missing a few features that I'd like to see, like being able to run daemons as an unprivileged user, and granular network permissions; I know that the former is on the roadmap
<NickZ> the latter seems to be blocked by this very old bug in apparmor: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/796588
<mup> Bug #796588: Fine-grained network mediation <aa-feature> <aa-kernel> <kernel-net> <AppArmor:In Progress> <apparmor (Ubuntu):Triaged> <linux (Ubuntu):Triaged> <https://launchpad.net/bugs/796588>
<mup> PR snapd#5815 closed: client: catch and expose logs errors <Simple> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5815>
#snappy 2018-09-12
<kyrofa> NickZ, yeah that's a question for jdstrand
<mup> PR snapcraft#2263 opened: project: catch parent YAML exceptions <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2263>
<NickZ> jdstrand: any progress on that feature since the last update?
<mup> PR snapd#5819 opened: tests: fix for nested test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5819>
<mup> PR snapcraft#2264 opened: Fix issue where cross compile target is ignored <Created by eberkund> <https://github.com/snapcore/snapcraft/pull/2264>
<mborzecki> morning
<zyga> Good morning
<zyga> Is github working now?
<mvo> zyga: good morning
<mvo> zyga: it looks like it, I see a lot of green today
<zyga> :-)
<zyga> Great
<mup> PR snapd#5816 closed: overlord/assertstate: propagate TaskSnapSetup error <Simple> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5816>
<mborzecki> zyga: mvo: hey
<mvo> mborzecki: good morning
<mup> PR snapd#5808 closed: snapd-env-generator: fix when PATH is empty or unset <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5808>
<mvo> pedronis: 5765 may be something you like, it splits bits of the store tests into their own file
<mborzecki> #5777 triggers one annoying bug in wrappers and map iteration order
<mup> PR #5777: wrappers/services.go: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5777>
<mup> PR snapd#5820 opened: wrappers: fix snap services order in tests <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5820>
<mborzecki> super simple ^^
<mvo> mborzecki: I'm curious about 5820 - I ran this test with -count 1000 and got no failure. is that a go 1.11 thing?
<mborzecki> mvo: i was doing some changes on top of 5777 and it failed like this https://paste.ubuntu.com/p/6T3JVzK7fj/
<mup> PR snapd#5803 closed: ifacestate: fix hang when retrying content providers <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5803>
<pstolowski> mornings
<mborzecki> mvo: it's a bug nonetheless. info.Apps is a map, so the order of iteration is random-ish
<mborzecki> pstolowski: hey
<mup> PR snapd#5804 closed: ifacestate: fix hang when retrying content providers (2.35) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5804>
<mvo> mborzecki: yes, I'm just surprised we don't see it more often
<mborzecki> mvo: wouldn't be surprised if changing some strings or order of operations in the test would be enough to trigger it
<mvo> zyga: whats the status of 1791814
<mvo> zyga: do we need a fix for the interfaces issue in 2.35.2?
<pedronis> mvo: hi, I see, IÂ need to finish something I was trying to finish yesterday before doing new reviews
<mvo> pedronis: no problem, this was just a fyi
<Chipaca> morning all
<Chipaca> was up stupid late last night, so I might zonk off at some point (but y'all woke up to a lot more green PRs, so that's ok i guess)
<zyga> mvo: re
<zyga> mvo: sorry for the lag
<zyga> mvo: there's a small PR but it's not critical
<mvo> zyga: ok, I release 2.35.2 without that, we can always do a .3
<zyga> that's fie
<zyga> fine
<pstolowski> pedronis: hey, my plan for solving yesterday's issue is to check the wait-chain (using the helper mvo just landed) and not retry if i see setup-profiles ahead, wdyt?
<pedronis> pstolowski: ?
<pedronis> pstolowski: didn't you say this was setup-profiles of gopkg
<pedronis> you shouldn't need to follow the chain to know that
<pedronis> pstolowski: also it should be possible to write a test, right?
<pedronis> pstolowski: also  IÂ remember why we put auto-connect where we put it, because setup-profiles phase2 is a nop anyway in the new world
<pedronis> pstolowski: another approach would be to check if setup-profiles has the phase2 flag and ignore it
<pedronis> either way, IÂ hope we don't need to follow the chain
<pedronis> pstolowski: you basically need an installingSnap like for the disconnect check?  then the two are the same again?
<pstolowski> pedronis: yes, it was setup-profiles of gopkg, but rather than checking if we have setup-profiles for same snap (which would also need to check if it's from same change i think), we would check if setup-profiles is waiting on us.
<pstolowski> pedronis: but you're right about setup-profiles phase 2 being noop, i forgot that
<pstolowski> pedronis: yeah, looking at if corePhase2 -> do nothing... seems to be most straightforward to ignore setup-profiles conflict in such case
<pstolowski> pedronis: and of course test is possible and a must
<pedronis> thx
<pedronis> pstolowski: the tricky bit is that it needs to be a spread test with an old snapd, or we need to manually construct what an old InstallPath would build
<pedronis> in terms of tasks
<pstolowski> pedronis: should be possible to have a spread test for just 16.04 system with snapd from distro, don't we do that already to test upgrades somewhere?
<pedronis> pstolowski: we do but  I don't know which  snapd we want,   desktop images  and cloud images vs archive have different versions
<pstolowski> ah
<pedronis> we sru snapd into 16.04
<pstolowski> right
<mup> PR snapd#5821 opened: release: 2.35.2 <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5821>
<pedronis> pstolowski: mvo maybe can help navigate that
<pstolowski> thx
<mup> PR snapd#5770 closed: many: provide salt for generating instance-key in store requests <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5770>
<zyga> is jdstrand back today?
<pedronis> he should be
<mup> PR snapd#5820 closed: wrappers: fix snap services order in tests <Simple> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5820>
<zyga> https://twitter.com/ismonkeyuser/status/1039392972339523586 ;)
<zyga> mvo: may 2.35.2 live long and prosper
<mup> PR snapd#5812 closed: snapstate: refactor tests to use SetModel* <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5812>
<mup> PR snapd#5814 closed: daemon: fix snap list --all with parallel snap instances <Parallel installs> <Simple> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5814>
<zyga>  pstolowski hey, there's a small conflict here: https://github.com/snapcore/snapd/pull/5497
<mup> PR #5497: overlord/patch: patch for static plug/slot attributes <Created by stolowski> <https://github.com/snapcore/snapd/pull/5497>
<pstolowski> zyga: thanks! will fix in a bit
<zyga> pstolowski: is this https://github.com/snapcore/snapd/pull/5680 something we ought to review?
<mup> PR #5680: [RFC] hotplug: handling of simple add/remove scenario <Blocked> <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5680>
<zyga> I need a 2nd review for https://github.com/snapcore/snapd/pull/5802
<mup> PR #5802: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/5802>
<pstolowski> zyga: this is RFC brach for high-level comments, i'm chopping smaller pieces from there into separate PRs
<zyga> ah, ok
<pstolowski> zyga: and it needs updating after existing hotplug PRs land
<mborzecki> zyga: so the last decision is system/core fix goes to the `snap interfaces` command but the API stays right?
<zyga> mborzecki: please land https://github.com/snapcore/snapd/pull/5713 once jdstrand ack's it
<zyga> mborzecki: yes
<mup> PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Squash-merge> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5713>
<zyga> mborzecki: I implemented that here: https://github.com/snapcore/snapd/pull/5818
<mup> PR #5818: cmd/snap: handle "snap interfaces core" better <Created by zyga> <https://github.com/snapcore/snapd/pull/5818>
<mborzecki> zyga: yeah, i'm looking it now
<zyga> mborzecki: I think we will need one more change
<zyga> mborzecki: once snapd is the holder
<zyga> mborzecki: the mapper needs to keep translating "core" and "system" to "snapd"
<zyga> mborzecki: right?
<zyga> mborzecki: I will make a PR for that
<mborzecki> zyga: probably, iirc the slots will appear on snapd now (pstolowski added the change?) but i'd expect the api to return 'system' there nonetheless
<pstolowski> mborzecki: i haven't changed that, i think the initial bits come from zyga
<zyga> mborzecki: the api does return "system" when "snapd" holds implicit slots
<pstolowski> mvo: hey, yt?
<mborzecki> zyga: you think you could extort a review from someone and land #5802 ?
<mup> PR #5802: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/5802>
<mup> PR snapd#5822 opened: wrappers: allow user mode systemd daemons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>
<mvo> pstolowski: yes
<mvo> pstolowski: s'up?
<pstolowski> mvo: hey, i was discussing writing a spread test for yesterday's issue with pedronis (see above ~1h ago); i'd need a spread test for 16.04 running an old snapd binary (the one from desktop image i think)
<pstolowski> mvo: do you know if we do anything like that already?
<pstolowski> mvo: i basically need to run from an "old" state into new snapd
<mvo> pstolowski: we have a upgrade test already
<mvo> pstolowski: I have not looked into the details in a long time
<mvo> pstolowski: there is also the option to use the snapd from the released 16.04 version
<mvo> pstolowski: but thats 2.0.2 which is pretty ancient
<mvo> pstolowski: tests/upgrade/basic/task.yaml - let me refresh my memory on this one
<mup> PR snapd#5823 opened: snapcraft.yaml: add workaround for LP:#1791871 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5823>
<pstolowski> mvo: looking
<zyga> mborzecki: I'd love to :)
<zyga> mvo: can you have a look at 5802 perhaps?
<pstolowski> mvo: right. the question is how to enforce a well known old version, not a newer one after SRUs
<mvo> pstolowski: that is hard
<mvo> pstolowski: what is the version we need?
<zyga> mvo: some failures on https://github.com/snapcore/core18/pull/70
<mup> PR core18#70: hooks: add rfkill <Created by mvo5> <https://github.com/snapcore/core18/pull/70>
<zyga> mvo: https://github.com/systemd/systemd/issues/10068 :)
<pstolowski> mvo: i need to find out yet; it needs to be a version that creates setup-profiles tasks with core-phase-2=true; Gustavo had it with a fresh install of 16.04
<mvo> ok
<mvo> zyga: aha, nice. /me hugs xnox
<zyga> mborzecki: added test to https://github.com/snapcore/snapd/pull/5818
<mup> PR #5818: cmd/snap: handle "snap interfaces core" better <Created by zyga> <https://github.com/snapcore/snapd/pull/5818>
<xnox> mvo, hm? =) are people stalking me on github or something?
<xnox> i just filed it.
<cjwatson> mvo: Hi - does https://bugs.launchpad.net/launchpad-buildd/+bug/1791907 ring any bells with you?
<mup> Bug #1791907: Cannot build base snaps <launchpad-buildd:New> <https://launchpad.net/bugs/1791907>
<cjwatson> It's pretty weird and I don't see how it can be launchpad-buildd's fault, but don't know where to reassign it
<pstolowski> mvo: looking at debian changelog, it would need to be snapd <= 2.33
<mvo> pstolowski: hm, the best option is probably to download it from https://launchpad.net/ubuntu/+source/snapd/2.32.9
<mvo> pstolowski: i.e. "curl https://launchpad.net/ubuntu/+source/snapd/2.32.9/+build/14895451/+files/snapd_2.32.9_amd64.deb ; sudo apt install -y ./snapd_2.32.9_amd64.deb"
<pstolowski> mvo: nice, is this something we can rely on to stay there for the lifetime of 16.04?
<mvo> pstolowski:
<mvo> pstolowski: yes
<pstolowski> mvo: great, thank you!
<mvo> pstolowski: yw
<zyga> xnox: I'm following systemd on github
<mup> PR snapd#5821 closed: release: 2.35.2 <Simple> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5821>
<mup> PR snapd#5819 closed: tests: fix for nested test suite <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5819>
<zyga> pstolowski: some comments on https://github.com/snapcore/snapd/pull/5807
<mup> PR #5807: interfaces: extra argument for static attrs in NewConnectedPlug/NewConnectedSlot <Created by stolowski> <https://github.com/snapcore/snapd/pull/5807>
<zyga> you wanted to land it quickly for conflict avoidance
<pstolowski> zyga: yes, thank you, yesterday's issue caught all my attention
<zyga> pstolowski: also some small feedback on the racy append fix: https://github.com/snapcore/snapd/pull/5817
<mup> PR #5817: snapstate/tests: serialize all appeneds in fake backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/5817>
<zyga> Sep 12 10:54:56 sep121046-033697 snapd[27140]: helpers.go:174: cannot regenerate seccomp profile for snap "core": signal: terminated
<zyga> hmm
<mup> PR snapd#5824 opened: [WIP] fetch store assertions together and in the context of interpreting snap-declarations <Created by pedronis> <https://github.com/snapcore/snapd/pull/5824>
<jamesh> zyga: thanks for the initial review of my branch.  If you've got any ideas about how to wrangle a spread test for this kind of thing, I'm all ears.  I haven't had any luck so far.
<zyga> jamesh: I think that's tricky, we'd have to start systemd as a user session manager in tests somehow
<zyga> jamesh: I don't have any ideas, perhaps it's doable, perhaps it's doable but requires extensive work
<zyga> I fixed formatting and pushed to your branch to unbreak unit tests
<mup> PR snapd#5799 closed: Install snap-failure binary on Fedora <Created by eyusupov> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5799>
<jamesh> zyga: sorry about that.  I pushed the branch up just before going out for a walk (wanted to get out of the house before it was dark)
<zyga> no need to be sorry :)
<jamesh> It was nice to see how little I needed to change
<jamesh> and I think some of the changes might be able to go away or be minimised further w.r.t. enable/disable
<mup> PR snapd#5806 closed: tests: fix install snaps test by adding link to /snap <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5806>
<om26er> How to get a snap publisher "verified" ?
<zyga> om26er: not sure, is there anything about it on the forum?
<om26er> https://forum.snapcraft.io/t/verified-developers/2005
<popey> We haven't published details of that internal process om26er
<popey> We're not planning on verifying everyone.
<zyga> jamesh: some tweaks for tests are probably needed to mock presence of a browser
<zyga> https://api.travis-ci.org/v3/job/425653825/log.txt
<mup> PR snapd#5785 closed: tests,interfaces: run interfaces-account-control on UC18 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5785>
<om26er> popey: we'd like to verify our company account at least.
<zyga> oh, I could verify my own company too
<zyga> oh man, time flies today
<kravietz> hello, I'm building a Python snap and getting this
<kravietz> The linker version '2.23' used by the base 'core' is incompatible with files in this snap:
<kravietz> At the priming stage
<kravietz> Any idea how to debug this?
<zyga> if you are building natively then your host must match the base snap of the applications in your snap
<zyga> in practice, if you don't say "base: core18" and build on ubuntu 18.04 you will see issues like this
<kravietz> Exactly, I'm using 18.04 as host
<zyga> the universal remedy is to build in a container/vm but I'll defer to kyrofa or sergiusens for details
<zyga> kravietz: just add "base: core18"
<kravietz> Let me try
<zyga> this will make your snap execute against the ubuntu 18.04 runtime
<zyga> so newer libraries and everything
<zyga> and compatible linker :)
<kravietz> zyga: it worked, thanks!
<zyga> kravietz: that's great, good luck :)
<mborzecki> pstolowski: some conflicts in https://github.com/snapcore/snapd/pull/5817
<mup> PR #5817: snapstate/tests: serialize all appends in fake backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/5817>
<pstolowski> mborzecki: thanks, will fix in a moment
<zyga> Chipaca: standup?
<zyga> ijohnson: some responses on your branch
<zyga> thank you for pushing it
<sergiusens> mvo: remeber when you told me interpreter symlinks would be relative? :-)
<sergiusens> (snapcraft) ubuntu@snapcraft-xenial-dev:~/source/keepalived$ ls /snap/core18/current/lib64/ld-linux-x86-64.so.2 -l
<sergiusens> lrwxrwxrwx 1 root root 32 Apr  2 21:07 /snap/core18/current/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.27.so
<mvo> sergiusens: uh, let me fix this
<mvo> sergiusens: this sounds like a regression from core18 vs core
<mvo> sergiusens: while i have you here - my snapd builds are failing in LP currently with"The source has changed on disk." and "Build failed" in https://launchpadlibrarian.net/387957761/buildlog_snap_ubuntu_xenial_arm64_snapd-2.35_BUILDING.txt.gz
<mvo> sergiusens: I tried to workaround with source-type: git
<mvo> sergiusens: but no luck
<mvo> sergiusens: I'm currently trying to trigger the build using the beta snapcraft (once I manage to convince lp-shell)
<mvo> sergiusens: but that is only good for a one-off build :/
<mvo> sergiusens: any ideas what I can try?
<sergiusens> mvo: can you try with edge?
<sergiusens> mvo: this is something kyrofa has been working on, mind waiting an hour until he comes on?
<sergiusens> mvo: or give me the source where snapcraft.yaml lives on
<mvo> sergiusens: this comes from https://github.com/snapcore/snapd
<mvo> sergiusens: and the build is https://code.launchpad.net/~mvo/+snap/snapd-2.35
<ijohnson> zyga: I refreshed the branch again, do you have any recommendations on a concise snap name for the test?
<sergiusens> mvo: you probably do not need that plugin anymore as you can script most of that in override-build
<sergiusens> mvo: but this is your issue https://github.com/snapcore/snapd/blob/master/parts/plugins/x_builddeb.py#L21
<sergiusens> mvo: if you want to continue that hack you will have to do more to not trigger "change detection"
<mvo> sergiusens: hm, I added that because of lp: #1772584
<mup> Bug #1772584: Having a "snap" directory with actual content causes build failures <Snapcraft:Triaged> <https://launchpad.net/bugs/1772584>
<mvo> sergiusens: I can play with override-build but last I worked on this having a populated "snap/" dir was a no-go and snapcraft would simply not work. but maybe that has changed? any hints welcome :)
<sergiusens> mvo: yeah, snap directory is special in snapcraft as things in there trigger special behavior
<sergiusens> just like debian/conrol means something
<sergiusens> mvo: I'll let kyrofa go over that with you to find a good path forward
<ppisati> uhm, i thought snapcraft's advanced grammar was transparent, and i could exploit it whenever i expected a string, but i guess i was wrong:
<ppisati> http://paste.ubuntu.com/p/hHvJXvghR5/
<ppisati> when i try this:
<sergiusens> debian/conrol means nothing though as I managed to typo my point
<mvo> sergiusens: ok, I understand that the naming of the dir is unfortunate - but at the same time, refactoring our code to call it notsnap would be unfortunate as well
<ppisati> http://paste.ubuntu.com/p/cpcnxm9Ttt/
<mvo> sergiusens: heh, no worries, I got your point
<zyga> ijohnson: test-snapd-... not sure :)
 * zyga gets dinner 
<sergiusens> mvo: you could always do your packaging out of tree, that might be cleaner
<ppisati> sergiusens: any idea? ^
<mvo> sergiusens: a separate repo you mean? one nice benefit from the current approach is that we get a new LP build every time our repo changes, not sure if that would be possible with an extra repo?
<ppisati> kyrofa: ^
<sergiusens> ppisati: that grammar thing needs to be enabled for that key, it is not for everything
<sergiusens> mvo: LP has tracking for that for "source" entries in parts
<sergiusens> build.snapcraft.io does at least, which means LP does too, just need to figure out where
<sergiusens> if it is not automatic
<ppisati> sergiusens: uhm, ok, so i need to patch the kernel plugin to accept it - any example of plugin / key that was patched to accept it? so i can read it and learn what i have to do?
<mvo> sergiusens: ok
<mvo> sergiusens: I like that the snapcraft.yaml is git right now, but maybe I just need to get used to the idea to move it out
<cjwatson> debian/control is a bad example anyway, since it's perfectly permissible and quite common practice to drop extra packaging-related helper files into debian/
 * mvo nods
<cjwatson> sergiusens: no, LP has no such tracking.  BSI handles this itself by having a poller script that parses snapcraft.yaml and looks for other parts to poll
<sergiusens> cjwatson: it is, our problem is that we gave meaning to so many paths... and what you say is true as long as you do not squat ones that do have meaning
<mvo> this is unfortunate for us because it blocks the snapd 2.35.2 snap release so having some agreement on the way forward would be good
<sergiusens> cjwatson: thanks for confirming that
<mup> PR # closed: snapd#5170, snapd#5234, snapd#5271, snapd#5346, snapd#5395, snapd#5451, snapd#5469, snapd#5497, snapd#5583, snapd#5596, snapd#5623, snapd#5644, snapd#5672, snapd#5680, snapd#5696, snapd#5712, snapd#5713, snapd#5714, snapd#5717, snapd#5724, snapd#5727, snapd#5739, snapd#5758,
<mup> snapd#5759, snapd#5762, snapd#5765, snapd#5768, snapd#5771, snapd#5777, snapd#5782, snapd#5789, snapd#5791, snapd#5792, snapd#5802, snapd#5805, snapd#5807, snapd#5809, snapd#5811, snapd#5813, snapd#5817, snapd#5818, snapd#5822, snapd#5823, snapd#5824
<cjwatson> perhaps you should define something under snap/ that snapcraft won't touch
<cjwatson> for instance, I often put things under debian/local/
<sergiusens> cjwatson: in the case of mvo, it is an entire source tree
<cjwatson> last I checked directories could contain directories :)
<mup> PR # opened: snapd#5170, snapd#5234, snapd#5271, snapd#5346, snapd#5395, snapd#5451, snapd#5469, snapd#5497, snapd#5583, snapd#5596, snapd#5623, snapd#5644, snapd#5672, snapd#5680, snapd#5696, snapd#5712, snapd#5713, snapd#5714, snapd#5717, snapd#5724, snapd#5727, snapd#5739, snapd#5758,
<mup> snapd#5759, snapd#5762, snapd#5765, snapd#5768, snapd#5771, snapd#5777, snapd#5782, snapd#5789, snapd#5791, snapd#5792, snapd#5802, snapd#5805, snapd#5807, snapd#5809, snapd#5811, snapd#5813, snapd#5817, snapd#5818, snapd#5822, snapd#5823, snapd#5824
<sergiusens> cjwatson: yeah, but in go, that would change the import path
<cjwatson> that sort of approach would allow people to keep things that are essentially part of snap-specific packaging somewhere under snap/, which would be tidy, while not interfering
<mvo> sergiusens: could we have logic like if os.path.exists(".snap"): ignore("snap") or something?
<cjwatson> surely you could set GOPATH
<mvo> sergiusens: or snap/.i-own-this-really or something?
<sergiusens> mvo: so kyrofa is the person to talk to as he is taking care of this thing
<mvo> sergiusens: ok, sorry, I thought it would need your architectural blessing  or something. if not thats fine I will talk to him
<sergiusens> cjwatson: snap dir lives next to another source dir they have that does "import <>/snap"
<mvo> sergiusens: thanks for your help in any case!
<sergiusens> mvo: no, it does not need my architectural blessing
<cjwatson> ah, that's a bit different from the sort of thing I was thinking of
<cjwatson> I do generally think that a subdir reserved for use by the packaging as opposed to snapcraft would be helpful
<sergiusens> cjwatson: yes, this is a ver special snowflake case where they got around it by monkey patching our code base through an external plugin :-)
<sergiusens> cjwatson: the snap/local seems like a very good idea we could move forward on that
<sergiusens> kyrofa: ^
<mvo> kyrofa: so once you are around I would love to talk to you about 1772584 (after having pestered sergiusens way too long about it)
<cjwatson> (It's true that name collisions in debian/ are possible, but in practice I've never run into them because they're basically always hidden behind debhelper compatibility level changes, at least if they're something that it's remotely plausible people might collide with by accident)
<cjwatson> (and the debhelper maintainer tends to do test rebuilds to spot problems with major changes AIUI)
<cjwatson> snapcraft has nothing like http://manpages.ubuntu.com/manpages/cosmic/en/man7/debhelper.7.html#compatibility%20levels AIUI ...
<sergiusens> no, our plan was to introduce that with build environments but that item got killed off high above
<sergiusens> cjwatson: speaking of testing, I switched some test jobs to use the snap and it seems they still use the deb (https://launchpad.net/~sergiusens/+snap/multipass-test). Are there any obvious mistakes here?
<cjwatson> build environments would be kind of orthogonal I thought - this kind of thing in packaging toolchains is more about the semantics of the packaging
<cjwatson> sergiusens: there's a bug where you have to request the builds using the API - the UI currently disregards auto_build_channels
<sergiusens> build environment is not the vm thing
<sergiusens> we were redesigning the yaml to be versioned, so you subscribe to certain semantics
<cjwatson> combination of https://bugs.launchpad.net/launchpad/+bug/1791265, https://bugs.launchpad.net/launchpad/+bug/1791269, and https://bugs.launchpad.net/launchpad/+bug/1791272
<mup> Bug #1791265: Manual snap builds don't allow for snapcraft/snapd channel selection <Launchpad itself:New> <https://launchpad.net/bugs/1791265>
<mup> Bug #1791269: Options for automatic builds could be defaults for all builds in a snap <Launchpad itself:New> <https://launchpad.net/bugs/1791269>
<mup> Bug #1791272: Manual snap builds could use a target channel override <Launchpad itself:New> <https://launchpad.net/bugs/1791272>
<cjwatson> ah, OK, well if it ever comes up again maybe you can get a less confusing name while you're there :)
<sergiusens> we are planning on bring that versioning piece back, but next cycle
<cjwatson> in the meantime, you should be able to use https://launchpad.net/+apidoc/devel.html#snap-requestBuilds
<sergiusens> thanks for the bug pointers
<cjwatson> explicitly passing the desired channels
<cjwatson> or https://launchpad.net/+apidoc/devel.html#snap-requestAutoBuilds should work too
<sergiusens> thanks
<cjwatson> I'll try to get at least the worst of those bugs fixed soon - they are absolutely confusing
<sergiusens> cjwatson: btw, someone proposed snap/x- as an ignore pattern
<cjwatson> same idea but x- seems cumbersome compared to a subdirectory.  I think you use x- in situations where you don't have other kinds of structure available
<cjwatson> but it's your project :)
<sergiusens> cjwatson: I wanted your opinion actually :-) and it is good
<cjwatson> I don't think exact choice of name is super-important, but structure is nice
<ijohnson> zyga: what about test-snapd-svcs-disable-install-hook as the name?
<zyga> Yeah that sounds good
<ijohnson> cool
<kyrofa> ppisati, I'm afraid it's not just generically used for all strings, whatever is responsible for processing it needs to actually call a function to make it happen
<ppisati> kyrofa: do you happen to remember what's the name of this function?
<kyrofa> ppisati, yeah let me show you, one sec
<kyrofa> ppisati, this may not be quite as simple as you were hoping, but here's how it works today: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/project_loader/_parts_config.py#L219
<kyrofa> There are two processors, one for global/root properties, one for part properties
<ppisati> kyrofa: /me scratches his head
<kyrofa> mvo, I'm looking at what you've got now, see if we can get you unblocked short-term and come up with something better long-term
<ppisati> kyrofa: ok, let me play around with it, let's see if i can bend my mind around it
<kyrofa> ppisati, let me know if you have any questions
<kyrofa> mvo, your monkey patch still works, have you tried building on edge? bug #1791871 is fixed there
<mup> Bug #1791871: 2.43 breaks when you run "snapcraft pull" first <Snapcraft:Fix Committed by kyrofa> <https://launchpad.net/bugs/1791871>
<kyrofa> Might be able to patch around the bug too... let's see
<mvo> kyrofa: thanks, I have not tried in lp with edge yet
 * cachio lunch
<kyrofa> mvo, try this, no edge required: https://paste.ubuntu.com/p/DXhkWMJbpD/
<kyrofa> Obviously a hack, essentially disables change detection
<mvo> kyrofa: cool, will do in a tiny bit (in a meeting right now). thanks a lot
<mvo> kyrofa: getting us unblocked for now is great, we can talk in brussels about a longer term solution
<pstolowski> niemeyer: you said in the standup you had some new feedback for one of my PRs, but i haven't received anything; have you saved/submitted?
<niemeyer> pstolowski: No, I've just been looking at a camera and microphone for that many hours
<pstolowski> niemeyer: ah, sure, understood; didn't mean to push you, just got worried for it get lost
<niemeyer> pstolowski: Oh, no worries.. I was indeed hoping to get more reviews finished, but didn't manage to
<mup> PR snapcraft#2259 closed: cli: show trace if no tty <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2259>
<thresh> hmm,  using qt 5.11 it seems statx syscall is now being used
<thresh> which is caught with apparmor it seems and results in "[28964.168141] audit: type=1326 audit(1536769071.191:214): auid=1000 uid=1000 gid=1000 ses=3 pid=4815 comm="vlc-qt-check" exe="/snap/vlc/x4/usr/libexec/vlc/vlc-qt-check" sig=0 arch=c000003e syscall=332 compat=0 ip=0x7f12e1428839 code=0x50000"
<thresh> no denials though
<mup> PR snapcraft#2255 closed: catkin plugin: use SnapcraftException <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2255>
<thresh> how would I go about whitelisting that syscall for my snap?
<thresh> looks like popey already hit that with Neon repos as well, in https://forum.snapcraft.io/t/unknown-syscall-when-running-an-18-04-built-snap/7094/8
<sergiusens> thresh: best to get either jdstrand or zyga on that thread
<sergiusens> mvo, kyrofa: now that the urgency on that is gone, we should checkpoint on this in Brussels
<kyrofa> Agreed
<thresh> thanks sergiusens!
<zyga> thresh: Iâll read that now
<zyga> That is interesting
<zyga> I think statx should be allowed by default
<zyga> jdstrand: ^ if you agree I can prepare the PR
<zyga> Iâll prepare the PR and we can discuss it there
<jdstrand> zyga: how do we know that 332 corresponds to statx?
<zyga>  I dont know yet, if this is not statx then my suggestion is moot
<zyga> Iâm walking to my desk now
<om26er> if snapd becomes a snap, how will you install it in the first place ?
<om26er> I just found there is a snapd snap available as well.
<zyga> re
<zyga> om26er: that's a great question :)
<zyga> om26er: it will be installed with a imaging tool
<zyga> on classic systems deb/rpm package will be used to install snapd which can then install snapd snap
<Chipaca> popey: on the laptop that becomes unusable on resume, do you have SNAPD_DEBUG enabled?
<Chipaca> popey: is it actually unusable, or is it hogging the network?
<om26er> zyga: so once my deb based snapd installs the snap based snapd, will I then be able to remove the deb based snapd ? (That would be a tongue twister if spoken)
<zyga> jdstrand: scmp_sys_resolver claims that it is statx
<zyga> om26er: I suspect so but we are not planning on removing the deb
<zyga> om26er: though maybe eventually that will be supported
<zyga> om26er: snapd as a snap is required in the multi-base world we are going towards
<zyga> om26er: where core16, core18 and future core20 will be co-installed to support diverse apps on a single system
<om26er> cool stuff!
<zyga> om26er: indeed :)
<cjwatson> om26er: Note that snapd already re-execs snapd inside the core snap, and has done for some time; moving that bit to a dedicated snapd snap is a refactoring, AIUI
<Chipaca> cjwatson: re-exec is a distro choice, though
<Chipaca> (ubuntu does)
<cjwatson> True
<jdstrand> zyga: interesting. are you on cosmic?
<om26er> cjwatson: I guess making that a separate snap will make updating snapd on a UbuntuCore system quicker
<zyga> jdstrand: indeed
<zyga> om26er: yes, it will no longer require a reboot
<ahayzen> jdstrand, thresh, BTW i think that this is related to Qt apps not running with core18 https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1774739  and this https://github.com/snapcore/core18/issues/4
<mup> Bug #1774739: Running Qt apps inside a 18.04 container crashes <qtbase-opensource-src (Ubuntu):New> <https://launchpad.net/bugs/1774739>
<mvo> sergiusens: I added it to https://forum.snapcraft.io/t/developer-sprint-sep-17th-2018/7336
<mup> PR snapd#5825 opened: tests: add snap install hook with base: core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5825>
<jdstrand> ahayzen: yes, for sure. zyga, if you are doing a PR, can you reference that bug ^
<zyga> thanks, will do
<joc> what's the simplest method to check in a shell script if a device has a serial assertion? would `snap known serial` exit with an error code if there wasnt one?
<ahayzen> zyga, thanks ! do you know if a fix would also help out docker containers ? Or would it be specific to snapd ?
<zyga> ahayzen: I'm not sure I understand
<zyga> unless those containers are inside snapd
<zyga> the change will allow all snap applications to use the new system call
<jdstrand> ahayzen: it is possible that docker is missing the statx syscall
<ahayzen> one bug was about running Qt applications under a straight docker container (no snapd), one was about running Qt apps with core18 snap
<jdstrand> ahayzen: I don't know how to adjust docker's policy to allow extra syscalls, but that is certainly possible
<ahayzen> apparently it works on debian sid, so i wondered if it was a general missing syscall for $container related things
<thresh> ahayzen, for docker, you need 18.04 docker engine and libseccomp 2.3.3 on a host
<thresh> that works
<thresh> 18.04 or later that is
<ahayzen> thresh, ah! So 17.12.1-0ubuntu1 from the archive is "too old" :-) ... i should use the snap ;-)
<jdstrand> 18.04 only has 2.3.1 of libseccomp
<jdstrand> which is why it shows up as unknown
<ahayzen> yeah i'm using 17.12.1-0ubuntu1 docker + 2.3.1-2.1ubuntu4 libseccomp
<jdstrand> zyga: note that golang seccomp might need to be adjusted to find statx
<thresh> maybe upstream docker wont use the systems libseccomp
<zyga> yeah, I suspect this will be a bit annoying to release
<mup> PR snapcraft#2265 opened: build providers: allow snapcraft channel selection <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2265>
<jdstrand> zyga: or rather, to resolve it. you might want to create a test case for this to make sure it is covered everywhere
<zyga> for sure
<ahayzen> yeah so debian testing has 2.3.3 seccomp and a newer docker.io, so makes sense it works. Thanks for the info!
<Chipaca> ok, EOD for me. Tomorrow: tests.
 * cachio afk
<kyrofa> jdstrand, I suddenly had a few PRs fail the review tools tests that pull from edge, did something odd happen?
<kyrofa> There didn't seem to be an actual error, just an exit 1. I'm re-running one now
<kyrofa> (I just got a pass locally)
<kyrofa> Wonder if it has something to do with trusty, I'll try it out on there
<kyrofa> Oh nevermind, this runs in a bionic lxd
<jdstrand> kyrofa: I'm neverminding
<kyrofa> jdstrand, found the issue. Running a bionic lxd: cannot perform operation: mount --rbind /lib/modules /tmp/snap.rootfs_cJIipS//lib/modules: No such file or directory
<kyrofa> stable core, edge review tools
<kyrofa> Works fine on bionic (without lxd)
<kyrofa> I'm able to reproduce simply by running review tools in a bionic lxd container on a bionic host
<kyrofa> jdstrand, we'll need to skip those tests for now
<jdstrand> kyrofa: that is something outside of the review-tools. they run as non-root and don't do anything like that
<kyrofa> jdstrand, https://forum.snapcraft.io/t/snaps-are-broken-in-bionic-lxd-container/7339
<kyrofa> Indeed, all snaps are broken in lxd bionic
<kyrofa> Which makes me want to scream "why don't we have tests for this yet?" again after the last LXD fiasco
<NickZ> well that's no good
<jdstrand> I thought they were added. maybe only for core 16 since core18 wasn't a thing?
<kyrofa> core16 is fine, and things still seem to work in xenial containers. But not bionic (still core, not core18)
<NickZ> i was just about to start looking into deploying the snaps in an lxd container, too :P
<sergiusens> jdstrand: this is lxd launch ubuntu:bionic and installing and running snaps in there
<jdstrand> kyrofa, sergiusens: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support.c#L645
<jdstrand> kyrofa, sergiusens: it sounds like the container doesn't ship /lib/modules?
<kyrofa> NickZ, worth the investigation, but leave yourself options. It seems not many people do that
<jdstrand> kyrofa: if so, what happens if you 'mkdir /lib/modules' in the container?
<kyrofa> jdstrand, it works
<kyrofa> I'll add that to the forum
<jdstrand> kyrofa: maybe changing the aforementioned line to '{"/lib/modules",.is_optional = true},' would be a viable fix
<kyrofa> jdstrand, perhaps so. Not sure what side effects that might have
<kyrofa> Hopefully the snapd folks see that tomorrow
<mup> PR snapcraft#2266 opened: integration tests: disable tests using bionic container <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2266>
<kyrofa> sergiusens, ^ there you go
<NickZ> kyrofa: yeah, but we kind of have to if we want to test juju deployment on a local server
<kyrofa> NickZ, this took roughly a year to fix: https://forum.snapcraft.io/t/lxc-snaps-dont-update/786
<NickZ> haha welp
<NickZ> its not a huge issue, we can test deployment on xenial
<kyrofa> Yeah I can't wholeheartedly recommend it until the spread suite includes relevant releases of lxd
<mup> PR snapcraft#2128 closed: project_loader: stop setting LD_LIBRARY_PATH <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2128>
<mup> PR snapcraft#2267 opened: build providers: refresh packages on bring up <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2267>
<mup> PR snapcraft#2250 closed: project_loader: add preflight check <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2250>
<mup> PR snapcraft#2265 closed: build providers: allow snapcraft channel selection <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2265>
<mup> PR snapcraft#2263 closed: project: catch parent YAML exceptions <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2263>
<mup> PR snapcraft#2268 opened: sanity checks: allow snap/local dir <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2268>
<mup> PR snapcraft#2269 opened: Provider decides on the image <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2269>
#snappy 2018-09-13
<mup> PR snapd#5826 opened: tests: refactor for nested suite and tests fixed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5826>
<mborzecki> morning
<zyga> Yawn, hey hey
<mborzecki> zyga: hey hey
<mvo> hey zyga and mborzecki
<mborzecki> any interesting reviews to look at?
<pstolowski> heyas
<mvo> pstolowski: good morning
<mup> Issue core18#4 closed:  Crash qt gui aplication (build with core 18 on ubuntu 18.04(LXD))  <Created by EndrII> <Closed by EndrII> <https://github.com/snapcore/core18/issue/4>
<zyga> there's going to be an interesting change
<zyga> to seccomp
<zyga> hopefully it won't be painful
<mborzecki> zyga: what kind of change?
<mborzecki> something in upstream?
<zyga> a "one liner"
<zyga> we need to support statx
<zyga> I'm on it
<mborzecki> ack
<pedronis> mborzecki: I reviewed #5778 a bit closer, is not super clear that all removes and undo cases have been replaced,  basically I tried looked at all the call paths to the removed os.Remove and seen if they grew a matching call to some new remove, it might also mean we miss some tests
<mup> PR #5778: snap-update-ns: remove deadcode <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5778>
<pedronis> mborzecki: sorry, I meant #5758
<mup> PR #5758: overlord/snapstate, snap: handle shared snap directories when installing/remove snaps with instance key <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5758>
<mborzecki> pedronis: thanks
<mborzecki> pedronis: the removes in undosetupsnap had to go one level higher to the caller, because you don't know whether it's ok to remove the directory in the cleanup code path
<pedronis> mborzecki: I know but there are other cases, removeDirs that you changed was called from a lot of places for example
<pedronis> not super clear they are all covered now
<pedronis> including undo cases
<mborzecki> pedronis: i see, so undoCopySnapData and doCopySnapData need a further fix, i'm not sure about cleanupSnapData, is cleanup executed only in success path?
<mup> PR snapd#5827 opened: ifacestate/autoconnect: do not self-conflict on setup-profiles if core-phase-2 <Created by stolowski> <https://github.com/snapcore/snapd/pull/5827>
<pstolowski> pedronis: ^ i didn't manage to recreate the case with spread (tried coming from snapd 2.0.2, 2.33.1, 2.23.9). i'm pretty sure the conflict check is the culrpit as discussed, but there might be a factor in reproducing that I missed
<mup> PR snapd#5765 closed: store: move download tests into downloadSuite <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5765>
<ogra> pedronis, any idea why the assertion importer talks aout a model that doesnt exist in https://forum.snapcraft.io/t/porting-ubuntu-core-to-imx6-am335x-issue/7089/20 ?
<ogra> (the model name of the image seems to be "advantech" not "rsb4220")
<ogra> *about
<pstolowski> zyga, mborzecki : responded to your comments to https://github.com/snapcore/snapd/pull/5807 and fixed gofmt oddities
<mup> PR #5807: interfaces: extra argument for static attrs in NewConnectedPlug/NewConnectedSlot <Created by stolowski> <https://github.com/snapcore/snapd/pull/5807>
<pstolowski> mvo: would you mind taking a look at https://github.com/snapcore/snapd/pull/5762 ?
<mup> PR #5762: ifacestate: don't initialize udev monitor until we have a system snap <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5762>
<mvo> pstolowski: sure, will do in a bit
<pstolowski> mvo: also, your https://github.com/snapcore/snapd/pull/5813 could land i think?
<mup> PR #5813: image: warn on missing default-providers <Created by mvo5> <https://github.com/snapcore/snapd/pull/5813>
<mvo> pstolowski: yeah, I think its good - was wonder if samuele wanted to peek at it but its probably fine as is
<mup> PR snapd#5818 closed: cmd/snap: handle "snap interfaces core" better <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5818>
<zyga> thanks!
<Chipaca> thursday before the sprint, and me without a haircut yet
<Chipaca> morning all
<mvo> Chipaca: hey! yeah, I'm scrambling to get osme things sorted as well
<Chipaca> mvo: I don't know what osme is, but it sounds serious
<Chipaca> mvo: today's my dad's birthday, as well. And I've got an interview with people from one of the boys' potential schools.
<Chipaca> and, I've got tests to write
<Chipaca> :-)
<mvo> Chipaca: sounds like a full day!
<mvo> Chipaca: *cough* osme -> some :(
<Chipaca> and a washing day! because the sun is out
<mvo> Chipaca: clear sign that I need to get better at typing
<pedronis> mvo: left a couple of non-blocking comments on #5813 for you to consider
<mup> PR #5813: image: warn on missing default-providers <Created by mvo5> <https://github.com/snapcore/snapd/pull/5813>
<mvo> pedronis: \o/ thank you
<pstolowski> oh right, haircut /o\, thanks for reminder!
<pstolowski> getting repeated failures today on google:ubuntu-18.04-64:tests/main/lxd
<pedronis> pstolowski: gave a +1 to the fix PR but it's red atm
<pstolowski> pedronis: yes everything is terrible atm
<pstolowski> pedronis: and thanks btw
<Chipaca> actuall, this thing is already nearly 900 lines. I'll split it, and then write the tests
<niemeyer> zyga, mvo: I think we should do a bit better for that fix
<Chipaca>        y
<niemeyer> But good mornings, first :)
<mvo> niemeyer: what fix in particular? and good morning :)
<niemeyer> mvo: The one about interfaces core
<mvo> ok
<zyga> niemeyer: hello
<zyga> what kind of improvement are you looking for?
<niemeyer> zyga: Heya
<niemeyer> zyga: It would be nice if it is possible, anyway.. let's see
<pstolowski> good morning niemeyer!
<niemeyer> zyga: Do we ever send the snap name to the server end?
<zyga> no
<pstolowski> mvo: thanks for the review of wait-for-core pr
<niemeyer> zyga: Hmm :/
<zyga> niemeyer: otherwise I would have implemented a server side fix
<niemeyer> zyga: and I guess we don't actually print the snap name either, when it's system/core
<zyga> that's correct
<niemeyer> zyga: Ok, sorry, the fix is great then, thanks
<niemeyer> zyga: The only other alternative I can think of is reverting the change, making it "core" again, and adding an explicit "nicknames" field
<zyga> I had a branch that does the revert, if we add the nicknames field we would indeed be 100% backwards compatible
<zyga> we could do that, that's an interesting idea
<zyga> let me check one thing really fast
<zyga> niemeyer: so in all cases we _can_ add a field
<zyga> so yeah, we could do that
<niemeyer> zyga: The thing that bothers me a bit about that approach is that we have a significant number of connections to core
<niemeyer> obviously
<niemeyer> zyga: So this will become super repetitive
<zyga> indeed :/
<zyga> but this is the best we can do without breaking the compatibility
<niemeyer> zyga: Perhaps we could add some metadata at the outer level
<niemeyer> zyga: So it stops being repetitive
<niemeyer> zyga: "nicknames": {"system": "core"}
<zyga> phone
<niemeyer> zyga: Not sure.. "phone" doesn't feel like a great nickname in this case
<zyga> i m on z call
<mvo> zyga: z ?
<zyga> I'm on a call
<mvo> heh :)
<mvo> ok sorry
<niemeyer> mvo: He's not getting jokes today :P
<mvo> niemeyer: heh
 * mvo hands zyga some more coffee
<niemeyer> "I'm on z call" feels so german somehow
<zyga> re
<zyga> ok
<zyga> so yeah, we could do that
<zyga> give me an hour to wrap this up
<niemeyer> I just got a reply to my flight re-request saying "Sorry for not responding earlier, we work 10:00-18:00.." .. the request was on Monday...
<zyga> I can reopen my branch, add the nickname there and see what we get
<niemeyer> zyga: There where?
<zyga> to the top-level of the response
<zyga> because we have space for that
<zyga> as in, the types are set up so that it is not hard to do
<zyga> niemeyer: we may even use this to fix another issue
<zyga> niemeyer: that the client doesn't know the type of the snap
<niemeyer> zyga: Yeah, I think we have a place specific for metadata in the response already
<zyga> to know that "core" or "snapd" are special
<zyga> and can be abbreviated
<zyga> and we could do it all in a way  that is 100% backwards compatible
<mborzecki> off to pick up the kids
<niemeyer> zyga: Yeah
<niemeyer> mborzecki: o/
<mup> PR snapcraft#2267 closed: build providers: refresh packages on bring up <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2267>
<pstolowski> "building microservices with go" ebook available for free today at www.packtpub.com today (follow 'Free learning...' button at the bottom)
<mup> PR snapcraft#2266 closed: integration tests: disable tests using snaps in bionic container <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2266>
<pstolowski> mvo: hey, i've added real device samples to https://github.com/snapcore/snapd/pull/5759 per your comment
<mup> PR #5759: ifacestate: implementation of defaultDeviceKey function for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5759>
<pstolowski> everything fails terribly on lxd spread test now (18.04). seems to be something fundamental - /var/snap/lxd/common/lxd/unix.socket is missing
<zyga> pstolowski: lxd is socket activated now
<zyga> perhaps the socket has moved?
<ogra> zyga, it isnt anymore
<zyga> no?
<ogra> (while it gets switched to the snap by default)
<zyga> can you tell me more?
<ogra> https://lists.ubuntu.com/archives/ubuntu-devel/2018-September/040487.html
<ogra> Note that at this time, the LXD snap isn't using socket activation yet.
<ogra> We have code in place for that in the edge channel but want to do more
<ogra> tests on it before we roll it out to all our users. This means that
<ogra> starting on Monday, LXD will be starting up unconditionally on 18.10
<ogra> images. This is a temporary situation and will be corrected by release.
<ogra> so better ping stephane, that might be a transition bug or some such
<ogra> (since i dont know if it should actually apply to 18.04 too)
<pstolowski> zyga: should we get rid of wait_for_lxd?
<zyga> pstolowski: I'm not very familiar with the details
<pstolowski> me neither
<pstolowski> we basically keep polling for /var/snap/lxd/common/lxd/unix.socket before actual tests
<mvo> pstolowski: cool
<mborzecki> re
<zyga> pstolowski: I'm deep in another task, can we discuss this in some time once I'm done
<pstolowski> zyga: sure, in the meantime i'm experimenting with this test a little bit
<mvo> pstolowski: nice, the updated tests give me a much better idea what it will look like in the real world
<Chipaca> pedronis: niemeyer: I've got three options, and they're three somewhat unpalatable, and I thought maybe you guys might help me decide (or find a fourth)
<Chipaca> if you recall, every successful command needs to check the warnings summary and report about it
<Chipaca> the three options I see: 1. have everything from client return a ResultInfo, that contains the wanring summary, and have every command check that once it succeeds. This is the one I wrote, but it has two problems: it's a massive diff :-) and it's very easy to forget to check for warnings on success of a command
<Chipaca> 2. have the client hang on to the relevant info, and pass the client into the checker. Smaller diff, just as easy to forget to do
<Chipaca> 3. in cmd/snap have a single client instace instead of a Client() method, and have main itself check the warnings. Small diff, single point checking (as long as no command calls os.Exit directly on success, which should be easier to catch),  but it's a global. Globals are bad, right?
<Chipaca> 3b. like 3, but change all commands so the client is passed in.
<Chipaca> pedronis, niemeyer: thoughts?
<pedronis> Chipaca: the part about the client keeping state is what we did for restarts fwiw,  but there were fewer places that cared
<pedronis>  Chipaca: so on that expect there is precedent, see Client.Maintenance
<Chipaca> yep
<Chipaca> pedronis: but here, every single command cares
<Chipaca> (with two exceptions: the warnings-related commands themselves don't care)
<pedronis> Chipaca: how would you pass in a client btw ?
<pedronis> Execute is part of go-flags contract
<menace> ahoi, is there a possibility for minikube to get the source recipe? there is a very old version of minikube installed, i'd like to try to update it on the current version
<Chipaca> pedronis: ah, drat, you're right
<Chipaca> cmars: ^ see menace's q
<pedronis> Chipaca: same with the output
<Chipaca> pedronis: the output?
<niemeyer> pstolowski: A few comments in #5782... nitpicks mostly (sorry)
<mup> PR #5782: ifacestate: helpers for generating slot names for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5782>
<pedronis> I mean you can't change either input or output of that
<Chipaca> pedronis: if this is 3b, that'd be every command doing checkWarnings(client) on success
<Chipaca> ah no
<Chipaca> pedronis: no it wasn't
<Chipaca> pedronis: so i don't follow, no
<Chipaca> pedronis: ah, maybe this: idea was you pass the client in, and then run does the checkWarnings(client) (client would presumably have warning info after the command was done with it)
<niemeyer> Chipaca: As pedronis mentioned, it sounds analogous to Maintenance
<niemeyer> pedronis, Chipaca: I think our Execute is already higher-level
<Chipaca> nop
<niemeyer> Or that's what my faulty mind reminds
<Chipaca> or yep
<Chipaca> niemeyer: no, the Execute from commands isn't run directly by us, but via flags.Parse()
<Chipaca> niemeyer: it's similar, except Maintenance is only checked in two places (in wait, ie for all async commands, and in cmd_changes)
<pedronis> maybe it's time to think of a cheap way to sit in between go-flags and Execute, we do have some control in addCommand
<pedronis> so we could do something, the question is how cheap/clean that could be
<Chipaca> it's high time we thought about moving on from flags, but that's a longer-term thing
<menace> i have to go, i will come back later...
<Deknos> re
<Deknos> sorry.
<Deknos> i have still time to the next track
<Chipaca> pedronis: ah, i see what you mean, yes
<Deknos> did anyone answer my minikube source recipe question? :>
<Chipaca> Deknos: you were menace a moment ago
<Chipaca> Deknos: the snap author is in TX, it's 7am there, check back in a few hours
<menace> ah, okay, thanks
<Chipaca> menace: is the thing about it being old also true about the edge version?
<menace> Deknos is just an older handle which i used on other network.. because of that i want to use it here now, too
<Deknos> how can i choose the edge channel/version?
<Deknos> i am new to snap =)
<Chipaca> Deknos: ah. Look at 'snap info minikube' to see more
<pedronis> Chipaca: there should be a way to have ExecuteExt  and some wrapping that would expose an Execture calling ExecuteExt
<Chipaca> Deknos: and 'snap install --edge minikube' if you want that
<Chipaca> Deknos: (note edge is typically unstable)
<Chipaca> pedronis: you'd rather this to approach, then?
<Chipaca> should be straightforward, but I'd do it in two steps
<Deknos> how can i check which version is in the snap channel without installing it?
<pedronis> Chipaca: I doubt is straightforward
<Chipaca> Deknos: did you look at 'snap info'
<pedronis> but possible
<Deknos> ah, edge is 0.24.1, but current is 0.28
<pedronis> Chipaca: you need to keep go-flags reflection happy
<Chipaca> pedronis: I have a code axe. Everything is straightforward with enough violence.
<Deknos> then my question still stands :)
<pedronis> Chipaca: said that it still make sense the other path, make warnings state on client
<pedronis> Client
<pedronis> s/path/part/
<Chipaca> pedronis: on client the package, not client.Client?
<Chipaca> mborzecki: suggested the same
<pedronis> Chipaca: ?
<pedronis> Chipaca: like Maintenance so client.Client
<Chipaca> ah, right
<pedronis> not global in client
<Chipaca> pedronis: and have the check be in each command?
<pedronis> please not that
<pedronis> Chipaca: no  have check in Execute wrapping ExecuteExt
<Chipaca> ah
<Chipaca> mmkay
<pedronis> maybe
<pedronis> you need to write
<Chipaca> if we had go 1.7 it'd be super easy
<pedronis> and ssee how it looks
<Chipaca> i can build structs using reflect, there :-)
<pedronis> heh
<Chipaca> metaprogramming \o/
<Chipaca> anyway. I'll go make lunch and think.
<Chipaca> pedronis: thanks
<Chipaca> niemeyer: and you
<niemeyer> o/
<niemeyer> Chipaca: Btw, I think it's easy to wrap around the builder()
<niemeyer> Chipaca: But you probably already figured as muc
<niemeyer> h
<pstolowski> niemeyer: thanks for the review!
<niemeyer> pstolowski: np
 * pstolowski quick lunch
<alexlarsson> jamesh: what is the status of backporting x-d-p in bionic?
<Deknos> (kpom
<Deknos> arg, sry
<cmars> hi menace, the source to minikube is here: https://github.com/cmars/minikube-pkg
<cmars> note the unsupported note there -- microk8s is a far better solution for my needs, uses less resources, so I've dropped it
<cmars> menace: however, if you want to take it over, i'm happy to assign the snap ownership over to you
<Deknos> cmars, well first i want to be sure i am able to do such stuff
<Deknos> i'll look at the repository :) if i am able to, i can maintain it.
<mup> PR snapd#5828 opened: snap-confine: make /lib/modules optional <Created by mvo5> <https://github.com/snapcore/snapd/pull/5828>
<zyga> alexlarsson: while James is probably away now in 18.10 we have 1.0.2-1
<zyga> alexlarsson: not sure if that helps
<alexlarsson> Well, that is kinda expected
<alexlarsson> The issue is about the bionic flatpak ppa
<zyga> I don't know the status of the back porting effort though
<alexlarsson> should i update x-d-p in it
<alexlarsson> I waited with that a bit, but people are starting to complain
<zyga> I don't know
<zyga> perhaps just email James
<alexlarsson> yeah, will do
<Deknos> cmars, do i understand that right that microk8s does not need a virtual machine, but it could be run within a virtualmachine?
<cmars> Deknos: yes, that's correct
<cmars> Deknos: i'm currently running a microk8s cluster in a multipass bionic VM, works great
<Deknos> .. nice. i have windows and macos developers.. and though vagrant/virtualbox works there, minikube is a pain in the ass.. having the local developer kubernetes cluster in a virtual machine with ubuntu would help massively...
<Deknos> nonetheless first i have to look into your minikube repo.
<Deknos> cmars, when you built the last minikube version (0.23) did you build it for ubuntu 16.04 or ubuntu 18.04? because i do not know to see the base dependency in snap for your edge package :)
<cmars> Deknos: i think it was just 16.04
<Deknos> since i am reading your readme and it mentions that libvirt interface was not released with snap... is that still the issue or should i try to convert it to a libvirt interface if i understood the normal packaging and able to recreate it?
<cmars> Deknos: ah, the readme is stale. the libvirt interface landed in snapd, so the KVM driver binary should work with that plug
<cmars> Deknos: so this minikube snap is designed to run minikube on linux.. that's probably not going to work out too well for your windows/macos users
<cmars> Deknos: the minikube snap will use docker-machine-kvm2 to create another VM. a VM in a VM is not great
<pstolowski> https://www.irccloud.com/pastebin/NR6enGKq/
<pstolowski> mvo: ^ re lxd test, that's the issue i'm getting now
<mvo> pstolowski: yeah, thats what I see
<mvo> pstolowski: I pushed a small PR to test this
<mvo> pstolowski: 5828
<cmars> Deknos: https://microk8s.io is probably going to be a better fit for your needs
<Deknos> i know that miniknube snap will not work on windows/macos. but i hate to do the curl-calls. and i suppose, others, too. therefore, if it is really easier than deb packaging  i would want to maintain minikube for snap
<Deknos> microk8s is then another tool for my toolbox. but people already know minikube (on linux)
<cmars> gotcha
<pstolowski> mvo: ah, nice, thanks. i wonder about socket check though
<mvo> pstolowski: the socket check I'm not sure about, it looks like this works (after some time) on master but if there is a nicer way by all means, we should switch to the nicer way
<pstolowski> mvo: okay, i'll see if my change works on older systems
<pstolowski> mvo: you PR passed
<pstolowski> *your
<mvo> pstolowski: yay
<mborzecki> pstolowski: did your PR with fake backend appends land?
<pstolowski> mborzecki: no, because of lxd test failures
<mborzecki> aah
<mup> PR snapcraft#2269 closed: Provider decides on the image <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2269>
<mborzecki> pstolowski: cause i'm running a test with UpdateMany() and then every some runs i get bs data in fakebackend ops
<pstolowski> mborzecki: right.. yeah i hope to land my fix very soon
<pstolowski> zyga: can you ack mvo's #5828 ?
<mup> PR #5828: snap-confine: make /lib/modules optional <Created by mvo5> <https://github.com/snapcore/snapd/pull/5828>
<pstolowski> it's green (it's refreshing to see green after all-day red ;))
<mvo> pstolowski: \o/
<mvo> zyga: I reported the https://github.com/seccomp/libseccomp/issues/129
<mvo> zyga: seccomp issue
<mup> PR snapd#5828 closed: snap-confine: make /lib/modules optional <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5828>
<mborzecki> pstolowski: eh found where the bug was, fakestore is collecting data by snap-id :/
<Chipaca> ok, 'm off to that meeting
<Chipaca> wish me luck :-)
<mborzecki> Chipaca: good luck
<pstolowski> mborzecki: so is it another problem, or the actual problem (and we don't need locking)?
<mborzecki> pedronis: turns out mine was not locking related after all
<mborzecki> pstolowski: ^^
<jdstrand> mborzecki: re https://github.com/seccomp/libseccomp/issues/129> nice report and idea. looking forward to the response
<mborzecki> pstolowski: but caused by map iteration, so randomish hence giving bs results
<pstolowski> mborzecki: k
<pstolowski> mborzecki: i see
<pedronis> mborzecki: multi snap tests are hard in snapstate (or you need to be flexible checking results)
<pedronis> because order is not guaranteed by various pieces not can they
<mborzecki> pedronis: yeah, i was pulling my hair out on this
<mup> PR snapd#5829 opened: tests: use lxd's waitready instead of custom polling around lxd sâ¦ <Created by stolowski> <https://github.com/snapcore/snapd/pull/5829>
<kyrofa> mvo, snapd has some sort of system health check these days, doesn't it? Is this system sane/can it run snaps type thing?
<kyrofa> mvo, is that something an external caller (say, snapcraft) could use?
<mvo> kyrofa: it has a mechanism, yes. its not very sophisticated though. its currently a) kernel version too old b) squashfs mountable c) appamror usable (lxd)
<mvo> kyrofa: its not available via a call currently but that would be trivial to do
<kyrofa> mvo, that would be quite useful. If you point me in the right direction I'd be happy to do it
<mvo> kyrofa: the selftest/ pkg
<mvo> kyrofa: in snapd, you could just wire it to a (hidden) command
<mvo> kyrofa: to a hidden snap command - selftest.Run() error iirc is the external API
<kyrofa> mvo, e.g. snap selftest?
<Deknos> cmars, you forked the docker_machine_kvm repository? is there anything in there which is still not in the repository of dhiltgen?
<kyrofa> mvo, or a new binary not in the standard PATH?
<Deknos> cmars: at least i see no pull from you to him...
<Deknos> bbl
<kyrofa> mvo, I'll work toward `snap selftest`, let me know if you prefer something different
<mvo> kyrofa: thats fine
<mvo> kyrofa: yes, snap selftest and it should error differently when not run as root
<mvo> kyrofa: the mount selftest needs to be root
<menace> re
<menace> cmars, did you answer my docker-machine-kvm repo question? had to reboot because of bios update
<cmars> menace: yes. i think i had a PR into that project, but it may have never landed
<cmars> menace: i think it was something to do with libvirt version compatibility, but it's been awhile.
<cmars> dhiltgen might have since updated docker machine with the reqd changes
<cmars> gotta go afk for now
<menace> i will look into it. dhiltgen and others put the project under a new umbrella, but not much activity. thanks for your help
<om26er> Wimpress: hello
<om26er> Wimpress: this needs you review https://github.com/snapcrafters/android-studio/pull/28 -- Its inspired by your prior work on sublime-text
<mup> PR snapcrafters/android-studio#28: Embed autodownloads <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/28>
<ogra> wowzer !
<ogra> so accidentially not adding CONFIG_DEBUG_INFO=n to a kernel snap build actually results in an 1GB kernel snap
<ogra> ppisati, ^^^ couldnt we make that a default so that you need to add CONFIG_DEBUG_INFO=y if you explicitly want debug info built in ?
<ogra> (took me a while to find out why ubuntu-image and dd suddenly started taking so long :P )
<mup> PR snapd#5817 closed: snapstate/tests: serialize all appends in fake backend <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5817>
<mup> PR snapcraft#2270 opened: catkin, rosdep: stop using FileNotFoundErrors <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2270>
<mup> PR snapcraft#2271 opened: reporting: fail gracefully on submit errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2271>
<bedna> hello all, please add support to snapd for systemd free distros, thanks.
<popey> bedna: hello. which distros in particular?
<popey> We have had a request for one, I wondered if your request was for the same or another.
<bedna> popey, antiX
<popey> Thanks
<bedna> popey, same?
<popey> no
<popey> I'd not heard of antix before now.
<bedna> popey, antiX is same as MX Linux, but MX Linux more userfriendly
<bedna> popey, users from MX Linux have same problem. MX Linux on Distrowatch have 3th position in last month https://distrowatch.com/dwres.php?resource=popularity
<popey> Distrowatch is a measure of distributions with poor SEO, not a measure of users :)
<bedna> popey, OK, but what is better?
<popey> Steam survey, wikimedia foundation, netcraft survey etc.
<popey> I'm not saying MX Linux is bad. :). Just that distrowatch isn't a measure of a distribution's popularity.
<bedna> popey, OK
<pedronis> seems we have a test not mocking and actually writing to $HOME/snap/snapname
<mup> PR snapcraft#2272 opened: meta: friendlier message for incorrect app command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2272>
<NickZ> doot doot
#snappy 2018-09-14
<mborzecki> morning
<zyga> Hey hey
<zyga> Janek just got on the bus to school
<zyga> His âfirstâ rainy morning
<zyga> bedna: hello
<zyga> bedna: it may be possible to add support for snaps that don't use services
<zyga> bedna: but I think services would be extremely difficult to support, in general
<mborzecki> FYI seems like apparmor userspace will land in community arch repo, it's in community-testing atm
<zyga> mborzecki: question about https://github.com/snapcore/snapd/pull/5378/files
<mup> PR #5378: dirs: improve identification of Arch Linux like systems <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5378>
<zyga> does arch set ID_LIKE=archlinux
<mborzecki> zyga: yes
<zyga> ah, ok
<mborzecki> antergos was off on this
<mborzecki> don't remember what manjaro does
<mborzecki> or maybe we had explicit check for manjaro?
<zyga> I don't know either
<zyga> I wonder if anyone wants to review https://github.com/snapcore/snapd/pull/5802
<mup> PR #5802: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/5802>
<mborzecki> zyga: i did already :)
<zyga> I know :)
<zyga> thank you :)
<mborzecki> mvo if off today
<zyga> ooh right
<mborzecki> maybe john/pawel
<mborzecki> idk about pedronis, whether he's off too
<zyga> I think chipaca should review it as we need to discuss how to merge it to osutils
<zyga> I actually could get a day off too
<zyga> to prepare for the trip,
<mborzecki> ok
<zyga> I need to buy a SSD
<zyga> to fit into the bracket mvo is packing
<zyga> ...
<zyga> I will remind mvo just in case
<mborzecki> i think i'll take a day or 2 swap days afer the trip to make up for the half-weekends, it's the only time you can actually do anything takign more than 1h
<zyga> yeah
<mborzecki> and there's a sports event at school on tue which i'll miss :/
<mup> PR snapd#5830 opened: packaging/arch: sync packaging with AUR <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5830>
<mborzecki> zyga ^^
<zyga> thanks
<mborzecki> hm we seem to have explicit checks for arch, manjaro and antergos https://github.com/snapcore/snapd/blob/master/dirs/dirs.go#L200
<zyga> indeed
<zyga> that's why I asked
<zyga> because that code uses DistroLike
<zyga> and the condition changed
<mborzecki> zyga: but DistroLike looks at ID as well
<zyga> mhm
<mborzecki> iirc it's ID == this || in list of ID_LIKE
<zyga> correct
<mborzecki> yup, it's 	if ReleaseInfo.ID == distro || strutil.ListContains(ReleaseInfo.IDLike, distro)
<mborzecki> arch works for us either way, and so does the rest
<mborzecki> eli's PR has landed, so antergos in should end up with ID_LIKE=arch too
<jamesh> zyga: I managed to get some spread tests for user mode systemd daemons that works on all but three distros under spread
<zyga> jamesh: hey, that's great!
<zyga> which three are problematic?
<jamesh> zyga: it turns out "systemctl start user@$UID.service" does the trick provided you've got a new enough systemd
<jamesh> to get the user instance running
<mborzecki> heh nice
<mborzecki> jamesh: and then systemctl --user for that user works?
<jamesh> mborzecki: yes, provided you run it with the correct UID and have XDG_RUNTIME_DIR set
<mborzecki> nice
<jamesh> (the latter so it can find the user insrtance socket)
<mborzecki> mhm
<pstolowski> morning
<zyga> good morning
<zyga> all set for the trip?
 * zyga afk for a sec
<mborzecki> pstolowski: hey hey
<pstolowski> Mount snap "test-snapd-control-consumer" (2) ([start var-lib-snapd-snap-test\x2dsnapd\x2dcontrol\x2dconsumer-2.mount] failed with exit status 1: Job for var-lib-snapd-snap-test\x2dsnapd\x2dcontrol\x2dconsumer-2.mount failed
<pstolowski> again in the spread tests, grr
<mborzecki> heh
<mborzecki> maybe we could do some brainstorming about that while at the sprint
<pstolowski> i wish we had a short sprint focused on stabilization of the tests
<zyga> I think we should land https://github.com/snapcore/snapd/pull/5807
<mup> PR #5807: interfaces: extra argument for static attrs in NewConnectedPlug/NewConnectedSlot <Created by stolowski> <https://github.com/snapcore/snapd/pull/5807>
<mborzecki> yeah, good idea, touches many files, easy to get into conflicts with other code
<mup> PR snapd#5830 closed: packaging/arch: sync packaging with AUR <Simple> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5830>
<pedronis> I see, thre is some test(s) in cmd/snap tests that leaves behind ~/snap/snapname for real
<pstolowski> zyga, mborzecki can you take a look at this trivial https://github.com/snapcore/snapd/pull/5829?
<mup> PR #5829: tests: use lxd's waitready instead of polling lxd socket <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5829>
<mborzecki> looking
<pstolowski> zyga: thanks, will fix the newline
<pstolowski> now
<mborzecki> pstolowski: do you know if wait_ready is in lxd stable too?
<pstolowski> mborzecki: i've just installed lxd on my 18.04, it's still a deb version and it has it if that means anything?
 * zyga tries to recall how to use quilt 
<zyga> I have a patch for qt for the statx issue
<zyga> but man,... packaging
<mborzecki> pstolowski: thanks, just curious, in case we use lxd from stable in some test and need it
<Chipaca> zyga: whoa, qt easier to patch than the rest of it?
<pstolowski> mborzecki: ah, i misunderstood your questions; you meant channels
<pstolowski> mborzecki: let me check
<zyga> Chipaca: yes
<zyga> Chipaca: though we're progressing on the "rest of it" aspect
<Chipaca> zyga: whoa
<Chipaca> zyga: is this going to work for thresh, though? I thought they were using qt from a ppa
<zyga> nope
<zyga> but it's a low hanging fruit
<Chipaca> one of your five-a-day!
<pstolowski> mborzecki: yes, lxd from stable channel supports waitready
<mborzecki> pstolowski: thx
<thresh> :)
<om26er> How do you "unrelease" a snap ? We have a snap whose "beta" channel have a very old version and we currently don't want to expose a new revision to the users in the beta channel. How do we remove that ?
<zyga> close the channel
<om26er> zyga: super, I was looking for `snapcraft unrelease`, didn't know there was a `close` command.
<mborzecki> hm snapstate tests should be run with -count=10 and some random sleep between ootb
<om26er> So now we need parallel installs because our crossbar snap has two variants (cpy3 vs pypy) and would be cool to have both installed at the same time, instead of having different snap names.
<zyga> mborzecki: because raciness?
<zyga> om26er: it's coming :)
<mborzecki> zyga: or some crazy map iteration thing
<zyga> hmmm
<zyga> building qt on one core out of 8
<zyga> :/
<zyga> well
<zyga> at less I'll get my debdiff
<mborzecki> zyga: parallel builds explicitly disabled or you forgot a switch?
<zyga> I don't know
<zyga> it's not default
<zyga> so maybe there's some switch
<zyga> but meh :/
<zyga> crappy defaults
<zyga> mborzecki: ha
<zyga> I was -j16
<zyga> but I need more ram
<zyga> c++
 * zyga adds more ram to the VM
<mborzecki> hahaha
<pstolowski> noo i shouldn't have touched these newlines, now travis hates me again
<zyga> the build process crashes because apparently 4GB is insufficient
<mborzecki> zyga: can't you do that in systemd-nspawned chroot?
<zyga> (for compiling, let alone linking)
<zyga> mborzecki: the whole OS is a vm
<zyga> I'm not running natively
<mborzecki> aah you're on mac
<zyga> yeah
<zyga> ok, while this builds I can hack on a laptop
 * Chipaca looks at what he's wrought so far, and goes for more coffee
 * Chipaca pushes a PR before the coffee
<mup> PR snapd#5831 opened: client, cmd/snap: on !linux, exit when the client tries to Do something <Simple> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5831>
<Chipaca> ^^ if you could give it a look as my next pr would build on it ^^
<zyga> sure
 * zyga figured out a way to update seccomp filters on the fly
<zyga> Chipaca: done
<Chipaca> zyga: getting some good feedback from pedronis also
<Chipaca> thank you
<mup> PR snapd#5807 closed: interfaces: extra argument for static attrs in NewConnectedPlug/NewConnectedSlot <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5807>
<mup> PR snapd#5762 closed: ifacestate: don't initialize udev monitor until we have a system snap <Hotplug> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5762>
<Chipaca> zyga: pstolowski: (pedronis): I changed the approach in that simple PR; it's a lot nicer now
<pstolowski> Chipaca: k, looking
<pstolowski> Chipaca: ah, runtime check, that's much nicer indeed
<pstolowski> +1 once again
<Chipaca> pstolowski: thanks!
<Chipaca> https://mobile.twitter.com/Caged/status/1039937162769096704
<pstolowski> lol, so true
<Chipaca> if you have a struct { client *client.Client }, that just holds the client and nothing else, what would you call it? clientHolder?
<Chipaca> yeOldeClientBag?
<Chipaca> clientHolder sounds like something that'd have a clientHold method
<zyga> Chipaca: store
<zyga> Chipaca: ;)
<zyga> or guard
<zyga> it just holds the client
<pstolowski> clientContainer
<zyga> Chipaca: maybe if you tell us why you want that
<zyga> is it a proxy?
<zyga> client future?
<Chipaca> zyga: a mixin
<Chipaca> to be embedded in any cmdFoo that needs a client
<zyga> ClientIncluded5PercentOffBuyNow
 * zyga stops being silly
 * Chipaca throws plushies at zyga
<pstolowski> clientWrapper
<Chipaca> i like clientContainer best, so far
<zyga> type interface Clienter { Client() *Client }
<pstolowski> Chipaca: 5% interest rate if you make any profit of it
<Chipaca> pstolowski: ok
<zyga> Chipaca: how about just clientMixin?
<Chipaca> zyga: that might be clearer overall
<Chipaca> and cheaper also
<pstolowski> #5829 anyone? trivial and needs 2nd review
<mup> PR #5829: tests: use lxd's waitready instead of polling lxd socket <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5829>
<zyga> me
<zyga> +1
<pstolowski> thx
<mup> PR snapd#5829 closed: tests: use lxd's waitready instead of polling lxd socket <Simple> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5829>
<zyga> Chipaca: do you think you will have time to look at the trespassing fix PR
<Chipaca> zyga: I don't think I'll have time today unless it's urgent
<Chipaca> zyga: which is the pr?
<zyga> one sec
<zyga> https://github.com/snapcore/snapd/pull/5802
<mup> PR #5802: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/5802>
 * zyga -> coffee
<mup> PR snapd#5826 closed: tests: refactor for nested suite and tests fixed <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5826>
<pstolowski> Chipaca: #5831 can old, or are you still tinkering with it?
<mup> PR #5831: client, cmd/snap: on !linux, exit when the client tries to Do something <Simple> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5831>
<Chipaca> green already?
<Chipaca> greyback: purple now :-)
<mup> PR snapd#5831 closed: client, cmd/snap: on !linux, exit when the client tries to Do something <Simple> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5831>
<pstolowski> wow, the day of landings today
 * Chipaca -> lunch and such
<zyga> pstolowski: before a day of takeoffs :)
<pstolowski> indeed ;)
<mup> PR snapd#5832 opened: [RFC] overlord/{snapstate,assertstate}: parallel instances and refresh validation <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5832>
<mborzecki> pedronis: ^^ i was totally unfamiliar with this area, hopefully didn't do anything stupid there
<mup> PR snapcraft#2218 closed: yaml: replace yaml.safe_load() with CSafeLoader <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2218>
<mborzecki> off to pick up the kids
<mup> PR snapcraft#2271 closed: reporting: fail gracefully on submit errors <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2271>
<mup> PR snapd#5833 opened: asserts,interfaces/policy: add support for on-store/on-brand/on-model plug/slut rule constraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/5833>
<mup> PR snapcraft#2270 closed: catkin, rosdep: stop using FileNotFoundErrors <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2270>
<mborzecki> re
<mborzecki> opesuse mirrors returning empty responses again :/
<Son_Goku> mborzecki, this is why I use the openSUSE metalink instead of the redirector URL
<Son_Goku> unfortunately, I'm not sure how well zypper supports the metalink (I use dnf with openSUSE nowadays...)
<zyga> I think we're just complaining when distribution archive is not working
<zyga> regardless of why
<Son_Goku> the redirector is kind of dumb
<Son_Goku> and because it only passes one URL, the package manager can't fall back to another mirror easily
<Son_Goku> whereas when using the metalink, it can actually do that
<Son_Goku> I think I recently saw some commits go into libzypp about metadata download handling, which makes me think it might have been broken before :/
<mborzecki> hm
<mborzecki> hopefully it'll be fixed soon
<mborzecki> and then we'll complain again in a month or so :)
<Son_Goku> haha
<mborzecki> didn't know dnf was supported in opensuse
<Son_Goku> DNF is available in openSUSE since Leap 15.0
<mborzecki> nice
<mborzecki> Son_Goku: btw. do you remember that other package manager in fedora that happnend sort of between yum and dnf time wise, iirc it was written in c
<pedronis> mborzecki: I saw your RFC PR, not sure I will get to it today
<mborzecki> pedronis: no worries, we can do it next week
<Son_Goku> mborzecki: you're talking about zif
<Son_Goku> mborzecki: https://github.com/hughsie/zif
<mborzecki> Son_Goku: ah zif right, is it dead?
<Son_Goku> it became hawkey, which is now libdnf
<mborzecki> oh it is
<Son_Goku> microdnf is another lightweight C implementation of DNF: https://github.com/rpm-software-management/microdnf
<Son_Goku> mborzecki, VMware wrote their own C implementation of DNF called "tdnf" for VMware Photon, but it's kind of broken :(
<zyga> mborzecki: standup
<pedronis> pstolowski: did you land your changes to NewConnectedPlug/Slot ?
<mup> PR snapd#5834 opened: cmd/snap: commands no longer build their own client <Created by chipaca> <https://github.com/snapcore/snapd/pull/5834>
<Chipaca> ^^ very long :-( but repetitive :-) pure refactor PR I'll be basing snap warnings on
<pstolowski> pedronis: yes
<pedronis> ok, makes sense, I need to fix my PR
<zyga> man, that's really long
<mup> PR snapcraft#2273 opened: build providers: use the best CPU configuration <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2273>
<mup> PR snapcraft#2274 opened: snap: use a newer PyYAML and drop patches <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2274>
<mup> PR snapcraft#2272 closed: meta: friendlier message for incorrect app command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2272>
<kyrofa> Trevinho, you around?
<mup> PR snapcraft#2275 opened: build providers: use the provider if exported <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2275>
<kyrofa> kenvandine, Trevinho finally figured out how to reliably trigger that odd "firefox windows show up under slack icon" issue
<kyrofa> kenvandine, Trevinho close Firefox. Open slack snap. Click a link in slack, which fires up Firefox. Notice Firefox now shows up under the slack icon, not Firefox
<kenvandine> oh
<kyrofa> Might be xdg-open-related
<kyrofa> If firefox was already running before clicking the link in slack, it works as expected
<kenvandine> kyrofa, maybe something leaking in the env?
<kenvandine> jdstrand, could you please ack the dbus slot for gnome-calendar so I can get the strict snap into the edge channel?
<jdstrand> kenvandine: I thought I did that before. I'll take a look
<kenvandine> jdstrand, that was gnome-contacts :)
<kenvandine> getting them both confined this week
<kenvandine> jdstrand, and i just requested auto-connect for gnome-calendar as well
<jdstrand> kenvandine: done. it's going through automated review now
<kenvandine> jdstrand, thanks!
#snappy 2018-09-15
<mup> PR snapcraft#2274 closed: snap: use a newer PyYAML and drop patches <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2274>
<mup> PR snapcraft#2268 closed: sanity checks: allow snap/local dir <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2268>
<mup> PR snapcraft#2276 opened: spread: move legacy wiki tests to spread <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2276>
<mup> PR snapcraft#2273 closed: build providers: use the best CPU configuration <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2273>
#snappy 2018-09-16
<mup> PR snapcraft#2275 closed: build providers: use the provider if exported <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2275>
<mispp> does anyone here know if "base: core18" is now available on snapcraft.io?
#snappy 2019-09-09
<mup> PR snapd#7427 opened: tests/overlord/snapstate: refactor for cleaner test failures <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7427>
<mup> PR snapd#7428 opened: systemd, wrappers/services: add helpers for disabling multiple services in a snap <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7428>
<mup> PR snapd#7429 opened: wrappers/services: add CurrentSnapServiceStates + unit tests <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7429>
<mup> PR snapd#7430 opened: [RFC] overlord/snapstate: set snap-setup-task for first task in change <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7430>
<mup> PR snapd#7431 opened: overlord/snapstate: don't re-enable and start disabled services on refresh, etc <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7431>
<mborzecki> morning
<mborzecki> mvo: morning
<mup> PR snapd#7427 closed: tests/overlord/snapstate: refactor for cleaner test failures <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7427>
<pstolowski> morning
<mvo> hey pstolowski
<mborzecki> pstolowski: hey
<mborzecki> nice, thunderstorm at 9am :/
<pstolowski> mhm. quiet here but very cloudy and raining
<mborzecki> pstolowski: it's finished now
<mborzecki> pstolowski: < 10 minutes total, heh
<zyga> hey
<zyga> oh boy
<zyga> I was in #snapcraft
<zyga> complaining that there is nobody there
<zyga> and it's a quiet day :D
<zyga> how are you guys?
<zyga> mborzecki, pstolowski: really? it's sunny and almost 20 here
<mvo> zyga: hey, good morning. good, good, but it sounds like you need a cup of coffee :)
<zyga> mvo: haha :)
<zyga> I guess so
<zyga> I'm reviewing channels PR
<zyga> mvo: I was on a bike ride already, should be more awake
<mborzecki> zyga: the front is moving NW, so enjoy your weather
<mborzecki> zyga: about that, this is what poland looked like on 03.09 https://www.wykop.pl/cdn/c3201142/comment_I9dTRiDkK6k1pkTXd1VyOL7XMeNwQ8PD.jpg
<zyga> mborzecki: looks like cake
<mborzecki> zyga: mhm, the bottom screen capture is from Lodz afaik
<zyga> mborzecki: polska A i polska B ;-)
<zyga> I should make that coffee
<zyga> it was surprising because mvo didn't join #snapcraft
<zyga> but was doing reviews
<zyga> so I was thinking there's an IRC split
<mborzecki> zyga: conflicts in https://github.com/snapcore/snapd/pull/7421
<mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
<ackk> zyga, hi, do you know why doing something https://github.com/maas/maas/blob/master/Makefile#L770-L784 would break a try'd snap?
<ackk> zyga,  I ran that and now I get
<ackk> $ maas
<ackk> execv failed: No such file or directory
<Chipaca> ackk: are you running the maas binary you think you are running?
<mvo> Chipaca: do you think you could have a look at https://github.com/snapcore/spread/pull/69 ? should be easy but I want it to be as good as possible before giving it to Gustavo
<mup> PR spread#69: Manage pagination retrieving images from google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/69>
<Chipaca> mvo: I do think I could
<mvo> Chipaca: thank you!
<mvo> Chipaca: (I hope this means you will actually do it and not just think about it ;) I guess I phrased my question a bit too vague)
<Chipaca> :-p
<Chipaca> maybe it was just the right amount of vague
<mvo> heh
<zyga> Trevinho: hello
<zyga> Trevinho: I got a note that you experienced an interesting failure on your system last week
<zyga> mborzecki: hey
<zyga> I noticed yo talked to Trevinho last week
<mborzecki> zyga: hm?
<zyga> quick question:
<zyga> the "mount core" task failed
<zyga> the log has
<zyga> Mount snap "core" (7396)
<zyga> 2019-09-05T20:09:11+02:00 ERROR remove /snap/core/7396: device or resource busy
<zyga> does this seem to imply to you that succeeded on the DO path
<zyga> something later failed
<zyga> and then we went to UNDO
<zyga> and this is when this failed?
<mborzecki> zyga: i think Trevinho posted snap change for that refresh, and indeed it was undoing something
<mborzecki> zyga: let me check my history
<zyga> Hold    today at 17:13 CEST  today at 20:08 CEST  Remove snap "core" (7169) from the system
<zyga> this is what seems to have failed
<zyga> and then we got the other error
<zyga> because the new core was already used by something else
<zyga> or by some scanning utility that held open file descriptors to core
<zyga> so the question is: do you think that it was the undo path that failed?
<mborzecki> zyga: this is the snap change output https://pastebin.ubuntu.com/p/Yhy3hxGG8b/
<zyga> mborzecki: yes, I have that
<mborzecki> zyga: hard to tell from the log, but i think the problem was 2019-09-05T19:38:54+02:00 ERROR cannot remove snap file "core", will retry in 3 mins: remove /snap/core/7169: device or resource busy
<mborzecki> zyga:  then it went with undo
<mborzecki> zyga:  and then errored out in undo of setup-snap, which got logged with default case handler in taskrunner
<zyga> mmm
<zyga> mhm
<zyga> mborzecki: I've made a patch for that
<ackk> Chipaca, wdym? I get the same error by running /snap/bin/maas, if that's what you mean
<Chipaca> ackk: ah, good. Ok. What happens if you 'snap run --trace maas'?
<Chipaca> strace*
<ackk> $ snap run --strace maas
<ackk> error: exit status 1
<ackk> Chipaca, ^
<mup> PR snapd#7432 opened: boot,dirs,image: introduce boot.MakeBootable, use it in image instead of ad hoc code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7432>
<ackk> Chipaca, fwiw the same happens with the maas service, it fails to start with "file not found"
<zyga> mborzecki, mvo: https://github.com/snapcore/snapd/pull/7433
<mup> PR #7433: systemd: detach rather than unmount .mount units <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7433>
<mup> PR snapd#7433 opened: systemd: detach rather than unmount .mount units <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7433>
<Chipaca> ackk: what does snap pack --check-skeleton of the prime directory say, if anything?
<Chipaca> i think 'snap try' already does that but just in case
<ackk> Chipaca, nothing
<Chipaca> ackk: if that check passes, that means the binary itself that the app points to exists. As that's probably a shell wrapper, look at it and see what it calls
<Chipaca> ackk: or
<Chipaca> ackk: tell you what, if it is a wrapper, add "set -x" to the top of it :-)
<Chipaca> ackk: and see which command it is that fails
<ackk> Chipaca, execv failed: No such file or directory
<pedronis> Chipaca: hi, could you review #7425, #7411 and #7197 (they are already marked for you, there's a couple more but they either need more work or are descendant from those)
<ackk> Chipaca, I put a -x on the snapcraft wrapper
<mup> PR #7425: channel: introduce Resolve and ResolveLocked <Created by pedronis> <https://github.com/snapcore/snapd/pull/7425>
<mup> PR #7411: cmd/model: output tweaks, add'l tests <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7411>
<mup> PR #7197: usersession: track connections to session agent for exit on idle and peer credential checks <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7197>
<ackk> but it's not even run
<Chipaca> pedronis: will do
<Chipaca> pedronis: thanks
<Chipaca> ackk: how can i reproduce this?
<ackk> Chipaca, I guess by fetching the maas code, building the snap and using snap try
<Chipaca> ackk: if you pack the snap, does it still break in this way?
<ackk> Chipaca, I've run into this a lot of times in the past, recently thought it got fixed since I wasn't seeing it anymore
<ackk> Chipaca, well if I remove and reinstall it even with try it gets fixed
<ackk> Chipaca, it's not a snap filesystem issue for sure
<ackk> Chipaca, if it matters I'm running it in a container, with bind-mounted home
<ackk> Chipaca, so I can't really try a packed snap, because of the snapfuse issue...
<Chipaca> ackk: what happens if you disable and then enable the maas snap?
<ackk> Chipaca, starts working again it seems
<Chipaca> ackk: does maas use layouts or content?
<ackk> Chipaca, no
<Chipaca> content interface*
<Chipaca> ackk: it looks like the rsync somehow breaks the mount but not sure how
<Chipaca> ackk: unless â¦
<Chipaca> ackk: as well as doing that series of rsyncs you linked to, do you also somehow re-create the 'prime' directory?
<ackk> Chipaca, no, just that rsync
<Chipaca> hm
<ackk> I run 'make sync-dev-snap' and that's it
<ackk> (and snap restart maas)
<Chipaca> ackk: would be interesting to look at 'findmnt' (maybe 'findmnt -D') for when it works vs when it doesn't
<ackk> Chipaca, ok, lemme see if it happens again
<ackk> I have the one when it works
<ackk> Chipaca, of course now I ran sync like 30 times and it doesn't happen ;/
<Chipaca> :-)
 * Chipaca takes a break
<pstolowski> ogra: hey, any thoughts on https://bugs.launchpad.net/snapd/+bug/1843077 ? not sure it belongs to snapd, probably somewhere else (core?)
<mup> Bug #1843077: Data corruption when UC is not powered down cleanly  <snapd:New> <https://launchpad.net/bugs/1843077>
<mvo> zyga: oh, nice one!
<mborzecki> zyga: updated #7419
<mup> PR #7419: cmd/snap-confine: add unit tests for sc_invocation, cleanup memory leaks in tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7419>
<mborzecki> pstolowski:  can you take a look at that PR too? ^^
<ogra> pstolowski, the bug is way to vague ... "doesnt boot" ... :P ... (what did cause it exactly ... whats the actual error they see then etc etc) ... you can indeed tune some settings like having dirty pages flushed more often to disk and such but thats typically coming at a cost for other (generic) use-cases ... and it also only minimizes the risk. i'm not sure there is much that can be done about the journal
<ogra> oh ... and on a sidenote ... i'm officially on vacation (til 23rd) ;)
<ogra> (and "other filesystems" is a foundations question ;) )
<ogra> i only do run two flash based boards over here ... (the others from SD) ... neither of them has ever shown such a behaviour
<ogra> (hmm ... both on core 16 though ... thats perhaps a datapoint)
<pstolowski> mborzecki: i'll
<mborzecki> pstolowski: thx!
<pstolowski> ogra: i see, thanks, and sorry for disturbing! enjoy your vacation!
<zyga> mborzecki: looking
<ogra> pstolowski, i wouldnt need to answer, all fine you didnt disturb  ;)
<mvo> a second review for 7432 would be great, should be super straightforward
 * pstolowski lucnh
 * pstolowski lunch
 * zyga debugs something
<zyga> mvo: sorry for not doing more reviews :/
<mvo> zyga: no worries
<mup> PR snapd#7426 closed: cmd/snap-update-ns: clarify sharing comment <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7426>
<mup> PR snapd#7434 opened: seed/seedwriter:  implement WriteMeta and tree16 corresponding code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7434>
<Chipaca> pedronis: in #7425, why 'locked' instead of 'pinned'? seems confusing
<mup> PR #7425: channel: introduce Resolve and ResolveLocked <Created by pedronis> <https://github.com/snapcore/snapd/pull/7425>
<pedronis> Chipaca: because in Toronto we discussed we don't want to use pinned, I'm exploring other options
<pedronis> we'll have some clarity hopefully in Paris
<Chipaca> I thought it was going to be like progress.NewTaskProgressAdapterLocked
<Chipaca> it's the toronto water, it clogs the brain
<cmatsuoka> mborzecki: I patched snap-image to work with recovery, but there was an inconsistency in the way the utility was handling file copying so I had to change it a little bit
<mborzecki> cmatsuoka: cool, are the changes in your branch?
<cmatsuoka> mborzecki: not yet, still working on that
<mborzecki> cmatsuoka: ok, ping me when you push it, i'll take a look, perpahs somethins that could be fix in the RFC PR
<cmatsuoka> mborzecki: the main problem was related to how file organization is always used (source/target with different paths)
<cmatsuoka> mborzecki: I couldn't use the standard Write() methods to get files from the gadget to the prepared area, and then from prepared to the final image, because it would want to organize files twice
<cmatsuoka> mborzecki: and I also can't copy from gadget to image and prepared area to image in two different passes, because the writer was designed to do it in a single pass
<cmatsuoka> mborzecki: so I added an extra parameter to Write() to tell if file organization is to be used or not
<mborzecki> cmatsuoka: so you used Write() to some staging location and then Write() again from the staging to actual destination?
<pstolowski> re
<cmatsuoka> mborzecki: I tried numerous approaches and that seemed to be the one that didn't require major rewrites, but if you have any better idea I'll gladly accept it
<cmatsuoka> mborzecki: my first attempt was to copy from gadget to image in addition to the regular copy, but the writer wants to create the image from staging in a single pass
<pedronis> cmatsuoka: what is the prepared area, why do you need two places/copies?
<pedronis> is actually not super clear
<cmatsuoka> pedronis: the "prepared area" is the directory written by snap prepare-image. snap image get bits from there, and bits directly from the gadget
<cmatsuoka> pedronis: however, ubuntu-seed needs data from both at the same time (recovery from prepare-image, bootloader from gadget)
<cmatsuoka> pedronis: because prepare-image doesn't add content files
<mborzecki> cachio: https://paste.ubuntu.com/p/3pJzxxVT45/ so far we assumed it's only on arch?
<cachio> mborzecki, yes
<pedronis> cmatsuoka:  but we are not going to call prepare-image at runtime
<cmatsuoka> pedronis: yes, but that's for the initial image generation
<cachio> mborzecki, all the failures which I saw were on arch
<pedronis> cmatsuoka: there is no strict reason btw not to move things from prepare-image to just snap-image if it makes sense
<pedronis> cmatsuoka: also I just encapsulated the relevant code I think, the one that does gadget bits in prepare-image
<pedronis> cmatsuoka: you should probably read https://github.com/snapcore/snapd/pull/7432
<mup> PR #7432: boot,dirs,image: introduce boot.MakeBootable, use it in image instead of ad hoc code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7432>
<cmatsuoka> pedronis: I'll check that, thanks
<pedronis> cmatsuoka: to be clear, we haven't yet exactly decided what prepare-image/ubuntu-image do for core 20 images
<pedronis> if doing less or doing more is more convenient we ca tweak/decide
<cmatsuoka> pedronis: yes, the snap-image investigation made me understand the issues there to see what kind of tweaks could be useful
<mup> PR snapd#7435 opened: tests: explicitly restore after using LXD <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7435>
<ijohnson> good morning y'all
<zyga> hey ijohnson :)
<ijohnson> hey zyga o/
<zyga> WAT? https://www.irccloud.com/pastebin/rRkpecF0/
<ijohnson> pedronis: so from your comment, is #7428 unnecessary then? should I close that PR or might it still be useful to have those methods for a different use case
<mup> PR #7428: systemd, wrappers/services: add helpers for disabling multiple services in a snap <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7428>
<pedronis> ijohnson: we tend not to add unused helpers, it code base is big/sometimes confusing enough :)
<pedronis> s/it code/the code/
<ijohnson> ack, I'll close the PR then
<mup> PR snapd#7428 closed: systemd, wrappers/services: add helpers for disabling multiple services in a snap <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7428>
<zyga> ah, my bad
<zyga> local bug
<mup> PR snapd#7436 opened: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/7436>
<mup> PR snapcraft#2702 closed: Release changelog for 3.8 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2702>
 * zyga wants to go for lunch, ttyl
<mborzecki> pstolowski: noticed a little bug with unset, it's possible to unset an option that is not supported by core/system and otherwise would raise an error when tried with snap set
<pstolowski> mborzecki: uh, nice catch, thank you! will fix
<mup> PR snapd#7395 closed: cmd/snap-confine: apply global mount namespace initialization for confined and classic snaps <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7395>
<mborzecki> wow, some heavy rain here
<mup> PR snapd#7432 closed: boot,dirs,image: introduce boot.MakeBootable, use it in image instead of ad hoc code <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7432>
<mup> PR snapd#7419 closed: cmd/snap-confine: add unit tests for sc_invocation, cleanup memory leaks in tests <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7419>
<ijohnson> grr regex... am I missing something obvious here? https://pastebin.ubuntu.com/p/rFh2SzQG4z/
<ijohnson> I have a feeling this has something to do with gocheck automatically adding the end of the line marker to the regex in ErrorMatches
<mvo> ijohnson: does it help if you prefix the regexp with ".* "?
<pstolowski> ijohnson: yep, this, and possibly .* at the end. you also have ] there, needs escaping
<ijohnson> ah actually it does if I add .* to the start and then \n.* at the end too
<ijohnson> went with
<ijohnson> 	c.Assert(err, ErrorMatches, ".*is-enabled snap.hello-snap.svc1.service] failed with exit status 1: whoops\n.*")
<ijohnson> pstolowski: I thought I would have to escape ] but it didn't seem to be necessary for some reason
<mvo> second look at https://github.com/snapcore/spread/pull/69 would be great, hopefully good now
<mup> PR spread#69: Manage pagination retrieving images from google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/69>
<pstolowski> ijohnson: interesting, maybe it's smart enough if opening [ is missing; some regex implementations would probably freak out
<ijohnson> yeah true, do you think I should escape it anyways in case go ever changes behavior? seems unlikely I guess
<pstolowski> ijohnson: i'd escape it just to avoid confusion / make it clear
<ijohnson> ack
<Trevinho> zyga: hey, hello... I saw mborzecki said wrote a patch, is that enough or do you need some more debugging data?
<Trevinho> fyi I'm still affected, so... I can test new versions and/or provide more debugging
<Trevinho> I suppose I still won't reboot for a while... Too much precious stuff in my /tmp xD
<zyga> Trevinho: hey, I think one thing might be useful
<zyga> Trevinho: please install lsof and run lsof on the paths that failed
<zyga> Trevinho: like /snap/core/1234 (fix the number)
<zyga> Trevinho: lastly, please report a bug,  this will aid in our tracking and allow us to store such logs easily
<zyga> Trevinho: if you don't want to just say so and I'll report it
<Trevinho> zyga: ok, as per lsof, there's nothing coming for the new version of the core
<zyga> and the old one?
<Trevinho> zyga: https://pastebin.ubuntu.com/p/jdbv6dRS79/
<zyga> Trevinho: is core rev 7270 the one that failed to be removed?
<Trevinho> yep
<Trevinho> my current one
<zyga> Trevinho: understood, thank you
<zyga> Trevinho: let me know about that bug number if you have one
<Trevinho> zyga: I also now tried to close all the app using current snap and it still failed, but without hanging at least...
<Trevinho> https://pastebin.ubuntu.com/p/9H3w9bSgMZ/
<Trevinho> so I suppose that in such case core should not block if removal of an old version failed
<Trevinho> I mean, is that a fatal error? :o
<zyga> Trevinho: what does lsof say now>?
<Trevinho> nothing
<zyga> lsof isn't perfect though, we'll see
<Trevinho> as it wasn't saying anything of the failed-to-remove version before
<Trevinho> yeah, that's the problem
<mup> PR snapd#7437 opened:  wrappers/services.go: add disabled svc list arg to AddSnapServices <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7437>
<Trevinho> zyga: I forgot, what's the command to get debug info from a change?
<zyga> snap changes
<zyga> snap change NNN or snap tasks NNN
 * cachio lunch
<mup> Bug #1843286 opened: Snap failing to remove old core doesn't update and keeps spinnig the CPU <Snappy:New> <https://launchpad.net/bugs/1843286>
<Trevinho> zyga: https://bugs.launchpad.net/snappy/+bug/1843286
<mup> Bug #1843286: Snap failing to remove old core doesn't update and keeps spinnig the CPU <Snappy:New> <https://launchpad.net/bugs/1843286>
<zyga> Trevinho: thank you very much
<zyga> I have the most of lack of luck recently
<mup> PR snapcraft#2707 opened: manifest: sort package and snap lists for consistency <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2707>
<mup> PR snapd#7433 closed: systemd: detach rather than unmount .mount units <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7433>
 * zyga EODs
<rogpeppe> zyga: do you know how i might find out why my ubuntu-core-running raspberry pi is crashing? i'm now running on a not-much-used pi 3 and it's crashing regularly about twice a day (hard crash - it doesn't auto-reboot)
<zyga> rogpeppe: enable persistent journal and look at the logs there; look at the serial output for hints
<zyga> no other ideas from the top of my head
<rogpeppe> zyga: thanks. looks like i can enable persistent journal with `mkdir /var/log/journal`. does that seem right to you?
<zyga> yes
<rogpeppe> zyga: sadly i can't look at serial output. i'm 500 miles away from the actual device now...
<rogpeppe> zyga: i've now enabled persistant journal; hopefully i might see something after the next crash.
<rogpeppe> zyga: BTW the other odd thing is that it only boots up about 50% of the time.
<rogpeppe> zyga: BTW thanks a lot for your interaction on this issue. it's really nice to have some feedback.
<zyga> I'm really happy to help
<zyga> it's hard to help everyone that comes around
<zyga> but it's also genuinely interesting to see what is the cause of this problem
 * ijohnson relocates
<ec0> hi there, observing something interesting with the organize keyword, and wanted to run it by someone. When using this keyword on a part using the 'python' plugin it doesn't seem to do anything? Is this expected behaviour?
<mup> PR snapd#7407 closed: tests: run failing tests on ubuntu eoan due to is now set as unstable <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7407>
<rogpeppe> zyga: FWIW i was ssh'd into the system when i saw this broadcast message:
<rogpeppe> reboot scheduled to update the system
<rogpeppe> The system is going down for reboot at Mon 2019-09-09 19:36:00 UTC!
<rogpeppe> zyga: so perhaps it's not crashing after all, but just automatically rebooting and shutting down and not restarting
<rogpeppe> zyga: why would it be rebooting automatically to update the system?
<rogpeppe> zyga: that certainly might explain why the system is going down so regularly!
<mup> PR snapcraft#2708 opened: tools: make environment-setup container name and image configurable <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2708>
#snappy 2019-09-10
<mborzecki> morning
<zyga> Good morning
<zyga> Iâm doing my school run now. See you all later
<zyga> back now
<zyga> mborzecki: it's cold today
<zyga> 13C at most
<zyga> brrr
<zyga> I hope it won't rain later
<mborzecki> and rainy here
<zyga> mborzecki: still, all the cars are stuck in traffic
<zyga> biking to school is way more robust
<zyga> how are we doing today?
<zyga> tests were awful yesterday
<zyga> failing left and right on random stuff
<zyga> store, portals, you name it
<zyga> good morning mvo
<zyga> a little cold and rainy today :)
<zyga> how was your Monday?
<zyga> quick breakfast
<mvo> hey zyga
<mborzecki> mvo:  hey
<mvo> hey mborzecki
<mup> PR snapd#7425 closed: channel: introduce Resolve and ResolveLocked <Created by pedronis> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7425>
<mborzecki> zyga: can you take another look at #7412 ? looks like we could land it easily
<mup> PR #7412: tests: run dbus-launch inside a systemd unit <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7412>
<zyga> sure
<mvo> looks like we can merge 7342 too?
<mvo> and 7125 needs a second review (should be simple)
<zyga> +1 on 7412
<zyga> mvo, do you want me to mere or do you want to yourself?
<zyga> mvo: +1 on 7342
<mvo> I can do the merge, I just noticed it has no second +1
<zyga> looking at 7125 now
<mup> PR snapd#7412 closed: tests: run dbus-launch inside a systemd unit <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7412>
<mup> PR snapd#7342 closed: fixme: rename ubuntu*architectures to dpkg*architectures <Created by ardaguclu> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7342>
<zyga> mvo: reviewed 7125, +1 but please check my comment there
<mvo> zyga: thanks, looking now
<zyga> thank you
<zyga> mvo, mborzecki: I'd like to ask for a review of https://github.com/snapcore/snapd/pull/7435
<mup> PR #7435: tests: explicitly restore after using LXD <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7435>
<zyga> it's a blocker for progress on https://github.com/snapcore/snapd/pull/7168
<mup> PR #7168: tests: measure testbed for leaking mountinfo entries <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7168>
<zyga> I have one PR slot open so I'll work on finishing and proposing a mount-ns extension that involves a mimic, so that we can properly evaluate https://github.com/snapcore/snapd/pull/7436 later
<mup> PR #7436: many: make per-snap mount namespace MS_SHARED <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7436>
<zyga> mvo: offtopic, last night I was playing with raspberry pi
<zyga> and I think we can slightly improve our watchdog story there
<zyga> specifically around try mode boots
<mvo> zyga: oh? tell me more
<zyga> I read a little about the watchdog on the pi
<zyga> it's a bit weird, has fixed 15 second interval
<zyga> we could enable it from the boot loader
<zyga> so any try mode boot can recover
<zyga> I will poke around in free time over evenings
<zyga> maybe I will reach something that works
<abeato> hey, is anybody experiencing problems with the telegram snap? I've opened https://forum.snapcraft.io/t/telegram-snap-fails-to-start/13132
<zyga> abeato: that's new to me
<zyga> abeato: ls -ld /mnt ?
<abeato> zyga, $ ls -ld /mnt
<abeato> drwxr-xr-x 2 root root 4096 jul 19  2016 /mnt
<zyga> ok, so regular directory, not a symlink
<pstolowski> mornings
<zyga> abeato: can you please check how many files matching "*snap-confine*" glob are present in /etc/apparmor.d/
<abeato> zyga, https://paste.ubuntu.com/p/xt7NyYgPKr/
<zyga> that's that!
<zyga> mvo: ^^^^
<abeato> sep 11?
<zyga> abeato: one of the files is wrong
<zyga> it's a bug in our postinst script I believe
<zyga> mvo: should that be fixed and released?
<abeato> hm, interesting
<zyga> abeato: what does "apt-cache policy snapd" say
<zyga> that will be most useful to mvo
<abeato> zyga, https://paste.ubuntu.com/p/G2JMwHJSJG/
<zyga> abeato: the fix for this bug is in 61cc58dbb0a7a1a785e9e3c391b6f593df892839
<zyga> Date:   Wed Aug 14 09:43:41 2019 +0200
<zyga> it may not be released yet, perhaps
<zyga> mvo: ^ can you confirm if 2.40 has this
<mvo> abeato: yeah, the /etc/apparmor.d/usr.lib.snapd.snap-confine should not be there :(
<mvo> zyga: yeah 2.40 should fix it
<zyga> if you want to fix your system please remove the file mvo mentioned and call sudo apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine.real
<abeato> mvo, zyga snapd journal: https://paste.ubuntu.com/p/wHsRR4R2xD/
<zyga> mvo: in that case the fix doesn't work
<mvo> zyga: oh well
<mvo> zyga: let me look at this again
<zyga> thank you!
<abeato> do you need more data?
<zyga> abeato: can you please update the forum thread with the log from this conversation?
<mborzecki> zyga: can you take a quick look at https://github.com/snapcore/snapd/pull/7109 ? pushed some changes there yday
<mup> PR #7109: snap-confine: fallback gracefully on a cgroup v2 only system <Created by mvo5> <https://github.com/snapcore/snapd/pull/7109>
<mvo> abeato: a bugreport (super small, just the data you already pasted)
<abeato> zyga, sure
<mvo> abeato: then I will do a sledgehammer fix
<zyga> abeato: thank you
<zyga> mborzecki: sure, looking now
<abeato> mvo, launchpad?
<mvo> abeato: plus the content of the /etc/apparmor.d/usr.lib.snapd.snap-confine please
<mvo> abeato: yeah
<abeato> ok
<mvo> abeato: or if its alreaady in the forum thats fine
<mvo> abeato: just need a refrence in the PR
<abeato> it is already in the forum, yes
<abeato> I will update then  the forum post
<mvo> abeato: then that should be fine
<mvo> abeato: thank you!
<abeato> np
<mborzecki> anyone else seen this google:debian-9-64:tests/main/snap-service-watchdog to fail recently?
<mup> PR snapd#7438 opened: devicestate: add support for base->base remodel <Created by mvo5> <https://github.com/snapcore/snapd/pull/7438>
<mborzecki> for soem reason the snap app gets SIGABRT https://paste.ubuntu.com/p/Z6k382RCrD/
<abeato> mvo, zyga https://forum.snapcraft.io/t/telegram-snap-fails-to-start/13132 updated
<mborzecki> this one is interesting https://paste.ubuntu.com/p/kmGzQzZRHJ/ probably something for Chipaca or pedronis
<zyga> store woes?
<mborzecki> idk, nonce is logged in the POST request, so it is sent ;)
<mvo> abeato: could you please pastebin me /var/lib/dpkg/info/ubuntu-core-launcher.conffiles
<mvo> abeato: and snapd.conffile too ?
<abeato> mvo, there is nothing starting as ubuntu-core* in /var/lib/dpkg/info/
<mvo> abeato: uh, sorry, please see if there is "snap-confine.conffiles"
<zyga> mvo: are conffiles retained after a package is removed?
<zyga> mvo: that is, they remain until purged?
<mvo> zyga: yes
<mvo> zyga: correct
<abeato> mvo, that file is not there either
<abeato> mvo, snapd.conffiles exists
<abeato> mvo, https://paste.ubuntu.com/p/pTN8P7Mtt2/ - but note that I already removed the old file and run apparmor_parser to fix the problem
<mvo> abeato: any output from grep usr.lib.snapd.snap-confine /var/lib/dpkg/info/*.conffiles
<mvo>  ?
<abeato> $ grep usr.lib.snapd.snap-confine /var/lib/dpkg/info/*.conffiles
<mvo> abeato: yeah, thats fine - I'm mostly trying to figure out if its still leftover in some dpkg files
<abeato>  /var/lib/dpkg/info/snapd.conffiles:/etc/apparmor.d/usr.lib.snapd.snap-confine.real
<mvo> abeato: thats the only match?
<abeato> mvo, yes
<mvo> abeato: thanks! I'm slightly puzzled but thats fine, I think I know what to do (even though I'm not sure how this happens, i.e. dpkg should either know about the file or it should be gone :/
<abeato> right, it's weird...
<zyga> abeato: did you develop snapd on this machine?
<zyga> perhaps it came from some earlier hacking
<abeato> zyga, no
<zyga> mvo: I need to take a break, back-pain after last evening's longer session
<zyga> I'll stretch and be back in a few moments
<mvo> zyga: sure thing, get well!
<mup> PR snapd#7439 opened: packaging: remove obsolete usr.lib.snapd.snap-confine in postinst <Created by mvo5> <https://github.com/snapcore/snapd/pull/7439>
<mvo> abeato: -^
<abeato> mvo, great!
<mborzecki> zyga: https://forum.snapcraft.io/t/significance-of-info-files-in-run-snapd-ns/12938
<mborzecki> tests are red again :/
<mborzecki> pedronis: hi, i thnk you weren't around when i liked it, interesting failure i stumbled upon today https://paste.ubuntu.com/p/kmGzQzZRHJ/
<mborzecki> s/liked/linked/
<pedronis> mborzecki: weird error given that we see the nonce in the requests log
<mborzecki> mhm
<pedronis> for some reason the nonce the store just gave us is considered invalid
<pedronis> unless if it's repeats worth poking the store people
<pedronis> but we haven't touched anything in that area since a while
<Chipaca> we do send the exact thing we get back
<Chipaca> fwiw
<pedronis> yes
<pedronis> so it's not missing
<Chipaca> this isn't the first time we've seen this error
<Chipaca> i think it's worth chasing down
 * Chipaca gets on it
<mvo> mborzecki: anything changed that make the tests red?
<mborzecki> mvo: no, looks like the usual stuff, desktop portal, occasionally installing snapd deps from package archive or store hiccups
<mvo> :(
<zyga> mborzecki: thank you, replied
<mborzecki> snap/channel/channel_test.go:139:17: undefined: arch.UbuntuArchitecture on master
<mborzecki> opening a pr in a bit
<pedronis> mvo: I did a pass over the 2.42 PRs (except mine), they all need a little bit more work I fear
<pedronis> mborzecki: crossing merges ?
<mborzecki> pedronis: yes
<mvo> pedronis: ok, I have a look, thank you!
<pedronis> mvo: I'll try to tweak the test to check for systemd version in mine when I get a 2nd, worst case it will not make 2.42
<mup> PR snapd#7440 opened: snap/channel: fix unit tests, UbuntuArchitecture -> DpkgArchitecture <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7440>
<mborzecki> also something weird with tests/unit/go on debian, gofmt is not installed (?)
<pedronis> Chipaca: also in #7411 I have two wonderings that maybe you can help with (I @chipaca-ed you on them)
<mup> PR #7411: cmd/model: output tweaks, add'l tests <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7411>
<Chipaca> pedronis: ack
<Chipaca> pedronis: i noticed i didn't notice some of the things you pointed out
<Chipaca> will look in a bit
<pedronis> mvo: your PRs for 2.42 also need 2nd reviews
<rogpeppe> zyga: i wonder if this might have some relevance: Sep 09 19:27:54 localhost snapd[692]: handlers.go:459: Reported install problem for "core18" as f732dba4-d35a-11e9-a660-fa163e6cac46 OOPSID
<zyga> rogpeppe: it means that snapd fails to refresh core18
<zyga> aborts the transaction
<zyga> and rolls back
<zyga> that explains your reboot loop
<zyga> this is very useful information
<rogpeppe> zyga: i'm not seeing a reboot loop currently FWIW
<zyga> mvo: ^ can we pull the log from that error tracker entry?
<zyga> rogpeppe: it will be re-attempted again
<zyga> rogpeppe: until it refreshes successfully
<zyga> that report has hints as to what went wrong
<rogpeppe> zyga: ah, so that's what explains the fact that it's rebooting periodically, i guess
<zyga> yes
<zyga> it's the transactional nature
<zyga> it's just not immune to problems
 * zyga found a bug (in what he was doing since morning)
<rogpeppe> zyga: here's another one: Sep 09 07:40:40 localhost snapd[715]: handlers.go:459: Reported install problem for "core18" as fc12d9b2-d2e7-11e9-b568-fa163e102db1 OOPSID
<mvo> zyga: INFO Waiting for restart...
<mvo> ERROR cannot finish core18 installation, there was a rollback across reboot
<zyga> huh
<zyga> interesting
<zyga> nothing magic
<zyga> rogpeppe: what does snap version say?
<mvo> looks like the restart is not happening, I see a lot of Waiting for resart
<mvo> snapd version is 2.40
<mvo> zyga: https://pastebin.canonical.com/p/WHVwWjRTVs/
<zyga> this is snapd + core18 arrangement, right?
<rogpeppe> zyga:
<rogpeppe> rogpeppe@localhost:~$ snap version
<rogpeppe> snap    2.40
<rogpeppe> snapd   2.40
<rogpeppe> series  16
<rogpeppe> kernel  4.15.0-1041-raspi2
<zyga> rogpeppe: can you run snap changes
<zyga> and pastebin that?
<rogpeppe> zyga: http://paste.ubuntu.com/p/GbtJH9N6vv/
<zyga> how about snap tasks 11
<zyga> and snap tasks 13
<rogpeppe> zyga: ?
<zyga> run the command: snap tasks 11
<zyga> and pastebin the output please
<rogpeppe> zyga: http://paste.ubuntu.com/p/CnjtBWwrtr/
<zyga> oh
<zyga> Error   yesterday at 19:25 UTC  yesterday at 19:27 UTC  Automatically connect eligible plugs and slots of snap "core18"
<zyga> it failed on auto-connect?!
<mborzecki> off to school to pick up the kids, afk for a bit
<zyga> pstolowski: ^ can auto-connect prevent a reboot?
<rogpeppe> zyga: this is task 13: http://paste.ubuntu.com/p/SvvXP7rP5R/
<zyga> same thing happened here
<zyga> I think we're getting somewhere now
 * Chipaca takes a break
<pstolowski> zyga: as any other task handler that errors out and triggers undo. it's implemented to retry on conflicts (which it did a couple of times in that log), but then there is a bunch of things it looks up in the state that can error out. slightly weird we don't see what the error was for this task
<zyga> pstolowski: we can presumably ask rogpeppe for the state file
<zyga> do you think it would help
<pstolowski> yes it might help, maybe we will be able to track down what changed in the state that made task error out
<zyga> rogpeppe: can you please report a bug on bugs.launchpad.net/snapd
<zyga> rogpeppe: include a rough description of the problem how you see it
<pstolowski> rogpeppe: so yes, if you can grab and send us state.json that would be great (don't pastebin as it has your macaroon etc)
<zyga> rogpeppe: and then work with pstolowski to attach the logs there
<zyga> rogpeppe: and the state file
<rogpeppe> pstolowski: where does that file live?
<pstolowski> rogpeppe: /var/lib/snapd/
<zyga> rogpeppe: please make sure to use a private bug (when reporting it) because as pawel said, the state file contains some shared secrets
<zyga> let us know if you need any help with reporting the bug
<zyga> we will use it for tracking and eventual regression testing
<zyga> mborzecki: found a small-ish bug just now, /etc/ssl is a special case, as you know
<zyga> mborzecki: as is /etc/alternatives
<zyga> mborzecki: and they don't play nicely with the trespassing detector
<rogpeppe> zyga: are the macaroons the only secret things in there?
<zyga> yes
<rogpeppe> zyga: ok, i've redacted them specifically.
<pstolowski> rogpeppe: ty
<rogpeppe> zyga, pstolowski: https://bugs.launchpad.net/snapd/+bug/1843417
<mup> Bug #1843417: ubuntu core installation goes down regularly <snapd:New> <https://launchpad.net/bugs/1843417>
<zyga> thank you very much
<zyga> we'll try to get to the bottom of this
<zyga> pstolowski: can we use the state file to simulate a refresh somehow?
<rogpeppe> zyga: thanks. BTW if it can't be fixed fairly soon, i'll need to move to another distribution, because winter is coming and my parents need heat in the house :)
<zyga> rogpeppe: can you try one specific command that may help you
<zyga> rogpeppe: snap refresh core18
<zyga> that will refresh the base snap
<rogpeppe> zyga: ok, trying
<zyga> then you can try to refresh snapd
<zyga> essentially one-by one
<zyga> one-by-one
<zyga> rather than all at once
<zyga> if there's some kind of conflict happening
<zyga> it might be averted this way
<rogpeppe> zyga: ok, it's refreshed and is rebooting
<rogpeppe> zyga: well, in a minute
<rogpeppe> zyga: ok, we'll see if it comes back up
<zyga> fingers crossed
<zyga> systems at scale is complex
<zyga> we wish to make this totally unattended
<zyga> but as reality shows, it's not trivial
<pstolowski> zyga: in theory possible but lots of mocking
<rogpeppe> zyga: i'm somewhat unhappy about the reboot just happening randomly, not under some sort of control, particularly if there's a possiblity that the system might not recover from it
<rogpeppe> zyga: in this particular case, if this happened when people were away, it could result in the house not being heated enough and pipes freezing, leading to expensive damage
<zyga> rogpeppe: you can schedule updates
<zyga> there's a way to update predictably at very precise moments
<rogpeppe> zyga: oh? how would i do that?
<zyga> https://snapcraft.io/docs/keeping-snaps-up-to-date
<zyga> in doubt ask mborzecki, he knows this code very well
<zyga> or ask degville about the documentation for suggestions or improvements
<pstolowski> i'm looking into the state
<rogpeppe> zyga: is there some documentation for the actual refresh timer syntax that isn't just examples?
<mborzecki> re
<zyga> I don't believe there is, what would you like, a more formal syntax?
<rogpeppe> zyga: yup
<zyga> I believe it's a set of ranges
<zyga> but mborzecki can correct me on this
<rogpeppe> zyga: and an explanation of the semantics
<zyga> mborzecki: is there a more formal syntax of https://snapcraft.io/docs/keeping-snaps-up-to-date
<rogpeppe> zyga: with those docs, i'm left guessing
<rogpeppe> zyga: what does the "5" in "fri5" mean, for example?
<degville> rogpeppe: I think you're right - we should add a formal explanation of the syntax.
<zyga> rogpeppe: the semantics is that snapd will only attempt to refresh in time that fits that schedule
<rogpeppe> zyga: it's surely not the 5th friday in the month
<mborzecki> rogpeppe: just examples
<zyga> rogpeppe: it actually is
<zyga> rogpeppe: you can plan a monthly refresh this way
<rogpeppe> zyga: most months don't have a 5th friday
<zyga> perhaps the example is not the best but that is the intent
<zyga> mborzecki: what would happen if you pick the 5th Friday actually?
<mborzecki> rogpeppe: exmples list: fri5,23:00-01:00  Last Friday of the month, from 23:00 to 1:00 the next day
<mborzecki> rogpeppe: it's day[<weeknum>], 5 means the last week basically
<rogpeppe> mborzecki: i don't understand why that's the last friday of the month - that's what i mean when i say that it would be good to actually document the semantics
<rogpeppe> mborzecki: if the digit "5" is special, then it should say so
<rogpeppe> mborzecki: for example, would fri9 mean the same thing?
<mborzecki> rogpeppe: some syntax was initially described here https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239/6 some changes were made along the way though
<rogpeppe> mborzecki: more unknowns: would you be allowed to do "22:00~23:00/2" ?
<rogpeppe> mborzecki: if so, what's the difference between that and "22:00-23:00/2" ?
<zyga> I think those are all good questions, thank you for engaging with us rogpeppe
<rogpeppe> mborzecki: basically, i'd like to see some actual description of the semantics, not just a set of examples where i'm left to try to infer the actual rules
<mborzecki> rogpeppe: there's this page too: https://forum.snapcraft.io/t/timer-string-format/6562
<mborzecki> i gues it could use a little update with some details
<mup> PR snapd#7441 opened: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings <Created by pedronis> <https://github.com/snapcore/snapd/pull/7441>
<rogpeppe> that design doc from niemeyer is a great start. it would be nice if some more of that made it into the actual docs.
<rogpeppe> it also mentions some stuff that isn't documented at all, such as `0:00~24:00/6:00`
<rogpeppe> but maybe that's not implemented, i guess
<rogpeppe> zyga: FYI the pi did not successfully reboot.
<rogpeppe> zyga: i'm gonna have to ask for it to be power cycled again
<zyga> rogpeppe: did it reboot but fail or failed to reboot?
<rogpeppe> zyga: i've got no way of knowing, i'm afraid
<zyga> huh, I see :/
<rogpeppe> zyga: it said it was going down, my ssh connection was terminated, and it hasn't come back up again
<zyga> it has rebooted then
<rogpeppe> zyga: well, it shut down :)
<zyga> and after someone reboots it again it should roll back
<rogpeppe> zyga: and then i'm back in the same position as before?
<zyga> I was discussing a way to make that automatic in case of failure on the pi specifically
<zyga> yes
<rogpeppe> zyga: ok. :-(
<zyga> rogpeppe: you can set the schedule to avoid refreshes while we try to understand the cause of the failure
<rogpeppe> zyga: can i set the schedule so refreshes are turned off entirely?
<zyga> no, that's explicitly not available
<rogpeppe> zyga: AFAICS the minimum frequency is once per month
<zyga> rogpeppe: you can try one more thing
<zyga> you can refresh snapd itself
<zyga> that should not reboot
<zyga> but give you new software stack
<zyga> so that some bugs that were fixed since 2.40 can be applied
<zyga> well the fixes that is, not the bugs
<zyga> rogpeppe: you can try to refresh snapd to candidate channel to get it
<zyga> rogpeppe: with "snap refresh snapd --candidate"
<zyga> on core18 systems you no longer need to reboot to get new snapd, fortunately
<zyga> using the same strategy you could even refresh to a hotfix branch that contains a fix for your machine
<zyga> which would allow you to refresh the rest of the system correctly, once we understand the nature of the failure
<rogpeppe> zyga: ok, i'll try that when the system has been restarted, thanks
<pstolowski> zyga: so, auto-connect handler errors out because WaitRestart() reports a rollback error, we hit the "// TODO: make sure this revision gets ignored for automatic refreshes" case again, there is a revision mismatch there. this was discussed a few months ago when we hit similiar case. pedronis also did some work around reboots recently but i'm not sure if that's in play here
<pedronis> pstolowski: the checking for reboots has been added
<pedronis> maybe we didn't remove all the TODOs
<mborzecki> zyga: tbh, in situations like this, maybe we should have a mechanism to temporarily disable refreshes, some local assertion or whatnot
<pstolowski> zyga: so auto-connect is just a vitim here, problem is elsewhere
<zyga> mborzecki: yeah
<pedronis> I don't remember when it landed though
<rogpeppe> zyga: do you think that the failure to reboot correctly is related to this problem here, or just another problem that happens to be exacerbating the issue?
<zyga> I think that it may be a separate problem
<zyga> perhaps it'd be good to look at snap boot environment and see what it says
<pedronis> mborzecki: you can set refresh.hold no
<mborzecki> aahh
<mborzecki> right
<pedronis> a bit annoying to set, we really need a command for it, but is there
<rogpeppe> zyga: ok, i'm back into the system
<pedronis> pstolowski: we should drop that todo, the check is now done, is done much earlier, in daemon itself
<rogpeppe> zyga: it's maybe interesting that it seems the system only reboots successfully after exactly two power cycles.
<zyga> pedronis: refresh.hold? what is that
<pedronis> zyga: https://forum.snapcraft.io/t/system-options/87#heading--refresh-hold
<pedronis> it's on same page as timer
<zyga> ah, it's not on https://snapcraft.io/docs/keeping-snaps-up-to-date
<mborzecki> zyga: afaiu it's not intended to be used by the user
<pedronis> well, it's annoying but it exists
<pedronis> I would not recommend to use it without a reason
<pedronis> but it can be used
<rogpeppe> am i right that there's no way to specify that the system will refresh on the first day of every month?
<zyga> I believe you're correct
<pstolowski> pedronis: should the restart check be dropped from auto-connect handler?
<rogpeppe> zyga: thanks
<pedronis> pstolowski: in which sense?
<pedronis> the answer is likely no
<pstolowski> pedronis: removing WaitRestart() from auto-connect
<pedronis> pstolowski: no
<pedronis> it will be hit for a bit until we restart/reboot
<pedronis> what I said is checked earlier if when a reboot is triggered
<pedronis> whether it happeneed
<pedronis> at some point we might be able to not use WaitRestart but that requires changes to taskrunner etc
<pstolowski> pedronis: i see. ok, we need to find out what triggers this check to fail sometimes
<pedronis> pstolowski: nowadays, if we reboot 3 times and fails it will trigger
<pstolowski> i've a power outage, need to power off soon before my ups runs out of battery
<pedronis> well, try to reboot 3 times
<zyga> 2019 is still the year when I wish lauchpad to support markdown
 * pstolowski lunch
<zyga> mborzecki: I reported two bugs that I found today https://bugs.launchpad.net/snapd/+bug/1843421 and https://bugs.launchpad.net/snapd/+bug/1843423
<mup> Bug #1843421: snap-update-ns doesn't know about the special property of /etc/ssl and /etc/alternatives <snapd:Confirmed> <https://launchpad.net/bugs/1843421>
<mup> Bug #1843423: snap-update-ns fails to construct a layout in /etc/test-snapd/foo <snapd:Confirmed> <https://launchpad.net/bugs/1843423>
<zyga> ondra: ^ some useful bugs for you
<zyga> ogra: in case you run into something like that in the field
<zyga> I meant ondra twice but I think ogra may run into things like that as well
<mborzecki> zyga: btw. does s-u-n need to know aboutl nsswitch.conf too?
<zyga> mborzecki: probably so
<ondra> zyga thank you :)
<zyga> I'll do my best to fix them obviously
<zyga> writing tests is useful
<Chipaca> imma go lunch
<zyga> enjoy :)
<Chipaca> i'll try
<zyga> is it just me or are things extra slow today
<zyga> setting up main test suite takes about 10 minutes to complete
<mborzecki> zyga: and spread test are failing
<zyga> how?
<zyga> I haven't seen any failures though I'm mostly writing new tests now
<zyga> (but no store related failures during that process either)
 * zyga quick lunchj
<zyga> jdstrand: hello, can you please enqueue https://github.com/snapcore/snapd/pull/7421 for a non-security review but rather a concept review of the idea
<mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
<jdstrand> zyga: sure
<pedronis> mborzecki: I don't understand the spread failures, many of them don't even seem to have clear errors, or I'm not looking right (quite possible)
<Saviq> am I doing something dumb?
<Saviq> $ snap info multipass | grep installed
<Saviq> installed:   0.9.0-dev.171+g7a968814              (x4) 194MB classic
<Saviq> $ snap refresh multipass --revision 1125 --amend
<Saviq> error: local snap "multipass" is unknown to the store, use --amend to proceed anyway
<mup> PR core18#139 opened: hooks: add missing dosfstools to get fsck.fat <Created by mvo5> <https://github.com/snapcore/core18/pull/139>
<zyga> rogpeppe: hello
<zyga> rogpeppe: we have some more ideas
<rogpeppe> zyga: cool!
<rogpeppe> zyga: BTW ISTM that the fail-to-reboot issue is the main problem here - i'm not sure that the other issue would be a real problem if the reboot hadn't failed to restart
<zyga> rogpeppe: we looked some more and we suspect the boot partition that uses fat is corrupted, we found a bug related to absent fsck on core18 systems
<zyga> rogpeppe: we devised a way forward that you should be able to do remotely
<zyga> rogpeppe: if you have an app using "core" installed you should have access to fsck.vfat from /snap/core/current/usr/sbin/
<zyga> rogpeppe: you can use that to fsck the boot partition
<zyga> rogpeppe: you can unmount it for the duration of the check as well
<rogpeppe> zyga: given that i re-flashed the card very recently, it seems slightly unlikely that it's corrupted already (within a few hours of first installing) but happy to try
<zyga> rogpeppe: mvo looked at some of the error tracker logs and found what I believe was kernel telling us about fs corruption of the FAT partition
<zyga> rogpeppe: so that's the first step, I think you know how to run that without hand-holding but please ask for help if you need any
<zyga> rogpeppe: try to run it in mode verbose enough for us to see if there were any errors there
<rogpeppe> rogpeppe@localhost:~$ ls -l /snap/core/current/usr/sbin/*fsck*
<rogpeppe> ls: cannot access '/snap/core/current/usr/sbin/*fsck*': No such file or directory
<rogpeppe> rogpeppe@localhost:~$ ls -l /snap/core/current/usr/sbin/*vfat*
<rogpeppe> ls: cannot access '/snap/core/current/usr/sbin/*vfat*': No such file or directory
<zyga> oh, silly me
<zyga> just /snap/core/current/sbin/
<zyga> not /usr
<rogpeppe> zyga: so i'm planning to run these commands; do they seem right to you?
<rogpeppe> umount /boot/uboot
<rogpeppe> fsck -V /dev/mmcblk0p1
<zyga> yes
<zyga> they look good
<zyga> (assuming PATH is setup to find the fsck.vfat)
<zyga> rogpeppe: as an extra remark, it's sometimes good to stop snapd.service during things like this (hand's on experiments)
<zyga> to avoid background activity
<rogpeppe> zyga: http://paste.ubuntu.com/p/Fm3RpdC8d2/
<zyga> interesting!
<rogpeppe> zyga: i'd definitely unmounted the fs
<zyga> perhaps uboot and kernel disagree on which boot sector to use and then something gets out of sync later
<zyga> for the purpose of experiment, copy original to backup
<zyga> I _believe_
<zyga> that is what the kernel would use
<zyga> but I welcome the advice of mborzecki
<zyga> mborzecki: ^
<rogpeppe> zyga: and remove dirty bit?
<zyga> yes, but please understand my POV of trying to fix the partition and see if that means you can correctly boot out of the problem
<zyga> one more idea
<zyga> perhaps tarball all of the boot partition
<zyga> or even dd the whole partition to ext4 somewhere
<zyga> for forensics
<zyga> dd is better
<rogpeppe> zyga: sure, i could send you a copy
<zyga> as you don't have to mount do do
<zyga> *to do
<zyga> yes, we can then look at it bit by bit in hexedit
<zyga> fortunately we don't keep that many files there
<rogpeppe> zyga: ok, downloading disk image now; will upload to s3
<zyga> thank you
<rogpeppe> zyga: i still find it very odd that it only boots up ok once every other time. i can't think of something that might be causing such predictable boot failures.
<zyga> I can offer one
<mborzecki> zyga: fwiw, i think it's worth checking wether the same incorrectly unmounted warning appears on a cleanly built image
<mborzecki> like out of the box
<zyga> mborzecki: good idea
<zyga> rogpeppe: if uboot reads the FAT differently (we saw that at least once in the past) and sees a different file than linux
<zyga> then snapd will configure the boot loader to boot kernel-1, core-1 in "trying" mode
<rogpeppe> zyga: BTW the s/w i'm running ran fine without any issues for months on end previously
<zyga> the boot loader will go but never see those values
<zyga> booting something else
<zyga> perhaps something that is removed now
<zyga> or perhaps something that is there but disagrees with what snapd expected
<zyga> so snapd will change boot configuration again
<zyga> and plan another reboot
<zyga> rogpeppe: but the point is that the oscillation may be kernel/uboot disagreeing on the contents of a specific file
<zyga> and snapd writing to that file in between boots
<rogpeppe> zyga: ok, interrresting
<mup> PR snapd#7440 closed: snap/channel: fix unit tests, UbuntuArchitecture -> DpkgArchitecture <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7440>
<rogpeppe> zyga: try this: https://rogpeppe-scratch.s3.amazon.com/bootcopy.gz
<zyga> grabbing
<zyga> dns issue?
<rogpeppe> zyga: i've probably forgotten how s3 urls work
<Chipaca> i thought they'd turned off that feature
<Chipaca> of being able to just url the stuff
<Chipaca> (but i didn't pay too much attention to that email because i don't use it)
<rogpeppe> zyga: just usual amazon eventual consistency issues; try again
<mborzecki> zyga: fsck does't complain with a pristine core image
<zyga> mborzecki: thank you for checking!
<zyga> rogpeppe: still nothing
<rogpeppe> zyga: ha, it works for me :-\
<zyga> my dns may have cached it as gone?
<zyga> how big is it?
<zyga> can you email me@zygoon.pl
<rogpeppe> zyga: 48621287 bytes
<zyga> might be faster :)
<zyga> I'll go over the bits in the evening to see what's wrong
<zyga> meanwhile you can attempt to fix FAT
<zyga> or even remake it and copy the files back
<rogpeppe> zyga: for the time being, i've just slowed down updates so it'll only update on the first monday of the month
<zyga> excellent
<zyga> rogpeppe: as pedronis said, you can also use refresh.hold to delay up to 60 days
<rogpeppe> zyga: sent
<mup> PR snapd#7442 opened: tests: extend mount-ns test to handle mimics <Created by zyga> <https://github.com/snapcore/snapd/pull/7442>
<rogpeppe> zyga: i think 60 days isn't enough longer than 30 days to justify the unpredictability
<zyga> sure, just saying
<zyga> let's try to fix that FAT online
<zyga> apply all the fixes that fsck would normally do
<rogpeppe> zyga: you think that might fix the issue for good?
<zyga> I think it's likely
<zyga> but we don't have the data trends from the error tracker AFAIK so perhaps there's more but we're not aware of it
<rogpeppe> zyga: this is quite concerning BTW - this was an absolutely pristine image created following the instructions on the web to the letter
<rogpeppe> zyga: if i'm seeing this problem, then i'd guess that everyone else using ubuntu core is too
<zyga> indeed, we proposed that the boot partition is read only outside of the transactions that need to use it
<zyga> so that random power failures don't leave FAT in mounted state
<rogpeppe> zyga: that seems like a good idea.
<zyga> rogpeppe: there are some issues that can be specific to your device, e.g. the SD card may be just really failing
<zyga> I have a number of cards that reliably corrupt a fixed offset
<rogpeppe> zyga: it's a near-new SD card too, but i guess that's possible
<zyga> you can write zeros or ones, you keep reading that blob that they somehow store
<zyga> rogpeppe: the one I have is little-used sandisk pro 32GB card
<zyga> rogpeppe: it failed in a few weeks after purchase
<rogpeppe> zyga: that would make it both 32GB SD cards that are failing in a similar way then
<rogpeppe> zyga: because i saw a similar issue with the Pi 2 and assumed the sd card had gone
<rogpeppe> zyga: i actually have that pi with me in fact
<zyga> I got the boot image now, thank you
<zyga> rogpeppe: try something like 'etcher' to see if you can write a pristine image and read it back correctly if you want to check that
<rogpeppe> zyga: yeah, i'll try that
<rogpeppe> zyga: i wasn't surprised when the original sd card failed BTW - it had been in constant use for about 3 years.
<rogpeppe> zyga: ... if it did fail, of course
<zyga> indeed, analysis will reveal the cause
<zyga> there are some moving parts
<zyga> and some failures on our end
<zyga> sil2100: hey, there's one PR for core18
<zyga> sil2100: it's related to what we are discussing now
<zyga> sil2100: we didn't seed fsck.vfat on core18
<zyga> sil2100: do you think you could review it please?
<zyga> https://github.com/snapcore/core18/pull/139
<mup> PR core18#139: hooks: add missing dosfstools to get fsck.fat <Created by mvo5> <https://github.com/snapcore/core18/pull/139>
<mvo> rogpeppe: thank you so much for reporting this - and yes, super concerning to us and we dig into it
 * mvo hugs zyga for digging into it
<rogpeppe> mvo: thanks for your interaction :)
<zyga> rogpeppe: this is what I see on the partition: https://pastebin.ubuntu.com/p/tVXVjCK99Q/
<zyga> I will now check the contents of config.txt, cmdline.txt and uboot.env
<zyga> for one, I like that mtools exists
<zyga> and wish that there was an ext4 variant :)
<rogpeppe> zyga: i don't know about mtools...
<zyga> rogpeppe: it's a GNU tool for interacting with FAT offline
<sergiusens> hello folks, is there a fix upcoming for "- Download snap "crystal" (71) from channel "latest/stable" (stream error: stream ID 1; PROTOCOL_ERROR)" ?
<sergiusens> this is really slowing us down
<zyga> sergiusens: we don't have a fix, only a workaround mvo worked on
<sergiusens> zyga: does the workaround require work (a setting) on our side?
<ondra> zyga I found one cloud instance with 4 broken snaps I was not able to remove, with latest snapd, I was able to remove all them :) Great work!
<zyga> sergiusens: no, it's automatic
<zyga> ondra: thank you so much :)
<ondra> zyga thank you for fixing it :)
<zyga> ondra: fixing bugs is sometimes very draining, I'm very glad I was able to help you and others in FE
<zyga> rogpeppe: this is the hexyl dump of uboot.env, I'll check out what it says next https://paste.ubuntu.com/p/GgScB76RyT/  -- specifically to see if it is in agreement with snapd's state
<zyga> though I must say that the colorized output from hexyl is easier to read as it shows NUL bytes and other such stuff in clear, distinct color
<zyga> mvo: one other idea, just looking at this, is to have two uboot environment files: one for the fixed program and the other one for just the handful of actual variables we need
<zyga> oh, mvo is not online anymore
<zyga> rogpeppe: so looking here I see we have the following things: snap_core=core18_1076.snap, snap_kernel=pi-kernel_44.snap, snap_mode= (empty string), snap_try_core=core18_1100.snap, snap_try_kernel=pi-kernel_51.snap,
<zyga> I need to reference the boot logic for a second to understand snap_mode=""
<zyga> mborzecki: ^ unless you remember
<zyga> rogpeppe: do you have the snaps and revisions listed there in /var/lib/snapd/snaps/
<zyga> they should all be mounted as well
<zyga> and visible in snap list --all
<zyga> rogpeppe: (output of snap list --all would help as well)
<mborzeck1> zyga: this? https://github.com/snapcore/core-build/blob/master/initramfs/scripts/bootloader-script#L89
<mborzeck1> zyga: or this one https://github.com/snapcore/pi3-gadget/blob/16/uboot.env.in#L48
<zyga> huh
<zyga> https://github.com/snapcore/core-build/blob/master/initramfs/scripts/bootloader-script#L104
<rogpeppe> zyga: http://paste.ubuntu.com/p/ktw4XYgrvG/
<zyga> I don't understand how that works
<zyga> ah, wait
<zyga> didn't notice nesting
 * zyga re-reads
<zyga> rogpeppe: do you have core18 at revision 1100?
<zyga> I mean
<zyga> I don't see it
<zyga> so I assume that's why it fails
<zyga> it seems we are trying to get to core18 revision that's simply not here
<zyga> that would explain the immediate failure
<rogpeppe> zyga: i see core18 at 1076
<zyga> though I didn't check what uboot script does if it cannot find that snap
<rogpeppe> zyga: what's special about 1100?
<zyga> rogpeppe: nothing, it's just referenced from your uboot.env but not present on the system
<rogpeppe> zyga: oh, i see
<rogpeppe> zyga: i wonder how that happened
<zyga> indeed
<zyga> though snapd may have undone 1100 transaction
<zyga> removing the file from disk
<zyga> if you feel lucky, fix the boot partition with fsck
<zyga> snap refresh core18
<zyga> and check if it manages
<zyga> one other lesson from this
<zyga> is for snapd to fix any boot variables that are inconsistent with reality
<zyga> we have one boot mode
<zyga> as in, one variable called snap_mode
<zyga> that impacts two variables "trying"
<rogpeppe> i'm not feeling very lucky currently :)
<zyga> and it's clear that in this case there's a chance one of them will fail
<zyga> rogpeppe: I'll collect this in a retrospective
<zyga> there's a lot for us to learn from this
<zyga> rogpeppe: I would suggest to fix the FAT partition
<zyga> that might be enough to fix other issues
<rogpeppe> zyga: ok, i'll try that
<zyga> I'll collect all of this for a retrospective and share with you
<zyga> I was thinking about breaking for dinner now
<rogpeppe> zyga: ok, dirty bit  removed. it didn't give me an option to do anything else
<rogpeppe> zyga: i suspect i may have done the wrong thing there :-'
<rogpeppe> :-\
<zyga> oh?
<zyga> note, you can always dd it back!
<rogpeppe> zyga: good point!
<zyga> what did you do?
<zyga> try fixing it, mounting it
<zyga> and looking at the files
<rogpeppe> zyga: http://paste.ubuntu.com/p/MtVGCFGGwk/
<zyga> at least the boot.env
<rogpeppe> zyga: i suspect i should've said "no" to removing the dirty bit, i think
<zyga> ah, no
<zyga> I think that's fine
<zyga> it's just a bit
<zyga> fat has no journal
<zyga> so apart from top-down scan there's little to do
<rogpeppe> zyga: i thought i'd get the option to address the other issue too
<rogpeppe> zyga: so the dirty bit is the only thing that was wrong?
<zyga> ah right
<zyga> I honestly don't know
<zyga> can you fsck again?
<zyga> maybe with some --force option
<rogpeppe> zyga: a ran it again - it does nothing
<rogpeppe> *i* ran it again
<zyga> did you use -V?
<zyga> rogpeppe: so
<zyga> rogpeppe: writing the report I'm not sure we understand what really failed on boot
<zyga> rogpeppe: we know that the fat was slightly corrupt
<zyga> that it was not unmounted cleanly
<zyga> rogpeppe: we do know that core18 revision 1100 was missing from your disk
<zyga> rogpeppe: though perhaps it was removed by snapd in its undo path
<zyga> rogpeppe: I would like to know if you'd be willing to attempt another reboot, at your convenience, coupled with another reboot done by "snap refresh core18"
<rogpeppe> zyga: so one reboot without "snap refresh core18", then run "snap refresh core18", then let that reboot by itself?
<zyga> yes
<zyga> but only if you have confidence you can recover manually
<zyga> and not super inconvenient for you
<rogpeppe> zyga: ok, i'll try that. what should i do when it fails to restart after the first reboot?
<zyga> power cycle
<rogpeppe> zyga: ok
<zyga> if that fails we may be SOL but I dont't think it will come to that
<zyga> you may want to mount the partition back
<zyga> mvo: hey welcome back
<rogpeppe> zyga: does that make a difference?
<zyga> rogpeppe: in case snapd wishes to write to it
<zyga> otherwise no
<rogpeppe> zyga: ok, i'll mount it again now
<mvo> hey zyga - whats new?
<zyga> mvo: we found some things, one sec, I'll share my notes
<ijohnson> hey folks, could I get another review on https://github.com/snapcore/snapd/pull/7429 ? mvo maybe if you're not EOD yet and have a couple minutes :-)
<mup> PR #7429: wrappers/services: add CurrentSnapServiceStates + unit tests <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7429>
<mvo> ijohnson: heh, let me have a look
<ijohnson> thanks :-)
<zyga> rogpeppe: let us know what you find pleaes
 * Chipaca goes for a run
<mvo> ijohnson: you have feedback
<mvo> ijohnson: should be super simple
<ijohnson> yay thanks looking now
<rogpeppe> zyga: will do. it might be tomorrow.
<zyga> ack, thank you for the note
<ijohnson> mvo: thanks I fixed the out of date comment / for loop, but I think it's still nice to have the more verbose/complete systemctl script
<mvo> ijohnson: thats fine
<mvo> ijohnson: keep it if you prefer it :)
<ijohnson> okay, cool so with your and mborzecki's review am I good to merge?
 * ijohnson waits on the merge button
<mvo> ijohnson: yes
<ijohnson> oh well I guess the tests have to pass too
<mvo> ijohnson: *cough*
<ijohnson> :-O
<mvo> ijohnson: :(
<ijohnson> they're not failing just haven't started running yet
<mvo> ijohnson: ok
<ijohnson> thanks mvo, I'll merge sometime in my afternoon then
<mvo> ijohnson: good luck!
<ijohnson> :-)
<rogpeppe> anyone got any idea why `xdg-open` has stopped opening pdf files correctly for me (it opens them in an ebook viewer). I think it might have something to do with the fact that `xdg-mime query filetype anyfile.pdf` doesn't print anything, but I'm not sure how that works.
<rogpeppe> oops, wrong channel, sorry!
<mup> PR snapcraft#2644 closed: Release changelog for 2.44 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2644>
<mup> PR snapcraft#2709 opened: incorporate content provider snaps in dependency resolution <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2709>
#snappy 2019-09-11
<mborzecki> morning
<mup> PR snapd#7443 opened: timeutil: fix schedules with ambiguous nth weekday spans <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
<mborzecki> pedronis: hey
<mborzecki> gopkg is down?
<pedronis> mborzecki: from spread tests? I haven't seen that, I have see lots of things timing out though
<mborzecki> pedronis: the unit test travis job failed because of this in 7443, though it's green now after i restarted it
<pstolowski> morning
<mvo> hey pstolowski
<mvo> zyga: any updates on the pi system that was problematic yesterday?
<mvo> sil2100: if you have time a review for https://github.com/snapcore/core18/pull/139 would be great (should be simple)
<mup> PR core18#139: hooks: add missing dosfstools to get fsck.fat <Created by mvo5> <https://github.com/snapcore/core18/pull/139>
<zyga> Good morning
<mvo> hey zyga !
<zyga> Starting just now, sorry, today kids go to school at 8:45
<zyga> mvo: the reporter promised to try rebooting and report back
<zyga> So no update yet
<mvo> zyga: I see no new bugreport from that system in the error tracker since ~2 days
<mvo> zyga: no idea if thats good or bad though :/
<zyga> Iâll reach out
<zyga> Mvo we have another problem
<zyga> Please check the mail from Jamie
<mborzecki> anyoen feels like looking at https://github.com/snapcore/snapd/pull/7443 ?
<mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
<mborzecki> keep in mind, there be dragons
<zyga> re
<mup> PR snapd#7444 opened: overlord/snapstate/policy, etc: introduce policy, move canRemove to it <Created by chipaca> <https://github.com/snapcore/snapd/pull/7444>
<Chipaca> pedronis: ^
<pedronis> Chipaca: thanks
<Chipaca> pedronis: there's a bunch of things I'm itching to do to that code, but I've tried to leave it alone as much as possible :)
<pedronis> Chipaca: were the tests in snapstate that you are removing still passing? in general in this cases I prefer to do that removal as a 2nd step
<Chipaca> pedronis: some of them were failing
<Chipaca> but I could've made them pass with some tweaks
<Chipaca> pedronis: I can put them back, fix them, and then remove them
<pedronis> Chipaca: would be better for reviewers I think
<Chipaca> ok
<pedronis> Chipaca: I also I recommend having different file per types already, because the PR that decides we need that will be weird and hard to review
<pedronis> otherwise
<Chipaca> hmm
<Chipaca> pedronis: ok
<pedronis> git will not help there, splitting a file in a lot of files
<Chipaca> pedronis: should I close that, force-push with these changes?
<pedronis> you can force push
<Chipaca> k
<pedronis> I'm just giving high level comments
<pedronis> not really started reviewing in detail as such
<zyga> heh
<sil2100> mvo: sure thing!
<zyga> remember our 3K diffs
<zyga> check this out https://github.com/apple/swift/pull/20315/files
<mup> PR apple/swift#20315: [String] Use a UTF-8 representation for native strings <Created by milseman> <Merged by milseman> <https://github.com/apple/swift/pull/20315>
<zyga> hello sil2100
<zyga> how are you
<mup> PR snapd#7444 closed: overlord/snapstate/policy, etc: introduce policy, move canRemove to it <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/7444>
<sil2100> zyga: hello o/ Still a bit tired, but not bad - how about you?
<zyga> sil2100: enjoying the sun today, looking at landing some branches and finally doing a release for opensuse
<zyga> sil2100: mvo sent a small patch yesterday, I pinged you about it
<zyga> sil2100: can you look at it today please?
<sil2100> zyga: yes, looking at it right now ;)
<Chipaca> pedronis: WDYT of canremove_test?
<mup> PR core18#139 closed: hooks: add missing dosfstools to get fsck.fat <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/139>
<Chipaca> pedronis: organisation wise i mean
<zyga> thank you sil2100 :)
<zyga> now we need a regression test
<zyga> mvo: I think it'd be easier to write snapd side
<zyga> mvo: we can run it in nightly suite
<mvo> zyga: yeah
<zyga> and ensure nightly is ran on all relases
<zyga> mvo: we should write that down somewhere on release acceptance
<pedronis> Chipaca: yes, I think organising tests by policy method makes sense
<pedronis> we can always have <type>_test.go if there is really something very specific or helper to test
<Chipaca> k
<pedronis> #7416 needs reviews (it's big)
<mup> PR #7416: seed/seedwriter: start of Writer and internal policy16/tree16 <Created by pedronis> <https://github.com/snapcore/snapd/pull/7416>
<mvo> Chipaca, pedronis 6404 is extremly confused in the cla check. it thinks it needs to check 196 emails and fails on a gazillion of them. I'm not sure its worth fixing the checker, I could create a new PR, point to the discussion of the old PR and get on with things? wdyt?
<mvo> Chipaca: i.e. it looks like its not checking alternative emails in LP so it misses a lot of @canonical.com ones
<Chipaca> pedronis: i broke 7444 so 7445 is up for your viewing pleasure
<mup> PR snapd#6705 closed: bootloader: little kernel support <Created by kubiko> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6705>
<mup> PR snapd#7445 opened: overlord/snapstate/policy, etc: introduce policy, move canRemove to it <Created by chipaca> <https://github.com/snapcore/snapd/pull/7445>
<Chipaca> mvo: ...?
<Chipaca> mvo: let me see
<Chipaca> ah, super old pr?
<Chipaca> mvo: there's a small change I'd like to you to try first
<mvo> Chipaca: ok
<mup> PR snapd#7125 closed: snapstate: make progress reporting less granular <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7125>
<zyga> mborzecki: re
<Chipaca> whoops
<zyga> ?
<Chipaca> pushed code with for-debug panics
<Chipaca> not entirely convinced the panics aren't actually properly deserved tho :)
<Chipaca> but not right now
<Chipaca> degville: did I understand correctly that you were looking into https://forum.snapcraft.io/t/trouble-installing-snapd-on-rhel-8/13140 ? or, who was?
 * Chipaca has bad memory
<degville> Chipaca: yes, that's the post I talked about yesterday. Although I've not had much luck. Our docs reference EPEL for 7, and things have changed slightly for 8.
<Chipaca> degville: is the poster aware of your efforts?
<degville> Chipaca: maybe - I responded on the RHEL install page on docs category.
<degville> Chipaca: I had hoped it would be simply adding new instructions for the new repo config for EPEL, but that hasn't worked for me either.
<mup> PR snapd#7446 opened: tests/mountinfo-tool: proper formatting of opt_fields <Created by zyga> <https://github.com/snapcore/snapd/pull/7446>
<zyga> rogpeppe: hello, did you have any luck rebooting your board?
<rogpeppe> zyga: i'm waiting for someone to be around to power cycle when it fails to reboot
<rogpeppe> zyga: actually, i'll just try it anyway
<zyga> rogpeppe: understood, thank you so much for helping us understand this issue
<zyga> rogpeppe: we've fixed missing fsck.vfat already, we're going to implement a test that verifies the filesystem is really checked and repaired automatically next
<rogpeppe> zyga: ok, rebooting. keeping fingers crossed :)
<zyga> mvo: ^ :)
<zyga> rogpeppe: did it boot?
<rogpeppe> zyga: yes!
<zyga> excellent!!!
<zyga> rogpeppe: can you now try to refresh core18 snap
<zyga> it should be successful now
<rogpeppe> zyga: i have to say i wasn't expecting that :)
<zyga> and with some luck, it may unblock all refreshes
<zyga> rogpeppe: thanks to the image you sent me I will investigate how uboot you have sees that
<zyga> perhaps there's a discrepancy there
<zyga> (and by "that", I mean the file that controls the boot process)
<rogpeppe> zyga: ok, refreshed, waiting for reboot now. more crossed fingers. :)
<rogpeppe> zyga: sadly it hasn't come back up after that
<zyga> huh
<zyga> huh
<zyga> the plot thickens then
<zyga> let's wait some more and in case nothing changes, reboot it manually
<Chipaca> *clot
<rogpeppe> zyga: for the record, this was what the snap refresh command printed: http://paste.ubuntu.com/p/fPdkPjxdwY/
<zyga> once it recovers, let's look at "snap changes" and at journald
<zyga> Chipaca: is it likely that core18 revision 1100 is corrupt but stays in cache?
<zyga> Chipaca: and if so, is there a way we could verify that somehow from command line?
<Chipaca> zyga: no, things are only moved if sha3 is ok
<zyga> yes but if the card is corrputed
<zyga> and the file on disk is just corrputed
<zyga> is it going to be in cache after a failed refresh / reboot?
<zyga> *corrupted
<Chipaca> so, sudo find /var/lib/snapd/cache | xargs sudo snap info --verbose
<Chipaca> will print the sha3 of all snaps in the cache
<Chipaca> by re-reading them i mean
<zyga> mmm
<zyga> rogpeppe: ^^
<mup> PR snapd#7447 opened: snapstate: do not allow removal of the snapd snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/7447>
<Chipaca> now, the sha3 is also the filename
<Chipaca> but because of Reasons, it's formatted differently :-|
<mvo> Chipaca: \o/ for your cla check unshallow magic!
<zyga> rogpeppe: did it recover after power-cycle?
<rogpeppe> zyga: i'm waiting for my dad to see the email asking him to power cycle...
<zyga> understood
<zyga> I'll check if we can enable watchdog from the bootloader
<zyga> so that things like that don't require intervention
<rogpeppe> zyga: what do you mean by "watchdog" there?
<Chipaca> mvo: :)
<Chipaca> mvo: in store/cache.go, why is it using the hex digest instead of the EncodeDigest thing?
<Chipaca> bah, i guess store/store.go is the one that actually uses one or t'other
<mvo> Chipaca: I don't know why hex digest, sry
<Chipaca> k
<mvo> Chipaca: with the new unshallo I guess I can now remove the zyga@xenial-server from the whitelist, right?
<pedronis> Chipaca: hex might slightly more filename friendly?
<Chipaca> pedronis: a tiny bit, but the inconsistency bites
<Chipaca> mvo: dunno. Maybe?
<Chipaca> mvo: feel free to try :-)
<mvo> Chipaca: will do
<Chipaca> pedronis: bah, we could also make snap info print out both variants
<Chipaca> feels messy tho
<pedronis> that doesn't sound great
<pedronis> info is messy enough as is
 * Chipaca covers info's ears
<Chipaca> pedronis: EncodeDigest is a base64 url encoding, so it should be fine for filenames
<Chipaca> it's got _ and - and alphanum
<Chipaca> i'll look into switching it sometime
<rogpeppe> zyga: ok, looks like it was power-cycled. here's the snap changes output: http://paste.ubuntu.com/p/My5Cv4P443/
<rogpeppe> zyga: for the record, it took two power cycles to come up again, as before
<zyga> rogpeppe: there is one more angle
<zyga> rogpeppe: we are testing two things at the same time
<zyga> rogpeppe: if you recall, your kernel snap is refreshed and waiting to boot as well
<zyga> rogpeppe: so it might be either of the two that cause issues
<rogpeppe> zyga: i've emailed you the ouput of `journalctl --system`
<zyga> I'm reading it now
<pstolowski> mborzecki: funny bug that one with snap unset & unsupported core options you found... subtle bug in transaction.Changes()
<mborzecki> pstolowski:  heh ;)
<zyga> Sep 11 09:45:32 localhost snapd[690]: stateengine.go:150: state ensure error: devicemgr: snap "core18" has "refresh-snap" change in progress
<zyga> Sep 11 10:09:25 localhost snapd[690]: handlers.go:460: Reported install problem for "core18" as 37ec03ba-d47c-11e9-a667-fa163e6cac46 OOPSID
<zyga> mvo: ^ can you please look at that oops id?
<Chipaca> zyga: can't you?
<zyga> no
<zyga> or if I do
<zyga> I don't know I do
<zyga> last time I only could look at the graph of errors
 * zyga checks
<zyga> Chipaca: perhaps I should ask, can you see those?
<Chipaca> zyga: https://errors.ubuntu.com/oops/37ec03ba-d47c-11e9-a667-fa163e6cac46
<Chipaca> zyga: you need to log in
<mvo> zyga: looks the same as the last one, no more extra data
<zyga> oh, I see that one
<zyga> I tried https://errors.ubuntu.com/?problem/37ec03ba-d47c-11e9-a667-fa163e6cac46
<mvo> zyga: I'm not even seeing the "has ... changes in progress" in the oops :(
<zyga> mvo: that was in the journal
<zyga> thank you for teaching me about the proper URL Chipaca
<zyga> it's odd that there's "problem" and "oops" separately
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> zyga: problems are aggregations
<zyga> yeah, on second thought it does make sense
<zyga> but ... uuid,
<zyga> look up
<zyga> anyway :D
<Chipaca> zyga: at the bottom of every problem there's a list of oopses
<Chipaca> oopsen
<Chipaca> oopsi
 * Chipaca hides
<zyga> I'll check what the state engine message is about
<zyga> oppsinen?
<zyga> I prefer oopsi
<zyga> rogpeppe: I think we need to think about what may be going on now
<zyga> rogpeppe: I will gather more ideas from the team and see if any of those are worth experimenting at your inconvenience
<mup> PR snapd#7448 opened: tests: remove mount_id and parent_id from mount-ns test data <Created by zyga> <https://github.com/snapcore/snapd/pull/7448>
<rogpeppe> zyga: thanks. let me know if you have any more ideas.
<zyga> rogpeppe: thank you for working with us again, I'll try to replicate your setup locally to see if anything can be learned from this
<zyga> pedronis: there's a question about snap create-user --force-managed on https://bugs.launchpad.net/snappy/+bug/1647256 that I'm not sure how to answer
<mup> Bug #1647256: snap create-user cannot add a new user to an existing ubuntu core device <Snappy:New> <https://launchpad.net/bugs/1647256>
<pedronis> zyga: put in my queue, I don't have an immediate answer
<rogpeppe> zyga: FYI I just tried fsck.vfat again and it's all clean
<zyga> rogpeppe: mmm, that's useful, so it's not corruption that is causing the problem
<zyga> rogpeppe: can you check what Chipaca suggested above:
<rogpeppe> zyga: what was that (I see quite a few messages from Chipaca)
<rogpeppe> ?
 * Chipaca is a chatterbox
<zyga> one sec :)
<Chipaca> so, sudo find /var/lib/snapd/cache | xargs sudo snap info --verbose
<Chipaca> rogpeppe: ^
<zyga> sudo find /var/lib/snapd/cache | xargs sudo snap info --verbose
<rogpeppe> wow, snap info is really slow!
<Chipaca> with verbose, it's doing some expensive stuff yes
<rogpeppe> Chipaca, zyga: http://paste.ubuntu.com/p/vSpW6tmnJn/
<Chipaca> ok, gimme a bit to check those
<zyga> Chipaca: can I ask the dummy question of unifying the way the hash is printed
<rogpeppe> Chipaca, zyga: FWIW, the info for the hydroctl service doesn't seem to be correct - it says that the hydroctl.hydroserver service is disabled/inactive, but it's definitely running currently
<zyga> so that it is easier to eyeball-check
<zyga> rogpeppe: oh, can you give us the output of systemctl status for that service unit?
<zyga> rogpeppe: I think at some point it'd be good to report issues or we will be lost in the details
<rogpeppe> zyga: as in `systemctl status hydroctl.hydroserver` ?
<zyga> I think that it ought to be systemctl status snap.hydroctl.hydroserver.service
<rogpeppe> zyga: ah, ok
<zyga> snapd prepends "snap." to all units installed by snap packages
<rogpeppe> zyga: http://paste.ubuntu.com/p/ntMd8jXMFg/
<zyga> indeed, if snap service output disagrees, that's a bug!
<zyga> can you collect that as well and report it via bugs.launchpad.net/snapd
<zyga> Chipaca: can we look up snap revision for a blob for "snap info --verbose"?
<rogpeppe> zyga: without truncated logs FWIW http://paste.ubuntu.com/p/rjxwqpvFM5/
<zyga> thank you
<rogpeppe> zyga: sorry, i'm not exactly sure what's the bug here
<zyga> rogpeppe: disagreement, snap service should not misrepresent facts
<rogpeppe> zyga: you mean "snap info", right?
<Chipaca> zyga: rogpeppe all those hashes are coorect
<zyga> Chipaca: thank you for checking that!
<zyga> rogpeppe: perhaps I misunderstood, what did you mean when you said "FWIW, the info for the hydroctl service doesn't seem to be correct - it says that the hydroctl.hydroserver service is disabled/inactive, but it's definitely running currently"
<zyga> how did you produce the information?
<rogpeppe> zyga: which information?
<zyga> information for hydroctl service
<rogpeppe> zyga: it runs a web service that I can access
<Chipaca> heh
<zyga> aha
<Chipaca> rogpeppe: sorry if that's confusing
<Chipaca> you ran snap info on a file, not on an installed snap
<Chipaca> it should not print that service info for files
<Chipaca> i'll look into it
<rogpeppe> Chipaca: ok, i see
<Chipaca> rogpeppe: if you run snap info --verbose hydroctl, you should see the right status there
<zyga> ah, I understand now
<zyga> thank you Chipaca
<rogpeppe> https://bugs.launchpad.net/snapd/+bug/1843567
<mup> Bug #1843567: snap info reports incorrect service status <snapd:New> <https://launchpad.net/bugs/1843567>
<mup> PR snapd#7449 opened: overlord/configstate: special-case json.RawMessage("null") in transaction Changes() <Created by stolowski> <https://github.com/snapcore/snapd/pull/7449>
<Chipaca> niemeyer: is gopkg.in in trouble?
<zyga> 70 PRs
<zyga> time to stop
<rogpeppe> Chipaca: looks ok to me
<Chipaca> just got a string of failed tests because of 'Failed for "gopkg.in/retry.v1" (failed to clone repo)' because 'error: RPC failed; HTTP 502 curl 22 The requested URL returned error: 502'
<Chipaca> eh, redoing
<pstolowski> mborzecki: can you take a look at #7449?
<mup> PR #7449: overlord/configstate: special-case "null" in transaction Changes() <Created by stolowski> <https://github.com/snapcore/snapd/pull/7449>
<pstolowski> mborzecki: and i'm going to look at your schedule fix
<zyga> pstolowski: I'm looking at that too
<mborzecki> pstolowski: sure, looking
<zyga> pstolowski: looking at your comment there
<zyga> pstolowski: the decoder acts on the type you give, so if you give a map, you get a nil map
<zyga> pstolowski: though one might discuss if "null" is a valid JSON representation of a map
<zyga> pstolowski: I think, perhaps surprisingly so, that it is
<pstolowski> zyga: yep, it's a bit ambigous
<zyga> pstolowski: as a technicality, perhaps the len check could be merged into the original line, after err == nil
<zyga> and the comment put up front, with slight rewording
<zyga> so that it's reasier to read
<zyga> I think again that the point is that the decoding is not unexpected
<pstolowski> zyga: yes i had the len check merged but found it easier to read if the case is isolated with comment
<pstolowski> ymmv
<zyga> alternatively, it's the single condition, len > 0
<zyga> as err is otherwise unused
<zyga> uh
<zyga> we have another thing to fix in master
<zyga> 'debian-sid-64' now has support. Please update this test
<zyga> this is from     - google:debian-sid-64:tests/main/system-usernames
<pedronis> something for jdstrand
<zyga> we should open a priority pull request to make address that
<Chipaca> pedronis: in snapstate, any reason to load the yaml and look at type instead of using snapst.Type()? (afaik no but you're better at tracking this)
<pedronis> Chipaca: depends where,  in some places we might not have set snapst type yet
<pedronis> basically the one from the yaml might be safer to know it's there
<Chipaca> pedronis: in places that call canRemove
<Chipaca> :)
<pedronis> should be safe, last famous words
<Chipaca> :-)
<mborzecki> off to pick up the kids
<Chipaca> pedronis: i can always make it fall back to loading the yaml if unset
<pedronis> might be easier to assume app if it's not
<pedronis> for remove
<pedronis> we might even have code like that anyway
<pedronis> because remove should work even with broken snaps
<pedronis> in theory
<pedronis> or at least it should try
<Chipaca> pedronis: fair
<Chipaca> I'll be tweaking the code in a followup :-)
<zyga> going through this slowly
<Chipaca> ooh, i think i see a bug
 * Chipaca kicks off a core18
<sergiusens> Getting this error a lot since Monday, anyone else seeing something similar when running on spread/google? "- Start snap "lxd" (11824) services ([start snap.lxd.activate.service] failed with exit status 1: Job for snap.lxd.activate.service failed because the control process exited with error code."
<Chipaca> sergiusens: what's in the journal when that happens?
<sergiusens> Chipaca: I will have to add a "debug" stanza to see (I can only trigger the google provider through travis, me have no keys)
<Chipaca> sergiusens: k
<Chipaca> sergiusens: you should have a debug stanza, yes :-)
<Chipaca> the logs of when things break can be quite valuable
<sergiusens> Chipaca: does debug at the top level run fine (spread.yaml) or do I need debug-each (does that exists?)
<Chipaca> sergiusens: debug at the toplevel should work fine
<Chipaca> sergiusens: debug-each exists, indeed
<sergiusens> ok, since this fails for the top level prepare I will add a debug, but just in case, will also add "debug-each"
<pedronis> we had also this related to lxd.activate: https://forum.snapcraft.io/t/snapd-pegged-cpu-updates-never-completing-on-core/13142
<Chipaca> pedronis: mvo: we have a bug where we'll take "core" to satisfy a "base: core16" snap, but not check in canRemove
<pedronis> Chipaca: ok
<sergiusens> Chipaca: "journalctl -xe" or more?
<pedronis> Chipaca: I don't think is very urgent, just keep track of it somehow
<Chipaca> sergiusens: probably enough for now (you'll add more as you go i guess?)
<Chipaca> pedronis: i'm in the right place to fix it now tho
<Chipaca> :)
<Chipaca> but, sure
<pedronis> Chipaca: if it's not too much extra lines/work
<Chipaca> eep, 70 PRs :-|
<zyga> Chipaca: and master being red
<Chipaca> mmm, red
<niemeyer> Chipaca: It's not in trouble but it's suffering.. there are spikes over the day that may put the machine over capacity for a moment
<Chipaca> niemeyer: ack
<niemeyer> Chipaca: We're already in the process of moving it inside Canonical DC
<mup> PR snapd#7450 opened: tests: debian sid now ships new seccomp, adjust tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7450>
<zyga> jdstrand: can you please look at https://github.com/snapcore/snapd/pull/7450 -- I must be missing something there
<mup> PR #7450: tests: debian sid now ships new seccomp, adjust tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7450>
<zyga> thank you, I'll check the other tests as well
<zyga> I'll rewrite the commit message as well
<zyga> jdstrand: fixed and pushed
<jdstrand> thanks!
<zyga> thank you for the urgent review :)
<jdstrand_> np
<zyga> mvo: we can always productively add _more_ PRs
<mup> Bug #1843589 opened: core snap stuck refreshing <Snappy:New> <https://launchpad.net/bugs/1843589>
<zyga> ugh, mvo, Chipaca ^^^^
<Chipaca> yeah, reading
<Chipaca> something's missing there though
<Chipaca> bah, it's strange
<zyga> stranger snaps
 * zyga break for coffee and some rest 
<mvo> hm, store is not a happy puppy right now - I just got 400 from a refresh on jq
<Chipaca> mvo: 400?!
<Chipaca> nice
<mvo> yes
<tomwardill> hello! store team again, store is having problems, refresh particuarly.
<mup> PR snapcraft#2710 opened: Add setting to remove the "jar" option in the gradle command <Created by LyzardKing> <https://github.com/snapcore/snapcraft/pull/2710>
<mup> PR snapd#7451 opened: sandbox/cgroup: introduce cgroup wrappers package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7451>
 * Chipaca takes a break
<ijohnson> zyga: I reviewed #7435 for you, you should merge it while it's still green :-)
<mup> PR #7435: tests: explicitly restore after using LXD <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7435>
<zyga> ijohnson: thank you
<ijohnson> np you're welcome
<mup> PR snapd#7435 closed: tests: explicitly restore after using LXD <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7435>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7451#pullrequestreview-286825091
<mup> PR #7451: sandbox/cgroup: introduce cgroup wrappers package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7451>
<sergiusens> mvo: pstolowski 3.8 is in stable, which has the snapcraft fix from edge tested to build the snapd snp
<mvo> sergiusens: cool, thank you
<mvo> niemeyer: we have a small spread PR for you, hopefully easy and quick to review https://github.com/snapcore/spread/pull/69 - it will help sergio because we hit the limit of a single page for the images :)
<mup> PR spread#69: Manage pagination retrieving images from google backend <Ready> <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/69>
<niemeyer> mvo: Nice, thanks!
<joedborg> morning all, i'm trying to add some config options (i.e. snap get / set) to a snap.  am i right in saying that *all* of the logic for this is handled by snap/hooks/configure (including default options etc)?  I've seen `add-arg` in some over-ride builds
<niemeyer> mvo: Isn't the pagination design/API a general feature of GCE?
<niemeyer> mvo: In other words, will we be doing the same for every similar call?
<niemeyer> mvo: If so, should we integrate the feature in the 'do' method instead?
<niemeyer> mvo: I appreciate that in the original design the fiddling with the document is abstracted away: give a URL, obtain a Go value
<niemeyer> mvo: This is moving that slightly up the chain
<niemeyer> mvo: Maybe unavoidable, but worth considering at least
<mvo> niemeyer: thanks, thats great feedback. if you don't mind I put it into the PR and will look into moving it into the proper place
<zyga> joedborg: hello,yes, it's all doneby  the configure hook
<zyga> it's all done
<niemeyer> mvo: Of course, and sorry, should have mentioned there
<joedborg> zyga: so there's no way for a user to see what args are available to be set?
<joedborg> via the snap command i mean
<mvo> niemeyer: thanks! I explore this and get back to you :)
<zyga> joedborg: no, not at present, you can document that elsewhere in your snap but the system doesn't know about that yet
<joedborg> zyga: thanks
<zyga> joedborg: we were thinking about adding a schema to the configuration system but that work was de-prioritized for now
<joedborg> zyga: yeah i can see pros and cons with allowing it all to be handled in the hook, i've just hit a con in this instance :)
<joedborg> zyga: thanks for the help
<zyga> good luck!
<niemeyer> mvo: Thank you!
<ijohnson> cachio, Chipaca: I've now seen the google:ubuntu-core-16-64:tests/main/catalog-update test fail a few times, hitting the loop limit (yesterday and Monday as well), is that test susecptible to store outages?
<ijohnson> I realize there's some store stuff today with store outages, but not sure if we can/need to make that test more robust
<ijohnson> see https://api.travis-ci.org/v3/job/583566210/log.txt for example
<mup> PR snapcraft#2682 closed: tests: change default spread provider to lxd outside of travis <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2682>
<zyga> ijohnson: I tried to improve the catalog-update test a while ago
<zyga> let me pull the PR number
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/6174/files
<mup> PR #6174: many: add snap debug refresh-catalogs <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6174>
<zyga> perhaps something to revisit?
<ijohnson> zyga: yes I agree, we should revisit that I think
<cachio> ijohnson, hey, do you have a log for that?
<cachio> ijohnson, have a log
<cachio> ijohnson, I'll try to reproduce it
<zyga> cachio: what for?
<zyga> it's a known issue, when store is under load
<cachio> zyga, ah
<cachio> ok
<cachio> zyga, I thought it was something new
<zyga> cachio: the catalog update test is know, I didn't check if there are other failures there
<zyga> though now with store being partially up checking stuff is going to be painful
<cachio> zyga, following the log I think it could be caused  by load in the server
<mup> PR snapd#6174 opened: many: add snap debug refresh-catalogs <Created by zyga> <https://github.com/snapcore/snapd/pull/6174>
<zyga> ^ needs love though
<zyga> mvo: can I point your attention to https://github.com/snapcore/snapd/pull/7450 please
<mup> PR #7450: tests: debian sid now ships new seccomp, adjust tests <Simple ð> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/7450>
<ijohnson> cachio, zyga: yeah the log is above, and I think it's probably because the store was under load, but I've seen it fail in other circumstances as well with the same behavior
<zyga> it's green in travis but shows up red in github
<ijohnson> so I was just wondering what we can do about that test to either make it more clear why it's failing (i.e. store under load) or if it might be failing for some other reason
<ijohnson> zyga: is that test waiting on the unstable status?
<zyga> ah, perhaps that's the case
<zyga> it's only pushed back once all tests are done
<ijohnson> that would make sense
<zyga> hopefully soon
<mup> PR snapcraft#2711 opened: tests: print journal logs when spread tests fail <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2711>
<zyga> finally
<zyga> master should no longer always fail
<zyga> it's back to roll-a-dice
<mup> PR snapd#7450 closed: tests: debian sid now ships new seccomp, adjust tests <Simple ð> <â  Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7450>
 * ijohnson goes and gets his lucky dice
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/7449 is a bug fix so let's tag it as such
<mup> PR #7449: overlord/configstate: special-case "null" in transaction Changes() <Created by stolowski> <https://github.com/snapcore/snapd/pull/7449>
<zyga> pstolowski: if you want you can also report a bug number on lauchpad for some stats but I won't push you for that :)
<pstolowski> zyga: sure about tagging, i didn't know we do that
<zyga> pstolowski: I think it helps to prioritize reviews in some way
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/7446 please
<mup> PR #7446: tests/mountinfo-tool: proper formatting of opt_fields <Created by zyga> <https://github.com/snapcore/snapd/pull/7446>
<zyga> it's rather simple and close to unblocking another PR
<zyga> which will in turn unblock a few more
<pstolowski> zyga: no disagreement, +1
<zyga> ijohnson: can you look at https://github.com/snapcore/snapd/pull/7448 -- just at the rationale of the change
<mup> PR #7448: tests: remove mount_id and parent_id from mount-ns test data <Created by zyga> <https://github.com/snapcore/snapd/pull/7448>
<zyga> the actual "diff" is one liner here https://github.com/snapcore/snapd/pull/7448/files#diff-36e872aea1fc7dba34c7dfa820f13ac0R108 that effectively overrides the default and hides .mount_id .parent_id
 * cachio lunch
<sergiusens> zyga: hey, how do I reset connections? I removed a couple of interfaces and snap connections is still showing them after removing and reinstalling the snap
<zyga> I believe right now there is no user-facing way
<zyga> you'd have to edit the state
<zyga> cc mborzecki for ideas
<zyga> I think we discussed having something to do it
 * zyga switched to passive mode
<pedronis> we have some ideas in that area (also related to hotplug), but not implemented yet
<ijohnson> zyga: yes I had that on my list of things to review for you
<zyga> ijohnson: thank you so much!
<mup> PR snapcraft#2712 opened: snap: migrate to core18 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2712>
<mup> PR snapd#7109 closed: snap-confine: fallback gracefully on a cgroup v2 only system <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7109>
<mup> PR snapcraft#2711 closed: tests: print journal logs when spread tests fail <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2711>
<mup> PR snapd#7452 opened: tests/classic-ubuntu-core-transition*: move to nightly <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7452>
<mup> PR snapd#7453 opened: tests/classic-custom-device-reg: disable on opensuse-15 and fedora-30 <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7453>
#snappy 2019-09-12
<mup> PR snapd#7449 closed: overlord/configstate: special-case "null" in transaction Changes() <Bug> <Created by stolowski> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7449>
<mup> PR snapd#7454 opened: interfaces: extend the fwupd slot to be implicit on classic <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7454>
<mup> PR snapd#7455 opened: tests: moving ubuntu-core-transition tests to nightly test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7455>
<mborzecki> morning
<mborzecki> gorename has gone crazy since 1.13 update
<zyga> Morning school run
<mborzecki> zyga:  hey
<zyga> hey
<zyga> in the office now
<zyga> mborzecki: can you give me +1 on https://github.com/snapcore/snapd/pull/7446
<mup> PR #7446: tests/mountinfo-tool: proper formatting of opt_fields <Created by zyga> <https://github.com/snapcore/snapd/pull/7446>
<zyga> this will unblock the whole avalanche of related PRs
<mborzecki> zyga: started looking at it yday, but didn't finish bc of kids :/
<zyga> mborzecki: it's super easy, just fixes  formatting of the optional fields list to contain "-"
<zyga> thanks, I'll look at other stuff as well
<mborzecki> while at it i just pushed some updates to #7451
<mup> PR #7451: sandbox/cgroup: introduce cgroup wrappers package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7451>
<zyga> let's start with that
<zyga> good morning mvo
<mborzecki> mvo: hey
<mborzecki> zyga: tbh wondering what the distros still shipping py2 will do next year
<zyga> mborzecki: macos will remove python from the OS
<zyga> it's not used by the os itself, unlike on linux
<mborzecki> zyga: and perl i think?
<zyga> I think others will port / remove
<zyga> mborzecki: likewise
<zyga> ruby, perl and python are removed
<zyga> as is bash
<zyga> you can install them from the upstream distributions but the OS won't have them
<mborzecki> zyga: well, they were outdated anyway, so nobody used them?
<zyga> mborzecki: I think they were used
<zyga> even though outdated
<mvo> hey zyga and mborzecki !
<zyga> but nowadays it's docker / vms instead
<mup> PR snapd#7446 closed: tests/mountinfo-tool: proper formatting of opt_fields <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7446>
<mvo> tests more green today?
<zyga> mvo: not sure
<zyga> mvo: last night I restarted a single test like every 30 minutes
<zyga> all day
<zyga> so if something is green it's because blood, tears and mud
<mborzecki> it'd be nice if we could move google:ubuntu-18.04-64:tests/main/desktop-portal-filechooser to nitghtly too :/
<zyga> mvo: store had some issues frequently, there's lots of chatter in snapstore
<zyga> mborzecki: I think we need a different suite
<zyga> nightly is not a dumpster for stuff that is  broken
<zyga> we need a fragile suite
<zyga> nightly should never fail
<mborzecki> zyga: deskop-dumpster suite
<zyga> and if it fails, it's all hands on deck to fix
<zyga> otherwise nightly will degrade to that thing that is always red so we don't care
<mvo> yeah
<mborzecki> zyga: you're saying nightly is where the tests go to die? :)
<zyga> and then a real issue explodes on us and in a post-mortem someone will say, "this test failed in nightly for 3 weeks"
<mborzecki> 72 prs
<zyga> mvo: I commented on a related issue here https://github.com/snapcore/snapd/pull/7453
<zyga> mvo: I think we should be very careful with changes like that
<mup> PR #7453: tests/classic-custom-device-reg: disable on opensuse-15 and fedora-30 <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7453>
<zyga> a simple review https://github.com/snapcore/snapd/pull/7448
<mup> PR #7448: tests: remove mount_id and parent_id from mount-ns test data <Created by zyga> <https://github.com/snapcore/snapd/pull/7448>
<zyga> +2,505, -2,504
<zyga> it's a one line diff really :)
<mvo> zyga: yeah, we should blindly disable tests
<mvo> zyga: hm, master is red for the last ~5 runs or so - thats not good
<zyga> mvo: let's look at why
 * zyga checks
<zyga> I see LXD failure
<zyga> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<zyga> grep error: pattern not found, got:
<zyga> this is something I reported a few days ago
<zyga> that it really happens and indicates we're racing somewhere
<zyga> or perhaps that one of the mirrors has a corrupt LXD image?
<zyga> who knows but it's real
<mvo> zyga: oh, I saw this too in a branch of mine
<zyga> I'll save the log and look at past tests
<mvo> zyga: this was the lxd PR to move to the faster mirrors
<zyga> perhaps there's some clue there
<mborzecki> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks still happening oocassionaly inside lxd?
<zyga> yes
<zyga> error: cannot fetch snap signatures/assertions: cannot add assertion account-key (BWDEoaqyr25nF5SNCvEv2v7QnM9QsfCc0PBMYD_i2NGSQ32EF2d4D0hqUel3m8ul): failed signature verification: openpgp: invalid signature: hash tag doesn't match
<zyga> this is another, cannot prepare suite
<zyga> ubuntu-core assertion fetch failed because the signature was invalid
<zyga> another error
<zyga> error: Get https://api.snapcraft.io/api/v1/snaps/download/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_1797.snap: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "Let's Encrypt Authority X3")
<zyga> is the store really using a let's encrypt certificate?!
<zyga> that last error happened at least three times
<zyga> sanity check test failed, expected log message was not found in the journal
<zyga> mvo: I was thinking about that
<zyga> I think our journal handling is still bad
<zyga> and I was thinking that for the sake of robustness we could log to a file as well
<zyga> perhaps only under testing debug mode
<zyga> it would also help us on 14.04 where journal has weaker APIs and just doesn't do what we need many times
<zyga> - Consider re-refresh of "test-snapd-classic-confinement" (cannot query the store for updates: got unexpected HTTP status code 503 via POST to "https://api.snapcraft.io/v2/snaps/refresh")
<zyga> but this is when store was down
<zyga> error: cannot install "core16": cannot get device session from store: store
<zyga>        server returned status 503 and body "<html><body><h1>503 Service
<zyga>        Unavailable</h1>\nNo server is available to handle this
<zyga>        request.\n</body></html>\n"
<zyga> we apparently print the body of responses sometimes too?
<mvo> woah
<mvo> zyga: also "error: cannot fetch snap signatures/assertions: cannot add assertion account-key (BWDEoaqyr25nF5SNCvEv2v7QnM9QsfCc0PBMYD_i2NGSQ32EF2d4D0hqUel3m8ul): failed signature verification: openpgp: invalid signature: hash tag doesn't match"
<pstolowski> morning
<mvo> hey pstolowski
<mvo> zyga: I mean, *sigh*
<mvo> zyga: fwiw, the lxd error I also got in 7286
<mvo> zyga: and from looking at the logs I was wondering if its real so that the apparomor profile is not loaded by the postinst under certain circumstance
<zyga> Good morning PaweÅ
<mvo> zyga: *but* it all does not make sense and is hard to debug so I got a bit despaired
<zyga> pstolowski: last night Catalina update fixed VMware
<mvo> zyga: but yeah, it looks like the store was mightly unhappy last night
<zyga> mvo: in cases like this I would look at all the errors to see if something stands out more than others but then proceed to focus on a single case
<zyga> It does look grim when things are failing but we are not alone :)
<pedronis> as I said it would be good to have stasts on error frequency but it's work
<mvo> pedronis: you mean we should have stats on our side?
<mvo> pedronis: and good morning :)
<pedronis> which tests/hpw fail the most
<pedronis> *how
 * mvo nods
<mvo> zyga: uh - I see "Sep 11 20:27:08 sep112008-564525 snapd[16506]: Sep 11 20:27:05 sep112008-564525 systemd[1]: [/etc/systemd/system/snap-test\x2dsnapd\x2drsync-12.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'" in the logs. a agzillion of those
<mvo> zyga: looks like this was added in 232 but 16.04 has 229
<pedronis> ah
<pedronis> fun
<mborzecki> mvo: should be harmless though
<zyga> Oh man
<zyga> How come nothing failed on that?
<pedronis> we don't test for the behavior no?
<pedronis> it's just spamming the logs
<pedronis> I think
<pedronis> not failing to use the unit at all
<zyga> Should we revert it or extend it so that we perform the unmount ourselves, without involving systemd?
<mborzecki> looking into desktop-portal-filechooser, for some reasons this keeps failing quite often on 18.04 but not on later releases
<pedronis> mvo: I have 3 more seedwriter PRs ready (+1 very close), but they probabbly would not be helpful right now, I also the accumulated size would be scary
<pstolowski> a simple pr - https://github.com/snapcore/snapd/pull/7390 only adds a new test and is green but needs reviews
<mvo> pedronis: yeah, let me start looking at those
<mup> PR #7390: tests: unit test for a refresh failing on configure hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/7390>
<mvo> pedronis: I'm almost ready scheduling for paris
<mvo> mborzecki: the cgroup spread failure on i386 looks real (fwiw)
<mborzecki> mvo: do you have log?
<pedronis> pstolowski: hi,  #7196 can be simply closed now, no? we have #7092 waiting on snapcraft
<mup> PR #7196: packaging: use passthrough for type:snapd <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7196>
<mup> PR #7092: packaging: use snapd type and snapcraft 3.x <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>
<mborzecki> zyga: fwiw. looking at some things on amzn2, systemd complains about LazyUnmount, StartLimitInterval and FileDescriptorName, so it's a reasonable fallback behavior by systemd
<pstolowski> pedronis: yes, done
<mup> PR snapd#7196 closed: packaging: use passthrough for type:snapd <â Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7196>
<pedronis> mborzecki: zyga: do we still need #7198 ?
<mup> PR #7198: tests: reboot the node when restoring after a test involving lxd <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7198>
<mborzecki> pedronis: nope, we can close it
<mborzecki> let me do it
<Chipaca> moin moin
<pedronis> Chipaca: hi
<mup> PR snapd#7198 closed: tests: reboot the node when restoring after a test involving lxd <â Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7198>
<mborzecki> Chipaca: hey
<mborzecki> obviously desktop-portal-fielchooser does not fail when you try to debug what's happening :/
<zyga> mborzecki: than you
<pedronis> sergio has a PR about it, not sure what it does
<pedronis> mborzecki: what about #7193 ?
<mup> PR #7193: [WIP] cgroupsv2 spread run <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7193>
<mup> PR snapd#7452 closed: tests: move classic-ubuntu-core-transition* to nightly <Created by anonymouse64> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7452>
<mup> PR snapd#7455 closed: tests: moving ubuntu-core-transition tests to nightly test suite <Created by sergiocazzolato> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/7455>
<mborzecki> pedronis: i'd liek to keep it around to track the failing tests (also needs an update)
<pedronis> mborzecki: ok, that's fine, just wondered
<pedronis> Chipaca: are you aware of #7447 ?
<mup> PR #7447: snapstate: do not allow removal of the snapd snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/7447>
<Chipaca> the jumbo jet pr
<Chipaca> yeah let's not do it this way :-)
<Chipaca> I'll push a replacement for it and close this one
<Chipaca> â¦ as soon as i can get the current one green? or should i push it stacked? or ...?
<Chipaca> pedronis: question about canRemove: both baseInUse and coreInUse call snapstate.All, but handle failure differently: one returns false, the other returns err != ErrNoState. Which is the correct approach?
<pedronis> Chipaca: they probably both wrong
<Chipaca> pedronis: â¦ go on
<pedronis> let me look
<Chipaca> :) ok
<pedronis> but eating errors is never a good idea
<Chipaca> canremove would have to start bubbling the error out, in that case
<pedronis> Chipaca: is used in one place no?
<Chipaca> pedronis: right now yes
<pedronis> anyway let me look
<Chipaca> pedronis: i don't know why disable doesn't also check this though
<pedronis> Chipaca: disable is a use at your own peril op
<Chipaca> disable, the oft-forgotten ugly sibling
<pedronis> also because it's our turn it off/on again remedy tbh
<pedronis> or has been at least
<zyga> pstolowski: something for you
<zyga> https://www.irccloud.com/pastebin/yrr42wg7/
<pstolowski> zyga: uuuh
<pstolowski> zyga: is it on your box? state.json?
<zyga> pstolowski: https://bugs.launchpad.net/snapd/+bug/1843683
<zyga> nope, just spread on master
<mup> Bug #1843683: cannot unmarshal state entry for "timings" <snapd:Confirmed> <https://launchpad.net/bugs/1843683>
<zyga> since the 4.39e+08 is there, you can just write a test to see what happens
<pstolowski> zyga: ok, thanks, will investigate
<zyga> thank you
<pstolowski> zyga: is this now blocking master / happening all the time?
<zyga> no
<zyga> but feels dangerous since it may break state handling
<mvo> 6404 and 6839 are green and need a second review I think
<pstolowski> zyga: only on `snap debug timings ..`
<zyga> ah, that's good
<zyga> though I thought that was always on and collected?
<zyga> but perhaps I don't know well
<pstolowski> zyga: yes always collected but we dont' unmarshall them, only append raw messages
<pstolowski> regardless.. i'll investiagte today
<zyga> pstolowski: thank you!
<ackk> hi, is this the right place for multipass questions?
<mup> PR snapd#7456 opened: usersession/client: add a client library for the user session agent <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7456>
<zyga> ackk: ask away, Saviq is here
<zyga> https://github.com/snapcore/snapd/pull/7448 is green and would unblock me
<mup> PR #7448: tests: remove mount_id and parent_id from mount-ns test data <Created by zyga> <https://github.com/snapcore/snapd/pull/7448>
<ackk> Saviq, hi, I'm getting failures when trying to build a snap in multipass at the "apt update" phase, it seems it's trying to use ipv6 but failing contact the archive over ipv6
<Saviq> ackk: what version of Multipass?
<ackk> Saviq, I can ping that address from the machine where multipass runs. is there something to configure in multipass itself?
<Saviq> `multipass version`
<ackk> Saviq, installed:   0.9.0-dev.199+g69dad0f            (1135) 169MB classic
<ackk> and:
<ackk> multipass  0.9.0-dev.199+g69dad0f
<ackk> multipassd 0.9.0-dev.199+g69dad0f
<Saviq> ackk: go back to beta, we have a networking issue on edge
<ackk> oh, I'm on edge
<zyga> yay for channels
<ackk> Saviq, should I use stable or beta?
<Saviq> :)
<zyga> I think this is so fantastic
<ackk> zyga, +1
<Saviq> ackk: stable not there
<Saviq> Coming soon
<ackk> oh right :)
<ackk> sorry, haven't tried in in a while
<Saviq> zyga: even better, bisecting snap revisions ;)
 * ackk tries beta
<Chipaca> i need to pop round to the bank, will bbiab
<mborzecki> off for a bit
<ackk> sarnold, beta worked, thanks!
<ackk> err, Saviq ^
<Saviq> :)
<Saviq> I'm sure sarnold will be happy, too !)
<pedronis> mvo: I gave my +1 to 6404 and 6839 , I left a question in the latter though. They still need 2nd reviews
<mvo> pedronis: thank you! I will check if there is a missing test in 6839
<mup> PR snapd#7448 closed: tests: remove mount_id and parent_id from mount-ns test data <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7448>
<mborzecki> re
<zyga> https://github.com/snapcore/snapd/pull/7442/files shrank from 5K diff to 500 diff
<zyga> :)
<mup> PR #7442: tests: extend mount-ns test to handle mimics <Created by zyga> <https://github.com/snapcore/snapd/pull/7442>
<pedronis> pstolowski: I did another pass on #7277
<mup> PR #7277: overlord/snapstate: fix undo on firstboot seeding <Created by stolowski> <https://github.com/snapcore/snapd/pull/7277>
<pstolowski> pedronis: ty
<zyga> brb
<pstolowski> #7390 needs 2nd review, it's just a new test and green :}
<mup> PR #7390: tests: unit test for a refresh failing on configure hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/7390>
<pstolowski> nooo, koza is leaving
<Chipaca> was jonathan riddel on irc? anybody know their nick?
<pstolowski> Chipaca: the kde guy? jriddel afair, or maybe just riddel
<Chipaca> hm
<pstolowski> Chipaca: maybe you could take a look at #7390?
<mup> PR #7390: tests: unit test for a refresh failing on configure hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/7390>
<zyga> re
<zyga> sorry, some woes with daugther
<zyga> 10-year-olds and all that stuff
<Chipaca> pstolowski: in a bit yes
<mborzecki> zyga:  pffff desktop portals https://paste.ubuntu.com/p/VttStX82xQ/
<zyga> desktop-mortal
<zyga> jamesh: hello
<jamesh> zyga: hi
<zyga> are you still around by any chance? I know it's probably super late for you
<zyga> hey!
<zyga> mborzecki was looking at some of the failures in the xdg-desktop-portal test, specifically on 18.04
<zyga> and concluded that it is likely that this specific version 0.11 of the portal is just buggy
<zyga> how likely is to backport the portal stack to 18.04
<mborzecki> zyga: jamesh: actually 1.0.3 was pushed to 18.04, but the issue persists
<zyga> and if unlikely, should we formally support it at the current version?
<jamesh> mborzecki: 1.0.3 is in bionic-updates
<jamesh> oh.
<jamesh> We'll definitely want to upgrade for the snap support improvement work I haven't started
 * pstolowski bbiab
<cjwatson> Chipaca: Riddell, two ls
<Chipaca> ah
<cjwatson> (that was their nick as well as their surname.  Dunno if they're still on IRC)
 * Chipaca bad with names
<jamesh> mborzecki, zyga: the only patch to the document portal FUSE code missing from the Bionic packages is this one: https://github.com/flatpak/xdg-desktop-portal/commit/c9159903e151d5aba3067dcaeb977ceb9a1a9e8b#diff-113fd392ffd1391fc2e8547af3dd1789
<mborzecki> jamesh: so 2 problems we have now, 1. when the test code in desktop-portal-filechooser closes the fd it writes to, the content cannot be immediately read from the actual file, but after waiting for a bit it does appear there (some race with closing/flushing data in xdp in the portal)?
<mborzecki> jamesh: then 2nd. occasionally we get OSError with -ENOSYS when the file did not exist pefore it was picked for saving-to (the same test)
<jamesh> mborzecki: I wonder if the link count could affect that first one?
<mborzecki> jamesh: i've started a portal separately with G_MESSAGES_DEBUG=all, replaced the one running in test user's session, but cannot reproduce the problem this way, so maybe a race again
<zyga> perhaps all versions are buggy then?
<zyga> mborzecki: does that test run on anything more recent than 18.04?
<mborzecki> zyga: yes, 19.04 and 19.10, haven't really seen issues on 19.10
<zyga> mmm
<mborzecki> jamesh: maybe that's a data point then
<zyga> so it's a real thing then
<jamesh> mborzecki: It's quite possible that there is a problem outside of the xdg-desktop-portal code too
<jamesh> mborzecki: this is the other change to document-portal-fuse.c between 1.0.3 and master: https://github.com/flatpak/xdg-desktop-portal/pull/310
<mup> PR flatpak/xdg-desktop-portal#310: document-portal: make xdp_inode_kernel_unref check that kernel_ref_count > 0 <Created by jhenstridge> <Merged by alexlarsson> <https://github.com/flatpak/xdg-desktop-portal/pull/310>
<jamesh> which we included in the Bionic package
<jamesh> I don't think we ever worked out the root cause for that
<jamesh> it is possible that it's a bug in the bionic kernel
<mborzecki> jamesh: another data point, i can't really reproduce any of the problems by stating the portal manually, but happens regularly when it's started by user systemd
<mborzecki> jamesh: https://paste.ubuntu.com/p/P7Jj5BVsgz/ captured when rename happens after fuse_release, so the content is not really available yet
<jamesh> mborzecki: the kernel unref PR I mentioned earlier is something that shouldn't be necessary: it essentially means that the fuse filesystem and kernel disagree about the kernel-side reference count of an inode
<jamesh> mborzecki: it's something I haven't been able to reproduce on any other distro release
<jamesh> if there is some bug in the kernel-side fuse code for that release, it could very well lead to this kind of problem
<mup> PR snapd#7390 closed: tests: unit test for a refresh failing on configure hook <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7390>
<ackk> does snapcraft need to use the lxd snap or can it use an already set up lxd?
<Chipaca> whoops, just spotted a bug in the model pr
 * Chipaca pokes at it
<mborzecki> zyga: left a coment https://github.com/snapcore/snapd/pull/7442#discussion_r323712211
<mup> PR #7442: tests: extend mount-ns test to handle mimics <Created by zyga> <https://github.com/snapcore/snapd/pull/7442>
<mborzecki> zyga: fwiw, core18 mounts seem ok, though with /usr/share/gdb you'd have just 2 entries
<zyga> yeah, I will change that
<zyga> I made progress on https://github.com/snapcore/snapd/pull/7421
<mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
<zyga> check out the pretty red diff there :)
<zyga> re
<zyga> mvo: sorry, daughter had existential problems related to lunch
<zyga> mvo: needed to have a walk and talk to her
<zyga> uh :)
<cwayne> zyga: who doesnt have the occasional mid-lunch crisis :P
<Chipaca> ijohnson: ah just saw your last question, and you're right i hadn't replied
<ijohnson> np, thanks for clarifying
<Chipaca> ijohnson: let me clarify more just in case
 * ijohnson needs to get a cup of coffee then will read through
<Chipaca> ijohnson: _if_ the output is yamlish, and _if_ the value needs to start with "- ", then yes use esc.dash
<pedronis> it might be our case there
<Chipaca> ijohnson: e.g. in 'snap info', we use esc.dash for "this channel is closed" (e.g. stable in 'snap info multipass'), but not for the - at the end of a channel line
<ijohnson_> okay, thanks Chipaca for that explanation
<Chipaca> ijohnson_: short answer: copy the output without the dash into http://yaml-online-parser.appspot.com/ and if it complains, change it to dash
<ijohnson_> yes for the `snap model --verbose` we will hit that case where the output is yamlish and the value starts with "- (..."
<mup> PR snapcraft#2708 closed: tools: make environment-setup container name and image configurable <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2708>
<pstolowski> oh well, fun with json, i feel that https://bugs.launchpad.net/snapd/+bug/1843683 is a tip of an iceberg
<mup> Bug #1843683: cannot unmarshal state entry for "timings" <snapd:In Progress by stolowski> <https://launchpad.net/bugs/1843683>
<pstolowski> fun fact: the only way to unmarshall something like 4.39e+08 is to have float in struct; using DecodeWithNumber doesn't help
<mvo> niemeyer: hey, we talked yesterday about pagination support for the spread google backend and you suggested to look into something more generic. I did that and pushed https://github.com/snapcore/spread/pull/87 - it would be great if you could have a look and tell me if that is what you had in mind. no need for a in-depth review yet, just a check. if you think this should be the path forward I will polish it a bit and add more tests. if you prefer
<mvo>  the simpler approach in pr69 thats also fine of course :)
<mup> PR spread#87: google: add generic pagination support on GCE results <Created by mvo5> <https://github.com/snapcore/spread/pull/87>
<pstolowski> while i can change durations in debug timings to float64 both in timing definition and in the client to make everything happy end-to-end (and it's backward compatible change), we may have similiar problem with doing/undoing time on tasks. but what made json marshaller use 4.39e+08 out of sudden to encode int64 duration in the state is still mistery to me
 * cachio bank
<cachio> and lunch
<niemeyer> mvo: Yeah, that's the direction indeed
<niemeyer> mvo: Would be nice to avoid reflecting, but I'm not entirely sure how
<mvo> niemeyer: yeah, the reflection is a bit ugly, I couldn't think of a better way though. I keep meditating over it :)
<niemeyer> mvo: Sent a note in the PR
<mvo> thanks niemeyer
<niemeyer> mvo: One option to avoid both would be to do smoething like dofl(........, &foo.TheItemsField)
<niemeyer> mvo: This would enable pagination and provide the field in one go.. I don't know how realistic that is, though.. I thought about it for 10 seconds only
<mvo> niemeyer: thats fine, thanks for the suggestions! I will experiment and see how far I get and if I can eliminate reflection entirely (or mostly). no worries, I ping you again once I had a chance to update it
<niemeyer> mvo: Yeah, entirely is probably not doable as the slice extension needs to take place, but to a good degree maybe
<mvo> niemeyer: indeed
<mup> PR snapd#7453 closed: tests/classic-custom-device-reg: disable on opensuse-15 and fedora-30 <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7453>
<ijohnson_> zyga: are you planning on changing the directory to one that has less diff between core/core18 in #7442 ?
<mup> PR #7442: tests: extend mount-ns test to handle mimics <Created by zyga> <https://github.com/snapcore/snapd/pull/7442>
<ijohnson_> Chipaca, pedronis, for `snap model --verbose`, both brand and brand-id will be in the output, but which should come first?
<ijohnson_> looks a little better with brand first I think
<ijohnson_> see https://pastebin.ubuntu.com/p/Kk48mvwBMq/ for output with brand first
<zyga> mborzecki: I will look
<zyga> ijohnson_: yes,
<zyga> ijohnson_: just AFK on child care
<ijohnson_> no rush zyga, just curious if I should wait to review that
<ijohnson_> sounds like yes wait to review
<ijohnson_> thanks
<zyga> ijohnson_: yeah, please wait a few hours
<ijohnson_> np
<zyga> thank you for checking
<pedronis> ijohnson_: I'm not quite sure I understood that suggestion from John myself, we might have to chat with him tomorrow
<ijohnson_> pedronis: hmm ok well do you want me to add it to the PR or leave it out for now?
<pedronis> ijohnson_: let the code stay as however it is at the moment, we can tweak tomorrow/in a follow up
<pedronis> also maybe Chipaca is still around
<ijohnson_> ack
<ijohnson_> he said he EOD in the other channel a bit ago
<pedronis> ah ok
<ijohnson_> it's just 4 lines of code so it's real easy to add back if desired
<pedronis> ijohnson_: anyway I gave some input if we go there
<ijohnson_> thanks
 * ijohnson_ lunches
<ardaguclu_> Is snap-failure executable deprecated?
<mup> PR snapd#7351 closed: tests: retry checking until the written file on desktop-portal-filechooser <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7351>
<mup> PR snapd#6404 closed: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6404>
<mvo> zyga: mind if I do the bits that john asked for in 6174?
<ijohnson_> hey cachio, does kill-timout for a task apply to prepare and execute? do both parts have to come in under kill-timeout or does it apply to both separately?
<cachio> ijohnson_, kill timeout is for the whole task
<ijohnson_> okay, I'm thinking about opening a PR changing the kill-timeout for some tasks from like 2m or 3m to double that because the tests keep getting killed while trying to download a snap from the store or something like that
<cachio> ijohnson_, you can set kill-timeout: 60m for the task
<cachio> let me check in the code
<ijohnson_> cachio, no not for debugging, like permanently I was thinking
<ijohnson_> just because it seems to be happening so much
<cachio> ijohnson_, the idea is to have at least 5 minutes depending on the task
<cachio> by default it is 20
<cachio> ijohnson_, which task is timingout?
<ijohnson_> I've seen tests/main/snap-wait, classic-custom-device-reg some of the ubuntu-core-transition tasks probably others I can't remember
<cachio> ijohnson_, you are right kill-timeout: 2m
<cachio> it should be at lest 5m
<cachio> at some point I updated all the timeouts
<cachio> to 5m
<ijohnson_> hmm
<cachio> this is new
<ijohnson_> I'll submit a PR with all the ones less than 2m upped to 5m
<cachio> also happens that in the boards it usually takes more time
<ijohnson_> but I'll ask in SU tomorrow if there's a good reason any of the tests should be less than 5m
<cachio> and 2m is not enough
<ijohnson_> right
<cachio> ijohnson_, please submit the PR
<cachio> that's really appreciated
<ijohnson_> ack
<ijohnson_> cachio: it would be kind of nice if you could somehow configure the timeout to be more time on slower hardware, like perhaps a per-system or per-backend timeout
<ijohnson_> cachio: opened PR #7457
<mup> PR #7457: tests/main/many: increase kill-timeout to 5m <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7457>
<mup> PR snapd#7457 opened: tests/main/many: increase kill-timeout to 5m <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7457>
<cachio> ijohnson_, thanks taking a look
<mfeatherston> Is there anything going on with the servers?  I'm trying to "snapcraft register-key" and keep getting "The Snap Store encountered an error while processing your request: internal server error (code 500).".  If I enter the wrong username/password it notices that, but fails with this message when I give it the correct login
<roadmr> mfeatherston: checking, hang on
<roadmr> mfeatherston: a favor if you can - can you run SNAPCRAFT_ENABLE_DEVELOPER_DEBUG=yes snapcraft register-key (and specify a correct login) ? that might give more info about that 500
<roadmr> mfeatherston: I'm checking logs on my side as well
<roadmr> mfeatherston? where'd you go?!?! ð¤
<roadmr> mfeatherston: you can use a pastebin service to post long logs
<Chipaca> ijohnson_: I stepped away, I hadn't _quite_ EOD'ed yet
<Chipaca> just went for a run
<Chipaca> but now i'm back
<Chipaca> well, technically i was back half an hour ago also, but, eww stinky
<ijohnson_> Chipaca: np, I mean it does seem reasonable for you to EOD when you did
<Chipaca> soft-EOD because I had some threads still going
<Chipaca> :)
<Chipaca> also runs sometimes clear the head and you come back ready to break things
<ijohnson_> true that
<ijohnson_> so did you mean for brand and brand-id to both be displayed with `snap model --verbose` ?
<Chipaca> ijohnson_: i suspect we need to sync with pedronis because that's what I understood _him_ to say :-) and it seemed reasonable to me
<Chipaca> so maybe i'm missing something
<ijohnson_> haha okay
<Chipaca> I mean, his comment about
 * Chipaca looks for it
<ijohnson_> well I commented with potential outputs on the PR to look at
<Chipaca> 'my original proposal would do this also if x.Verbose,'
<Chipaca> the one i replied to in fact
<Chipaca> doing that "also if x.Verbose" means printing brand-id when verbose even if not --serial
<Chipaca> right?
<ijohnson_> that's what I understood him to mean as well
<Chipaca> the other thing in the if he commented on was already being printed
<ijohnson_> I think pedronis' most recent point is fair though about if we do both brand and brand-id we should drop the `(...)` from brand if it exists
<Chipaca> sigh :)
<Chipaca> i think i'm going to go have a curry and let the universe think about what it's done
<sergiusens> cachio: hey, can you tell me what this means https://travis-ci.org/snapcore/snapcraft/jobs/584308760 ?
<mup> PR snapd#7458 opened: interfaces/kubernetes-support: allow systemd-run to ptrace read unconfined <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7458>
<mup> PR snapd#7459 opened: interfaces/kubernetes-support: allow systemd-run to ptrace read unconfined - 2.41 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7459>
<mup> PR snapd#7459 closed: interfaces/kubernetes-support: allow systemd-run to ptrace read unconfined - 2.41 <Simple ð> <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/7459>
<mup> PR snapd#7460 opened: interfaces/kubernetes-support: allow systemd-run to ptrace read unconfind - 2.41 <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7460>
<mup> PR snapcraft#2713 opened: tests: completely mock bzr tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2713>
#snappy 2019-09-13
<mup> PR snapcraft#2686 closed: New app handler (command-chain and no wrappers if command allows for it) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2686>
<mup> PR snapcraft#2560 closed: meta: do not wrap commands by default <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2560>
<mborzecki> morning
<mup> PR snapd#7457 closed: tests/main/many: increase kill-timeout to 5m <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7457>
<mup> PR snapd#7458 closed: interfaces/kubernetes-support: allow systemd-run to ptrace read unconfined <Simple ð> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7458>
<mborzecki> mvo: morning
<mvo> mborzecki: hey, good morning!
<zyga> Biking home
<mvo> hey zyga
<mvo> zyga: nice, already doing a workout?
<zyga> yes
<zyga> every morning
<zyga> uff :)
<zyga> this and a standing desk does work wonders
<zyga> and every time I complain about my back it's really when I was lazy and skipped one or the other
<zyga> mvo: I'm sorry about not finishing work last night, I went to bed at 9
<zyga> last day before paris
<zyga> let's make it count!
<mborzecki> brb, new kernel (and gnome)
<mborzecki> re
<mvo> mborzecki: you look into 7133 further? should we merge as is and you build on top? or do you want to work in the PR?
<mborzecki> mvo: left anote and merged it
<mup> PR snapd#7133 closed: overlord,daemon: adjust startup timeout via EXTEND_TIMEOUT_USEC using an estimate <Created by pedronis> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7133>
<mborzecki> mvo: systemd does not update TimeoutStartUSec even though snapd requests more time, perhaps that's how it's suposed to work anyway
<mborzecki>     - google-unstable:ubuntu-19.10-64:tests/main/interfaces-calendar-service
<mborzecki>     - google-unstable:ubuntu-19.10-64:tests/main/interfaces-contacts-service
<mborzecki>     - google-unstable:ubuntu-19.10-64:tests/unit/go
<mborzecki> these fail on 19.10
<mborzecki> unit/go fails bc of gofmt
<pstolowski> morning
<ackk> zyga, hi, is there a workaround for that limitation about only allowing home directories under /home in snaps?
<ackk> zyga, I'm trying to use "lxc" from a jenkins job, but the jenkins user has home set to /var/lib/jenkins, so it fails
<zyga> ackk: only one from the user, that is, to bind-mount the actual home directory to /home/$LOGNAME/
<ackk> zyga, I see
<ackk> thanks
<mborzecki> pstolowski: hey
<ackk> zyga, I also need to update the passwd though?
<zyga> ackk: not really
<zyga> well
<zyga> it's up to you
<ackk> zyga, it's not working here
<zyga> all that you need to ensure that anywhere your actual $HOME points
<zyga> there's a bind mount of that to /home/$LOGNAME
<zyga> hmm
<zyga> on second though
<zyga> thought
<zyga> yes, please update passwd
<zyga> that's something we don't manage
<zyga> I'll make a note
<zyga> we have some ideas how to map that internally but that might be derailed by gecos
<ackk> zyga, ok, that seems to work, but not it seems snapcraft is looking for build-packages on the host
<ackk> not in the container
<ackk> oh, it seems the proxy config is not forwarded to the container :/
<ackk> same issue I was hitting with multipass
<mup> PR snapd#7461 opened: run-checks, tests/main/go: allow gofmt checks to be skipped on 19.10 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7461>
<rogpeppe> zyga: FYI that pi is still going down at regular intervals, despite scheduling the updates only to be done once a month :-\
<zyga> rogpeppe: that's not good, can you give us the scheduling string please
<zyga> rogpeppe: as well as "snap changes"
<rogpeppe> zyga: will do, when it gets restarted again
<zyga> rogpeppe: I procured another PI and I can now replicate your setup
<rogpeppe> zyga: have you managed to replicate any of the issues i've been seeing?
<zyga> rogpeppe: not yet, I needed to get the right hardware first
<rogpeppe> zyga: ok, cool
<zyga> rogpeppe: and I was doing other fixes in the meantime
<zyga> rogpeppe: I will put regular core-18 on the device and then load your uboot.env to see what it claims
<zyga> then I plan to get the same kernel / base
<zyga> and same try mode kernel and base
<zyga> and see if I can reboot correctly
<zyga> with serial attached and all that
<rogpeppe> zyga: i'm fascinated to find out if it all works just fine for you :)
<zyga> rogpeppe: I hope it doesn't
<zyga> rogpeppe: it's much harder to fix something that works for me
<zyga> :)
<pedronis> mvo: I answered to https://github.com/snapcore/snapd/pull/7416#discussion_r324077826  probably degville or Chipaca's input on that is valuable
<mup> PR #7416: seed/seedwriter: start of Writer and internal policy16/tree16 <Created by pedronis> <https://github.com/snapcore/snapd/pull/7416>
<degville> pedronis: I'll take a look.
<zyga> mborzecki: I tweaked https://github.com/snapcore/snapd/pull/7442 based on your idea earlier
<mup> PR #7442: tests: extend mount-ns test to handle mimics <Created by zyga> <https://github.com/snapcore/snapd/pull/7442>
<zyga> the diff is short and pretty comprehensible
<pedronis> degville: thanks
<degville> pedronis: np.
<mvo> pedronis: yeah, sorry for the bikesheed there
<mvo> pedronis: aha, sorry, I missed part of the information. its snaps coming from the new "options" file, I missed that piece. let me medidate a bit but with that my suggestions are indeed not good
<pedronis> mvo: not from a file, but is snaps coming from ubuntu-image --snaps
<pedronis> or anything external from the model really
<mvo> pedronis: yeah, I get it now
<pedronis> given that is quite generic and ubuntu-image/prepare-image are just the first use case
<mvo> pedronis: sorry, that was not clear to me, let me comment in the PR but with that my comment does not make much sense anymore
<mvo> pedronis: +1
<pedronis> mvo: to be fair as I said the doc comment is not super clear
<pedronis> and I should fix it
<pedronis> also OptionsSnap might be less confusable with optional snap
<mvo> pedronis: yeah, I like that
<mvo> pedronis: and +1 on a comment fix, maybe with a small example like "E.g. OptionsSnaps may come via ubuntu-image --snaps ..."
<pedronis> yea, as I said I might leave a todo for the actual rename to do later in the chain
<pedronis> because otherwise I fear conflicts
<pedronis> all over the place
<pedronis> in it
<ackk> how do I run a clean build with snapcraft --use-lxd ?
<zyga> ackk: I'm not sure, sorry, perhaps one of the others knows
<mvo> pedronis: +1
<zyga> hey
<zyga> a quick question
<zyga> does anyone know of "git diff" like tool
<zyga> that shows differences inside one line
<zyga> like what github can do
<ackk> emacs :)
<zyga> any command I can try to see it
<ackk> zyga, perhaps git diff --word-diff does what you want? https://makandracards.com/makandra/6585-git-diff-changes-in-a-long-line-efficiently
<zyga> I'm not after a two semester curriculum ;)
<zyga> oh, that's probably exactly that, thank you so much
<ackk> np, TIL too
 * Chipaca goes for coffee
<mup> PR snapd#7462 opened: asserts: introduce explicit support for grade for Core 20 models <Created by pedronis> <https://github.com/snapcore/snapd/pull/7462>
<mup> PR snapd#7463 opened: tests/main/interfaces-{calendar,contacts}-service: disable on 19.10 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7463>
 * Chipaca *really* goes for coffee
<Chipaca> augh
<mup> PR snapd#7460 closed: interfaces/kubernetes-support: allow systemd-run to ptrace read unconfined - 2.41 <Simple ð> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7460>
<pstolowski> Chipaca: hey, wdyt about https://bugs.launchpad.net/snapd/+bug/1843725 ? should we simply de-duplicate args or error out right away with "nonsense argument given"?
<mup> Bug #1843725: snap install with duplicated snap names gives confusing errors <snapd:Confirmed> <https://launchpad.net/bugs/1843725>
<Chipaca> pstolowski: we need to make electrified keyboards mandatory
<pstolowski> Chipaca: :)
<Chipaca> pstolowski: more serious answer involves better checking for this case in both snapstate and cmd/snap
<Chipaca> pstolowski: -1 to de-duplication
<pedronis> mvo: applied feedback: https://github.com/snapcore/snapd/pull/7416/commits/fea6a6c7f694b9489f6655c1af66209f76ba576b
<mup> PR #7416: seed/seedwriter: start of Writer and internal policy16/tree16 <Created by pedronis> <https://github.com/snapcore/snapd/pull/7416>
<Chipaca> zyga: about in-line diff tool
<Chipaca> zyga: it's in git itself, but not built
<Chipaca> zyga: $ git config --get core.pager
<Chipaca> /home/john/bin/diff-highlight | less
<Chipaca> zyga: diff-highlight is /usr/share/doc/git/contrib/diff-highlight
<zyga> thanks, I'll check that out
<Chipaca> zyga: OTOH, snap install icdiff, git icdiff
<zyga> it will come in handy for some of the changes I'm doing :)
<Chipaca> zyga: side-by-side diff with in-line highlighting
<Chipaca> zyga: something's buggy with the pager detection in icdiff so you want to set icdiff.pager explicitly, I need to dig into that this weekend
<Chipaca> but it's otherwise good :-)
<zyga> I'll check it out but I think you're way ahead of me :)
<pstolowski> Chipaca: thanks for feedback on the bug
<zyga> the diff on https://github.com/snapcore/snapd/pull/7436/files _finally_ makes some sense
<mup> PR #7436: many: make per-snap mount namespace MS_SHARED <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7436>
<zyga> I need to double check that it's good
<zyga> but I feel this branch is close
<zyga> mborzecki: yeah, as I thought
<zyga> mborzecki: I think we still got sharing wrong, even with MS_SHARED
<zyga> the per-user stuff is not a real slave
<zyga> it's still bi-directional
<zyga> I need to check that
<zyga> it seems wrong
<zyga> and indicates more tests needed
<zyga> mborzecki: I commented out the MS_SLAVED | MS_REC change for the per-user mount namespace
<zyga> I wonder if it doesn't work
<zyga> I want to see the effect it has
<Chipaca> pedronis: wrt your comment about gadgets having bases, does that mean a gadget without an explicit base needs core?
<pedronis> Chipaca: yes
<Chipaca> pedronis: was there a special value of base that meant "no base needed"?
<pedronis> none
<mup> PR snapd#6839 closed: devicestate: allow remodel to different kernels  <Remodel :train:> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6839>
<pedronis> but we implemented it but is not used
<mborzecki> zyga:  can you take another look at https://github.com/snapcore/snapd/pull/7451 ?
<mup> PR #7451: sandbox/cgroup: introduce cgroup wrappers package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7451>
<zyga> yes, sorry
<zyga> looking now
<Chipaca> pedronis: the string "none"?
<pedronis> the string "none" yes
<Chipaca> pedronis: all these changes to canremove, should they go into the same refactor pr?
<pedronis> Chipaca: as you prefer
<mup> PR snapd#7464 opened: snapstate: add missing tests for checkGadgetOrKernel <Created by mvo5> <https://github.com/snapcore/snapd/pull/7464>
<zyga> mborzecki: only small remark about capitalizing sentences and stuff like that
<mborzecki> zyga: ack, thx
<zyga> mborzecki: sent now
<zyga> https://github.com/snapcore/snapd/pull/7451#pullrequestreview-287952596
<mup> PR #7451: sandbox/cgroup: introduce cgroup wrappers package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7451>
<zyga> I'd like to land https://github.com/snapcore/snapd/pull/7442 -- it will show up more behavior of the sharing bug in the next PR
<mup> PR #7442: tests: extend mount-ns test to handle mimics <Created by zyga> <https://github.com/snapcore/snapd/pull/7442>
<mup> PR snapd#7465 opened: snap-confine: fix return value checks for udev functions <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7465>
<zyga> oh, interesting mvo
<zyga> I had a look at this code recently, let me double check if this bug is there too
<zyga> thank you!
<zyga> daaaaaaaaaaaaaaaaaaaaaaaaaaaaamn
<zyga> aww crap :)
<Chipaca> zyga: ...?
<zyga> Chipaca: I removed one line from snap-confine
<zyga> and ... no change to tests
<zyga> it's a dead line
<zyga> but one we hoped not to be dead
<zyga> I'll check out what's going on next
<mup> PR snapd#7466 opened: cmd/snap: special handling of snap set refresh.hold <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7466>
<zyga> test rolling now
<mborzecki> wonder what do you guys thing about 7466
<zyga> yeah, another bug
<zyga> maaaaan
<zyga> tests
<Chipaca> mborzecki: +1; 'hold' feels like a duration anyway
<zyga> thank you
<Chipaca> zyga: https://www.youtube.com/watch?v=dpWmlRNfLck but with 'tests'
<zyga> mvo: so, we have another bug, not sure how we never noticed before
<mborzecki> zyga: where?
<zyga> https://www.irccloud.com/pastebin/2UL7crS0/
<zyga> this has absolutely no impact
<mborzecki> hah
<zyga> I was digging at something that showed up in the MS_SHARED test
<zyga> it was showing something that made no sense
<zyga> so I kept digging
<zyga> and now this
<mborzecki> zyga: mayeb the tests are too limited to catch whetehr this has any impact or not
<zyga> no
<zyga> they 100% would catch this
<Chipaca> zyga: could it be a 1404ism?
<Chipaca> or something like that?
<zyga> 1404, no
<zyga> it's really not working
<zyga> I'll write a test
<Chipaca> eh, ok
<zyga> sucky
<Chipaca> i'm going to go make lunch and let you have your fun
<Chipaca> mmmmmmmmmmmmm lunch
<zyga> but yeah, little by little test show crap
 * Chipaca needs food
<zyga> oh, I'm hungry now
<zyga> don't tell me about food please
 * Chipaca was about to, but stops
<cachio> sergiusens, hey
<Chipaca> zyga: I'll tell you that i'm hungry because apparently running 30k makes me hungry for more than 12 hours
<cachio> sergiusens, about https://travis-ci.org/snapcore/snapcraft/jobs/584308760#L175 error
<Chipaca> zyga: or maybe it's just my excuse :-)
<zyga> Chipaca: congratulations, that's nice!
 * Chipaca goes
<sergiusens> hello!
<cachio> sergiusens, this seems to be missing the key to connect to gce
<cachio> sergiusens, is this a new travis job?
<sergiusens> yes and no
<cachio> sergiusens, what's the new part?
<sergiusens> cachio: https://travis-ci.org/snapcore/snapcraft/builds/584308757/config I moved the unit tests into spread https://github.com/snapcore/snapcraft/pull/2712/commits/b871fd4777d690a3b51c858084e03d27184f33e8
<mup> PR snapcraft#2712: snap: migrate to core18 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2712>
<sergiusens> cachio: in the second link
<sergiusens> cachio: hmm, the only difference is that I am using the snap for spread compared to just downloading it for the spread task that works
<cachio> so, you didn't change the project
<cachio> or the google key?
<cachio> right
<cachio> # SPREAD_GOOGLE_KEY
<sergiusens> cachio: do you use the spread snap for your jobs?
<cachio> sergiusens, I really don't know how spread snap could affect
<cachio> we dont we it
<cachio> we download the bin
<sergiusens> hah, that might explain it
<sergiusens> is the spread snap known to be working?
<zyga> sergiusens: I don't know if it is maintained
<zyga> would be good to check revision history
<cachio> sergiusens, we don't use it, and we don't maintain this
<cachio> sergiusens, so, not sure
<cachio> sergiusens, niemeyer could kno
<cachio> w
<zyga> mborzecki: and I know why that is now too
<pedronis> sergiusens: I do use the snap locally
<pedronis> it's old though apparently
<sergiusens> pedronis: and it reads your google key just fine when exported into the environment?
<pedronis> yes
<pedronis> I just used it yesterday
<sergiusens> ok, I will continue checking to see if it is something else, but this is the only diference between a job that works and one that does not on travis
<mup> PR snapd#7467 opened: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7467>
<mup> PR snapd#7468 opened: seed/seedwriter: support local snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7468>
<mup> PR snapd#7469 opened: seed/seedwriter,snap/naming: support classic models  <Created by pedronis> <https://github.com/snapcore/snapd/pull/7469>
<Chipaca> pedronis: that's a long chain of PRs :-(
<mup> PR snapd#7423 closed: overlord/snapstate: config revision code cleanup and extra tests <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7423>
<pedronis> Chipaca: it's not even the end of it, but I'll try not to push more up today
<Chipaca> heh
<pedronis> Chipaca: it's not visible atm but except the first one that mvo skimmed they are all reasonably sized
<pedronis> that's why they are many
<Chipaca> pedronis: cool
<Chipaca> pedronis: i'm reviewing 7416 fwiw
<pedronis> Chipaca: indeed that's the start and the biggest one
<pedronis> thank you
<pedronis> Chipaca: I pushed some more in case people want to see where things head to review the start
<pedronis> btw
<pedronis> in case
<pedronis> as well
<Chipaca> very confusing that asserts' core snaps are type "core"
<Chipaca> (well, that's not the confusing bit, but ykwim)
<pedronis> Chipaca: we could probably do something in types.go
<pedronis> anyway there is exactly two snaps with type "os"
<Chipaca> :)
<pedronis> (not counting strange test ones)
<Chipaca> pedronis: wouldn't "AdditionalSnap" have been clearer for OptionsSnap?
<pedronis> Chipaca: they are not additional
<pedronis> they can also tweak model ones
<pedronis> you can see --snap core=edge
<pedronis> core is not additional there
<pedronis> s/see/say/
<Chipaca> pedronis: unrelatedly, you know how to write graphviz graphs, yes?
<pedronis> yes
<Chipaca> pedronis: graph-easy produces ASCII output from 'em
<Chipaca> pedronis: as in sudo apt install libgraph-easy-perl
<pedronis> didn't know that
<Chipaca> then 'graph-easy foo.dot' â ascii graph
<mup> PR snapd#7408 closed: tests: fix interfaces-timeserver-control on 19.10 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7408>
<mup> PR snapd#7126 closed: tests: part3 making tests work on ubuntu-core-18 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7126>
<Chipaca> pedronis: looking at that graph, is the line on the left that goes from Start to SnapsToDownload supposed to be there? The 'no local snaps' label seems to be about the one immediately to its right that goes from LocalSnaps to SnapsToDownload
<Chipaca> and the leftmost one just mirrors the rightmost one
<Chipaca> ok my lunch smells ready now
 * Chipaca grabs a bowl
<pedronis> Chipaca: right side jumps: if you didn't call SetOptionsSnaps, you can jump straight from Start to SnapsToDownload, left side jumps: if you called it but none of them where local you can also do that, if you don't have local snaps you can also skip InfoDerived even if you called LocalSnaps
<pedronis> the right side one is a bit redundant, if you have no option snaps then of course you don't local either
<mup> PR snapd#7470 opened: DRAFT: core20 snap install <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7470>
<mup> PR snapd#7463 closed: tests/main/interfaces-{calendar,contacts}-service: disable on 19.10 <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7463>
<mup> PR snapd#7471 opened: tests: fix newline and wrong test name pointed out in previous PRs <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7471>
<zyga> ijohnson: hey, I know it's not fair because I don't review much lately but  https://github.com/snapcore/snapd/pull/7442 is +60,-0 and I've addressed your comments now
<mup> PR #7442: tests: extend mount-ns test to handle mimics <Created by zyga> <https://github.com/snapcore/snapd/pull/7442>
<ijohnson> zyga: sure happy to take a look
<Psil0Cybin> Hey guys can someone guide me through an install of Snappy to install an app for Kali Linux , problem "home is not in /home/user its just in /user"
<Psil0Cybin> I know snappy doesd not function so, but I found a few work around guides but want perhaps more guidance before i just blindly punch in commands
<ijohnson> Chipaca: updated #7411
<Chipaca> ijohnson: ack
<mup> PR #7411: cmd/model: output tweaks, add'l tests <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7411>
<Chipaca> ijohnson: i'll get to a savepoint in #7416 and look at that
<mup> PR #7416: seed/seedwriter: start of Writer and internal policy16/tree16 <Created by pedronis> <https://github.com/snapcore/snapd/pull/7416>
<Chipaca> PRs have savepoints, right?
<ijohnson> sure, no rush
<ijohnson> save early save often
<pedronis> Chipaca: btw did you see my answer here about that flow diagram ?
<Chipaca> pedronis: from before the standup, yes
<Chipaca> pedronis: if after, no
<pedronis> yes, from before
 * Chipaca is a Byzantine General
<cachio> mvo, canonistack server where spread-cron runs has been migrated, I'm migrating this as well to the new one
<cachio> so snapd-vendor-sync won't run until the new instance is ready
<ijohnson> zyga: #7442 approved
<mup> PR #7442: tests: extend mount-ns test to handle mimics <Created by zyga> <https://github.com/snapcore/snapd/pull/7442>
<ijohnson> looks like it's green so you could merge :-)
<Psil0Cybin> if anyone has time later to plz help me get snap.d working on kali i would really appreciate it just becasue of the home folder situation...
<Chipaca> Psil0Cybin: in kali, do you run everything as root, or are you your own user?
<mvo> cachio: nice
<__chip__> Psil0Cybin: in kali, do you run everything as root, or are you your own user?
<__chip__> (silly train network doing silly things)
<Psil0Cybin> __chip__, my own user, created my own user for kali hardening
<Psil0Cybin> but still for some reason my home directory is /newuser
<__chip__> Psil0Cybin: where did you put this user's home?
<Psil0Cybin> instead of /home/newuser.
<Psil0Cybin> sadly in /newuser
<Psil0Cybin> why it was default or i did not notice any other settings :(
<__chip__> Psil0Cybin: sudo mkdir -p /home/newuser; sudo mount --bind /newuser /home/newuser
<__chip__> Psil0Cybin: that should work around the home issue, let you look at the next blocker
<__chip__> kali had no shortage of those
<Psil0Cybin> :O would that work? Can i do this while logged in?
<__chip__> like weird network
<__chip__> and weird X
<__chip__> Psil0Cybin: yes. And yes.
<Psil0Cybin> yea im down to figure out these blockers and even write a guide since i see non online to avoid similar things happening to users.
<__chip__> k
<__chip__> good luck
<Psil0Cybin> perfect first command worked, lets install snapd now :D
<__chip__> Psil0Cybin: we're about to disappear for a week as we meet in person to plan the next chunk of work, so use the forum more? or be extra patient :)
<__chip__> my train's almost there so ttfn
<Psil0Cybin> sounds good incase you go missing! Hats off to you gentle man
<Psil0Cybin> men**
<sergiusens> pedronis: cachio fyi, by switching to the downloaded spread I could get a machine assigned
<cachio> sergiusens, nice
<Chipaca> ijohnson: very quick one: you've double-imported check into asserts_test
<pedronis> Chipaca: thanks for the review
<Chipaca> pedronis: ijohnson: was the consensus that 'snap model --verbose' did not print 'brand' at all?
<Chipaca> just brand-id
<pedronis> Chipaca: yes
<jdstrand_> roadmr: hi! would you mind pulling 20190913-1517UTC? not urgent
<roadmr> jdstrand_: sure thing. Probably won't deploy today (Friday the 13th, before a sprint? not a chance ;) but I'll aim to roll out next week
<jdstrand> roadmr: hehe, sounds perfect
<pedronis> good, OOPS: 55 passed, 1 FAILED
<pedronis> that's image_test.go with seedwriter behind the scenes (plugged a bit hackishly atm but working)
<Chipaca> network hiccup :-|
<Chipaca> pedronis: ijohnson: was the consensus that 'snap model --verbose' did not print 'brand' at all? just brand-id?
<pedronis> Chipaca: yes
<Chipaca> ok
<ijohnson> Chipaca: whoops sorry
<Chipaca> ijohnson: a few more coming up
<ijohnson> ah ok I'll wait for the full review then
<Chipaca> ijohnson: done
<mup> PR snapd#7365 closed: tests: spread test for snap refresh/switch channel and risk switching <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7365>
<Chipaca> ooh, missed one thing
<Chipaca> ijohnson: you've got an if (something) { continue } else { stuff }
<Chipaca> ijohnson: that leaves {stuff} more indented than it needs to be
<Chipaca> ijohnson: silly stylistic, but hey
<ijohnson> that's what you get paid for right?
<roadmr> sillistic?
<Chipaca> ijohnson: no, i get paid for my good looks
<Chipaca> ijohnson: style is just a bonus
<ijohnson> of course how could I forget
<mup> PR snapd#7461 closed: run-checks, tests/main/go: allow gofmt checks to be skipped on 19.10 <Simple ð> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7461>
<ijohnson> Chipaca: where's the if thing you're mentioning?
<Chipaca> ijohnson: cmd_model.go:252
<pstolowski> zyga: merged #7461 and didn't notice your small remark there, sorry
<mup> PR #7461: run-checks, tests/main/go: allow gofmt checks to be skipped on 19.10 <Simple ð> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7461>
<ijohnson> got it thanks
<Chipaca> ijohnson: would be nice to see what the output looks like in this case
<Chipaca> is there a test for it?
<Chipaca> i'll look in a bit
<ijohnson> in which case
<ijohnson> ?
<Chipaca> (coming up to a stop)
<Chipaca> required-snaps
<ijohnson> yes there's a test with required-snaps in the unit tets
<ijohnson> tests
<Chipaca> neat, i'll look
<Chipaca> thank you
<Chipaca> ttfn
<ijohnson> hey jdstrand, pedronis, mvo if I install a snap with system-usernames: snap_daemon in it, then I manually delete the snap_daemon user I can't seem to remove the snap due to seccomp being unable to compile the profile (because we disconnect interfaces first)
<mup> PR snapd#7442 closed: tests: extend mount-ns test to handle mimics <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7442>
<mup> PR snapcraft#2713 closed: tests: completely mock bzr tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2713>
<zyga> re
<zyga> I was asleep, sorry
<mup> PR snapcraft#2714 opened: tests: completely mock mercurial tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2714>
<jdstrand> ijohnson: can you file a bug?
<ijohnson> jdstrand: sure
<roadmr> why is the snapcraft test suite from source trying to run /snap/bin/snapcraft?
<roadmr> cachio: ^^ any idea about this? I mean, I can install the snapcraft snap but the point here is to test the source code I cloned
<cachio> roadmr, I don't know, perhaps sergiusens could help on this
<roadmr> thanks!
<roadmr> oh there's a snapcraft channel :) I'll ask there
<mup> PR snapcraft#2715 opened: Unit 7z <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2715>
<mup> PR snapd#7471 closed: tests: fix newline and wrong test name pointed out in previous PRs <Simple ð> <Created by stolowski> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7471>
<mup> PR snapd#7429 closed: wrappers/services: add ServicesEnableState + unit tests <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7429>
#snappy 2019-09-14
<mup> PR snapcraft#2714 closed: tests: completely mock mercurial tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2714>
<mup> PR snapcraft#2715 closed: Unit 7z <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2715>
<mup> PR snapd#7411 closed: cmd/model: output tweaks, add'l tests <Created by anonymouse64> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7411>
