#snappy 2015-08-24
<ogra_> kyrofa, hmm, did you see the softpedia article about your blog post ?
<ogra_> ..."Now, the good news we want to share with you today is that the guys over at Canonical managed to implement support for the I2C communications protocol and General-purpose input/output (GPIO) on the Raspberry Pi 2 device for Ubuntu Core.
<ogra_> Therefore, the Snappy Scope has now extra functionality, such as support for listing installed and stored snaps (.snap packages), as well as support for installing and uninstalling snaps."...
 * ogra_ wonders why the scope needs GPIO when reading these lines ...  :P
<svij> experts!
<ogra_> http://news.softpedia.com/news/ubuntu-core-receives-support-for-gpio-and-i2c-on-the-raspberry-pi-2-video-489854.shtml for reference btw
<zyga> hey, I was using snapcraft run to test my snap
<zyga> but it failed to install in a way I don't understand:
<zyga> 2015/08/24 09:28:44 Signature check failed, but installing anyway as requested
<zyga> no config found for this snap
<zyga> the "no config found for this snap" is the last thing I get before the install command fails (snappy install on the device)
<zyga> any ideas what that means?
<Chipaca> zyga: strange, can you pastebin the whole thing from the command you use to install on?
<zyga> Chipaca: yep
<zyga> Chipaca: http://pastebin.ubuntu.com/12182344/
<zyga> Chipaca: it's not the full log but it's pretty boring at the top
<zyga> Chipaca: I can give you the snap if you want
<Chipaca> zyga: please
<mvo> zyga: anything special in the snap, i.e. does it actually have a config handler
<mvo> hey Chipaca good morning
<zyga> mvo: not that I can think
<zyga> I'll show you the snapcraft yaml
<Chipaca> zyga: do you have any other *.snap other than the one you were expecting to have?
<zyga> http://paste.ubuntu.com/12182360/
<zyga> ohh
 * Chipaca grumbles about snapcraft doing "scp *.snap"
<zyga> yes
<zyga> yes
<zyga> thanks
<zyga> Chipaca: I fixed a lot of bugs in snapcraft but I realized this is still using *.snap there
<Chipaca> mvo: good morning sah!
<zyga> Chipaca: so is this more like an update issue?
<zyga> or is it related to the new snap
<Chipaca> zyga: I don't know. Can you put the actual generated snap somewhere?
<zyga> Chipaca: yep, copying to chinstrap, to ~zyga
<zyga> Chipaca: it's a private snap so please don't share it
<zyga> Chipaca: ETA ~2m
<Chipaca> zyga: ok, ta
<zyga> Chipaca: done, can you get it from chinstrap?
<Chipaca> a ver...?
<Chipaca> zyga: yep
<Chipaca> done
<Chipaca> aha
<Chipaca> zyga: it works here
<zyga> Chipaca: weird
<Chipaca> zyga: can you check whether it's installing and then trying to run config on it?
<Chipaca> zyga: e.g., install it by hand
<Chipaca> zyga: because what it looks like is that the install is succeeding, and then snapcraft tries to do "snappy config", which fails
<Chipaca> but the command that is in the traceback does not support that
<zyga> Chipaca: please refresh my memory, what is snappy config?
<Chipaca> so a possibility is that there's a broken try/except that's masking the proper command
<Chipaca> zyga: a way for snaps to be configured
<Chipaca> zyga: but it's separate from installation
<Chipaca> zyga: you'd run 'sudo snappy config package < configfile' and the config file would be passed to a config hook in your package
<Chipaca> zyga: (idea is to at some point have a schema so a config interface can be created automagically)
<zyga> Chipaca: I don't have any hooks myself, where are hooks specified? are they per par or on the whole snap?
<Chipaca> zyga: i could answer that question, but i believe you are misunderstanding what i think the problem is
<Chipaca> zyga: your snap has no config
<Chipaca> zyga: no config hook
<Chipaca> zyga: so running "snappy config" will fail, with exactly the error you print
<Chipaca> zyga: "snappy install" does not run "snappy config"
<Chipaca> zyga: so it's possible snapcraft is running config after install itself
<zyga> hmm, odd, is it?
<Chipaca> zyga: you could confirm this if you did "snappy install" yourself, manually instead of through snapcraft
<zyga> Chipaca: I read the code just now, it's not doing snappy config
<zyga> Chipaca: it's only doing sudo snappy install *.snap
<Chipaca> oooooooooohhhhhh
<Chipaca> it's the *.snap thing!
<Chipaca>   snappy [OPTIONS] install [install-OPTIONS] [package name] [config file]
<zyga> Chipaca: I have a patch for that section but I did not change the meaning really
<zyga> ah
<zyga> heheheh
<zyga> nice!
<zyga> Chipaca: I'll fix that localyl
<zyga> Chipaca: and send you MRs
<Chipaca> zyga: i hope that was a plural you :) 'cause i'm not on snapcraft right now
<zyga> ah
<zyga> I didn't know that
<zyga> I'll just send it to lp:snapcraft, I'm sure someone can be poked into reviewing and landing them
<Chipaca> zyga: thanks :)
<mvo> ogra_: how is the uboot.env stuff is looking? any issues so far? or did we finally kill the corruption issues?
 * mvo is catching up on the last weeks
<ogra_> mvo, all fine and stable
<mvo> yay!
<mvo> \o/
<ogra_> no issues so far
<ogra_> (at least i havent heard anything in that direction)
<ogra_> documentation updates are missing ... for the porting doc
<mvo> ogra_: thanks, that sounds like (hopefully) something straightforward
<ogra_> kind of, yeah :)
 * Chipaca ~> the search of the lost lunch
 * ogra_ hands Chipaca a faded map with a dotted line and cross on it 
<davmor2> Chipaca: the map is a lie, it's to pirate treasure, you'll starve before you get there and ogra_ will eat your food cause he's like that ;)
<ogra_> omnomnomnom
<mvo> Chipaca: could you please set the prereq branch to schmideload in the service-endisable branch? so that the diff is easier to read :)
<ogra_> mvo, wrt bug 1479711 ... do you think we should backport it to 15.04 ?
<ubottu> bug 1479711 in initramfs-tools-ubuntu-core (Ubuntu) "snappy should not mount with "discard" option" [Undecided,New] https://launchpad.net/bugs/1479711
 * ogra_ just uploaded the change to wily
<mvo> ogra_: probably yes
<ogra_> ok, i'll shelve it until i hear back from ricmm_ about the resize tests on 15.04
<ogra_> (dont want to taint the testing right now)
<ogra_> hmm, we have 132 open bugs ... and only 33 of them are triaged at all, the rest is in undecided state
<ogra_> pitti, do you happen to have any hint for bug 1485683 ? smells like an ordering prob of the units or some such
<ubottu> bug 1485683 in Snappy "/etc/sysctl.d is not applied on boot" [Undecided,New] https://launchpad.net/bugs/1485683
<kyrofa> ogra_, eh? No!
<ogra_> heh
<pitti> ogra_: replied
<kyrofa> ogra_, haha, read the article. Thanks for the reference! Indeed, not sure how informed the author was, but it's good press anyway :)
<kyrofa> ogra_, and they were obviously thrilled with your work!
<ogra_> pitti, ah, cool ... though i wonder if we should perhaps move the sysctl stuff out of systemd in this case ... we might want values to be set before mounting for example
<ogra_> i guess there is a reason why it usually runs early
<ogra_> yeah, but it make one wonder why the snap scope needs I2C to work :)
<ogra_> *makes
<ogra_> heh
<kyrofa> ogra_, yeah, my fault for writing about both in the same article :P
<ogra_> yeah, two topics in the same article is to much for some :)
<kyrofa> ogra_, haha, I'll keep that in mind
<ogra_> wow, searching for snapcraft gets me a ton of minecraft posts on google
<ogra_> the actual howto is the pre-last hit
<ogra_> GRRR
 * ogra_ curses finger memory
<ogra_> ogra@anubis:~$ sudo snappy install snapcraft
<ogra_> Installing snapcraft
<ogra_> snapcraft failed to install: snappy package not found
<ogra_> :P
<longsleep> Chipaca: do you have an opinion on bug #1484641 - does one need to implement restart logic in the snap or should that be done automatically? I am also wondering on when/if the config hook is run on installation.
<nothal> Bug #1484641: snappy config command does not restart service after setting the configuration <Snappy:New> <http://launchpad.net/bugs/1484641>
<ubottu> bug 1484641 in Snappy "snappy config command does not restart service after setting the configuration" [Undecided,New] https://launchpad.net/bugs/1484641
<Chipaca> longsleep: the config hook is run on install if you give it a config argument
<ogra_> bah
<ogra_> snapcraft downloading is unbelivable noisy
<longsleep> Chipaca: config argument like snappy install mysnap --config ?
<Chipaca> longsleep: i don't have an opinion as to whether a service should be restarted on config; wouldn't the config hook know whether it needs to do this or not?
<longsleep> Chipaca: yes it would, though the docs say that the systemd service is restarted
<longsleep> Chipaca: and that is the usual thing to do, and i think that cannot be done from the config hook can it?
<Chipaca> longsleep:
<Chipaca>   snappy [OPTIONS] install [install-OPTIONS] [package name] [config file]
<Chipaca> longsleep: (from snappy install --help)
<Chipaca> interestingly, that does not appear in the manpage that's generated from the same information
<Chipaca> silly go-flags
<longsleep> Chipaca: ok thats one way to do it, what about the configuration specified in the oem snap, do you know then this is applied. I mean if my oem snap provides config for a snap, does this get applied when the snap is installed later?
<Chipaca> longsleep: i don't remember offhand, but i can look
<Chipaca> give me a sec
<longsleep> cool thanks
<Chipaca> longsleep: it looks like it's applied on first boot
<longsleep> Chipaca: ok, well i think that is good enough for my purpose then. Where i pre populate various snap configs.
<rickspencer3> o/
<rickspencer3> can anyone tell me what I am doing wrong here?
<rickspencer3> (BeagleBoneBlack)ubuntu@localhost:~$ sudo snappy update
<rickspencer3> another snappy is running, try again later
<ogra_> wow
 * rickspencer3 braces
<rickspencer3> ogra_, I assume I did something very silly?
<ogra_> no idea, i have never seen that :)
<mvo> rickspencer3: nothing wrong, there is probably (90% confidence) just snappy autopilot running in the background and updating you
<rickspencer3> oh
<mvo> rickspencer3: its doing that automatically every couple of hours
<rickspencer3> mvo, so, I just plugged it in for the first time in weeks, I guess it triggered then?
<mvo> yeah
<rickspencer3> so, I just wait?
<mvo> I guess we need to improve the error message or (even nicer) "attach" to the running snappy so that you can see what its doing
<rickspencer3> I guess I will get kicked out of my ssh session when it is done and reboots?
<mvo> rickspencer3: yeah, just wait and/or check /var/log/syslog, iirc it prints some progress there
<longsleep> try something like `ps ax|grep snappy`
<rickspencer3> mvo, would you like me to log a bug?
<mvo> rickspencer3: it will inform you about the reboot and give you a chance to cancel it
<mvo> rickspencer3: yeah, please do
<ogra_> mvo, we should make the message more clear
<mvo> yep
<longsleep> whoohoo mvo is processing all my bugs /cheer !!
<rickspencer3> mvo, enjoy bug #1488114
<nothal> Bug #1488114: Confusing message while manually updating during an automatic update <Snappy:New> <http://launchpad.net/bugs/1488114>
 * rickspencer3 is going to try to make an led light up with snappy :)
<ogra_> rickspencer3, whee, like edison !!!
<rickspencer3> mvo, oh nice, I see it gives me 10 minutes before the automatic reboot
<mvo> rickspencer3: yeah and it should also tell you how to cancel it
<rickspencer3> yeah, it's all very clear and nice
<mvo> great
<rickspencer3> ogra_, does this diagram mean that P8_8 is a digital write pin? https://www.safaribooksonline.com/library/view/programming-the-beaglebone/9780071832120/images/figc-1.jpg
<rickspencer3> i.e. if I want to send 5v to a breadboard, I use a jumper from one of those pins?
<ogra_> uh, no idea, sorry ... and that diagram doesnt really say anything
<ogra_> (apart from telling you where P8_8 sits)
<rickspencer3> oh weird, it made the led glow slightly!
<rickspencer3> ogra_, maybe this one is better?
<rickspencer3> http://www.element14.com/community/servlet/JiveServlet/showImage/38-17874-209857/bbb-pinout.jpg
<rickspencer3> looks like it is GPIO_67 ?
<ogra_> rickspencer3, yeah, looks like you should be able to switch it by using GPIO_67
<beuno> rickspencer3, http://beagleboard.org/static/images/cape-headers-digital.png
<beuno> I use that
 * rickspencer3 looks
<ogra_> well, pretty much the same
<beuno> I guess it's the same, but has the nice colors to distinguish
<beuno> yeah
<beuno> but you get red for electrical stuff!
<rickspencer3> so, weird that it completed the circuit before I wrote any code!
<rickspencer3> I guess when the GPIO pin is unitialized, it sends it electricity ;)
<rickspencer3> now it's time to get control ;)
<imuguruza> anyone using Snappy in OdroidC1??
<ogra_> imuguruza, longsleep does
<imuguruza> great, I just realized I have downloaded his img
<imuguruza> longsleep: any chance of using I2C?
<imuguruza> I have installed i2c-tools but can't open it
<longsleep> imuguruza: you might have to load some modules
<longsleep> imuguruza: i am using SPI with no problems, did not try I2C for a while
<imuguruza> ok
<imuguruza> I'm interested on SPI also
<longsleep> well for spi you just load spicc and spidev module
<longsleep> modprobe spicc
<longsleep> modprobe spidev
<longsleep> then you have /dev/spi.. and can use the examples from the linux kernel
<longsleep> imuguruza: also the snappy image kernel has the same gear as the hardkernel kernel, so anything you try on normal Ubuntu should work on Snappy as well.
<longsleep> ah yes
<longsleep> modprobe aml_i2c
<longsleep> should give you the i2c bus
<imuguruza> longsleep: yes!
<imuguruza> great, thanks!
<longsleep> imuguruza: you are welcome
<elopio> ogra_: when you sy boottest, do you mean something like this? http://bazaar.launchpad.net/~canonical-ci-engineering/ubuntu-touch-boottest/trunk/view/head:/tests/boottest/debian/tests/boottest
<ogra_> elopio, well, boot a VM with a new initrd and see if it comes up at all would be my first test
<ogra_> then as a next step go through the initrd code and look what it does ... wherever applicable add a test to check that it did what it was supposed to do for each individual bit
<elopio> ogra_: we already kind of have that. If the vm doesn't get an ip, the integration tests would fail.
<ogra_> well, in the specific case of the resize script you would check if after first boot there is more then 10% unpatitioned spasce on the disk your writable partition lives on
<ogra_> that would indicate that it failed to run
<elopio> that we can easily add, sure. Let me start there.
<ogra_> where we can test such stuff from the normal initrd bits we should do that as well
<ogra_> many bits are hidden sadly ... like mounting ... since usually the last step is to move-mount the bits and pieces
<ogra_> so the running system wouldnt see the initial mount or if there were failures ...
<ogra_> such bits we cant really test
<elopio> ogra_: there must be a way, but probably we will have to build it. Something that listens to the events that happen during that script, and record them.
<ogra_> well, that would mean you test a hacked version of the initrd
<elopio> if it's too hard, it might not be worth it to automate and we can just crowd test it.
<ogra_> not sure how reliable we consider that
<ogra_> we could add more logging all over the place though ... and you could at least parse that log from /dev/initramfs/
<elopio> ogra_: as with everything we test, the idea is to catch some of the possible bugs, not all of them. Ideally the most important ones. And if we consider the impact of those bugs to be more expensive than to write the tests, then we automate the tests even if parts are faked.
<elopio> ogra_: I think you could add at least one log message so we can easily check that the script ran.
<elopio> if you add many more messages, that would affect the boot time, right?
<ogra_> nah
<ogra_> it would just be some echos and redirects
<ogra_> shouldnt impact the boot time much
<ogra_> if something seriously went wrong with the default script you most likely wont finish booting anyway
<ogra_> the log would just be a finer grained view of what the general boot process did
<elopio> ogra_: ok. So for testing, we need only one log message per branch. If you don't have any ifs, it's the same to have one log at the end or many logs.
<elopio> but for debugging, more logs will help.
<ogra_> indeed
<rsalveti> elopio: ogra_: we might also be able to mock some of the core pieces of the initrd code, and test that when building the package
<rsalveti> besides checking for logs after the system booted
<rsalveti> but yeah, as elopio said, need to check for the complexity
<elopio> and I insist that running the script standalone in an already booted system gives some value.
<ogra_> yep
<elopio> not a lot, but it will discover some obvious problems.
<rsalveti> righy
<rsalveti> *right
<elopio> so during the boot, we can ignore those obvious problems and test for other things.
<mcphail> Are there any resources/guides detailing best practice, caveats and gotchas for snappificating an existing package? I was wondering whether it would be helpful to have a cohort of "case studies" of existing packages to highlight these. Perhaps it would be useful for both package builders and snappy devs?
<longsleep> mcphail: Take a look at https://developer.ubuntu.com/en/snappy/snapcraft/
<mcphail> longsleep: that's not quite what I meant. I'm thinking more of focusing on the thing snappy doesn't handle well/easily such as man pages, bash completion etc
#snappy 2015-08-25
<elopio> pitti: ping. I think I have a test that is taking long to reboot. But there's no way to increase the reboot timeout in adt-run, right?
<pitti> elopio: no, not right now; mind filing a bug for this?
<elopio> pitti: sure.
<elopio> pitti: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1488358
<ubottu> Launchpad bug 1488358 in autopkgtest (Ubuntu) "Can't increase the reboot timeout" [Undecided,New]
<elopio> mvo: could you look into https://bugs.launchpad.net/snappy/+bug/1488186 ?
<ubottu> Launchpad bug 1488186 in Snappy "Failed to update: gnutls_handshake() failed" [Undecided,New]
<elopio> it's causing like 50% of the failures in jenkins.
 * elopio goes to bed. See you tomorrow.
<mvo> hey elopio, sure, I have a look
<mvo> elopio: sleep well
<mvo> ppisati: hey, for later (no rush) I would love to hear your opinion on https://bugs.launchpad.net/snappy/+bug/1480248 and if it needs to be re-assigned to the kernel or something else
<ubottu> Launchpad bug 1480248 in Snappy "automatic reboot fails with zero size initrd in bbb" [Critical,Triaged]
<ppisati> mvo: so the actual bug is that it hangs there instead of panicing
<ppisati> mvo: weird, let me see
<pitti> elopio: asked some questions in the bug
<ppisati> mvo: why the watchdog doesn't kick in and reboot the board?
<mvo> ppisati: AFAIK we don't use the watchdog, how can we enable it, that would be a nice fix indeed
<ppisati> mvo: that should be enabled in uboot
<mvo> ppisati: I have the board in this state sitting on my desk if you want me to test anything
<ppisati> mvo: so if we don't reach the userspace in 60secs, it reboots the board
<ppisati> mvo: so, i did a couple of tests
<mvo> ppisati: nice, is that a uboot config option or code?
<ppisati> mvo: yep
<ppisati> mvo: let me do a couple more checks and i'll comment in the lp bug
<mvo> great, thanks
 * ppisati needs more coffee first
<mvo> elopio: I debug the issue a bit but so far nothing conclusive, maybe worth trying to run a curl test on the jenkins server (see bugreport)
<beowulf> mvo: I commented on #1480404, i think both front and backend need work
<mvo> ta
<ogra_> ppisati, hmm, why in u-boot ? i thought thats a kernel feature
<Chipaca> ogra_: i guess it needs enabling from kernel commandline to be useful?
 * Chipaca guesses
<ogra_> well, we have panic=-1 by default there
<ogra_> panic=		[KNL] Kernel behaviour on panic: delay <timeout>
<ogra_> ...
<ogra_> timeout < 0: reboot immediately
<ogra_> ... is what the kernel docs say
<ppisati> ogra_: i didn't look at the option for the watchdog on the cmdline
<ogra_> well, we dont set nmi_watchdog=1
<ppisati> ogra_: but AFAIK a userspace sw open /dev/watchdog
<ogra_> but we do set panic=-1
<ppisati> ogra_: and have to reopen it before TIMEOUT expires
<ogra_> which shoud make the kernel reboot i think
<ppisati> etc
<ppisati> ogra_: moreover, what happens if thekernel hangs before the wdt is enabled?
<ppisati> the correct init should be:
<ppisati> uboot sets the wdt to X and start booting the board
<ogra_> i thought the nmi_watchdog is kernel only
<ppisati> kernel takes over and, either reach usrspace (and wdt is reset)
<ppisati> or uboot settings reset the board
<ogra_> BOOTPARAM_SOFTLOCKUP_PANIC and BOOTPARAM_HARDLOCKUP_PANIC shoudl provide that if i can belive the docs
<ppisati> anyhow, i spent the morning looking at uboot
<ppisati> and it seems the wdt is not supported there
<ogra_> ppisati, but why does the normal panic option not kick in here ?
<ppisati> ogra_: nmi_watchdog?
<ogra_> no, we dont have that on currently
<ogra_> just the normal panic= stuff
<ppisati> and it's x86 only
<ppisati> nmi_watchdog=   [KNL,BUGS=X86]
<ppisati> he sayd he doesn't get any panic
<ogra_> oh, right
<ogra_> damn
<ppisati> just hangs there
<ogra_> oh, i see why :P
<ogra_>  Waiting for root device /dev/disk/by-label/system-b...
<ogra_> no udev ... no /dev/disk/by-label/system-b ...
<ogra_> the kernel itself doesnt set these links
<mvo> yeah, thats the symptom, but why does it not complain if initrd.img is invalid?
<ppisati> do we pass rootwait?
<ogra_> depends on the board
<ppisati> mvo: it doesn't get the initrd at all
<ogra_> if it is in the default env we dont wipe it
<ogra_> we dont add it explicitly iirc
<ppisati> mvo: if you pass a malformed initrd, like 1 byte, it says "bad format" or something
<ppisati> mvo: but it doesn't panic there either
<ogra_> i guess we could add a check to uboot (and switch system_ab based on it)
<ppisati> what really bugs me is that uboot says "watchdog enabled" but i can't fucking get that thing to work
<ppisati> and IMO it doesn't
<ogra_> i.e. look up the size and make sure it isnt zero after loading the initrd
<ogra_> but technically having the kernel fall over would be cleaner
<ogra_> is there any kernel option for "dont boot without initrd" ?
<ppisati> not that i am aware
<ppisati> mvo: do you have the rootwait option?
<ppisati> mvo: on the cmdline i mean
<mvo> ppisati: yes, "Kernel command line: console=ttyO0,115200n8 root=/dev/disk/by-label/system-b init=/lib/systemd/systemd ro panic=-1 fixrtc rootfstype=ext4 rootwait"
<ppisati> ok
<ppisati> quick test
<ogra_> bah, why do we set rootfstype
<ppisati>    /* wait for any asynchronous scanning to complete */
<ppisati>     if ((ROOT_DEV == 0) && root_wait) {
<ppisati>         printk(KERN_INFO "Waiting for root device %s...\n",
<ppisati>             saved_root_name);
<ppisati> ...
<ppisati> if loops there waiting for tghe rootdevice if root_wait = true
<ogra_> yeah
<ppisati> can you try to take that option out?
<ogra_> neither rootfstype nor rootwait should be set
<ogra_> thats comeing from the default env for the BBB
<ogra_> mvo, hmm, can it be that our bbb changes never actually landed in snappy-hub/snappy-systems ?
<mvo> ogra_: I certainly send a MP
<mvo> ogra_: but I haven't tracked (due to sprints/confs) if it actually landed :/
<ogra_> https://code.launchpad.net/~mvo/snappy-hub/bbb-env/+merge/264975
 * ogra_ approves
<ogra_> (hopin thats the actual code we used for the last image :P )
<ogra_> line 90 is the issue for the bog above
<ogra_> *bug
<Chipaca> elopio: question: is there a reason _integration-tests/bin/ and _integration-tests/data/output aren't in bzrignore?
<mvo> ogra_: thanks, branch updated
<mvo> ogra_: cool, so if I remove the rootwait it will work?
<mvo> ogra_: as a quick test?
<ogra_> mvo, you should test it, but it is very likely, yes
<mvo> ogra_: does that also fixes the "1" byte file initrd.img ? or is that a separate bug ?
 * mvo tests once that bbb finishes booting
<ogra_> just intercept the boot in uboot and set mmcrootfstype to nothing or just to ext4 or so
<ogra_> the 1byte initrd will also try to fall back to mount root= directly ... (and fail) the outcome should be the same
<mvo> ogra_: cool, I set this now via fw_setenv and see what happens
<ogra_> +1
<mvo> nice panic
<ogra_> and reboot too ?
<mvo> yes
<ogra_> yay !
<ogra_> awesome
<mvo> I try the one byte file now just for good measure
<ogra_> yeah
<mvo> ogra_: I assume you are on the updated snappy-systems branch?
<ogra_> i would be surpised if it wouldnt do the same
<ogra_> i dont have my BBB powered/wired up atm ...
<ogra_> the Rpi is (on a local copy, since we dont have the Pi upstream)
<mvo> ogra_: ok, I can work on the branch if you want, just don't want to dupliicate work :)
<ogra_> ah, k
<mvo> same for 1 byte
<ogra_> yay
<ogra_> ppisati, ^^^ all fine then
<ppisati> ogra_: cool, but i still want to understand why the f*ck watchdog didn't reboot from uboot
<Chipaca> 15.04 is go 1.3, right?
<mvo> yes
<mvo> ogra_: https://code.launchpad.net/~mvo/snappy-hub/lp1480248-norootwait/+merge/269032
<ogra_> mvo, approved
<mvo> ogra_: I'm doing a final test with a good initrd.img (takes forever because of the sync mount option)
<mvo> ogra_: thanks
<ogra_> the sync mount option ?
<mvo> ogra_: I copied the good initrd back and that cp takes a long time
<mvo> ogra_: because we mount /boot sync
<ogra_> ah, right
<mvo> ogra_: but all good, booted fine from b
<ogra_> i thought the boot takes forever :)
<Chipaca> rsalveti: you around?
 * ogra_ is afk for a bit (need to get a new laptop for susie ... her lenovo blew up the DC board last night ... out of the blue ... a month after the warranty is gone ... crap HW...)
 * mvo tests bbb update snap
<mvo> someone will need to approve my updated bbb snap
 * mvo gets lunch first
<rickspencer3> hi all, snappy-remote keeps timing out on me
<rickspencer3> any ideas? I can easily ssh right into the BBB
<Mikaela> I am unfamiliar with snappy-remote but if it has something to do with GitHub they are mitigating DDoS attack and restoring service which causes git pulls etc. to fail for me unrelated to snappy.
<rickspencer3> Mikaela, thanks for your answer, that is interesting
<rickspencer3> but, snappy-remote is just a wrapper around ssh, I think, to push and install your snap package
<rickspencer3> it looks like it is trying to do some kind of key exchange that is failing
<ogra_> rickspencer3, using an IP or webdm.local ?
<rickspencer3> ogra_,  webdm.local
<ogra_> and ssh to webdm.local works from the same machine ?
 * rickspencer3 tries with straight ip
<rickspencer3> ogra_, ssh works fine, yeah (using webdm.local)
<rickspencer3> and using the ip address with snappy remote worked fined as well
<ogra_> aha
<rickspencer3> I assume that I need to grant permissions for the snap to use the gpio pins?
<ogra_> you most likely need to grant access to teh respectiver /dev node with hw-assign
<rickspencer3> ogra_, is there a place where I can look up how to do that?
<ogra_> the webcam tutorial ...
<ogra_> https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
<ogra_> you should actually see complaints in syslog about device access
<rickspencer3> ogra_, does this tell me how to use hw-assign?
<rickspencer3> nm, I figured it out
<ogra_> :)
<mvo> ogra_: is lp #1429749 sill a issue? i.e. that the rpi2 is not updating ? aiui this was only a problem with early rpi2 images, right?
<ubottu> Launchpad bug 1429749 in Snappy trunk "Ubuntu Core updated but not switch to new version after reboot on Raspberry Pi 2" [Undecided,New] https://launchpad.net/bugs/1429749
<rickspencer3> is there a Go library for gpio that is known to work with BBB and snappy?
<sergiusens> hello hello
 * sergiusens is in back to normal mode
<mvo> hey sergiusens, good monring!
<mvo> sergiusens: do you happen to know if we have a branch for snappy remote 0.4 somewhere?
<mvo> sergiusens: I was looking into a issue that rickspencer3 reported earlier about slow webdm.local resolving
<sergiusens> mvo: how is it related to snappy remote?
<sergiusens> mvo: snappy-remote just uses avahi indirectly when using ssh
<sergiusens> mvo: you probably want to up the broadcast of IPs in webdm itself, I think
<mvo> sergiusens:  I wanted to check what snappy-remote is doing and if we could cache the ip there for example
<sergiusens> mvo: oh, it's just using 'ssh'
<mvo> sergiusens: aha, that sounds like a better suggestions, thanks
<mvo> sergiusens: yeah, I found the source for 0.3 but was wondering if 0.4 has changed anything, looks like bzr might need a bzr push with the latest changes :)
<mvo> (or I looked at the wrong branch :/)
<sergiusens> mvo: yeah, I might have forgotten to push and I'll need to power up my older laptop to get it :-/
<sergiusens> will do in a bit; the 0.4 thing only does some key magic
<mvo> no worries, I can manually import from the deb if its trouble to find the old laptop
<mvo> ogra_, ppisati: bug #1458866 is another one of the failover robustness that would be nice to get input on. this time its about a correpted dtb. could we do something smart if snappy_mode is try and it fails to read the dtb?
<nothal> Bug #1458866: hangs in uboot boot prompt if dtbs dir is missing <Snappy:New> <http://launchpad.net/bugs/1458866>
<ubottu> bug 1458866 in Snappy "hangs in uboot boot prompt if dtbs dir is missing" [Undecided,New] https://launchpad.net/bugs/1458866
<mvo> lool: re bug #1459755 - could we simply unconditionally enable serail grub in our generic-amd64 snap? or is there a downside to this?
<nothal> Bug #1459755: Need a way to drive GRUB over serial port <Snappy:New> <http://launchpad.net/bugs/1459755>
<ubottu> bug 1459755 in Snappy "Need a way to drive GRUB over serial port" [Undecided,New] https://launchpad.net/bugs/1459755
<mvo> elopio: hi, can we get click-reviewers-tools in the testbed? this triggered a issue in the intergration tests that caused the test failure for the snappy-review-tools-reneable branch
<mvo> ppisati, ogra_: I subscribed you to some more of the failover bugs, would be nice to get your input (not urgent though)
<ogra_> sergiusens, any idea why azure needs rootwait ? that shouldnt be necessary (and is usually unused, since the initrd handled waiting itself)
<ogra_> *handles
<ogra_> do the azure images have a special initrd or some such ?
<sergiusens> ogra_: iirc, rsalveti added it
<ogra_> right, but why ?
<ogra_> rootwait is only helpful when booting without initrd ... and in our case it is actually harmful :)
<rsalveti> ogra_: azure needs it
<rsalveti> because of azure :-)
<rsalveti> or better, because of reasons
<sergiusens> ogra_: ah, it's in there docs
<ogra_> lol
<sergiusens> as a requirement
<ogra_> i dont get that
<ogra_> it should be a total no-op if you use an initrd
<ogra_> (apart from breaking our auto-panic )
<ogra_> do we have any azure devs we could ask ?
<ogra_> for $reasons
<rsalveti> ogra_: check our priv channel
<ogra_> ah, i need to re-loacate
 * ogra_ goes to the office
<elopio> mvo: we could, but it's always hard to install things in snappy. We could copy the python script, or we could make a snap. But did you see my comment here?
<elopio> https://code.launchpad.net/~mvo/snappy/snappy-review-tools-reenable/+merge/264301/comments/676317
<mvo> elopio: aha, ok, sorry, I didn't - brain was in quick triage mode apparently :/
<elopio> mvo: wow, you triaged the world. Thanks!
<davmor2> elopio: don't make it sound like such a chore,  it's easy, "The World" is broken, global warming, war, deforestation, over heating, yellowstone get more active, the list goes on ;)
<elopio> davmor2: snappying the world it's such a chore.
<elopio> barry: we started getting this error: https://bugs.launchpad.net/snappy/+bug/1488186
<ubottu> Launchpad bug 1488186 in Snappy "Failed to update: gnutls_handshake() failed" [High,Triaged]
<elopio> barry: any idea what could cause it?
<barry> elopio: i don't.  i'll subscribe to the bug, but it seems like it's a lower level tls problem.  is the server perhaps load balanced and maybe there's a problem there?
<elopio> barry: who manages the server? I'm not sure whom to ask about that.
<barry> elopio: probably is, but slangasek has access
<slangasek> elopio, barry: I don't have any access to the web frontends; that's IS-managed
<mvo> elopio: I guess a rt ticket is the best way forward at this point
<elopio> mvo: ok, on it.
<elopio> Chipaca: we wanted to move _integration-tests/bin/ and _integration-tests/data/output out of the tree, but didn't get to it yet.
<elopio> a .bzrignore in the mean time seems appropriate.
<ogra_> ricmm_, how do you resize the partition on the kvm image ... seems gparted doesnt like it
<ricmm_> ogra_: gparted offers to fix the partition table header for you
<ricmm_> then it shows fine as unallocated space
<ogra_> hmm, doesnt here
<ricmm_> then sfdisk actually does the job correctly when doing 2.26
<ricmm_> didnt offer you to fix?
<ricmm_> I appended zeros to the image file first
<ogra_> ah, i was trying to shrink writable
<ricmm_> so I'm trying right now with flashing the image as-is (4G) onto flash and see if that works
<ricmm_> or if theres the same error as on kvm
<ogra_> i'd expect the same error with the old sfdisk
<ogra_> ricmm_, hmm, no errors on rolling ... but no resize either
<ogra_> http://paste.ubuntu.com/12193628/
 * ogra_ appends moar zeros
<ogra_> hmm, it sees that the disk grew bigger
<ricmm_> ogra_: it gret 1.3 MB for you
<ricmm_> yet you had added 500M of zeros
<ricmm_> mmm
<ogra_> i added another GB
<ogra_> and it properly sees the device is 5GB now
<ogra_> but it doesnt resize
<ogra_> (doesnt error either)
<elopio> Chipaca: https://code.launchpad.net/~elopio/snappy/bzr_ignore_integration_output/+merge/269095
<ricmm_> ogra_: hmmm it worked for me
<ricmm_> did you open it with gparted at some point?
<ogra_> no
<ricmm_> open it with gparted, lets try to understand what kind of fix that is doing
<ogra_> i added 1.5G
<ricmm_> it will offer to "fix" the partitioning
<ricmm_> yea but added it how
<ricmm_> just appending zeros?
<ogra_> dd
<ogra_> yeah
<ogra_> dd oflag=append conv=notrunc if=/dev/zero of=kvm-rolling.img bs=1MB count=1000
<ogra_> and before the same with 500
<ogra_> now i'm in an initrd shell ...
<ricmm_> lol
<ogra_> trying sfdisk there manually say the GPT is damaged and will be fixed on next write ...
<ricmm_> yea wily didnt boot for me on real hw
<ricmm_> right, thats the error that gparted fixes
<ogra_> (on purpose, i added break=premount to the cmdlijne)
<ogra_> well, but sfdisk tells me it will fix it on next write ... i tried to write it but that didnt help it seems
<ogra_> hmm
<ogra_> perhaps i need a reboot or re-read the partition table at the kernel level
<ogra_> hmm, nope
<ogra_> blockdev --rereadpt doesnt change a thing
<ogra_> sigh
<ogra_> i dont think there is a way around using parted
<ogra_> slangasek, do you happen to have any idea about teaching sfdisk about GPT ? (it works fine for all MBR based images just not for the amd64 one now)
<ogra_> well, not teaching it about it but making it repair the GPT to make it possible to resize the writable partition
<ricmm_> ogra_: sfdisk knows GPT
<ricmm_> thats not the problem
<ogra_> yes
<ogra_> thats why i wrote the second line :)
<ricmm_> the problem is that when cloning disk images like this the secondary GPT header (footer) is misaligned
<ricmm_> its not at the physical end of disk
<elopio> kyrofa: nice video. Did you publish the source for your snap somewhere?
<ogra_> right
<ricmm_> ogra_: parted can fix this I think but there should be an easier way to do so for GPT
<ricmm_> maybe we can teach sfdisk to do so
<ricmm_> :)
<kyrofa> elopio, thanks! Yeah, it's here: https://github.com/kyrofa/piglowtop
<kyrofa> elopio, for snappy-specific stuff, see the snappy readme (meta/readme)
<ogra_> well, sfdisk even *tells* me it will fix it "on next w(rite)"
<ogra_> but it seemingly doesnt
<elopio> kyrofa: thanks!
<ricmm_> ogra_: but did it do an actual write? how about read the partition as-is then write it again
<ricmm_> it might realign it to end of disk
<ogra_> oh damn !
<ogra_> i'm blind
<ogra_> so after printing a lot of info when i do the write ... it then says "use gparted to correct the GPT errors"
<ogra_> i missed that :P
<ogra_> sigh
<ogra_> so that silly GPT stuff will make me re-write the whole thing then :((( to use parted and bloat the initrd
<ricmm_> well not necesarily
<ricmm_> we can try to understand what gparted is doing to fix the stuff
<ricmm_> and just teach sfdisk about it
<ricmm_> if we want to avoid the bloat...
<ricmm_> how big is this bloat anyways? why does it concern you so much
<ogra_> i guess thats a lot more effort
<ogra_> dunno, likely a few MB
<ogra_> it pulls in all of ncurses at least ... probably even more stuff (i never checked, ncurses was already enough to make me run away)
<ogra_> the code change alone is probably small
<sergiusens> ogra_: ricmm_ parted should be compilable without curses
<ogra_> sergiusens, it is linked against it
<sergiusens> ogra_: you need to do multibuild in the deb package
<ogra_> so copy_exec from initramfs-tools pulls in the libs
<ogra_> (copy_exec reversely runs ldd against all binaries and copies all deps in)
<ogra_> and i surely dont want to re-package parted :)
<ricmm_> ogra_:      if (q == PED_EXCEPTION_FIX)
<ricmm_>         {
<ricmm_>           last_usable = last_usable_if_grown;
<ricmm_>           /* clear the old backup gpt header */
<ricmm_>           ptt_clear_sectors (disk->dev,
<ricmm_>                              gpt_disk_data->AlternateLBA, 1);
<ricmm_>           gpt_disk_data->AlternateLBA = disk->dev->length - 1;
<ricmm_>           *update_needed = 1;
<ricmm_>         }
<ricmm_> doesnt look that bad to teach sfdisk about it perhaps ;D
<ogra_> hmm
<ogra_> i think upstream sfdisk is even at 2.28 ... perhaps someone cared already :)
<ricmm_> perhaps
<ogra_> ah, no, 2.27 ...
<ogra_> 2.28 is in development
<ricmm_> yea 227
<ogra_> hah ... they added json dumps :P
<ricmm_> of course they did
<ricmm_> going to rest my disk now
<ricmm_> ogra_: https://github.com/karelzak/util-linux/commit/9d9a1b876094fe38c5539f19a57323437b8b8a0d
<ricmm_> looks relevant
<ogra_> well, thats only checks
<ogra_> i was hoping for relocation code :)
<ogra_> so seemingly we could use gdisk ... but that has a similar dependency chain as parted
<sergiusens> ricmm ogra_: then maybe the idea of using cloud-init is back up for discussion?
<ogra_> sergiusens, cloud-init ????
<ogra_> you want to pull cloud-init into the initrd ?
 * ogra_ wants cloud-init gone completely, its a PITA 
<ogra_> and i surely dont want a python interpreter in the initrd :)
<sergiusens> ogra_: cloud-init does growfs outside of init
<sergiusens> initrd that is
<ogra_> sergiusens, with the whole bind mount farm active on top of the writable part ??
<ogra_> thats like gambling :)
<ogra_> the only sane way to resize is from the initrd before we have the bind mounts active
<ogra_> (even before anything gets mounted at all for extra safety)
<ogra_> sergiusens, i'll pull parted in before this discussion even comes to speed
<ricmm_> I'd like not have a bunch of python scripts meant for dispoable cloud instances running on unreachable hardware that is meant to stand the test of time (10 yrs)
<ricmm_> doing partitioning that is
<ricmm_> :)
<ogra_> :)
<sergiusens> Chipaca or mvo and elopio I am ready for slaughter https://code.launchpad.net/~sergiusens/snapcraft/meta-all-yaml/+merge/269100 :-)
<elopio> sergiusens: I'll start looking at it after lunch.
<elopio> sergiusens: could you look at https://code.launchpad.net/~elopio/snappy/remove_ssh_copy/+merge/268947 ?
<sergiusens> elopio: sure
 * mvo also needs review for some branches
<ogra_> ricmm, sfdisk -d /dev/sda|sfdisk /dev/sda  ... that makes the error go away but doesnt allow me to resize anymore ... http://paste.ubuntu.com/12194329/
<ricmm> ogra_: sfdisk: libfdisk/src/table.c:420: new_freespace: Assertion `end > start' failed.
<ricmm> looks like an error to me !
<ogra_> well, it doesnt complain about the GPT anymore
<ricmm> right but it fails at "creating" the freespace definition
<ricmm> in other words I'll bet the GPT footer is still wrongly positioned
<ricmm> because it didnt get the padding from the unallocated space
<lool> mvo: bug #1459755: perhaps we can do this for now, but it's not a long-term solution as the serial port might be used for e.g. an UPS or whatever
<nothal> Bug #1459755: Need a way to drive GRUB over serial port <Snappy:Triaged> <http://launchpad.net/bugs/1459755>
<ubottu> bug 1459755 in Snappy "Need a way to drive GRUB over serial port" [Medium,Triaged] https://launchpad.net/bugs/1459755
<lool> mvo: I guess in theory it ties into our hardware assignment story
<lool> but this is probably too remote for now
<sergiusens> mvo: seems like we are in bargaining mode :-P
<lool> mvo: in any case, we need to set the right linux console
<lool> mvo: a config flag would be fine though; something like /writable/etc/grub.d/zzzSetserial.conf could be generated perhaps
<ogra_> ricmm, yeah, i'll switch to parted ... that just means a lot more math i was hoping to avoid
<sergiusens> lool: we don't parse and generate grub.cfg anymore ;-) It goes straight into the snap
<sergiusens> so it can be whatever you want
<lool> sergiusens: right; it doesn't really relate to what we used to do, but just to a config-time place to set bootloader options
<lool> that's why I thought of the single-instance writable partition which has some etc stuff rather than dealing with system-a/system-b stuff
<sergiusens> lool: if it is a fixed function device problem it can certainly have its own gadget/oem snap defining the console
<lool> sergiusens: yes, that's exactly what I have in mind
<sergiusens> if not, I prefer a snappy config for ubuntu-core (or the gadget)
<sergiusens> although the gadget snap is not configured, it handles passing down config :-)
<sergiusens> lool: great
<lool> sergiusens: I mean, we need to provide the config hooks to turn on serial console in a couple of places, and they need to set it
<lool> sergiusens: so typically one would set the config from gadget snap, and it would set config options provided by the kernel snap I guess
<lool> of course, there's a risk that walking down the path of adding config options makes us reinvent every single of GRUB's options
<lool> and here we can already see the difference between the GRUB notion of a serial console and the linux one
<lool> are we going to abstract it away for folks to consume
<lool> e.g. ubuntu-core/serial-console=ttyS0 and then map that to the right GRUB and Linux serial devices
<lool> or will we provide kernel/console=(or extra-cmdline=)/dev/ttyS0 and bootloader/serial-console=ttyS0
<lool> etc.
<ricmm> ogra_:
<ricmm>     /* check that the backup header is properly placed */
<ricmm>     if (le64_to_cpu(gpt->pheader->alternative_lba) < cxt->total_sectors - 1)
<ricmm>         /* TODO: correct this (with user authorization) and write */
<ricmm>         goto err0;
<ricmm> lazy people ;)
<ogra_> ricmm, hmm, so i just tried the goarted repair ... and while the resize log says the partition is 2.5G now, df and the rest of the world disagree
<ogra_> (i,e, /proc/partitions)
<ricmm> well you'd still need to resize2fs right ?
<ricmm> not sure if your script is doing that
<ogra_> indeed it does
<ogra_> http://paste.ubuntu.com/12194394/
<sergiusens> lool: I don't plan to look at that today
<ricmm> hmm it looked fine for me after gparted sorted the error
<ogra_> df tells me 1.6G
<ogra_> for the /oem mount
<ogra_> (which is the writable partition)
<ogra_> and /proc/partitions agrees ...
<ogra_> the resize log says it resized though
<ogra_> and sfdisk run on the running system with --force says 1.6G too
<ogra_> it didnt actually resize
<ricmm> ah you are right
<ricmm> GPT PMBR size mismatch (11713186 != 11713187) will be corrected by w(rite).
<ricmm> im getting this now
<ogra_> yeah, thats what i got all the time
<ogra_> lets give up on sfdisk ...
<ricmm> geez
<ricmm> heh
<ogra_> unless we want to drop GPT ...
<ricmm> try the parted approach
<ricmm> lets see how larger it is
<ogra_> yeah, but thats a bit more than just adding parted and removing sfdisk
<ogra_> parted expects exact values for everything ... that will require a lot more scripting
<ogra_> not a 5 min job
<ricmm> if only we had a shell expert
<ogra_> :P
<ricmm> ogra_: dont need it today, tomorrow 7am is fine
<ricmm> ;D
<ricmm> j/k, we can continue tomorrow
<ogra_> if only we had someone who could still focus :P
<ricmm> its late anyways
<ogra_> yeah
<sergiusens> ricmm: it's barely snack time for you!
<ricmm> true
 * lool returns to leave
<ricmm> ogra_: I think im going to try to do the sfdisk patch
<ogra_> ricmm, hah, brave
<ogra_> after seeing it tell me lies about the resizing i dont feel like i can trust it wrt GPT
<ricmm> well the error happened because of the line I showed you
<ricmm> it exits quietly before writing back to disk
<ricmm> thats where there should be a yes/no option to "fix" and a headless force I guess
<ricmm> will look into it later tonight if I got energy
<ricmm> after all, I'm still in PST
<ogra_> heh
<ogra_> brainf*cked ...
<sergiusens> elopio: Chipaca another one https://code.launchpad.net/~sergiusens/snapcraft/validation/+merge/269120
<sergiusens> elopio: did you find a way to not see those 'Leftover .*' messages from plainbox?
#snappy 2015-08-26
<elopio> sergiusens: I didn't look for a way to remove the leftover messages. I just filed a bug for zyga: https://bugs.launchpad.net/plainbox/+bug/1484596
<ubottu> Launchpad bug 1484596 in PlainBox (Toolkit) "tests print a lot of warnings when they leave files on the working directory" [Undecided,Triaged]
<sergiusens> elopio: bummer, it is so annoying :)
<sergiusens> elopio: here's another one https://code.launchpad.net/~sergiusens/snapcraft/testing-fixes/+merge/269146
<sergiusens> 3rd and last
 * sergiusens goes for some zzzzz
<zyga> mvo: hey
<zyga> mvo: around?
<mvo> hey zyga, good morning
<zyga> mvo: hey, I'm trying to understand how a part of snapcraft you wrote works
<zyga> mvo: I'm thinking of the python3-project plugin
<zyga> mvo: specifically it seems to be a bit broken IMHO, but perhaps I'm missing something
<mvo> zyga: ok, what part is unclear? or everything :) ?
<zyga> mvo: could you please show me how to use two python3-project parts where A depends on B?
<zyga> mvo: how it's supposed to work, I already read the code and patched a few things
<zyga> mvo: but before I patch more, I want to see if I'm doing something sane
<zyga> mvo: I was trying to structure the plugin after virtualenv, so that each subseqeuent part, after it's staged, can be imported by the rest of the snapcraft assembly process
<zyga> mvo: (I wasn't thinking of using virtualenv, just to follow the same principle)
<zyga> mvo: also, from what I see, setuptools depenencies are not followed at all, so the developer has to put everything together manually, right?
<mvo> zyga: yeah, so dependencies are not resolved (yet) thats something that must be done manually right now
<zyga> right, thanks for confirming that
<mvo> zyga: we haven't used it in the scenario you describe, it may well be broken for that, how do you patches look right now? and in what way does it break exactly? code crashes or files not copied ?
<zyga> mvo: ok, thanks, so currently it just crashes trying to run the setup of the 2nd part as it cannot import the 1st part
<zyga> mvo: what I'm doing now, is to change how setup is invoked
<zyga> mvo: I'm using --root relative to installdir and a fixed prefix
<zyga> mvo: and I'll be probably using a different layout, but I need to see how to control the environment first
<zyga> mvo: I found plugin.env() but it's not being called, I saw it's something related to handler.code but I've yet to connect the dots
<zyga> mvo: I want to write an env function there that uses PYTHON* viariables to set everything up
<mvo> zyga: aha, I see. there is a env() method that is available to add e.g. PYTHONPATH, there is also the after= directive to ensure on part is build before another
<zyga> mvo: it also may be a factor that I'm working from a virtualenv in the first place (snapcraft itself is in a virtualenv)
<zyga> mvo: and I want to make sure it's working regardless of that fact
<zyga> mvo: I added env() but it's not getting called yet
<zyga> as in ...
<mvo> zyga: right
<zyga> ttp://paste.ubuntu.com/12197674/
<zyga> mvo: I'll dig through this and improve it anyway I can
<zyga> mvo: I need the plugin to work with roughly anything I can throw at it for an active project we're doing in cert so I'll probably ask you for a few reviews as I go
<mvo> zyga: sure, thanks. sergio will also be around later to help with that, once I finish my current snappy branch I can take a deeper look to see why env() is not doing what you expect
<zyga> mvo: thanks
<zyga> ah
<zyga> small fix is to use /usr/bin/python3 instead of python3
<zyga> that addresses the virtualenv factor
<zyga> mvo: are you using virtualenv for development?
<mvo> zyga:  I don't use virtualenv
<zyga> mvo: how do you develop snapcraft then?
<mvo> zyga: in my normal wily env
<zyga> mvo: just running it straight from the tree?
<zyga> mvo: ok, thanks for the tip
<zyga> mvo: is python 3.5 default there?
<zyga> mvo: I'm on vivid
<mvo> zyga: its available but not default (yet)
<mvo> zyga: not sure what the plans of the distro team are, I assume they want to make it default but its a rc at this point aiui
<ogra_> mvo, i see you closed bug 1479711 ... do we consider bugs "fix released" if the fix is only in wily ?
<ubottu> bug 1479711 in initramfs-tools-ubuntu-core (Ubuntu) "snappy should not mount with "discard" option" [Undecided,Fix released] https://launchpad.net/bugs/1479711
<ogra_> (just a general question)
<zyga> ogra_: o/
<ogra_> hey zyga
<mvo> ogra_: I would say yes unless there is a 15.04 task, feel free to add one though
<ogra_> k, thanks
<mvo> ogra_: I wonder if we should maybe do a 15.10 "release" and move current trunk to 15.04, nothing radical in there AFAICS and mostly useful and stable for 15.04 people. but this of course needs wider discussion
<ogra_> well, would that work ? given the potential differences in both releases (newer go version, gcc5 etc)
<ogra_> if that doesnt get in our way, yeah sure
<mvo> ogra_: that we need to explore, but it might be good enough to just build trunk on 15.04 and some specific packages (like the initramfs improvements)
<zyga> ha
<zyga> small bug in logging in snapcraft :)
<ogra_> yeah, it definitely makes sense for stabilizing the stable image
<ogra_> to keep the focus there ...
<ogra_> (and it will make everyone more cautious sbout landing his changes as a nice sideefect :) )
<zyga> and perhaps some more in various places, logging is broken wrt all arguments
<mvo> yeah, thats my goal, optimize our time and spend less time porting, either via developing for 15.04 and merging from that into trunk or by moving trunk closer to 15.04
 * zyga starts proposing fixes
<zyga> https://code.launchpad.net/~zyga/snapcraft/fix-logging-setup/+merge/269163
<zyga> mvo: who's the lead reviewer for snapcraft?
<mvo> zyga: sergio right now, but let me have a look, I can cover TZ wise
<zyga> mvo: cool, you can expect a lot of patches from me soon :)
<mvo> zyga: cool :)
<zyga> mvo: btw, do you want to use git with snapcraft (I am)
<zyga> mvo: it's pretty cool :)
<zyga> helps sorting through patches a lot
<mvo> is the tarmac problem solved? that was the only thing holding us back
<zyga> mvo: bzr on the server
<zyga> mvo: git locally
<zyga> mvo: I'm using git-lp that I wrote (and I'm using all the time for the past three years)
<mvo> zyga: nice, where can I find it?
<zyga> mvo: https://github.com/zyga/git-lp
<zyga> https://github.com/zyga/git-lp/wiki
<zyga> mvo: if you have any issues just ping me
 * mvo looks
<zyga> mvo: it's just a single file, drop it in $PATH somewhere
<zyga> mvo: apply the damn patch to bzr and you're all set
<zyga> (instructions on the wiki might be a bit stale, I wrote them at around 12.04 time frame)
<mvo> uh, I vaguely remember the patch
<zyga> :D
<zyga> mvo: how often does snapcraft merge processor (tarmac?) runs?
<mvo> zyga: should be every 10min, but I think there was a commit message missing, I set one now
<zyga> mvo: ah, sorry, I'm used to autogenerated commit messages
<zyga> thanks
<mvo> no worries
<mvo> and yes, that is (much) nicer
<zyga> ok, the other half of the change is now pushed
<zyga> mvo: https://code.launchpad.net/~zyga/snapcraft/fix-logging-calls/+merge/269167
<mvo> meh, its still updating the diff
 * mvo waits (im)patiently
<zyga> mvo: yeah, is is oddly slow
<zyga> mvo: I have another branch to sweeten the wait
 * zyga cannot wait till he gets to the part of improving plainbox-based tests
<zyga> mvo: https://code.launchpad.net/~zyga/snapcraft/fix-process-leak/+merge/269172
<zyga> it's pretty odd because all the delta shows up fine http://bazaar.launchpad.net/~zyga/snapcraft/fix-logging-calls/revision/136
<zyga> and the one on the 2nd branch is already generated
<zyga> mvo: both branches are reviewable now
<mvo> zyga: and are reviewed :P
<zyga> oh, sorry :)
<mvo> thanks again zyga, much appreciated!
<zyga> thank you :)
<zyga> mvo: I have plenty more :-)
<mvo> thats good
<mvo> keep them coming and we will name the next release after you :)
<zyga> hahaha :-0
<zyga> :-)
<zyga> when I'll run out of ideas I'll start fixing pep-8 issues and adding docstrings everywhere
<mvo> lol
<ogra_> ricmm, any luck with the sfdisk hacking ?
<ogra_> mvo, so i guess we can create a raspberry subtree on snappy-hub to push the RPi setup to  ?
<mvo> ogra_: its seems to be, yes
<mvo> ogra_: thats what I heard yesterday :)
<imuguruza> longsleep: just one rapid question: device tree needs to recompile for exposin /dev/spidev0.0 right??
<imuguruza> Thanks in advance!
<imuguruza> (Talking about your OdroidC1 Snappy image)
<imuguruza> I meant /dev/spidev0.1
<zyga> mvo: I have a bigger one now
<mvo> zyga: nice
<zyga> mvo: https://code.launchpad.net/~zyga/snapcraft/fix-1486659/+merge/269190
<zyga> mvo: have look, I tested it obviously but there are no tests for that yet
<zyga> mvo: I'll get to add tests but I'm not familiar with how to do it yet and I still think it's important to merge fixes for real issues, even if they are not tested automatically
<zyga> mvo: there's one more issue that i didn't know how to fix, if the selected key is encrypted and there's no agent around, it will propmt the user, I wanted to prevent that somehow but I'm not sure how yet
<zyga> mvo: also, if you want me to split this branch into separate branches & file bugs for various sub-issues, I can do that easily
<mvo> zyga: thanks, I think its fine and I agree with the reasoning , I have a look now (or maybe after lunch if I don't finish in time :)
<zyga> mvo: thanks
<zyga> sergiusens: ping
<zyga> sergiusens: around? :-)
<sergiusens> zyga: yeah, but need to get some coffee, so start typing and I'll get back to you ;-)
<zyga> sergiusens: thanks, I have a few ideas I want to discuss with you
<plars> zyga: hey
<zyga> plars: hey
<ricmm> ogra_: nothing yet ;) working on that this afternoon
<zyga> plars: in a meeting
<zyga> plars: I got your message
<plars> zyga: I'm still not having much luck getting chainloading to work with inception in kvm, and still issues with mountpoints
<plars> zyga: sure, np... just sometime today, maybe we can walk through it
<zyga> plars: I will fix that today
<ogra_> ricmm, so should we start in parallel on two approaches (me going the parted route) ? just to be safe ?
<zyga> plars: I'm working on some improvements though they also intersect with other parts of the stack
<zyga> plars: I'll tell you more later today
<plars> zyga: I also have some other stuff I was changing in my local branch, but wasn't sure where to push it to. There's no project that I could find
<zyga> plars: I'll make one shortly
<zyga> plars: right now you can just push it to any git repo
<zyga> plars: I can work with that
<ricmm> ogra_: yea take a look at doing it with parted
<ogra_> great ...
<ricmm> if I get something for this we can change to it due to size improvements I guess
<ricmm> but you already know how to do it with parted, so best to move forward
<ogra_> it also seems like you cant really resize GPT partitions at all ...
<ogra_> all docs i can find delete the old one and create a new one with all tools
<ogra_> i have to test what resize in parted actually does ... if we need to delete and re-add that means even more math and scripting :/
<ogra_> silly GPT !
<ogra_> ppisati, btw, i dont think a watchdog will help with the 0byte kernel and dtb files ... we should have checks in the bootloaders and do the auto-fallback there
<ogra_> (not sure how hard that is to do in grub ... in uboot it is surely possible to check the size and file existence)
<emilebosch> hi guys, can someone tell me a little bit how to create a snappy package with postgreql and rails in it., are there any examples online somewhere?
<zyga> sergiusens, mvo: I would appreciate feedback on this mr, I have more things in the pipe and I (_crazy_ schedule) need to know I can land things effectively https://code.launchpad.net/~zyga/snapcraft/fix-1486659/+merge/269190
<zyga> if you are blocked/cannot review things/disagree with the changes, i'd like this feeback sooner rather than later
<ogra_> emilebosch, take a look at snapcraft https://developer.ubuntu.com/en/snappy/snapcraft/your-first-snap/
<ogra_> (it is still very young and rough on the edges, please file bugs if you find issues)
<emilebosch> ogra_: thanks, i just want to know a bit on the internals in order to understand how the services work. are they converted to systemd targets?
<ogra_> if you define a service in the package.yaml a systemd unit is created for it, yes
<emilebosch> ogra, ok so are snaps than basically lxd containers?
<emilebosch> with a systemd as init?
<ogra_> no, there are no containers ...
<ogra_> a snap runs natively on your system but wrapped by a launcher and confined by apparmor
<emilebosch> huh.  now i am confused. ok i need to read about the internals instead of annoying you guys, where can i find it
<emilebosch> aaah
<emilebosch> feels a bit weird now since ubuntu is moving to lxd/lxd
<ogra_> there is an lxc/lxd framework in the works and there is also a docker framework in the snap store ... but you would have to explicitly depend on them and have them installed for contsainer use
<ogra_> but by default snaps are just jailed on the system without containers around them
<emilebosch> ogra what would be the upgrade scenarioâs for snaps? in the sense lets say i have an app that runs a database then in release a new version how would it be upgraded?
<ogra_> your snap has a data dir where it stores such stuff ... that data dir is migrated (copied for now) durinng upgrades
<emilebosch> thanks
<ogra_> it is reflected in the $SNAP_APP_DATA_DIR env var that is exported to your snaps environment when things start
<emilebosch> ok awesome. is ther emore in-depth documentation avialable?
<ogra_> https://developer.ubuntu.com/en/snappy/guides/security-policy/
<ogra_> that should list all the vars ...
<ogra_> and indeed there are https://developer.ubuntu.com/en/snappy/guides/package-metadata/ and https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/
<ogra_> and a very basic tutorial at https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
<emilebosch> awesome thanks ogra_
<ogra_> mvo, looking at http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1196 ... doesnt the build also create an initrd.img that should be deleted ?
<mvo> ogra_: that is moved earlier unless I miss something
<ogra_> ok
<ogra_> i did only see the patch ... slightly out of context indeed
<mvo> zyga: sorry for the delay, all approved now
<zyga> mvo: thanks a lot, no need to worry :-)
<zyga> mvo: a related question, where should *.snap files go?
<zyga> are they expected to build to current working directory?
<mvo> zyga: I think that was the plan, mterry was working on this part, I need to check the source/spec to be certain
<zyga> mvo: if you have a link handy I'd like to see as well
<zyga> joc_: https://code.launchpad.net/~zyga/snapcraft/extra-run-features have a look at this please
<zyga> joc_: get this branch somwehere on the side and tell me if that lets you run snapcraft run to play with real wifi
<zyga> the corresponding MR is https://code.launchpad.net/~zyga/snapcraft/extra-run-features/+merge/269202
<mvo> zyga: I look at this now
<zyga> mvo: thanks
<zyga> mvo: the use case is this
<zyga> mvo: well, it's all explained there :)
<zyga> mvo: but it makes development faster as you can just assemble/run
<zyga> mvo: and often you don't need to involve real hardware
<zyga> my usb wifi dongle stopped working
<zyga> or maybe not?
 * zyga tries
<cwayne> i havent been able to get mine working on rpi2 with the newer image
<cwayne> zyga: ^ not sure if thats related at all, but fyi  :)
<ogra_> cwayne, oh, ?
<zyga> cwayne: I don't have a rpi2
<cwayne> ogra_: yeah, it keeps saying that it failed to associate with the driver and there's auth failures, even though i've looked over the psk 10,000 times and its correct
<ogra_> cwayne, if the driver is in the kernel/modules it should just work by adding the necessary data to /etc/network/interfaces
<zyga> sigh
<zyga> yes it's dead
<cwayne> ogra_: i've even copied the /etc/network/interfaces from my rpi1 with raspbian with the same dongle and it works there
 * zyga needs to buy another wifi eh
<ogra_> smells like a driver issue then ... i know others use wlan dongles just fine ... do you know what driver it usually uuses ?
<cwayne> i'd had it working on an older image, but i've also physcially moved it, maybe its not getting a strong enough signal..
<zyga> ogra_: which dongle are you using?
<zyga> ogra_: amazon links appreciated
<ogra_> zyga, i dont :P
 * ogra_ has wires 
<zyga> why do we always have to be on the front lines ;-)
<ogra_> zyga, iirc rickspencer3 uses one on his BBB
<rickspencer3> hi ogra_
<ogra_> hey rickspencer3
 * rickspencer3 looks for context
<ogra_> rickspencer3, you use a wlan dongle on your BBB, dont you ?
<rickspencer3> ogra_, no, I could not get either of mine to work
<ogra_> zyga, looks for recommendations for buying one that works
<ogra_> oh
<zyga> ogra_: see
<rickspencer3> zyga, if you get one that definitively works, can you let me know?
<ogra_> yeah :(
<rickspencer3> :)
<zyga> ogra_: I'll buy you one
<zyga> rickspencer3: absolutely rick
<cwayne> i got this one: http://www.amazon.com/gp/product/B00FWMEFES?psc=1&redirect=true&ref_=oh_aui_detailpage_o03_s00
<zyga> rickspencer3: I'll get a few and try what works
<cwayne> and it did work before
<cwayne> maybe i just need to move it or something.. who knows
<zyga> cwayne: looks like http://www.amazon.es/TP-LINK-TL-WN725N--Nano-Adaptador-garant%C3%ADa/dp/B008IFXQFU/ref=sr_1_1?ie=UTF8&qid=1440593083&sr=8-1&keywords=wifi+usb
<zyga> cwayne: I wonder what's the chipset inside
<zyga> anyway, cha-ching, let's get an see
<ogra_> zyga, hmm, i havent seen one of these NANO adapters tht had a linux supported chipset (though that was like 1.5y ago when i looked at them last)
<zyga> ogra_: there's just one rpi2 now, right?
<zyga> anyone that I get is good
<zyga> joc_: any luck?
<zyga> joc_: does it work for you
<ppisati> ogra_: yeah
<ppisati> ogra_: my point there was that
<ppisati> ogra_: the hack that i implemented in uboot
<ppisati> ogra_: is that, either you boot the kernel
<ppisati> ogra_: or it forcefully reboots the board
<ppisati> ogra_: so the a/b logic has another chance to run or whatever we put there
<ppisati> ogra_: and once the kernel takes over
<ppisati> ogra_: uboot can't do anything
 * zyga looks for a master bug to get python3-project projects to see each other 
<mvo> ppisati: hi, I hope I don't get on your nerves yet but did you had a chance to check https://bugs.launchpad.net/snappy/+bug/1471868 - its a bit confusing, looks like the kernel is doing funny stuff if init is broken (and it seems to be different depending on architecture)
<ubottu> Launchpad bug 1471868 in Snappy "automatic reboot fails with non executable empty systemd" [Critical,Triaged]
<ppisati> well, the kernel can't do anything
<ogra_> ppisati, well, just blindly resetting wont make the ab switch ... you need to actively set snappy_ab to the opposite value too ... else you just create a loop
<ppisati> if there's no init
<ppisati> it doesn't know what to do
<ppisati> iirc it even looks in a couple of places
<ppisati> for alternate inits
<ogra_> yeah
<ppisati> but if the fs is corrupted
<ogra_> 4 or 5 even
<ppisati> and it cannot exec any of time
<ppisati> you are screwed
<ppisati> it can probably panics and reboot
<ppisati> but i've to check
<mvo> ppisati: so this is a test when its broken and I think its doing the right thing on arm (panics) but not on amd64
<ogra_> it should panic
<mvo> ppisati: we broke init deliberately for the test of course
<mvo> ppisati: feel free to downgrade/comment if there is nothng that the kernel can do of course, its all part of the robustness dance :)
<ppisati> ogra_: well, the watchdog sets a timer in hw
<ppisati> ogra_: and if it expires, it restes the board
<ppisati> ogra_: i mean, i cant change a var in the exec
<ppisati> ogra_: because the reset is done in hw, i can't run a trigger for example
<ppisati> mvo: that's weird, i've to test it
<mvo> ppisati: thanks! no real rush, I'm mostly curious about it
<mvo> (well, we should fix it eventually but its not omg-now priority or anything)
<ppisati> mvo: can you make a list of all these 'robustness thing' bugs?
<mvo> ppisati: sure, I think I subscribed you to all of them, but I'm happy to add a tag, is "failover-robustness" good?
<mvo> (as tagname?)
<ppisati> mvo: snappy robustness or something like that?
<mvo> ppisati: works for me, so snappy-robustness as tag in LP and I send you the url that shows all such bugs?
<ppisati> mvo: that would be perfect
<ogra_> ppisati, right, thats why i mean a watchdog is the wrong approach, since we need to switch over from a to b (or the opposite)
<ppisati> ogra_: once mvo is done collecting all the robustenss bugs, we can discuss about it
<ogra_> yeah
<rickspencer3> arg, I can't remember how to hw-assing to the gpio pins
<rickspencer3> (BeagleBoneBlack)ubuntu@localhost:~$ sudo snappy hw-assign bike-and-bus-sensor.sideload '/sys/class/gpio/'
<rickspencer3> invalid hardware device
<rickspencer3> ?
<ogra_> didnt you open a bug about it yesterday ?
<zyga> joc_: ha, the option is already very seful
<zyga> useful
<rickspencer3> ogra_, differnet bug
<zyga> joc_: SNAPCRAFT_RUN_QEMU_ARGS="-smp 2" snapcraft run
<zyga> joc_: and you can write a simple "amd I SMP" test case
<zyga> joc_: go for it!
<rickspencer3> ogra_, yesterday I figured out how to do hw-assign for the pins, but now I forget :/
<joc_> zyga: just trying the wifi thing - bit of pain cos think need root to access the wifi dev
<zyga> joc_: oh
<zyga> joc_: hmm
<zyga> joc_: patch snapcraft to use sudo there
<zyga> joc_: or
<zyga> joc_: add yourself to the appropriate group
<zyga> joc_: (2nd thing should be better but requires you to login again)
<ogra_> rickspencer3, https://bugs.launchpad.net/bugs/1488618
<ubottu> Launchpad bug 1488618 in Snappy trunk "cannot specify /sys/class/gpio/export with hw-assign" [Critical,In progress]
<ogra_> (there is a workaround)
<rickspencer3> ogra_, yeah, that's a different bug, actually
<joc_> zyga: the device is root:root
<zyga> joc_: ah, I see
<zyga> joc_: that's crap
<rickspencer3> and I've applied the work around :)
<zyga> joc_: you an try an udev rule to change permissions
<zyga> joc_: but I think running it via rut is easier
<zyga> joc_: just patch cmd.py to have sudo there
<joc_> k
<ogra_> rickspencer3, hmm, looks to me like the worakaround should give you full access
<zyga> joc_: I'll add an option to make that a possible choice on command line
<ogra_> without even needing to call hw-assin again
<rickspencer3> ogra_, the work around gives me access only to export
<rickspencer3> so it provides access to the program that creates gpio files
<rickspencer3> but hten I need access to those files once created
<rickspencer3> which, I think, worked yesterday
<rickspencer3> but today I can't figure out that I did
<ogra_> rickspencer3, well, just add more lines for the other nodes in there
<ogra_> whatever you need
<rickspencer3> yeah, I can hack around it, but I swear I could just use hw-assign yesterday, so I think I am doing something silly
<ogra_> well, the bug says /sys/class is generally denied ... so i would be surpised if you got it working yesterday without hacksd
<ogra_> *hacks
<ogra_> probably jdstrand can clearify
<rickspencer3> well, all I can say is, I had it working with a different snap yesterday
<joc_> zyga: seemed to work ok with a sudo added to the kvm call
<rickspencer3> it could have been a fluke, i.e. something else I didn't do wrong yesterday that I did wrong today :)
<ogra_> func validDevice(device string) bool {
<ogra_>  return strings.HasPrefix(device, "/dev") || strings.HasPrefix(device, "/sys/devices")
<ogra_> }
<ogra_> these are the only two allowed paths when using hw-assign
<zyga> joc_: cool, thanks for confirming this
<cwayne> ogra_: so i moved my rpi2 physically closer to the AP and now it connects, so there's that :)
<ogra_> cwayne, yay
<cwayne> zyga: ^
<zyga> cwayne: coool
<jdstrand> rickspencer3, ogra_: currently we should allow access to the devices that are exported. the problem was that we blocked export/unexport
<rickspencer3> jdstrand, well, today I am getting blocked on the exported device :(
<jdstrand> rickspencer3: so once you exported, hw-assign should work as expected (hw-assign foo /sys/devices/...)
<jdstrand> rickspencer3: what is the denial?
<ogra_> jdstrand, /sys/class ...
<ogra_> not /sys/devices :)
<rickspencer3> jdstrand, I have 2
<rickspencer3>  audit: type=1400 audit(1440595711.301:11): apparmor="DENIED" operation="open" profile="bus-and-bike-sensor.sideload_bus-and-bike-sensor_0.1" name="/sys/devices/platform/ocp/481ac000.gpio/gpio/gpio68/direction" pid=726 comm="bus-and-bike-se" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
<jdstrand> ok, that one should work with hw-assign
<rickspencer3> jdstrand, can you give me the command for hw-assign, I couldn't make it work
<jdstrand> sudo hs-assign bus-and-bike-sensor.sideload '/sys/devices/platform/ocp/481ac000.gpio/**'
<jdstrand> err
<rickspencer3> ug
<jdstrand> sudo snappy hw-assign bus-and-bike-sensor.sideload '/sys/devices/platform/ocp/481ac000.gpio/**'
<jdstrand> now, the /sys/devices/... could be just /sys/devices/platform/ocp/481ac000.gpio/gpio/gpio68/direction
<rickspencer3> wow, taking a while :)
<emilebosch> is there anywhere a git repo wiht sample snaps?
<emilebosch> or just some apps snappyfied?
<jdstrand> but with the glob you shouldn't have to do extra stuff
<rickspencer3> let me try rebooting and see what happened
<jdstrand> rickspencer3: don't reboot
<rickspencer3> too late
<rickspencer3> sorry
<jdstrand> did the command complete?
<rickspencer3> jdstrand, yes
<jdstrand> ok that's fine
<rickspencer3> I waited for the command to complete :)
<rickspencer3> for once I was not too impatient
<jdstrand> hehe
<jdstrand> rickspencer3: did it work?
<rickspencer3> so, here I am again
<rickspencer3> : type=1400 audit(1440596552.734:17): apparmor="DENIED" operation="open" profile="bus-and-bike-sensor.sideload_bus-and-bike-sensor_0.1" name="/sys/class/gpio/export" pid=1142 comm="bus-and-bike-se" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
<rickspencer3> I thought I fixed that in the apparmour file
<jdstrand> ok, yes, that is what requires the workaround rule
<jdstrand> oh, I know what happened
<ogra_> emilebosch, bzr branch lp:~snappy-dev/snappy-hub/snappy-examples
<jdstrand> you added the workaround rule to the profile, then used hw-assign which rewrote the profile
<ogra_> (no git ... but bzr :) )
<emilebosch> aarg
<jdstrand> rickspencer3: ^
<emilebosch> ok berw install bzr
<rickspencer3> oh
<rickspencer3> jdstrand, I did, but, looks like the apparmor profile got regenerated
<jdstrand> the good news is, it sounds like mvo was going to hop on this so the workaround rule won't be needed
<jdstrand> rickspencer3: yes. the hw-assign blew it away
 * jdstrand adds comment to the bug
<rickspencer3> ok, I fixed the file and reran the parser
 * rickspencer3 reboots
<rickspencer3> \o/
<rickspencer3> thanks jdstrand that got it working again
<jdstrand> that reboot shouldn't be required if you are restarting the correct service. if you feel compelled to try to chase that down, please file a bug and we can chase it down
<jdstrand> rickspencer3: sure, np. sorry I forget to mention/didn't think about the fact that hw-assign regenerates the profile yesterday
<rickspencer3> meh
<rickspencer3> I would have gotten there since the same app armor denial came back
<rickspencer3> now I have a happily blinking led again :)
<jdstrand> yeah!
 * rickspencer3 moves on to controlling it from a web api :)
<ogra_> rickspencer3, next step, phone webapp ?
<rickspencer3> hehe
<ogra_> (though that might be tricky without avahi )
<rickspencer3> ogra_, I am going to get the next bus prediction from my local transport companies api
<rickspencer3> and first blink a light depending on when the next bus is coming
<rickspencer3> then do something similar for the city bikes near me
<rickspencer3> then I will add some info the lcd screen
<ogra_> ah
<ogra_> so you dont want a webapp but integration with the phone notifications !
<rickspencer3> yeah, phone notifications could be next
<rickspencer3> but, I was just thinking it would be like ambient information
<rickspencer3> "oh, bikes are running low, maybe I should leave now instead"
<rickspencer3> "hmmm looks like we can take our time, it will be a while before the next bus"
<rickspencer3> that kind of thing\
<ogra_> yeah
<rickspencer3> I'm thinking that if I get really tricky, I can make a web config UI, then other people in DC can make their own, just add their stop and bike station ids :)
<mvo> ppisati: https://bugs.launchpad.net/snappy/+bugs?field.tag=snappy-robustness <- the list we talked about earlier
<ppisati> ogra_: ^
<mvo> pitti: silly question, how can I see if m systemd "ubuntu-snappy.boot-ok.service" was executed before or after the "rc.local" script? and if it was run before, is there a way to ensure that ubuntu-snappy.boot-ok.service is run last (ideally very last :) ?
<pitti> hey mvo
<pitti> mvo: there is no "very last" concept in any recent init system, I'm afraid (not even in SysV with insserv)
<mvo> pitti: hm, do you have a idea what might be the closest approximation?
<pitti> mvo: you can check systemctl show -p ExecMainStartTimestampMonotonic ubuntu-snappy.boot-ok.service
<mvo> pitti: after getty is run or something?
<pitti> (that gives you subsecond precision)
<pitti> mvo: and compare that to the time stamp in rc-local.service
<pitti> mvo: or just check the journal which one was starting/started after which
<mvo> pitti: yeah, thats helpful
<pitti> mvo: After=multi-user.target is fairly late
<mvo> pitti: I think thats the culprit, our book-ok script runs before rc.local
<mvo> pitti: cool, let me try this
<pitti> mvo: I've heard of several people wanting their unit to be the "very last", they can't *all* be that :)
<mvo> pitti: ahah, if its late enough thats ok
<pitti> mvo: but most stuff runs < multi-user.target, at that point you can definitively call the boot a "success"
<mvo> pitti: I just want to be sure that it made it to the prompt
<mvo> pitti: thanks (as always!) for you great and prompt help :)
<pitti> mvo: soif that's the intention ("is my boot okay?), then After=multi-user.target sounds about right
<mvo> great
 * mvo will add it
 * pitti hugs mvo
 * mvo hugs pitti
<mvo> and one more bug down
<mvo> .)
<pitti> mvo: FTR, I saw LP #1457491, still in my queue; sorry for the delay
<ubottu> Launchpad bug 1457491 in Snappy "Upgrade from r41 to r55 on BBB failed to boot and also to failover (drops into rescue systemd mode)" [High,Triaged] https://launchpad.net/bugs/1457491
<mvo> pitti: aha, yeah, thats another one where I would prefer if it could go to auto-reboot if a certain kernel cmdline is set
<mvo> pitti: i.e. I guess I just need something like a custom preexec script or something
<pitti> mvo: probably just OnFailure=reboot.target
<pitti> (or something such; I haven't checked the details yet)
<mvo> aha, cool
<mvo> thats pretty amazing if its that simple
<pitti> and I'm not very familiar with the OnFailure= bit yet, need to test this
 * pitti tries hard to catch up with mail/bug/IRC queue
<mvo> pitti: no worries, not urgent really :) I can dig with the new OnFailure info a bit more myself
<ogra_> ppisati, gigantic :P
<elopio> mvo: I don't get why snappy-from-branch is not working for your branch. When I pring $(which snappy) it shows /tmp/adt-run.wnFI56/tree/_integration-tests/bin/snappy
<elopio> ah, sudo which snappy prints /usr/bin/snappy
<mvo> elopio: ohhh, of course, thanks!
<mvo> elopio: I fix tomorrow then, have you commented in the mp already? if not, please do so that I don't forget about it agian :)
<elopio> mvo: I can't preserve the user path. An alias doesn't work, because ExecCommand adds the full path to the binary. And go doesn't seem to like passing PATH=$PATH in the command args.
<sergiusens> elopio: tell sudo not to wipe the env
<elopio> sergiusens: -E doesn't work. -i doesn't work.
<rickspencer3> I seem to recall that there was some kind of cli command that I could issue that would let systemd tell me what messages my app wrote out
<rickspencer3> does anyone remember what I mean?
<elopio> sergiusens: https://code.launchpad.net/~elopio/snappy/sudo_path/+merge/269252
<elopio> that's the only way I could make it work.
<rickspencer3> jdstrand, if I am seeing this:
<rickspencer3> Aug 26 18:26:45 localhost kernel: [   74.556368] audit: type=1400 audit(1440613605.338:11): apparmor="DENIED" operation="capable" profile="bus-and-bike-sensor.sideload_bus-and-bike-sensor_0.1" pid=1561 comm="bus-and-bike-se" capability=12  capname="net_admin"
<rickspencer3> can I just add net_admin to my caps or something?
<jdstrand> this is that bug from before
<rickspencer3> this is being hit when I write Go code that accesses an https resource
 * jdstrand finds it
<jdstrand> https://bugs.launchpad.net/snappy/+bug/1465724
<ubottu> Launchpad bug 1465724 in Snappy "net_admin apparmor denial when using Go" [Undecided,Incomplete]
<rickspencer3> jdstrand, so, this seems like a common thing to do, no?
<rickspencer3> use Go to access an https resource?
 * rickspencer3 thought this was fixed a while ago
<jdstrand> yes, but the denial should be harmless. is it keeping your app from running?
<jdstrand> we reviewed it and it is just an out of order check in the kernel
<jjohansen> jdstrand: no cap net_admin should not be handed out like candy
<rickspencer3> jdstrand, yes, it keeps my app from running
<jjohansen> it allows modifying routing tables, interface config, masquerading
<rickspencer3> so far as I can tell, anyway
<jdstrand> jjohansen: no one is proposing that
<jjohansen> jdstrand: give it out to every go app is handing it out like candy
<jdstrand> jjohansen: no one is proposing doing that :)
<jdstrand> jjohansen: it is a kernel bug
<jdstrand> jjohansen: see https://bugs.launchpad.net/snappy/+bug/1465724/comments/9
<ubottu> Launchpad bug 1465724 in Snappy "net_admin apparmor denial when using Go" [Undecided,Incomplete]
<rickspencer3> jdstrand, maybe it isn't keeping my app from running, hard to say
<jdstrand> rickspencer3: ok, for now you have to modify the profile to add 'capability net_admin,' to unblock you. the bug was deprioritized because we thought it was a harmless denial. we'll up the priority
<elopio> rickspencer3: fwiw, we have this card: https://trello.com/c/V5pmALwm/197-document-the-files-and-logs-that-help-to-diagnose-problems-in-a-snap
<rickspencer3> jdstrand, I just add that to the end of the app armor profile?
<rickspencer3> I can try it, and see if it fixes my app
<jdstrand> rickspencer3: ah, well, if you add that rule and it starts working, then it likely is the cause, but if it still doesn't work, then it probably isn't
<jdstrand> rickspencer3: yes, before the trailing '}', like before
<sergiusens> elopio: here you go: https://code.launchpad.net/~sergiusens/snapcraft/validation/+merge/269120
<sergiusens> elopio: I'll trade ;-)
<rickspencer3> elopio, right, so I am printing debug information from my code, but I forget how to read it
<rickspencer3> I recall there is some trick to telling journalctl how to look at your debug output
<elopio> sergiusens: wait on mine, because it stopped working :/
<elopio> sergiusens: and you probably owe me like 400 lines. This is not fair trade ;)
<jdstrand> sudo journalctl --unit <name of file in /etc/systemd/system>
<rickspencer3> jdstrand, for what it is worth, adding the cap didn't fix my app ;)
<tyhicks> rickspencer3: that's good to know - I was fairly sure that the AppArmor denial wouldn't affect go apps but I wasn't 100% sure
<rickspencer3> right
<jdstrand> rickspencer3: ok, thank you for the feedback
<sergiusens> elopio: it's mostly tests ;-)
<elopio> sergiusens: ready now. I forgot to make it writable.
<jdstrand> tyhicks: we might want to reconsider the current priority of that bug because it is confusing to the developer
<tyhicks> jdstrand: I agree that it is confusing
<elopio> sergiusens: tests are also code!
<elopio> If you prick them, do they not bleed?
<sergiusens> elopio: not in production ;-)
<sergiusens> :-P
<elopio> sergiusens: I don't understand why you have to quote the version.
<sergiusens> elopio: because if not, it is not a string according to the yaml spec
<sergiusens> elopio: and python assigns an int to it for things like '1', '2'
<elopio> sergiusens: but isn't the vendor a string? And it has no quotes.
<sergiusens> elopio: if it can detect it is a string, it will be a string
<sergiusens> elopio: there are no letters in 1
<elopio> I find it confusing. Can't we overwrite the parsing to make the version always a string?
<sergiusens> elopio: notice that if it were 1.1 it would also be an int, but maybe 1.1.1 would be a string
<elopio> yeah, I understand now.
<sergiusens> elopio: maybe, I need to look into the engine a bit more
<elopio> but I wonder if this is a common practice in yamls. Or just something that's forced on us because of python being too smart.
<sergiusens> elopio: well I know how to fix this in go :-)
<sergiusens> elopio: I bet there is a way in python and I have it somewhere to check; in any case, version is deprecated
<elopio> sergiusens: we are not going to have versions?
<elopio> that's enough for my back this morning, I'll have lunch and take a break. bbl.
<sergiusens> elopio: is python 3.4 available for trusty?
<sergiusens> elopio: and yeah, versions are meaningless, at least manual ones; just look at all our packages ;-)
#snappy 2015-08-27
<pitti> mvo: replied to bug 1457491 now, with a solution tested in a wily cloud instance
<ubottu> bug 1457491 in Snappy "Upgrade from r41 to r55 on BBB failed to boot and also to failover (drops into rescue systemd mode)" [High,Triaged] https://launchpad.net/bugs/1457491
<mvo> pitti: \o/
<mvo> pitti: thanks abunch
<zyga> good morning :)
<zyga> mvo: did you have luck with git-lp yesterday?
<zyga> mvo: today will focus entirely on the python3-project plugin, I want to get to a point where separately-installed projects can see each other successfully
<zyga> mvo: I have some code but it's not fully working yet
<clobrano> hi there, I was wondering if ubuntu core has suspend/hibernate functionality and how to test it
<ogra_> clobrano, no, i dont think we have this yet
<ogra_> could you file a whishlist bug ?
<clobrano> ogra_: sure I can. Could you give me a hint about how to do it? :)
<ogra_> there is a link in the channel topic ;)
<clobrano> ogra_: oh, that was easy enough :D
<ogra_> ;)
<ogra_> ppisati, ^^should the kernels theoretically suppport suspend and hibernate ? (i know we dont ship any userspace bits for it currently)
<clobrano> ogra_: actually writing on /sys/power/state works
<ogra_> clobrano, yeah, but you will most likely not be able to wake it up again
<clobrano> ogra_: if you're lucky to have a power button you will :)
<ppisati> clobrano: which kernel?
<ogra_> well, does it work ?
<clobrano> ogra_: yes, it does
<clobrano> ppisati: 3.19.0-23
<ogra_> oh !
<ppisati> ogra_: rpi2 doesn't have any /sys/power/state file, so the answer is no
<ppisati> clobrano: which hw?
 * ogra_ wouldnt have expected it to work at all
<ppisati> ogra_: /me guesses he tested the amd64 img
<clobrano> ppisati: I flashed a pendrive and I'm testing on a notebook
<clobrano> ppisati: yep
<ogra_> ah
<ppisati> right, so
<ogra_> sorry, my brain is so arm centric :)
<clobrano> so no suspend on other systems, right?
<ppisati> ogra_: on BBB no, suspend to disk might work but we need the correct fw and a dedicated partition
<ogra_> yeah
<ppisati> ogra_: on rpi2, at least on this 3.19, there's no power state file, so no again
<ogra_> clobrano, right, thats what i would suspect
<ppisati> for the BBB the only kernel that supports suspend to ram is the TI one
<clobrano> I'll file a whishlist bug then
<ogra_> thanks !
<clobrano> ;)
<ppisati> so either someone try to port all the power management stuff from there, or it will have to use the TI kernel
<ppisati> on rpi2, i don;t know, i might do some more research when i'm done with other stuff
<ppisati> uhm
<ppisati> ubuntu@raspy2:~$ cat /boot/config-3.19.1-12-generic-bcm2709 | grep -i suspend
<ppisati> CONFIG_ARCH_SUSPEND_POSSIBLE=y
<ppisati> # CONFIG_ARM_CPU_SUSPEND is not set
<ppisati> CONFIG_OLD_SIGSUSPEND3=y
<ppisati> # CONFIG_SUSPEND is not set
<clobrano> mmh, I'd like to test it on my rpi2 as soon as I get home :D
<imuguruz_> ogra_: I'm working at Erle Robotics and I'm trying to execute a piece of software we use. The software that is running in Rpi2 or BBB sends data to my laptop through UPD under ethernet. I see that the communication in the RPi2 Snappy is not as reliable as in Snappy BBB. I have executed the same piece of software in Raspbian and works OK. I think something is going on under Snappy in Rpi2
<imuguruz_> Not a Linux expert
<imuguruz_> thanks
<ogra_> imuguruz_, hmm, can you open a bug for it and attach your /var/log/syslog file from the RPi image so we can see if there are any apparmor denials ?
<imuguruz_> sure
<ogra_> (could well be that the app confinement needs some fine tuning here)
<ogra_> a link to the bug page is in the channel topic
<imuguruz_> ok
<ppisati> ogra_: have you ever tried the 'break=$something' on arm kernels?
<ppisati> ogra_: to debug the initramfs i mean
<ogra_> not recently, but it should work
<ppisati> crap
<ppisati> i've a vivid image here
<ppisati> and when i try the premount target
<ppisati> i don't get any shell
<ogra_> the initrd is identical to the amd64 one ... and there i used it this week
<ppisati> albeit busybox is there
<ogra_> hmm
<ogra_> wrong console= args ?
<ppisati> uhm no
<ppisati> the image boot fine
<ogra_> well, what does your cmdline have ? only one console=ttyS0 ?
<ppisati> ogra_: i've a lot of stuff there
<ogra_> if you have something pinting to tty1 or some such your input wouldnt be taken from the serial console
<ppisati> it's the cmd line from the bcm bootloader on the raspi2
<ppisati> right
<ppisati> i need to trim that forest
<ogra_> +1
<imuguruz_> ogra_: done
 * ogra_ sees bug 1489412
<ubottu> bug 1489412 in Snappy "RPi2: connection not realiable" [Undecided,New] https://launchpad.net/bugs/1489412
<ogra_> thanks !
<imuguruz_> you're welcome!
<imuguruz_> happy to contribute
<ogra_> hmm, no specific denials ... that i would assign to your problem
<ogra_> (interestingly a lot others that i wouldnt have expected )
<ogra_> jdstrand, could you take a look at the syslog in the above bug ? there are quite some DENIALS for snaps from the store (unrelated to the bug itself, but i think xkcd-webserver should rather be denial-free :) )
<ogra_> hmm
<ogra_> webdm seems to fail with udp issues too ... i wonder if we have two snaps wrangling over the socket
<ogra_> ooh ... i have an idea what it could be
<ogra_> imuguruz_, you can try to append "smsc95xx.turbo_mode=N" to the default cmdline in /boot/uboot/cmdline.txt and reboot ? the USB NIC on the RPi2 might drop packages when the turbo mode is enabled
 * ogra_ ponders to put that as default into the 15.04.3 image 
<imuguruz_> ogra_: ok, will try right now
<imuguruz_> ogra_: in /system-boot/cmdline.txt?
<ogra_> right
<imuguruz_> ok, done
<ogra_> (sorry, i was assuming you edit on a running system :) )
<imuguruz_> now let's try it
<ogra_> yeah
<imuguruz_> ogra_: works better but not well
<ogra_> hmm
<ogra_> do you have many USB devices attached ?
<imuguruz_> one, keyboard
<imuguruz_> i don't need it, so i'll try again without keyboard and hdmi
<imuguruz_> more fluid, but not at as good as in BBB Snappy or Raspbian
<ogra_> hmm
<ogra_> i dont reallly know what kernel and config raspbian uses ... will have to check that ...
<imuguruz_> v 3.18.11-v7
<ogra_> we are on 3.19 (and about to switch to 4.x) ... and the version sadly doesnt tell what tree they used
<ogra_> but i'll find out
<ogra_> imuguruz_, you could try to also add: dwc_otg.dma_enable=1 dwc_otg.dma_burst_size=256  ... i just read that this should improve things alongside disabling the turbo mode
<ogra_> http://elinux.org/R-Pi_Troubleshooting#Crashes_occur_with_high_network_load btw ...
 * Chipaca wonders why emacs now freezes on startup with "Loading pylint..."
<ogra_> it wants to telll you that you should use vim ?
<imuguruza> ogra_: ok
<sergiusens> Chipaca: I just dropped all those legacy things and moved to notepad.exe under wine
<sergiusens> :-P
<Chipaca> ogra_: i truly believe that vim and emacs are completely equivalent, and the fact that i use one instead of the other is due to random chance, but switching from one to the other is extremely expensive
<sergiusens> Chipaca: it is expensive, I switched to atom one day after getting fed up with vim and it's plugin system; I thought I'd move back but I'm still using atom in vim mode ;-)
<Chipaca> it's a bit like why we use D-glucose instead of L-glucose
<jdstrand> ogra_: the net-admin is almost certainly bug #1465724 which tyhicks and I discussed here yesterday (kernel bug, harmless). the xkcd one is also harmless. I guess I could put an explicit deny rule in there
<nothal> Bug #1465724: net_admin apparmor denial when using Go <Snappy:Confirmed> <http://launchpad.net/bugs/1465724>
<ubottu> bug 1465724 in Snappy "net_admin apparmor denial when using Go" [High,Confirmed] https://launchpad.net/bugs/1465724
<bzoltan_> ogra_:  is there a raspberry pi A/B+ image somewhere?
<ogra_> bzoltan_, you mean the first gen RPi ?
<bzoltan_> ogra_:  yes
<ogra_> thats not armv7
<bzoltan_> ogra_: yes armv6l
<ogra_> bzoltan_, ubuntu doesnt support pre-v7
<bzoltan_> ogra_:  I used to have ubuntu on my pandaboard es2 ... in 12.04 the video driver got busted, but in headless mode it was OK
<zyga> ogra_: is ubuntu-device-flash a good way to get a devel rpi2 image
<zyga> ogra_: or should I get a prebuilt one somewhere?
<bzoltan_> ogra_:  sorry for my ignorance, but what is the technical reason of not supporting first gen Pi?
<ogra_> bzoltan_, we dont have packagesd that coould run on that ancient arch
 * bzoltan_ has two 1stGenRPi boards
<ogra_> *packages
<sergiusens> we have no archive for that
<zyga> bzoltan_: hey man, how are you?
<ogra_> zyga, yeah, u-d-f is the best way
<zyga> ogra_: on vivid or do I need wily?
<bzoltan_> zyga:  hello there ... I started to do a hobby IoT project with RPi :) the new wind you know
<ogra_> just grab the device tarball and pi2 snap from http://people.canonical.com/~platform/snappy/raspberrypi2/
<ogra_> zyga, it will work on both
<zyga> bzoltan_: nice
<zyga> bzoltan_: I got a pi2 myself just today
<zyga> bzoltan_: though my needs are more mudane
<zyga> ogra_: hmm, how do I run it? (what's the release to use? 15.04?)
<bzoltan_> zyga: ohh Pi2 I have since it came out ...serving well as media box :)
<zyga> bzoltan_: I have 1st gen pi and two beagles
<bzoltan_> zyga:  But I want to play with the 1st boards too
 * zyga looks up 
<bzoltan_> zyga: beagle I have one .. and a panda ... + 4 N810 + 2 N900 +1N950 +N9 :)
<zyga> ah
<zyga> bzoltan_: I don't have a panda anymore, still have a beagle
<zyga> (this turns into a who-has-what contest ;)
<ogra_> zyga, udo ubuntu-device-flash core --channel=edge --oem pi2_0.15_all.snap --developer-mode --device-part=device-pi2-0.15.tar.xz -o pi2.img rolling
<bzoltan_> zyga: and I just bricked an Arduiono Mini... freaking sensitive piece
<zyga> ogra_: thank you!
<ogra_> zyga, that would get you a "latest wily" image
<bzoltan_> zyga:  Panda I used with Ubuntu desktop :) awesome hw
<zyga> ogra_: is that the best image to follow?
<zyga> ogra_: e.g. vs 15.04/
<ogra_> zyga, udo ubuntu-device-flash core --channel=edge --oem pi2_0.15_all.snap --developer-mode --device-part=device-pi2-0.15.tar.xz -o pi2.img 15.04
<zyga> ah, thanks
<ogra_> would give you the latest un-QA-ed 15.04 build
<zyga> zyga@virtual-fx:~$ sudo ubuntu-device-flash core --channel=edge --oem pi2_0.15_all.snap --developer-mode --device-part=device-pi2-0.15.tar.xz -o pi2.img rolling
<zyga> Determining oem configuration
<zyga> pi2_0.15_all.snap failed to install: snappy package not found
<zyga> hmm?
<ogra_> did you download it to $PWD ?
<sergiusens> zyga: download that snap ;-)
<ogra_> else you need to supply the path
<zyga> ahhh
<zyga> no
<zyga> where from?
<sergiusens> zyga: .snap means on disk (we can make that error message clearer)
<ogra_> i'll upload it to the store before next 15.04 image
<zyga> sorry, I'm a bit of a noob here
<ogra_> then you dont need to download anymore
<zyga> sergiusens, ogra_: so where's the pi2_0.15_all.snap?
<ogra_> at the url i pointed you to above
<ogra_> next to the device tarball :P
<zyga> ogra_: oh, I missed that
<zyga> ogra_: sorry, thanks I get it now
<ogra_> :)
<imuguruza> ogra_: same as before
<imuguruza> thanks anyway for the link
<ogra_> imuguruza, hmm, k
<sergiusens> elopio: you around and about yet?
<zyga> mvo, sergiusens: I think I fixed python3-project plugin
<zyga> to work correctly now
<zyga> I'll have a branch for review in a moment
<zyga> but the simple trick is this: run python3 from stage dir
<zyga> use --prefix=/usr
<zyga> use --root=installdir
<zyga> that seems to do the right thing for what I tried so far
<zyga> I'll do some bigger tests in a second
<sergiusens> zyga: thanks, I guess this can apply to py2 as well?
<zyga> sergiusens: yes
<mvo> zyga: woah, you rock
<zyga> sergiusens: and if you combine that with setuptools hack
<zyga> sergiusens: then it can almost be the pip plugin
<zyga> sergiusens: to the point where I wonder if it's better to do a special source URL
<zyga> sergiusens: pip:whatever(==version)
<zyga> sergiusens: and get the tarball and carry on from there
<zyga> sergiusens: I'll try with something that has C extensions next
<zyga> sergiusens: as I suspect it's "not that easy" ;)
<zyga> but I think this is very promising
<sergiusens> zyga: well we need to write a specific pip plugin anyways ;-)
<zyga> sergiusens: essentially it now works with dependencies for free
<sergiusens> zyga: with setup tools you mean? My hackish solution did get me all the deps without me worrying which was good :-)
<zyga> sergiusens: python3-setuptools
<zyga> sergiusens: if you use the ubuntu plugin internally
<sergiusens> \o/
<zyga> sergiusens: anyway, wait, I just need a few more iterations, I just wanted to let you guys know this is close to being universally useful
<zyga> sergiusens: the one thing that is still a pain is /usr/bin/python{,3,3.4} shebangs
<zyga> sergiusens: that's the ubuntu plugin to fix this though
<zyga> sergiusens: those are staright from the package
<zyga> sergiusens: alternatively I could build a custom python from debian sources but the fact that sideloading changes paths would break everything
<zyga> sergiusens: unless I hard-code --prefix for python to /apps/$name/current/
<zyga> sergiusens: but that seems evil
<zyga> sergiusens: and racy (current symlink replacement)
<zyga> *straight
<sergiusens> zyga: I don't mind ignoring the shebang and calling out python[2,3]
<zyga> actually... .python has the right sys.prefix
<zyga> sergiusens: yeah but that breaks generated scripts
<zyga> sergiusens: that sucks a lot
<sergiusens> but ideally those shebangs should be clean
<zyga> sergiusens: it only works when you run one progam
<zyga> sergiusens: and that program never runs anything
<zyga> sergiusens: if it runs another (non exposed) program youre SOL
<zyga> sergiusens: I can fix setuptools generated scripts
<zyga> sergiusens: I wonder what's the (long?) tail that remains after that
<zyga> anyway, back to work
 * zyga would love for caching to be a bit smarter; rm -rf snap/ stage/ parts; is a slow way to iterate
<mindbender1> I asked this question on #ubuntu and was pointed here. So where is snappy used mostly?
<mindbender1> A simple Google search us not very clear on this.
<imuguruza> mindbender1: you can uset in embedded platforms like BeagleBone Black, RaspberryPi 2 o Odroidc1, for example
<mindbender1> Okay so mostly for embedded, small devices, and cloud?
<mindbender1> Not very much for desktop.
<clobrano> I'm looking at apparmor configuration, but how I can understand which capabilities (I mean, the names of the caps and their context) I need for an app?
<zyga> I have a _crazy_ working version
<zyga> I'll clean it up
<zyga> it now fixes shebangs for python
<zyga> for python3-project parts (python2 will be treated the same way)
<clobrano> mindbender1: I think Canonical is moving to adopt snappy as package manager even for desktop
<sergiusens> elopio: I bumped the build dep
<jdstrand> oh, I was going to answer clobrano
<sergiusens> zyga: nice
<zyga> sergiusens: btw, there's something weird when I snap python3:
<zyga> sergiusens: Snapping python3
<zyga> cp: uwaga: plik ÅºrÃ³dÅowy âusr/lib/python3/dist-packages/setuptools/scriptâ pojawiÅ siÄ wiÄcej niÅ¼ raz
<zyga> cp: nie moÅ¼na wykonaÄ stat na â(dev).tmplâ: Nie ma takiego pliku ani katalogu
<zyga> sergiusens: "source file usr/lib... occurs more than once
<zyga> sergiusens: unable to stat "..." no such file or directory
<zyga> sergiusens: have you seen that?
<zyga> sergiusens: it seems harmless (so faR)
<sergiusens> zyga: no, I haven't, let me check
<zyga> sergiusens: I patched the python3 part to pull in 'python3-setuptools' and 'python3-pkg-resources'
<sergiusens> zyga: s/part/plugin/?
<zyga> sergiusens: plugin
<zyga> sergiusens: I need an architectural advice
<zyga> sergiusens: can a part depend on something from another path
<zyga> sergiusens: and if so, should that part look at the stage area or at the uninstalled part?
<zyga> sergiusens: in practical terms
<zyga> sergiusens: I'd like to force this sequenec:
<zyga> sergiusens: part A: build
<zyga> sergiusens: part A: stage
<zyga> sergiusens: part B: build (can take advantage of A)
<zyga> sergiusens: part B: stage
<zyga> sergiusens: what do you think?
 * zyga found two more bugs in snapcraft 
<zyga> quoting :)
 * zyga found another bug in part.env() 
<zyga> eh
<zyga> quoting is fundamentally broken
<zyga> sometimes we depend on expansions, sometimes not
<zyga> mvo: do you know what's the point of common.run() and assemble_env() there?
<zyga> mvo: why not subprocess.check_call()
 * zyga smells go in all of that code
<zyga> the 0 return codes
<zyga> I'd much rather have exceptions really
<zyga> it's not pythonic
<sergiusens> zyga: isn't that what 'after' is for?
<sergiusens> zyga: but mixing parts was a no no... I can revisit as soon as I am more interiorized with snapcraft
<zyga> sergiusens: mmmm, so how would you expect python libraries to work together?
<zyga> sergiusens: would you (offtopic) accept de-goification patches that remove non-pythonic code like return subprocess.call(...) == 0 ?
<sergiusens> zyga: lol de-goification; I don't know who wrote this code originally (but I think either of the folks who did knew more about python), but yeah, I added a bunch of tasks that involve cleanups
<zyga> sergiusens: fantastic, so I won't hold back
<zyga> sergiusens: thanks
<zyga> sergiusens: so please tell me how you think python parts should work
<zyga> sergiusens: and I'll have a nice set of patches for you
<zyga> sergiusens: (including fixing all the shell quoting bugs in the code)
<sergiusens> zyga: https://trello.com/search?q=%23technical in case you want to go crazy
<zyga> mmm
<zyga> nice
<zyga> sergiusens: if python parts cannot meaningfully depend on each other, then the part that pulls in the top-level thing will need to pip-install (equivalent) everything
<zyga> sergiusens: now the question is
<zyga> sergiusens: is it the right assumption that nobody will ship more than one part like that
<zyga> sergiusens: so my snap has parts A and B (both python3-projects, for example)
<zyga> sergiusens: and they technically both depend on the C library
<zyga> sergiusens: should it get bundled twice?
<zyga> sergiusens: and if so, this would require major changes to how it's done now
<zyga> sergiusens: as each A an B would essentially bundle python with a special prefix
<zyga> sergiusens: what do you think
<sergiusens> zyga: I think the key here is in using the 'after' keyword
<sergiusens> zyga: in a C/autotools whatever app, you can do something like depend on another part being built; take a look at my wiki branch for a quick example
<zyga> sergiusens: mmm, I'll try, I used requires: but that didn't stage them
<zyga> sergiusens: I'm fine with after if it works
<sergiusens> zyga: http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/snapcraft/yaml.py#L120
<zyga> sergiusens: I've been there :-)
 * zyga tries
<sergiusens> zyga: maybe the python plugin needs to extend PYTHONPATH into he env
<zyga> sergiusens: yeah, I already did that
<zyga> my patch is pretty big now
<zyga> more like 3-4 different things there
<sergiusens> zyga: yeah, I always have that problem. I just split after, I gave up on using pipelines as I end up putting everything in the same pipe as I start getting excited :-P
<zyga> sergiusens: hmm, I must be missing somethnig, it's not staging things
<zyga> sergiusens: snapcraft.yaml: http://paste.ubuntu.com/12207670/
<zyga> sergiusens: output of snapcraft build http://paste.ubuntu.com/12207680/
<zyga> sergiusens: (I need to introduce you to python3-guacamole)
<sergiusens> zyga: I think I saw a g+ post
<sergiusens> ;-)
<zyga> sergiusens: 0.10 has some amazing features coming up
<zyga> sergiusens: here, my patched python3-application part/plugin is trying to run python3 from stage directory
<zyga> sergiusens: as that's where everything is supposed to be, er, staged, right?
<zyga> sergiusens: the whole build sequence (correct me if I'm wrong) feels like [part.build() for part in parts]; I'm still unsure how stage works
<sergiusens> zyga: iirc, staging happens after all parts have built, use after, but on line 83 we should see an extended PYTHONPATH
<sergiusens> you said you added that already?
<zyga> sergiusens: yes, but it's not working, Python3ProjectPlugin.env() is not getting called
<zyga> sergiusens: but wait
<zyga> sergiusens: it's irrelevant, it's not going to work this way
<zyga> sergiusens: each python3project part needs _staged_ python3
<zyga> sergiusens: will after enforce that?
<zyga> sergiusens: did I mess up the snapcraft.yaml
<sergiusens> zyga: nope
<zyga> ahh
<sergiusens> zyga: and nope
<zyga> okay
<zyga> mmmmm
<zyga> so .. how would you feel about incremental staging?
<zyga> it'd be hard to point parts at un-staged python3
<zyga> and then point that python3 at each un-staged python3project part
<sergiusens> zyga: I would need to take that to the architects, here's me channelling it through rsalveti ^
<zyga> sergiusens: okay, thanks
<zyga> sergiusens: in the meantime, I have a way out:
<zyga> sergiusens: use one python3project
<zyga> sergiusens: and solve deps internally with pip
<zyga> sergiusens: so snapcraft.yaml will really only list one part
<sergiusens> zyga: I think that would be the defacto path forward
<zyga> rsalveti: I' love what you think about this
<zyga> sergiusens: this feels broken anyway, since parts are not reusable
<sergiusens> zyga: as pip is on the roadmap for pluginizing
<zyga> sergiusens: yeah, I wonder how it would solve this issue
<zyga> sergiusens: what I have now is equivalent to pip
<zyga> sergiusens: I _do_ handle deps like pip does now
<sergiusens> zyga: yeah, not in python at least, they are in c/c++
<zyga> sergiusens: wait, what? I'm lost -- how would the upcoming pip plugin solve this exact issue
<zyga> sergiusens: would it also allow one big part
<zyga> sergiusens: or would it try to solve the many-parts problem?
<sergiusens> zyga: one big part, just like when using go.
<zyga> sergiusens: and if I have one big part
<zyga> sergiusens: and I want another big part
<zyga> sergiusens: I cannot get that because unlike go, there's no static linking
<zyga> sergiusens: and you'll get file conflicts
<zyga> sergiusens: this smells like a design issue
<zyga> sergiusens: parts cannot be mixed together
<zyga> sergiusens: __unless__ each pip part uses custom prefix and bundles python
<zyga> sergiusens: that would be pretty tragic though IMHO
<sergiusens> zyga: that is solved in the stuff I'd be working on if I wasn't talking here :-) (conflicting files)
<zyga> sergiusens: so identical files won't conflict?
<zyga> sergiusens: that'd be great
<zyga> sergiusens: okay, thanks for all your time
<zyga> sergiusens: I will iterate tomorrow, I still think that without incremental staging this cannot be solved
<zyga> sergiusens: (runtimes need to run)
 * rsalveti reading backlog, back from lunch
<rsalveti> zyga: a part can depend on another part by using after
<rsalveti> and the plugin itself can handle the dependencies/reuse of parts
<rsalveti> to avoid conflicts, we do need to flatten the dependencies, each as a normal part
<rsalveti> but that is not yet done
<zyga> rsalveti: I'd like to understand how that interacts with staging, e.g. a in incremental build process (librarya, libraryb, program[liba, libb]) will need a common staging area to discover other pieces
<zyga> rsalveti: for the case where I care (python3) sergiusens pointed me to an upcoming design document
<rsalveti> right, a part is built separately but it can stage the resulted binaries and libraries
<zyga> rsalveti: and I suspect that will be enough
<zyga> rsalveti: so if you agree that staging can be incremental (part after part) then I'm in agreement and I see no problems
<rsalveti> right
<rsalveti> don't see why not
<zyga> rsalveti: excellent, I'll work on that with sergiusens
<elopio> ogra_: when is this released? https://code.launchpad.net/~mvo/snappy-hub/lp1480248-norootwait/+merge/269032
<mvo> elopio: it was in the review queue in the store, I now approved it
<elopio> mvo: great, thanks.
<sergiusens> elopio: do we need to install python3-jsonschema manually https://code.launchpad.net/~sergiusens/snapcraft/validation/+merge/269120/comments/677688 ?
<sergiusens> elopio: python3-mccabe would be good there too
<elopio> sergiusens: I've installed them.
<sergiusens> elopio: \o/
<sergiusens> elopio: btw, now that you are back https://code.launchpad.net/~sergiusens/snapcraft/icon-meta/+merge/269446 ;-)
<zyga> re
#snappy 2015-08-28
<elopio> pitti: I'm not sure how to send a pull request to the autopkgtest debian branch, so I attached a patch: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1488358/comments/5
<ubottu> Launchpad bug 1488358 in autopkgtest (Ubuntu) "Can't increase the wait_for_ssh timeout" [Medium,Confirmed]
<pitti> elopio: just saw, thanks! looks good
<elopio> cool :)
<pitti> elopio: I'd just rename it --timeout-ssh, just in case we ever add others
<elopio> pitti: makes sense. Want me to update the patch?
<pitti> elopio: nah, I think I'll be able to do that :)
<elopio> pitti: even better :)
<elopio> good night then.
<elopio> thanks pitti!
<pitti> elopio: sleep well! adjusting/testing/committing now
<zyga> good morning
<imuguruza> good morning zyga!
<zyga> I will be working on changing how environmet is handled in snapcraft
<zyga> I'll post my patches after breafkast, I made it work yesterday but I need to clean it up and run some tests
 * ogra_ returns from dentist 
<Chipaca> lunch break \o/
<rickspencer3> ogra_, lool for some reason you guys seem like you could advice
<rickspencer3> is there some way I could craft a script or command for my desktop that would allow me to see the journctl output for a snap?
<rickspencer3> I'm thinking that it would be nice if I could do snappy-remote install and then in some way script getting the output over ssh
<ogra_> i think that only works if your snap uses a systemd unit
<ogra_> you can indeed just grep for your snap name in syslog
<ogra_> not sure if thats sufficient
<rickspencer3> ogra_, well, I guess the idea is, I would like it to be automated from the host development desktop to the board
<rickspencer3> sorry, that didn't make much sense
<ogra_> well, i dont think you can read syslog or run journalctl as normal user
<ogra_> which makes using ssh a bit tricky
<rickspencer3> ogra_, currently I ssh into the board, and then run sudo journalctl --unit
<ogra_> (in an automated way)
<ogra_> yes
<ogra_> not sure if that works without password request so that you can script it
<rickspencer3> I'd like to make it easier for developers to access their println statements from their desktops
 * ogra_ wishes we had stayed with upstart ... there you could just cat the log from your specific upstart job
<zyga> ogra_: well, you can still redirect stdout from a systemd unit to a file, right?
<zyga> ogra_: it's just that it goes to journal normally
<ogra_> yeah
<ogra_> argh ! ... so i finally have a proper resize script using parted ... and am trying it for the first time ...
<ogra_> Error: the resize command has been removed inpparted 3.0
<ogra_> *in parted
 * ogra_ curses loudly 
<ogra_> so remove->re-add is mandatory ... how sad
<Chipaca> ogra_: sfdisk | sed | sfdisk ftw
<ogra_> Chipaca, no sfdisk for me ...
<ogra_> unless someone takes over ricmm's meeting schedule so he can produce the patch :P
<Chipaca> i probably still have a 3.5" floppy with PM2.EXE
<Chipaca> or was that PM8
<ogra_> lol
 * ogra_ adds "mknod /dev/floppy" to his script
<sergiusens> elopio: easy peasy https://code.launchpad.net/~sergiusens/snapcraft/split-up-collect/+merge/269519
<kyrofa> sergiusens, ping
<sergiusens> kyrofa: pong
<kyrofa> sergiusens, can you explain the thought process behind SNAPPY_GLOBAL_ROOT ? I was hoping I could just change the location where things were installed, but it also changes where the hooks are looked for, etc.
<sergiusens> kyrofa: it's only useful for provisioning, as in 'chroot', it changes '/'
<kyrofa> sergiusens, alright, thanks :) . Just wanted to understand the purpose there
<sergiusens> kyrofa: it's for u-d-f mostly
<kyrofa> sergiusens, makes sense
<sergiusens> :-)
<sergiusens> elopio: Chipaca can I get your initial comments on https://code.launchpad.net/~sergiusens/snapcraft/less-source/+merge/269547
<elopio> sergiusens: initial comment is that it looks great.
<elopio> I'll probably review it tomorrow.
<sergiusens> elopio: great; I will probably be adding tests to each of the source classes in a bit; just got through this major shift
#snappy 2015-08-29
<rajen> #lool
<pindonga> hi anyone around? how can I specify snappy to run everything unconfined (so that I can test everything works, before starting to restrict things)
<pindonga> I've tried specifying security-template: unconfined, but it doesn't seem to be enough (I get 'bad system call' errors when the program tries to setuid
<pindonga> (it's a daemon)
#snappy 2015-08-30
<ogra_> ricmm, rsalveti fyi http://paste.ubuntu.com/12230139/ ... (i still need to test the mbr path, gpt works fine though)
<ogra_> (got quite big and ugly)
<bzoltan_> ogra_:  is there a non snappified vivid core image... like as it used to be? If not, then how can I turn back a snappified core image to support apt?
<bzoltan_> ogra_:  please ignore me ... I am an idiot
#snappy 2016-08-29
<huwshimi> Hello. I have a snap that installs, but doesn't expose the command. I can see the file for the command in places like stage/usr/bin, but once the snap is installed the command does not exist. Snap here: http://paste.ubuntu.com/23105293/
<huwshimi> Any guidance appreciated!
<mup> PR snapd#1772 opened: cmd: enable SNAP_REEXEC only if it is set to SNAP_REEXEC=1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/1772>
<mup> Bug #1617890 opened: 2.12 crashes with latest ubuntu-core snap due to re-exec <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1617890>
<mup> PR snapd#1773 opened: firstboot: disable firstboot on classic for now <Created by mvo5> <https://github.com/snapcore/snapd/pull/1773>
<mup> PR snapd#1774 opened: tests: add test for current snapd with ubuntu-core/edge interactions <Created by mvo5> <https://github.com/snapcore/snapd/pull/1774>
<dholbach> hey hey
<liuxg> I have python as plugin in both parts, when building the projects, some files are copying to the same locatiton, resulting conflicts like http://paste.ubuntu.com/23106210/. how can I avoid this issue?
<tvoss> good morning :)
<dholbach> liuxg, maybe file a bug report on snapcraft?
<liuxg> dholbach, yeah, I think so. I will do that, thanks
<dholbach> thanks
<liuxg> dholbach, I have reported it at https://bugs.launchpad.net/snapcraft/+bug/1617907
<mup> Bug #1617907: Two python parts in the same snapcraft.yaml result in not installing the python correctly <Snapcraft:New> <https://launchpad.net/bugs/1617907>
<dholbach> great
<mvo> pitti: hi, quick question - we have the netplan config in snapd now, its great. its also static, so I would like to ship it just in the ubuntu-core-config (which is only installed on ubuntu-core devices)  package as a static /etc/netplan/00-default.yaml  package
<mvo> pitti: eh, static file of course. any reason not to do that?
<pitti> mvo: what does it contain?
<zyga> good morning
<pitti> mvo: I'm not a big fan of constant config files in /etc, I must say
<pitti> mvo: if we start doing that, I'd rather add support for /lib/netplan/*.yaml
<mup> PR snapd#1769 closed: snap: add export-key --account= option <Created by cjwatson> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1769>
<tvoss> mvo: hey, did you have a chance to raise the topic of vendorizing go build deps for snapd?
<mvo> pitti: support for /lib/netplan/*.yaml sounds great, if its not too much work, I can also look at it if you are too busy
<pitti> mvo: already at it
<mvo> tvoss: not explicitely, we talked about it in the team recently and the concensus was that we want to do it
<mvo> pitti: cool, thanks! for context: https://github.com/snapcore/snapd/pull/1765/files#diff-7c06ac92ab14c8f3ece674037573ceddR14 is the config we want to ship by default
<mup> PR snapd#1765: many: move network initialization to a separate service <Created by mwhudson> <Conflict> <https://github.com/snapcore/snapd/pull/1765>
<pitti> mvo:/url 2
<pitti> mvo: oh - DON'T ever ship that in a package
<pitti> mvo: this means that you cannot ever reconfigure any device, as 00-* is always the first match
<tvoss> mvo: ack, will join your standup today then (if I can make it)
<mvo> pitti: ok, so this needs to be 99-ubuntu-core-defaults if we move it to a package?
<pitti> mvo: mwhudson discussed that with slangasek and me recently; AFAIR the idea was to only create that file in /run/ if there is no actual config (i. e. before running console-conf), and as soon as there is some /etc/netplan/* then not generate it any more
<mvo> pitti: and it would be in a package that is only installed on core systems, is that ok?
<mvo> pitti: oh, I see /run - hm
<pitti> mvo: actually, the name of the *.yaml is not that relevant
<pitti> there is no natural order in the yaml definitions
<pitti> other than that later definitions override previous ones
<mvo> pitti: hmhm, ok, let me ponder a bit if we only want this in /run under these conditions that changes the picture a little bit
<pitti> mvo: I suggest talking to mwhudson, he is also working on this and it seems that there is a lot of overlap and not enough coordination
<mvo> pitti: yeah, I started talking to him and he directed me to you :) thanks, I think I know all I need to know for now
<pitti> mvo: anyway, suport for /lib/netplan/ committed, it would also be useful for things like lxc (bridge configs)
<mvo> pitti: \o/
 * ogra_ grins about https://github.com/snapcore/snapd/pull/1573
<mup> PR snapd#1573: asserts/tool,cmd/snap: introduce hidden "snap sign" <Created by pedronis> <https://github.com/snapcore/snapd/pull/1573>
<ogra_> we have a secret handshake !
<ogra_> cjwatson, is there any known way for me to find out a revision number for a snap that was auto-uploaded by LP ?
<ogra_> (would be nice to be able to map a revision to a build number and log)
<ogra_> i see i get a "manage this package in the store" link after successful upload on the UI page, but i dont see anything in the LP api that would map to this
<zyga> ogra_: do you have a 3.4 based kernel around on any device?
<pitti> ogra_: manual wifi bringup with wpasupplicant and networkd works fine; now it's a SMOP :)
<zyga> ogra_: would you mind doing ls -ld /proc/$$/ns/mnt for me?
<ogra_> zyga, snappy device ? no, i dont
<pitti> ogra_: (and SMOWTC)
<zyga> ogra_: no, any device
<zyga> ogra_: (phone is good)
 * ogra_ hugs pitti and looks up acronyms :)
<pitti> ogra_: I just made it up -- SMO writing test cases :)
<ogra_> :)
<pitti> ogra_: oh, "simple matter of programming" (but that's rather common)
<zyga> hah
<zyga> it's all doable, it's all software ;)
<ogra_> zyga, i only have 3.10 :/
<cpaelzer> Hi, I was asked by elopio to move some bits out of my waf integration test belonging to PR 716 to be an external part
<zyga> ogra_: that's actually good, is that ubuntu phone?
<ogra_> yes
<cpaelzer> I thought I updated https://wiki.ubuntu.com/snapcraft/parts the right way, but something is missing
<ogra_> ooh ...
<zyga> ogra_: thanks, I was worried that older kernels are still around
<cpaelzer> is there any update cycle or anything I have to wait until I can discover a part there?
 * ogra_ just found one machine in his network running 2.6.37 
<ogra_> i guess its time to upgrade that one
<ogra_> zyga, they are ... u just dont have any active phone with them anymore
<ogra_> s/u/i/
<ogra_> zyga, only the last two devices had 3.10
<ogra_> nexus and the bq phones are all 3.4
<cpaelzer> no matter if the part is already right yet (not sure on that part) I'd have expected that "snapcraft update && snapcraft search wafdemo" gets me something, but it doesn't
<mup> PR snapd#1775 opened: Add thumbnailer interface <Created by fkaleo> <https://github.com/snapcore/snapd/pull/1775>
<ogra_> cjwatson, there is an update on bug 1608432 for you
<zyga> mwhudson: around?
<mup> Bug #1608432: snaps with type: os should allow publishing of .manifest files <launchpad-buildd:New> <Snapcraft:Incomplete> <https://launchpad.net/bugs/1608432>
<mup> PR snapd#1773 closed: firstboot: disable firstboot on classic for now <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1773>
<Son_Goku> morning
<zyga> Son_Goku: hey
<Son_Goku> hello
<Son_Goku> zyga, so, did you get anywhere on the path relocation?
<zyga> Son_Goku: yes, it basically works now, I need to work on selinux support in systemd to let the service start now
<ogra_> mvo, btw, not sure you have seen https://github.com/snapcore/classic-snap/pull/4
<mup> PR classic-snap#4: merge recent changes that are in the store, improve bin/classic <Created by ogra1> <https://github.com/snapcore/classic-snap/pull/4>
<ogra_> (sorry for the ping in the wrong channel before)
<Son_Goku> zyga, you might want to look at the abrt service policy as an example
<Son_Goku> https://github.com/fedora-selinux/selinux-policy/tree/rawhide-contrib
<mvo> ogra_: checking
<mup> Bug #1618004 opened: Need a classic-bin interface to see classic binaries <Snappy:New> <https://launchpad.net/bugs/1618004>
<mvo> ogra_: thanks, nice one, merge - I assume you alrady pushed it?
<ogra_> mvo, not yet, doing so now (i didnt know how you wanted to handle the missing bits)
<mvo> ogra_: I think its was a forgoten push on my side, sorry for that
<ogra_> NP
<mup> PR snapd#1683 closed: osutil: fix create-user on classic <Reviewed> <Created by jaymell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1683>
<mup> PR snapcraft#763 opened: Include /sbin and usr/sbin in wrappers <Created by lool> <https://github.com/snapcore/snapcraft/pull/763>
<arges> elopio: I see bug 1616157 has been verified, should I tag it 'verification-done'? And mvo is it ready for release into xenial?
<mup> Bug #1616157: [SRU] 2.13 <verification-needed> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1616157>
<mup> PR snapd#1776 opened: image: snap assertions into image <Created by pedronis> <https://github.com/snapcore/snapd/pull/1776>
<mup> PR snapd#1723 closed: image: prepare-image: import snap assertions as well <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1723>
<mup> PR snapd#1777 opened: osutil: tweak the createUserTests a bit and extract common code <Created by mvo5> <https://github.com/snapcore/snapd/pull/1777>
<mvo> arges: I have a look, in a meeting right now
<Kaleo> zyga, hey :) thanks for the review
<Kaleo> zyga, looks like I forgot a commit :)
<ogra_> hmm, no sergio today ?
<Kaleo> zyga, please ignore the entire PR until I add that commit :)
<Kaleo> zyga, and voila
<Kaleo> zyga, I'm sorry I wasted your time
<Kaleo> zyga, about the snap/implicit.go, is there some documentation of what it means?
<zyga> Kaleo: I'll check it after the meeting
<Kaleo> thanks
<zyga> Kaleo: look at snap/implicit.go and look what's there, there's no docs but I have a blog post about it on zygoon.pl (the lastest one)
<zyga> Kaleo: please check it out
<Kaleo> cheers
<jdstrand> lool, tianon: hey I read lool's status on the docker PR progress. I thought there were still some open questions that needed to be addressed before another review and I got the impression one of you would be working on the kernel modules backend.
<lool> jdstrand: I actually got the impression you would be coming back to the review after a while
<lool> jdstrand: :-)
<jdstrand> well, I planned to come back to the review, but thought people were working on the kernel modules backend
<lool> jdstrand: I'm not sure who if anyone has time to work on the kernel module backend
<jdstrand> if it makes sense for me to do another round of reviews, I can
<jdstrand> hrmm
<lool> I dont know if I can ask tianon to work on this, if he can't I imagined I'd end up doing it
<lool> but I was hoping someone from the core team would come to it first
<jdstrand> lool: this might be a question to have with JamieBennett
<jdstrand> err
<jdstrand> a conversation to have with him
<lool> Yes
<lool> jdstrand: it would be helpful to know how much other things are needed for this to get in
<lool> how many / how much work
<jdstrand> I was assigned some high priority (snappy) work a week and half ago so I've been trying to get through all that while (I thought) the other issues with docker were being worked on. if you're saying you're blocked on me, I can try to get through that review today
<lool> jdstrand: I think we're blocked on your next review + this kernel module feature which isn't docker specific but that docker seems to need first
<lool> jdstrand: I dont know of other work on the snap / interface that was requested in the pull request and wasn't done
<jdstrand> lool: fwiw, that feature is needed by firewall-control for the GA release for a customer requirement. it's also needed by ppp interface
<jdstrand> I guess I'll take a look at that. I'll try to get to that today
<lool> jdstrand: cool; I'm currently debugging other issues with the docker snap on classic (works on core but not on classic with weird errosr)
<zyga> jdstrand: before 3.8 /proc/$PID/ns/mnt did not exist
<jdstrand> zyga: sounds like that is a patch to add to the list. I wonder how intrusive it is. I suspect very-- we've said in the past 3.4 kernels can't be used to run lxd/docker
 * jdstrand is recalling from memory. ogasawara would probably have the definitive answer
<lool> I thought 3.10 was needed for systemd anyway?
<zyga> jdstrand: we have a few options for that
<zyga> jdstrand: one easy one is that this feature is not supported on 3.4
<zyga> jdstrand: a more complex one could usee a zygote process
<zyga> jdstrand: and a backport for this patch could be a third approach
<zyga> lool: I'm not sure
<zyga> lool: if so, then this discussion is moot, I guess this is about defining a baseline kernel for snappy
<tedg> Is there a recommended way to get $HOME back to the correct value?
<tedg> Tried with getent, but don't have permissions.
<zyga> tedg: I don't believe there is
<lool> I believe the oldest we provide for apparmor patches is 3.10
<tedg> Uhg, it makes the open/close dialog in Inkscape mostly unusable :-(
<lool> we probably had older patchsets, but we haven't updated them
<jdstrand> zyga: I really don't like the zygote approach in general. it depends on how it is implemented
<zyga> tedg: snappy could easily set a variable like SNAPPY_OLD_HOME
<stokachu> im trying to get my systemd bridge service working and not able to get an ip assigned to it, https://paste.ubuntu.com/23107318/
<lool> actually systemd requires >= 3.4
<zyga> jdstrand: I think we agree on this
<jdstrand> lool: apparmor isn't the probelm-- we have patches for 3.4 kernel for touch
<jdstrand> I'm not sure how up to date they are as of this second, but that is certainly possible.
<lool> jdstrand: in the snappy kernel templates, we only offer 3.10 and onwards
<mvo> arges: yeah 2.13 looks good, the issues that elopio mentioned with gnome-software is a bug in 2.12, we are working on a fix
<jdstrand> lool: ogasawara maintins a list somewhere
<Son_Goku> lool, afaik, newest systemd requires kernel >= 3.14, iirc
<tedg> zyga: Sure, but then I'd need a specific version of ubuntu-core, which I can't depend on.
<jdstrand> lool: that may be because other things have made them say that 3.4 is not possible, so we said "well, then we don't have to produce apparmor backports"
<lool> jdstrand: https://docs.google.com/document/d/1LOqrSty2yTsUtQ4nFehaisZc4XmKKsK_E_tz-O1hU-M/edit
<jdstrand> sure, it is a cause and effect thing
<jdstrand> the effect of not supporting snappy on 3.4 is that it causes the security team to not provide backports to 3.4 :)
<lool> jdstrand: yup; I'm just trying to be realistic; I believe the oldest we consider maintainable is 3.10, but of course everything is possible  :-)
<ogra_> tedg, just use /home/$USER ?
<jdstrand> sure. I'm just saying that *apparmor* is not why it isn't maintainable
<lool> jdstrand: sorry it's just the first thing we're missing when we're applying the ubuntu patches
<lool> (over vanilla / bsp kernels)
<zyga> tedg: you can, there's a mechanism for that
<tedg> ogra_: Yeah, can try that as a work around. Good idea.
<lool> didn't
<lool> didn't mean to pick on these patches specifically
<lool> it's all our ubuntu sauce
<zyga> tedg: assume (or somethng like that) you can put this into your snapcraft.yaml
<lool> jdstrand: this was an earlier effort of mine to capture the reqs https://docs.google.com/document/d/1W9TJDTWevnxARYaE3w7fahXeCgjv_9xJ2RTZ6nN0Va4/edit
<zyga> tedg: in general it feels like a bug to fix
<lool> which was after internal consultation
<ogra_> zyga, but rarher in the desktop launcher than in snapcraft
<ogra_> err
<ogra_> snapd
<ogra_> after all it is the launcher wrapper script that forces $HOME
<tedg> zyga: Hmm, I see that in the snapcraft schema, but I don't see what the string needs to look like. "ubuntu-core>x.y.z" ?
<zyga> tedg: it's a list of strings
<zyga> tedg: each string is a feature flag you can request from snapd
<zyga> tedg: e.g. old-home-env
<zyga> tedg: snapd knows which flags it supports
<zyga> ogra_: no, that's actually in snapd itself
<tedg> zyga: Oh, so it's not requesting a specific version as much as a set of features.
<zyga> ogra_: the launcher doesn't change home AFAIR
<zyga> tedg: exactly
<zyga> ogra_: the wrapper script is made by snapd
<ogra_> i thought it has HOME="$SNAP_USER_DATA"
<zyga> ogra_: and since 2.14 those are gone
<zyga> ogra_: so this is all managed internally in snapd
<zyga> ogra_: (no more wrappers!
<ogra_> (talking about the desktop wrapper here)
<zyga> ogra_: that's all snapd
<zyga> ogra_: snapd can now set environment in the started app processes
<tedg> Wait, so how is snapd launching the process? Spawning from its own then?
<ogra_> zyga, yeah, i just checked, it doesnt touch HOME ... only creates a ton for XDG dirs in SNAP_USER_DATA
<tedg> Or is the CLI starting the application.
<ogra_> s/for/of/
<zyga> tedg: it's complex, the app name, say "foo", is a symlink to snap-run
<zyga> tedg: snap-run does some stuff, run snap-confine, which does some more and runs snap-exec which does some more and exec's the command associated with the snap
<tedg> zyga: So for starting apps I should be calling that symlink still? Or calling snap-run?
<zyga> tedg: nothing changes for the user
<zyga> tedg: this is all an internal change
<zyga> tedg: and snap-run is not on PATH AFAIK
<tedg> zyga: Well, I'm kinda a special user here :-)
<zyga> tedg: why?
<zyga> tedg: I mean, this should not be visible to anyone in practice
<tedg> zyga: Becuase we're setting up the exec in Upstart for desktop apps
<zyga> tedg: it's just an optimization that gives us some more control
<zyga> tedg: that should just run the command as it in the desktop file
<tedg> zyga: Ideally, but the desktop files aren't that useful.
<tedg> (the ones generated by snapd)
<zyga> tedg: perhaps what you want to do should be managed by snapd itself
<zyga> tedg: I'm not sure what this is exactly, feel free to ask for more information if that helps you
<tedg> zyga: I am :-)
 * ogra_ thought we are drooping Ãpstart this cycle from desktop
<stokachu> when i install a snap it runs both command and stop-command via oneshot
<stokachu> https://paste.ubuntu.com/23107384/
<tedg> zyga: Seems like the symlink should work fine for now.
<stokachu> i just need it to run the start command and then the stop command on uninstall
<tedg> ogra_: Trying for Unity7, not for Unity8.
<stokachu> not at once
<ogra_> ah
<zyga> anyone, what's the glib-way to rm -rf a directory?
<zyga> (this is for unit test code)
<ogra_> stokachu, i would imaggine running stop-command on install is a bug ... but nontheless your script should check if what it wants to stop is actually running
<stokachu> ogra_, huh? there is nothing running
<stokachu> the start command runs some ip/iptables commands
<ogra_> so it should exit gracefully
<ogra_> hmm, actuall running the stop command makes indeed sense on upgrades
<ogra_> so iits probably not a bug at all
<stokachu> it runs the start command then stop-command right after
<stokachu> running the stop-command before the command makes sense
<zyga> stokachu: note, this is all systemd stuff
<zyga> stokachu: nothing is done by snapd here
<zyga> stokachu: whatever you are experiencing is systemd related
<zyga> stokachu: we just start/stop units
<zyga> stokachu: (we do stop and start the units on upgrades)
<stokachu> you call stop-command after the start command?
<ogra_> zyga, well, you can define stop-command for a daemon
<ogra_> snapd should make sure what it generates can be run in the desired order
<lool> elopio: are the snapcraft integration tests usually passing? I get an error on snapcraft-parser
<ogra_> stop-command should be only run on shutdown or uninstall of the package ... or before an upgrade wants to start the daemon newly
<stokachu> which it's not doing now
<ogra_> right
<zyga> ogra_: snapd just generates a systemd unit file, all the running is done by systemd
<ogra_> zyga, well, but if snapd allows us to define a stop-command for a daemon it should not "just run"
<ogra_> only for stopping the daemon
<ogra_> so imho something is generated wrongly
<ogra_> probably a Chipaca topic
<zyga> ogra_: check the systemd unit, does it look good or bad?
<ogra_> no idea ... its stokachu's unit :)
<stokachu> where is that located
<ogra_> but it is clear that tthe two units run in the wrong oorder on package install
<stokachu> ogra_, zyga https://paste.ubuntu.com/23107454/
<stokachu> so my oneshot daemon runs command, then stop-command directly after
<lool> elopio: well they are passing on travis; not sure why it fails here
<zyga> stokachu: looking now
<zyga> stokachu: can you pastebin the snap.conjure-up.bridge.service file
<zyga> stokachu: it should be easy to find in /etc
<stokachu> zyga, https://paste.ubuntu.com/23107463/
<stub> Given I can do both, should I create my daemon simple or forking?
<lool> kyrofa: travis completed on the /sbin branch
<stub> Any advantages of one over the other?
<lool> (successfully)
<ogra_> zyga, stokachu, hmm, i wonder if it should actually be oneshot if it has a stop command defined
<lool> kyrofa: I couldn't open the autopkgtests links
<cmars> zyga, hi, i was following your blog post on writing an interface. i'd like to write one for libvirt, so that snaps can control it on a classic host
<mup> PR snapd#1772 closed: cmd: enable SNAP_REEXEC only if it is set to SNAP_REEXEC=1 <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1772>
<stokachu> ogra_, should i just put the tear down of iptables etc in the same start script
<stokachu> and handle it logically
<cmars> zyga, i got the socket part working, but the snap i'm working on wants to see stuff in /var/lib/libvirt, such as dnsmasq
<ogra_> you could indeed do that ...
<cmars> zyga, how would i expose that through the interface? (or is this even a good idea?)
<stokachu> ogra_, what about snap remove?
<ogra_> that would call stop
<stokachu> so maybe just a bridge script that'll accept an argument
<cmars> zyga, i tried adding /var/lib/libvirt/** to the aa profile, but the plugged-in snap doesn't seem to see it. is there some mounting that would need to happen?
<mvo> a new ubuntu-core stable got just released, it is based on 2.13, please do let me know if you notice any issues
<sergiusens> good morning
<mvo> arges: there was some talk about command not found hanlding? do you have some details for me?
<josepht> good morning sergiusens
<zyga> cmars: if you explore the environment you will see that /var/lib/libvirt just doesn't exist in the core snap
<zyga> cmars: as a easy workaround please look at snap-confine and at quirks.c therein (look for lxd quirk)
<zyga> cmars: note that this is only for a devmode snap as no interface allows any snap to use /var/lib/lxd
<zyga> cmars: I would recommend you to create an interface that bind mounts /var/lib/lxd from the host into a snap-specifc directory
<zyga> cmars: I'm not familar with libvirt, does it need just a socket or the whole directory tree
<cmars> zyga, the socket, but also parts of the tree, such as /var/lib/libvirt/dnsmasq, if you want to read the IP addresses of VMs for example
<zyga> cmars: I would recommend you to also report a bug tagged with snapd-interface and ask jdstrand for advice
<zyga> cmars: I see
<cmars> zyga, ok, will do
<zyga> cmars: we can use the mount backend to bind mount /var/lib/lxd to a directory in the snap (relative to $SNAP_DATA)
<stokachu> i thought interfaces was a last resort and that we should be packaging every requirement in the same snap
<zyga> cmars: then you can patch or config libvirt inside the snap to assume that libvirt is in that directory
<zyga> stokachu: interfaces allow to shape the sandbox in which apps execute
<zyga> stokachu: if you want to have a snap that talks to something in the classic world or talks to another snap you can use an interface for this
<stokachu> snaps have no notion of dependencies though
<zyga> stokachu: it feels perfectly fine to have a snap with libvirt or libvirt installed on classic and an interface that allows another snap to talk to libvirt (wherever it is)
<stokachu> how would someone know that libvirt is a requirement for cmars snap?
<zyga> stokachu: the snap would declare a plug of type 'libvirt'
<zyga> stokachu: we have no syntax for this but plugs will have a way to say "I have to be connected before this snap can be used"
<mhall119> zyga: is somebody working on adding the content interface details to the existing docs?
<elopio> lool: hello. What error are you getting locally?
<zyga> stokachu: then however that libvirt is provided (could be from the core snap, could be from another snap)
<cmars> i imagine it's a similar situation for snaps that need to plug into mir & x11
<zyga> mhall119: not that I'm aware of, I'll do this after snap-confine features for 1.0.41 are implemented
<zyga> cmars: yes
<stokachu> cmars, read the docs for now?
<elopio> cpaelzer: maybe josepht can help you with the wiki entry. I get no parsing errors, but I also don't get the new part.
<cpaelzer> elopio: ok, thanks for the update
<cpaelzer> elopio: that is why I opened the bug on LP to give people some time to really look at it
<lool> elopio: I couldn't reproduce it after rerunning; here's the one I get locally right now:
<lool> elopio: http://paste.ubuntu.com/23107571/
<cmars> zyga, thanks for the advice, snap-confine sources are clearing things up for me :)
<jdstrand> zyga (cc cmars): fyi, a libvirt interface is going to be super-privileged, like docker and lxd
<zyga> jdstrand: I agree, note that it seems that it is just the plug-side of libvirt for now
<jdstrand> session:/// wouldn't need to be. but no one uses session:///
<lool> elopio: python3 -m unittest -b integration_tests.test_parser is passing for me now, sorry; it failed a couple of times even when rerunning manually
<lool> perhaps wiki issue or something
<camako> I think snappy-playpen CI is having infrastructure issues ("No CMAKE_C_COMPILER could be found") on more than one PRs. Does anyone know why it's failing? Is there anyway to re-kick it (without updating the branch)?
<lool> elopio: ah I know what's going on
<lool> elopio: install: error writing '/tmp/tmpe3p0e0r9/simple-rust/parts/simple-rust/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc
<lool> _llvm-39b92f95.so': No space left on device
<lool> elopio: /tmp is in memory, the vm has 2G and that's apparently not enough
<josepht> cpaelzer: it looks like it's because your part is named 'waf-project' in your snapcraft.yaml and 'wafdemo' in the wiki.  The wiki entry needs to use the part name, not the project name.
<arges> mvo: not sure what you mean exactly
<elopio> lool: oh, that makes sense. The tests use tmp a lot, the real build doesn't.
<lool> elopio: yeah
<mup> PR snapcraft#764 opened: add support for snap-build grade parameter in snapcraft.yaml <Created by caio1982> <Conflict> <https://github.com/snapcore/snapcraft/pull/764>
<lool> elopio: this also explains why it transients (running other things took memory / disk space)
<lool> *was
<mvo> arges: sorry, if you don't know about command-not-found that is fine, it was in a google doc and I was referenced
<mvo> arges: I will find out, I thought the context was kernel stuff
<mvo> arges: in any case 2.13 should be good to go
<arges> mvo: i see it now, it was to ensure /snap/bin is in $PATH, that should probably be filed as a bug if it isn't already
<josepht> cpaelzer: fyi, the wiki is processed once an hour.
<lool> Error: Node Sass does not yet support your current environment: Linux Unsupported architecture (arm) with Node.js 4.x
<lool> damn it
<arges> mvo: and shouldn't block 2.13 regardless so I'm happy to release if there aren't any other issues
<elopio> josepht: shouldn't that print a warning on parse?
<mvo> arges: cool, no other issues
<cpaelzer> josepht: thanks a lot, trying that then
<josepht> elopio: yes, I'll update the bug so we can fix that
<mvo> arges: we pushed a fix for /snap/bin, let me search for the bug reference, one sec
<josepht> cpaelzer: I already updated the wiki
<mvo> arges: https://launchpad.net/ubuntu/+source/sudo/1.8.16-0ubuntu1.2
<arges> mvo: awesome thanks
<elopio> josepht: thank you.
<ogra_> mvo, any idea when this will land ? that must sit in -propsed since a month now
<ogra_> ah, well, 11 days ... my sense of time seems to be off :P
<mvo> ogra_: someone *cough* needs to do the verification, could be anone expect me (as I uploaded it)
<mvo> ogra_: help appreciated :)
<ogra_> on it
<mvo> \o/
<mvo> I'm sure arges will let it in once its verified
<arges> which package?
<mup> Bug #1618085 opened: snap run fails to run, cannot find app "me" in "me" <Snappy:New> <https://launchpad.net/bugs/1618085>
<ogra_> done
<mvo> arges: sudo itself
<ogra_> that wasnt actually hard :)
<mvo> arges: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1595558
<mup> Bug #1595558: sudo doesn't have /snap/bin in PATH <verification-done> <snapd (Ubuntu):Won't Fix> <sudo (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Won't Fix> <sudo (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1595558>
<mvo> ogra_: :)
<ogra_> mvo, what about shadow ? we still have it sitting in the PPA
<ogra_> did you plan to push the fixes to debian ?
<mvo> ogra_: thats the --extrausers fixes?
<ogra_> yeah
<ogra_> i cant remember if sergiusens pushed the former changes to debian or if we did a distro patch for that
<mvo> ogra_: I don't remember :/ I think I did send some patches some time ago and vaguely remember them sitting in the bts forever, but I may be wrong
<ogra_> we should get the PPA empty for RTM ... or at least between RTM and GA
<ogra_> so that we dont release any ubuntu-core into stable that cant be built from the archhive
<ogra_> (/me has already worked a bit on the cleanup, but there is still a lot to do)
<mup> Bug #1618095 opened: [SRU] 2.0.14 <Snappy:New> <https://launchpad.net/bugs/1618095>
<zyga> slangasek: around?
<ogra_> sergiusens, bug 1618019 seems like an easy fix
<mup> Bug #1618019: builds of "type: kernel" add obsolete options to snap.yaml <Snapcraft:New> <https://launchpad.net/bugs/1618019>
<ogra_> (or kyrofa ^^)
<kyrofa> ogra_, why are those keys no longer required?
<ogra_> kyrofa, because the kernel snap now is defined ... bits need to sit in the right paths inside it so you dont need any meta info anymore
<kyrofa> ogra_, "don't need" and "fail review because" seem slightly different. Everything is always so out of sync :(
<ogra_> kyrofa, i cant find the link to the final kernel.yaml doc anymore (as usual with gdoc ...) but all options except "type: kernel" and "version:" are gone
<ogra_> the snapcraft.yaml can indeed still use them for the kernel plugin ... but the snap.yaml should not have any of these anymore since the content is in pre-defined paths now
<ogra_> s/is in/has to be in/
<kyrofa> ogra_, isn't that the stuff that was just recently finalized?
<ogra_> (and dont blame me, i didnt define the kernel yaml :P )
<ogra_> afaik it was finalized in heidelberd
<ogra_> *heidelberg
<kyrofa> Oh I don't blame you, but I'd like to start doing this stuff with cross-project bugs instead of each project changing independently and making the others sprint to catch up
<ogra_> kyrofa, see pm
<sergiusens> ogra_ there is a really old card for extra users where mvo was supposed to add it to debian
<mvo> I think I did
<sergiusens> kyrofa ogra_ wrt kernel plugin, I asked for the spec on Wednesday, didn't get it
 * sergiusens is being short on words as he has a feverish kid up in arms
<ogra_> sergiusens, there is a gdoc from heidelberg that defines that only type and version are needed in snap.yaml
<ogra_> the rest is defined via pre-defined paths the binary stuff needs to be
<sergiusens> ogra_ link it to the bug please so I can check if everything required is being done
<sergiusens> ogra_ does this include the init chainloading?
<kyrofa> sergiusens, huh, mine has a fever this morning too
<ogra_> sergiusens, chainloading ?
<sergiusens> ogra_ initrd from os and kernel snap
<sergiusens> chainloading, munging, aggregation, ... whatever it is called
<ogra_> sergiusens, not defined anywhere ... but also not relevant
<ogra_> there will be an initrd in the kernel snap ... that wont change
<sergiusens> ok, just wondering if I can kill the logic that downloads the kernel snap
<ogra_> the changes are in gadget then
<sergiusens> the os snap
<ogra_> ah, not yet
<ogra_> i'll ping you ...
<ogra_> but thats for between RTM and GA
<ogra_> the logic will sit in the bootloader scripts and in the initrd build scripts ... neither needs anything from the kernel snap or from snapcraft atm
<ogra_> sergiusens, doc link added to the bug
<mup> PR snapcraft#756 closed: Use block style for multiline YAML values <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/756>
<stokachu> is the lxd interface auto connect?
<eldarkg> kyrofa: hello
<kyrofa> eldarkg, hey, welcome!
<eldarkg> kyrofa: I was talking with about kicad-snap
<cmars> that new snapd 2.13 release.. does that enable snaps to be installed in a lxd container?
<kyrofa> eldarkg, so I dug into this issue a bit, but not quite as much as I would have liked. It does actually seem to find your lib, but when it comes time to link it can't find the lib. I suspect the Findngspice.cmake is looking in an odd place
<kyrofa> Rather, it seems to find the includes, but not the lib
<kyrofa> eldarkg, but my lack of familiarity with the project started to get in the way at that point
<eldarkg> kyrofa: mmm
<la_juyis`> hi, question. i have an app installed as a deb in my system. I built a snap, installed it, but when I call the app by the name it still calls the deb in /usr/bin - in this case to try if the snap runs ok I should call it by the /snap/ bin, right?
<eldarkg> kyrofa: Is it bug of Findngspice.cmake script?
<kyrofa> eldarkg, maybe, but I'm not sure. It requires some digging into it, the time for which I'm afraid I don't have right now. I'd definitely start there with further investigation, though
<kyrofa> la_juyis`, yeah, /snap/bin comes later in the path
<la_juyis`> kyrofa roger, thanks!
<eldarkg> kyrofa: ok. how I can to simulate LP building on my PC?
<kyrofa> eldarkg, I'd fire up a clean container for it (I use lxc)
<eldarkg> kyrofa: thank you. I'll try digging
<mup> PR snapd#1778 opened: daemon: make socket split backward-compatible <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1778>
<stub> Where does my daemon send its logs? Or do I need to log to $SNAP_COMMON or similar and handle log rotation myself?
<eldarkg> stub: check cat /var/log/syslog
<eldarkg> stub: good tail -f /var/log/syslog
<stub> eldarkg: I mean where should it send its logs. I guess I could dump them all to syslog and let the operator work it out from there.
<eldarkg> stub: sorry I'm new
<stub> I'm at the point I'm dealing with the rough edges. Currently also trying to figure out locale handling. I only seem to have the C locale available.
<eldarkg> stub: Look at my try to work with i18n https://github.com/eldarkg/kicad-snap/blob/master/kicad.wrapper#L10
<stub> eldarkg: I see. So you are generating the locales yourself, rather than relying on locales-all or something to have then embedded in the snap.
<eldarkg> stub: I found only this solve maybe exist the right one
<eldarkg> stub: ping me if you find the right way
<derjasper> What is the state of Ubuntu Snappi on the Raspberry Pi 3 ? Is there a development or inofficial build available?
<mup> PR snapd#1669 closed: interface: add usb device support to serial-port <Blocked> <Critical> <Created by jocave> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1669>
<ogra_> derjasper, http://people.canonical.com/~ogra/snappy/all-snaps/
<ogra_> arges, do you plan to do raspi2 and dragonboard kernel SRUs too today ?
<ogra_> (just asking because i need to make the snap packages pick that up then)
<elopio> nessita: I've just requested a reserved name, cf. Can you please approve it?
<derjasper> Thanks! Is this already 64 bit? And does it receive updates?
<mup> PR snapd#1696 closed: interfaces: add hidraw-device interface <Blocked> <Critical> <Created by jocave> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1696>
<ogra_> derjasper, no, not 64bit (and i'm not sure we'll do 64bit before the pi foundation doesnt announce all firmware blobs are ready for that)
<ogra_> but it receives updates indeed
<derjasper> thanks!
<ogra_> (nopte also that binaries for 64bit eat about 2/3 extra ram, they are a lot bigger)
<stub> eldarkg: It seems to be working if I have locales-all in my stage-packages, and set the LOCPATH environment variable to $SNAP/usr/lib/locale
<stub> eldarkg: I need all locales available (the user can choose at runtime), so this might not be appropriate for your use case
<eldarkg> stub: thank you
<ogra_> ubuntu@pi3:~$ ps ax -o rss,cmd |grep snapd
<ogra_> 12864 /usr/lib/snapd/snapd
<ogra_> ubuntu@dragonboard:~$ ps ax -o rss,cmd |grep snapd
<ogra_> 27248 /usr/lib/snapd/snapd
<ogra_> derjasper, ^^^
<ogra_> same binary from the same source ...
<ogra_> (teh pi3 is armhf ... the dragonboard is arm64)
<alextn> Hello all. I've been working with Snappy Core on the Samsung ARTIK 10 and I was wondering if the "gadget snap" or anything that I might use to produce a custom image is available.
<ogra_> the only real advantage you get with arm64 is on systems with a lot of ram
<ogra_> which the pi3 really isnt
<derjasper> okay, didn't thought about that ^^
<ogra_> :)
<tbr> as if ARMv7 couldn't do LPAE...
<mup> PR snapcraft#757 closed: Export important project variables <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/757>
<ogra_> tbr, does LPAE help gimp to use a 64bit address space ? :)
<tbr> sure, if you want to run Chrome or Firefox with more than two tabs or anything else, you'll need 64bit address space :)
<ogra_> heh, well ...
<alextn> What if you want to virtualize something... ARMv8.x is better for virtualization..
<ogra_> what i meant is that the larger 64bit binaries can actually have a benefit ... but that will only make sense if their functions can actually also address 64bit blocks and have enough ram for that
<arges> ogra_: re: rpi/snapdragon kernels that's something ppisati handles
<ogra_> but yeah, in general armhf is the better choice and LPAE will allow you to use more than 3GB
<ogra_> arges, i have no idea, i only noticed you spammed my changes mailboxes everywhere with these other kernels (new pc-kernel snap with your SRU is already in the store btw) :)
<arges> ogra_: yup its kernel release day today
<ogra_> and i try to be fast with the snaps when an ABI bump happens
<ogra_> (i'll soon automate that so a script can notice a new meta in -updates/-security and it re-builds teh snap automatically)
<ogra_> (maintenance free = win :) )
<jdstrand> roadmr: hey, can you pull r726?
<nessita> elopio, hi! so transfering a snap name is not trivial, and will not be for some time until that is scheduled and added to our roadmap. We usually recommend to not take the upstream names and use suffixes like cf-elopio. Have you consider that?
<elopio> nessita: yes, but then less people will install it and it will get worse stats. My hope is that by the time upstream is ready to take ownership, all the issues in the transfer would be solved.
<elopio> 3 months from now maybe?
<nessita> elopio, ok, I will try to have it approved by EOD today (need to confirm a few things first). Is that ok?
<elopio> nessita: yes it is. Thank you :)
<jdstrand> ogra_: hey, I see a bunch of kernels in the store. do you have an updated list of kernel and gadget snaps that should not be blocked?
<ogra_> jdstrand, heh, nothing changed, no ... all kernels we use auto-land fine
<jdstrand> maybe these are old names
<jdstrand> one has canonical-* at the beginning
<ogra_> they likely are ... i wish i could delete packages
<ogra_> yeah, thats alll dead beef
<ogra_> only pc-kernel, pi2-kernel and dragonboard-kernel are relevant ...
<ogra_> the rest is old cruft
<ogra_> (and these three are fine)
<jdstrand> ok, those are the ones I have
<jdstrand> ogra_: is there a list of gadget snaps?
<ogra_> pc, pi2, pi3 and dragonboard
<ogra_> but we are updating them rarely enough that manual approval is fine
<ogra_> especially since it is always a manual process ... we dont have any snapcraft integration for our gadgets yet
<jdstrand> ogra_: ok, thank you
<jdstrand> roadmr: if you are so inclined, r728 instead (whitelists a few gadget snaps). if you already pulled r726, it can wait
<roadmr> jdstrand: will do. I'd just pulled r721 :)
<wililupy> is there an example of how to use the dump plugin? Not urgent since copy is still working, but would like to learn it. ;)
<roadmr> jdstrand: (but not deployed yet, so it's a good time)
<jdstrand> great, thanks!
<mup> PR snapcraft#765 opened: Use a recursive iglob for filesets <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/765>
<mup> PR snapcraft#754 closed: Use in plugin code to remove unwanted files <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/754>
<dobey> how does one start the snapd service inside an lxc container?
<dobey> error: daemon does not handle 0 listeners right now, just one
<dobey> ^^ i get this if i try to just run "sudo /usr/lib/snapd/snapd"
<dobey> and i can't seem to use systemctl
<sergiusens> dobey it doesn't work in a container; there are bugs that I don't have handy related to the kernel/apparmor that the security team is working on for this
<sergiusens> I think it was jjohansen
<dobey> sergiusens: oh right. is there no way to run it completely unconfined?
<sergiusens> dobey the container itself? Maybe with profiles and such, but that is outside my area of expertise
<dobey> sergiusens: snapd
<dobey> hrmm, maybe i can just bind mount /run/snapd.socket instead
<dobey> err, i guess not because /run is tmpfs
<jjohansen> sergiusens: can you try the xenial proposed kernel? Ubuntu-4.4.0-37.56 has more than a dozen apparmor fixes in it
<sergiusens> jjohansen that would be for dobey ^
<dobey> installed in host or container?
<kyrofa> dobey, container uses host, no?
<dobey> kyrofa: well, the running kernel is on the host of course, but the container doesn't necessarily use other files from the host
<dobey> if i could just bind mount the socket though, that'd be best
<jjohansen> dobey: host
<kgunn> stgraber: hey there, i discovered this means "image not found" ...but shouldn;t there be an arm64 xenial image?
<kgunn> kg@kg-MacBookPro:~$ sudo lxc launch images:ubuntu/xenial/aarch64 xen-arm64
<kgunn> error: not found (not a fingerprint, partial fingerprint (first 12 chars) or valid alias)
<kgunn> or am i doing it wrong?
<ogra_> kgunn, as a fallback (if you cant get lxc to work) https://github.com/snapcore/classic-snap ...
<kgunn> ogra_:  :-P
<ogra_> :)
<kgunn> how do you know i want to cross compile ?
<ogra_> mindwaves ;)
<kgunn> lol
<stgraber> kgunn: lxc launch images:ubuntu/xenial/arm64
<stgraber> kgunn: though based on your hostname, that's not going to work as it will only run on an arm64 system
<dobey> why can't i bind mount anything in tmp/ or run/ in an lxc any more? :(
<mup> PR snapd#1779 opened: miscellaneous policy updates:  <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1779>
<tvoss> jdstrand: o/
<jdstrand> hey tvoss :)
<mup> PR snapd#1778 closed: daemon: make socket split backward-compatible <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1778>
<tvoss> jdstrand: would you find a few to review the very recent locationd upload?
<jdstrand> tvoss: sure-- though I did approve a bunch earlier today
<jdstrand> I see you uploaded a few more
<tvoss> jdstrand: yup, thanks for that -- I had to correct a minor issue for two of the commands
<jdstrand> tvoss: ok done
<tvoss> jdstrand: ack and thx
<mup> PR snapcraft#766 opened: Better file conflict message <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/766>
<jcastro> What would cause this error: error: cannot communicate with server: Post http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
<tvoss> jcastro: running in container or chroot?
<jcastro> no, normal xenial desktop
<jcastro> I did a refresh to ubuntu-core --edge earlier today, but that wouldn't be related I think?
<tvoss> wouldn't think so, I usually ran into the issue in a chroot or container
<tvoss> nessita: o/ I'm running into a publishing problem with locationd. packages are auto-uploaded from launchpad, and even after review, there does not seem to be a way to publish the new packages except for unpublishing/publishing. Wondering if I'm missing something
<jdstrand> jcastro: sabdfl mentioned a bug in edge's core snap
<jdstrand> jcastro: I think SNAP_REEXEC=0 in /etc/environment was the workaround
<jdstrand> yes
<jdstrand> https://lists.ubuntu.com/archives/snapcraft/2016-August/000862.html
<jdstrand> jcastro: ^
<kyrofa> jdstrand, jcastro should be fixed with today's daily build, whenever that happens
<jcastro> ah thanks for that guys, missed that post
<nessita> elopio, cf name approved!
<nessita> tvoss, checking
<elopio> nessita: :) thanks!
<nessita> tvoss, if you go to a revision page, like https://myapps.developer.ubuntu.com/dev/click-apps/5666/rev/11/, scroll down to the bottom
<nessita> tvoss, there is a "Publish" button which is per revision
<nessita> tvoss, the one at the top is "package wide", the one at the bottom is "per revision" (yes, we have a bug to improve the UX there_
<nessita> )
<tvoss> nessita: ack, let me see
<mup> Bug #1618239 opened: console-conf uses 20+MB memory at rest on embedded systems <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1618239>
<ahoneybun> popey: it built now!
<ahoneybun> \o/
<popey> ahoneybun: yay
<ahoneybun> thanks to you lol
<popey> np
<popey> glad i could help
<popey> it's way more fun when stuff works :)
<ahoneybun> it is lol
<ahoneybun> can LP builds run like Travis CI?
<ahoneybun> auto refreshing the page
<popey> lp can build snaps
<popey> and autobuild too
<ahoneybun> no
<ahoneybun> the way Travis auto loads the new state of the build
<ahoneybun> showing the progress without a refresh of the page like LP does
<ahoneybun> or needs
<mup> PR snapcraft#764 closed: Implementing 'grade' support in snapcraft.yaml <Created by caio1982> <Closed by caio1982> <https://github.com/snapcore/snapcraft/pull/764>
#snappy 2016-08-30
<mup> PR snapcraft#764 opened: Implementing 'grade' support in snapcraft.yaml <Created by caio1982> <https://github.com/snapcore/snapcraft/pull/764>
<mup> PR snapcraft#767 opened: Make a copy of the snapcraft files common list before using it <Created by elopio> <https://github.com/snapcore/snapcraft/pull/767>
<mup> PR snapcraft#741 closed: Make it easy to setup a pre-commit hook <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/741>
<mup> PR snapcraft#767 closed: Make a copy of the snapcraft files common list before using it <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/767>
<dholbach> hey hey
<tvoss> o/
<mup> PR snapd#1780 opened: Mention Launchpad bugs list in README <Created by nottrobin> <https://github.com/snapcore/snapd/pull/1780>
<nottrobin> We got an issue with Snapd filed to the snapcraft.io site. I realise your github README doesn't mention where to file bugs. I've created a PR to fix that. ^
<zyga> good morning
<zyga> mwhudson: hey
<zyga> mwhudson: would you mind adding me as a co-maintainer to snap-confine and snapd?
<mup> PR snapd#1781 opened: README: cover the new /run/snapd-snap.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/1781>
<mup> PR snapd#1781 closed: README: cover the new /run/snapd-snap.socket <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1781>
<mup> PR snapd#1780 closed: Mention Launchpad bugs list in README <Created by nottrobin> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1780>
<mup> PR snapd#1782 opened: docs/interfaces: Add empty line after lxd-support title <Created by caldav> <https://github.com/snapcore/snapd/pull/1782>
<mup> PR snapd#1782 closed: docs/interfaces: Add empty line after lxd-support title <Created by caldav> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1782>
<mup> Bug #1600713 changed: snapd.boot-ok.service always failed after booting <Snappy:Invalid> <https://launchpad.net/bugs/1600713>
<mup> PR snapd#1783 opened: snap-exec: add support for commands with internal args in snap-exec <Created by mvo5> <https://github.com/snapcore/snapd/pull/1783>
<mvo> pitti: re bug #1618207 - whats the best bet to figure out if the system is on a high-quality link? talking to NM?
<mup> Bug #1618207: snapd.refresh.service runs when being offline or on expensive/slow internet <amd64> <apport-bug> <yakkety> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1618207>
<pitti> mvo: NM might not be installed (but if it isn't, then I think we can assume to not have 3G or other "expensive" links)
<pitti> mvo: not sure what touch does for updates, maybe that does something clever
<mvo> pitti: iirc its using the download-manager which tries to be very smart
<mvo> pitti: I wish nm-online had an option --is-expensive
<ogra_> hmm
<mvo> pitti: then it would be super simple
<ogra_> my dragonboard and rpi3 installs used to greet me every day with a refreshed core snap for the past two weeks ... seems that has stopped very recently
<ogra_> i need to run snap refresh now to actually get the update
<ogra_> snapd.refresh.timer says "loaded active waiting" ...
<pitti> mvo: "ip route show to 0/0" shows the device of the default route, and nmcli d show $(device) the device type; but that's non-trivial indeed
<pitti> mvo: not the most important thing in the world too, but I noticed the failed service so I thought I'd at least record a bug
<mvo> pitti: yeah, it makes sense
<mvo> ogra_: uh, strange
<mvo> ogra_: no reason why its waiting?
<ogra_> how do i find out ?
<pitti> well, why would a timer not be waiting?
<pitti> (that's the normal state)
<pitti> ogra_: maybe snapd.refresh.service failed for you? check systemctl status?
<ogra_> http://paste.ubuntu.com/23110890/
<pitti> it does fail for me on my normal laptop
<pitti> Aug 30 06:24:30 donald snap[1084]: error: cannot refresh []: Post https://search.apps.ubuntu.com/api/v1/snaps/metadata: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
<pitti> which is different than the two bugs I filed
<ogra_> Aug 30 08:36:55 dragonboard /usr/lib/snapd/snapd[2597]: snapstate.go:379: cannot refresh snap "ubuntu-core": snap "ubuntu-core" has changes in progress
<ogra_> Aug 30 08:36:55 dragonboard snapd[2597]: 2016/08/30 08:36:55.414746 snapstate.go:379: cannot refresh snap "ubuntu-core": snap "ubuntu-core" has changes in progress
<ogra_> aha
<ogra_> ah, wait, thats my manual run
<pitti> FWIW, if I open https://search.apps.ubuntu.com/api/v1/snaps/metadata in a browser I get a 403
<ogra_> i dont see any changes in progress
<ogra_> thats weird
<ogra_> seems when i manually refresh it tries to spawn the timer refresh too at the same time
<ogra_> ubuntu@pi3:~$  grep refresh /var/log/syslog
<ogra_> Aug 30 08:37:40 pi3 systemd[1]: Starting Automatically refresh installed snaps...
<ogra_> Aug 30 08:37:40 pi3 /usr/lib/snapd/snapd[2663]: snapstate.go:379: cannot refresh snap "ubuntu-core": snap "ubuntu-core" has changes in progress
<ogra_> Aug 30 08:37:40 pi3 snapd[2663]: 2016/08/30 08:37:40.631024 snapstate.go:379: cannot refresh snap "ubuntu-core": snap "ubuntu-core" has changes in progress
<ogra_> Aug 30 08:37:48 pi3 systemd[1]: Started Automatically refresh installed snaps.
<ogra_> Aug 30 08:37:48 pi3 systemd[1]: snapd.refresh.timer: Adding 1h 15min 34.967902s random time.
<ogra_> Aug 30 08:37:48 pi3 systemd[1]: snapd.refresh.timer: Adding 4h 22min 20.282576s random time.
<ogra_> this was definitely triggered by a manual "snap refresh"
<ogra_> i guess the timer and the manual refresh somehow wrangle over it
<mvo> pitti: I got a timeout as well in one of my tests currently
 * ogra_ got a properly updated ubuntu-core ... no timeouts here 
<ogra_> do you have the VPN active ?
<ogra_> i noticed that sometimes after DSL reconnect i get DNS issues with it ... reconnecting the VPN then helps
<ogra_> (DNS issues with all canonical machines)
<mup> PR snapd#1770 closed: overlord/assertstate,asserts/snapasserts: give snap assertions helpers a package, introduce ReconstructSideInfo <Critical> <Reviewed> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1770>
<ahoneybun> dholbach: I'm looking for a project in snappy-playpen that uses those white_check_marks and red_circles for examples
<dholbach> ahoneybun, just take a look at the top-level README.md
<dholbach> (the file itself)
<ahoneybun> none of the projects use that
<ahoneybun> the check mark things
<ahoneybun> mm :Cannot find definition for part 'desktop-qt5
<ahoneybun> oh got it
<mup> PR snapd#1784 opened: Add an interface to access the usb drives <Created by axelebas> <https://github.com/snapcore/snapd/pull/1784>
<ahoneybun> that's a real useful line right there: http://start.ubuntu.com/connectivity-check.html
<ahoneybun> yea this thing called lxd is kinda useless with the errors
<mwhudson> zyga: sure, you@ubuntu.com?
<mwhudson> i'm not even sure i'm a maintainer for snapd yet
<Son_Goku> I can't believe I'm saying this, but morning all
 * Son_Goku doesn't understand how he's awake this early in the morning...
<ahoneybun> same
<ahoneybun> it's 5:30am here
<Son_Goku> yep
<Son_Goku> same here
<ahoneybun> niice
<Son_Goku> I'm going to be in for a world of hurt today, since I have meetings ALL afternoon
<Son_Goku> this is going to suck hard
<mwhudson> zyga: eh given that https://qa.debian.org/developer.php?login=zygmunt.krynicki@canonical.com has things and ubuntu.com does not...
<Son_Goku> what port does snapd use to talk to the Canonical store?
<zyga> Son_Goku: part?
<Son_Goku> what TCP port?
<zyga> mwhudson: me@zygoon.pl
<Son_Goku> I'm attempting to write a simple SELinux policy for snapd
<zyga> mwhudson: I'll transition my packages over there
<zyga> Son_Goku: woot! thank you!
<mwhudson> zyga: done
<Son_Goku> zyga, making no promises here, as I have almost no idea what I'm doing :P
<zyga> Son_Goku: I cracked the snap-confine feature I was trying to implement; I will try to land it and release 1.0.41 today/tomorrow
<Son_Goku> awesome
 * zyga hugs Son_Goku 
<zyga> Son_Goku: mount namespaces are *complex* and underdocumented
<Son_Goku> ugh
<zyga> I'd like to fix the namespace(7) man page, it's just lacking essential facts
<Son_Goku> I feel like stabbing someone after hearing that
<zyga> mwhudson: thank you :-)
<ogra_> Son_Goku, isnt "i dont know what i'm doing" a prerequisite for using selinux ?
<Son_Goku> no
<ogra_> :)
<zyga> mwhudson: I'll try to prepare 1.0.41 in alioth and ask you for review (not today, no worries :)
<Son_Goku> I do actually know what I'm doing with SELinux
<mwhudson> zyga: did you get your DM?
<zyga> mwhudson: given our timezone coverage it should be good to work on the overalap for a few moments
<Son_Goku> I have no idea what the totality of snapd's scope is
<zyga> mwhudson: yes
<mwhudson> zyga: congrats!
<mwhudson> zyga: and collab-maint?
<ogra_> Son_Goku, totality of snapd scope -> make the world a better place... and free beer for zyga ...
<zyga> mwhudson: not sure, I think that is separate, no?
<ogra_> (what else :) )
<mwhudson> zyga: yeah it is
<mwhudson> zyga: https://lists.debian.org/debian-devel-announce/2012/01/msg00006.html i think
<zyga> aleba: o/
<mwhudson> zyga: took a couple of days for me, but might have been over a weekend or something, don't remember
<Son_Goku> more procedure?
<zyga> mwhudson: ah, I see
<zyga> mwhudson: just signed email
<Son_Goku> ogra_ , I don't know what TCP/UDP ports snapd uses to talk to the store API
<zyga> Son_Goku: yeah, I would really like to see more of fedora's web tools in debian
<zyga> Son_Goku: ahhh, just http/https I bet
<ogra_> Son_Goku, 80/443 i think
<ogra_> err
<zyga> Son_Goku: there's no UDP involved
<zyga> Son_Goku: everything is http-based
<ogra_> yeah,
<zyga> Son_Goku: there's the trivial store implementation somewhere AFAIR
<Son_Goku> zyga, insofar as seeing more of fedora's awesome tools in debian, they gotta at least implement fedmsg fully
<Son_Goku> https://wiki.debian.org/FedMsg
<zyga> Son_Goku: and badges!!!
<zyga> Son_Goku: but badges should be cross-distro
<Son_Goku> the badges are powered by fedmsg :)
<zyga> Son_Goku: one person, all the badges from all the distros toether
<zyga> Son_Goku: I know, I looked at it
<zyga> Son_Goku: badges are awesome :)
<Son_Goku> the fedora people would definitely be interested in spreading the software everywhere :)
<Son_Goku> there's even people interested in making Koji build proper debian packages, too :P
<Son_Goku> the fedora infrastructure is awesome
<Son_Goku> the upcoming fedora hubs will be even more amazing
<zyga> hubs?
<Son_Goku> https://fedoraproject.org/wiki/Fedora_Hubs
<zyga> Fedorabook ;)
<Son_Goku> yep
<zyga> interesting, I'm going to look at how that evolves
<Son_Goku> it's supposed to be deployed shortly after the third generation Fedora Account System goes live
<Son_Goku> we're on FAS2 now
<Son_Goku> which I think we've been using for about six years
<zyga> Son_Goku: heads up, snappy now uses two sockets, the new one is /run/snapd-snap.socket
<zyga> Son_Goku: 2.14 in COPR has an updated patch to cover this
<zyga> Son_Goku: the 2nd socket is designed to allow all the snaps to talk to snapd about their stuff
<zyga> Son_Goku: (it is not a priviledged socket)
<Son_Goku> ugh
<zyga> Son_Goku: I guess I have to update the request for the socket presets
<Son_Goku> it's a systemd socket?
<zyga> yes
<Son_Goku> err systemd unit
<zyga> Son_Goku: actually
<zyga> Son_Goku: it's one .socket
<zyga> Son_Goku: the same one we had
<Son_Goku> so you're fine
<zyga> Son_Goku: it just has two listen streams
<zyga> Son_Goku: ahhh right :-)
<zyga> that's a relief :)
<zyga> Son_Goku: I'll finish my coffee and .41 patch and do a quick test to see how snapd works without top-level /snap
<Son_Goku> does snapd have any log files?
<zyga> Son_Goku: no
<zyga> Son_Goku: just systemd stuff
<ogra_> it logs to syslog
<Son_Goku> okay
<ogra_> (or journald )
<zyga> Son_Goku: I was wondering how to transition people on COPR
<zyga> Son_Goku: plan a) do nothing, advertize this and let people transition manually
<zyga> Son_Goku: plan b) do the transition in COPR before the package lands
<zyga> Son_Goku: and keep the transition logic copr-only
<Son_Goku> transition what?
<zyga> Son_Goku: transition away from /snap
<Son_Goku> plan B
<Son_Goku> the transition logic shouldn't exist in the official fedora packaging
<Son_Goku> but being the good person you are, you'll handle the transition properly in copr
<zyga> Son_Goku: yeah, I agree
<Son_Goku> you'd probably use one of the transaction scriptlets to do this
<zyga> Son_Goku: I was thinking that the package could stop all the mount units, this should stop all the services, do the transition in the mount files, and re-start the mount units
<Son_Goku> right
<zyga> Son_Goku: but I don't know, I'd like to try it out in a controlled env before I push any updates
<Son_Goku> sure
<zyga> Son_Goku: (and move the stuff around a little on the FS while this happens)
<Son_Goku> zyga: https://fedoraproject.org/wiki/Packaging:Scriptlets
<mup> PR snapd#1745 closed: overlord/snapstate: respect SnapMountDir in tests <Reviewed> <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1745>
<Son_Goku> zyga, are there any config files that snapd needs rw access?
<jamespage> SamYaple, I appear to be following you around snap bits and pieces related to openstack - I have some prelimary snaps for keystone and nova - https://github.com/search?q=user%3Ajavacruft+snap
<jamespage> might be good to hook up and collab and ensure we're not re-doing each others work to much :-)
<zyga> Son_Goku: /var/lib/snapd/*
<zyga> Son_Goku: nothing in /etc AFAIK
<Son_Goku> okay
<ogra_> oh
<zyga> ogra_: ?
<ogra_> nothing, i just checked the ubuntu-core dl stats :)
<zyga> ogra_: aand? :)
<ogra_> +50% since i last checked (about two weeks ago or so)
<zyga> ogra_: woot :-)
<ogra_> mvo, we will need to talk about GL libs in the kernel and how to handle them ...
<Son_Goku> zyga: https://gitlab.com/Conan_Kudo/snapcore-selinux
<ogra_> (afaik there is nothing today that bind mounts them into the right place etc )
<ogra_> (or that even recognizes them in the kernel snap)
<zyga> Son_Goku: checking
<zyga> Son_Goku: https://gitlab.com/Conan_Kudo/snapcore-selinux/blob/master/snappy.fc#L6
<zyga> Son_Goku: will that catch both snapd.socket and snapd-snap.socket?
<Son_Goku> I think so
<zyga> Son_Goku: what does ? do in that context?
<zyga> Son_Goku: it looks like you wanted *
<zyga> Son_Goku: or better yet, just spell out both sockets
<zyga> Son_Goku: quick question, would you mind moving this to github? we could move it to snapcore/snapcore-selinux
<Son_Goku> create the project and I'll push it there
<zyga> Son_Goku: thanks, I don't mind gitlab but that's just one-more-account for me
<Son_Goku> I personally dislike GitHub a lot
<Son_Goku> but I can't avoid it
<Son_Goku> more and more projects are moving there all the time :(
<mup> PR snapd#1776 closed: image: snap assertions into image <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1776>
<ogra_> cjwatson, did yu see my ping about Bug #1608432 yesterday ?
<mup> Bug #1608432: snaps with type: os should allow publishing of .manifest files <launchpad-buildd:New> <Snapcraft:Incomplete> <https://launchpad.net/bugs/1608432>
<cjwatson> no
<ogra_> i have the manifext in place now ...
<ogra_> *manifest
<cjwatson> right, that path is fine
<ogra_> cjwatson, and another question i asked yesterday, is there any way for me to get the store revision number for a snap from the LP api (i have a script that screen-scrapes the url from the UI currently, but thats indeed no long term solution)
<cjwatson> ogra_: not at present, will probably need thought, file  abug
<ogra_> will do
<Son_Goku> zyga, so I have a super basic SELinux policy module for snapd
<Son_Goku> https://gitlab.com/Conan_Kudo/snapcore-selinux
<Son_Goku> it has a Makefile and install instructions
<zyga> Son_Goku: checking
<mup> PR snapd#1785 opened: many: add vendoring of dependencies by default <Created by mvo5> <https://github.com/snapcore/snapd/pull/1785>
<zyga> tyhicks: hey, I've implemented the mount namespace sharing
<zyga> tyhicks: I'll write a few spread tests for it and I'll ask you for review
<zyga> tyhicks: there's one thing that I didn't anticipate but it's not a major thing
<zyga> tyhicks: (systemd changing a default)
<mup> PR snapd#1786 opened: debian: readd ubuntu-core-snapd-units as a transitional package <Created by mvo5> <https://github.com/snapcore/snapd/pull/1786>
<mvo> tvoss: I pushed a vendoring branch fwiw
<mup> PR snapcraft#768 opened: Update kernel meta to the latest spec <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/768>
<tyhicks> zyga: nice!
<sergiusens> good morning!
<zyga> tyhicks: the only wart that kept me from getting this to work is that the preserving bind mount needs to be targetted to a private tree
<zyga> tyhicks: and systemd makes / shared by default
<mup> PR snapcraft#769 opened: Minor fixes for typos in --help <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/769>
<zyga> tyhicks, jdstrand: can you join a hangout please
<zyga> https://hangouts.google.com/hangouts/_/canonical.com/snappy-devel?authuser=1
<zyga> about the ns sharing thing
<tyhicks> zyga: not quite yet - having another conversation
<zyga> tyhicks: when could you be free?
<zyga> jdstrand: how about you?
<jdstrand> I'm in said conversation
<mup> PR snapcraft#770 opened: HACKING.md: list dependencies to install with pip <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/770>
<zyga> ok, let me find a spot for the four of us then
<zyga> I sent you an invite, please tell me if you are free at this time or if you have other commitments
<mup> PR snapd#1786 closed: debian: re-add ubuntu-core-snapd-units as a transitional package <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1786>
<zyga> jdstrand, tyhicks, niemeyer: I moved the call a few hours into the future, I hope that we can all meet then
<tyhicks> zyga: I can't do the new time
<tyhicks> zyga: I'm off this afternoon
<zyga> can you do it now?
<tyhicks> zyga: in a few more minutes
<zyga> jdstrand, niemeyer: ^^ let's use that time if you are available
<zyga> as the rest of the day looks packed
<zyga> and we are running out of time
<jdstrand> I have a meeting in 1 hour and in 2 hours
<jdstrand> zyga: I think tyhicks and I are almost done. do we need a full our?
<jdstrand> hour?
<zyga> let's hope not :)
<zyga> let's do it now
<zyga> joining the hangout
<zyga> tyhicks, jdstrand, niemeyer: https://hangouts.google.com/hangouts/_/canonical.com/mount-namespace?authuser=1
<mup> PR snapcraft#765 closed: Use a recursive iglob for filesets <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/765>
<mup> PR snapd#1771 closed: store: refresh expired device sessions <Critical> <Created by matiasb> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1771>
<SamYaple> jamespage: sounds good. I have nova and glance put together mostly. lets catch up on what to do next
<jamespage> SamYaple, api services appear to be relatively simple (just network and network-bind required)(
<jamespage> SamYaple, the big tickets on my list atm are openvswitch, libvirt and all of the network management and virt management stuff that happens
<mup> PR snapd#1783 closed: snap-exec: add support for commands with internal args in snap-exec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1783>
<jamespage> SamYaple, have you any thoughts on snap naming?  as this is greenfield, having something that easily identifies the snap as openstack related feels goof to me
<jamespage> so I was going for something like
<jamespage> openstack-identity
<jamespage> openstack-image
<jamespage> openstack-block-storage
<jamespage> so project names, rather than codenames?
<SamYaple> jamespage: well the project names are keystone, glance, cinder
<SamYaple> not naming them that seems like a bad choice
<jamespage> SamYaple, purpose vs name I guess
<SamYaple> but i do have the snap names for the openstack projects registered
<SamYaple> well this affects the binaries too, keep that in mind
<jamespage> SamYaple, I'm easy either way tbh - for our charms we use the keystone, cinder, glance names..
<tvoss> mvo, thx, got link?
<jamespage> SamYaple, so you're thinking simply keystone/glance
<jamespage> no openstack prefix?
<SamYaple> if there is an openstack prefix then we end up with openstack-keystone.manage, and openstack-nova.manage
<SamYaple> its not the end of the world, but im not sure its ideal
<jamespage> SamYaple, I saw the bug related to additional binary naming - agree if feels awkward and would mean lots of *NOTES* in official docs...
<jamespage> I'd rather not write a whole new install guide for this stuff :-)
<mvo> tvoss:  https://github.com/snapcore/snapd/pull/1785
<jamespage> SamYaple, I was pondering a plugin extending py2 or py3 (or either) to wrap the OpenStack snap related bits in
<mup> PR snapd#1785: many: add vendoring of dependencies by default <Created by mvo5> <https://github.com/snapcore/snapd/pull/1785>
<SamYaple> i know what you mean. thats what i was trying to get out of that bug report. however a simple alias would align all the packages
<SamYaple> jamespage: what do you mean?
<SamYaple> jamespage: ive extended the py2 plugin to do mostly everything thats needed. now im refactoring the py2 and py3 plugins to be one plugin
<jamespage> SamYaple, I was thinking about some non py related stuff
<jamespage> SamYaple, having these - https://github.com/javacruft/snap-openstack-compute-controller/blob/master/bin/run.sh
<jamespage> in every snap feel ugly - it should be generated as part of the creation of the snap IMHO
<jamespage> so the yaml would allow a snap author to configure bits of that
<SamYaple> im not sure any script inside the snap is needed
<jamespage> SamYaple, what's been your approach to configuration files then?
<jamespage> that's pretty much all that does - so for example for keystone it sets various state paths to SNAP_COMMON/xxxx
<SamYaple> there is some changes being implemented that would allow /etc/nova from the host to bind into the container. that is my ideal
<SamYaple> i want a replacement to system packages as much as possible
<SamYaple> operators manage it the same way they would a baremetal deploy
<SamYaple> certainly things we can talk about though
<jamespage> I can see how that helps with config files; but for local state, I think that want to be in SNAP_COMMON
<jamespage> that said, I don't think we should consider ourselves bound to /etc/XXXX
<mup> PR snapd#1787 opened: overlord/snapstate, daemon, cmd/snap: more explicit revision support <Created by chipaca> <https://github.com/snapcore/snapd/pull/1787>
<jamespage> keystone and nova control plane service where quite happy to run in a non root location, with config files pulled in from SNAP_COMMON and the snap itself
<SamYaple> well the /etc bind part is done at run time right? so thats a variable location
<SamYaple> but i woud like the ability to set the configs _to_ that location. i dont think this restricts either one of us in what were saying though
<SamYaple> jamespage: you arent the first to express intrest about this. i just threw up a channel at ##openstack-snappy, perhaps we can discuss the openstack bits there rather than clog up this channel with non-snappy things
<jamespage> coreycb, ddellav: ^^ you might wanna join that as well
<coreycb> jamespage, joined
<morphis__> ogra_: I saw that cloud-init isn't generating files in /etc/network/interfaces.d anymore, is that due to the netplan landing?
<ogra_> morphis__, yeah, we're waiting for the final bits in subiquity
<morphis__> ogra_: but any edge channel should have these already?
<ogra_> no
<ogra_> you need to manually create the /e/n/i files atm
<morphis__> but networkd takes over on my current pi3 image
<mup> PR snapcraft#770 closed: HACKING.md: list dependencies to install with pip <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/770>
<ogra_> not here
<morphis__> ogra_: there is a /etc/netplan/00-initial-config.yaml  which enables dhcp for all ethernet devices
<morphis__> and networkctl marks my en* devices as configured
<ogra_> well, i dont have issues on my devices ...
<morphis__> ogra_: I don't have issues too
<ogra_> they both have a wlan0 config though
<morphis__> just trying to understand what the current state is
<jamespage> coreycb, did you?
<ogra_> the current state is that we wait for subiquity
<morphis__> ogra_: and what exactly are you waiting for?
<ogra_> that will then forcefully re-config
<ogra_> missing UI bits fior fixed bugs
<coreycb> jamespage, a double #
<jamespage> coreycb, yah
<jamespage> lolo
<jamespage> cargonza, ditto you ##openstack-snappy
<morphis__> ogra_: what will it re-config? network configuration via netplan?
<ogra_> everything
<morphis__> or via /etc/network/interfaces.d?
<ogra_> default user ... network etc
<ogra_> subiquity will forecefully do a basic config
<ogra_> since that kills your system if it doesnt succeed it has been ripped out til all UI bits for all config pieces are there
<morphis__> ogra_: so who is currently putting /etc/netplan/00-initial-config.yaml in?
<ogra_> i guess netplan
<morphis__> ok, where are the netplan packages we currently pull in?
<ogra_> in the PPA
<mup> PR snapd#1788 opened: snapstate: use umount --lazy when removing the mount units <Created by mvo5> <https://github.com/snapcore/snapd/pull/1788>
<morphis__> ogra_: which ppa?
<ogra_> the ubuntu-core build PPA ... https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<morphis__> ogra_: thanks
<mup> PR snapd#1789 opened: many: when installing snap file derive metadata from assertions unless --force-dangerous <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1789>
<nessita> elopio, hi! who is in charge of snapcraft/snappy docs? I'm following http://snapcraft.io/create/ and it mentions snapcraft 2.11 while in xenial we already have 2.15.1
<mup> PR snapcraft#769 closed: Minor fixes for typos in --help <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/769>
<mup> PR snapd#1790 opened: store: set initial device session <Blocked> <Created by matiasb> <https://github.com/snapcore/snapd/pull/1790>
<davidcalle> nessita: "you'll need to have Snapcraft 2.11 or later installed"
<mup> PR snapcraft#764 closed: Implementing 'grade' support in snapcraft.yaml <Created by caio1982> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/764>
<nessita> davidcalle, users don't read text, we just look at the pretty pictures or bash-clis :-P (thanks)
<ysionneau> hmmm
<ysionneau> "the requried kernel commandline snap_core is not set" after upgrading os.snap
<ysionneau> what is supposed to be in snap_core ?
<sergiusens> davidcalle oh, btw
<sergiusens> davidcalle https://bugs.launchpad.net/snapcraft/+bug/1618126
<mup> Bug #1618126: tour: snapcraft upload does not return a url <Snapcraft:New> <https://launchpad.net/bugs/1618126>
<davidcalle> nessita: the point is valid though, the plan was to update it when we have breaking changes or new major versions.
<morphis__> ogra_: also is that known that with a image generated for the pi3 from edge neither gadget or kernel snaps are listed?
<ogra_> morphis__, nope
<morphis__> it also redownloads the core snap
<ogra_> mvo, ^^^
<sergiusens> davidcalle which makes me want to delete https://github.com/snapcore/snapcraft/blob/master/docs/upload-your-snap.md
<sergiusens> davidcalle and https://github.com/snapcore/snapcraft/blob/master/docs/your-first-snap.md
<davidcalle> sergiusens: oh thanks, when I saw the title, I thought it was an issue on your side. The store API is not returning it at all?
<sergiusens> davidcalle we changed the whole workflow
<ysionneau> any idea what snap_core is supposed to be in the cmdline ?
<davidcalle> sergiusens: I'm about to EOD, can you take some time tomorrow to walk me through the new workflow? I may have some assumptions about it that could use an update.
<ysionneau> hm it seems I reached the end of what I could squeeze out of U-D-F to generate working images
<ysionneau> with new os.snap it does not work anymore
<ysionneau> what's the working replacement for U-D-F then?
<ogra_> ysionneau, u-d-f
<ogra_> from the u-d-f snap package
<ysionneau> ah right a new u-d-f
<ysionneau> snap find udf ?
 * ysionneau does not find udf package
<ogra_> snap install ubuntu-device-flash --edge --devmode
<mup> PR snapd#1791 opened: Support checking account-key-request assertions <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1791>
<ysionneau> yann@imperium:~/dev/snappy_paros/tools/snappy/paros_image$ sudo -E /snap/bin/ubuntu-device-flash --verbose core 16 -o paros.img --channel edge  --gadget ../../../paros_2.0_all.snap --kernel ../../../paros_kernel/paros-kernel_3.10.97_armhf.snap --os ubuntu-core --developer-mode --enable-ssh
<ysionneau> cannot use "../../../paros_2.0_all.snap", must be one of: ["canonical-i386" "canonical-pc" "pc" "canonical-pi2" "pi2" "pi3" "canonical-dragon" "dragonboard" "beagleblack" "plano-amd64"]
<ysionneau> I cannot supply my gadget file?
<ogra_> ysionneau, i think there was an option ot override that check ...
<ogra_> damn .. but i forgot what it was, mvo should be able to help
<ysionneau> I wasn't using extra option before but if there is one I'm interested :)
<ogra_> i think it was an env var ... morphis__ do you remember ?
<ysionneau> please pm it to me if you find something, I've got to do
<ysionneau> to go*
<ysionneau> thanks for the help!
<morphis__> ogra_: I've just changed the kernal snap, for the gadget I can't say :-)
<ogra_> hmm
<mup> PR snapd#1718 closed: daemon,overlord: add subcommand handling to snapctl <Reviewed> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1718>
<ogra_> hrm
<ogra_> ubuntu@pi3:~$ sudo reboot
<ogra_> Failed to start reboot.target: Connection timed out
<ogra_> ...
 * qengho hugs systemd.
<ogra_> well, seems kill doesnt work ...
<ogra_> i cant kill -9 any processes
<ogra_> pitti, ^^^ i have a suspicion that systemd on arm has some issues
 * ogra_ had the kill -9 issue before and thought it was only subiquity ... but seemingly it is deeper in the system since subiquity was unseeded
<mup> PR snapd#1792 opened: asserts: introduce device-session-request <Created by pedronis> <https://github.com/snapcore/snapd/pull/1792>
<pitti> ogra_: do you have a full journal from that system? signal handling is unrelated to pid 1, that sounds kernel-ish
<ogra_> well, i rebooted ...
<mup> PR snapd#1793 opened: asserts: initial support to generate/sign snap-build assertions <Created by caio1982> <https://github.com/snapcore/snapd/pull/1793>
<ogra_> hmm... and there is no logging in journalctl between this morning reboot and the reboot i did just now
<ogra_> well, actually it didnt log anything since the 26th
<ogra_> thats weird
<ogra_> uh
<ogra_> no, actually i see the clock switch backwards during boot in the log
<ogra_> pitti, http://paste.ubuntu.com/23112815/
<ogra_> this is a werid log
<ogra_> (syslog though)
<ogra_> it seems to jump to aug. 26th during boot
<pitti> ogra_: systemctl --failed ?
<ogra_> ubuntu@pi3:~$ sudo systemctl --failed
<ogra_> 0 loaded units listed. Pass --all to see loaded but inactive units, too.
<ogra_> To show all installed unit files use 'systemctl list-unit-files'.
<ogra_> nothing... but as i said, i rebooted by now
<pbek> hello all, since today when I upload my qownnotes snap to the store I get an error message: Launchpad uploaded this snap package to the store, but the store failed to
<pbek> scan it:
<pbek>  'Exec=usr/bin/QOwnNotes' does not use: qownnotes
<pbek> (the same snapcraft.yml worked yesterday)
<pbek> that's the yml: https://git.launchpad.net/~pbek/qownnotes-snap/tree/snapcraft.yaml
<pbek> Does anyone have an idea?
<slangasek> mwhudson, cyphermox: sounds like we should get nplan 0.11 or later into the ppas soonish?
<cyphermox> yes
<cyphermox> is it somewhere right now?
<sergiusens> ogra_ mind adding a manual test case here https://github.com/snapcore/snapcraft/blob/master/manual-tests.md for kernel building?
<kyrofa> pbek, your .desktop file is off
<kyrofa> pbek, try changing the Exec to `Exec=qownnotes`
<kyrofa> pbek, so you use the command you exported
<kyrofa> pbek, the desktop file is not run from within $SNAP-- it's run from outside the snap altogether
<kyrofa> pbek, so usr/bin/QOwnNotes does not exist. You need to run the app like a user would, using the qownnotes in the PATH
<pbek> kyrofa: thanks a lot for mentioning, I will try that!
<kyrofa> pbek, sure thing!
<sergiusens> jdstrand hey there, is this correct? /dev/shm/snap/my-snap/my-mem (my-snap is my snap)
<jdstrand> sergiusens: no. use /dev/shm/snap.my-snap.<anything else including '/'>
<sergiusens> ah, thanks
<nessita> anyone with experience using debian packages as dependency for a snap part? I'm listing a few debian deps as "stage-packages" for a part and getting "Error downloading stage packages for part 'magicicada-client': no such package 'gir1.2-notify'"
<nessita> from the docs " This method can reuse any of the 48000 .deb packages that traditional Ubuntu provides" I understand I can list as many debian package names as needed
<seb128> nessita, there is no such deb in ubuntu, you forgot a -0.7?
<seb128> nessita, https://launchpad.net/ubuntu/+source/libnotify
<seb128> nessita, see the debs names listed
<nessita> seb128, ah, I guess I was confused because sudo apt-cache policy gir1.2-notify returns a result, and apt-get install also works :-)
<nessita> seb128, thank you!
<seb128> nessita, it does?
<nessita> seb128, yeah
<seb128> weird
<nessita> nessita@miro:~/projects/magicicada-client/current$ sudo apt-cache policy gir1.2-notify
<nessita> gir1.2-notify-0.7:
<nessita>   Installed: 0.7.6-2svn1
<nessita>   Candidate: 0.7.6-2svn1
<seb128> ah
<nessita> but as you say the package name is gir1.2-notify-0.7
<seb128> right, it's named -0.7
<ogra_> sergiusens, a manual test case for building a kernel ? what do you want to verify with that ?
<nessita> seb128, yeah, just noticed, thank you!
<seb128> apt seems to do something weird
<seb128> yw!
<sergiusens> ogra_ ask elopio
<sergiusens> ogra_ just to see thst nothing breaks in every release
<mup> PR snapcraft#766 closed: Better file conflict message <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/766>
<mup> PR snapcraft#768 closed: Update kernel meta to the latest spec <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/768>
<mup> PR snapd#1794 opened: devicestate: some cleanups and solving a couple todos <Created by pedronis> <https://github.com/snapcore/snapd/pull/1794>
<kyrofa> jdstrand, can I ask you to take a look at #1586465 for the reviewer tools when you're able?
<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>
<ogra_> sergiusens, elopio, i doubt it makes any sense to build a kernel  without a full image test ... (you need to check bootability etc)
<ogra_> and the store already does a lint check when uploading the auto-built snap so issues will be catched there
<ogra_> sergiusens, elijah all we could perhaps test is to roll an empty kernel snap and check in the snap.yaml that the values didnt return ... but given the whole code was ripped out thats very unlikely anyway ;)
<ogra_> err
<ogra_> s/elijah/elopio/ ... sorry
<elopio> ogra_: I would like to have documented and execute for every release a test of building the kernel and booting it.
<elopio> I know we are not there yet.
<elopio> If you think we are safe making releases with that test, that's ok for me. We can wait until ubuntu-image is ready.
<ogra_> hmm, thats now pretty deeply integrated with LP and nearly fully automated ... you can indeed do it locally but that wont tell you much
<ogra_> i'll think about it
<elopio> ogra_: thanks.
<elopio> s/with that test/without that test. :)
<mup> PR snapd#1795 opened: camera interface improvements <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1795>
<nessita> sergiusens, hi! what's the proper path for getting assistance for a snapcraft error? https://pastebin.canonical.com/164307/
<nessita> trying to follow the same procedures as end users :-)
<josepht> nessita: either ask here, the snappy-playpen channel on gitter, or the mailing list.
<mup> PR snapd#1794 closed: devicestate: some cleanups and solving a couple todos <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1794>
<nessita> josepht, thanks.
<nessita> Help! snapcraft is failing when trying to build a part and the error is unclear on how to get it fixed https://pastebin.canonical.com/164307/
<nessita> hum, I should use a public paste :-/
<sergiusens> nessita we don't have a real solution for that yet, except for telling people about http://stackoverflow.com/questions/14296531/what-does-error-option-single-version-externally-managed-not-recognized-ind
<nessita> sergiusens, perhaps snapcraft can fetch latest setuptools instead of using the system's?
<sergiusens> nessita the setuptools in xenial are fine with this, what needs updating is setup.py
<nessita> sergiusens, is "my" setup.py you mean?
<sergiusens> nessita yes yours... or wait for us to fix
<nessita> sergiusens, is there any doc I can read about what I need to change in my setup.py? or what command I can run to make this error appears and fix it
<mup> PR snapcraft#762 closed: node plugin: run build in pull phase to download dependencies <Created by smoser> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/762>
<smoser> \o/
<mup> PR snapd#1796 opened: interfaces: add screen-inhibit-control interface (LP: #1604880) <Created by jdstrand> <Conflict> <https://github.com/snapcore/snapd/pull/1796>
<sergiusens> nessita not that I know of; I still get confused with setuptools distutils eggs and what not to have it handy
<sergiusens> nessita is your snapcraft.yaml anywhere?
<nessita> sergiusens, let me push it
<sergiusens> smoser thanks for the PR
<nessita> sergiusens, https://code.launchpad.net/~nataliabidart/magicicada-client/snapping/+merge/304417
<nessita> sergiusens, be aware I'm not sure what I'm doing, yet :)
<nessita> sergiusens, I'm following http://snapcraft.io/create/ and making free interpretation of things
<sergiusens> ev do you have something I can test this with? https://github.com/snapcore/snapcraft/pull/752/files
<mup> PR snapcraft#752: Ant properties, build target, and destination directory options <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/752>
<sergiusens> nessita that's fine
 * sergiusens install bzr
<ev> sergiusens: cooking something up
<sergiusens> ev if you have something simple, please add to integration_tests :-)
<ev> sergiusens: confused; I did add an integration_test
<sergiusens> ev err ignore me :-)
<ev> ooh, slight bug: properties and targets in the docstring should be ant-properties and ant-targets
<ev> fixing
<sergiusens> ok, this just means I need to look at this closer
<ev> damn, and I was so close ;)
<mwhudson> slangasek, cyphermox: yes
<mwhudson> slangasek, cyphermox: it's just dch -Dxenial "build for xenial" && dput ...
<sergiusens> nessita it might take me a bit on my 6Mbps
<slangasek> mwhudson: can you do this, for whichever version you would like me to also copy to the snappy-dev ppa? :)
<kyrofa> sergiusens, lucky, you have 6?
<mwhudson> slangasek: sure
<mwhudson> slangasek: aren't we supposed to be talking now? :)
<slangasek> mwhudson: we clearly are talking!
<sergiusens> kyrofa I was told I was going to be upgraded from 3 to 6 but it still feels like 3 according to speedtest
<sergiusens> and over the air ;-)
<mwhudson> slangasek: multi format communication!
<kyrofa> Yeah that's what mine is right now too. It's terrible!
<nessita> sergiusens, thanks!
<mup> PR snapd#1797 opened: interfaces: add upower-observe interface (LP: #1595813) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1797>
<ev> sergiusens: https://gist.github.com/evandandrea/b1ed4ffa0395f994ec31a6a6101d0cb4
<ev> produces the same snap as https://github.com/evandandrea/cassandra-snap/blob/master/parts/plugins/x-cassandra.py did
<mup> PR snapd#1765 closed: many: move network initialization to a separate service <Created by mwhudson> <Closed by mwhudson> <https://github.com/snapcore/snapd/pull/1765>
<lool> would someone know where the code corresponding to the ubuntu-device-flash snap is stored? I can't find the same error strings in lp:goget-ubuntu-touch
<mup> PR snapd#1798 opened: firstboot: change location of netplan config <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1798>
<lool> doesn't seem to be under https://launchpad.net/~snappy-dev/+snaps either
<slangasek> lool: if you find it, please let me know; that would help for ubuntu-image porting work as well...
<lool> slangasek: lp:goget-ubuntu-touch does not seem extremely far off, and there were mentions of a derived branch in recent conversations lp:~mvo/goget-ubuntu-touch/minimal-first-boot
<lool> but I can't confirm it's the same code
<sarnold> does this look familiar? Download snap "ubuntu-core" (352) from channel "stable" (read tcp 192.168.122.102:58452->64.94.115.12:443: read: connection reset by peer)
<sarnold> apt-get purge snapd && apt-get install snapd fixed that.
<lool> jdstrand: thanks for taking the time to do another pass on the docker snap; see card/pull request for what I know about the breakage of this snap
<lool> jdstrand: in fact fwding you the email
<sergiusens> jdstrand hi there, has cprov briefed you on `grade`?
<cprov> sergiusens: I didn't. Any side effect on CRT ?
<sergiusens> cprov it might block uploads :-)
<sergiusens> in any case I affected click-reviewers-tools to the bug
<cprov> If absent it defaults to stable, exactly as confinement
<cprov> And Snacraft init starts with develop
<sergiusens> ev nice! I do have two observations; glue seems temporary which is good; [build-]environment is coming for parts and apps but in your custom plugin you could of done it by overriding the `env` method.
<sergiusens> cprov yes, that is all good :-) Problem is, we might get rejected as the key might be unknown to c-r-t
<sergiusens> unless that works already
<cprov> Yes, should have checked that, sorry
<mup> PR snapd#1799 opened: asserts,cmd/snap: add "name" header to account-key(-request) <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1799>
<sergiusens> cprov no need to be sorry ;-)
#snappy 2016-08-31
<sergiusens> nessita darn, I went into fixing our python3 plugin and was trying with ill results until I noticed this was python2 :-P
<mup> PR snapcraft#771 opened: Python plugin improvements <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/771>
<tasdomas> is there an interface that rants an application permissions to read files in /etc (hosts, resolv.conf)?
<tasdomas> s/rants/grants
<pbek> kyrofa: strange, when I call `qownnotes` directly in the desktop file I get a: `404 Client Error: Not Found`
<pbek> kyrofa: using `desktop-launch $SNAP/usr/bin/QOwnNotes --snap` didn't work neither, but it now seems `qownnotes` worked 3 out of 4 times. I only got the error  `404 Client Error: Not Found` once, so I will stick with that. Thanks a lot!
<mup> PR snapd#1798 closed: firstboot: change location of netplan config <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1798>
<mup> PR snapd#1796 closed: interfaces: add screen-inhibit-control interface (LP: #1604880) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1796>
<mup> PR snapd#1795 closed: camera interface improvements <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1795>
<mup> PR snapd#1792 closed: asserts: introduce device-session-request <Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1792>
<mup> PR snapd#1800 opened: tests: fix firstboot-assertions to actually work on clasic again <Created by mvo5> <https://github.com/snapcore/snapd/pull/1800>
<dholbach> hey hey
<tvoss> o/
<mup> PR snapd#1800 closed: tests: fix firstboot-assertions to actually be runnable on classic again <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1800>
<mup> PR snapd#1801 opened: snap: make snap download also download the assertions for the snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/1801>
<mwhudson> mvo: thanks for merging that
<zyga> o/
<tasdomas> is there a way to let a snappy application access system files (e.g. /etc/hosts)?
<mvo> mwhudson: yw
<mvo> mwhudson: thanks for working on it in the first place :)
<zyga> tsimonq2: yes, using interfaces
<zyga> tsimonq2: that file should be in the default permission set
 * zyga checks
<ysionneau> morning!
<ysionneau> any idea how to tell the new u-d-f to use my own gadget snap?
<mzanetti> hey, anyone has an idea what's wrong if I hit this from ubuntu-device-flash?
<mzanetti> cannot bind mount /dev to /tmp/snap.rootfs_k6mTS3/dev. errmsg: No such file or directory
<zyga> tsimonq2: that file is not allowed currently
<mzanetti> I've the u-d-f version from the snappy store
<zyga> tsimonq2: please open a bug and tag it with 'snapd-interfaces' on launchpad.net/snappy
<zyga> mzanetti: this is a message from snap-confine, does your system have /dev?
<mzanetti> I have no idea
<zyga> ysionneau: no idea, sorry
<zyga> mzanetti: ls -ld /dev ?
<mzanetti> zyga, ah, you mean the folder, yes it does :D
<mzanetti> I thought "dev mode enabled" or something :D
<zyga> mzanetti: how about: ls -ld /snap/ubuntu-core/current/dev
<mzanetti> nope that's missing
<zyga> mzanetti: can you try: export SNAP_CONFINE_DEBUG=1
<zyga> mzanetti: oh? how about snap list
<zyga> mzanetti: snap list
<zyga> mzanetti: tell me if you have the core snap installed (ubuntu-core)
<zyga> mzanetti: and if so, which revision that is
<mzanetti> I do, but it says "broken" in the Notes
<mzanetti> rev 48
<zyga> mzanetti: interesting, any idea how you managed to do that?
<zyga> mvo: ^^
<mzanetti> no
<zyga> mzanetti: (this is why you cannot run snaps)
<mzanetti> right, makes sense
<zyga> mzanetti: if you look in /var/lib/snapd/snap can you see the corresponding .snap file?
<zyga> (for ubuntu core)
<mzanetti> I'm on xenial (+stable-phone-overlay) and I installed the ubuntu-calculator-app via snap some months ago, didn't really touch it since... now it's broken
<mzanetti> yes, the ubuntu-core.snap is there
<zyga> mzanetti: curious, can you report a bug, attach your /var/lib/snapd/state.json file (please make the bug private)
<zyga> mzanetti: which version of snapd are you on now>?
<mzanetti> 2.13
<mwhudson> mzanetti: fwiw i had that happen to me and rebooting fixed it
<mwhudson> i think
<mwhudson> random flailing around, including rebooting, fixed it
<ogra_> mwhudson, will the new console-conf skip network device config if it finds an existing one (did you guys test with a configured wlan device yet) ?
<mwhudson> ogra_: it won't skip, but just pressing ok should work fine
<ogra_> what got me in the loop was the inability to cancel or skip that bit iirc
<ogra_> ok
<mwhudson> ogra_: i haven't tested it myself (not sure where i put my dragonboard!)
<ogra_> a pi3 would even be better ... since it has eth and wlan ;) (and i fear a typical usecase is to not use the eth)
<mwhudson> my linaro days left me with a profound dislike of all developer boards :)
<ogra_> lol
<ogra_> see, that is why i never went there ;)
<mwhudson> probably sane
<ogra_> it leaves its marks to work for a company that sounds like a sanitary pad ;)
<mwhudson> hmm do rpis actually have proper MAC addresses?
<mwhudson> sounds like an improvement over some things...
<ogra_> yep ... on our images they do ;)
<mwhudson> like e.g. the dragonboard iirc
<ogra_> the dragonboard images have fixed MACs as well
<mthaddon> hi folks - I'm trying to snap codetree (lp.net/codetree) and I'm most of the way there, but I'd expect it'll need to be able to use bazaar and git credentials for a user. Are there some docs that would explain how to do that?
<zyga> mthaddon: I don't believe you can do that today, there are existing interfaces that aim to allow a snap to use certain "dot" directories
<zyga> mthaddon: sorry, I meant, bugs and pull requests
<mthaddon> zyga: ack, thx
<zyga> mthaddon: the $HOME directory is not the real home, that's a separate issue
<mthaddon> it's non-hidden home, right?
<zyga> mthaddon: so I'd say that you need to look at solving two separate problems
<zyga> mthaddon: 1) knowing where real home is (e.g. through a new SNAP_REAL_HOME variable)
<zyga> mthaddon: teaching your snap to construct symlinks to $SNAP_REAL_HOME/.ssh .bzr and .git and what not in $HOME
<zyga> mthaddon: and using an interface to gain read/write access there (you can start with devmode)
<zyga> mthaddon: given that $LOGNAME exists you can work around the first problem by just faking it with /home/$LOGNAME
<zyga> mwhudson: give that a try!
<zyga> Son_Goku: hey!
<zyga> Son_Goku: just the person I was looking for
<zyga> Son_Goku: what are the common names for locale packages?
<mthaddon> thx
<zyga> Son_Goku: I was working on an update to golang gettext bindings when I noticed tests don't work anymore, the test code was tweaked to use setlocale(LC_ALL, "") and I suspect I need to add appropriate locale packages to the mock environment as build-deps
<Son_Goku> zyga, dnf repoquery --whatprovides "glibc-langpack" will give you a list of them
<Son_Goku> the C and C.utf-8 locales are provided by glibc-minimal-langpack
<Son_Goku> you probably want glibc-all-langpacks for gettext
<Odd_Bloke> Upstream of what I'm trying to snap up don't provide source, and ship only a zip file.  Scripts in this zip file aren't executable, but they do expect one another to be.  Is there a good way for me to run "chmod +x .../*" as part of my snapcraft build?
<Odd_Bloke> (I'm currently just using the dump plugin.)
<zyga> Son_Goku: thanks!
<zyga> Odd_Bloke: I'm old so I love make, just use make :)
<Son_Goku> zyga, prior to fedora 24, all langpacks were installed by default since they weren't split out in glibc
<Son_Goku> so none of this existing pre-f24
<Son_Goku> all the base locale stuff was installed by default in f23 and older
<Odd_Bloke> zyga: How do I use upstream zip as a source but get my own Makefile integrated in?
<zyga> it might be that or something else, I'm investigating
<zyga> could be that the test fails because of the current working directory
<zyga> Odd_Bloke: just unpack it as a part of the make target
<zyga> Odd_Bloke: keep the makefile in your tree
<Odd_Bloke> zyga: And also fetch it as part of the make target?
<zyga> Odd_Bloke: get the zip using snapcraft
<Odd_Bloke> Oh, just don't tell it it's a zip file?
<zyga> Odd_Bloke: yep, just switch to the make plugin and point to the separate makefile
<stub> how are people handling log rotation inside their snaps?
<zyga> Son_Goku: anything I can pass to fedpkg mockbuild to get an interactive shell at a particular point?
<mup> PR snapd#1802 opened: image,overlord/boot,snap: metadata from asserts for image snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/1802>
<mthaddon> zyga: would I expect to see a PR for allowing access to specific dot directories on https://github.com/snapcore/snapcraft/pulls ? Would like to track the issue if there is one
<mthaddon> also don't see a bug matching "dot" or "hidden" on https://bugs.launchpad.net/snapcraft
<zyga> mthaddon: there's a bug about this, not sure if there's a PR for it too
<zyga> try launchpad.net/snappy
 * zyga would like a snapcore project group
<zyga> and snapd, snapcraft, ... projects insid
<zyga> e
<mthaddon> cool, https://bugs.launchpad.net/snappy/+bug/1607067 - thx
<mup> Bug #1607067: Add a dotfiles / hidden files interface <snapd-interface> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1607067>
<ogra_> zyga, that group is called snappy-dev on LP ;)
<zyga> ogra_: not group, project group
<zyga> ogra_: that's nice to use to search bugs amongs snappy related projects
<zyga> ogra_: coordinate milestones and find the relevant projects in one spot
<ogra_> https://bugs.launchpad.net/~snappy-dev ... we just need tio sunscribe the team to the right packages and branches
<ogra_> *sub
<zyga> ogra_: that doesn't help people when bugs are spread amongs projects and they are not a member of the -dev group to know about it in the first place
<ogra_> (no idea why nobody did that yet ... we definitely use the team for everything else... like automation, branch and PPA ownerships)
<ogra_> huh ? why wouldnt it
<ogra_> everyone can see the buglist
<zyga> ogra_: do you know what a launchpad project group is?
<zyga> ogra_: e.g. https://launchpad.net/checkbox-project
<ogra_> https://bugs.launchpad.net/snappy ?
<zyga> ogra_: that doesn't show bugs in snapcraft or in snap-confine
<zyga> that is exactly my point
<ogra_> so we can add these
<zyga> ogra_: ?
<zyga> ogra_: add them where?
<mup> PR snapd#1803 opened: spread: enable halt-timeout, tweak image selection <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1803>
<ogra_> cant you add additional bug monitoring to the project by subscribing it to other projects ?
<ogra_> iirc  thats possible
<zyga> ogra_: I don't know anything about that, sorry
<ogra_> https://launchpad.net/snappy/+sharing
<ogra_> the snapcraft team would have to share them with usa
<ogra_> *us+
<ogra_> bah
<ogra_> then they will show up in the snappy buglist
<zyga> ogra_: in the end, will I see all the bugs in bugs.launchpad.net/snappy?
<ogra_> right
<ogra_> lets talk about it in the meeting
<zyga> ogra_: interesting, I wonder what's the desire with the project group feature overlap
<zyga> ogra_: I think the issue is social, people recall snapcraft as the "brand" because that is what the mailing lists and the website is called
<ogra_> right
<zyga> ogra_: we talked about setting up a project group a while ago but it never materialized
<zyga> Pharaoh_Atem: hey, I have a question, is it ok to commit non-working packaging to master
<zyga> Pharaoh_Atem: I'd like to have a second pair of eyes on the problem I was facing
<morphis> ogra_: 9 M snap size and 0.9% memory usage on my pi3, does that sound better for you for the network-manager snap? :-)
<ogra_> morphis, definitely an improvement, but indeed still more then 0MB :)
<ogra_> *than
<ogra_> i think NM preseeded is absolutely fine on PC class installs like the dell gateways, but i still think we shouldnt pre-seed it on embedded (rpi, dragonboard) and use the existing alternative there
<Son_Goku> why?
<Son_Goku> latest NM is quite small and lightweight
<Son_Goku> and it's super easy to configure
<ogra_> Son_Goku, because it is still bigger than zero ;)
<ogra_> it just doesnt make sense ot have something like NM on the embedded board of your lawnmower
<Son_Goku> it really doesn't make sense for your lawn mower to be internet connected
<ogra_> where you most likely have pretty hard requirements regarding disk and ram size
<ogra_> huh ?
<Son_Goku> I'd say in that case it should have nothing
<ogra_> how else would i install additional autopilot snaps ;)
<Son_Goku> not even the legacy networking
<ogra_> or steer it via that mobile app
<Son_Goku> ....
<Son_Goku> you have problems
<ogra_> well, snappy was initially designed for IoT ... and we'll go there again after that little detour to make it a generic package format
<morphis> ogra_: yeah I agree
<morphis> by default we give netplan/ifupdown which is enough and then someone can pick
<ogra_> well, we should have a default image with NM as well ... just not for the low level devices
<morphis> sure, but that is then for the implementor to pick
<morphis> as long as the snap is in the store, tested and ready to use you can put it in images, install on demand, whatever you want
<ogra_> yeah
 * ogra_ trickles launchpad 
<ogra_> come on publisher ... you knwo you can do it
<morphis> btw. I lied, amd64 is 7.9 M and armhf is 5.9 now
<ogra_> how about arm64 ?
<ogra_> i suspect thats the biggest
<morphis> need to check
<Son_Goku> morphis, why not use networkd
<ogra_> we do
<ogra_> when NM isnt installed
<Son_Goku> good
<morphis> Son_Goku: networkd does give you some advance features in certain situation
<Son_Goku> it's quite nice
<Son_Goku> and it isn't ifupdown :)
<Son_Goku> which means no sysv scripts
 * ogra_ doesnt get all the hate for ifupdown ... 
<morphis> ogra_: https://launchpad.net/~morphis/+snap/network-manager-reduced-footprint
<Son_Goku> my server stalls for more than 5 minutes at work while trying to bring up networking
<Son_Goku> swapping that out for NetworkManager completely eliminated the bottleneck
<ogra_> wow, that sounds like a buggy setup then
 * tvoss hugs the poor little publisher
<ogra_> hmm
<ogra_> my current upgrade wants to uninstall unity8-desktop-session
<ogra_> that doesnt sound right
 * ogra_ triggers an ubuntu-core edge build with console-conf included ... lets see how it behaves now 
<mvo> pitti: quick (silly) question, what kind of network restrictions do we have inside adt? I would love to run our spread tests inside adt but need some access, notable github and the snappy store. I guess the later is no problem, what about the former?
<Son_Goku> ogra_ uhh no
<Son_Goku> my setup is damn simple
<Son_Goku> it's just bringing up the interface with dhcp
<Son_Goku> ifupdown is just brittle as hell
<ogra_> well, except that it isnt normal to take 5min :)
<ogra_> not even with ifupdown
 * Son_Goku shrugs
<Son_Goku> moving to networkd or NetworkManager fixes it
 * ogra_ doesnt have such probs with any of his machines ... so i never felt the need to move
<mup> PR snapd#1804 opened: tests: use the spread tests with the adhoc interface inside autopkgtest <Created by mvo5> <https://github.com/snapcore/snapd/pull/1804>
<ogra_> hmm, it would be really nice if the store wouldnt spam me with a 504 error mail for each ubuntu-core snap build
<ogra_> (especially since its a lie)
<pitti> mvo: you can use that, as long as you respect the proxy vars
<pitti> mvo: we routinely run tests which clone stuff from github, works fine
<mvo> pitti: cool, thank you
<mvo> ogra_: hm, we have a "test" user in our image?
<mvo> ogra_: do you know anything about this? uid 1001
<ogra_> mvo, nope
<mup> PR snapd#1803 closed: spread: enable halt-timeout, tweak image selection <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1803>
<ogra_> mvo, which ubuntu-core revision is that ? i just did a test build with console-conf re-added
<mvo> ogra_: this is the one I got I think
<ogra_> then it might come from there
<mvo> pitti: and one more silly question, what is the best way to test if autopkgtest works in the real environment we use? I guess a yakkety upload? or is there some better way?
<mvo> ogra_: so console-conf might add a test user?
<ogra_> i dont know what else would
<ogra_> definitely not livecd-rootfs
<ogra_> and i havent seen any cloud-init changes either
<pitti> mvo: if it works locally with qemu it should mostly likely work on teh infra too
<pitti> mvo: you can try it on canonistack too if you want
<mvo> pitti: ok, that is good enough for me (qemu), I will double check in there then and hope for the best :)
<ogra_> mvo, looking at the subiquity diff i dont see anything that would add a test user
<pitti> mvo: note that github has a great CI functionality too -- we can run the autopkgtests on PRs on xenial and yakkety
<pitti> which is a much better way to do it than waiting for an upload and then trying to find out what broke stuff
<cyphermox> morning
<mvo> pitti: you mean via travis?
<mvo> pitti: this is close to what we are doing, except that we use spread instead of autopkgtest. I'm trying to brige these worlds right now
<pitti> mvo: no, you can configure a web hook to request an autopkgtest on our infra, and ask it to build and test a PR branch
<pitti> we've done this for systemd for a long time now, and didrocks once set it up for ubuntu-make
<pitti> mvo: this just needs an hour of sitting down, exchanging some shared secrets and configuring the snappy gh project
<mvo> pitti: indeed, we had the webhook setup too, we had some trouble with the infrastructure though, federico knows the details and eventually moved to spread
<ogra_> mvo, oh, FYI .. http://people.canonical.com/~ogra/ubuntu-core-builds/ ... ( that is only pparsing the log from the auto-builder though, so manual builds are ignored)
<mup> PR snapd#1788 closed: snapstate: use umount --lazy when removing the mount units <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1788>
<ogra_> (but helpful if you need the mapping between LP and the store revisions)
<mvo> neat
<ogra_> changelogs (manifest diffs) and manifests will show up there too... once we have them
<mup> PR snapd#1805 opened: use beta u-d-f in test by default  <Created by mvo5> <https://github.com/snapcore/snapd/pull/1805>
<sergiusens> pitti mvo if it helps snapcraft runs adt on every PR; but mvo just recall that is what you sort of moved away from (I think)
<pstolowski> jdstrand, hello!
<sergiusens> the canonistack/prodstack side of it
<mvo> sergiusens: yeah, the canonistack was the part we had trouble with hence spread. but I hope I can cross the worlds again
<ppisati> sergiusens: how do i unstuck this?
<ppisati> sergiusens: https://github.com/snapcore/snapcraft/pull/748#issuecomment-241420986
<mup> PR snapcraft#748: kernel plugin: vmlinuz -> kernel.img hard link <Created by piso77> <https://github.com/snapcore/snapcraft/pull/748>
<mup> PR snapd#1806 opened: overlord/devicestate: set device registration URLs <Blocked> <Created by matiasb> <https://github.com/snapcore/snapd/pull/1806>
<sergiusens> ppisati can you address the comment in here https://github.com/snapcore/snapcraft/pull/748/files ?
<mup> PR snapcraft#748: kernel plugin: vmlinuz -> kernel.img hard link <Created by piso77> <https://github.com/snapcore/snapcraft/pull/748>
<sergiusens> ppisati in some sense I am asking to just remove that os.link call and the comment above if they aren't needed anymore
<ppisati> sergiusens: oh ok
<sergiusens> ppisati if we sort that out today I will wait for it for the 2.16 release being tagged today
<ppisati> sergiusens: would a symlink be good for you?
<sergiusens> ppisati os.link is fine, I am just wondering if we need the vmlinuz one
<ppisati> sergiusens: the bootloader should only look for kernel.img
<jdstrand> sergiusens: re 'grade'> no
<ppisati> so we can remopve that vmlinuz completely
<jdstrand> pstolowski: hi
<ppisati> k
<sergiusens> ppisati great, so yeah, `dd` (in vi) on the line `os.link(src, os.path.join(self.installdir, 'vmlinuz'))` and the one above is my specific quetion :-)
<sergiusens> jdstrand I've affected the project on the bug.
<pstolowski> jdstrand, hi! i've hit https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1618737 today, and took the liberty of assigning it to you
<mup> Bug #1618737: firewall-control doesn't grant all the required permissions for ufw to work <snapd (Ubuntu):New for jdstrand> <https://launchpad.net/bugs/1618737>
<ppisati> sergiusens: you forgot the unit tests :)
<jdstrand> pstolowski: that is bug #1583514
<mup> Bug #1583514: firewall-control and ip[6]table_filter module loading <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1583514>
<pstolowski> jdstrand, ah! ok, thanks!
<jdstrand> pstolowski: what is needed is a kernel module backend. that is also needed by docker, ppp and other interfaces
<jdstrand> jamiebennett, lool: can someone get bug #1583514 assigned? ^
<mup> Bug #1583514: firewall-control and ip[6]table_filter module loading <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1583514>
<mup> PR snapd#1807 opened: interfaces/builtin/bluetooth_control.go: Add access to /dev/vhci <Created by cwayne18> <https://github.com/snapcore/snapd/pull/1807>
<jamiebennett> pstolowski is doing some bug triage atm
<jamiebennett> pstolowski: can you take a look to see what is required?
<pstolowski> jamiebennett, sure, will do
<jdstrand> pstolowski: fyi, comment #1 in the bug lays out the high-level idea which was approved by niemeyer and zyga. I can point you at other converstaions for lower level details. give me a minute
<mup> PR snapd#1736 closed: tests: port integration tests to spread <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1736>
<ogra_> cyphermox, hmm, i seeded console-conf again and upgraded ubuntu-core ... i end up with no console-conf UI but also with no serial console now
<cyphermox> hit enter
<ogra_> nothing
<ogra_> oh, now i get some messed up stuff at the top
 * ogra_ seed eth0 unconfigured ... sit0 too and wlan0 with an IP ... 
 * ogra_ hits "done"
<ogra_> hey, this gfot me further than last time
<ogra_> whee !
<sergiusens> ppisati can you also click `Update branch`/merge/rebase the branch?
<sergiusens> ppisati indeed I forgot the units :-)
<ogra_> cyphermox, apart from the visual glitches uit technically seems to work ... i guess just adding a "clear" at the top of your code would greatly improve the UI
<cyphermox> no chance you took a screenshot of what you saw garbled?
<cyphermox> it looks fine to me, and clears as much as one would expect on serial
<ogra_> cyphermox, it someply has all the boot output ... and then starts the U(I in the top left (i dont have the terminal at 80x24 here)
<mup> PR snapd#1808 opened: many: add snap set and snap get commands <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1808>
<ogra_> just clearing the terminal should be enough
<cyphermox> not for that, but that sounds like what I'm seeing here
<ogra_> i guess if my terminal hade been at 80x24 i wouldnt have noticed
<ogra_> *had
<cyphermox> well, mine isn't either
<cyphermox> I have no idea why it picks that, could be some weirdness in urwid
<jdstrand> pstolowski: for docker: https://github.com/snapcore/snapd/pull/1619/#issuecomment-239678941 (not much detail) and https://github.com/snapcore/snapd/pull/1226#discussion_r64953106 for ppp ((3rd bullet). I can't seem to find where the clear explanation is, so I'll give it to you
<mup> PR snapd#1619: interfaces/builtin: add initial docker interface <Blocked> <Created by tianon> <https://github.com/snapcore/snapd/pull/1619>
<mup> PR snapd#1226: Interface for modem manager <Reviewed> <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1226>
<ogra_> cyphermox, http://people.canonical.com/~ogra/serial-shot.png
<ogra_> this is what i see now
<cyphermox> yep, looks good
<ogra_> heh
<cyphermox> well, as good as it can when limited to 80x24 ;)
<jdstrand> pstolowski: snapd grows a new backend, eg, KernelModule. interfaces add what modules to explicitly load via this backend. Eg, firewall-control would tell KernelModule to load iptable_filter and ip6table_filter
<ogra_> i'm sure there is a way to clear the tty before you fire up your UI
<cyphermox> the problem is not the clearing though
<cyphermox> it's the size
<cyphermox> and size can't exactly be guessed from serial
<jdstrand> pstolowski: then this backend creates file(s?) in /etc/modules-load.d to simply list the modules
<ogra_> also there was no note at all that i need to press enter
<ogra_> it just sat there at the end of the boot messages
<cyphermox> ogra_: ok, I'll look into that
 * ogra_ tries the dragonboard
<cyphermox> I think we can keep this in the image now though?
<jdstrand> pstolowski: so, firewall-control lists those two modules, on interface connect of firewall-control, snapd splats out /etc/modules-load.d/snap.modules.conf with each of those, one per line
<mup> PR snapd#1807 closed: interfaces/builtin: allow /dev/vhci on bluetooth-control <Created by cwayne18> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1807>
<ogra_> cyphermox, thats my current screen on the dragonboard before hitting enter http://paste.ubuntu.com/23116099/
<cyphermox> ta
<cyphermox> yep, looks like agetty is still not complying
<jdstrand> pstolowski: there is some question as to whether there should be one big file that is managed or one per interface. that is an implementation detail. I believe zyga said he understood how to do all this, but not sure if there is any code or anything. this functionality is not difficult
<ogra_> cyphermox, now the million dollar question ... on debvices that have tty1 and a serial tty ... could we show the UI on both (and have it stop when on one of the ttys the config was done)
<ppisati> sergiusens: yep
<ppisati> sergiusens: i just built an image for test
<cyphermox> ogra_: what do you mean?
<ppisati> sergiusens: let me finish to flash it and i'll update the branch
<cyphermox> ogra_: you want on boot that tty1 and ttyS* show the UI?
<cyphermox> (rather than wiating for input?)
<ogra_> cyphermox, systemd automatically configures tty1 ... so on systems with console=blahblaS0 ... you end up with both, tty1 and blahblahS0 login prompts
<cyphermox> tty1 will currently show "Hit enter to configure." or something like that
<ogra_> it would make sense to have both show the UI ...
<pstolowski> jdstrand, sorry, i was in the meeting. reading
<cyphermox> there's a wrapper around the binary to deal with your memory issue
<mup> PR snapd#1254 closed: snap: use symlink in /snap/bin instead of wrappers <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1254>
<ogra_> cyphermox, well, i dont care about memory, i care about raspberry pi users that have no serial cable ;)
<cyphermox> ogra_: in fact, not just tty1 but tty1-6 should show that, and wait for a key to start the UI
<cyphermox> that behaves correctly AFAICT
<ogra_> so wheerever the keypress comes from will run the UI ?
<cyphermox> the problem is that you can't use the exact same options in agetty on ttyn than on ttySn, because serial behaves differently than screen
<cyphermox> yup
<cyphermox> wherever the keypress comes it will run the UI
<cyphermox> the intent is to show the message, which works on VTs, but apparently not on serial
<ogra_> ok, i'll try my way through :)
<cyphermox> re-flashing my card so I can start fresh, I'll bring up my pi2 with HDMI attached this time, but I tested it last night before sending you the email
<cyphermox> "last night" for varying definitions of night.
<sergiusens> ppisati ah, you may be a good candidate for adding a test for the kernel plugin here https://github.com/snapcore/snapcraft/blob/master/manual-tests.md
<jacekn> I am trying to build snap using LP. I have 2 branches, each one with slighly different snapcraft.yaml (stable vs edge). One of them build fine and I can publish to the store. But when I try to set up 2nd branch to build snaps I am getting "here is already a snap package owned by Jacek Nykis with this name". How can I work around it?
<ogra_> jacekn, name the branch differently ?
<ogra_> (or the snap rather i guess)
<kyrofa> ogra_, it's perfectly fine to name the snaps differently in LP
<kyrofa> ogra_, sorry, jacekn
<kyrofa> jacekn, as long as the snapcraft.yaml indicates the correct name, the generated snap will have that name
<kyrofa> jacekn, think of the snap name in LP as the LP ID for that snap instead of its actual name
<ppisati> the img that i just created doesn't boot...
<jacekn> kyrofa: ack, thanks I'll try that
<chihchun> Is there a easy way to add new apparmor rules without rebuild snapd? seems edit /var/lib/snapd/apparmor/profiles/*profile* and snap refresh did not do the trick
<kyrofa> jacekn, I have a snap that automatically deploys to different channels on LP. When I merge to develop, I want it published on the beta channel. When I merge to master, I want it published to all channels. I do that by creating two different snaps, "my-snap" and "my-snap-beta" associated with those branches
<ogra_> ppisati, using the latesst u-d-f snap ?
<ppisati> yep
<ppisati> sudo ubuntu-device-flash core 16 --channel edge --kernel pi2 --gadget pi2 --os ubuntu-core
<ogra_> (revision 9 or so)
<ppisati> -o pi2.img
<mup> PR snapd#1809 opened: interfaces/bluetooth_control: needs /dev/vhci to be writable <Created by cwayne18> <https://github.com/snapcore/snapd/pull/1809>
<ogra_> ppisati, --kernel pi2-kernel i hope :)
<ppisati> err no
<ogra_> else you installed a gadget as kernel
<ogra_> ;)
<ppisati> ubuntu-device-flash  3          3    canonical  devmode
<ogra_> interesting that we dont refuse that
<ogra_> oh, better update that
<ogra_> ogra@anubis:~$ snap list ubuntu-device-flash
<ogra_> Name                 Version  Rev  Developer  Notes
<ogra_> ubuntu-device-flash  10       9    canonical  devmode
<cwayne> sorry for the double PR, had been too quick to post before checking if rw was needed!
<pstolowski> jdstrand, ok, so fixing this bug includes: 1) implementation of the new snapd backend which loads kernel modules and 2) make firewall-control interface drop a file there to have the modules loaded, correct?
<jdstrand> chihchun: you can add the rules to /var/lib/snapd/apparmor/profiles/*profile* then do 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/*profile*
<jdstrand> chihchun: a snap refresh will actual remove those changes though (as will an install, remove/install, etc)
<chihchun> jdstrand: and it will overwrite the cache in /var/cache/apparmor, correct?
<ogra_> cyphermox, what happens on disconnected devices regarding the user ?
<cyphermox> ogra_: I need to clarify that. Currently, to configure a device with console-conf you'd need Ubuntu SSO credentials, or you'd have to login with the ubuntu user via SSH and add a user manually
<jdstrand> pstolowski: '2' is not for firewall-control to drop a file, but simply adding those to modules to a list for the backend to add to a file it will drop there
<jdstrand> s/to modules/two modules/
<ogra_> cyphermox, that would have been my next question :) can i drop the ubuntu user creation from livecd-rootfs :)
<ogra_> but seems i cant yet
<jdstrand> pstolowski: ie, the backend does the dropping. the interfaces just tell the backend what to put there
<cyphermox> ogra_: originally we expected that was what would happen once console-conf was in, but looks like we need further policy discussion on that matter
<ogra_> i know sabdfl__ is eager to get rid of being mr. "ubuntu" on the devices ;)
<cyphermox> that transpired during my night too :)
<cyphermox> I won't blame him, it's a big wart on the devices, tbh
<ogra_> it is
<ogra_> well, i'll leave the user in for now til we have clearified that ... let me know once it can go
<cyphermox> one of my top priorities today is to sort out what to do with the users
<ogra_> big step !
<cyphermox> yep
<ogra_> awesome work !!
<cyphermox> thanks. I'll convey your feedback to mwhudson too!
<ogra_> and to slangasek ;)
<cyphermox> yep
<pstolowski> jdstrand, ok, i see. i'm afarid i cannot commit to work on this atm, i'm in the middle of something else
<jdstrand> chihchun: that won't overrite the cache, no, but on reboot the apparmor init will notice the profile is newer and update the cache
<chihchun> jdstrand: thanks for the tips, it works for me. I found an issue on the rules for input method, will file a pull request
<jdstrand> chihchun: cool, thanks
<jdstrand> pstolowski: ack
<jdstrand> pstolowski: for posterity:
<jdstrand> pstolowski: one other thing is that on interface connect, the backend should load the modules (in addition to adding them to /etc/load-modules.d)
<mhall119> zyga: jamiebennett: are you available for the snappy community sync call?
<jamiebennett> mhall119: Sorry, have a snappy team call
<mhall119> well we can just join that :)
<ogra_> mhall119, wasnt that commun8ity sync dead since ages ?
<jdstrand> mvo: hey, ok, now that I have the rights to merge stuff, what is the policy if I propose a PR and someone else +1s it? Should I merge it or wait for someone else?
<jdstrand> mvo: related, how many +1s are needed for me to do the merge for a PR someone else submitted?
<pstolowski> jdstrand, thanks, I added all your explanations to the bug report as this is a good summary
<jdstrand> pstolowski: oh heh, I already did :)
<ppisati> ogra_: http://pastebin.ubuntu.com/23116284/
<ppisati> ogra_: do you have any idea how can i debug this?
<pstolowski> jdstrand, oh lol.. i haven't refreshed for several minutes so didn't see it..
<ppisati> so, starting with a fresh rpi2 image, i can't install a new kernel because
<ppisati> it coudln't connect to the store
<jdstrand> pstolowski: yeah, that happens from time to time too :)
<ppisati> while if i roll a custom image with a fresh kernel built using snapcraft kernel pluging, i get this
<mhall119> ogra_: zyga and I had kept it going
<jdstrand> happens to me*
<sergiusens> ppisati can you click on "Update branch" please?
<ppisati> sergiusens: dpne
<sergiusens> ppisati thanks
<jdstrand> jamiebennett: fyi, https://bugs.launchpad.net/snappy/+bug/1583514/comments/7
<mup> Bug #1583514: firewall-control and ip[6]table_filter module loading <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1583514>
<mup> PR snapd#1810 opened: interfaces/builtin/unity7.go: fix fcitx support <Created by chihchun> <https://github.com/snapcore/snapd/pull/1810>
<zyga> mhall119: perhaps next week, this week is RTM work sprint
<sergiusens> ppisati but does it work? :-)
<ogra_> ppisati, sorry, in a meeeting ... mount the first partition and check if ubuntu-raspi2-kernel_x1.snap/ exists as dir in there ...
<ogra_> (or do fatls from the uboot prompt)
<mhall119> zyga: can you review my blog post today? I'd like to publish it tomorrow
<zyga> mhall119: yes, I'll review it after this batch of meetings, I had a look early in the morning but I didn't read it in detail to say +1/-1 yet
<mhall119> thanks zyga
<ppisati> ogra_: you mean the partition containing the bootloader files?
<ppisati> ogra_: but there's no 'ubuntu-raspi2-kernel_x1.snap' dir there
<ogra_> thats your issue then
<ppisati> sudo ubuntu-device-flash core 16 --channel edge --kernel ../linux/ubuntu-raspi2-kernel_4.8.0_armhf.snap --gadget pi2 --os
<ppisati>  ubuntu-core -o ...
<ppisati> i as trying to roll an image from a fresh kernel built using the snapcraft plugin
<ppisati> usually i used snappy image for the target
<ppisati> and then i installed the new kernel over it
<ppisati> but this time i couldn't install a new kernel (couldn't connect to the store or something)
<ogra_> well, did you update your u-d-f snap to the latest yet ?
<ogra_> ppisati, https://docs.google.com/document/d/1jZqJ92g0ox9xUk8Nge3ess89dQChdMzKXrNwwgloEbc/edit#heading=h.mey6uws9k5sy is the master setup now (kernel.yaml was dropped after it was written)
<sergiusens> ppisati that is why I asked you to update the branch ^
<sergiusens> ogra_ there is no kernel.yaml implementation in snapcraft
<ogra_> sergiusens, yeah, its gone as i said
<ogra_> the only bits that count now are the fs structure inside the snap and "type: kernel" ... and indeed the version string needs to match the name of the modules dir
<morphis> ogra_: btw. why are we not using something like https://github.com/snapcore/snapcraft/blob/master/demos/96boards-kernel/snapcraft.yaml for the pi kernel snaps?
<ogra_> morphis, because our official kernels contain a ton more than just a kernel ... and we need to use the signed kernel binaries from the archive for secureboot
<morphis> ogra_: I see
<ogra_> (there are also postinst script tasks we need from the linux-image-*foo packages
<ogra_> )
<ogra_> s/ our official kernels/ our official kernel snaps/
<ogra_> morphis, http://bazaar.launchpad.net/~snappy-dev/kernel-snap-makefile/trunk/view/head:/Makefile is our actual build script ... referencesd from the different snap builds like http://bazaar.launchpad.net/~snappy-dev/pi2-kernel-snap/trunk/view/head:/snapcraft.yaml
<ogra_> *referenced
<ogra_> (yes, i know it could use some cleanup, the Makefile takes nearly every possible kernel snap variant we ever had into account :) )
<morphis> ogra_: thanks
<om26er> Hi! Is there a way I can add wifi credentials in my RPi running snappy without ethernet or a screen ?
<ppisati> sergiusens: i'm rebuilding with the up to date branch
<ppisati> ogra_: there's no version 9 of u-d-f in xenial, or am i wrong?
<ogra_> ppisati, sudo snap refresh ubuntu-device-flash --edge --devmode
<ogra_> that should get you the very latest
<ppisati> --devmode made a difference
<ogra_> yeah
<ppisati> withoput it, it would say "no updates ..."
<ogra_> right, because it isnt in stable
<ogra_> no options = only look in stable
<ogra_> confinement: devmode = cant release to stable
<ppisati> even if you say --channel=edge?
<ogra_> yes
<ppisati> ...
<pbek> Hi folks, lately when I run my `qownnotes` snap I get the error message `multiple nvidia drivers detected, this is not supported`. Although I can run the QOwnNotes binary directly from the snap directory... Any ideas?
<pbek> that's the yml: https://git.launchpad.net/~pbek/qownnotes-snap/tree/snapcraft.yaml
<pbek> maybe kyrofa can help again?
<mup> PR snapd#1811 opened: interfaces: serial-port: udev slot definition <Created by jocave> <https://github.com/snapcore/snapd/pull/1811>
<ogra_> pbek, Bug 1615248 ... has a workaround too
<mup> Bug #1615248: ubuntu-core-launcher nvidia driver detection is bogus <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1615248>
<pbek> ogra_: I will check that, thanks a lot!
<mup> PR snapd#1812 opened:  image,overlord/boot,snap: metadata from asserts for image snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/1812>
<sergiusens> nessita looked at your problem re-did all of the python plugins last night (still experimenting) but your project does not work with a plain `pip install .` either
<sergiusens> nessita from what I saw it is distutils use instead of setuptools
<sergiusens> given the complexity of your project not sure how easy it is going to be
<nessita> sergiusens, yeah, I blame dobey :-P
<nessita> sergiusens, so first I need to make it work with "pip install ."?
<sergiusens> nessita if it works with pip install it should work
<nessita> sergiusens, I was hoping to avoid that since running it is just "PYTHONPATH=. ./bin/ubuntuone-syncdaemon"
<sergiusens> nessita well a custom plugin could work or just installing the deps and using the dump plugin for everything else
<nessita> sergiusens, that was my next question :-) where can I read on custom plugins?
<sergiusens> nessita http://snapcraft.io/docs/build-snaps/plugins
<nessita> sergiusens, thanks!
<dobey> do what
<dobey> oh crikey you're trying to make a snap of ubuntuone-client?
<dobey> well ubuntuone-client isn't installable with pip install because we never uploaded/registered it there
<niemeyer> morphis: snapd#1674 is ready for some love
<mup> PR snapd#1674: interfaces/builtin: add udisks2 and pluggable-storage interfaces <Blocked> <Critical> <Reviewed> <Created by ssweeny> <https://github.com/snapcore/snapd/pull/1674>
<morphis> niemeyer: thanks
<niemeyer> jdstrand, morphis: Should we rename pluggable-storage to "media"?  That's almost the same, and in practice it gives access to /media, so rings a nice bell
<morphis> ssweeny, jdstrand: can you comment on niemeyer's points on those?
<morphis> niemeyer: media also rings other bells like hardware media encoding/decoding etc.
<morphis> I still like plugable-storage more as that really describes what should only end up in /media
<ssweeny> well it's a subset of removable media I guess
<morphis> where /media is just the name being there for history reasons
<niemeyer> morphis: Yeah, that's true..
<niemeyer> morphis: "pluggable" is such an ugly term, though.. hmmm
<morphis> a bit, yeah
<morphis> niemeyer: I think for the access to /dev/sd* and /dev/mmcblk* we agreed with jdstrand that we allow this but explicitly put this into the udisks2 interface where we can ensure from the store side that just a single snap owned by canonical can use this
<morphis> and nothing else
<morphis> we maybe should enforce this in the sanitizeslot function
<morphis> like we do for the lxd interface
<sborovkov> Hello, does anyone know where I can download snapd 2.11 package for armhf?
<niemeyer> morphis: I wouldn't like to make that the norm
<morphis> niemeyer: yeah, but its a compromise until we have hotplug :-)
<niemeyer> morphis: That's unrelated to hotplug
<morphis> usb devices are hotpluged, so we get /dev/sd* /dev/mmcblk* device dynamically
<niemeyer> morphis: That's still unrelated to hotplug
<niemeyer> morphis: The problem is not the dynamic device.. it's the fixed one that contains the operating system
<morphis> if you think it that way, yes, true
<morphis> niemeyer: so short term for RTM, what are we doing?
<niemeyer> morphis: What is the snap the holds the slot side of this?
<morphis> udisks2
<morphis> https://code.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/udisks/+ref/master
<ppisati> sergiusens: it works, ship it!
<ppisati> ogra_: ^
<niemeyer> morphis: Okay, let's follow your advice and constrain it to udisks2/canonical until we have the snap declaration in place
<niemeyer> morphis: So same as lxd-support
<morphis> niemeyer: aye, thanks
<morphis> ssweeny: ok with that?
<niemeyer> morphis: Thank you
<ssweeny> morphis, sure
<morphis> niemeyer: want to get this solved :-)
<morphis> "solved" to be honest
<niemeyer> morphis: For the iface name, external-storage, dynamic-storage, <other idea>?
<morphis> external-storage if we want to exclude system partitions
<morphis> ssweeny: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/lxd_support.go#L95
<morphis> ssweeny: but in our case that would be in SanitizeSlot
<ssweeny> morphis, ack
<morphis> niemeyer: but can't think of anything else
<morphis> niemeyer: but will see if I get something better overnight
<niemeyer> morphis: This is about /media to be clear
<morphis> right
<niemeyer> morphis: So it's not just about excluding system partitions
<morphis> just asking to make this clear
<morphis> niemeyer: if you don't like plugable-storage I would be then for external-storage
<morphis> niemeyer: or removable-media according to http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT
<niemeyer> morphis: You just made a typo on it. Yes, I really don't like it. :)
<morphis> "3.11. /media : Mount point for removable media"
<morphis> "This directory contains subdirectories which are used as mount points for removable media such as floppy
<morphis> disks, cdroms and zip disks."
<niemeyer> morphis: removable-media is nice
<morphis> it doesn't mention usb, but same story
<niemeyer> morphis: external-storage might mean S3/etc
<morphis> yeah
<morphis> so removable-storage it is
<niemeyer> morphis: removable-media keeps the association with /media, so very nice
<morphis> ssweeny, jdstrand: you're ok with that too?
<niemeyer> morphis: media!
<niemeyer> :)
<morphis> sorry ..
<morphis> too late
<morphis> removable-storage
<niemeyer> removable-media
<morphis> ah sorry
<morphis> niemeyer: can you comment that on the PR?
<morphis> need to leave now
<niemeyer> morphis: Yeah
<niemeyer> morphis: Thanks o/
<morphis> thanks
<ssweeny> ok so we settled on removable-media?
<mup> PR snapd#1809 closed: interfaces/builtin: allow writing on /dev/vhci in bluetooth-control <Created by cwayne18> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1809>
<ev> sergiusens: do you care about "Coverage decreased (-0.03%) to 97.871%â? Should I pad that out with another test case?
<niemeyer> ssweeny: Yeah
<ssweeny> ack
<ssweeny> niemeyer, when you say "the slot (not the interface) can only be used by udisks2" you just mean error on snap != udisks2 and dev != canonical in SanitizeSlot rather than SanitizePlug, right?
<niemeyer> ssweeny: Right.. otherwise we'd only allow the snap to connect to itself
<ssweeny> niemeyer, ok cool. Just making sure I understand
<niemeyer> ssweeny: lxd-support is different because the slot is constrained to the core
<niemeyer> ssweeny: It's the consumer that gets wider access
<ssweeny> right
<niemeyer> ssweeny: I think we'll eventually want to constrain the consumer of udisks2 as well, but we can probably wait until snap-declarations can do that
<mup> PR snapcraft#748 closed: kernel plugin: vmlinuz -> kernel.img hard link <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/748>
<ssweeny> that makes sense
<sborovkov> jamiebennett: Hello. Who can I ask about store issue I have? For some reason can't install from our snap again though everything seems correct on my side. Evan Dandrea does not seem to appear on IRC for last couple of days (I wanted to ask him)
<sergiusens> ev I thought that covering the schema in a unit test would bring the coverage back up for you
<sergiusens> ev that is what I got from looking at coveralls
<mup> PR snapd#1805 closed: tests: use beta u-d-f in test by default  <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1805>
<jdstrand> niemeyer: I'm fine with media
 * jdstrand but also continue to be fine with pluggable-storage
<jdstrand> removable-media is nice
<jdstrand> now that I've read backscroll :)
<jdstrand> niemeyer, morphis: ^ +1 on removable-media
<jdstrand> mvo: ping regarding merge questions
<niemeyer> jdstrand: Ack, thanks
<mvo> jdstrand: pong
<jdstrand> mvo: hey, did you see my questions from earlier?
<jdstrand> mvo: if not, that's fine
<mvo> jdstrand: no, sorry
<mvo> jdstrand: aha, policy
<mvo> jdstrand: with two +1 you can merge
<jdstrand> mvo: am I allowed to merge my own with two +1s or just others?
<jdstrand> jamiebennett: btw, thank you for commenting in bug #1583514
<mup> Bug #1583514: firewall-control and ip[6]table_filter module loading <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1583514>
<mvo> jdstrand: we have no rules here, but you can also merge other if you feel they are ok, I think you will have good judgement on this
<jdstrand> mvo: ack, yes. just wanted to make sure I was following any commit policy. we talked about this before, but from the perspective of a non-committer. I jotted down what you said. Thanks!
<mvo> jdstrand: sure, enjoy
<jdstrand> mvo: oh, one last clarification-- the +1 must be froma core committer, yes?
 * jdstrand is assuming two +1s from https://github.com/orgs/snapcore/people
<mvo> jdstrand: yes, but we are sometimes leaniant about this, e.g. interfaces reviews can go in with a single +1 from a core commiter and an additonal one from a trusted community person
<jdstrand> ok, then I think upower-observe fits that
<mup> PR snapd#1813 opened: debian: umount --lazy before rm on snapd.postrm <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1813>
<jdstrand> but the policy updates https://github.com/snapcore/snapd/pull/1779 does not
<mup> PR snapd#1779: miscellaneous policy updates: default policy, browser-support, and x11 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1779>
<mup> PR snapd#1797 closed: interfaces: add upower-observe interface (LP: #1595813) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/1797>
<dobey> error: cannot read snap file: cmd: "unsquashfs -i -d /tmp/read-file081779118/unpack /tmp/snapd-sideload-pkg-621916875 meta/snap.yaml" failed: exit status 1 ("Filesystem on /tmp/snapd-sideload-pkg-621916875 is (49135:701), which is a later filesystem version than I support!\n")
<dobey> ^^ i get this when trying to install sl-moon127
<dobey> also with tree.snap
<dobey> err, tree from psivaa
<mup> PR snapd#1790 closed: store: set initial device session <Critical> <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1790>
<mup> PR snapd#1784 closed: Add an interface to access the usb drives <Created by axelebas> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1784>
<tianon> lool: can you give me slightly higher privs on https://github.com/docker-snap ? :)  (wanting to rename the repo I just transferred there)
<mup> PR snapd#1779 closed: interfaces: updates to default policy, browser-support, and x11 <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1779>
<dobey> i guess mup is the only living thing in here really
<jdstrand> roadmr: hey, cprov said he was going to ensure that the 'grade' commits to the review tools are pulled. can you guys just make that r736?
<jdstrand> roadmr (cc cprov): that's* r736 has a nicer message for a desktop file error
<cprov> jdstrand: np, will bump SCA
<lool> tianon: hey
<ogra_> hmpf ...  i cant access the uploads histrory of ubuntu-core in the store anymore ... i get a permanent gateway timeout
<lool> tianon: sure
<ogra_> nessita, are you able to open this page ?  https://myapps.developer.ubuntu.com/dev/click-apps/4142/configurations/
<lool> tianon: done, you're owner too now
<ogra_> looks like the store timeouts start to get more serious
<lool> tianon: I dont think I could adjust this earlier, it was pending your acceptance of the invitation
<jdstrand> cprov: thanks!
<nessita> ogra_, checking
<ogra_> (this is the uploads summary page of ubuntu-core ... which is admittedly a long list (but far from where we will be at in ... say 6 months))
<nessita> ogra_, no, too slow
<nessita> ogra_, let me check
<ogra_> nessita, there are 6 uploads a day happening (6 arches, automated daily build for edge) ... so this will explode even more in the future
<nessita> ogra_, right, it shouldn't, could you please file a bug?
<ogra_> will do
<ogra_> i guess i hit a threshold today ... yesterday it still worked :)
<nessita> ogra_, yeah, it needs fixing for sure
<nessita> ogra_, I have oopses with the sql timeline, so we can debug from there, but the bug will help us track this
<ogra_> oki
<ogra_> nessita, bug 1619018
<mup> Bug #1619018: timeouts when trying to look at the uploads summary of ubuntu-core <Software Center Agent:New> <https://launchpad.net/bugs/1619018>
<nessita> ogra_, thanks!
<ogra_> np, thanks for looking :)
<lool> tianon: I wonder whether this proposed change could be related https://github.com/snapcore/snap-confine/pull/122/files
<mup> PR snap-confine#122: Replace pivot_root implementation by LXC's <Created by stgraber> <https://github.com/snapcore/snap-confine/pull/122>
<mup> PR snapd#1813 closed: debian: umount --lazy before rm on snapd.postrm <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1813>
<lool> tianon: and that might explain the difference between a classic and a core system: there would be other mounted filesystems
<mup> PR snapd#1777 closed: osutil: tweak the createUserTests a bit and extract common code <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1777>
<tedg> Snapd is failing for me: "internal error: could not unmarshal state entry "snaps": json: cannot"
<tianon> lool: thanks :)
<tianon> lool: nice find!  that does look like it could be related!
<tedg> Ah, got the rest: "cannot unmarshal string into Go value of type int"
<mup> PR snapd#1814 opened: client,cmd/snap: display os-release data only on classic <Created by zyga> <https://github.com/snapcore/snapd/pull/1814>
<lool> tianon: actually they get an "operation not permitted" on unshare
<mup> PR snapcraft#772 opened: Set GOBIN in go plugin build environment <Created by tasdomas> <https://github.com/snapcore/snapcraft/pull/772>
<tianon> lool: interesting, although could definitely still be related!
<tianon> lool: rootfs issues always come in spades, in my experience...
<tianon> as evidenced by Docker 1.11 and 1.12 getting entirely different errors :)
<lool> tianon: a quick grep on the source doesn't yeild very interesting usages of unshare in docker, but could still be the same issue yeah
<zyga> jdstrand: not high priority but I'd love to know +/-1 on https://github.com/snapcore/snap-confine/pull/121
<mup> PR snap-confine#121: Allow the use of capabilities over setuid bit <Created by zyga> <https://github.com/snapcore/snap-confine/pull/121>
<tasdomas> is there a way to allow a snap application access to system files (e.g. /etc/hosts) ?
<lool> tianon: if you're tempted to rebuild snapd with that pull request and try that, that might prove the point or not
<tianon> yeah, definitely tempting
<tianon> had been pondering whether it was worth trying, but I think it likely is
<lool> tianon: I have to disappear for a bit to hug the family and I'm not feeling too well so I probably wont last long
<lool> I'll check back in a few
<tianon> lool: ok, no worries!  thanks for the extra eyes, and take care of yourself :)
<sborovkov> Hello, any way I can make snapcraft ignore such errors? '/home/kami/build/snaps/full/parts/ping-wrapper/build/rootfs/var/lib/avahi-autoipd' is a broken symlink pointing outside the snap
<tedg> So it looks like my state.json is somehow invalid, is there a way to rebuild it?
<jdstrand> ogra_: hey, we used to have http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/. where has that gone?
<jdstrand> ogra_: well, my real question is where do a find a linux-generic kernel for armhf? (I'm updating some docs)
<jdstrand> ogra_: also, http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ had manifests. where did those go? I feel like you told me that once before.... this time I am documenting it :)
<jdstrand> :wq
<jdstrand> meh
<magicaltrout> not even irrsi supports :wq
<mup> PR snapd#1815 opened: Auto connect interfaces for special name/developer combinations <Created by arges> <https://github.com/snapcore/snapd/pull/1815>
<magicaltrout> so lazyPower  now the crazyiness is coming to an end, i should have some cycles over the next few weeks to tidy up a bunch of DC/OS stuff and add some proper relations etc
<lazyPower> nice
<magicaltrout> one thing people did like today was the fact you could leverage stuff deployed in DC/OS againsts normal charms
<magicaltrout> assuming the hooks provided enough metadata
<nessita> ogra_, hey, are you blocked by this store timeout in the configurations page?
<ev> sergiusens: oh yes, I forgot you had requested that. On it
<mup> PR snapd#1816 opened: libvirt interface to allow snaps to access libvirtd on a classic host <Created by cmars> <https://github.com/snapcore/snapd/pull/1816>
<mup> PR snapd#1817 opened: Wrapper: create $SNAP_USER_COMMON (LP:#1611063) <Created by brunonova> <https://github.com/snapcore/snapd/pull/1817>
<mup> PR snapd#1789 closed: many: when installing snap file derive metadata from assertions unless --force-dangerous <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1789>
<lool> tianon: I'm headed to bed, did you find anything?
<tianon> lool: I tried several times to just dpkg-divert snap-confine's binary and copy in my manually-built binary, but couldn't get it working (and hadn't decided to just grab the direct .deb src to apply the patch and build a whole new .deb yet)
<kyrofa> tianon, you're trying to run your own snap-confine?
<tianon> yeah
<tianon> kyrofa: trying to test https://github.com/snapcore/snap-confine/pull/122, specifically
<mup> PR snap-confine#122: Replace pivot_root implementation by LXC's <Created by stgraber> <https://github.com/snapcore/snap-confine/pull/122>
<tianon> because we think it might be a potential fix for the issues we're seeing with Docker in Classic too
<lool> tianon: note that snapd reexecs itself from the ubuntu core snap; I dont know about snap-confine though
<tianon> ah
<kyrofa> tianon, lool indeed, which makes it very difficult to test some things
<tianon> :)
<lool> tianon: set SNAP_REEXEC=0
<kyrofa> tianon, lool if re-exec is enabled, it's probably using the snap-confine from within the core snap
<lool> in the env
<lool> tianon: snapd env should be enough, via an override file would work; or set it in /etc/environment
<tianon> I get permission errors when I replace my host env's snap-confine, so I think that is being used at least in some capacity
<lool> tianon: oh quite probably indeed
<lool> tianon: is it +x?
<tianon> yes
<tianon> and u+s
<tianon> just like the original
<tianon> it executes fine, but has other errors, so I'm not convinced I'm compiling correctly
<tianon> hence why I was going to try re-building a new .deb
<stgraber> tianon: you may want to unload the snap-confine apparmor profile
<lool> yeah, makes sense
<kyrofa> tianon, you can always overlayfs the new binary on top of the one in the core snap too
<stgraber> tianon: the new snap-confine does a bunch of new things which the old profile doesn't allow, so you either want to update your local profile or just disable it (I did the later while working on that branch)
<kyrofa> But yeah... profiles
<tianon> stgraber: ah, exciting -- I even tried building straight from the tag of my host version
<tianon> stgraber: can't we just make everything unconfined and call it a day? O:)
<lool> tianon: probably wouldn't help since there were no denials
<tianon> lol I know, just joking around
<tianon> permissions are hard, let's go ride bikes
<lool> :)
<mup> PR snapcraft#763 closed: Include /sbin and usr/sbin in wrappers <Created by lool> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/763>
<cmars> your CI log banners are awesome
<mup> PR snapcraft#510 closed: Use the in ubuntu-core python3 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/510>
<ogra_> jdstrand, you mean a linux-generic snap ? we dont build that atm ... and the cdimage images had to be removed "on request"... our ubuntu-image created ones will go there after RTM
<ogra_> regarding manifests ... we'll soon get them for the ubuntu-core snap builds .. i'll then link them from http://people.canonical.com/~ogra/ubuntu-core-builds/
<ogra_> jdstrand, if you want to roll your own kernel snap ... fork https://code.launchpad.net/~snappy-dev/pi2-kernel-snap/trunk ... and https://code.launchpad.net/~snappy-dev/kernel-snap-makefile/trunk ... then edit the armhf target in the Makefile, make your snapcraft.yaml from your pi2-kernel-snap use your Makefile and just let LP build the snap for you
<ogra_> s/from/for/
<ogra_> err
<ogra_> (if needed i can set that up for you, but not tonight anymore :) )
<ogra_> nessita, well, it is the only way to see which revision was released to stable currently ... if you have another way to get the channel info then the page isnt that important
<slangasek> ogra_: so, u-d-f's implementation of pi2 support says 'bcm2836-rpi-2-b'... which is not the name of a file anywhere in the resulting boot partition.  Is this the wrong dtb name?
<slangasek> ogra_: I see in uboot.env that we have fdtfile=bcm2709-rpi-2-b.dtb; that's a file that exists in the gadget snap boot-assets dir and is published without modification or name change to the boot partition.  So the 'device-tree'/'platform' declaration seems to not do anything useful here
<ogra_> slangasek, yeah, not on the pi2 (as i explained, the SBL loads it ... )
<ogra_> but bcm2709-rpi-2-b.dtb should be the correct name
<ogra_> s/SBL/SPL/
<ogra_> we should definitely ship it in case we find a way to use uboot for loading the dtb and overlays one day
<ogra_> so try to treat it as if it would be used :)
<slangasek> ogra_: ok; I think the pi2 gadget is ready for a release, I don't think I've been given access to upload that one
<ogra_> slangasek, well, we need someone to approve even if i upload it for you ... did you merge your changed in the snappy-systems branch ? i dont see any changes
<ogra_> (i just did all the file moves to clean up boot-assets)
<slangasek> ogra_: erm, where are you pushing these changes?  I'm using lp:~snappy-dev/snappy-hub/snappy-systems which is the only branch I've ever been told about
<ogra_> http://paste.ubuntu.com/23118082/
<ogra_> i see commits in the bzr log but i see no actual files there
<ogra_> oh, i' blind
<ogra_> *i'm
<ogra_> sorry ...
<slangasek> ok :)
<wililupy> Does anyone know of an easy way to implement a udev rule file so that it doesn't have to be created after installation manually?
<ogra_> slangasek, change pushed
<wililupy> maybe in cloud init after snappy starts up?
<ogra_> i can upload the gadget, but i think we need someone like jdstrand to approve it
<lool> tianon: I'm headed to bed, good night
<tianon> lool: good night!
<wililupy> Dang lool, burning the midnight oil? Get some rest
<ogra_> slangasek, btw, versions are shallow in snaps  :) all that counts is the revision the store assigns
<slangasek> ogra_: yes; that doesn't mean they're not a useful convention
<slangasek> ogra_: I don't see your boot-asset change pushed?
<ogra_> well, you end up with two ... next to each other in snap list ... which adds confusion ... but yeah
<ogra_> gah
<ogra_> seems we clashed mid air
<ogra_> oh, wow
<ogra_> i can actually publish it in the store
<ogra_> done :)
<ogra_> and branch pushed as well
<ogra_> slangasek, you got mail ;)
<ogra_> argh, crap
<ogra_> i forgot to generate uboot.env
 * ogra_ fixes
<ogra_> slangasek, 16.04-0.10 revision 17 is what you want
<ogra_> uploaded and published
<slangasek> cool
<ogra_> and you have upload access too now
<ogra_> (once you accept the invite :) )
<slangasek> \o/
<slangasek> ogra_: you want to add me to dragonboard too while you're at it?
<ogra_> sure
<ogra_> added you to pi3 as well :)
 * ogra_ vanishes back into the night... :)
<slangasek> ogra_: ok, well that broke snap prepare-image; iterating
#snappy 2016-09-01
<sergiusens> thanks ev, but you have static errors now :-)
<ev> d'oh
<ev> fixing
<slangasek> ev: hey, so I mistakenly clicked the 'unpublish' button for pi2 (what I really wanted was to remove a particular revision from a channel), and I got a gateway timeout, and then when I hit reload I got an EPERM but it seems it actually did unpublish so that seems bad
<mup> PR snapd#1818 opened: Fix documentation on price - it is a floating point number, not a string <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1818>
<ev> slangasek: eep. Can I have a bug report?
<slangasek> ev: where at?
<ev> sergiusens: all good
<ev> slangasek: https://bugs.launchpad.net/developer-portal/+filebug
<slangasek> ev: https://bugs.launchpad.net/developer-portal/+bug/1619086
<mup> Bug #1619086: 'unpublish' throws errors, but actually worked <Developer registration portal:New> <https://launchpad.net/bugs/1619086>
<ev> thank you
<mup> PR snapd#1817 closed: Wrapper: create $SNAP_USER_COMMON (LP:#1611063) <Created by brunonova> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1817>
<mup> PR snapd#1818 closed: Fix documentation on price - it is a floating point number, not a string <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1818>
<dholbach> hey hey
<davidcalle> o/
<psivaa> dobey: re?
<psivaa> dobey: sorry, re: tree, i did not have any issues installing. Let me try and dig more on that error
<mup> PR snapd#1573 closed: asserts/tool,cmd/snap: introduce hidden "snap sign" <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1573>
<dholbach> niemeyer, can you moderate the snapcraft list, I know of at least one good mail sitting in the queue :)
<zyga> o/
<zyga> \o
<zyga> \o/ :)
<mwhudson> TIL: if you run /var/lib/classic/enable.sh before making your OS snap, snappy thinks you're on a classic system
<mwhudson> is there an easy way to run kvm so you can see both serial and the vts?
<mwhudson> oh -serial stdio
<mvo> mwhudson: yeah
<mvo> mwhudson: qemu is pretty fantasic, you can also run it as a nc/telnet capable service that you can connect to later, I pushed a branch for spread with that feature to allow easy inspection of boot failures
<mwhudson> mvo: qemu's command line is one of those things i've been a bit afraid of for years, but i'm getting there :-)
<mvo> mwhudson: ha! for totally good reasons, the functionality is awesome, the commandline â¦ not so much
<mwhudson> he's a strange systemd question
<mwhudson> can a process find out if it is a main process for some systemd service?
<kalikiana> best motivation to make a snap: qt update broke my irc
<kalikiana> was done in 15min :-P
<kalikiana> also, awesome to find that cleanbuild now can do remote parts
<mup> PR snapd#1819 opened: snap: set user variables even if HOME is unset (like with systemd services) <Created by mvo5> <https://github.com/snapcore/snapd/pull/1819>
<kalikiana> Hmm how do I launch a browser a la xdg-open from a confined snap?
<morphis> mvo, ogra_: I've generated a new image for my pi3 yesterday with ubuntu-device-flash core 16 --channel edge -kernel pi2-kernel --gadget pi3 --os ubuntu-core -o test.img
<morphis> mvo, ogra_: when I boot the resulting image now I get no snaps listed when calling snap list
<morphis> where /snap/pi2-kernel/11/ is present
<morphis> but no ubuntu-core snap inside /snap
<mvo> morphis: what does snap changes tell you?
<mvo> morphis: any error details there? also systemctl status snapd.firstboot
<morphis> mvo: https://paste.ubuntu.com/23119389/
<morphis> https://paste.ubuntu.com/23119391/
<mup> PR snapd#1814 closed: client,cmd/snap: display os-release data only on classic <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1814>
<pitti> mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd â known?
<ysionneau> hmm Snappy takes a very long time to boot when not connected to internet
<zyga> kalikiana: you use xdg-open having snapd-xdg-open installed on your host
<ysionneau> mostly because of [FAILED] Failed to start Wait for Network to be Configured.
<ysionneau> is there a way to tell snappy to not wait for network to boot?
<zyga> kalikiana: I believe there is an SRU for snapd-xdg-open into xenial, it is also slowly spreading into other distributions
<ysionneau> ( https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html )
<zyga> mwhudson: hey, interesting, no idea really
<zyga> kalikiana: the core snap should now have xdg-open executable that just talks to the service on the outside
<kalikiana> zyga: Ah. So it should start working whenever that new package arrives?
<mvo> pitti: yes, this is why I asked all those autopkgtest question :)
<mvo> s
<zyga> kalikiana: yes
<zyga> kalikiana: I believe so, please have a look at https://github.com/snapcore/snapd-xdg-open/
<zyga> kalikiana: you can build and install that locally
<zyga> kalikiana: and experiment with the special version of xdg-open available here: https://github.com/snapcore/snapd-xdg-open/blob/master/src/xdg-open.c
<zyga> kalikiana: exectutable built from that file should be in the core snap, if not you can add it to your own snap for now)
<zyga> jamiebennett: o/
<jamiebennett> zyga: o/
<mup> PR snapd#1820 opened: many: start services only after the snap is fully ready (link-snap was run) <Created by mvo5> <https://github.com/snapcore/snapd/pull/1820>
<morphis> mvo: so really looks like something got broken with the firstboot scenario
<morphis> mvo: want a bug for that?
<mvo> morphis: its fine, I think this breaks our tests currently so I'm already on it
<morphis> good :-)
<mvo> morphis: very confusing that state.json is there, if you haven't done anything with the thing yet, could you paste that file?
<mvo> morphis: but only if you haven't ran any command except snap changes
<morphis> mvo: sure
<morphis> mvo: https://paste.ubuntu.com/23119456/
<mvo> morphis: hm, interessting. looks like a race
<morphis> :-)
<mup> PR snapd#1821 opened: ensure snapd.refresh.service waits for snapd.firstboot.services <Created by mvo5> <https://github.com/snapcore/snapd/pull/1821>
<mvo> morphis: -^ for you
<mup> PR snapd#1822 opened: snapd.refresh.service: require snap.socket and /snap/*/current <Created by stolowski> <https://github.com/snapcore/snapd/pull/1822>
<ogra_> ysionneau, this might be related to the new netplan network setup (before we covered for this case throughj /etc/network/interfaces.d options (iirc it was "allow-hotplug" and leave "auto" out so that link detection takes precedence)), probably pitti has an idea how the netplan setup now differs from this
<pitti> ogra_: ah, so you want to mark some interfaces as "not relevant for booting" (allow-hotplug), so that network-online.target does not block on those?
<pitti> ogra_: right, that's currently missing; bug report appreciated
<mup> PR snapd#1823 opened: overlord/devicestate: try to fetch/refresh the signing key of serial (also in case is not there yett) <Created by pedronis> <https://github.com/snapcore/snapd/pull/1823>
<ogra_> pitti, well, we might have networkless drones that get occasionally connected to a cable for updates etc but are offiline most of the time ... or span up their own AP for a management app on a phone but for updates use ethernet ,... etc etc
<ogra_> pitti, i guess that also needs an option in console-conf ?
<pitti> ogra_: enabling/disabling it globally is fairly easy; right now netplan always enables systemd-networkd-wait-online.service into wait-online.target, so that booting waits for all declared interfaces; if we want to globally disable that, this is simple
<pitti> disabling it on a per-interface level is more involved, not sure if you need that
<ogra_> i guess thats a start ... long term per interface is likely needed
<ogra_> for such corner cases
<pitti> ogra_: yeah, I think so; quite a lot of services start when network-online.target starts and assume that they can do network stuff; these would be broken wit that setup
<pitti> but if you have done that until now with allow-hotplug, this won't change
<ogra_> mvo, do you remember why you created the pi2.moved dir in snappy-systems ? looks like thats a 15.04 setup, i guess i can wipe it ?
<mvo> ogra_: yeah, kill it please
<ogra_> done
<ppisati> so, this morning i created a fresh new amd64 img
<ppisati> but when i try to install a kernel on it
<ppisati> i got
<ppisati> error: cannot find signatures with metadata for snap "foobar.snap"
<ppisati> funny thing is that i installed a kernel yesterday on my rpi2 board
<ppisati> so
<ppisati> what am i doing wrong?
<zyga> ppisati: I believe you are now seeing assertions in place
<zyga> ppisati: is the foobar snap something you installed from the store?
<ppisati> nope
<ppisati> something i rolled
<ppisati> is there a way to sideload a custom kernel/snap?
<ppisati> or to turn off the assertions?
<zyga> ppisati: yep, though I don't remember the option name, perhaps pedronis knows as he's working on that
<ogra_> would be bad if he wouldnt know it then ;)
<mup> PR snapd#1824 opened: tests: use ubuntu-image for the ubuntu-core-16 image creation <Created by mvo5> <https://github.com/snapcore/snapd/pull/1824>
<ogra_> mvo, do you happen to have commit access to ubuntu-image ? ( http://paste.ubuntu.com/23119768/ avoids the sudo calls if we are root already, should fix the snap issues)
<pedronis> ppisati: you need to use --force-dangerous if that kernel is local
<pedronis> and you don't have store assertions/signatures for it
<ogra_> uuuuh !
<ogra_> "force dangerous"
<ogra_> that makes you feel like indiana jones ... :) ... adventures ;)
<ppisati> use the force-dangeroues Luke!
<pedronis> ogra_: it's quite new but that's what we discussed with Gustavo
<ogra_> :)
<pedronis> ogra_: the issue is really that there are to cases, you are bing asked/tricked to install  a random snap (the option should tell you maybe you need to know/trust what you are doing), you are installing a snap you just built
<pedronis> and then it feels a bit silly
<pedronis> s/to cases/two cases/
<ogra_> yeah
<ogra_> i totally understand ... just found the option name funny :)
<tvoss> sergiusens: o/ I'm trying to build a snapcraft package, latest and greatest from git, but package build fails with: http://pastebin.ubuntu.com/23119776/
<tvoss> sergiusens: is that known or "fails on your machine only"? :)
<ogra_> "root@" ??
<ogra_> dont build snaps as root ...
<mwhudson> uh oh i didn't realize switching to netplan implied waiting for network
<mwhudson> pitti: is this a new-ish feature in netplan or something?
<mwhudson> i'm sure i wasn't seeing this behaviour a few days ago but i am now
<morphis> mvo: thanks!
<pitti> mwhudson: not really that new: https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1613548
<mup> Bug #1613548: enable systemd-networkd-wait-online.service <nplan (Ubuntu):Fix Released by pitti> <https://launchpad.net/bugs/1613548>
<pitti> mwhudson: since 0.7 (two weeks ago)
<mwhudson> pitti: huh
<mwhudson> oh man i'm amazed anything ever boots
<pitti> i. e. currently it behaves like ifupdown's "auto", before 0.7 it always behaved like "allow-hotplug"
<mwhudson> what is it that's waiting for network-online though?
<mwhudson> oh sorry never mind i need to sleep
<pitti> mwhudson: not sure, a few services wait for it (or network mounts)
<pitti> mwhudson: but most service indeed aren't blocking on this, so not sure what's actually blocking
<pitti> mwhudson: on my system: lxd.service, rc-local.service, kerneloops; none of those are critical
<mwhudson> pitti: ah, it's ubuntu-fan.service here i think
<mwhudson> here as in "on my snappy image"
<mwhudson> oh yeah and rc.local.service
<ogra_> mwhudson, bug #1619245 for your enjoyment ...
<mup> Bug #1619245: console-conf does not allow to create a user for offline devices <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1619245>
<ogra_> (since i noticed there was no bug for that yet)
<mwhudson> ogra_: fair enough, can you get someone with some architectural-level view to say how that should work?
<mup> Bug #1619245 opened: console-conf does not allow to create a user for offline devices <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1619245>
<ogra_> heh, i'll try to catch niemeyer today
<jamiebennett> ogra_: That bug doesn't look good.
<ogra_> nope
<ogra_> pedronis, uuuh, i just noticed that in classic i get the same issue when tyring to install a local snap ... is that wanted ?
<pedronis> ?
<pedronis> it's for all snap install *.snap
<ogra_> ogra@styx:~/Devel/branches/ubuntu-image-mvo$ sudo snap install ubuntu-image_0.5_amd64.snap --devmode
<ogra_> error: cannot find signatures with metadata for snap "ubuntu-image_0.5_amd64.snap"
<ogra_> ogra@styx:~/Devel/branches/ubuntu-image-mvo$ sudo snap install ubuntu-image_0.5_amd64.snap --devmode --force-dangerous
<ogra_> ubuntu-image 0.5 installed
<ogra_> ah
<ogra_> i thought only for the ones the system marks un-upgradeable in the images
<ogra_> s/un-upgradeable/un-sideload-able/
<pedronis> ogra_:  we are protecting from two things here
<pedronis> a) the snap didn't go through the store validation (now containment should do its job but there are still potential issue with bugs that are more likely with a non validated snap)
<pedronis> b) you will be mounting tha squashfs with the kernel
<ogra_> mvo, please try http://people.canonical.com/~ogra/snappy/ubuntu-image_0.5_amd64.snap ... should work even with the sudo issues
<pedronis> so there are potential vulnerabilities that way
<ogra_> yeah ... but i already use --devmode in a local install anyway
<pedronis> that means something else though
<ogra_> which means i know i'm installing something potentially insecure
<pedronis> yea, maybe we should conflate devmode to mean that too
<pedronis> but not sure
<ogra_> imho --devmode should just imply --force-dangerous when i do a local sideload
<pedronis> it's a bit of Gustavo question that one
<jamiebennett> ogra_: Seems others are having issues with this first boot experience, see the email from MikeB on the snapcraft list
<jamiebennett> (this was with network though)
<ogra_> jamiebennett, that triggered my bug ... (i had discussed ityesterday with mwhudson and cyphermox already and they said they would discuss it internally, so i refrained from filing a bug ... seeing others have issues too got me to file it)
<ogra_> well, i guess he has network but no internet access in his case ... thats even more tricky
<jamiebennett> ogra_: Yeah, I guess we will always come across people with no network or without a correctly configured UO account, in this case without a ssh key
<ogra_> right
<jamiebennett> ogra_, mwhudson: Worth getting back to MikeB on the list
<ogra_> and we should have a fallback ... even if it is insecure and should probably print a warning
<ogra_> a typical case is an IoT device that brings up an AP so you can control it via a mobile app, but doesnt have any other connection to the internet
<ogra_> there you wouldnt set up any network, but would perhaps want a local user to snap install something
<jamiebennett> ogra_: in that case only local sideloaded snaps should be allowed
<ogra_> well, that would be fine ... the issue is that you dont even get a login console
<ogra_> console-conf just hogs them all unless you can finish it once successfully
<ogra_> (though admittedly if there is no user at all you dont need a login console either)
<jamiebennett> ogra_: so we need to teach console-conf to add local users it seems
<ogra_> yes
<jamiebennett> It could use snap create-user but that expects a correctly configured UO account
<ogra_> pitti, bug 1619258
<mup> Bug #1619258: netplan should allow NICs to be disconnected and not stall the boot <Snappy:New> <nplan (Ubuntu):New> <https://launchpad.net/bugs/1619258>
<mup> Bug #1619258 opened: netplan should allow NICs to be disconnected and not stall the boot <Snappy:New> <nplan (Ubuntu):New> <https://launchpad.net/bugs/1619258>
<Son_Goku> morning
<jamiebennett> Morning Son_Goku
<jamiebennett> ogra_: Did you manage to test slangasek's pi2 image?
<ogra_>  jamiebennett not yet ... in my TODO though ...
<ogra_> jamiebennett, i think he tested it locally on his pi2 though
<junaidali> Hi everyone, I'm new to Snappy, can we install libvirt-bin  in Snappy?
<jamiebennett> ogra_: OK, let me know. I've just sent my Pi2 off to iahmad for testing
<ogra_> will do
<jamiebennett> ogra_: and I believe slangasek said "It has not yet been tested on an actual RPi2"
 * ogra_ waits for a free moment where he doesnt find  bugs in 5min :P
<ogra_> *5 bugs in
<jamiebennett> ogra_: your a star :)
<ogra_> lol
<la_juyis> jamiebennett: ogra_ are you talking about a new rpi2 image?
<sergiusens> good morning
<ogra_> la_juyis, yes
<jamiebennett> gm sergiusens
<la_juyis> i was trying the classic offered in our site but aftr upgrading it didn't have network interfaces :D
<la_juyis> well, not nicely named nework interfaces
<ogra_> la_juyis, well, not sure who maintains the classic pi images, try talking to foundations perhaps ?
<ogra_> (though most of them are on vacation this week apparently)
<la_juyis> ogra_: thanks :)
<ogra_> pitti, did you see ysionneau's question on the ML ?
<ogra_> seems he sees the timing out network on boot when having two properly configured NICs (do they wrangle over the default route perhaps ? )
<pitti> I followed up on the bug
<ogra_> pitti, well, i think the thing he describes on the ML is another bug
<pitti> ogra_: maybe bug 1618522?
<mup> Bug #1618522: netplan does not generates .network files just for ethernet <nplan (Ubuntu):In Progress by pitti> <https://launchpad.net/bugs/1618522>
<ogra_> hmpf ... so building the pi2 image as slangasek describes explodes in snap prepare-image
<pitti> ogra_: it seems we have a "match: *" with dhcp4 rule by default, which is rather demanding (we expect all existing interfaces to respond to DHCP4)
<pitti> not a fan of this, this is a very strong assumption
<ogra_> yeah
<pitti> anyway, I'm currently working on restricting this to ethernets, not wifis
<ogra_> i pointed him to your bug ...
<ogra_> lets see if he confirms
<Son_Goku> zyga, hey
<Son_Goku> have you tried the SELinux policy module with snapd on F24?
<ogra_> jamiebennett, so i'm not able to build the pi2 image at all :/ ... snap prepare-image seems to fail
<ogra_> mvo, any idea ? http://paste.ubuntu.com/23120037/
<ogra_> subprocess.CalledProcessError: Command '['snap', 'prepare-image', '--channel=edge', 'amd64-generic-model.assertion', '/tmp/tmp77onoa5j/unpack']' returned non-zero exit status 1
<ogra_> Crash in state machine
<jamiebennett> ogra_: :(
<ogra_> ogra@styx:~/Devel$ snap --version
<ogra_> snap    2.14.1+ppa214-1
<ogra_> snapd   2.14.1+ppa214-1
<ogra_> series  16
<ogra_> ubuntu  16.04
<ogra_> i should be on the latest snapd
<ogra_> mvo, did you manage to boot at least an amd64 image built by ubuntu-image yet ?
<sborovkov> la_juyis: apt install network-manager and everything works fine...
<mvo> ogra_: but cloud-init stuff is missing so its a bad experience
<ogra_> mvo, how did you build it at all ?
<ogra_> i cant mamange to even have snap prepare--image to create one
<ogra_> COMMAND FAILED: snap prepare-image --channel=edge pi2-model.assertion /tmp/tmpoyu83bsc/unpackerror: cannot decode model assertion "pi2-model.assertion": assertion: "sign-key-sha3-384" header is mandatory
<ogra_> same for amd64
<mvo> ogra_: try http://paste.ubuntu.com/23119360/
<ogra_> hmm, more errros in slangasek's model assertion
<ogra_> wow, so after deleting like 10 extra lines it seems to do something now :)
<ogra_> (well, it sits there without any output)
<mvo> ogra_: yes, I reported a bug about the long delay
<mvo> ogra_: its snap prepare-image - which has a progress bar
<mvo> ogra_: but u-i is eating it
<ogra_> well, some "what am i doing" output would be helpful :)
<mvo> ogra_: I also pushed a branch with tweaks
<ogra_> ah
<mvo> ogra_: yeah, reported a bug about htis
<mvo> this
<ogra_> ok, i got an img
<mvo> ogra_:  https://github.com/snapcore/snapd/pull/1824 is something I want - u-i for our tests
<mup> PR snapd#1824: tests: use ubuntu-image for the ubuntu-core-16 image creation <Created by mvo5> <https://github.com/snapcore/snapd/pull/1824>
<mvo> ogra_: but not quite working yet, but close
<ogra_> lets see ogra@styx:~/Devel$ kvm -m 512 -redir :8022::22 images/snappy/u-i-amd64.img
<ogra_> qemu-system-x86_64: -redir :8022::22: Could not open 'images/snappy/u-i-amd64.img': Permission denied
<ogra_> ogra@styx:~/Devel$ ls -l images/snappy/u-i-amd64.img
<ogra_> -rw-r--r-- 1 root root 4000000000 Sep  1 14:59 images/snappy/u-i-amd64.img
<ogra_> wow
<ogra_> ok, boots after chowning it to ogra
<ogra_> hmm, or not
<ogra_> hangs now
<ogra_> now cloud-init goes mad
<ogra_> (trying to connect to some http service even though console-conf didnt run/start yet to actually configure the network)
<ogra_> i also see a lot kernel complaints about /dev/fd0 ... i guess we should blacklist the floppy module
<mvo> ogra_: yeah, cloud-init is going wild
<mvo> ogra_: in a meeting right now, later
<ogra_> mvo, btw, did you see my ping about the ubuntu-image snap above
<mvo> ogra_: not really,
<ogra_> seems to work fine here
<mvo> ogra_: cool, I pushed some updates fwiw
<mvo> ogra_: all based on my branch
<ogra_> yeah, i have a patch to work around the sudo bits
<ogra_> applied to your PR and then just snapcrafted :)
<mvo> ogra_: nice
<ogra_> http://paste.ubuntu.com/23119768/
<ogra_> something in ubuntu-image is actually bringing my machine onto its knees though ... during the last seconds the system goes completely unresponsive
<sborovkov> Hello. What does this error even mean? [Errno 17] File exists: '../tmp/log' -> '/home/kami/build/snaps/full/parts/gstreamer/install/rootfs/dev/log' During snap build. All I do for this part is copying of 1 file with organize  gstomx.conf: viewer/usr/share/gst-omx/
<ogra_> (when building an image)
 * ogra_ takes a break 
<ogra_> oooh !
<ogra_> waiting til cloud-init dies helps ...just takes 10min
 * ogra_ is logged in to his amd64 image built via ubuntu-image 
<ogra_> \o/
<jamiebennett> ogra_: ouch
<jamiebennett> ogra_: 10min + boot sounds bad ;)
<ogra_> well, thats how we know and love cloud-init :P
<ogra_> (nah, i'm not bitter, i always taste like that :P =
<ogra_> )
<mvo> ogra_: misfeature in ubuntu-image, we really need a way to feed a inital configuraiton, i.e. a  way to tell it to not look for remote cloud config
<ogra_> yeah
<ogra_> well,i'm happy it eventually boots
<ogra_> hmpf
<ogra_> booting isnt enough though
<ogra_> i end up without resolver ...
<ogra_> ogra@localhost:~$ sudo snap install htop
<ogra_> error: cannot install "htop": Get https://search.apps.ubuntu.com/api/v1/snaps/details/ubuntu-core?channel=stable&confinement=strict: dial tcp: lookup search.apps.ubuntu.com on [::1]:53: read udp [::1]:56040->[::1]:53: read: connection refused
<ogra_> ogra@localhost:
<ogra_> ogra@localhost:~$ ping web.de
<ogra_> ping: unknown host web.de
<ogra_> didnt we have some cdmline option that prevented cloud-init from doing network stuff at all ?
<ogra_> or some u-d-f thing that put it in place in /var/lib/cloud
 * ogra_ seems to remember something like that 
<ogra_> yeah, chacking /var/lib/cloud/data it definitely is different
<ogra_> err
<ogra_> s/data/seed/
<ogra_> ogra@pi3:~$ cat /var/lib/cloud/seed/nocloud-net/meta-data
<ogra_> instance-id: nocloud-static
<ogra_> this is what we're missing
<mvo> ogra_: yeah, there is some stuff stuff my branch
<ogra_> i think thats the only thing actually ... the other bit we put in place is uder-data which we wont need anymore
<ogra_> thanks to console-conf
<ogra_> wow ... and i thought after one successfull boot cloud--init wouldnt kick in anymore ... seems i was wrong
 * ogra_ twiddles thumbs
<rharper> attempting to build a core image with ubuntu-device flash using an updated os-snap I built, I'm getting an error: mkdir /tmp/diskimage470593504/system/var/lib/cloud: read-only file system -- any pointers?
<rharper> http://paste.ubuntu.com/23120293/ is my u-d-f command
<ogra_> rharper, --kernel pc-kernel
<rharper> ok
<ogra_> (else you install the gadget as kernel :) )
<mvo> ogra_: trying to replace u-d-f with u-i in our tests, I'm in a world of pain currently
<rharper> ogra_: thanks for that;  I get the same error though;  let me try in a clean Xenial vm
<mup> PR snapd#1799 closed: asserts,cmd/snap: add "name" header to account-key(-request) <Created by cjwatson> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1799>
<ogra_> no idea about the error though ...
<ogra_> mvo, i can imagine
<ogra_> damn ... i know i filed a bug once about the pre-creation of the cloud-init data
<ogra_> i cant find it
<ogra_> i was listing the exact files and their content
<mvo> arges: hey, feedback for your branch :)
<mvo> arges: I'm still keen to land it, delayed the sru for a bit
<ogra_> there we go
<ogra_> bug 1485306
<mup> Bug #1485306: ubuntu-device-flash should not create data in writable partition <Snappy:Invalid> <https://launchpad.net/bugs/1485306>
<ogra_> damn ... and it doesnt have the content either
<ogra_> hah
<mvo> ogra_: what are you looking for?
<ogra_> but putting both files in place makes it boot in seconds again
<ogra_> mvo, getting rid of the cloud-init mess
<ogra_> i have a 20sec boot again now
<ogra_> http://paste.ubuntu.com/23120339/
<mvo> ogra_: https://github.com/snapcore/snapd/pull/1824/files#diff-556bb7431481e375713ea3e0883a771aR127
<mup> PR snapd#1824: tests: use ubuntu-image for the ubuntu-core-16 image creation <Created by mvo5> <https://github.com/snapcore/snapd/pull/1824>
<ogra_> when i turn off the ubuntu user stuff it doesnt work though
<ogra_> i'd really like to get rid of this
<mvo> ogra_: fwiw, slangasek mentioned that cyphermox will work on a option for ubuntu-image to copy these files in place
<ogra_> (oh how i wish we could just unseed cloud-init :/ )
<mvo> ogra_: oh, meh :(
<ogra_> mvo, well, cyphermox is off til next week too
<mvo> ogra_: what happens if you turn off the ubuntu user?
<mvo> ogra_: meh, ok
<ogra_> it does the 10min boot again
<nessita> ogra_, hi! I read your response, when you have some time would you please let me know so we can find alternatives for you?
<ogra_> let me try to drop sigle lines from user-data
<rharper> cloud-init is searching for user-data, including nocloud seed gives it a source and to moves on;
<ogra_> nessita, well, its not only me, i guess mvo would also like to be able to look up which revisions he released to stable :)
<arges> mvo: ok no problem, yea looking at the comments now
<ogra_> rharper, so just the existence of the file shoould be enough ?
<rharper> ogra_: you may only need the meta-data file
<ogra_> well, that definitely didnt work
<mvo> ogra_: I use pen and paper for this
<ogra_> mvo, lol !
<mvo> (SCNR)
<rharper> ogra_: it needs a meta-data file to declare the instances;   it may need the user-data file as well (but empty)
<ogra_> mvo, living in the future, eh ?
<cyphermox> ogra_: how am I off till next week?
<ogra_> cyphermox, oh, you arent ? i thought everyone working on u-image was
<cyphermox> thanks for giving me some extra vacation, good day! :D
<ogra_> sorry, then i missed something :)
<ogra_> haha
<mvo> cyphermox: he said so! off you go :)
<cyphermox> hehe
<cyphermox> nah, I'm indeed doing this today
<cyphermox> I would write an empty user-data I guess, so no ubuntu user by default?
<mhall119> zyga: ping, have you had a chance to finish reviewing my blog?
 * ogra_ hugs rharper 
<rharper> so the presence of 'passwd' triggers the creation
<ogra_> you are right ! an empty user-data is ennough
<rharper> no ubuntu user is created by default but if you set the passwd, then that triggers the creation of the default user
<rharper> ogra_: nice!
<nessita> ogra_, we'll definitely fix the issue, but right-right now, it may take a few days
<cyphermox> well, actually we still want the ssh settings I think
<rharper> cyphermox: right
<ogra_> though i'm not sure if it works with a virgin image ... this one was configured now
<nessita> ogra_, so until then we wanted to give you an alternative, like curling the results from the package index
<cyphermox> rharper: what is the syntax if I want to create a user other than ubuntu?
<nessita> ogra_, so what do you need to know? what revision is in the stable channel for each arch?
<rharper> https://git.launchpad.net/cloud-init/tree/doc/examples/cloud-config-user-groups.txt
<rharper> cyphermox:
<ogra_> cyphermox, do you actually want to ? you should only need proper host keys
<rharper> and we need my branch/patch to enable use of --extrausers when running under snappy
<rharper> which is what I'm trying to test right now  =)
<ogra_> nessita, yeah, i guess that would be a good first step
<cyphermox> ogra_: then at least ssh_genkeytypes: ['rsa', 'dsa', 'ecdsa', 'ed25519'] seems good.
<ogra_> yeah
<cyphermox> maybe pwauth we don't need for the default images, but you'll probably want it for the testing
<rharper> if you drop the user-data keys 'password' and 'chpasswd'; no user should be created
<ogra_> user wise you already get the key from SSO ... so only the host keys shoudl be needed
<mup> PR snapcraft#752 closed: Ant properties, build target, and destination directory options <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/752>
<cyphermox> ogra_: well, for testing I would expect you don't run console-conf ?
<ogra_> cyphermox, well, yes and no ...
<mvo> slangasek: I also added a bug about that we need to be able to create local users via console-conf otherwise people are stuck when there is no network
<nessita> ogra_, what package name? ubuntu-core?
<ogra_> i'd like to see console-conf to work with offline devices too
<mvo> slangasek: (this came out of the team meeting today)
<ogra_> which means we'd need a fallback to actually create a local user anyway
<mvo> is it just my or is myapps.developer.ubuntu.com not responding?
<cyphermox> mvo: I know about that too, we should be able to fix that today hopefully
<ogra_> hah
<ogra_> *snap*
<ogra_> mvo, is faster than me
<mvo> cyphermox: excllent
<ogra_> (and i wasnt even in that meeting :P )
<cyphermox> ie. there already existed code to do that, we just need to dig for the corpse and hook it up to the lightning rods.
<ogra_> nessita, currently only ubuntu-core, yeah
<mvo> cyphermox: I have a slightly messy branch up for review that contains one important trunacte() vs dd fix, testing that right now
<cyphermox> ok
<mvo> cyphermox: sorry for the messyness, its a very busy world right now
<cyphermox> yeah, I know
<cyphermox> ubuntu-image got in my hands today as a rush rush rush job :)
<ogra_> mvo, mind adding http://paste.ubuntu.com/23119768/ to your snapcraft.yaml PR too ? then i dont need to crete an extra one
<mvo> but *hopefully* with that branch we can kill u-d-f for our own tests
<mvo> ogra_: I'm a bit confused about this one tbh, sudo should already do this, i.e. if sudo is run with uid=0 it will just do nothing, so I'm not sure how what it fixes
<ogra_> that makes ubuntu-image fully working as a snap
<ogra_> mvo, the issue is that you cant exec sudo from inside a snap
<ogra_> so sudo has no chance to fall back
<ogra_> when the snap binary is execed with uid 0 it should just not attempt sudo
<ogra_> (i know that could be coded cleaner though)
<mvo> ogra_: aha, you installed this without --devmode?
<ogra_> but with that change i can use ubuntu-image as snap just fine
<ogra_> nope
<ogra_> with --devmode
<rharper> can anyone else get to search.apps.ubuntu.com ?  u-d-f queries that and is failing now for me
<ogra_> ogra@styx:~/Devel/branches$ snap list ubuntu-image
<ogra_> Name          Version  Rev  Developer  Notes
<ogra_> ubuntu-image  0.5      x1              devmode
<ogra_> thats what i'm using here
<ogra_> http://people.canonical.com/~ogra/snappy/ubuntu-image_0.5_amd64.snap
<mvo> ogra_: hm, http://paste.ubuntu.com/23120379/ works for me
<ogra_> weird
<mvo> ogra_: maybe somethng else?
<ogra_> yeah, strange
 * mvo scratches head
<ogra_> perhaps my patch isnt actually needed ...
<ogra_> did you try without it ... can you run it ?
<mvo> ogra_: yes, as long as I run it via sudo
<ogra_> and if you dont it doesnt do the sudo call ?
<ogra_> (the in-code one)
<ogra_> well, then ignore my patch
<mvo> ogra_: it does and the sudo calls fails with "can not get pty"
<ogra_> ah
<ogra_> the old buddy pty :)
<ogra_> well, then ignore my patch ... should be fine then
<ogra_> mvo, do you also see your machine grind to a halt at the end of image creation ?
<ogra_> i think there is still something worng in the final steps of ubuntu-image
<mvo> ogra_: haven't seen that yet
<ogra_> must be my laptop then
<ogra_> strange
<ogra_> reproducable though
<mvo> ogra_: maybe I have it and just did not notice
<morphis> niemeyer, jdstrand, mvo: any further comments for https://github.com/snapcore/snapd/pull/1688 or can we merge it?
<mup> PR snapd#1688: interfaces: add fwupd interface <Critical> <Reviewed> <Created by timchen119> <https://github.com/snapcore/snapd/pull/1688>
<tedg> kgunn: I keep getting this when doing your mir build image instructions: https://paste.ubuntu.com/23120407/
<tedg> kgunn: Have you seen that? Not sure what a partitioning error 1 is.
<ogra_> mvo, any objections in me blacklisting the floppy module inside ubuntu-core ?
<ogra_> (the floppy errors on boot are annoying in kvm)
<niemeyer> morphis: I will look into it
<mvo> ogra_: not at all
<morphis> niemeyer: thanks
 * ogra_ does so then
<niemeyer> morphis, joc: Do you have a moment to talk about snapd#1811
<mup> PR snapd#1811: interfaces: serial-port: udev slot definition <Blocked> <Created by jocave> <https://github.com/snapcore/snapd/pull/1811>
<niemeyer> joc_: ^
<nessita> ogra_, roadmr my bash is poor but this will do https://pastebin.canonical.com/164527/
<mvo> morphis: its in
<mup> PR snapd#1688 closed: interfaces: add fwupd interface <Critical> <Reviewed> <Created by timchen119> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1688>
<ogra_> nessita, whats json_pp ?
<ogra_> (you pipe to it)
<mvo> pretty print
<ogra_> ah, perl
<nessita> ogra_, something that pretty prints json
<ogra_> yep ... adds linewraps, i see
<nessita> ogra_, can use any other json printing tools or just read the raw json
<ogra_> yup
<joc_> niemeyer: i have a moment yes
<nessita> ogra_, does that work for a couple of days as workaround?
<ogra_> yeah, i guess
<niemeyer> joc_: The point you raise there is a valid one, and I think we want a general fix so we don't hit this on other interfaces
<nessita> ogra_, let me know if not, we have someone assigned to the bug but RTM and GA priorities are tough (well you would know :))
<ogra_> :)
<joc_> niemeyer: ok, is it reasonble to attempt that fix now or do we need to do something to workaround it in the short term?
<niemeyer> joc_: The special case there is len(slot.Apps) == 0..
<tedg> sergiusens: Do you have any idea what I could be doing wrong here? https://paste.ubuntu.com/23120407/
<kgunn> tedg: no that's news to me....might ask mvo
<niemeyer> joc_: I'm looking at that code and wondering if it would be sensible to inject a security tag that matches the snap in that case, and whether that'd have the proper results
<rharper> cyphermox: so I think the os-snap I'm trying to install during the build is the issue; if I specify --os ubuntu-core instead of my local snap; it builds fine.
<rharper> how do we debug the install of the os-snap I built (which just added my ppa to pull in an updated cloud-init deb)
<niemeyer> joc_: For udev, I think it'd clearly solve your problem.. I'm wondering if it'd have the intended consequence for other cases as well
<joc_> niemeyer: so that section is called as many times as there are slots
<niemeyer> joc_: and whether we want that in the plug side too
<joc_> niemeyer: what key would you use so that multiple different rules files could be created with their possibly different requests for symlinks? currently appname prevents clashes there
<ogra_> ogra@anubis:~/datengrab/images/snappy$ sudo snap install ubuntu-image_0.5_amd64.snap --devmode
<ogra_> error: cannot find signatures with metadata for snap "ubuntu-image_0.5_amd64.snap"
<ogra_> niemeyer, ^^^
<niemeyer> joc_: Each slot needs a unique name
<ogra_> could we prehaps make --force-dangerous implicit when i use --devmode ?
<ogra_> i already explicitly say i want to do something bad here, so i should not need to additionally say "i'm a bad guy"
<niemeyer> ogra_: Sounds like different things
<niemeyer> ogra_: What
<niemeyer> ogra_: 's missing
<ogra_> well, i turn off all confinement
<niemeyer> ogra_: on that picture is the generation of assertions for your devmode snap
<sergiusens> tedg I am not involved in u-d-f anymore, but I am guessing it failed once and you have leftover mapped loops
<ogra_> so why not also make it implicit set --force-dangerous so i dont need to extra specify it on the commandline
<ogra_> feels like duplication and unnecessary annoyance for developers to me
<niemeyer> joc_: Makes sense?
<joc_> niemeyer: so something like securityTag := snap.AppSecurityTag(snapName, slot.Name)   ?
<niemeyer> ogra_: --force-dangerous ignores checksum errors, ignores the lack of signatures on that snap, etc
<ogra_> right ... which is what i want when installing a local snap
<niemeyer> ogra_: It's turning off confinement for something that is completely unknown vs. turning off confinement for something known
<niemeyer> ogra_: But will discuss that to see what others think
<ogra_> probably it shouldnt be bound to --devmode but to "this snap is local anyway"
<niemeyer> ogra_: No, local snaps is yet another axis on that picture
<niemeyer> ogra_: A snap can be local and be properly signed
<ogra_> oh ?
<ogra_> hwo is that ?
<ogra_> *how
<mhall119> signed by the store, or by the developer?
<ogra_> if i have a local snap it should be considered insecure by default imho
<tedg> sergiusens: I don't see any, but let me reboot to be sure :-)
<niemeyer> mhall119: Either.. more likely both
<niemeyer> ogra_: "local" is not indicative of it being insecure
<ogra_> the only snaps i trust shoudl come from the store ... all others are developer meterial ... IMHO
<ogra_> *materiel
<ogra_> bah
<niemeyer> ogra_: Downloading a snap and installing it with the proper assertinos, or downloading from the store, has the exact same result
 * ogra_ signs up for the anonymous dyslectics
<niemeyer> ogra_: In fact, when you install a local snap, snapd will eventually attempt to get assertions for it
<ogra_> hmm
<niemeyer> It's not about where the data is obtained from, but about whether the data is trusted or not.. assertions give an async way to convey that
<ogra_> well, i'd just like to have something more convenient than an additionall cmdline switch for that usecase
<ogra_> which is  a typical thing ... i develop a snap and first install it locally before it has ever seen the store
<niemeyer> ogra_: Yeah, I get it.. I think we'll have something slightly more subtle than simply have --force-dangerous behavior by default
<ogra_> well, fine with me too :)
<ogra_> i just feel that once we have more bits you need to turn off to test a dev snap you will have a very long commandline with lots of options :)
<jdstrand> morphis: regarding fwupd. I gave my +1 yesterday
<niemeyer> Yep.. we want to solve that without opening the door for eaiser social exploits
<ogra_> right
<niemeyer> ogra_: There's also some subtlety here that indeed we need to account for.. maybe --force-dangerous indeed doesn't protect much compared to --devmode, which means we could make one imply the other as you suggest
<niemeyer> ogra_: Will discuss this with pedronis
<ogra_> thx :)
<niemeyer> joc_: Ok, here is a strawman proposal to get us unblocked:
<jdstrand> ogra_: regarding building kernel snap> thanks. I have two bbbs that I'd like to have run series 16 and will have to figure out something. was hoping for the generic armhf kernel... is that still going to be a thing?
<jdstrand> ogra_: btw, I saw you say you might need me to approve something?
<ogra_> jdstrand, i learned that gadgets go magically through now !
<ogra_> so no, you're not needed ... go on vacation :)
<niemeyer> - If there are interfaces (slots or plugs) and no apps on a given snap, we pretend there's a single app with the snap name, which means a security tag of snap.AppSecurityTag(snap.Name(), snap.Name())
<jdstrand> ogra_: heh, not on vacation today. tomorrow, yes :)
<niemeyer> jdstrand: Just tomorrow?
<niemeyer> jdstrand: Not next week?
<jdstrand> monday is a us holiday so then too
<niemeyer> Ah, ok
<ogra_> jdstrand, the generic armhf kernel wont be an official thing ... but i think mvo will go on maintaining the BBB gadget as "community maintained" so then we'll need a matching kernel that i can set up an auto-build for
<jdstrand> but working tue-fri next week
<niemeyer> jdstrand: Ack, thanks
<jdstrand> mon-thu this week, tue-fri next week
<niemeyer> jdstrand, joc, morphis: we need to sort all of these interfaces today then
<niemeyer> As we'd like to cook a pre-image on Monday
<jdstrand> that was what I was thinking
<niemeyer> joc_, morphis: I think this will sort out the issue
<niemeyer> I mean, this:
<niemeyer> - If there are interfaces (slots or plugs) and no apps on a given snap, we pretend there's a single app with the snap name, which means a security tag of snap.AppSecurityTag(snap.Name(), snap.Name())
<niemeyer> on len(slot.Apps()) == 0 on the slot side, and len(plug.Apps()) on the plug side
<niemeyer> We can do that both for permanent and connected slots, I believe
<joc_> niemeyer: so 4 changes to securitySnippetsForSnap one for each snippet function?
<niemeyer> Yeah, I think so
<morphis> niemeyer: we still need to sort the remaining issue with the udisks interface
<niemeyer> morphis: Indeed.. can we have that ready today?
<niemeyer> morphis: So that jdstrand can review
<morphis> niemeyer: the interface is fine, we the thing we have to solve is the mount propagation in snap-confine
<morphis> s/we the/the/
<jdstrand> niemeyer: so, on my list is serial-port/hidraw (in progres), fwupd (+1 from me, seems ready to merge), udisks2/removable-storage (close). systemd-control was another, but I thought we were going to go for a much simpler 'reboot-control' interface (or whatever it would be named-- I asked in the PR)
<niemeyer> morphis: Okay, let's talk about this in a bit, with mvo
<niemeyer> morphis, mvo: Can we have a call in ~45 mins on this?
<jdstrand> niemeyer: fyi, zyga was the one advising ssweeny on the mount bits for snap-confine for udisks2
<jdstrand> he seemed to know the issue
<niemeyer> zyga is off due to some family needs and I'm not quite sure he'll be back soonish
<niemeyer> So we cannot count on him before we hear more details
<morphis> niemeyer: ok, meeting for that?
<niemeyer> morphis: Yeah
<niemeyer> I'll step out for lunch.. back in a bit
<morphis> niemeyer: ok, need to finish a meeting here
<morphis> ssweeny, jdstrand: ok with a meeting in 30-45 min?
<ssweeny> sure
<jdstrand> sure
<ogra_> mvo, on pi2 http://paste.ubuntu.com/23120588/
<ogra_> image creation worked though ... cloud-init timeout took a little longer than in kvm (more like a 20min boot) ... but no snaps found is worrying
<ogra_> jamiebennett, ^^^ FYI
<mvo> ogra_: woah, nice
<ogra_> otoh cyphermox will be happy to hear that console-conf worked just fine :)
<mvo> ogra_: oh, no snaps found
<mvo> ogra_: sucks
<ogra_> yeah
<mvo> ogra_: could you do snap changes please?
<mvo> ogra_: and systemctl status snapd.firstboot?
<ogra_> ogra@localhost:~$ snap changes
<ogra_> error: no changes found
<ogra_> ogra@localhost:~$
<mvo> oh
<ogra_> ogra@localhost:~$ systemctl status snapd.firstboot
<ogra_> â snapd.firstboot.service - Run snappy firstboot setup
<ogra_>    Loaded: loaded (/lib/systemd/system/snapd.firstboot.service; enabled; vendor preset: enabled)
<ogra_>    Active: failed (Result: exit-code) since Thu 2016-09-01 15:43:20 UTC; 8min ago
 * mvo scratches head harder
<ogra_>   Process: 2584 ExecStart=/usr/bin/snap firstboot (code=exited, status=1/FAILURE)
<ogra_>  Main PID: 2584 (code=exited, status=1/FAILURE)
<ogra_> ogra@localhost:~$
<mvo> ogra_: :( no ouput why it failed
<ogra_> well, it resulted in an exit code :P
<ogra_> (the most silly error message of all)
<mup> PR snapd#1825 opened: interfaces: snippet creation for snaps without apps <Created by jocave> <https://github.com/snapcore/snapd/pull/1825>
<mvo> ogra_: do you have "error need a model assertion"?
<ogra_> ogra@localhost:~$ ls /var/lib/snapd/snaps/
<ogra_> pi2-kernel_11.snap  ubuntu-core_414.snap
<ogra_> i dont have a gadget snap !
<mvo> ogra_: you have, just under seed/snaps
<ogra_> mvo, where would i find that ?
<ogra_> (tghe model assertion error)
<joc_> niemeyer: let me know if PR snapd#1825 matches expectation
<mup> PR snapd#1825: interfaces: snippet creation for snaps without apps <Created by jocave> <https://github.com/snapcore/snapd/pull/1825>
<cyphermox> mvo: I have some issues with the assertions for ubuntu-image?
<ogra_> ogra@localhost:~$ sudo journalctl |grep model
<ogra_> Sep 01 15:43:09 localhost.localdomain kernel: Machine model: Raspberry Pi 2 Model B Rev 1.1
<ogra_> Sep 01 15:43:20 localhost.localdomain snap[2584]: error: need a model assertion
<ogra_> mvo, ^^^
<ogra_> cyphermox, http://people.canonical.com/~ogra/snappy/amd64-generic-model.assertion use that one
<mvo> ogra_: yeah, I think this is it
<cyphermox> first it complained about a sign-key, and now about the gadget.yaml
<ogra_> cyphermox, tseves is porked
<ogra_> *steves
<ogra_> *borked
<ogra_> mvo, asny hit how to fix it ?
<ogra_> *any
<ogra_> (my god ... typing is hard today)
<ogra_> mvo, http://people.canonical.com/~ogra/snappy/pi2-model.assertion is what i used
<cyphermox> ogra_: Steve's isn't missing 'core', 'class' and 'store' ;)
<ogra_> cyphermox, yes, these are the keys that break everything :)
<cyphermox> COMMAND FAILED: snap prepare-image  /home/mtrudel/TÃ©lÃ©chargements/amd64-generic-model.assertion.1 /tmp/tmpol1xbe71/unpackerror: cannot decode model assertion "/home/mtrudel/TÃ©lÃ©chargements/amd64-generic-model.assertion.1": assertion model: "class" header is mandatory
<ogra_> uuuh
<ogra_> works for me
<cyphermox> I'm using the code from master
<ogra_> using the latest ubuntu-image rolled as snap
<ogra_> http://people.canonical.com/~ogra/snappy/ubuntu-image_0.5_amd64.snap
<jdstrand> morphis: so, I really think zyga should be in that meeting if it is about how to fix snap-confine. otherise, I'm not prepared to speak to the fix (I would have to come up to spead on the problem, etc)
<ogra_> cyphermox, ah, i built it from mvo's PR
<cyphermox> nah, I'm trying to work on the git code; to modify ubuntu-image ;)
<ogra_> there might be more fixes than just the snapcraft.yaml
<morphis> jdstrand: zyga is out
<mvo> cyphermox: that PR keeps growing fixes
<mvo> just saying
<morphis> jdstrand: that is why I invited you, or is there anyone else who can speak to mount namespace issues?
<ogra_> cyphermox, well, i thought it was master with snapcraft.yaml added ... seems there are more fixes
<mvo> ogra_: yes, almost ready to use it for our image tests
<cyphermox> mvo: oh, is that already ready to be merged?
<ogra_> cyphermox, https://github.com/mvo5/ubuntu-image
<ogra_> there os a PR
<ogra_> *is
<mup> PR snapd#1808 closed: many: add snap set and snap get commands <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1808>
<jdstrand> morphis: well, there is no one that knows *this* issue. zyga knew the specific problem. tyhicks or I can look into it, but aiui this was a code ordering thing
<mvo> cyphermox: definitely for a review, I plan to make more noise once I get a successful image test in our infrastructure
<ogra_> cyphermox, https://github.com/CanonicalLtd/ubuntu-image/pull/46
<mup> PR CanonicalLtd/ubuntu-image#46: add snapcraft.yaml & --extra-snaps <Created by mvo5> <https://github.com/CanonicalLtd/ubuntu-image/pull/46>
<mvo> cyphermox: but some of the bugs I reported are fixed there
<morphis> jdstrand: yeah, then lets take this as briefing session for you guys, is that ok?
<jdstrand> morphis: but the point is, neither one of us is ready to comment on the fix cause we haven't studied the issue
<cyphermox> mvo: none of that looks like it would help in finding a gadget.yaml though :/
<jdstrand> tyhicks: are you able to meet in 10 minutes?
<ogra_> mvo, so for the pi, is there anything i can fix in my model assertion ?
<ogra_> or do i need to wait for your side
<jdstrand> tyhicks: I can give you some context before (what little I have)
<morphis> jdstrand: yeah I see, I am sorry for that but from somewhere we need to get help for ssweeny on this
<ogra_> cyphermox, well, i just built a kvm image 5 min ago here and it worked fine
<mvo> cyphermox: finding a gadget yaml? you mean ogras bug? or something else. sorry, a bit confused
<ogra_> (apart from the known cloud-init issue)
<cyphermox> let's back up for a second
<cyphermox> what version of ubuntu-image is currently snapped up?
<jdstrand> morphis: no I get that. I just want you to know we are as far along on diagnosing/suggesting a fix as yourself :) I think one of us could look at it, but we need time. a briefing meeting is fine
<mvo> cyphermox: my branch
<ogra_> cyphermox, https://github.com/mvo5/ubuntu-image
<morphis> jdstrand: thanks!!
<ogra_> snap is at http://people.canonical.com/~ogra/snappy/ubuntu-image_0.5_amd64.snap
<ogra_> using the model assertion from http://people.canonical.com/~ogra/snappy/amd64-generic-model.assertion gets me a working kvm image
<cyphermox> huh, it works there
<cyphermox> oh well, I won't pretend I know how all this works yet ;)
<ogra_> just merge mvo's PR and we're all good :)
<mvo> cyphermox: heh, do not merge just yet, lets wait for slangasek or barry first
<ogra_> mvo, so next week ?
<ogra_> they are off
<cyphermox> mvo: yeah, I know
<mvo> ogra_: is steve off today
<ogra_> i thought til monday ?
<cyphermox> I wasn't going to merge, but I'm forking my own branch to merge in yours + my changes
<cyphermox> barry should be around tomorrow to do the mergings
<ogra_> mvo, "I'm on vacation Thursday through Monday, returning Tuesday. "
<jdstrand> niemeyer: how important is docker interface for monday? I ask but I suspect there is no way that will be ready due to another snap-confine issue that needs zyga (the pivot_root lxd bug)
<tyhicks> jdstrand, morphis: I can meet in a few minutes but have a hard stop for another meeting at the half hour
<lazyPower> jdstrand - thanks for driving that conversation forward. i've been tracking it
<ogra_> mvo, well, anything i can do for the pi2 ? while we wait for merges ...
<jdstrand> tyhicks: it is briefing meeting only. let's join this second so you and I can coordinate
<mvo> ogra_: not sure, I think not, sucks a bit
<ogra_> quite, yeah
<mvo> ogra_: we will have real signed assertions for themodel
<jdstrand> tyhicks: if you can
<ogra_> but why ddoes it work with the fake amd64 one
<tyhicks> jdstrand: ack
<ogra_> i dont get that
<cyphermox> ogra_: what do you need merges for? just mvo's PR?
<ogra_> cyphermox, well, that is what is working currently
<ogra_> so yeah, i havent used more than that
<mvo> ogra_: not sure, need to look
<ogra_> k
<cyphermox> anything else needs fixed in ubuntu-image?
<ogra_> only the bugs :)
 * ogra_ just filed bug 1619362
<mup> Bug #1619362: images should not be largely bigger than the actual content <Ubuntu Image:New> <https://launchpad.net/bugs/1619362>
<ogra_> i'm really tired of 20min dd runs ;)
<morphis> niemeyer: joining us?
<mvo> ogra_: fixed in my branch
<ogra_> mvo, the size thing ?
<mvo> ogra_: yes, I create a sparse file, so it looks big but is not
<ogra_> nooo
<ogra_> dd will still write zeros
<ogra_> cxant we just check the size of the snaps, add a certain wiggle room and be fine ?
<mvo> ogra_: it will be exactly the same as with u-d-f, or was u-d-f not fine?
<ogra_> no
<ogra_> udf was a pain too
<ogra_> the pi2 image can be 200MB
<mvo> ogra_: fair enough
<ogra_> that takes 30sec with dd
<ogra_> since we resize on first boot anyway the img doesnt need to be bigger than the actual content
<ogra_> also releasing images is a pain if you have so many zeros to xz :)
<ogra_> you know that
<morphis> tyhicks: thanks!!
<tyhicks> np!
<cyphermox> mvo: ogra_: even with that PR (things look a little bit better) it still fails to find gadget.yaml
<cyphermox> http://paste.ubuntu.com/23120867/
<mvo> cyphermox: what is the full output? do you use --channel edge?
<cyphermox> I did not set --channel
<mvo> cyphermox: that should help
<cyphermox> right, it's just not very discoverable ;)
<cyphermox> yup, that works, finally
<cyphermox> thanks!
<ogra_> well, once the gadget is in stable you wont need it anymore :)
<cyphermox> right
<cyphermox> well, now to test the crack I just added :)
<ogra_> :D
<cyphermox> Q'apla!
<mup> PR snapd#1804 closed: tests: use the spread tests with the adhoc interface inside autopkgtest <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1804>
<mup> PR snapd#1812 closed:  image,overlord/boot,snap: metadata from asserts for image snaps <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1812>
<joc_> jdstrand: note that i just push a couple of commits that change the allowed symlink path on serial-port
<jdstrand> ack
<cyphermox> ogra_: mvo: https://github.com/CanonicalLtd/ubuntu-image/pull/47
<mup> PR CanonicalLtd/ubuntu-image#47: Preseed cloud-init and allow further preseeding when building the image <Created by cyphermox> <https://github.com/CanonicalLtd/ubuntu-image/pull/47>
<ogra_> cyphermox, hmm, but that requires the user to have a local cloud-init config, no ?
<ogra_> ahm no, i see you write defaults
<ogra_> ignore that :)
<mvo> ogra_: could you trigger a ubuntu-core build once snapd 2.14.2 is published in the PPA? that would be super nice, the resulting core-snap will become the new candidate snap
<mvo> cyphermox: I think we want something like --cloud-init-file some-file too so that we can create images that are actually useful in the cloud, but that is for later
<ogra_> mvo, no prob
<cyphermox> ogra_: are there any fixes needed to console-conf?
<ogra_> mvo, oh ... i3386 FTBFS
<cyphermox> (asking if anything transpired last night while I was away)
<ogra_> cyphermox, not sure yet ... sabdfl_ said in my bug that a special assertion should create local users for offline devices (no idea how that will work and it sounds really complex for someone doing a port and initial device bringup etc) ... in that light it seems console-conf is fine for the moment
<niemeyer> ogra_: next week devmode will get over dangerous as you suggested
<cyphermox> ok
<sabdfl_> yeah yeah
 * ogra_ hugs niemeyer 
<cyphermox> well, --cloud-init will let you create an offline user
<ogra_> oh, right ...
<cyphermox> then I will also add back the local-user magic in console-conf
<ogra_> now that we can just inject config ...
<sabdfl_> the basic guidance is that "all snap users are associated with the private or public store that the device is getting updates and apps from"
<cyphermox> well, injecting config is nice, but it's not proper experience for a random appliance someone would buy
<sabdfl_> if you are offline, then the way to do that is to have an assertion from that store saying "user joe has these ssh keys"
<mvo> ogra_: yeah, super confusing
<cyphermox> hrm
<ogra_> FAIL
<ogra_> FAIL	github.com/snapcore/snapd/overlord/state	0.385s
<ogra_> === RUN   Test
<ogra_> seems it faisl this test
<sabdfl_> cyphermox here's the experience as I would like it
<ogra_> *fails
<sabdfl_>  - you go to your web-based management system ("my.ubuntu.com" or a corporate equivalent)
<sabdfl_>  - you get a text file on a USB key
<sabdfl_>  - you stick that USB key into your appliance
<sabdfl_>  - it is now securely registered to your account
<sabdfl_> that's pretty friendly
<cyphermox> that covers what I was going to ask: "sabdfl_: I'm just not clear on how an offline system would get the information for user joe?"
<sabdfl_> it's in that text file
<cyphermox> yup
<sabdfl_> it's signed (an "assertion" is a signed piece of text)
<sabdfl_> et voila
<sabdfl_> ogra is just being difficult :p
<cyphermox> I suppose all these should be parsed by snapd, not by console-conf; and rather get console-conf to be skipped, perhaps
<ogra_> sabdfl_, nah, i'm lazy :)
<sabdfl_> old-fashioned :p
<ogra_> heh
<sabdfl_> in a good way!
<sabdfl_> we are building on fine traditions ;)
<cyphermox> sabdfl_: so should we have a method to create a user manually in console-conf; aside from the 'enter your email' form?
<ogra_> sabdfl_, though a way to inject that assertion during ubuntu-image run would be nice so i dont need additional HW when i roll my own offline rpi image
<sabdfl_> console-conf is a console front-end to this experience
<sabdfl_> cloud-init is a metadata front-end
<sabdfl_> both of them can essentially steer the process
<sabdfl_> one is for humans on a console
<sabdfl_> the other is for orchestrators spinning stuff up remotely in clouds
<sabdfl_> but yes, snapd is the steward of device state, so ultimately both of those pathways drive things through snapd
<ogra_> hmm, but cloud-init can currently completely circumvent the assertion process ... if i tell it to add a local user it will do so ... sounds like we should block that
<sabdfl_> the base *primitive* for users is "dear snapd please create a user on this device associated with such-and-such a user in such-and-such a store"
<sabdfl_> ogra_, possibly, yes
<sabdfl_> we have to understand the gray area of classic, too, where you have both snap-friendly users and legacy UNIX-only users
<cyphermox> ogra_: sound like we should make sure you can specify the store credentials for a user cloud-init would create.
<ogra_> cyphermox, right ... and find out how to block the standard adduser cloud-init does
<ogra_> else you could just randomly abuse that
<ogra_> the prob now is ... we dont have that magic assertion creator yet ... even console-conf just downloads the ssh key from LP without further stuff
<cyphermox> sabdfl_: I guess what I'm asking is if we should have the UI to create UNIX-only users in console-conf at all, or if the current behavior of using the email address is all we want.
<ogra_> cyphermox, no
<ogra_> it is either "you are online" -> console-conf ... or "you are offline" -> provide an assertion via cloud-init
<cyphermox> ok, so only "preseeding" via store assertions or
<cyphermox> skip the 'or' there.
<ogra_> right ...
<ogra_> but we dont have that store side bit yet ... so only online devices for now i guess
<cyphermox> ok, in that case we'll want these assertions to be able to tell snapd that console-conf has run.
<ogra_> we should probably have an "ubuntu" user assertion for now and make that publically available until the sotre can generate real ones :)
<ogra_> *store
<ogra_> i.e. some fake placeholder so people with offline devices dont get blocked in their development
<cyphermox> who will be doing that?
<ogra_> no idea
<ogra_> i yet have to understamd assertions properly :)
<ogra_> (only slowly understanding the machine part of it since today)
<ogra_> cyphermox, i guess the core team together with the stroe team should be able to provide us something
<ogra_> mvo, should i just retry the i386 build ?
<ogra_> seems amd64 passed the test
 * ogra_ just tries 
<ogra_> mvo, i386 retry worked
<ogra_> weird ...
<jdstrand> zyga: please ignore my irc highlights from earlier today
<joc_> jdstrand: thanks for reviews, i think i have addressed all comments (including ones just made), i'm going to start copying this over to a hidraw interface
<mup> PR snapd#1819 closed: snap: set user variables even if HOME is unset (like with systemd services) <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1819>
<slangasek> mvo: "create local users via console-conf" - that's contrary to the design we've been given; can we please discuss that on the list?  If you are mastering an image and want a local user created, that should be via cloud-init preseeding and not via console-conf
<cyphermox> slangasek: we've already reached that conclusion, I think.
<slangasek> mvo: so, please explain where you're seeing non-sparse images
<slangasek> cyphermox: ok ;)
<cyphermox> also, what are you doing here?
<cyphermox> ;)
<jdstrand> joc_: I made a comment on your most recent commit
<joc_> jdstrand: i think what you are asking for is there, just not in an else block
<jdstrand> mvo (cc ogra_): is it known that on all snaps images the ip address keeps incrementing? I think netplan isn't sending the dhclient hostname or something so the dhcp server isn't reusing the ip for the mac. I didn't investigate, just a hunch
<jdstrand> joc_: oh, maybe I read to fast
 * jdstrand rereads
<jdstrand> joc_: yeah, sorry, you're right. thanks!
 * jdstrand deleted the comment
<joc_> np
<ogra_> jdstrand, doesnt happen for me on pi2, pi3 or dragonboard ... where do you see that ?
<jdstrand> ogra_: amd64 vm
<jdstrand> ogra_: that I generated yesterday
<ogra_> ah, something i rarely use
<jdstrand> note, this is with libvirt's dnsmasq. that is a configuration that worked in earlier series 16, which is why I thought of netplan
<jdstrand> anyway, I can't focus on that right now, but thought I'd mention it
<ogra_> yeah, could be ... talk to pitti or mwhudson then ...
<ogra_> i assume you went through the console-conf stuff to actually have the setup ready ?
<mvo> jdstrand: aha, thank you - I think the righ people for a question like why netplan keeps increating the ips is pitti or mwhudson, your idea about the missing hostname makes sense
<ogra_> ooooh !
<ogra_> the arm builders finally made their mind up
<jdstrand> ogra_: I did go through console-conf. fyi, static ip address didn't seem to work at all (always got incrementing dhcp)
<ogra_> yeah, that sounds like either console-conf or netplan
<ogra_> ststic should surely work too
<jdstrand> pitti, mwhudson: ^ fyi (also, I can't debug this right now. easy to see with this image: sudo /snap/bin/ubuntu-device-flash core --size=8 --enable-ssh --channel=edge --output=snappy-20160831-amd64.img --gadget pc --kernel pc-kernel --os ubuntu-core 16
<jdstrand> pitti, mwhudson: I saw it after importing that image into libvirt, but bet it would happen with any dnsmasq dhcp server (or possibly isc)
<cyphermox> jdstrand: do you mean you configured static and don't get a static IP?
<elopio> you are not funny ogra_
 * ogra_ hugs elopio 
<elopio> :)
<ogra_> :)
<cyphermox> because otherwise I wouldn't be surprised if the leases for DHCP were all wrong
<jdstrand> cyphermox:yes. after I saw the incrementing dhcp ip I tried to workaround by setting static ip
<jdstrand> cyphermox: and that didn't work
<cyphermox> interesting
<cyphermox> I'll give it a shot here
<ogra_> --size 8 .... how excessive
<jdstrand> ogra_: not really-- I'm helping with docker interface :)
<ogra_> heh, k ... thats explains a lot :)
<jdstrand> though not this second. now I'm working on udisks/snap-confine
<jdstrand> ssweeny: fyi, I left a note in your snap-confine fork but that isn't for you to do anything at this time. just now starting to look and will sync when I have more info
<ssweeny> jdstrand, sounds good. I'll have to step out around 3-4PM EDT but I'll be back later in the afternoon
<ogra_> mvo, sigh, who is that overlord guy ... arm64 FTBFS in the same test ... retrying
<jdstrand> ssweeny: can you make the udisks2 snap available?
<cyphermox> jdstrand: ok, the IP issue is a bug that is fixed, just need a newer nplan / console-conf I think
<cyphermox> I'm double-checking
<jdstrand> that's great! :)
<ogra_> mvo, and arm64 built too ... this overlord is an evil overlord for sure :P
<cyphermox> jdstrand:  ah, not fixed, but we did run into the same issue once before, it needs to be changed again :/
 * ogra_ waits for the publisher now
<mup> Bug #1619420 opened: snappy removal of dpkg-query breaks lsb_release --all <Snappy:New> <https://launchpad.net/bugs/1619420>
<mup> Bug #1619423 opened: snappy does not include ssh-import-id preventing cloud-init user-data from importing ssh-keys <Snappy:New> <https://launchpad.net/bugs/1619423>
<sabdfl> ogra_, cyphermox, assertions are coming along, latest snapd added a few, user ones will be there in good time, i would not worry too much
<sabdfl> for the current image test and dev just.... be online ;)
<ahoneybun> this : http://snapcraft.io/docs/reference/snapcraft links to this : https://linuxcontainers.org/lxd/getting-started-cli/
<ahoneybun> when talking about cleanbuild but there is no âUbuntu Desktop and Ubuntu Serverâ section on that page
<cyphermox> sabdfl: great, I'm glad people are happy so far with console-conf and all :)
<mup> PR snapd#1825 closed: interfaces: snippet creation for snaps without apps <Created by jocave> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1825>
<SamYaple> sergiusens: hey. question for you. what is the reason of _get_python2_include and why does python3 not also need that?
<SamYaple> im unifying the two plugins and just coming across some inconsistencies
<sergiusens> SamYaple hey
<sergiusens> SamYaple non, but look https://github.com/snapcore/snapcraft/pull/771
<mup> PR snapcraft#771: Python plugin improvements <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/771>
<SamYaple> oh..
<cyphermox> mvo: where is ubuntu-device-flash source? could it be writing a netplan config?
<ogra_> ARGH
<SamYaple> sergiusens: cool. looks good. i just switched jobs so ive been a bit busy :)
<ogra_> so console-conf breaks the classic mode
<mup> PR snapd#1826 opened: interfaces: add interface for hidraw devices <Created by jocave> <https://github.com/snapcore/snapd/pull/1826>
<SamYaple> sergiusens: ill let you handle that then and ill work on some other python improvements that ive had in mind then
<joc_> jdstrand: hidraw PR opened ^ should be fairly familiar
<ogra_> hmm ...
<ogra_> ogra@dragonboard:~$ sudo classic
<ogra_> sudo: unknown user: ogra
<ogra_> sudo: unable to initialize policy plugin
<ogra_> ogra@dragonboard:~$ sudo -u ubuntu -i
<ogra_> ubuntu@dragonboard:~$ sudo classic
<ogra_> (classic)ubuntu@dragonboard:~$
<ogra_> fun
<sergiusens> SamYaple yeah, I took a completely different approach and a lot happier with it; a much needed improvement over the older python plugins
<sergiusens> SamYaple I would like to know if you can run it through any test subjects you might have or point me to them
<ogra_> cyphermox, for some reason the sudo user that console-conf created is different
<SamYaple> sergiusens: agree. much nicer. like the unified approach too. wasnt looking forward to duping work to add python features
<SamYaple> sergiusens: i will start using it locally, but i don't have any projects or test suites around snappy yet. still working on a POC for openstack
<sergiusens> SamYaple sounds good!
<mup> PR snapd#1827 opened: #1802 + #1823 <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1827>
<sergiusens> josepht seems the parser tests are leaving the /tmp dirs behind. Mind adding a cleanup task for that?
<sergiusens> I guess elopio could help
<josepht> sergiusens: sure, file a bug :)
<elopio> oh, just use the tmp dir fixture.
<sergiusens> josepht trololol
<cyphermox> ogra_: groups, I bet
<cyphermox> there's nothing I can really do about that, we just use snap create-user to create the user (but I'll double-check)
<cyphermox> result = run_command(["snap", "create-user", "--sudoer", "--json", self.email.value])
<cyphermox> let's see, self.email.value contains...
<cyphermox> doh, reading it the wrong way around
<cyphermox> self.email.value is obviously just an email address, and we expect a result in json format from snap
<ogra_> cyphermox, yeah, that wont work ... the user needs to be in adm and sudoers
<ogra_> ogra@dragonboard:~$ groups
<ogra_> ogra
<ogra_> else he cant even open logfiles
<cyphermox> so somethign to fix in snap create-user I guess
<ogra_> oh CRAP !
<ogra_> no, that wont work at all
<ogra_> the sudo group lives in the readonly /etc/groups
<ogra_> and i doubt sudo gets along with moving that to extrausers
<cyphermox> why is that an issue?
<cyphermox> sudo works fine on the system
<josepht> sergiusens: where can the name and version variables be used? in the wiki and in the part?  Or just one or the other?
<ogra_> because you cant write to it ?
<ogra_> well, not when i try to spawn a classic chroot
<ogra_> as you can see above
<cyphermox> I don't disagree that something is wrong, I'm just saying it's not the fact that the user is in sudo group or not
<cyphermox> classic might not know about extrausers?
<josepht> sergiusens: I guess either way I can just do the substitution on the parsed part to cover both bases.
<ogra_> i thought it gets bindmounted
<cyphermox> will outside the chroot maybe
<ogra_> yeah,, it doesnt ...
<sergiusens> josepht in the snapcraft.yaml
<ogra_> i guess i should bind mount it then
<ogra_> sigh
<sergiusens> josepht only
<josepht> sergiusens: ack
<ogra_> (classic)ubuntu@dragonboard:~$ cat /var/lib/extrausers/passwd
<ogra_> ubuntu:x:1000:1000:ubuntu,,,:/home/ubuntu:/bin/bash
<ogra_> (classic)ubuntu@dragonboard:~$
<sergiusens> stokachu hey, would you mind looking at this https://github.com/snapcore/snapcraft/pull/771/files I built conjure-up successfuly after changing a tinsy thing in the `snap` entry s|/usr/bin/conjure-up|bin/conjure-up|
<mup> PR snapcraft#771: Python plugin improvements <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/771>
<ogra_> cyphermox, ^^
<ogra_> so extrausers is there
<ogra_> but does not contain added users
<sergiusens> stokachu I really hope that is ok and not have to support the backwards compatible dist-packages anymore.
<cyphermox> I have no idea what to tell you; my understanding of classic is that it extracts a tarball, that must furthermore include any users created outside that tarball
<stokachu> sergiusens, so does this not use requirements.txt any longer?
<cyphermox> it's really as simple as extrausers, we don't do anything special to create the user in console-conf
<stokachu> sergiusens, looks ok to me
<ogra_> ogra@dragonboard:~$ sudo cp /var/lib/extrausers/* /var/snap/classic/common/classic/var/lib/extrausers/
<ogra_> ogra@dragonboard:~$ sudo classic
<ogra_> (classic)ogra@dragonboard:~$
<ogra_> cyphermox, theer we go
<ogra_> i'll fix the classic wrapper to copy it every time you invoke the classic shell
<cyphermox> ok
<SamYaple> sergiusens: when do you think that python plugin will be done? i dont want to make you rebase but i need to change teh constraints part around a bit
<SamYaple> sergiusens: also, it builds everything i need it to so far :) good job
<sergiusens> SamYaple good to hear
<sergiusens> SamYaple somewhere around today/tomorrow most likely
<SamYaple> oh yea. perfect.
<sergiusens> cprov did grade make it to the store review?
<ogra_> mvo, ok, finally all snapd package built ... ubuntu-core build running ...
<ogra_> *packages
<cprov> sergiusens: yes, in production.
<SamYaple> the constraints should also accept a url, so i just need to adjust how it processes the option
<mvo> ogra_: cool! thats will be the new candidate snaps for core :)
<ogra_> yay
<ogra_> mvo, note that the store UI is borked regarding channels (you cant open the list of uploads)
<ogra_> so it might be a bit tricky to get that moving through the channels
<ssweeny> jdstrand, hey sorry for the delay. Do you need an armhf or amd64 snap?
<ogra_> mvo, ad classic will need a fix ... i'll prepare a Pr for tomorrow
<ogra_> *and
<Birchy> Can you do unionfs with Snappy?
<Birchy> I'm thinking of a fancy system for Wine
<ogra_> Birchy, well, there is a fuse interface ... so a fuse-unionfs might be possible
<ogra_> but that will crawl indeed
<mvo> ogra_: uh, ok
<Birchy> ogra_, just how slow?
<ogra_> you have to try ... i know it wasnt really usable when we tried it for livecds several years ago
<SamYaple> sergiusens: youll be happy to know your python plugin also fixes an issue with some python package installs (try installing uwsgi python package with the python2 plugin)
<SamYaple> sergiusens: so you are fixing bugs you didnt know about with just overall better code
<mup> Bug #1619455 opened: classic does not work with connsole-conf created user <Snappy:New> <https://launchpad.net/bugs/1619455>
<sergiusens> SamYaple good to know, I knew I'd be fixing bugs along the way and just switched to use pip for everything
<sergiusens> SamYaple stage-packages from python are also taken into account when calculating deps (that was a peeve of mine)
<SamYaple> sergiusens: yea i saw that. awesome! very happy youve had the time for this. i have not
<mup> PR snapd#1828 opened: cmd/snap,client: add snap set and snap get commands <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1828>
<sergiusens> SamYaple it is my job and this was long overdue so I gave it priority ;-)
<SamYaple> sergiusens: yea this is my free time stuff, so slightly different. still glad for your help here
<sergiusens> SamYaple the pleasure is mine
<mup> PR snapd#1829 opened: interfaces: fix interface handling on no-app snaps <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1829>
<mup> PR snapcraft#773 opened: parser - Handle project name and version variables <Created by josepht> <https://github.com/snapcore/snapcraft/pull/773>
<niemeyer> jdstrand: snapd#1829 contains that idea we discussed
<mup> PR snapd#1829: interfaces: fix interface handling on no-app snaps <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1829>
<niemeyer> jdstrand: Evolved a bit since then
<niemeyer> jdstrand: Less hackish now
<awe> can anyone help me with a signatures error when trying to sideload a snap on my rpi2 running latest core?
<awe> I get the same error with and without --devmode ( which I didn't think would help )
<awe> error: cannot find signatures with metadata for snap
<awe> snap was built by lp earlier today
<pedronis> awe: yea, that's not released/announced but snap install -h mentiones --force-dangerous (it's going to change again and devmode will imply it but as master stands it's like that)
<awe> thanks pedronis; I see that now when running 'snap install --help' on my rpi.  I initially checked on my desktop, and I guess I need to update there
<awe> ;)-
<awe> and that works
<awe> cool
<pedronis> awe: it's a follow up for locally installing snaps for the fact that since 2.13 we are verifying assertions/signatures when we install from the store
<awe> got it
<pedronis> flags will change a bit again (likely already tomorrow --devmode will sort of imply it , and will be just --dangerous)
<awe> it'd be nice if there was a shortened paramater ( eg. -f ), as --force-dangerous is a mouthful, and bash completion doesn't work on the rpi
<awe> ah, cool
 * awe likes --dangerous
<mup> PR snapd#1830 opened: firstboot: only configure en* interfaces by default <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1830>
<jdstrand> niemeyer, ssweeny: status update: the snap-confine changes for udisks2 are not done. tyhicks and I are investigating. there will not be a patch for snap-confine today. that should not block udisk2 merge and Monday's image (but this is a bug we need to fix and are looking at it with priority)
<niemeyer> jdstrand: Okay, let's please aim at having this fixed on Tuesday the latest, as it's a bug worth fixing for RTM
<jdstrand> niemeyer: that is the goal
<niemeyer> jdstrand: Thanks for looking into this on short notice
<niemeyer> cc tyhicks
<jdstrand> it's unfortunately a bit thornier than we expected
<ssweeny> jdstrand, thanks for the update
<mup> PR snapd#1829 closed: interfaces: fix interface handling on no-app snaps <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1829>
<antipsychiatry> A
<antipsychiatry> N
<antipsychiatry> T
<antipsychiatry> I
<antipsychiatry> P
<antipsychiatry> S
<antipsychiatry> Y
<antipsychiatry> C
<antipsychiatry> H
<antipsychiatry> I
<antipsychiatry> A
<antipsychiatry> T
<antipsychiatry> R
<antipsychiatry> Y
<antipsychiatry> .
<antipsychiatry> O
<antipsychiatry> R
<antipsychiatry> G
<mwhudson> hey so https://launchpad.net/ubuntu/+source/golang-github-coreos-pkg needs to be MIRed as it's now a dep of golang-github-coreos-go-systemd
<mwhudson> so can the snappy-dev team subscribe to bugs?
<mwhudson> hm that needs mvo asac or slangasek, all not here
<wililupy> HA! I finally figured out why my custom images were not coming up showing the three basic snaps installed....
<wililupy> My kernel snaps were being built with confinement: devmode. I switch it to strict and now I get the kernel snap, the gadget snap and the os snap.
<mwhudson> hm is there a good document on assertions?
<mwhudson> i've read a spec ages ago, but i wonder if details have changed
#snappy 2016-09-02
<niemeyer> mwhudson: Heya
<mwhudson> niemeyer: hi
<niemeyer> mwhudson: We have very good coverage on assertions on the system design doc
<mwhudson> ah yes, i've seen that i think
<niemeyer> mwhudson: Do you have a moment to chat about the upcoming image?
<mwhudson> niemeyer: it's been kept up to date as the implementation has happened?
<mwhudson> niemeyer: sure
<niemeyer> mwhudson: Yeah, I think it's quite precise stlil
<mwhudson> cool, i shall re-read it then
<niemeyer> mwhudson: There might be a couple of minor assertions missing there, but otherwise it's good
<mwhudson> niemeyer: chat here or some kind of voip?
<niemeyer> mwhudson: We'd like to finish our pending activities for RTM by EOD tomorrow, so that we can cook a candidate image by Monday
<niemeyer> mwhudson: Here is fine to start, we can jump on a call if we need more bandwidth
<niemeyer> mwhudson: So I'd like to sync with you regarding open points on your end
<mwhudson> niemeyer: that would be great, i've been feeling a bit disconnected
<mwhudson> well not disconnected, just a bit unsure of some things
<niemeyer> mwhudson: Yeah, the usual problem of living on different sides of the world
<mwhudson> that and coming in late to a fast moving project :)
<niemeyer> mwhudson: We've had a few network-related branches landing recently
<mwhudson> yes
<niemeyer> mwhudson: INdeed
<niemeyer> mwhudson: I've been very far from that work, so I'm not sure what your plans for it are
<niemeyer> mwhudson: is it working already?
<mwhudson> niemeyer: more or less, it works fine in kvm
<mwhudson> niemeyer: the ui does not let you configure wlan interfaces, but if you inject an ifupdown config to make that work, it shouldn't get in the way
<niemeyer> mwhudson: Cool, that's a start
<niemeyer> mwhudson: How do you mean? wlan feels like the basic stuff
<mwhudson> niemeyer: netplan only just gained support for wlan, and we haven't written the ui yet
<mwhudson> niemeyer: nothing fundamental, just lack of time
<niemeyer> mwhudson: Ok.. hmm
<niemeyer> mwhudson: So is there anything pending that we need to do today to have a proper image on Monday?
<mwhudson> i can hack like crazy and see what i can get done in the 3 hours of work i have left in the week ...
<mwhudson> niemeyer: not that i am aware of
<mwhudson> niemeyer: on the networking side
<mwhudson> niemeyer: on the user side, there was some confusion about whether cloud-init should accept the traditional cloud-init syntax for creating users
<niemeyer> mwhudson: Something you'd like to be tested during the next month as we put those images to run
<niemeyer> mwhudson: Yeah, I've seen the bug  #
<mwhudson> niemeyer: sorry, is that a question?
<niemeyer> mwhudson: Yeah, sorry, it was part of the previous one
<mwhudson> the biggest open bits are around user management but that's not happening for RTM aiui
<niemeyer> mwhudson: re. the cloud-init feature, I'm not sure.. one alternative would be to teach it to talk to snapd and call create-user
<niemeyer> mwhudson: Yeah, there's an open point I noted down today for GA.. we still need to associated the system user created with a snapd user
<mwhudson> niemeyer: well it should likely be able to do that, sure, but that's not what i meant by "accept the traditional cloud-init syntax for creating users"
<niemeyer> mwhudson: Ah?
<mwhudson> which is username/password/ssh key, not email for use with sso
<mwhudson> niemeyer: yes, snapd user tied to system user and some way for console-conf to tell that this has happened
<niemeyer> mwhudson: Ideally we'd also put that under the same system
<niemeyer> mwhudson: So we have a single path to create ubuntu core users, and the outcome is always the same
<niemeyer> (owner semantics, credentials for snapd, etc)
<mwhudson> niemeyer: that certainly makes sense
<niemeyer> mwhudson: Cool.. so for RTM, if you have any critical changes you'd like to see tested in the candidate image, today or your Monday should be fine, and we'll try to get the changes in on time
<niemeyer> mwhudson: Post RTM, let's nail down networking and those credentials/ownership details
<mwhudson> niemeyer: ack. how should i provide any such fixes? upload to ppa:canonical-foundations/ubuntu-image and email canonical-snapcraft@ ?
<niemeyer> Yeah, or push a PR to snapd, if that's the case
<niemeyer> mwhudson: ^
<mwhudson> niemeyer: talking of which! https://github.com/snapcore/snapd/pull/1830
<mup> PR snapd#1830: firstboot: only configure en* interfaces by default <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1830>
<niemeyer> mwhudson: LGTM
<niemeyer> mwhudson: As a minor, would be nice to fix indentation on this file
<niemeyer> mwhudson: I'd suggest 4 spaces consistently
<niemeyer> mwhudson: one space makes a bit too hard on the eye
<niemeyer> mwhudson: and the first level is using 2
<mwhudson> niemeyer: fair enough, fixing
<niemeyer> mwhudson: Much nicer, thank you
<mwhudson> ah haha can i customize the kernel command line of a snappy image?
<mwhudson> /etc/default/grub is read only...
<mup> PR # closed: snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652
<justinmcp_> where can I read about assertions?
<lpotter> hmm.. I think the qmake snapcraft plugin should include g++ build package
<lpotter> oh man, cleanbuild can be painful
<mvo> pitti: good morning! latest yakkety adt in snapd is failing because it runs out of diskspace (the container). is that a known issue? http://autopkgtest.ubuntu.com/browse.cgi/packages/s/snapd/yakkety/amd64
<mvo> pitti: and one more question - the new autopkgtest tests we have are based on spread. this is a little bit unusual as it usually drives the testsuite over ssh on a different host, for adt I point the test simply to localhost, but it still needs to connect via ssh (because that is how spread works). in my adt local vm this is all working great, however in the dc I get failures to connect to localhost
<pitti> mvo, jdstrand: networkd is supposed to send the hostname on a DHCP request, so if the server keeps a hostname -> IP mapping that shold work; but if it relies on the client to save the previous lease, we don't do that across reboots right now
<pitti> mvo, jdstrand: if that's needed, please file a bug (but why bother..)
<mup> PR snapd#1830 closed: firstboot: only configure en* and eth* interfaces by default <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1830>
<pitti> mvo: disk space failure is known, bug 1619285
<mup> Bug #1619285: cc_growpart fails on yakkety <cloud-utils:Fix Committed> <cloud-init (Ubuntu):Confirmed> <cloud-utils (Ubuntu):Confirmed> <util-linux (Ubuntu):Confirmed> <https://launchpad.net/bugs/1619285>
<pitti> mvo: we'll do a mass-retry after this is fixed, s_moser is working on it
<pitti> mvo: hm, sshd should be running in the instances, that's how we connect to it after all
<mvo> pitti: "Discarding adhoc:ubuntu-16.04-64, cannot connect: cannot connect to adhoc:ubuntu-16.04-64: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain", would love to play with it some more, works in my local adt qemu. and its really cool, we run 85 integration spread tests now in there which much more than with the old system, I'm super keen to land this but I need some test uploads to a real
<mvo>  adt to figure out why its not wokring just now. ideas appreciated (or a wiki page), I had hoped I could use yakkety but...
<mup> PR snapd#1821 closed: ensure snapd.refresh.service waits for snapd.firstboot.services <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1821>
<pitti> mvo: Changing password for ubuntu.
<pitti> chpasswd: (user ubuntu) pam_chauthtok() failed, error:
<pitti> mvo: and that's not just it?
<mvo> pitti: where do you see that? that may well be it
<pitti> mvo: anyway, if this happens with the current -proposed package, I can start a test manually with --shell and give you ssh access to the instance so that you can poke aroud
<pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/i386/s/snapd/20160901_214402@/log.gz
<pitti> mvo: the i386 snapd failure
<pitti> mvo: amd64 runs into the growpart failure, the i386 one got further
<pitti> mvo: well, where did *you* see it?
<mvo> pitti: yay, I think this gives me enough, I will try some more yakkety, I had no idea that i386 would work, as long as I have one working, its all good
<mvo> pitti: thank you
<pitti> mvo: so, I'm just saying don't do five uploads to debug this, the latency will kill all of however much patience you still have left :)
<mvo> pitti: heh, ok! *maybe* its just a single one, this log gives me some clues
<mvo> pitti: should I add "breaks-testbed" because of the modifications I make?
<pitti> mvo: irrelevant for the infra, but a nice warning for people trying to run it locally, yes
<mvo> ta
<pitti> mvo: well, actually not irrelevant if you have more than one test (this decides whether the testbed gets reset in between tests)
<mvo> pitti: its just a single (large test) currently
 * mvo adds it
<mvo> pitti: thanks a bunch for your help, much appreciated
<pitti> mvo: no worries; please let me know if you need ssh to a testbed instance
<mvo> ogra_: can you please check if you have the system-boot partition on your pi2, i.e. if it shows up with ls -l /dev/disk/by-label ? its not there on amd64 so firstboot breaks in different ways
<om26er> how to install lxd on all-snap image ?
<ogra_> mvo, nope
<mvo> ogra_: its not there?
<ogra_> no
<mvo> ogra_: then firstboot fails for this reason
<mvo> ogra_: easy enough to fix, I can push a new gadget, we had the same issue on amd64
<mvo> ogra_: a world of pain
<ogra_> filesystem-label: system-boot
<ogra_> it is in gadget.yaml
<mvo> ogra_: yeah but that is not the partition label
<ogra_> well, it uses an msdos table ... not sure we even planned for partition labels there
<mvo> ogra_: no idea either, I wonder if http://paste.ubuntu.com/23123142/ helps
<ogra_> (that might need more code in u-image)
<mvo> ogra_: I can look at the old u-d-f code
<mvo> ogra_: I checked, there is code in u-i for setting the fs-label, I just suspect its the wrong one
<ogra_> yeash, that smells like it should help
<om26er> I can see lxd here: https://uappexplorer.com/app/lxd.stgraber but can't install, am I missing something ?
<mvo> ogra_: I push it, what could possibly go wrong
<ogra_> heh, indeed
<mvo> meh, store and bzr out of sync!
<om26er> stgraber, around ? Can you tell if I can currently install lxd on all-snap image ?
<om26er> (on a RPi)
<dholbach> hey hey
<mup> PR snapd#1831 opened: interfaces: modem-manager: ignore camera <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/1831>
<mup> PR snapd#1831 closed: interfaces: modem-manager: ignore camera <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1831>
<zyga> o/
<zyga> ogra: hey, do you remmember the /etc/os-release thing
<ogra> zyga, see my bug comments :P
<ogra> (i linked all related bugs)
<zyga> ogra: ah, I see now; too bad we cannot use variant
<zyga> ogra: but whatever works :)
<ogra> well, i guess we can just use variant
<ogra> i personally find it cleaner ...
<ogra> it sounds like the natural field to use for this
<ogra> what worries me more is how we can mangle it in a clean way ...
<ogra> technically the change needs to be in base-files
<ogra> instead of being a hack in the build system
<ogra> i'm not sure how we should do that
<zyga> yep, I don't know either
<zyga> update-alternatives perhaps?
<ogra> uh
<zyga> or dpkg-divert something
<ogra> pitti, as somone who has touched base-files often ... any idea how we could cleanly mangle the content of os-release without evil hacks ?
<mup> PR snapd#1768 closed: many: automatically restart all-snap devices after os/kernel updates <Critical> <Reviewed> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1768>
<ogra> zyga, well, then a sed or mv/cp is as good ... given we dont use dpkg at all on the aime
<ogra> s/aime/img/
<zyga> ogra: you are right
<mvo> ogra: talked to steve, my changes to the gadget were incorrect, I fixed it now in the u-i code
<ogra> dpkg-divert really only makes sense regarding debs ...
<mvo> ogra: new ubuntu-image snap is uplaoded
<ogra> oh, its in the store already ?
<ogra> hah
 * ogra grabs
<mvo> yep
<mvo> only tested on kvm so far and need to go and work on snapd code next
<ogra> error: cannot fetch and check prerequisites for the model assertion: account-key [Jv8_JiHiIzJVcO9M55pPdqSDWUvuhfDIBJUS-3VW7F_idjix7Ffn5qMxB21ZQuij] not found
<ogra> hmpf
<mvo> ogra: yeah, one sec
<mvo> ogra: export UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1
<ogra> moves on
<ogra> mvo, did you already publish teh new gadget ?  http://paste.ubuntu.com/23123319/ ...
<mvo> ogra: sorry, now
<pitti> ogra: I don't actually know much about base-files, but WDYM with "mangle"?
<ogra> hmm, does u-image cache something ?
<ogra> still the same
<ogra> pitti, Bug #1619420
<mup> Bug #1619420: snappy removal of dpkg-query breaks lsb_release --all <cloud-init:New> <Snappy:New> <https://launchpad.net/bugs/1619420>
<ogra> and bug 1481086
<mup> Bug #1481086: Need API/cli method to know if "is_snappy" <Snappy:Triaged> <https://launchpad.net/bugs/1481086>
<ogra> mvo, didnt change :/
<ogra> mvo, also, any reason why you reverted the README change in the gadget ?
<mvo> ogra: sounds like a mistake
<ogra> ah, yeah, it was in the "merge from steve" merge :)
<mvo> ogra: yeah, that probably confuse dme, sorry, shall I fix or will you?
<mvo> ogra: I uploaded a new rev24 of the pi2 snap, jsut to be sure
<ogra> i can fix it, but i still get the same u-image error
 * ogra retries once again
<mvo> ogra: seems to be ok here, maybe a store delay?
<ogra> seems to work now
<ogra> at least it sits silent there
<ogra> aaaand ... i got an image ...
 * ogra dd's
<mvo> ogra: it does? my latest snap should have proper progress
<ogra> well, for the downloads
<ogra> everything after is still quiet
<ogra> (the image creation itself)
<mvo> aha, ok
<mvo> thats fine
<mvo> was worried for a second
<ogra> ogra@anubis:~/datengrab/images/snappy$ ls -l u-image-pi2.img
<ogra> -rw-r--r-- 1 root root 4000000000 Sep  2 10:29 u-image-pi2.img
<ogra> the size is really funny
<mvo> we probably need something slightly smaller
<ogra> yup, i have a bug open for that
<mvo> iirc we reduced it in u-d-f because some usb sticks are not up to it
<mvo> aha, yeah, we can make it a lot smaller indeed :)
<ogra> Bug #1619362
<mup> Bug #1619362: images should not be largely bigger than the actual content <Ubuntu Image:Incomplete> <https://launchpad.net/bugs/1619362>
<ogra> 300MB should be enough
<ogra> (effectively i'd like u-i to just compute the content, add a few MB wiggle room and roll that ..
<ogra> )
<ogra> as long as we resize on first boto we can be as small as the content
<ogra> *boot
 * ogra tries conv=sparse for dd ... according to steve that should not write the zeros
<ogra> woah
<ogra> and he seems to be right ... that was a fast dd
<mvo> ogra: yeah, I meant to add this to godd automatically but ENOTIME :/
 * ogra boots 
<ogra> reading /kernel.img
<ogra> ** Unable to read file /kernel.img **
<ogra> reading /initrd.img
<ogra> nope ... :(
<mvo> ogra: uh, that is worse than before
<ogra> yeah... waiting til i get a uboot prompt
<mvo> ogra: maybe I did a incorrect uboot.env from a wrong uboot.in?
<mvo> ogra: I think I regenerated it, maybe using the wrong readme? could you double check that maybe?
<ogra> http://paste.ubuntu.com/23123371/ filesystem looks fine
<mvo> ogra: yeah, I'm sure the env is wrong for some reaon
<ogra> no snap_kernel and snap_core in the env
<ogra> sounds more like u-i than the default env
<ogra> all other defaults are correct
<mvo> ogra: hm, hm ok
<mup> PR snapd#1802 closed: image,overlord/boot,snap: metadata from asserts for image snaps <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1802>
<ogra> WOAH
<ogra> i just wanted tzo check the vars on yesterdays dragonboard image
<ogra> snap_kernel=dragonboard-kerne.snap
<ogra> how the heck did that boot at all ?!?!
 * ogra reboots the board 
<ogra> hmm, despite the mangled value it seems to use the correct one on boot
<ogra> how weird is that
<ogra> snap_kernel=dragonboard-kernel_7.snap
<ogra> hmm ... now it is correct
<ogra> probably a serial tty glitch then
<ogra> U-Boot> setenv snap_kernel pi2-kernel_11.snap
<ogra> U-Boot> setenv snap_core ubuntu-core_424.snap
<ogra> mvo, boots fine with that ^^^
<ogra> bah, still the cloud-init failures
 * ogra goes to make coffee ... that'll take 10-15min til cloud-init gives up 
<ogra> ogra@localhost:~$ snap list
<ogra> No snaps are installed yet. Try 'snap install hello-world'.
<ogra> ogra@localhost:~$
<ogra> mvo, in that regard nothing changed ^^^
<mvo> ogra: what is the systemctl status snapd.firstboot output?
<ogra> give it a bit, i just rebooted
<ogra> oh come on cloud-init
<ogra> sigh
<ogra> this is such a pain :/
<mvo> ogra: yeah, I think I will merge the branch from cyphermox into my snap
<mvo> ogra: its just terrible otherwise
<ogra> mvo, http://paste.ubuntu.com/23123469/
<ogra> nothing exciting
<mvo> ogra: hm, snap changes?
<mvo> ogra: and snap change 1 ?
<ogra> ogra@localhost:~$ snap changes
<ogra> error: no changes found
<ogra> ogra@localhost:~$ snap change 1
<ogra> error: cannot find change with id "1"
<ogra> and i guess if i greop for the model assertion error ... i will find the same thing
<mvo> ogra: oh, yeah, I suspect that is the case
<ogra> ogra@localhost:~$ sudo grep model /var/log/syslog
<ogra> Sep  2 08:31:11 localhost kernel: [    0.000000] Machine model: Raspberry Pi 2 Model B Rev 1.1
<ogra> Sep  2 08:31:12 localhost snap[2612]: error: need a model assertion
<ogra> yeps
<mvo> ogra: we are close to having a real model assertion
<ogra> but first things first ... whatever sho7uld set snap_kernel and snap_core failed to do so
<ogra> this only booted because i manually tweaked them
<ogra> sigh ... and the user isnt in adm ... thats also painful
<ogra> mvo, ARGH !
<ogra> http://paste.ubuntu.com/23123498/
<ogra> kernel is gone ...
<ogra> i assume the vfat we create with u-i is different from what u-d-f did create
<mvo> ogra: its gone now?
<mvo> ogra: was it there before?
<mvo> ogra: and vanished on boot?
<ogra> i booted it a few times, yes
<ogra> looks like something did an fsck
<ogra> and moved the files to fsck000X.rec
<ogra> i bet it doesnt get along with "pi2-kernel_11.snap/" not being 8+3
<ogra> for whatever reason
<ogra> so i assume u-i creates the wrong type of vfat
<mvo> uh, the fsck ones are indeed terrible
<mvo> ogra: thats alarming
<ogra> well, good that we hit it now :)
<ogra> i ran the former u-d-f image for about a month ... with at least one reboot per day (for the new ubuntu-core) ... so i know the u-d-f setup was 100% robust
<ogra> there must be something different in the vfat creation
<mvo> ogra: let me fix that
<ogra> +1
<mvo> ogra: I think (because the filesystem is small) it was auto-selecting fat16
<mvo> ogra: if you can boot it, there should be a way to verify
<ogra> well, its an SD :)
<mvo> ogra: heh, ok
<ogra> GerÃ¤t      Boot  Start     Ende Sektoren GrÃ¶Ãe Id Typ
<ogra> bah
<ogra> GerÃ¤t      Boot  Start     Ende Sektoren GrÃ¶Ãe Id Typ
<ogra> /dev/sdc1  *      2048   264191   262144  128M  c W95 FAT32 (LBA)
<ogra> /dev/sdc2       264192 61315071 61050880 29,1G 83 Linux
<ogra> hmm
<mvo> hm indeed
<ogra> the start byte is different when i compare to an SD from u-d-f
<ogra> 2048 vs 8192
<abeato> ogra, do you know if anybody has snapped x11 for rpi?
<ogra> abeato, wont happen i guess
<ogra> mvo, didnt you add some magic math to u-d-f back then for exactly that ?
<ogra> i remember something like that
<ogra> abeato, Mir and XMir is the answer ...
<ogra> we wont allow plain X11 afaik
<abeato> ogra, sure, but we do not have those yet, isn't it?
<abeato> (snapped)
<ogra> we do have mir
<ogra> but we dont have images with graphics drivers
<abeato> ogra, hmm, will that happen any time soon for rpi?
<ogra> between RTM and GA
<abeato> ogra, git it, thanks
<abeato> *got it :p
<ogra> mvo, i actually think it is the mkfs.vfat call that might differ in u-i
<ogra> cmd := []string{"mkfs.vfat", "-F", "32", "-n", string(part.label)}
<ogra> thats what u-d-f has
<ogra> oh, and
<ogra>                         if size != "512" {
<ogra>                                 cmd = append(cmd, "-s", "1")
<ogra>                         }
<ogra>                         cmd = append(cmd, "-S", size, dev)
<ogra> it computes the exact sector size
<ogra> (and hands it over to mkfs)
<mvo> ogra: oh, interessting
<ogra> i have a suspicion that we use something less reliable in u-i
<ogra> like mtools instead of mkfs
<ogra> (because the former doesnt  need root)
<mvo> ogra: u-i also uses mkfs.vfat
<ogra> but with different options i guess
<mvo> ogra: but different parameters, let me try settings -s1
<ogra> func sectorSize(dev string) (string, error) {
<ogra>         out, err := exec.Command("blockdev", "--getss", dev).CombinedOutput()
<ogra>         if err != nil {
<ogra> that is what it uses to determine the size
<joc_> has there already been landings on master of snapd to prevent or change method for installing local unasserted snaps?
<mvo> ogra: I think its ok to always force -s1 aiui if size is 512 -s1 is also used (implicitely)
<ogra> blockdev --getss ....
<mvo> sergiusens: do you remember why vfat -s1 was used?
<mvo> sergiusens: in u-d-f?
<ogra> mvo, note -s != -S
<joc_> ah, i found --force-dangerous, dont worry :)
<ogra>        -s SECTORS-PER-CLUSTER
<ogra>            Specify the number of disk sectors per cluster.  Must be a power of 2, i.e. 1, 2, 4, 8, ... 128.
<ogra>        -S LOGICAL-SECTOR-SIZE
<ogra>            Specify the number of bytes per logical sector.  Must be a power of 2 and greater than or equal to 512, i.e. 512,  1024,  2048,  4096,  8192,
<ogra>            16384, or 32768.
<ogra> we always append -S
<mup> PR snapd#1832 opened: Added time-date-control interface for org.freedesktop.timedate1 <Created by stolowski> <https://github.com/snapcore/snapd/pull/1832>
<ogra> and if != 512 we *also* append "-s 1"
<mvo> ogra: oh, indeed
<mvo> hm, leaving that out for now then
<mvo> ogra: not even sure that will work on a file
<ogra> ogra@anubis:~/datengrab/images/snappy$ sudo blockdev --getss /dev/sdc1
<ogra> 512
<ogra> ogra@anubis:~/datengrab/images/snappy$ sudo blockdev --getss /dev/sdc1
<ogra> 512
<ogra> they are both identical
<ogra> (thats u-i vs u-d-f image)
<ogra> hmm
<ogra> though i should probably check *before* and fsck ran
 * ogra re-flashes the u-i image
<ogra> s/and/any/
<ogra> yeah, stays 512
<mvo> ogra: do we have that candidate snap for ubuntu-core? or should I try to set it?
<Son_Goku> morning!
<ogra> just try to set it from this mornings build i guess
<ogra> mvo, 421-426
<mvo> Son_Goku: hey, good morning. thanks for your mail, my world is terrible busy right now but I get back to you once we have finished our images deadlines
<Son_Goku> images?
<ogra> yes
<Son_Goku> what images?
 * Son_Goku is missing context
<ogra> snappy images :)
<Son_Goku> ah
<ogra> ubuntu-core + kernel snap + gadget snap ...
<mvo> on real devices like pi2 etc
<ogra> or pc's
<ogra> :)
<Son_Goku> ~_~
<Son_Goku> right, the thing I can't really do anything with at the moment
<ogra> why not ?
 * ogra runs a bunch of servers using these images(15.04 still though)
<ogra> and i'll convert this http://www.grawert.net/watchthesun/ to snap once we have finalized series 16 images :)
<ogra> (and the rest of my house control)
<Son_Goku> well, firstly, being Ubuntu is a bit of a problem (I'd like to have snappy Fedora/CentOS systems)
<Son_Goku> second, even if I was okay with Ubuntu, I'm not okay with an EOL Ubuntu
<ogra> series 16 will not be EOL before 2018
<ogra> long term we will also have phone and desktop images
<ogra> (for now the focus is IoT, embedded, cloud and headless)
 * ogra notes that people never recognize how old snappy actually is ... or that you can buy devices with it preinstalled since years :)
<ogra> every time i see a flatpack vs snaoppy discussion i see people claiming that snappy is something new ... it's three years old ... it just didnt get used on classic installs before :)
<sergiusens> mvo a review for Colin, I can maybe even fetch it
 * sergiusens waves good morning
<ogra> moin
<ogra> mvo, so did you do any changes regarding the vfat that i could try ?
<ogra> else i'll move on to fiddle withj the pi3 gadget and later with the dragonboard
<jgdx> using the gtk3 launcher, I get could not find or load the Qt platform plugin "xcb". Any suggestions?
<mvo> ogra: not yet, sorry
<mvo> ogra: I get the feeling pi2 is not going to happen today
<mvo> ogra: just too many issues
<ogra> mvo, well, we have time til friday, no ?
<mvo> ogra: today is friday, no?
<ogra> mvo, i mean next week ... i understood jamiebennett's mail that we postpone by a week
<ogra> (which is actually wed. not fri, but definitely next week)
<jamiebennett> ogra: A week from the original RTM which is Wed
<ogra> right
<jamiebennett> ogra: But of course we need to test before that
<ogra> indeed
<ogra> i'd say fri. is more realistic anyway :) ...
<ogra> in any case though ... we need to fix the pi probs and also need dragonboard images
<ogra> both are rtm targets
<jamiebennett> ogra: So image spinning on Monday, testing and bug fixing Tues
<ogra> jamiebennett, right ... the issue today is that pi2 images eat themselves after reboot ... the vfat gets trashed
<jamiebennett> ouch
<ogra> and we dont really knwo why
<mvo> I really want an iamge (pc at least) today
<ogra> we have working pc images, dont we ?
<ogra> (apart from known cloud-init issues etc)
<sergiusens> ogra mvo cannot find the MP, but most of the vfat logic comes from learnings of ubiquity
<mvo> ogra: I mean end-to-end, with model assertion, snap asseritons
<mvo> ogra: we have something that boots right now, thats all
<ogra> mvo, well, then we need approval to postpone arm ...
<ogra> i can surely get a dragonboard and pi3 gadget ready in time ... but if we dont fix the other bugs that wont help
<sergiusens> ogra mvo and first partition we put at 8192 (it used to be 4096) to take into account most of those raw partition writes some devices use; 8192 was a recomendation from lool
<mvo> ogra: well, like jamiebennett said, next week is fine for arm, its just that if we don't have a fully working pc image today, I think its going to be difficult for arm
<mvo> ogra: arm needs everything thta pc needs plus more
<jamiebennett> ack
<ogra> also, what makes you sure the vfat corruption wont happen on x86 ?
<mvo> ogra: same deal, we write much less to it
<mvo> ogra: but yeah, same concern
<ogra> right
<sergiusens> I would really partition those vfats like we did in u-d-f
<ogra> sergiusens, yeah
<sergiusens> maybe cjwatson can review ubuntu-image?
<ogra> did he review udf ? :)
<ogra> we really only need to make it identical
<sergiusens> ogra s512 and all that magic logic comes from his review
<ogra> ah !
<sergiusens> ogra I started with that? :-)
<sergiusens> ogra Colin's learnings from ubiquity ;-)
<ogra> well, what i definitely see is that the two vfats start at different bytes on the different SD cards here
<ogra> start byte -> 2048 vs 8192
<ogra> inspecting them beyond that doesnt reveal any differences
<sergiusens> ogra might be some broken magic on ubuntu-image?
<ogra> it seems to use the same mkfs.vfat command
<sergiusens> joc_ hey, mind looking at this https://github.com/snapcore/snapcraft/pull/771/files and maybe trying to build plainbox with it?
<cjwatson> sergiusens: well, I know how partitioning works in general but I know absolutely nothing about the logic that ubuntu-image is seeking to apply
<cjwatson> 8192*512 == 4MiB which I would agree is most likely to be aligned on suitable boundaries
<ogra> 274             if part.filesystem is FileSystemType.vfat:   # pragma: nobranch
<ogra> 275                 run('mkfs.vfat {}'.format(part_img))
<ogra> woah ...
<ogra> so i'm wrong
<cjwatson> (1MiB is a bit more typical but even a few years ago I was hearing rumblings about some media using 4MiB)
<ogra> we run mkfs.vfat totalyl witrhout any options
<ogra> while we apply a good bunch in u-d-f
<sergiusens> cjwatson thanks, it seems ogra found the culprit ;-)
<cjwatson> mkfs.vfat at least used to require some moderately exotic options to get things right
<ogra> yes
<ogra> and in u-d-f we use them ...
<joc_> sergiusens: thanks for heads up, i might ask one of the other checkbox devs to try as i'm a bit deep in to some snapd stuff right now
<cjwatson> -F fat32 plus an -S option set to the logical sector size of the device in question, IIRC
<ogra> yep
<cjwatson> and maybe -n
<ogra> plus -s 1 of the sector size isnt 512 or some such
<ogra> and yes, -n
<ogra> s/of/if/
<ogra> http://paste.ubuntu.com/23123789/ is the code we use in u-d-f
<ogra> (sectorSize is the return value of blockdev --getss)
<ogra> oh man ... and looking at line 22 in that paste i guess we can be happy that it never hit that code path :P
<ogra> "mkfs.ext4", "-F", "-L", string(part.label), dev ....
<ogra> (i doubt -F works without value)
<ogra> oh
<ogra> heh
<ogra> thats ext4
<sergiusens> !!
<ogra> ignore my babbling :P
<mup> PR snapd#1806 closed: overlord/devicestate: set device registration URLs <Critical> <Reviewed> <Created by matiasb> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1806>
<mup> PR snapd#1822 closed: snapd.refresh.service: require snap.socket and /snap/*/current <Reviewed> <Created by stolowski> <Conflict> <https://github.com/snapcore/snapd/pull/1822>
<mup> PR snapd#1824 closed: tests: use ubuntu-image for the ubuntu-core-16 image creation <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/1824>
<cjwatson> Right, I believe the account-key work is now code-complete and "just" needs four layers of stuff to be reviews/fixed/landed/deployed
<cjwatson> *reviewed
<cjwatson> (remaining snapd/asserts fixes for checking account-key-request; snap-assertions-service endpoint to do likewise; software-center-agent changes to account-key endpoint to use that; snapcraft PR to add register-key)
<sborovkov> jamiebennett: ping
<jamiebennett> sborovkov: Sorry, was at lunch, around now
<sborovkov> jamiebennett: Hello. Who can I ask about store issue? Can't install snap on classic again from our store. I am logged in with snap login and have correct variable in /etc/environment :(
<jamiebennett> sborovkov: What do you mean by "Can't install snapp", is the snap available with a snap find?
<sborovkov> jamiebennett: No. snap find --private is not working as well. Snap is published in our store and it was working before. With snap intsall --devmode --edge screenly-client
<jamiebennett> sborovkov: and what does snap --version say?
<sborovkov> jamiebennett: 2.14.1
<sborovkov> I tried proposed when the latest stable was not working
<sborovkov> nothing changed
<jamiebennett> so you have the latest and now it breaks your store, nothing else changed? If not then maybe mvo knows of a recent change that may have affected this
<jamiebennett> let me look at the code
<jamiebennett> sborovkov: what was the last working snapd version you tried?
<sborovkov> I am pretty sure 2.11 was working
<sborovkov> I reflashed after that because my SD card broke. And after apt upgrade I was not able to install snap from the screenly store anymore
<sborovkov> I saw some that there were some commits related to getting store id. May be it broke during that. But that's just guessing.
<sergiusens> joc_ where does plainbox live?
<jamiebennett> sborovkov: I'm looking into it now, will get back to you shortly
<Son_Goku> ogra, well, snappy as it exists today didn't exist more than a year or so
<sborovkov> jamiebennett: thanks
<jamiebennett> sborovkov: have you tried snap revert ubuntu-core to see if a previous snapd works?
<cyphermox> ogra: hey, u-i work needed?
<mvo> sborovkov: what env var are you using? UBUNTU_STORE_ID?
<ogra> cyphermox, not atm, no
<joc_> sergiusens: lp:checkbox
<popey> sergiusens: can you help me with fixing a snap where there is a dupe between two parts?
<sergiusens> popey ok
<sborovkov> mvo: yes
<popey> sergiusens: ok, lemme prep
<sergiusens> popey but I have father and son time starting in 3 minutes (aka baby sitting)
<sborovkov> jamiebennett: Oh, no I did not try that. I checked apt cache for previous versions but did not think of that
<sergiusens> so I might take a bit
<joc_> sergiusens: you might be most interested in this project though https://code.launchpad.net/~checkbox-dev/plainbox-provider-snappy/+git/packaging/+ref/master
<popey> sergiusens: http://paste.ubuntu.com/23123924/
<sborovkov> jamiebennett: what would be the syntax to get 2.11?
<sergiusens> joc_ whatever is needed to build the snap ;-)
<jamiebennett> sborovkov: just snap revert ubuntu-core until you get there
<popey> sergiusens: ok, run that, it fails - minetest and minetestgame parts both have a minetest.conf.example in them, which fails to snapcraft, so I added line 31/32 to exclude it, but that fails with:-
<popey> Stepping over existing file for organization 'games/minetest_game'
<popey> [Errno 2] No such file or directory: '/home/alan/Development/Snappy/github_snappy_playpen/snappy-playpen/minetest/parts/minetestgame/install/*'
<popey> which I don't get?
<jamiebennett> sborovkov: try each version as you revert though, maybe we can pinpoint the exact release
<joc_> sergiusens: yep that last repo has the yaml to look at then
<joc_> sergiusens: hopefully spineau will be here soon as he was most recently looking at building plainbox using the python3 plugin
<sergiusens> joc_ oh, it is not yet? then great ;-)
<joc_> sergiusens: nope currently we are pulling it from pypi
<sergiusens> joc_ the python plugin rewrite I did is a bit special wrt filesets because it doesn't mix stage-packages and pypi/pip ones
<sergiusens> oh, pulling from pypi and using it locally should be almost the same thing
<sborovkov> jamiebennett: Wait how does that work? snap list tells me there are no installed snaps. snap revert ubuntu-core tells me there is no revision to revert to. I guess I am doing something wrong?
<joc_> sergiusens: yeah this was what was need to fix our weird repo layout problem https://github.com/snapcore/snapcraft/pull/751
<mup> PR snapcraft#751: python3 plugin: run setup.py in source subdir if such option exists <Created by yphus> <https://github.com/snapcore/snapcraft/pull/751>
<sergiusens> popey does this work '*': 'games/minetest_game/' ? I have a bug to implement that iirc
<jamiebennett> sborovkov: snap install ubuntu-core
<popey> sergiusens: it used to.
<mvo> sborovkov: silly question (sorry if its obvious), but since you added it to the environment did you restart snapd since changing /etc/environment?
<jamiebennett> sborovkov: but wait
<popey> sergiusens: something changed in 2.14 (copy -> dump i think) which broke it all
<mvo> sborovkov: I looked at the code and it appears to be ok, let me dig some more
<jamiebennett> sborovkov: that won't help
<sborovkov> mvo: Yes, system was restarted few times since then
<jamiebennett> sborovkov: mmm
<sborovkov> mvo: May be I can enable some logging?
<sborovkov> SNAPD_DEBUG_HTTP or something like that?
<sergiusens> joc_ oh I missed that one, it is fixed here too btw  https://github.com/snapcore/snapcraft/pull/771/files
<jamiebennett> sborovkov: actually try snap install ubuntu-core
<sergiusens> along with a bunch of other things
<mvo> sborovkov: yes, if you set this to "7" it should print something
<jamiebennett> sborovkov: then snap revert it
<mvo> sborovkov: sudo systemctl stop snapd.service snapd.socket to stop the existing one
<mvo> sborovkov: and sudo /lib/systemd/systemd-activate -E SNAPD_DEBUG=1 -l /run/snapd.socket -l /run/snapd-snap.socket /usr/bin/snapd to see the output
<mvo> sborovkov: uh, add a -E with the debug env here :)
<sborovkov> mvo: Did not it print info to state.json and syslog before? or did that change
<mvo> sborovkov: and another -E with the UBUNTU_STORE_ID
<sborovkov> ok, going to get logs and the start reverting
<mvo> sborovkov: yeah, syslog will also have it
<popey> sergiusens: never mind, I'll grab you next week :)
<spineau> o/
<mvo> sborovkov: just double checked, the logging should hopefully be sufficient
<ogra> argh !
<ogra> so i tried my third ubuntu-image change now always ending with corrupt fs
 * ogra slaps mvo 
<ogra> source: https://github.com/mvo5/ubuntu-image.git
<ogra> tsk
 * ogra fixes snapcraft.yaml to use source: .
<joc_> hey spineau, sergiusens just pointed this out:
<mvo> ogra: you can just run via sudo ./ubuntu-image
<spineau> sergiusens: hello, I'll test your PR (https://github.com/snapcore/snapcraft/pull/771/files) and see if we can still use plainbox and if it solves our issue to use it from source.
<mvo> ogra: no need to snap it all
<ogra> oh, that finds all the modules?
<spineau> sergiusens: probably not today but on my todo for Monday
<mvo> ogra: yes
<ogra> ah, k
<mvo> ogra: just make sure you have a snapd that is sufficiently new, maybe from the ppa
<ogra> and i was wondering why my changes had no effect at all
<mvo> ogra: but for the fs tests I think its ok
<mvo> ogra: but you do see fs corruption constantly?
<joc_> spineau: yeah apparently 771 should fix the issue in your PR 751
<ogra> mvo, but source: https://github.com/mvo5/ubuntu-image.git inside the snapcraft.yaml that is in https://github.com/mvo5/ubuntu-image.git it pretty redundant :)
<mvo> ogra: fair enough
<ogra> mvo, yes, after second or third reboot
<ogra> -                run('mkfs.vfat {} {}'.format(fslabel, part_img))
<ogra> +                run('mkfs.vfat -F 32 -S 512 -s 1 -n {} {}'.format(fslabel, part_img))
<spineau> joc_: excellent. thanks
<ogra> thats what i'm trying to try
<ogra> hmm
<ogra> i shoudl drop -s 1 again ... that was just out of desparation
 * ogra does so and rolls a new image
<sborovkov> mvo: https://paste.kde.org/piqe5px4r/805roo Did 2 installations attempts. Before the second one I logged in again... Since I remember it timing out before. So just in case. not that it made a difference
<sborovkov> JamieBennett: mvo: I also can't install ubuntu-core before I remove UBUNTU_STORE_ID=screenly from /etc/environment. But I guess that's expected since my store does not have it?
<JamieBennett> sborovkov, right
 * ogra would add the env var to snapd's systemd unit instead ... 
<ogra> saves you the reboot
<sborovkov> JamieBennett: mvo: Haha. It's working now.
<JamieBennett> sborovkov, what did you do?
<sborovkov> after installing ubuntu-core
<sborovkov> I switched back to my store
<sborovkov> and it started installing it!
<zyga_> jdstrand, tyhicks: is there any other (easier) way to check that a given directory is a mount point (bind mount to be precise) than to parse /proc/self/mountinfo?
<mvo> sborovkov: d'oh - thank you
<mvo> sborovkov: that is an interessting bug
<JamieBennett> mvo, right
<sborovkov> Yeah, it was working before
<mvo> sborovkov: the "can not find snap" error is real, but it refers to ubuntu-core :(
<JamieBennett> mvo, seems you can't see snaps in a custom store if you don't have ubuntu-core installed?
<JamieBennett> mvo, ah
<sborovkov> oh, now it's clear yeah
<sborovkov> too bad there is no name
<mup> PR snapd#1833 opened: many: spell --force-dangerous as just --dangerous, devmode should imply it <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1833>
<mvo> sborovkov: yeah, definitely another silly UI bug
<JamieBennett> sborovkov, your paste includes a password, best to change that now ;)
<sborovkov> JamieBennett: oops
<JamieBennett> sborovkov, mvo actually it does show the missing snap name
<JamieBennett> Sep  2 12:39:52 ubuntu /usr/lib/snapd/snapd[4979]: logger.go:66: DEBUG: > "GET /api/v1/snaps/details/ubuntu-core?
<sborovkov> JamieBennett: mvo: One more question. I noticed that snap login would time out after some time. Is there some recommended way I can stay logged in? Also. Since my snap is in --devmode it would not get updated automatically? Should I just add cronjob to periodically do snap refress --devmode --edge screenly-client?
<JamieBennett> sborovkov, we use macaroons for store login that expire after a set amount of time
<mvo> I think the timeout is a bug, matiasb_ knows more
<JamieBennett> sborovkov, for refreshing cron would work, yes
<matiasb_> sborovkov, mvo, since 2.13 I think, auth refresh is in place and that should handle automatic refresh of macaroons in the background
<mvo> niemeyer: did we decide  against automatic refresh of --devmode snaps? or is the fact thta this is not happening yet a bug?
<sborovkov> understood, thanks guys
<ogra> pitti, i'm going mad here ... can i somehow teach netplan to not set the NIC up tio get a different IP at every reboot ?
 * ogra tries to do scripted reboots via ssh ... that behaviour is  rather counter-productive if you need to do 50 reboots
<ogra> GRRRRR
<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 on [::1]:53: read udp [::1]:33128->[::1]:53: read:
<ogra>                                connection refused
<ogra> whyx is *everything* broken today
<ogra> yeah, crap ... doesnt look like i can get console-conf out of this
<cyphermox> ogra: pi2?
<ogra> yeah
<cyphermox> yeah, nuke sit0
<cyphermox> I'll patch this in console-conf, it's annoying
<ogra> well, i didnt need to do that the last 20 boots
<ogra> and a hard reset worked (apart from the fact that i have nearly seen all my 254 free IP adresses my dhcp server provides)
<ogra> and indeed i get a new ssh key every boot
<ogra> mvo, no go ... no matter what mkfs.vfat options i use ... it reliably eats itself on second reboot
<ogra> i have tried all combos now ... it must be the img creation itself that interferes somehow
<ogra> not just the missing filesystem options
 * ogra is desparate 
<ogra> and i'm convinced this will bite us on all vfats
<Kaleo> jdstrand, we have an app in a snap connected to the home interface which requests a thumbnail of an image in the home folder to the thumbnailer service via dbus, the thumbnailer service uses aa_query_label to verify that the app has indeed the rights to read that file and it returns a non 0 value indicating that the app does not have access
<ogra> even on grub based ones
<Kaleo> jdstrand, any idea what might cause that?
<ogra> (even if it will take longer til it shows up there)
<mvo> ogra: we talked about it in the meeting just now, can we remove the ubuntu user
<ogra> mvo, well ... that makes debugging rather hard when doing bringup atm ...
<ogra> but technically we can indeed
<ogra> (i guess we still need to create empty extrausers files)
<ogra> mvo, though i dont really see alÃ¶l this as releasable if we dont find the cause for the vfat stuff ... i doubt grub images will be any more reliable
<ogra> it will just show up later since we write to the fat less
<ogra> but after all all vfats are created the same
<ogra> which makes it very likely they will all expose the same corruption
<ogra> sooner or later
<ogra> mvo, also ... since the IP changes every boot, how do you find the IP for your login when you can only log in via ssh now
<ogra> (wont really affect kvm where you can use localhost indeed)
<notadeveloper_> hi ogra
<notadeveloper_> is there a video support for raspi on snappy core
<notadeveloper_> rasp pi 3
<ogra> not yet, no
<notadeveloper_> video playback
<cyphermox> maybe libaa? :)
<ogra> we dont ship it ... so only in devmode :)
<cyphermox> oh, right
<ogra> but yeah, libaa could work :)
<ogra> you just have to go very far away from your screen :)
<niemeyer> mvo: We explicitly decided against the refresh
<niemeyer> mvo: Sorry, ECONTEXT probably... responding to that earlier question about refreshes in devmode
<mup> PR snapd#1834 opened: many: mostly work to support ABA upgrades <Created by chipaca> <https://github.com/snapcore/snapd/pull/1834>
<mvo> niemeyer: yeah, thats fine, it was a question from a user who was wondering about it
<mvo> niemeyer: I remembed this too, but wanted to confirm
<niemeyer> mvo: This was an alternative to another behavior that was discussed in that same meeting in Heidelberg
<niemeyer> mvo: The idea was taking it out of devmode on update
<niemeyer> mvo: Which felt very awkward to me.. so between that and blocking the update, I voted for the latter
<mvo> niemeyer: indeed, I remember now
<notadeveloper_> just to make sure
<notadeveloper_> is there a video support for raspi on snappy core
<notadeveloper_> video playback
<ogra> no
<mup> PR snapd#1835 opened: Support noneSecurityTag keyed snippets in udev backend <Created by jocave> <https://github.com/snapcore/snapd/pull/1835>
<notadeveloper_> only webplayback
<joc_> niemeyer: hi, thanks for getting the PR that you took over in last night, i think that ^ might be needed however
<ogra> notadeveloper_, cyphermox was joking ... libaa translates your video into ascii to play it in a terminal
<niemeyer> sborovkov: The notes slightly above are context for why the refreshes don't happen in devmode
<niemeyer> joc_: Heya, thanks, looking
 * ogra cries a little
<niemeyer> joc_: reviewed
<joc_> thx
<plars> Is there a way to use conditionals in the snapcraft.yaml? For instance, I have a dependency I need for build-packages on x86 (gcc-multilib) that doesn't exist on arm64. We already avoid building that piece on arm64, but snapcraft still tries to install the build-package and fails
<bulldog> hello from bulldog
<bulldog> :)
<ogra> mvo, http://paste.ubuntu.com/23124139/ ... this is the first boot !!
<bulldog> guys updates on snapcraft-gui plz check it out here https://github.com/keshavbhatt/snapcraft-gui#screenshot
<bulldog> ogra, hi :)
<niemeyer> joc_, _morphis; How's the outlook for all these interfaces? Do we need anything pending other than that branch?
<ogra> mvo, it seems to actually fall over on . and ..
<bulldog> mhall119, popey , guys check out the implemented features here feedback plz  https://github.com/keshavbhatt/snapcraft-gui#current-task
<ogra> ?!?
<niemeyer> Sorry, I know we have things up for review.. are they ready?
<ogra> Bad short file name (.).
<morphis> joc_: for serial-port and hidraw joc_ put everything up afaik
<ogra> Bad short file name (..).
<ogra> this is just insane !
<morphis> niemeyer: ^^
<joc_> niemeyer: i haven't managed to confirm everything works yet, need to confirm the udev rules do what expected
<mvo> ogra: hm, did you try to use the options from u-d-f? this did not make a difference when building pi2 images?
<niemeyer> bulldog: Wow, nice.. hadn't seen that
<bulldog> niemeyer, thanks :)
<ogra> mvo, right ... i tried with onlÃ¶y -F 32 ... i tried with any combo of -F 32 and -S 512 ... and even with -s 1
<ogra> no change
<ogra> and look at the fsck output above
<niemeyer> ogra: Haha, that's great
<bulldog> niemeyer, its not fully ready yet but everything is coming so fast in few days it will able to snap out packages :)
<ogra> niemeyer, well, it makes *all* images eat the vfat at some point
<ogra> niemeyer, if we dont get that fixed, i'd say forget about any release
<mvo> ogra: so -F 32 -S 512 -s 1 (what u-d-f is doing) did not help
<ogra> mvo, right
<ogra> mvo, but i totally dont get how i can have . and .. in a vfat dir at all
<ogra> (or why systemd would choke on it)
<ogra> (well, actually fsck.fat)
<mvo> ogra: yeah, its fsck
<ogra> mvo, i dont think u-d-f actually uses -s 1
<ogra> given that the size is actualyl 512
<ogra> so that code wont kick in
<ogra> (but i tested both )
<bulldog> no one wana contribute in snapcraft gui , damn but am not giving up this early :D
<ogra> mvo, i wonder if it is actually not the filesystem but actually the files ... since we use mtools to copy them
<ogra> 330                 run('mcopy -s -i {} {} ::'.format(part_img, sourcefiles),
<ogra> 331                     env=dict(MTOOLS_SKIP_CHECK='1', PATH=os.environ["PATH"]))
<ogra> MTOOLS_SKIP_CHECK='1' ... i wonder what check that actually skips :P
<ogra> aha
<ogra> All the Mtools commands perform a few sanity checks
<ogra>        before going ahead, to make sure that the disk is indeed an MS-DOS disk (as opposed to, say an ext2 or MINIX disk). These checks may reject  parâ
<ogra>        tially  corrupted  disks, which might otherwise still be readable. To avoid these checks, set the MTOOLS_SKIP_CHECK environmental variable or the
<ogra>        corresponding configuration file variable (see section  global variables)
 * ogra drops that and builds an image ... lets see if it errors
<ogra> hmm, no errors with it dropped
<Guest73706> Is there a list of currently supported distros? Roadmap for support? especially Linux Mint
<ogra_> Guest73706, if you use an ubuntu kernel on mint i dont see a reason why it wouldnt work
<ogra_> zyga, ^^^ your area :)
<ogra_> (as long as it is 16.04 based at least)
<mvo> ogra_: no errors means no more fsck errors?
<ogra_> mvo, no, i was hoping about errors from mcopy ... whoever did put MTOOLS_SKIP_CHECK='1' there must have had a reason
<ogra_> wow
<ogra_> the output of fsck is different every time
<ogra_> http://paste.ubuntu.com/23124260/ vs http://paste.ubuntu.com/23124139/
<sborovkov> mvo: Just one more question. Were there some breaking changes after snapcraft's updates? I have snap built from today in store. Previous version is from few weeks ago. If I unpublish only the latest revision I can't install snap from store as well. (I would check with sideloading, but it's not working on classic)
<zyga> Guest73706: hey, can you please repeat the question
<mvo> sborovkov: snapcraft is something that sergiusens known more about
<ogra_> zyga, <Guest73706> Is there a list of currently supported distros? Roadmap for support? especially Linux Mint
<mvo> sborovkov: so you unpublished a version and the previous one is not found?
<sborovkov> yes, I unpublished revision. After that snap install says snap not found. As soon as I publish it again it gets installed
<mvo> sborovkov: the store UI can be slightly confusing sometimes, can you doublle check that its published in a channel? there is a "overview" link.
<mvo> sborovkov: but there is  a previous version that it should find and its in the right channel :/ ? is that what you are saying?
<sborovkov> mvo: Yes. In the UI it shows the latest revision as not published (with the hand showing that it's ok. previous one is green and shown as published when I click on details)
<Pharaoh_Atem> zyga: have you tested my SELinux module yet on Fedora 24?
<zyga> Guest73706: hey, currently various distros are supported, I believe mint works (just not the last stable version but the one under development now)
<zyga> Pharaoh_Atem: no, still stuck with mount namespace sharing
<mvo> sborovkov: nessita may be able to help here, this sounds like the store is not quite correct
<Guest73706> great to hear! So for status, I would look under mint's development tracking or snappy's?
<zyga> Pharaoh_Atem: I need some time to breathe but that's not likely to happen this week
<zyga> Pharaoh_Atem: I wish I had 48 hours a day
<sborovkov> nessita: Hello, any ideas about why what I descibed above is happening? Is it a bug or expected behavior?
<mup> PR snapd#1833 closed: many: spell --force-dangerous as just --dangerous, devmode should imply it <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1833>
<nessita> sborovkov, hi, what package is this?
<zyga> Guest73706: I think mint inherits snappy from ubuntu, just try the latest version of mint
<zyga> Guest73706: it it doesn't work I'd love to know
<Guest73706> awesome, thanks!
<sborovkov> nessita: well, it's in private store
<sborovkov> nessita: sorry, had to reboot my pc. My keyboard went crazy. It's for my package in our store. I can give any info I can. Just ask whatever that will be helpful :)
<ogra_> zyga, will be interesting if it actualyl works with all the hackery mint does :)
<ogra_> (i.e. i have seen releases where they patched libc but kept the package name identical and such)
<zyga> ogra_: that shouldn't matter
<ogra_> (... and the version so it pretended to be ours)
<ogra_> zyga, haha ... ask xnox ... he had his share of fun with mint hacked libs :)
<ogra_> (as well as i did)
<zyga> ogra_: well, it doesn't matter what glibc you have, that is my point
<ogra_> zyga, if essential functions are patched to work completely different it does :)
<tyhicks> zyga: I don't know of an easier way to check if a path is a mount point
<zyga> ogra_: like?
<zyga> tyhicks: that's okay,
<zyga> tyhicks: if you want, I have something to pre-review
<zyga> tyhicks: and perhaps a bug in apparmor
<ogra_> zyga, dunno :)
<tyhicks> zyga: show me what you got
<zyga> tyhicks: OK
<tyhicks> zyga: fyi, Jamie is out today
<tyhicks> (security Jamie)
<mup> PR snapd#1822 closed: snapd.refresh.service: require snap.socket and /snap/*/current <Reviewed> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1822>
<zyga> tyhicks: yep, I know
<tyhicks> ok
<nessita> sborovkov, what's the package id? is in the URL in the myapps.developer.ubuntu.com site
<sborovkov> nessita: bvBwbB7aeomIdJxpQh9lakQByyJtyKXp
<nessita> sborovkov, thanks, let me check
<zyga> tyhicks: ok, let me push my branch now, sorry, I took a moment to add various notes
<tyhicks> no problem
<zyga> tyhicks: pushed
<zyga> er
<zyga> hmmm
<zyga> still pushing
<nessita> sborovkov, so your revno 9 is ready to be published, but right now is not published in the store (see the thumbs up next to the #9 to the left, vs the green boxes for the other revnos)
<nessita> sborovkov, also, if you check https://myapps.developer.ubuntu.com/dev/click-apps/5407/configurations/ (private URL only you and me can access) you can see the revision summary for your package
<nessita> sborovkov, does that match your expectations?
<tyhicks> zyga: pushed where?
<zyga> tyhicks: sorry, back to the main repo, I had to fiddle with keys and tokens
<zyga> it's there now
<zyga> tyhicks: https://github.com/snapcore/snap-confine/tree/ns-sharing
<mup> PR snapd#1836 opened: overlord/state: fix for reloaded task/change crashing on Set if checkpointed w. no custom data  yet <Created by pedronis> <https://github.com/snapcore/snapd/pull/1836>
<mup> PR snapd#1837 opened: [WIP] Add refresh-control header to snap-declaration assertion <Created by ralsina> <https://github.com/snapcore/snapd/pull/1837>
<zyga> tyhicks: configure it ./configure --prefix=/usr --libexecdir=/usr/lib/snapd/ --enable-nvidia-ubuntu --enable-maintainer-mode
<zyga> tyhicks: and give it a try (read it as well :)
<zyga> tyhicks: this is my main priority so I'll be here in case you figure anything out
<sborovkov> nessita: I unpublished latest revision. Since revision 8 is published should not it get installed?
<zyga> tyhicks: if you want a quick cut-to-the-chase https://github.com/snapcore/snap-confine/compare/ns-sharing?expand=1#diff-c3983658fdc823eef69accc8537b27f0R243
<nessita> sborovkov, for arch armhf and channels beta and edge, yes. Is that not working for you?
<zyga> tyhicks: I use a hat to confine the child process
<zyga> tyhicks: pehrpas overkill, perhaps not
<sborovkov> nessita: nope. says snap not found. As soon as I publish revision 9 - I can install it again without any issues. But not rev 8
<nessita> sborovkov, also are you trying to install with snapd? let me confirm if snapd works with the non default store
<nessita> sborovkov, are you exporting the proper env vars to use your private store?
<sborovkov> nessita: Yup. Because it works when revision 9 is published.
<nessita> sborovkov, ok, and how are you trying to install revno 8? (just asking the basic to troubleshoot without missing anything)
<sborovkov> With the same command snap install --devmode --edge screenly-client. Since it's the latest published I expect it to be installed
<sborovkov> did not try specifying specific revision
<nessita> sborovkov, that sound correct, let me debug more
<tyhicks> zyga: to get rid of that denial, you need to make this change: https://paste.ubuntu.com/23124379/
<tyhicks> zyga: if you want background reading: https://lists.ubuntu.com/archives/apparmor/2010-July/000110.html
<zyga> tyhicks: ! :)
<zyga> thanks! trying
<nessita> sborovkov, is not showing up for me neither, searching more
<zyga> tyhicks: cool, that changes the denial but I can work with the rest
<tyhicks> ok
<zyga> now I get: Sep 02 17:35:29 xenial-server kernel: audit: type=1400 audit(1472830529.357:78): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" name="/run/snapd/ns/hello-world.mnt" pid=43833 comm="ubuntu-core-lau" srcname="/" flags="rw, bind"
<zyga> failed mntpnt (mount point?) match
<tyhicks> yes
<tyhicks> zyga: try dropping that trailing '/' on the following rule
<tyhicks>   mount options=(rw bind)  -> /run/snapd/ns/*.mnt/,
<tyhicks> zyga: I don't think that'll do it but lets just rule it out
<zyga> ha, it did!
<tyhicks> "yay"
<tyhicks> that's a bug
<tyhicks> minor but annoying
<zyga> tyhicks: pushed the fix
<zyga> tyhicks: is it? this is a bind mount for a file, it actually looks consistent
<tyhicks> oh
<tyhicks> right
<tyhicks> I wasn't thinking that it was a file bind mount
<tyhicks> so that makes sense
<nessita> sborovkov, so the package is private, have you run snap login in that box?
<zyga> tyhicks: ok, I need to make one simple change in main
<zyga> tyhicks: but this might actually pass spread now
<tyhicks> ok, I'll sit tight
<sborovkov> nessita: yes, I did
<sborovkov> nessita: rev 9 is also private, so I would not be able to install it without that
<zyga> tyhicks: actually, to help me out, would you mind reviewing mountinfo.[ch]
<zyga> tyhicks: I can propose that separately as it is isolated
<nessita> sborovkov, what channel was 9 in?
<sborovkov> nessita: beta, edge
<nessita> sborovkov, I need some time to debug this by issuing the requests myself, could you file a bug please? https://bugs.launchpad.net/software-center-agent/+filebug
<nessita> sborovkov, please make the bug private
<sborovkov> nessita: sure
<tyhicks> zyga: looking at it now
<sborovkov> nessita: How do I make it private though? is this option going to appear after I click 'Submit bug report'?
<abeato> ogra_, , can I create an arm image to run inside kvm with u-d-f?
<ogra_> nope
<abeato> only rpi then, right?
<ogra_> cyphermox, can you set Bug #1619718 to critical
<mup> Bug #1619718: ubuntu-image created vfat eats itself after a while <Ubuntu Image:New> <https://launchpad.net/bugs/1619718>
<ogra_> (i can not set bug status  on u-image)
<ogra_> mvo, ^^^
<mvo> ogra_: I can't either
<ogra_> i added a snappy task now :)
<mup> Bug #1619718 opened: ubuntu-image created vfat eats itself after a while <Snappy:New> <Ubuntu Image:New> <https://launchpad.net/bugs/1619718>
<zyga> tyhicks: I'll open a pull request for mountinfo
<sborovkov> nessita: https://bugs.launchpad.net/software-center-agent/+bug/1619719
<zyga> tyhicks: https://github.com/snapcore/snap-confine/pull/123
<tyhicks> zyga: it is looking good so far
<mup> PR snap-confine#123: Add mountinfo module <Created by zyga> <https://github.com/snapcore/snap-confine/pull/123>
<zyga> tyhicks: I'll work on tests, I've updated ns-sharing branch to actually do what I intended in main
<zyga> tyhicks: but let's take it slow and focus on mountinfo now
<tyhicks> ok
<zyga> I'll write a few unit tests for all the mountinfo functions
<ogra_> mvo, bug 1619721 for the randomly changing IP
<mup> Bug #1619721: IP changes with every reboot  <Snappy:New> <nplan (Ubuntu):New> <https://launchpad.net/bugs/1619721>
<mup> Bug #1619721 opened: IP changes with every reboot  <Snappy:New> <nplan (Ubuntu):New> <https://launchpad.net/bugs/1619721>
 * zyga could use coverage reports here hmmm
<qengho> ogra_: what address? v6 link local? v4 DHCP-assigned? Something else?
<ogra_> qengho, ipv4 ...
<ogra_> but it desont make a difference, i did about 50-100 image installs today ... even with v6 it randomly changes
<ogra_> (well, even with v6 configured the v4 one randomly changes i should say)
<ogra_> mvo, do you need a bug for snap_kernel and snap_core not being set or do you already know wnat to do ?
<ogra_> *what
<qengho> What is DHCP doing now? discover,offer,nak,offer?
<pstolowski> jdstrand, hey! can you take a look at the apparmor policy of this new interface when you have a moment? https://github.com/snapcore/snapd/pull/1832
<mup> PR snapd#1832: Added time-date-control interface for org.freedesktop.timedate1 <Created by stolowski> <https://github.com/snapcore/snapd/pull/1832>
<ogra_> qengho, http://paste.ubuntu.com/23124588/
<ogra_> thats the whole day for this MAC on my DHCP server
<ogra_> at least for the boots when it was connected :)
<mvo> ogra_: I need to debug it
<ogra_> do you need a report ?
<mup> PR snapd#1836 closed: overlord/state: fix for reloaded task/change crashing on Set if checkpointed w. no custom data  yet <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1836>
<qengho> ogra_: So, the DHCP client doesn't have a previous address to suggest to the DHCP server to assign, perhaps. Not retained across boots?
<ogra_> qengho, well, it worked before nplan ... this pi2 has 192.168.2.29 since 15.04 days ... it only doesnt work with the new images using nplan and console-conf only
<ogra_> (if i had not overwritten the SD i could actually show you :) that it gets the same IP again)
<ogra_> mvo, Bug #1619729 for you then
<mup> Bug #1619729: ubuntu-image (or snapd) does not set snap_kernel and snap_core anymore in created images <Snappy:New for mvo> <Ubuntu Image:New> <https://launchpad.net/bugs/1619729>
 * ogra_ feels exhausted and breaks
<mup> Bug #1619729 opened: ubuntu-image (or snapd) does not set snap_kernel and snap_core anymore in created images <Snappy:New for mvo> <Ubuntu Image:New> <https://launchpad.net/bugs/1619729>
<zyga> tyhicks: I've added a few tests
<zyga> tyhicks: any feedback so far?
<tyhicks> zyga: I was just about to ask for a test that had two or more optional fields and see that you added one :)
<zyga> tyhicks: yep, and fixed a missing space there
<zyga> tyhicks: it's a shame the kernel doesn't produce json
<zyga> tyhicks: one thing I'm not doing is un-escaping parsed strings
<zyga> tyhicks: but for what we are doing this is *not* required as there are no spaces or special characters allowed
<tyhicks> zyga: there are spaces and special characters allowed in the mount src and dst
<tyhicks> you end up with something like this:
<zyga> yes but those are escaped and just looke escaped in the strings we read
<tyhicks> 46 26 0:20 /baz /dev/shm/foo\040bar rw,nosuid,nodev shared:4 - tmpfs tmpfs rw
<zyga> but for those that we care about (actively look at) this is not the case
<tyhicks> (that's for "/dev/shm/foo bar")
<zyga> tyhicks: it will parse OK
<tyhicks> ok
<zyga> tyhicks: we only look for /run/snapd/ns which is a constant
<tyhicks> I haven't got to how the mountinfo is used yet
<tyhicks> it took me a while to get through the parsing function
<mup> PR snapd#1838 opened: overlord: introduce AuthContext.DeviceSessionRequest with support in devicestate <Created by pedronis> <https://github.com/snapcore/snapd/pull/1838>
<tyhicks> it is complicated but I don't have a better suggestion at this time
<zyga> tyhicks: yes, the parsing is dense
<sborovkov> nessita: ping
<zyga> tyhicks: thank you!
<zyga> tyhicks: I can make a small PR on top, for the ns-sharing APIs
<zyga> tyhicks: if you are available for reviewing that
<zyga> tyhicks: I'll take a break now
<zyga> tyhicks: I'll send a chain of PRs
<zyga> tyhicks: if you are available, I would really love to get this reviewed
 * zyga -> off for some time
<sborovkov> nessita: so do you want me to leave everything as is so you could test, or can I upload new revisions? I am going offline soon, so in case you need me to leave everything as is for now pleas write there. I won't be doing anything till Sunday I think
<tyhicks> zyga: thank you!
<tyhicks> zyga: I need to focus on the udisks2 backend code this afternoon but I'll be up for a distraction
<popey> using cmake in snapcraft when building foo which depends on libbar, is there some way I can tell foo to look for libbar in the stage dir? is there an env variable for $SNAPCRAFT_STAGE or something?
<popey> for some reason foo isn't finding libbar... which I'm building from scratch because there's no package
<sergiusens> popey hey, forgot about your problem, so where are you at, I can help onw
<sergiusens> now
<popey> which one?
<popey>  ð
<popey> ^ this one is more fun :)
<sergiusens> popey there is a var, called $SNAPCRAFT_STAGE actually (it's an envvar in master) in the current release it is a replacement in snapcraft.yaml
<popey> so my foo which has a -DTELL_ME_WHERE_LIBBAR_IS= I could set it =$SNAPCRAFT_STAGE/usr/lib/blah ?
<sergiusens> popey yes!
<popey> excellent, will try that
<popey> thanks
<sergiusens> popey like this https://github.com/snapcore/snapcraft/blob/master/integration_tests/snaps/stage_env/snapcraft.yaml
<popey> perfect, will try that
<popey> sometimes, lxd chooses perfect names
<popey> $ snapcraft cleanbuild
<popey> Creating snapcraft-loudly-major-grouse
<sergiusens> popey it just knows what you are up to at times ;-)
<popey> :)
<popey> sergiusens: ok, got time for the other issue from earlier?
<sergiusens> josepht about https://github.com/snapcore/snapcraft/pull/773, do you think that is a reasonable request
<mup> PR snapcraft#773: parser - Handle project name and version variables <Created by josepht> <https://github.com/snapcore/snapcraft/pull/773>
<mup> PR snapd#1839 opened: interface: network_manager: enable resolvconf <Created by tonyespy> <https://github.com/snapcore/snapd/pull/1839>
<sergiusens> popey is the current cmake one solved? and sure, tell me more
<popey> not yet, it takes an age to build :)
<popey> it may be a known bug if so, which one.. lots of snappy-playpen examples broke in the copy->dump change
<popey> sergiusens: http://paste.ubuntu.com/23125014/
<popey> results in:- [Errno 2] No such file or directory: '/home/alan/Development/Snappy/github_snappy_playpen/snappy-playpen/minetest/parts/minetestgame/install/*'
<popey> used to work with copy plugin, all the examples which use copy, broke when we switched to dump
<sergiusens> popey it is not a blind one off replacement though
<sergiusens> popey line 26 certainly will not work and there is a bug for that :-)
<popey> ah
<sergiusens> popey inidividual file listing is required, this will get fixed in 2.17 (next week)
<popey> suh-weet!
<popey> got the bug number handy?
<sergiusens> popey https://bugs.launchpad.net/snapcraft/+bug/1616459
<mup> Bug #1616459: dump plugin not a full super-set to the now deprecated copy plugin <Snapcraft:New> <https://launchpad.net/bugs/1616459>
<popey> magic, ta
<popey> btw, i love snapcraft cleanbuild
<popey> its so handy
<elopio> sergiusens: josepht: I think the MissingPackageError should come from the pull method of each source class.
<sergiusens> popey wait til 2.16, with --debug you get a shell into the env on errors ;-)
<popey> woot
<popey> into the lxd container?
<popey> double woot
<mvo> ogra_: I did a new ubuntu-core build that should contian the new "ubuntu" user-less core
<mvo> ogra_: just fyi
<ogra_> mvo, ok
<ogra_> i'll play around with ti tommorrow
<ogra_> *it
<josepht> sergiusens: I think that's perfectly reasonable.  I'll get it updated
<josepht> elopio: I think that's a good idea.  I'll update the PR.
<sergiusens> elopio +1
<elopio> I'm full of good ideas this week! Sadly it's already friday, I can't make any promises for next week ^_^
<sabdfl> hi folks, how do we handle conditional-start situations with snaps
<sabdfl> for example, i havev a VPN service, and i want to start and run if there are VPNs configured, but if not then its OK to quit
<sabdfl> the init system isn't going to know if there are VPNs configured
<sabdfl> i assume i have a wrapper script which decides if it should exec the daemon
<sergiusens> sabdfl we have the same problem with "only start if networking is there"; in any case we do need more language to hook into init
<sabdfl> but if it doesn't exec the daemon, and it exits, won't the init system restart it?
<sergiusens> sabdfl wrappers are what people are using, but what if a VPN is configured on a running system after your snap decided not to start?
<sabdfl> i guess one could watch config
<sabdfl> in future well have config hooks
<sabdfl> we'll, sorry
<sergiusens> sabdfl in systemd RemainAfterExit= Takes a boolean value that specifies whether the service shall be considered active even when all its processes exited.
<sergiusens> sabdfl and a  Restart= condition of on-failure should be good
<sergiusens> maybe the RemainAfterExit is not needed at all with Restart=on-failure
<Hakase> hello there :)
<Hakase> anyone here ?
<elopio> Hakase: hello, welcome.
<Tester2009> hello
<mup> PR snapd#1838 closed: overlord: introduce AuthContext.DeviceSessionRequest with support in devicestate <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1838>
<mup> PR snapd#1840 opened: many: use symlinks instead of wrappers <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/1840>
<sabdfl> elopio, Hakase didn't have much to say :)
<jonsnow> Hi. Is there a way to host a private snappy store ?
<elopio> he seemed nice though, I hope he comes back... :'(
<elopio> jonsnow: something like this? https://insights.ubuntu.com/2016/06/24/howto-host-your-own-snap-store/
<jonsnow> elopio: yes perfect, thanks :)
<jonsnow> any plan to support OS X ? (snaps)
<elopio> jonsnow: are you offering to make the port? :)
<elopio> the first step is to support things without systemd. But from that to conquer the world there are still plenty of steps.
<sergiusens> elopio what does Not this last one. mean?
<elopio> sergiusens: it means that on the release notes for 2.16 you added the commit for the release notes for 2.16.
<sergiusens> elopio I think I see what you are getting at
<sergiusens> elopio and we've been doing that forever, and will keep doing it until we get the packaging split in place
<sergiusens> elopio I pasted the link to the package builds
<elopio> really? it's the first time I see it. Let me try to understand where is it coming form
<elopio> from
<elopio> sergiusens: I find disturbing the inconsistency in the use of the final period in sentences. Am I being too weird?
<elopio> sergiusens: let me get lunch and a little rest first, and then I'll run and document the tests. +1 on your changelog pr.
<mup> PR snapd#1791 closed: asserts: support checking account-key-request assertions <Created by cjwatson> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1791>
<mup> PR snapd#1793 closed: asserts: initial support to generate/sign snap-build assertions <Created by caio1982> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1793>
<mup> PR snapd#1841 opened: store: switch device session to use device-session-request assertion <Created by matiasb> <https://github.com/snapcore/snapd/pull/1841>
<sergiusens> elopio any updates on QA?
 * zyga returns to fix a few typos
<Son_Goku> ?
<zyga> hey!
<zyga> just a few typos, I read my pull requests and saw them
<zyga> I had to get away from my compuer for a while to vent my mind and give my body some exercise
#snappy 2016-09-03
<sergiusens> cprov is this hooked up already? https://bugs.launchpad.net/snapcraft/+bug/1619819 https://bugs.launchpad.net/software-center-agent/+bug/1619818
<mup> Bug #1619819: It is possible to release a devel snap to candidate and stable <store> <Snapcraft:New> <Software Center Agent:New> <https://launchpad.net/bugs/1619819>
<mup> Bug #1619818: Error when trying to push and release a snap with devel grade <store> <Snapcraft:New> <Software Center Agent:New> <https://launchpad.net/bugs/1619818>
<cprov> sergiusens: grade is fully supported by current SCA & CRT
<cprov> sergiusens: I have to check 19
<cprov> sergiusens: right, 18 is something else as elopio pointed in the last comment
<cprov> sergiusens: just checked the code, the release endpoint needs update to restrict channels according to grade :-/
<elopio> cprov: yes, I updated 18. Sorry about that.
<cprov> elopio: no problem, thanks for playing with it and discovering 19. Michael Nelson (our man in the future) will tackle this his early Monday and we will release the fix on SCA until Monday EOD
<cprov> it will probably require some publishing cleanup <sigh/>
<elopio> Autralians are amazing
<sergiusens> cprov elopio no rush, this won't make it to -updates until late Monday/early Tuesday
<zyga> anyone interested in a code review for snap-confine?
<eldarkg> hello guys. how to use in cmake config flags variable $SNAP_VERSION?
<Son_Goku> zyga: ?
<Son_Goku> zyga, what do you need reviewed?
<zyga> Son_Goku: hey, I need some help on this one https://github.com/snapcore/snap-confine/pull/123
<mup> PR snap-confine#123: Add mountinfo module <Created by zyga> <https://github.com/snapcore/snap-confine/pull/123>
<zyga> Son_Goku: sosrry for the lag, I was busy writing and dind't notice I didn't paste URL initially
<zyga> eldarkg: I don't know about that, what are you trying to achieve?
<eldarkg> zyga: I want to compile app with set to him $SNAP_VERSION value
<zyga> eldarkg: for informative purpose?
<eldarkg> zyga: https://bugs.launchpad.net/snapcraft/+bug/1619877
<mup> Bug #1619877: $SNAP_VERSION is empty when I set cmake vars <version> <Snapcraft:New> <https://launchpad.net/bugs/1619877>
<zyga> eldarkg: $SNAP_VERSION is set at runtime
<eldarkg> zyga: can I to define user variables in a snapcraft file?
<zyga> eldarkg: the plan is to allow that, it relies on a set of bits to be in place, I don't remember if this is all available from snapcraft all the way to snap-confine
<zyga> eldarkg: I think it might have gone live this week
 * zyga was busy under the hood 
<eldarkg> zyga: ok. thank you
<zyga> eldarkg: but $SNAP_VERSION is set by snappy automatically
<zyga> eldarkg: based on the version field from snapcraft.yaml
<eldarkg> zyga: ok
<Son_Goku> zyga, I don't see anything nuts about your PR
<zyga> Son_Goku: thanks
<mup> Bug #1619888 opened: Snap should be able to run chown <Snappy:New> <https://launchpad.net/bugs/1619888>
<mup> PR snapd#1842 opened: asserts: don't have Add/Check panic in the face of unsupported no-authority assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/1842>
<mup> PR snapd#1843 opened: snap: switch to the new agreed regexp for snap names <Created by pedronis> <https://github.com/snapcore/snapd/pull/1843>
<mup> PR snapd#1842 closed: asserts: don't have Add/Check panic in the face of unsupported no-authority assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1842>
<eldarkg> zyga: how to do that snap app can to list FS tree?
<zyga> eldarkg: hmm, that depends on what you mean
<eldarkg> zyga: https://github.com/eldarkg/kicad-snap/issues/7
<zyga> eldarkg: use the home interface for this snap, when connected it will grant access to most of the users home directory
<eldarkg> zyga: home interface used
<eldarkg> zyga: app is using files that contributed from snap tree ($SNAP/usr/share/kicad)
<zyga> eldarkg: I don't think I know what the problem is
<eldarkg> zyga: how resolve this?
<zyga> eldarkg: the home interface gives access to /home/$LOGNAME
<zyga> eldarkg: the $HOME variable is redirected so that might fool some applications (it points to snap-private home)
<zyga> eldarkg: I don't know what you mean when you talk about $SNAP/usr/share/kicad
<zyga> eldarkg: is this one or separate multiple issues?
<eldarkg> zyga: I want to take access to $SNAP file system to read and to list content
<zyga> eldarkg: can you be more specific? which location do you want to access
<eldarkg> zyga: content like footprints, 3d models, libraries of components, demos
<eldarkg> zyga: to $SNAP/usr/share
<zyga> eldarkg: that directory is available by defautl
<eldarkg> zyga: https://github.com/eldarkg/kicad-snap/issues/8
<zyga> eldarkg: can you add some kind of information to the bug report?
<zyga> eldarkg: I don't understand how you determine that something is denied
<zyga> eldarkg: do you get an apparmor denial?
<zyga> eldarkg: the $SNAP directory is typically /snap/$SNAP_NAME/$SNAP_REVISION
<zyga> eldarkg: so the data you are after is in /snap/kicad-dev-snap/$SNAP_REVISION/usr/share
<eldarkg> zyga: isn't accessible from gui? see previous issue link
<zyga> eldarkg: the gui is a part of the application,
<zyga> eldarkg: snappy has no influence over that
<mup> PR snapd#1820 closed: many: start services only after the snap is fully ready (link-snap was run) <Critical> <Reviewed> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1820>
<eldarkg> zyga: How I can to do that app works correctly?
<zyga> eldarkg: I don't know much about kicad, perhaps you can work with kicad developers on this
<eldarkg> zyga: ok. Maybe I can to list files from '/' (root)?
<zyga> eldarkg: yes, you should be
<eldarkg> zyga: why next? snapd-hacker-toolbelt sh;  ls / . Message: ls: can't open '/': Permission denied
<zyga> eldarkg: hmm, interesting
<zyga> eldarkg: that may be the cause of some of the things you saw
<zyga> eldarkg: does kicad snap work better in devmode?
<eldarkg> zyga: sorry snapd-hacker-toolbelt.busybox sh
<eldarkg> zyga: I don't check this in devmode.
<eldarkg> zyga: wait. I am trying
<eldarkg> zyga: Yes kicad in --devmode works fine but it isn't what I want. I want that snap app works in strict confine
<qengho> eldarkg: in devmode, it should permit but log your apps missteps in syslog in /var/log/ .
<qengho> eldarkg: Though, working in devmode and not in strict sounds like it is probably some syscall that is not allowed, unless you have another kicad installed from another package like deb.
<eldarkg> qengho: Sep  3 17:00:13 EP43-DS3L kernel: [30646.624140] audit: type=1400 audit(1472911213.426:1200): apparmor="DENIED" operation="open" profile="snap.snapd-hacker-toolbelt.busybox" name="/" pid=31164 comm="busybox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<eldarkg> qengho: snap app in strict mode doesn't accesible to '/' (root)
<eldarkg> qengho: only in $SNAP
<eldarkg> zyga: I go away to ~1 hour. If you found some info ping me
<qengho> eldarkg: with devmode, it should (?!) still warn. What else does it warn about?
<eldarkg> qengho: see my previous msg to you. I use $ snapd-hacker-toolbelt.busybox sh; $ ls /
<qengho> eldarkg: Yeah. But that is not your app. I want to make sure you're asking for what you really want, and not what you think is a path to the answer.
<qengho> Tell us you want your car tire changed. Don't ask where we keep the screwdrivers.
<eldarkg> qengho: see https://github.com/eldarkg/kicad-snap/issues/7. I go away
<zyga> eldarkg: I'm debugging a few things in snapd
<zyga> eldarkg: but not related to this
<mup> PR snapd#1844 opened: tests: adjust test setup after ubuntu user removal <Created by zyga> <https://github.com/snapcore/snapd/pull/1844>
<mup> PR snapd#1844 closed: tests: adjust test setup after ubuntu user removal <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1844>
<eldarkg> qengho: Do you see?
<mup> Bug #1619928 opened: snap app: access denied: list a FS tree <access> <Snappy:New> <https://launchpad.net/bugs/1619928>
<mup> PR snapd#1843 closed: snap: switch to the new agreed regexp for snap names <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1843>
#snappy 2016-09-04
<mhall119> zyga: how can I get https://bugs.kde.org/show_bug.cgi?id=368198 into Launchpad so it's on your radar?
<ehbello> hello... anyone awake?
<mup> PR snapd#1845 opened: tests: use the real model assertion when creating the core test image <Created by mvo5> <https://github.com/snapcore/snapd/pull/1845>
<ogra_> mhall119, file a bug using the link from the topic and add the kde bug as bugtask
<ogra_> mhall119, (nvidia drivers work just fine btw though that guy seems to use nvidia-prime, i think there are issues when the interl side is enabled instead of the nvidia one)
<bulldog> hi friends :P
<bulldog> ogra_,
<bulldog> j
<bulldog> hi
<bulldog> "
<bulldog> <hi>
<bulldog> hi bulldog
<kalikiana> grrr why oh why get snaps uploaded without any channels?
<kalikiana> this doesn't seem very sensible for a default
<bulldog> kalikiana, :P
<bulldog> you mean snaps getting uploaded w/o any channel ??
<kalikiana> Yes. And I didn't even realize (again) that this was the case so my snap was not available for 4 days
<bulldog> daem
<bulldog> you uploaded to store or from terminal using snap command ??
<bulldog> what should be change-id in snap abort ??
<bulldog> kalikiana, checkout snapcraft gui development :P
<kalikiana> Use 'snap changes' to get the id, it's the first column
<kalikiana> GUI development?
<bulldog> yeah am making gui for snapcraft
<bulldog> kalikiana, https://github.com/keshavbhatt/snapcraft-gui
<bulldog> it is under development
<bulldog> anyone can let me know how many ways you use pull , stage, and prime commands while building snaps ??
<mup> PR snapd#1846 opened: overlord/auth,store: fix raciness in updating device/user in state through authcontext <Created by pedronis> <https://github.com/snapcore/snapd/pull/1846>
<spieler8> i am trying to package my app as a snap. It's a compiled binary + libs + ressource files. Is there any existing example I can take as a guideline?
<mup> PR snapd#1835 closed: interfaces/udev: support noneSecurityTag keyed snippets <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1835>
#snappy 2017-08-28
<andschwa> I need some help. I'm looking for the global configurations so I can change SNAP_DATA and SNAP_COMMON for all my snaps (so I can install them to a separate drive).
<andschwa> But my god, I've searched and searched. There's docs on what the environment variables are, but not how to set them for snapd.
<andschwa> Should I really perhaps be looking at mounting my drive to /var/snap?
<andschwa> This seems like a super straightforward thing to do.
<andschwa> And I cannot find it.
<andschwa> Is anyone here, or is everyone on "Rocket"?
<andschwa> Is what I want to do against snappy's design or something?
<andschwa> It doesn't seem like it, since it's all centered around environment variables set at runtime by snapd for a snap.
<andschwa> So it seems almost explicitly setup such that you can change what snapd sets those variables to.
<andschwa> Yet I cannot find it.
<mup> PR # closed: snapd#2807, snapd#3120, snapd#3260, snapd#3372, snapd#3398, snapd#3484, snapd#3502, snapd#3556, snapd#3573, snapd#3616, snapd#3617, snapd#3621, snapd#3625, snapd#3635, snapd#3642, snapd#3697, snapd#3719, snapd#3720, snapd#3727, snapd#3734, snapd#3748, snapd#3750, snapd#3755,
<mup> snapd#3759, snapd#3760, snapd#3773, snapd#3777, snapd#3779, snapd#3780, snapd#3781, snapd#3795, snapd#3797, snapd#3804, snapd#3805, snapd#3807, snapd#3810, snapd#3812
<mup> PR # opened: snapd#2807, snapd#3120, snapd#3260, snapd#3372, snapd#3398, snapd#3484, snapd#3502, snapd#3556, snapd#3573, snapd#3616, snapd#3617, snapd#3621, snapd#3625, snapd#3635, snapd#3642, snapd#3697, snapd#3719, snapd#3720, snapd#3727, snapd#3734, snapd#3748, snapd#3750, snapd#3755,
<mup> snapd#3759, snapd#3760, snapd#3773, snapd#3777, snapd#3779, snapd#3780, snapd#3781, snapd#3795, snapd#3797, snapd#3804, snapd#3805, snapd#3807, snapd#3810, snapd#3812
<abeato> ogra_, do you know which is the current status of https://forum.snapcraft.io/t/updating-bootloader-assets-in-the-gadget-snap ?
<mup> PR snapd#3759 closed: add spread test for wayland <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3759>
<zyga-suse> good morning
<zyga-suse> sorry for being late, I was the last one at breakfast, along with my sleepwalking daugther
<zyga-suse> mvo: how are you doing today?
<mvo> zyga-suse: hey, good morning. doing fine, how are you?
<zyga-suse> pstolowski: hey, I think there's something you want to look into
<zyga-suse> mvo: perhaps ^ before release
<zyga-suse> mvo: downgrading from master to stable fails if you have any changes in flight that involves hooks
<zyga-suse> because of the new hooks that don't have handlers
<mvo>  zyga-suse hm, interessting. what does the error look like? can you pastebin the session?
<pstolowski> zyga-suse, hey
<zyga-suse> mvo: I _may_ I ran into it over weekend
 * zyga-suse scrolls back
<mvo> zyga-suse: thank you
<zyga-suse> mvo: essentially this looks like the "CE cannot rollback" problem we had
<mvo> zyga-suse: I'm mostly curious about the exact effect, if we really cannot rollback that is a problem
<zyga-suse> mvo: aha, maybe that wording was too strong, I think the given change will fail but rollback as a whole will work (still just guessing)
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#54 closed: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>
<mvo> zyga-suse: yeah, if that is the case its bad but not a blocker for the release. still something we want to fix
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#54 opened: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>
<pstolowski> zyga-suse, what do I do exactly to reproduce?
<mvo> zyga-suse, pstolowski: please keep me updated :)
<zyga-suse> pstolowski: wait, let me find it
<zyga-suse> mvo: one more thing, I merged that PR with apparmor probing code
<zyga-suse> mvo: I re-designed it after your comment
<zyga-suse> mvo: please have a look if you like that
<mvo> zyga-suse: you merged it and then re-designed it?
<zyga-suse> mvo: no, I read your comment, re-designed and merged
<mvo> zyga-suse: ok, I have a look. but I would prefer to look before it gets merged (two +1 and all that)
<zyga-suse> mvo: it's very similar to your suggestion and I had +1 from jamie so I merged it but I'll wait for re-affirmation next time
 * zyga-suse still looks for that hook info
<zyga-suse> darn, where was that...
<zyga-suse> pstolowski: sorry I cannot find it
<zyga-suse> I think it was on IRC but you were already off
<zyga-suse> but I cannot see it in my backlog
<zyga-suse> pstolowski, the situation is as follows, start installing a snap using master, stop snapd and revert to stable
<pedronis> I don't see many solutions here except changing the handling of hooks slightly in 2.26
<zyga-suse> I think being more graceful, as if the task was done in 2.26 would be good
<zyga-suse> essentially you cannot rely on the hook
<zyga-suse> since old snapd may run it
<zyga-suse> and if you want to rely, use assumes
<pedronis> is the revert of core itself that explodes?
<zyga-suse> I don't remember, I think it was not the core but then again, it may be
<zyga-suse> and in that case it would be unfortunate
<mvo> zyga-suse: I put some comments into the PR 3808, nothing criticial but worth considering IMO
<zyga-suse> sure,
<mvo> zyga-suse: don't get me wrong, I appreciate the work on this feature and I know its frustrating to wait for reviews :)
<zyga-suse> mvo: the nil result is something I copied from Chipaca's PR
<zyga-suse> mvo: I can undo that, I was just surprised that you can call methods on typed nil just fine
<zyga-suse> mvo: and I did it here
<mvo> zyga-suse: right, its fine, I was also surprised about it (haven't seen that pattern) and that is one good reason to have it in code review to spread the knowledge etc :)
 * zyga-suse got a telemarketer call now
<mvo> zyga-suse: do you remember what PR it was where Chipaca used this nil check pattern? curious to see how/why it was used there too
<mvo> zyga-suse: meh, I hate those
<zyga-suse> with a 500GB 3G/LTE data plan
<zyga-suse> mvo: no, but maybe Chipaca remembers, it was very recent
<zyga-suse> at 23euro / month
 * zyga-suse is considering that 
<zyga-suse> they also bundle some crap laptop
<mvo> Chipaca: do you think you could have a look at 3795? it probably also needs a review from niemeyer but if we are happy with the code that will help I think (we need gustavo mostly for the concecpt behind it)
<mvo> Chipaca: its also short :)
<zyga-suse> mvo: replied
<zyga-suse> mvo: let me know if you want me to change the nil pointer thing
<zyga-suse> man, clouds == crap network
<pstolowski> zyga-suse, you mean install a deb with master, then revert to debs from the distro?
<pstolowski> (pardon my ignorance, but I'm not sure if it should involve some images from edge etc.)
<zyga-suse> pstolowski: I think just install edge and go to stable
<zyga-suse> pstolowski: and have the right snap install pending
<pstolowski> k
 * mwhudson waves
<zyga-suse> hey mwhudson
<Chipaca> zyga-suse: mvo: good morning!
<Chipaca> *technically* it's a national holiday here
<zyga-suse> Chipaca: ohhh, nice
<zyga-suse> so what are you doing here?
<Chipaca> zyga-suse: having breakfast, and also i've been trying to snap a rather gnarly application
<zyga-suse> +100
<zyga-suse> I love trying to snap things
<zyga-suse> to see how that feels like
<zyga-suse> and to see what issues I run into
<Chipaca> it's looking like i can't make this one work without either bases or layouts
<Chipaca> and that assumes layouts lets me replace /lib
<Chipaca> zyga-suse: mvo: which PR were you two discussing?
<zyga-suse> Chipaca: remember when you showed me a PR where you did methods on nils?
<zyga-suse> Chipaca: and I was surprised this is doable in go
<Chipaca> yes
<mup> PR snapcraft#1512 opened: pluginhandler: clean error for BasePlugin.run{,_output} <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1512>
<zyga-suse> mvo: ^
<ogra_> abeato, no idea, perhaps ask in the thread ?
<pedronis> afaik it's been postponed
<abeato> ogra_, ok, will do
<mvo> Chipaca: context is my review of 3808, most specically https://github.com/snapcore/snapd/pull/3808/files#r135463240
<mup> PR snapd#3808: apparmor,release: add better apparmor detection/mocking code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3808>
<mvo> Chipaca: and was curious in what context you use it. in the context of this pr I was mostly wondering why not just return by-value but mostly I wanted some context as this is/was a new pattern for me
<mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<zyga-suse> mvo, Chipaca: please let me know if you want me to change that code, otherwise I'll move on to other work
<mvo> meh, it looks like our update to github.com/snapcore/snapd/vendor/golang.org/x/sys/unix broke powerpc
 * mvo looks
<zyga-suse> aww, sucks
<zyga-suse> mvo: btw, golang 1.9 had some support changes for that arch
<zyga-suse> they dropped some older HW
<pedronis> mvo: we updated it because of the golang/x/crypto update, IÂ don't even think we needed it before
<pedronis> fwiw
 * pstolowski amazed by mvo's code review
<zyga-suse> Chipaca: hmm, why doesn't logger.Noticef print stuff?
<pstolowski> mvo, thank you for taking time & proposing the changes
<pstolowski> !
<mvo> pedronis: aha, thanks, that is good to know, I will investigate, its a bit of a bummer
<zyga-suse> Chipaca: but it does later
<zyga-suse> 2017/08/28 11:13:52.385942 daemon.go:275: started snapd/2.27.3+git744.gd34c3ddc6 (series 16; classic; devmode) opensuse/20170823 (amd64) linux/4.12.8-1-default.
<zyga-suse> that's the first message I see
<mvo> pstolowski: your welcome, my pleasure
<zyga-suse> but before that I call noticef + println in another spot and only the println shows up
<mwhudson> zyga-suse: 1.9 changed stuff around ppc64 big endian, which has never been an ubuntu architecture
<mvo> zyga-suse: go-1.9> things we should land?
<mvo> zyga-suse: in master I mean?
<zyga-suse> mwhudson: ah, good
<mwhudson> zyga-suse: this failure is about powerpc
<mwhudson> i.e. 32-bit
<zyga-suse> aha
 * zyga-suse shuts up then
<mwhudson> which stopped being an ubuntu architecture in ... zesty?
<mwhudson> it ought to be possible to add gccgo / powerpc support to sys/unix, i never figured out how to do it thouh
<mwhudson> (also didn't care overly much)
<mvo> mwhudson: powerpc we probably still need to support because of 16.04, the failures look slightly nasty: http://paste.ubuntu.com/25416387/
 * zyga-suse sees SetLogger
<mwhudson> mvo: x/sys/unix just doesn't support powerpc at all
<mvo> mwhudson: aha, great that you know more about this, so what are our options? can we avoid sys/unix somehow?
<mwhudson> mvo: i don't know which bit of crypto is using it
<Chipaca> mvo: sitting in the top of the tree, try: find -type f -name \*.go -print0 | xargs -0 perl -wne 'BEGIN{$n=0}; if ($n!=0) {$n=0; print "$ARGV: $f$ARGV: $_" if /if $v == nil/ }; if (/^func \((\S+) \*/) {$n=1; $f=$_; $v=$1}'
<Chipaca> zyga-suse: where doesn't logger.Noticef print stuff?
<mwhudson> mvo: support for other arches with gccgo has been added, so presumably the same can be done for ppc
<zyga-suse> woah
<zyga-suse> that's nice
<Chipaca> zyga-suse: it might be trying to print stuff before it's initialised?
<ogra_> mvo, i just noticed that the initramfs-tools-ubuntu-core deb is behind the git tree, androidboot is missing and there was no deb build after the unit tests branch landed ... if i push that to the PPA today do i disturb any release ?
<zyga-suse> Chipaca: I patched an init() function in a module to call it
<zyga-suse> Chipaca: I understand that during startup we actually init the logger
<Chipaca> yes
<zyga-suse> Chipaca: and I got the short end of the ordering stick
<Chipaca> probably
<zyga-suse> hmmm
 * zyga-suse wants the user warning framework
<zyga-suse> I could really use it now
<Chipaca> zyga-suse: is this in debugging snapd?
<zyga-suse> yes
<zyga-suse> well
<Chipaca> zyga-suse: just print it?
<mvo> ogra_: thanks for checking, things should be fine today
<zyga-suse> I want something more sticky
<zyga-suse> jdstrand requested that we log that we are on partial apparomr
<ogra_> mvo, ok, then i'll upload
<zyga-suse> "prominently" logged
<zyga-suse> Chipaca: I'll just print it with a comment
<pedronis> so the failing test now is passing, so probably a bunch of other tests might start failing, will see
<Chipaca> mvo: that pattern is used in our code in a few places where the expected use of a something includes it sometimes being nil
<ogra_> so i built a wine snap last night ...
<mvo> Chipaca: thanks, interessting, it escaped me so far
<ogra_> and since wine currently only does i386 i actually had to build for i386 ...
<Chipaca> mvo: so rather than having âartifact:=default; if thing != nil {artifact = thing.GetArtifact()}â, you move the check into GetArtifact
<ogra_> and i must say i have never had such a painful experience with snapcraft :/
<ogra_> (trying to build for i386 on amd64 host)
<pedronis> Chipaca: mvo:  go does it by static typing, but it exists as pattern since smalltalk (maybe even earlier), afaik it is liked/disliked ever since though
<Chipaca> ogra_: you know you can ship i386 binaries in an amd64 snap, yes?
<Chipaca> maybe that wasn't your issue :-)
<ogra_> Chipaca, but when buiolding from source you still need a i386 build env
<Chipaca> anyway, i'll shut up now, seeing as how i'm not really working
<mvo> Chipaca, pedronis: thanks, it makes perfect sense was mostly wondering a bit when/how to use it. thanks for your input on this :)
<Chipaca> ogra_: âapt install build-essential:i386â?
<ogra_> and i dont want the 79234846 build deps wine needs installed on my host ...
<Chipaca> ah
<ogra_> so i use cleanbuild
<ogra_> and then things explode
<ogra_> even using a plain lxd container as i386 system doesnt work properly
<ogra_> (there is an unfixed bug in libc)
<mwhudson> pedronis: smalltalk is a bit different though, messages sent to nil are all ignored, iirc?
 * zyga-suse suffers terrible network
<zyga-suse> just 2 days left
<zyga-suse> I'll be home by Wednesday
<pedronis> mwhudson: well, I was more referring to people adding implementation of things to nil
<pedronis> which you can
<mwhudson> ah
<pedronis> (unless I'm totally misremembering this)
<pstolowski> zyga-suse, - Run refresh hook of "core" snap if present (internal error: no registered handlers for hook "refresh")
<pstolowski> zyga-suse, ^ is that what you saw when refreshing core from stable to edge and back to stable?
<zyga-suse> yes
<zyga-suse> that's what I saw
<mup> PR snapd#3814 opened: interfaces: enable partial apparmor support <Created by zyga> <https://github.com/snapcore/snapd/pull/3814>
<zyga-suse> pstolowski: is that a release blocker?
<mvo> 3781 needs a second review, its very nice and not very long
<pstolowski> zyga-suse, afaict we don't have this hook in release/2.27
<pedronis> pstolowski: a blocker for 2.28
 * zyga-suse looks at 3781
<mvo> Chipaca: 3748 has a conflict
<pstolowski> pedronis, oh, for 2.28 yes
<pedronis> or for 2.27 if we decide we need to do something there
<pedronis> it seems this a problem that will show up again and again with new hooks
<pstolowski> yes
<zyga-suse> pedronis, pstolowski: are you suggesting a 2.27.5 with some future-proofing for hooks in general?
<zyga-suse> ahead of 2.28 release?
<pedronis> I don't know
<pedronis> I'm mostly musing
 * zyga-suse nods
<pstolowski> i'm not sure. i need to fully understand the problem. hook machinery is a little bit deceptive with the 'Optional' flag. clearly the registration of hook handlers is critical
<zyga-suse> optional feels like "may fail"
<zyga-suse> but we need to know it exists
<zyga-suse> which poses a problem for each added hook
<pstolowski> i have a feeling that the only way around this is to make a missing handler non-critical
<pedronis> if it's optional and the hooks doesn't exist in the snap, we don't care if the hook is registered or not
<pedronis> internally
<pedronis> but I don't remember the internal details to know if this is easy or not to tweak that way
<pedronis> it probably breaks abstractions
<pstolowski> uh oh we have a logic like this in place already, but i think it has a bug
 * tbr slaps chihchun_afk around a bit with a large and slimy trout. Dude, turn off your nick-changes. That annoys the crap out of people.
<zyga-suse> whee
<zyga-suse> let me try it on ubuntu now
<zyga-suse> mvo: I'm almost ready with 2.28 branches :)
<zyga-suse> mvo: how are we doing with release freeze/fork
<ogra_> zyga-suse, oh, did you tell pstolowski about the "refresh back to beta" image we found on the weekend ?
<ogra_> (i didnt file a bug)
<zyga-suse> ogra_: yes, I was wondering where I saw that
<ogra_> pstolowski, http://paste.ubuntu.com/25416803/
<zyga-suse> ogra_: was that on IRC? I couldn't find the discussion
<zyga-suse> ogra_: woot, thank you :)
<ogra_> this is when moving to edge (for a test) and then trying to go back to beta
<zyga-suse> mvo: ^ given this I would say we need to fix that for 2.28
<pstolowski> ogra_, yeah, that's the issue i'm looking on. nb, you can of course snap revert core
<ogra_> a revert would switch channels ?
<mvo> zyga-suse: sounds like something we need to 2.28, yes. I understand pstolowski is looking into it(?)
<pstolowski> ogra_, no, just mentioning, it won't fail that way
<ogra_> right
<pstolowski> mvo, yes, i think i've a fix
<ogra_> it only fails when moving to edge and trying to go back though ...
<ogra_> (i doubt it affects the beta/candidate or stable channels yet)
<zyga-suse> ogra_: and by extension it will fail when CE will test rollback from 2.28
<ogra_> right
<fgimenez> hey mvo, looks like CE QA found an issue with 2.27.4, i've just forwarded you the message
<mvo> Chipaca: http://paste.ubuntu.com/25416853/ is probably something we need to fix for 2.28
<mvo> fgimenez: thanks, let me have a look
<zyga-suse> fgimenez: can this be public somewhere please?
<zyga-suse> mvo: also FYI, not for 2.28 (needs research first) but important as it breaks containers: https://bugs.launchpad.net/snapd/+bug/1712930
<mup> Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:In Progress by zyga> <https://launchpad.net/bugs/1712930>
<fgimenez> zyga-suse: not sure better ask them, they are posting to snap-update-verification@lists.canonical.com, maybe you can subscribe?
<zyga-suse> fgimenez: I mean, I could do that but then again we have https://forum.snapcraft.io/t/in-progress-snapd-2-27-4/572 that everybody should post to
<mvo> zyga-suse: hm, is this just changing the order of things (ideally switching two lines). or is there more work involved here?
<fgimenez> zyga-suse: yeap, i already mentioned them about the forum and the release threads but don't know about how (or if) they make their test results public, they can explain better for sure :)
<zyga-suse> mvo: not sure if this is just two lines :)
<zyga-suse> mvo: could be trivial or very complex, I didn't look yet
<mvo> ok
<mup> PR snapcraft#1513 opened: lifecycle: outdated step should raise SnapcraftError <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1513>
<mup> PR snapd#3815 opened: tests: install test-snapd-complexion on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3815>
<mvo> Chipaca: trivial reproducer -^
<zyga-suse> hmmmmmmm
 * zyga-suse is unhappy about https://travis-ci.org/snapcore/snapd/builds/269141620?utm_source=github_status&utm_medium=notification
<pedronis> mvo: I think it's an holiday for John
<zyga-suse> is that just another bug in apparmor profile loading for tests
<zyga-suse> or a real issue
<zyga-suse> indeed
<mwhudson> mvo: i wrote up that dput linter wrapper thing I talked about before https://gist.github.com/mwhudson/616499edb1191bd99c987bbbd8781ce9
<zyga-suse> he is off
<mvo> pedronis: oh, thanks
<mvo> Chipaca: weeeh, sorry - you are off today? I won't bother you anymore
<mvo> mwhudson: nice
<zyga-suse> mvo: question, will we re-load snap-confine's apparmor profile before configuring core?
<mup> PR snapd#3816 opened: hooks: do not error out when hook is optional and no hook handler is registered <Created by stolowski> <https://github.com/snapcore/snapd/pull/3816>
<pstolowski> zyga-suse, mvo ^ this should fix the problem with hooks, but I only tested with unit test
<mup> PR snapd#3817 opened: tests: wait more and more debug info about fakestore start issues <Created by pedronis> <https://github.com/snapcore/snapd/pull/3817>
<mup> PR snapcraft#1510 closed: ci: disable the travis deploy stage for docs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1510>
<mup> PR snapcraft#1508 closed: schema: version should have a max length of 32 <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1508>
<cachio> mvo, did you see the email I fw?
<mvo> zyga-suse, spineau, jdstrand: so I think I have an idea about the problem with "sudo network-manager.nmcli d show eth0" getting denies on 2.27 - we enabled seccomp argument filtering for socket. and the profile has "#  socket AF_NETLINK - -" and I assume that nmcli uses the netlink socket
<mvo> cachio: indeed I did and after a small panic I started debugging
<cachio> mvo, ohhh, any finding?
<mvo> cachio: yes, maybe, I think I need jdstrand to help me, but I suspect we need to enable socket AF_NETLINK at least for nmcli, maybe for more.
<cachio> mvo, is this caused because the last change done for 2.27.4?
<zyga-suse> mvo: there's a new set of netlink interfaces
<zyga-suse> mvo: maybe those are sufficient there
<zyga-suse> mvo: I wish we knew the values of other arguments but I suspect I can easily check that locally
<zyga-suse> mvo: (if it is netlink or not)
<zyga-suse> mvo: AFAIK it used KOBJECT_UEVENT but perhaps I'm wrong
<spineau> mvo: like mmcli? that's the first one I can think of
<zyga-suse> mvo: note that jamie is off today, I'll check it out after checking out one other thing
<zyga-suse> mvo: if you can strace it on your machine and pastebin that it would be sufficient
<spineau> zyga-suse: mvo: I'm still connected to our test device, if I can help you by providing more logs, just ask
<zyga-suse> spineau: thank you, if you know how to run strace under snap confinement (not trivial) then please do that
<zyga-suse> spineau: you need to edit the seccomp/apparmor profiles, allow extra stuff and run strace you get from the host somehow
<zyga-suse> spineau: don't worry if you don't want to go through those hoops
<spineau> zyga-suse: unfortunately, I'm still a snap newbie
<mvo> zyga-suse: strace is not working for me, hangs
<mvo> zyga-suse: when I enable AF_NETLINK things work
<zyga-suse> mvo: strace needs some love, ok
<mvo> zyga-suse: socket AF_NETLINK - -
<mvo> zyga-suse: if that is part of the profile things work
<zyga-suse> mvo: note that we don't have any interfaces that add that
<zyga-suse> mvo: we have "socket AF_NETLINK - NETLINK_AUDIT" and similarly NETLINK_CONNECTOR
<zyga-suse> we need to know which one is really required
<zyga-suse> mvo: and perhaps consider an approach (new release of network-manager or a snap-id specific quirk)
<willdeberry> so it seems that everything was passing, but since I have been rebasing just to keep things fresh, travis build now fails: https://github.com/snapcore/snapd/pull/3812
<mup> PR snapd#3812: Expose bluez interface on classic OS <Created by willdeberry> <https://github.com/snapcore/snapd/pull/3812>
<zyga-suse> mvo: offtopic
<pedronis> niemeyer: will you create a tracker topic in the forum for the current PRs?
<zyga-suse> mvo: I updated my x250 to zesty
<zyga-suse> mvo: and ... the update removed xorg-input-all
<zyga-suse> mvo: that was curious to debug
<zyga-suse> mvo: apparently people ran into this too and I found lots of forum posts and what not
<zyga-suse> mvo: so now things work
<zyga-suse> mvo: when you don't have xorg-input-all and its deps you have GDM/lightdm with *no* keyboard interaction at all
<zyga-suse> not even alt-ctrl-f2 to get out
<niemeyer> pedronis: I'm on the fence about it.. I want to make sure we take it as an actual sprint if it's added, and given all the work on the release we may not be able to do it
<zyga-suse> aha, so I know what is wrong with the spread setup, nothing, it looks like a very odd and curious apparmor behavior
<niemeyer> pedronis: Perhaps we can kick it off once the release is clean?
<pedronis> niemeyer: ok, just wondering because I start to have a bit of hard time finding/remembering what to review
<niemeyer> pedronis: Aha, I see
<niemeyer> pedronis: Let me create one then
<mup> PR snapd#3818 opened: interfaces: fix network-manger plug <Created by mvo5> <https://github.com/snapcore/snapd/pull/3818>
<mup> PR snapd#3819 opened: hooks: do not error out when hook is optional and no hook handler is registered (2.27) <Created by stolowski> <https://github.com/snapcore/snapd/pull/3819>
<mvo> 3260 needs a second review, tests are green now
<mvo> zyga-suse: 3818 is maybe what we need to fix the nmcli issue, an early look  is appreciated, I mostly opened it to get spread tests running
<zyga-suse> mvo: ack
<pedronis> snapd#3817 needs quick a review (it's about the fakestore tests that were sill failing sometimes for me in autopkgtests)
<mup> PR snapd#3817: tests: wait more and more debug info about fakestore start issues <Created by pedronis> <https://github.com/snapcore/snapd/pull/3817>
<zyga-suse> re-started something else and looking
<niemeyer> Forgot to ask.. did we have any other issues on the testing infra after the Spread changes I did on Friday?
<ogra_> wow, cool ...
<ogra_> seems my wine snap really works with all exe installers i have lying around ... and all install just go fine to SNAP_USER_DATA
<ogra_> *all installs
<mvo> ogra_: thats very neat, wine is a nice snap to have
<ogra_> well, needs --devmode
<ogra_> (or --classic, but i didnt feel like making a classic snap)
<ogra_> it wants to read / and /boot
<mvo> makes one wonder why that :)
<ogra_> but it it really cool that you can just install wine 2.15 next to the deb one
<ogra_> because it can put .desktop files in place and such
<ogra_> for apps it installs
<mvo> yeah, also wine might be perfect for tracks, i.e. being able to install 2.0, 2.1, etc
<ogra_> yeah
<ogra_> i only did it out of curiosity ... but there is a snapcraft source tree now that someone can take and make something real out of it
<ogra_> our forum doesnt work with the sippped wine IE :/
<ogra_> *shipped
 * mvo nods
<ogra_> "your browser is to old" :P
<ogra_> snapcraft.io itself and ubuntu.com work fine
<mup> PR snapd#3817 closed: tests: wait more and more debug info about fakestore start issues <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3817>
<zyga-suse> mvo: re, thank you for checking it is UEVENT
<zyga-suse> let me look at something related and I will review this
<mvo> zyga-suse: no real rush, I want to see the test results first, maybe its actually not working
<zyga-suse> I commented
<mvo> zyga-suse: aha, indeed, silly me, you are right. I will fix
<zyga-suse> thanks!
<zyga-suse> I checked other interfaces
<zyga-suse> they all use permanent snippet but for slot
<zyga-suse> for plug I think it's fine to keep this on connected
<mup> PR snapcraft#1514 opened: docs: add github processed templates <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1514>
<mup> PR snapd#2807 closed: snap: add new `snap switch` command <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2807>
<mup> PR snapd#3820 opened: spread: don't set HTTPS?_PROXY for linode <Created by zyga> <https://github.com/snapcore/snapd/pull/3820>
<zyga-suse> mvo: ^ trivial one
<zyga-suse> tested locally
<zyga-suse> mvo: looking at the ordering issue now
<mvo> zyga-suse: great, thank you!
<mvo> zyga-suse: I'm waiting for tests and I think 3818 will need a review from jamie as well, right?
<zyga-suse> yes
<zyga-suse> note that jamie is off today
<niemeyer> pedronis: https://forum.snapcraft.io/t/review-sprint-3/1880
<pedronis> niemeyer: thanks
<niemeyer> pedronis: No problem.. tweaked the format slightly as apparently the recent changes in Discourse modified some of the old icons we were using, but still same thing
<mup> PR snapd#3821 opened: tests: new regex used to validate the core version on extra snaps ass <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3821>
 * zyga-suse moved indoors, too cold 
<soee> hi, i have installed an app via snap and have this: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<soee> any idea what is wrong ?
<zyga-suse> hey
<zyga-suse> soee: let me try to help you
<zyga-suse> soee: can you start by running "snap version" and pasting the result
<Chipaca> mvo: ah! so on core we need to not do the snippets (and source complete.sh)
 * Chipaca disappears again
<cachio> pedronis, hey, any idea why this error could be happening runing tests on staging ?
<cachio> error: cannot fetch snap signatures/assertions: circular assertions are not expected: account (canonical)
<pedronis> cachio: sounds it's not using the right kind of snapd
<pedronis> maybe reexec doing something wrong
<pedronis> cachio: fwiw I used a correctly built snapd against staging on Friday and things worked
<pedronis> snapd built from master
<cachio> pedronis, how did you setup the tests?
<cachio> pedronis, which variables did you use?
<cachio> I want to replicate that into the sread-cron tests against staging
<pedronis> cachio:  afair  the test setup should do the right thing, there are two part to this,  you need a snapd built with withtestkeys or withstagingkeys
<pedronis> cachio: then you need SNAPPY_USE_STAGING_STORE=1
<cachio> pedronis, I have that
<cachio> export SPREAD_REMOTE_STORE=staging
<cachio> it is traduced into  SNAPPY_USE_STAGING_STORE=1
<pedronis> and DEB_BUILD_OPTIONS='nocheck testkeys' dpkg-buildpackage -tc -b -Zgzip
<pedronis> the testkeys should do the other part
<pedronis> I need a bit more details where this exactly is breaking? breaking early or in some specific test?
<pedronis> anyway IÂ need to go have dinner
<cachio> pedronis, on those tests https://travis-ci.org/snapcore/spread-cron/builds/268521976#L1224
<cachio> there are many tests failing for he same reason
<pedronis> cachio: I'll look in my morning
<cachio> pedronis, sure, tx
<cachio> I am taking a look right now too
<pedronis> notice that some are other platforms
<pedronis> IÂ mean != ubuntu
<pedronis> I don't think it makes sense to run those tests against staging
<pedronis> like that failure is for opensuse
<pedronis> IÂ don't know if it knows how to build a staging snapd
<cachio> ok
<cachio> pedronis, i'll change that too, thanks
<pedronis> cachio: I mean until we understand more IÂ would skip anything not ubuntu  for staging tests
<cachio> pedronis, sure
<pedronis> the main user of these tests would be store after a staging deployment
<pedronis> I think they have been too flaky to use them tough :/
<cachio> pedronis, yes, agree
<cachio> most of them have been failing for a while
<cachio> pedronis, I think staging should be used just to validate some specific stuff
<cachio> pedronis, so it is easier to keep it in green
<zyga-suse_> hmm
<zyga-suse_> - Run install hook of "core" snap if present (internal error: no registered handlers for hook "install")
<zyga-suse_> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170828_165347_9cd1b@/log.gz
<zyga-suse_> from upgrade/basic
<stormmore> How difficult would it be to write a snap that can read /etc with making using --classic?
<mup> PR snapd#3821 closed: tests: new regex used to validate the core version on extra snaps ass <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3821>
<niemeyer> stormmore: With classic or without classic?
<niemeyer> pedronis, zyga-suse_, cachio: Review board now has details on who's reviewing or needs to review
<cachio> niemeyer, nice
<stormmore> niemeyer: preferably without
<niemeyer> stormmore: That needs an interface for the specific need you have.. many are already available, but it may need to be created as well if it's not yet there
<niemeyer> stormmore: With classic, it's just a matter of opening the files.. nothing fancy to be done
<stormmore> niemeyer: whats a good place to see a list of interfaces. I did look there as that was what I was suspecting but I didn't find one that would give even read-only (not sure that is going to be sufficient for my needs yet but gotta start somewhere) access to /etc from their desc
<niemeyer> stormmore: No interface will give access to all of /etc
<niemeyer> stormmore: Some will give access to specific bits inside /etc, according to their described purpose
<stormmore> niemeyer: ah that is why I am probably leaning towards making this a classic snap (at least initially)
<niemeyer> stormmore: Yeah, it's a fine way to get started
<stormmore> niemeyer: thanks, just wanted to see if there was a "better way" but looks like I was on the right track
<mup> PR snapd#3120 closed: [WIP] interfaces/hooks: expose attrs to the interface API, snapctl enhancements (step #4) <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3120>
<zyga-suse_> niemeyer: wow, that's nice
<zyga-suse_> WOW, way nicer than I expected :D
<zyga-suse_> really nice work :)
<zyga-suse_> niemeyer: I wonder what will happen when we have initial clashes in the team
<niemeyer> zyga-suse_: Wow, thanks :)
<niemeyer> zyga-suse_: You mean more than 26 reviewers? ;P
<zyga-suse_> well, if we get another zygmunt, will we call him z^1 ;D
<niemeyer> zyga-suse_: We already have clashes.. look closely
<niemeyer> and apparently we also have a bug.. something is wrong with #3260.. looking
<zyga-suse_> ah, indeed
 * zyga-suse_ is happy that zygmunt is an uncommon word and his life is simple here
<cachio> niemeyer, do you know which is the job to sync prod with staging stores?
<pedronis> cachio: there's no such job
<cachio> pedronis, ok, is it a manual procedura?
<pedronis> yes, we typically add relevant snaps to staging
<pedronis> staging store and prod store are fairly indepedent
<cachio> ok, so I should download/upload the snaps
<cachio> pedronis, I'll try that
<pedronis> anyway probably another good reason to cut down staging tests
<cachio> pedronis, yes
<cachio> pedronis, if it is not automatic, it does not scale
<pedronis> not sure how to do that though, spread doesn't have more tagging than manual
<pedronis> skipping support is also missing, our skips atm ad hoc
<pedronis> one approach could be just have a different suite and symlinks
<cachio> pedronis, why we are running tests against staging?
<cachio> pedronis, if there is not something new to test on there the best we can do is to remove those execution from spread-cron as you suggested
<pedronis> cachio: ?  the idea was to run them each time one of the store services gets a new staging deploy ?
<pedronis> that's what triggers runs
<pedronis> to check that changes to the store don't break the contract with snapd
<pedronis> that was the idea
<cachio> pedronis, makes sense
<pedronis> yes, it's a sound idea, the executation hasn't been amazing so far though, also probably too many not relevant tests
<cachio> so, we just need to keep the databases synchronized
<pedronis> and also the store has changed, so we need different checks
<pedronis> cachio: ?
<pedronis> don't think that's going to happen
<cachio> pedronis, I mean, perhaps the solution is to add a job to keep both in sync
<pedronis> we can add something that keeps some subset of snaps in sync
<pedronis> but in general afaik there's no plan to keep them generally in sync
<cachio> pedronis, otherwise always when we do a change in a snap we need to make that same change in staging
<cachio> is it correct?
<pedronis> that's how we did so far, yes
<cachio> pedronis, ok
<cachio> pedronis, what do you suggest, disable the staging jobs? or continue doing that sync manually? or start doing something to keep it on sync
<pedronis> cachio: I think we need to take a step back and setup a meeting with the stakeholder interested in that
<pedronis> it's not about what *I* suggestÂ 
<pedronis> *stakeholders
<cachio> pedronis, ok, makes sense, how are the interested stakeholders?
<cachio> who
<cachio> celso?
<pedronis> I can ask tomorrow
<cachio> pedronis, sure
<cachio> let's talk about that tomorrow
<niemeyer> Okay, figured the issue and fixed.. board updated again, with correct data.
<mup> PR snapd#3760 closed: Allow snap-confine to be confined even with --disable-apparmor <Created by mwhudson> <Closed by mwhudson> <https://github.com/snapcore/snapd/pull/3760>
<mup> PR snapd#3260 closed: cmd/snap: implement userd command as replacement for snapd-xdg-open <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3260>
#snappy 2017-08-29
<stormmore> ok what I am missing, I am trying to creatte a classic snap. it builds but after I install it using --classic --dangerous and try and run the command it keeps getting unable to allocate memory errors after hanging for a while?
<mup> PR snapd#3819 closed: hooks: do not error when hook handler is not registered (2.27) <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3819>
<mup> PR snapcraft#1515 opened:  tests: use a fake pip, instead of mocking everything <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1515>
<mvo> mwhudson: so I checked and it looks like x/crypto/ssh/terminal brings in x/sys/unix - for 2.28 I need to find a way to make this build again on powerpc. I will poke a bit to see what can be done
<mup> PR snapd#3822 opened: vendor: use old golang.org/x/crypto/ssh/terminal to build on powerpc again <Created by mvo5> <https://github.com/snapcore/snapd/pull/3822>
<zyga-suse> good morning, sorry for a late start, had some woes with kids
<zyga-suse> mvo: I saw some concenring test failures again
<zyga-suse> mvo: I assumed it was caused by my branch but then it failed only partially,
<mvo> zyga-suse: what failures are those?
<zyga-suse> mvo: if you look at https://github.com/snapcore/snapd/pull/3621 you will see that upgrade/basic failed with Run install hook of "core" snap if present (internal error: no registered handlers for hook "install")
<mup> PR snapd#3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<zyga-suse> the latest rebuild didn't fail this way
<zyga-suse> the log is in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170828_165347_9cd1b@/log.gz
<zyga-suse> I'm worried there's still a race somewhere that we don't handle
<zyga-suse> I'll look at the code there and try to figure out what must happen for this to show up
<mvo> zyga-suse: it seems like 3816 has not landed yet, so seening this error seems to be ok still. or am i missing something?
<mvo> zyga-suse: but yeah, please do go ahead
<mvo> zyga-suse: and see if you can find out more
<zyga-suse> mvo: not sure if this is really related,
<mvo> ok
<zyga-suse> that PR was to fix rollback/downgrades
<zyga-suse> here we fail on upgrade
<zyga-suse> so I suspect the mechanism of the failure is different
<Chipaca> woo! go tyhicks
<zyga-suse> hey Chipaca :)
<zyga-suse> what is that about?
<Chipaca> zyga-suse: recent seccomp efforts coming together
<zyga-suse> ah, indeed
<pedronis> zyga-suse: as far has me know that happend when changelog has the wrong version, so reexec doesn't work
<pedronis> s/has me/as we/
<zyga-suse> pedronis: ah! perhaps that may explain it, I merged master later on
<zyga-suse> thank you!
<mvo> Chipaca: hey, good morning!
<mvo> Chipaca: would love to get your advice on 3815 - but ready when you are :)
<mup> PR snapd#3816 closed: hooks: do not error out when hook is optional and no hook handler is registered <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3816>
<mup> PR snapd#3750 closed:  snapstate: integration test for undoing a daemon restart on classic <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3750>
<mvo> mwhudson, pedronis: the powerpc build failure (because of the crypto update) should be fixed with 3822 - slightly ugly though
<Chipaca> mvo: so... on core, source complexion.sh from /etc/skel/.bashrc ?
<Chipaca> completion.sh i mean
<mvo> Chipaca: yeah, that might be an option, will not help with exiting installs, but otherwise nice and simple
<mvo> Chipaca: does the PR look otherwise ok? if it does I would love to see it merged as it blocks a lxd test
<pedronis> Chipaca: hi
<Chipaca> mvo: me, I would've done it differently, but it's fine as it is
<pstolowski> mvo, hey, 3773 has a conflict
<Chipaca> mvo: I mean, I would've looked at having osutil.IsWritable(dirs.CompletersDir) or somesuch
<mvo> Chipaca: happy to do it differently, what would be your approach?
<mvo> Chipaca: aha, even better, yeah, let me do that
<Chipaca> mvo: but that is more work :-)
<mvo> pstolowski: thanks, checking
<mvo> Chipaca: thats fine if quality(more_work) > quality(less_work) :)
<Chipaca> mvo: but if that existed, then noCompletion := !osutil.IsWritable(dirs.CompletersDir) || !osutil.FileExists(dirs.CompleteSh)
<Chipaca> mvo: and the rest stays unchanged
<mvo> Chipaca: indeed, I will tweak
<mvo> Chipaca: do you think we should rename "complexion" to "test-snapd-complexion" or just ignore that for now?
<zyga-suse> hopefully back
<zyga-suse> I learned that the new mac randomization thing doesn't love me
<Chipaca> mvo: if it goes to the store, it needs renaming
<mvo> zyga-suse: fwiw, I looked into the mount issue that lxd reported yesterday and it looks like real work (not just change two lines) :/
<Chipaca> mvo: if it doesn't go to the store i don't care :-)
<mvo> Chipaca: I think I could tweak things so that it does not have to go through the store
<mvo> Chipaca: I have a look
<Chipaca> mvo: ah, i see it's already in the store?
<zyga-suse> mvo: I came to the same conclusion
<zyga-suse> mvo: I plan on working on that today
<mvo> Chipaca: yes, but we can unpublish it again
<Chipaca> mvo: if /tests/lib/snaps/complexion and test-snapd-complexion are the same thing, then yes let's rename the former
<mvo> Chipaca: they are - ok, that works for me, I will tweak the branch
<Chipaca> ok
<Chipaca> pedronis: i know my pr has a conflict, but i'm also slight blocked waiting for a store issue so i'm in no hurry to deconflict it right now
<Chipaca> as if that landed some people might panic
<Chipaca> maybe i should label it
<Chipaca> first coffee, then label
 * Chipaca goes
<mvo> zyga-suse: do you have a plan yet? it seems like we may need to get back and add a "WantedBy=local-fs-pre.target" with a special "snap-confine ensure-shared-mounts" (or snap-helper or somesuch). or what do you have in mind?
<zyga-suse> no plans yet, I'm still hoping we can do this somehow from snap-confine alone
<zyga-suse> even if it requires more wokr
<mvo> zyga-suse: AIUI the problem is that systemd itself will load all the mount units at the same time (or before) it starts the daemons. so when snap-confine runs and fixes the /, /snap rshare thing stuff is already mounted there and that causes the havoc
<mvo> zyga-suse: so AFAICS we need to tweak the system boot ordering to make sure the remount happens earlier
<mvo> pstolowski: 3773 is de-conflicted
<zyga-suse> mvo: remember that snap-confine can remount anything inside its namespace so ... well, I need to look really
<pstolowski> mvo, thx!
<mvo> zyga-suse: ok
 * zyga-suse fights his network plan
<pedronis> Chipaca: let's mark it blocked then
 * zyga-suse wonders if anyone wants to review https://github.com/snapcore/snapd/pull/3621
<mup> PR snapd#3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<zyga-suse> mvo: ^ that's my top priority for 2.28 feature
<zyga-suse> just to see if it breaks people
<mvo> zyga-suse: I would prefer the https://discuss.linuxcontainers.org/t/snapd-cant-remove-old-revisions-when-running-inside-lxd/452/3 fix first
<zyga-suse> mvo: sure but 3621 doesn't need any work from me anymore
<mvo> zyga-suse: aha, cool
<zyga-suse> mvo: as I said I'm working on that, I only meant that that review is my only one that counts for 2.28 so far
<mvo> zyga-suse: aha, I see. this is the thing you taged for 2.28, thats fine
<zyga-suse> yes
<mup> PR snapd#3818 closed: interfaces: fix network-manager plug <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3818>
<pedronis> 3621 needs a jdstrand review though
<mvo> zyga-suse: do you think we need input from jdstrand for 3818 ?
<zyga-suse> hmmm, sorry, perhaps yes
<zyga-suse> I was closing my tabs and I saw 2+1's
<zyga-suse> and since this affects all plugs, it's something we should still ask jamie about
<mvo> zyga-suse: no worries, lets just make sure we do not release before he had a chance to weight in :)
<zyga-suse> +1
 * zyga-suse is fed up with the network, wants to call it quits and have a walk
<zyga-suse> I was trying to git push/pull for the past ten minutes
<pedronis> mvo: what's the state of snapd#3625 ? at least one of the snapcraft PRs it mentions isn't merged yet
<mup> PR snapd#3625: many: end-to-end support for the bare base snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/3625>
<pedronis> is it blocked?
<mvo> pedronis: yes, it is blocked right now :/
<zyga-suse> mvo: do we need any design for that
<zyga-suse> mvo: or just some coding?
<zyga-suse> it would be great if 2.28 had _a_ level of base snap support
<pedronis> you are getting ambitious there
<pedronis> Chipaca: do you plan to still do something in snapd#3398 ?
<mup> PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398>
<pedronis> it seems unclear if it needs more work OTOH it has 2 +1
<mvo> zyga-suse: with 3625 we would have basic support, the snapcraft stuff is only needed for specialized tests, I can make simpler tests
<zyga-suse> mvo: not sure if priority, just saying it would be nice
<mvo> zyga-suse: I think the two of us need to agree on how snap-confine should handle bases :) then this is good to go, I would love to have it for 2.28 as well and it seems like we are close
<zyga-suse> ok, let's try to discuss this in 2-3 hours
<mvo> zyga-suse: sounds good!
<mvo> pedronis: yeah, I will sort it out, if zyga and I can agree on snap-confine I will just write simpler tests for now until snapcraft is ready
<mvo> zyga-suse: welcome back
<mvo> zyga-suse: in 2-3h sounds good
<zyga-suse> mvo: it will likely be an IRC/telgram audio call
<mvo> zyga-suse: sure
<pedronis> what should happen with snapd#3617 ?
<mup> PR snapd#3617: interfaces/builtin: use udev tagging more broadly <Created by adglkh> <https://github.com/snapcore/snapd/pull/3617>
<pedronis> it's marked for 2.28
<mvo> zyga-suse: I know your bandwidth is limited currently, we can just discuss by typing
<mvo> pedronis: wasn't it just one extra change that needed backing out, otherwise it was ok? if so, I guess I could do that
<pedronis> I don't know, I suppose zyga knows
<pedronis> it says to remove the opengl stuff
<zyga-suse> hmm? opengl stuff
<zyga-suse> ah
<zyga-suse> I see
<zyga-suse> let me look at what needs doing on that PR
<zyga-suse> it is a major change and bugfix for CE
<zyga-suse> aha
<pedronis> anyway lots of PRs needing jdstranda afaict
<pedronis> Chipaca: did you see my question?
<Chipaca> i did not
<pedronis>  Chipaca: do you plan to still do something in snapd#3398 ?
<mup> PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398>
<Chipaca> pedronis: working on it right now
<pedronis> ah ok
<Chipaca> i'm going to need zyga and morphis' help to test this, at least
<Chipaca> but it should work :-)
 * Chipaca shoves it at linode
<pedronis> mvo: I'm going to tentatively merge snapd#3697
<mup> PR snapd#3697: docs: add PULL_REQUEST_TEMPLATE.md <Created by mvo5> <https://github.com/snapcore/snapd/pull/3697>
<mvo> pedronis: ta!
<mup> PR snapd#3697 closed: docs: add PULL_REQUEST_TEMPLATE.md <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3697>
<mup> PR snapd#3823 opened: tests: rename complexion to test-snapd-complexion <Created by mvo5> <https://github.com/snapcore/snapd/pull/3823>
<mup> PR snapcraft#1516 opened: lxd: LXD not installed when using remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1516>
<mvo> Chipaca: 3815 is ready for you
<mvo> Chipaca: but no rush, its lunchtime here I think
 * Chipaca ~> break & lunch
 * zyga-suse_ considers taking today off
<mvo> zyga-suse_, pedronis: I updated/de-conflicted 3617, this should be ready to do in now (waiting for tests still). but it has two +1 and looks sensible overall
<zyga-suse> mvo: I'm going to call it quits today
<zyga-suse> I'm just frustrated
<zyga-suse> trying to fix my network
<zyga-suse> need to put my mind at ease
<mup> PR snapd#3824 opened: Do not match any file or directory in or under /sys/bus/pci/devices/ <Created by adglkh> <https://github.com/snapcore/snapd/pull/3824>
<mup> PR core#55 opened: Create mount points for use in exposing host system fontconfig <Created by jhenstridge> <https://github.com/snapcore/core/pull/55>
<Chipaca> mvo: install-store seems really unhappy in snapd#3815
<mup> PR snapd#3815: wrappers: ensure bash completion snaps install on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3815>
<Chipaca> mvo, morphis_, zyga-*, would appreciate your input on snapd#3398
<mup> PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Blocked> <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398>
<jdstrand> mvo: re nmcli: trunk has 'socket AF_NETLINK - -', so does release/2.27
<jdstrand> mvo: if this is on 2.27, then something isn't regenerating the policy
<pedronis> jdstrand: there's a branch for you to look at
<pedronis> jdstrand: https://github.com/snapcore/snapd/pull/3818
<mup> PR snapd#3818: interfaces: fix network-manager plug <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3818>
<jdstrand> pedronis: ok
<pedronis> it was merged a bit too quickly but as far I understood mvo is waiting on your feedback there
<jdstrand> mvo: so, it looks like snap.network-manager.networkmanager.src has 'socket AF_NETLINK - -', but snap.network-manager.nmcli.src does not
<jdstrand> mvo: let me check the plugs, hold on
<jdstrand> mvo: ah, yes, only the networkManagerPermanentSlotSecComp has 'socket AF_NETLINK - -'
<jdstrand> mvo: nmcli may need an AF_NETLINK rule
<jdstrand> (weird, people tested that)
<jdstrand> mvo: I'll look into it and send something up
<jdstrand> oh, you sent it up
<jdstrand> KOBJECT_UEVENT, yeah, that's fine
 * jdstrand comments
<jdstrand> pedronis, mvo: +1d
<jdstrand> mvo: thanks for looking into that
<pedronis> Chipaca: mvo:  snapd#3815 needs a master merge now ?
<mup> PR snapd#3815: wrappers: ensure bash completion snaps install on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3815>
<Chipaca> pedronis: yeah, that's what we said in the standup i think
<Chipaca> niemeyer: may I be curious and ask how you generate the review sprint page?
<niemeyer> Chipaca: Go application that talks to both APIs
<Chipaca> niemeyer: sounds very credential-y
<Chipaca> niemeyer: i might have formatting suggestions, but i'll create them by hand before suggesting we code them
<niemeyer> Chipaca: Not too much.. luckily both ends have simplified versions of the full fledged auth that just requires a token
<Chipaca> also, not now, now -> reviews
<niemeyer> Chipaca: That's generally what I do too
<niemeyer> Chipaca: (looking at them by hand first)
<Chipaca> niemeyer: snapd#3398 is the pr i mentioned in the standup, btw
<mup> PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398>
<Chipaca> it _has_ two greens, but the conversation in the pr prompted the extra work
<niemeyer> Chipaca: Thanks
<mvo> pedronis: I do the master merge now
<mvo> jdstrand: thanks a bunch
<mvo> jdstrand: I will backport that to 2.27 now
<ogra_> popey, hmm ... didnt oyu once have a xonotic ansp (or do i mis-remember)
<ogra_> *snap
<ogra_> snap find doesnt reveal one
<popey> yes
<popey> not in the store, because it was too huge
<popey> I didn't optimise the assets iirc
<popey> not looked at it for a few months though., i think flexiondotorg has looked at it more recently than me, and had other issues
<ogra_> ah, is size an issue ?
<ogra_> (apart from taking long for uploads)
 * popey pokes flexiondotorg 
 * flexiondotorg feels a poke in ribs.
<popey> I was going for a headshot, but okay
<flexiondotorg> Yep, I did start a Xonotic snap.
<flexiondotorg> https://code.launchpad.net/~flexiondotorg/+junk/snap-xonotic
<flexiondotorg> Haven't tested it recently. BUt last time I did there was no audio.
<popey> oh that was it
<ogra_> ah
<flexiondotorg> Could well be fixed now, I've not tested in ages.
<ogra_> well, i was just curious, thanks
 * popey kicks off a build to see
<ogra_> (i was pondering to package stage9 ... but it is 1.9G big so collecting some info about possible probs in advance)
<mvo> Chipaca: 3398 looks great
<Chipaca> mvo: just saw your comments; replying
<mvo> a review for 3822 would be nice
<mvo> Chipaca: my comments are mostly nitpick, I think this can go in
<Chipaca> whoops, something is buggy in 3398
<Chipaca> tests failures look scary-real
<niemeyer> Chipaca: Btw, on #3398, if there's extra work, the easiest way to make that clear is to just send another review saying Request Changes
<niemeyer> Chipaca: This would put both GH and the board in the right state
<niemeyer> mvo: Looking
<niemeyer> Btw, just updated the board icons style.. seems much better now..
<niemeyer> Much easier to see the work
<Chipaca> hmm, liked the grey blank box more than the questionmark, but otherwise it does seem clearer, yes
<Chipaca> mvo: who groks the 14.04 delta?
<mvo> Chipaca: nobody, code duplication == pain :/
<Chipaca> mvo: asking because I'd like to go over the diffs in rules and etc and make sure they're ok
<mup> PR snapcraft#1513 closed: lifecycle: outdated step should raise SnapcraftError <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1513>
<Chipaca> mvo: e.g. there's a block that re-sets VENDOR_ARGS in 14.04, that seems suspicious
<Chipaca> in fact it looks like a whole block is dupe'd
<Chipaca> mvo: i'll figure it out :-)
<mvo> Chipaca: thank you, much appreciated
<Chipaca> just a SMOP, and tea
<mup> PR snapd#3822 closed: vendor: use old golang.org/x/crypto/ssh/terminal to build on powerpc again <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3822>
<mup> PR snapcraft#1505 closed: errors: introduce ContainerError <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1505>
<mthaddon> hi folks - would this be the right place to ask about getting https://bugs.launchpad.net/snapd/+bug/1699768 backported to xenial? It's a dependency for some k8s charm work
<mup> Bug #1699768: "snap set" causes snapd crash <snapd:Fix Released by stolowski> <snapd (Ubuntu):New> <snapd (Ubuntu Xenial):New> <https://launchpad.net/bugs/1699768>
<Riddell> https://blog.neon.kde.org/index.php/2017/08/29/great-web-browsing-coming-back-to-kde-with-falkon-new-packaging-formats-coming-to-kde-with-snap/
<mup> PR snapd#3815 closed: wrappers: ensure bash completion snaps install on core <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3815>
<Chipaca> mthaddon: xenial is what we ship to, so i'd assume it's getting backported
<Chipaca> mthaddon: mvo might know more
<Chipaca> mthaddon: also, hi :-)
<mthaddon> Chipaca: o/
<Chipaca> Riddell: woo :-)
<Chipaca> mvo: do you know if 14.04 needs/doesn't need --enable-static-libapparmor --enable-static-libseccomp?
<niemeyer> pedronis: snapd#3616 has one review
<mup> PR snapd#3616: cmd/snap-repair: check signatures of repairs from Next <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3616>
<niemeyer> Anyone up for a second one?
<stormmore> ok back to figuring out why my hello world snap works fine until I change it to a classic snap!
<ogra_> boo, classic snaps :P
<nacc> stormmore: what happens as a classic snap?
<stormmore> nacc: I keep getting a unable to allocate memory type error
<nacc> stormmore: can you pastebin the full output?
<nacc> stormmore: and/or maybe strace it?
<pedronis> niemeyer: thanks
<niemeyer> stormmore: Logs might also help in some cases
<niemeyer> stormmore: Ping jdstrand if you think it's something that the application is being blocked on
<stormmore> nacc: give me a few to make sure I wasn't "imagining things" yesterday but sure... I started using the hello expample from the docs and the only thing I changed was the containment to classic
<niemeyer> pedronis: np
<niemeyer> Lunch, biab for more
<stormmore> niemeyer: nacc: I suspect just a simple AppArmor problem but didn't get that far in troubleshooting
<mvo> Chipaca: 14.04 does not need these static builds, we only need it for 16.04 and for the core snap
<mvo> mthaddon: if you switch core to "candidate" this should work, we plan to release 2.27 on Monday
<Chipaca> mvo: but 14.04 does need the static builds because of dependencies
<mvo> Chipaca: oh, does it? in this case, ok
<Chipaca> mvo: of libpcap
<Chipaca> mvo: not of the other things
<mthaddon> mvo: cool, thx
<Chipaca> mvo: but, my question is, would you rather it weren't static?
<mvo> Chipaca: either way is fine
<Chipaca> mvo: that is: is it worth making the diff between the rules bigger?
<mvo> Chipaca: I would like to keep the diff as small as possible :)
<Chipaca> me too
<Chipaca> mvo: i'd also like to know if we really need the override_dh_systemd_ blocks
<mvo> Chipaca: yes, was wondering about that myself. wasn't it you who added it a *long* time ago :) ?
<Chipaca> mvo: lies!
 * Chipaca runs away
<Chipaca> mvo: i'll test that separately
<Chipaca> too many changes would be baad
<mvo> Chipaca: +1
<pedronis> Chipaca: you are working on the real failures in #3398
<pedronis> ?
<Chipaca> pedronis: yes
<pedronis> thx
<stormmore> nacc: niemeyer: actually got a different error this time /smh - https://pastebin.canonical.com/197040/ is the output from the commands from snap creation to running hello
<cachio> mvo, https://paste.ubuntu.com/25424909/
<nacc> stormmore: reading
<cachio> mvo, I am trying to understand why this test is making the snapd service gives that error when it is stopped
<cachio> mvo, any idea?
<nacc> stormmore: my initial guess is a conflict between the go in your snap and the go on your system
<nacc> stormmore: i'm not entirely sure how go works
<mup> PR snapd#3825 opened: tests: add nmcli regression test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3825>
<Chipaca> dpkg-architecture: error: DEB_TARGET_ARCH is not a supported variable name
<Chipaca> hmmm
<nacc> stormmore: although if you didn't use cleanbuild, i'm not sure, i guess it just uses the host to build
<nacc> Chipaca: manpage says since 1.17.14 :)
<Chipaca> mvo: how do you spell âdpkg-architecture -qDEB_TARGET_ARCHâ in Ye Olde Trvsty?
<Chipaca> nacc: maybe you know then ^ :-)
<stormmore> nacc: not to mention the app is just the gnu-hello C package
<nacc> stormmore: err, right :) but the backtrace is go something something :)
<nacc> Chipaca: looking, i'm not sure off the top of my head
<ogra_> you dont happen to have a go "hello" in your path, do you ? :)
<ogra_> (overriding the snap)
<nacc> Chipaca: still looking (spinning up a trusty env to see)
<Chipaca> nacc: that's very kind of you, thanks!
<Chipaca> maybe on trusty DEB_TARGET_ARCH would always be DEB_BUILD_ARCH?
<mvo> Chipaca: -qDEB_HOST_ARCH probably but its not quite the same but should be close enough
<mvo> Chipaca: let me know, I need to get dinner now but will read backlog
<mvo> the lxd-test branch (3372) is GREEN for the first time evar I think :)
 * mvo happy and &
<nacc> Chipaca: yeah HOST_ARCH is the closest thing that's documented, at least
<nacc> Chipaca: it seems like TARGET_ARCH wsa introduced for exactly this problem :)
<stormmore> nacc: ok strace hello showed an error about not being root! (running it as sudo strace hello right now filled my terminal backscroll so don't have the specifics right now)
<Chipaca> i'm not sure target_arch is the one we wanted anyway
<nacc> stormmore: ah yes, strace might need to be root
<Chipaca> it says target is for when building cross-toolchain
<nacc> stormmore: the strace would only have helped see what was giving back ENOMEM, but if you're not seeing that anymore, it's not likely to help
<Chipaca> ie building something for running on A to build things for B
<Chipaca> mvo: so, i'm going to change it to DEB_HOST_ARCH
<stormmore> nacc: I forget that as I don't use it as much as I probably should ;-)
<nacc> Chipaca: yeah, techincally you have 3 build, host and target
<Chipaca> mvo: as trusty has that, and it's what we want
<Chipaca> nacc: yup
<nacc> Chipaca: agreed you shouldn't need target unelss you're building the cross-toolchain itself
<Chipaca> as our thing is not a compiler, host == target anyway
<Chipaca> exactly
<nacc> Chipaca: yep
<pedronis> I pushed review feedback to snapd#3616 which needs a 2nd review
<mup> PR snapd#3616: cmd/snap-repair: check signatures of repairs from Next <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3616>
<Chipaca> gaaah
 * Chipaca shakes his fist at GNU coreutils
<cachio> Chipaca, any idea why this tests could be causing this? https://paste.ubuntu.com/25424909/
<Chipaca> cachio: I don't understand what I'm looking at, there
<cachio> Chipaca, first is the test, then is the error that it is produced
<Chipaca> cachio: but that error isn't in that code
<Chipaca> cachio: that's in the prepare somewhere
<cachio> the error is in the reset.sh
<cachio> when it stops the service
<cachio> on ubuntu 14
<stormmore> nacc: I am back at the original error with the sudo strace hello /smh - http://paste.ubuntu.com/25425936/ is a "chunk" of the strace inc the end
<cachio> it is so sporadic
<cachio> Chipaca, I can't reproduce it from local, I made a research on travis executions and there is a relation between the test regression/lp-1599891 and that failure
<cachio> Chipaca, but I can't understand what it causing this
<Chipaca> cachio: digging
<Chipaca> cachio: question: can you look at the timers when this happens?
<cachio> Chipaca, well, is is almost impossible to reproduce it for me
<Chipaca> sigh
<Chipaca> cachio: the thing that's returning an error is the 'systemctl stop', yes?
<cachio> Chipaca, yes
<Chipaca> cachio: the "job" that was canceled is the request to stop
<cachio> yes
<Chipaca> cachio: this might be a consequence of the previous daemon-reload
<Chipaca> or not
<Chipaca> i don't know
<cachio> Chipaca, it could be
<Chipaca> but, basically, you'd need to harden the code against this failure
<cachio> it is really weird, it is just happening on trusty
<Chipaca> not terribly surprised
<Chipaca> cachio: how many times do you need to loop to reproduce one of these?
<cachio> about 2000
<Chipaca> man
<cachio> but in travis is happening more frecuently
<Chipaca> cachio: how long does that take?
<cachio> Chipaca, 2000 running from my local
<cachio> Chipaca, I have a test made for that
<cachio> it takes like 2 hours
<Chipaca> cachio: one thing you _could_ try is to add a sleep between those two
<cachio> perhaps more
<Chipaca> on the other hand
<Chipaca> why even do the daemon-reload if you're going to stop it
<Chipaca> maybe do them in the other order: stop, then daemon-reload?
<Chipaca> in fact
<Chipaca> stop snapd
<Chipaca> _then_ reset_classic
<Chipaca> _then_ daemon-reload
<Chipaca> â¦ unless reset_classic uses snapd?
<Chipaca> dunno :-)
<cachio> Chipaca, ok, I'll try changing the order and see what happens
<Chipaca> cachio: plan B would be to check for the error and try again
<cachio> yes, in parallel I am doing that
<Chipaca> cachio: it could be as easy as: while ! systemctl stop snapd\*; do sleep .1; done
<cachio> Chipaca, i have an infinite look for this
<Chipaca> or less hang-friendly, for i in {1..10}; do systemctl stop snapd\* && break; done
<Chipaca> + a sleep in there somewhere
<nacc> stormmore: oh a seccomp failure
<cachio> Chipaca, running again
<cachio> with a loop trying to force the errror
<stormmore> nacc: yeah that is why I think I am doing something silly, trying a cleanbuild now and might even try upgrading my snap core to candidate
<Chipaca> cachio, niemeyer, please don't forget to revisit snapd#3484
<mup> PR snapd#3484: tests: add autopilot-introspection interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3484>
<cachio> Chipaca, sure
<Chipaca> mvo: snapd#3502 looks good, but I see there are changes requested by jdstrand that you claim to have implemented by i don't see (a newline, but also a long comment)
<mup> PR snapd#3502: snap-seccomp: add more tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3502>
<niemeyer> Chipaca: Thanks, commented
<Chipaca> mvo: does 14.04 have snapd-xdg-open?
<Chipaca> looks like no
<Chipaca> mvo: what's gbp.conf?
<pedronis> Chipaca: where is that?
<mvo> Chipaca: iirc we have no snapd-xdg-open in 14.04, we said 14.04 would be server side support
<mvo> Chipaca: gbp.conf is git-build-package
<Chipaca> mvo: i left those things alone for noe
<Chipaca> now*
<mvo> Chipaca: sounds good, thank you
<Chipaca> mvo: but, âdiff -urN ubuntu-14.04/ ubuntu-16.04/â FTW
<Chipaca> lots of questions
<Chipaca> mvo: e.g. the differing maintscripts
<Chipaca> the breaks/replaces in 14.04 seem to have lagged (i bumped those -- let me know if it was wrong)
<Chipaca> also the postrm script probably needs syncing again
<mvo> I think 3617 is ready for merging, if someone wants to have a final look (maybe jdstrand?) thats welcome otherwise I will merge it later or in my morning
<mvo> Chipaca: woah, thanks a lot. I can have a look at the diff/PR in my morning, really appreciated
<mup> Issue snapcraft#1477 opened: multi-arch build packages <design-required> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1477>
<Chipaca> mvo: with the upcoming debian-unstable work, keeping these things sane (and non-obvious differences documented) is going to be a must
<mvo> Chipaca: indeed, I would love to brainstorm a bit if we can somehow merge/symlink way more of the common things, its a DRY desaster right now
<mvo> Chipaca: anyway, your PR helps a lot already, thanks again
<mvo> Chipaca: 3398 looks like a real winner, once tests are green, I would love to see it going in and we can further optimize the packaing in followup branches
<mvo> looks like 3805 just needs a second review and can go in
<jdstrand> mvo: commented. LGTM
<mup> PR snapd#3826 opened: devices/iio: add read/write for missing sysfs entries <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3826>
<stormmore> nacc: niemeyer: I think I have figured it out and it is pretty silly... I changed the command to use bin/hello in the snapcraft.yaml and it is working
<niemeyer> Hmm.. the new lxd test in spread takes 2 to 3 minutes to run..
<mup> PR snapd#3372 closed: tests: add basic lxd test <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3372>
 * ikey grasses up onlyoffice https://twitter.com/only_office/status/902447739023368192
<niemeyer> ikey: Fingers crossed :)
<ikey> Yeah I'm not good with the whole subtlety thingy
<ikey> lol
<Chipaca> jdstrand: 3805 has a weird MockFindGid that isn't a mock and isn't in export_test.go, but other than that (and a couple of nits) it's good to go
<jdstrand> Chipaca: thanks. I was havig some trouble using findGid from the _test.go file and based this on something else in the tree
<Chipaca> jdstrand: usually you'd have an export_test.go
<Chipaca> jdstrand: and that would be in the main package, not in the _test package
<Chipaca> jdstrand: but as it's called _test it only gets built for tests
<Chipaca> jdstrand: so in there you'd do, simply, âvar FindGid = findGidâ
<Chipaca> jdstrand: and then in that package's tests thepackage.FindGid(...) and it'd DWYW
<niemeyer> cachio: Are you taking over snapd#3484 from fgimenez, or do we expect him to be on that tomorrow?
<mup> PR snapd#3484: tests: add autopilot-introspection interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3484>
<cachio> niemeyer, he said he was going to finish this one tomorrow
<cachio> otherwise, I'll take it
<cachio> niemeyer, federico is working until the 31st
<niemeyer> cachio: Sounds great, thanks
<cachio> niemeyer, I'll sync with him tomorrow again
<jdstrand> Chipaca: ok, let me play with that. thanks!
<Chipaca> jdstrand: you can look at release/export_test.go's ReadOSRelease as an example
<Chipaca> niemeyer: getting html back from linode again
<niemeyer> /o\
<Chipaca> niemeyer: more like <o/>
<Chipaca> it seems to have fixed itself though
<jdstrand> Chipaca: huh, that was easy. I thought I tried this and it didn't work...
 * jdstrand shrugs
<jdstrand> Chipaca: thanks!
<mup> PR snapd#3617 closed: interfaces/builtin: use udev tagging more broadly <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3617>
<mvo> Chipaca: the issue with 3398 is that snapd.install needs a directory as the second argument, there is a file there right now. check man dh_install  and sorry that I have not spoted that earlier :/
<mvo> Chipaca: at the end of the man-page there is a suggestion about renames though
<jdstrand> roadmr: hi! can you give me the output of https://dashboard.snapcraft.io/dev/snaps/8252/rev/12/ ?
<jdstrand> roadmr: it says unexpected output
<jdstrand> (in the store)
<roadmr> jdstrand: sure!
<roadmr> jdstrand: found it will just be a sec
<roadmr> jdstrand: https://pastebin.canonical.com/197058/
<jdstrand> hmm, that's curious
<jdstrand> roadmr: thanks
<jdstrand> roadmr: do you happen to know when that review started and when it completed?
<roadmr> jdstrand: completed at     15:33:12.756
<roadmr> trying to get the start timestamp
<jdstrand> kenvandine: can you press the 'request manual review' button here: https://dashboard.snapcraft.io/dev/snaps/8252/rev/12/
<kenvandine> jdstrand, sure
<kenvandine> jdstrand, button pushed :)
<jdstrand> kenvandine: thanks
<roadmr> jdstrand: the scan started at 15:33:11.785
<jdstrand> roadmr: that is weird and likely unrelated to the reaping code
<jdstrand> roadmr: have you seen any other 'unexpected output' since r922 went out?
<roadmr> jdstrand: what's weird?
<mup> PR snapcraft#1509 closed: project_loader: process stage package grammar <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1509>
<jdstrand> roadmr: that snap has that file. the fact that it is gone made me think something came along and removed the review directory
<roadmr> jdstrand: hm... indeed
<jdstrand> roadmr: (ie, lingering reaping bug), but i don't think so based on the timestamps. I'll re-review that code to be sure
<roadmr> jdstrand: the last instance of "os.rmdir(dirPath) FileNotFoundError: [Errno 2] No such file or directory:
<jdstrand> roadmr: there aren't any fs errors on that machine, are there?
<roadmr> jdstrand: was from Aug 23rd, and no "unexpected output" until this one just now
<jdstrand> ah
<roadmr> jdstrand: I could have it looked at, I haven't seen anything in any logs or alerts
<roadmr> jdstrand: I want to think we have alerts for misbehaving disks :)
<jdstrand> if the last rmdir was from the 23rd, then it really shouldn't be that code, since this review would've triggered that
<roadmr> right...
<jdstrand> roadmr: ok, let me review the code. unless I say something, I'll just keep an eye on this
<roadmr> ok, let me know if you need more info
<Chipaca> ok, time for a dog to stretch its legs
<jdstrand> roadmr: actually, do you have any 'Could not remove ...' in syslog?
<Chipaca> 7k steps worth of dogwalking coming up -- should be back just after spread finishes :-D
<roadmr> hm... let's see
<roadmr> Chipaca: so do you walk 3.5k steps one way, then turn back?
<roadmr> (and come back the same way, I guess)
<kenvandine> jdstrand, thx for the review
<roadmr> jdstrand: hm, no "Could not remove" in the logs. I only have application logs, no real access to syslog :( but, I can have it checked by someone with access
<jdstrand> roadmr: ok, that's alright. it was just the one. let's keep with me reviewing and keeping an eye on it
<jdstrand> kenvandine: np
<roadmr> ok jdstrand let me know
<niemeyer> pedronis: Around still?
<pedronis>  niemeyer: yes
<niemeyer> pedronis: I'm a bit confused on 3573.. I can just add the notes on the review, or we can quickly talk if you want to be unblocked early tomorrow
<niemeyer> snapd#3573
<mup> PR snapd#3573: overlord: always try to get a serial, lazily on classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/3573>
<pedronis> niemeyer: we can talk quickly
<niemeyer> pedronis: The main thing is about how "generic" apparently have two different keys
<niemeyer> has
<pedronis> one is for staging
<niemeyer> And generic is named models as a side effect.. is that a test-only thing or is that an actual plan?
<pedronis> ah, in that sense
<pedronis> there are two keys, yes
<pedronis> one for models , one for serials
<pedronis> on is an offline key, the other in an online key
<pedronis> canonical has the same btw
<niemeyer> Ah, models is a key name, not an account name, sorry, I was confused indeed
<pedronis> yes
<pedronis> it just a label
<pedronis> generic has models and serials
<niemeyer> Yeah
<pedronis> canonical for example has root,  store and models or something like that
<niemeyer> pedronis: Alright, thanks.. that was the only hanging point.. will review the rest
<cachio> pedronis, is it ok if I submit a fix to make the fedora tests pass again?
<pedronis> cachio: I have a PRÂ open to reenabled them,  snapd#3755
<mup> PR snapd#3755: try to reenable fedora spread tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/3755>
<pedronis> you mean to push something there?
<cachio> yes
<pedronis> yes, it's fine
<cachio> I mean to push some fixes for tests that are currently failing
<cachio> there are 2 tests failinf
<pedronis> cachio: yes, you can push to that PR of mine
<pedronis> IÂ created it because IÂ was the one turning them off
<cachio> pedronis, great, tx
<tpatel> Has anyone have issue with socket options SO_BINDTODEVICE not receiving data?
<stormmore> I am really starting to enjoy creating a snap
<nacc> i've got a classic snap that just updated (i own the snap) and after the update a script in the snap is for some reason not seeing a new python dependency (i've got a script in the snap that calls another program in the snap, which is failing from that script). Calling that program directly, though, is succeeding. I'm not entirely sure how to debug at this point
<nacc> oh i wonder if it's a symlink issue with the snaps
<nacc> well, that wasn't it
#snappy 2017-08-30
<soee> hey :-) Someone able to help me with this problem: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks ?
<mup> PR snapcraft#1511 closed: project_loader: support grammar on build-packages <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1511>
<mup> PR snapd#3804 closed: cmd/snap-seccomp: support parsing 'u:' and 'g:' for username and groups <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3804>
<mup> PR snapd#3805 closed: interfaces/{default,account-control}: Use username/group instead of uid/gid  <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3805>
<mup> PR snapd#3398 closed: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3398>
<mup> PR snapd#3616 closed: cmd/snap-repair: check signatures of repairs from Next <Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3616>
<zyga-ubuntu> good morning
 * zyga-ubuntu is packed and waiting 
<zyga-ubuntu> mvo: I'll be going back to warsaw at around 16:30, in the meanitime I'm working from a place with (hopefully) better network than mine
<pstolowski> morning zyga-ubuntu !
<pstolowski> mvo, hey, conflict in 3773, plus one silly question from me
<zyga-ubuntu> good morning :)
<mvo> zyga-ubuntu: ok, let try to catchup today about the bases snap-confine work
<mvo> pstolowski: thank you, I have a look now
<zyga-ubuntu> mvo: indeed, I'm sorry about yesterday
<mvo> zyga-ubuntu: no worries
<mup> PR snapd#3820 closed: spread: don't set HTTPS?_PROXY for linode <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3820>
<mup> PR snapd#3826 closed: interfaces/iio: add read/write for missing sysfs entries <Created by jdstrand> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3826>
<zyga-ubuntu> willdeberry: hey, conflicts on https://github.com/snapcore/snapd/pull/3812
<mup> PR snapd#3812: interfaces: expose bluez interface on classic OS <Created by willdeberry> <https://github.com/snapcore/snapd/pull/3812>
<mup> PR snapd#3755 closed: try to reenable fedora spread tests <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3755>
<mup> PR snapcraft#1498 closed: lxd: pass original CLI arguments down to container <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1498>
<zyga-ubuntu> I see this is a merge-morning :)
<zyga-ubuntu> pstolowski: any updates on https://github.com/snapcore/snapd/pull/3810 ?
<mup> PR snapd#3810: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <https://github.com/snapcore/snapd/pull/3810>
<pstolowski> zyga-ubuntu, yeah, let me push. nb, I removed Ref() after all. I added them in the first place just for a single interface that needed them for error message
<pstolowski> zyga-ubuntu, so instead I just changed the error message in that interface
<zyga-ubuntu> pstolowski: sounds good, let me know when this is ready for another review
 * zyga-ubuntu *really* likes commit messages from jhenstridge
<zyga-ubuntu> this is what a descriptive patch looks like
<zyga-ubuntu> mvo: oh 2.27.5 is out already? I need to push some packages then
<zyga-ubuntu> I'll do that in the evening from home though
<mvo> zyga-ubuntu: indeed
<mwhudson> zyga-ubuntu: feel free to do debian :)
<zyga-ubuntu> mwhudson: thank you! I really wanted to :)
<pedronis> mvo: not an immediate thing, but related to pstolowski comment on your run branch, should we consider sending repair failures/retry marking for sending to errtracker ?
<mvo> pedronis: that is a good idea
<zyga-ubuntu> indeed, good idea
<zyga-ubuntu> mvo: though I'd suggest doing a small refactor of that code
<zyga-ubuntu> mvo: so that we can queue/send async the errors
<zyga-ubuntu> and not just hurrah-send them like today
<zyga-ubuntu> the same thing will become useful to other layers
<zyga-ubuntu> mvo: it almost feels like an overlord manager
<mvo> pedronis: sending failures sounds good, sending retries I'm not sure, given that its not a failure as such, maybe we should send an error if we got no ack over the status fd? this indicates a buggy repair script
<mvo> zyga-ubuntu: I have no plans for this currently, I assume you have something like a spool dir and such in mind?
<Chipaca> mvo: so, about gbp.conf, why does trusty have that? why does Â¬trusty not have that? which is the right one?
<zyga-ubuntu> mvo: yes, something like that, essentially a way to start building on this as a feature we could use for health checks later on
<pedronis> mvo: yea, maybe that's an ok compromise
<zyga-ubuntu> mvo: something stateful that can survive power outage
<zyga-ubuntu> mvo: especially if we then revert core to, e.g. fix a network issue
<mvo> Chipaca: feel free to remove it, it needs some work to be useful again. it basicly stopped being useful when we started vendoring
<mvo> pedronis: thank you
<zyga-ubuntu> ikey: hey, I have a question about https://github.com/snapcore/snapd/pull/3720
<mup> PR snapd#3720: cmd,interfaces: add initial support for Solus <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/3720>
<zyga-ubuntu> ikey: do you plan on workin on that? Shall I pick it up?
<zyga-ubuntu> ikey: it would be great to have 2.28 with solus ready :)
<mvo> zyga-ubuntu: yeah, don't get me wrong, I am not against this at all, just have no plans to work on this currently (given the other open todo items)
<zyga-ubuntu> ikey: and related to that, we should talk about some level of CI, a headless image to at least test building would be awesome
<zyga-ubuntu> mvo: understood
<Chipaca> mvo: sir yes sir
<mvo> Chipaca: thank you
<pedronis> Chipaca: or mvo:  need a quick sanity check of the changes IÂ did to snapd#3573
<mup> PR snapd#3573: overlord: always try to get a serial, lazily on classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/3573>
<Chipaca> we're two PRs away from a single page of PRs
<Chipaca> i'm going to weep
<Chipaca> :-)
<mvo> quick, push more! oh, merge more I mean
 * Chipaca reaches for his MART
 * Chipaca quietly puts this on the coffee table: https://awfulmidis.tumblr.com/post/164727430527/totos-africa-but-with-the-donkey-kong-country
<Chipaca> pedronis: that PR looks fine
 * mvo looks at the current failure in master and pokes at snap userd in 14.04
<Chipaca> mvo: :-(
<mvo> Chipaca: 3823 looks like an easy win
<zyga-ubuntu> mvo: oho, upstart strickes back?
<Chipaca> pedronis: would loading "snaps" into a map[string]json.RawMessage be cheaper than loading it into a map[string]*SnapState?
<zyga-ubuntu> strikes*
<pedronis> Chipaca: yes
<Chipaca> pedronis: in NumSnaps
<Chipaca> pedronis: and loading it into a map[string]struct{}? (would that work?)
<mvo> zyga-ubuntu: maybe :) trying to figure out what is going on right now
<pedronis> Chipaca: that I don't know
<pedronis> I'm not sure it makes a lot of difference
<mvo> Chipaca: also 3795 is an easy one (and short)
 * zyga-ubuntu reviews top-bottom
<zyga-ubuntu> and debootstraps sid :)
<Chipaca> mvo: 3795 is good, i didn't +1 it myself because i saw it's got a request for gustavo to do so
<Chipaca> mvo: if you don't think it's that important for him to review it i can +1 it
<pedronis> it's a change for the REST api
<pedronis> that's why IÂ put it for him to look at it
<mvo> Chipaca: I could be wrong, but it seems the "allow-interactive" hint is uncontroversial
<pedronis> it's a name, names are always controversial
 * zyga-ubuntu mutters something about hygenic macros and goes back to reviews
<zyga-ubuntu> pedronis: conflict on https://github.com/snapcore/snapd/pull/3781
<mup> PR snapd#3781: cmd/snap-repair: track and use a lower bound for the time for TLSÂ checks <Created by pedronis> <https://github.com/snapcore/snapd/pull/3781>
<mvo> pedronis: meh, good point about names being controversial (cc Chipaca)
<pedronis> there are 6 PRs  marked for Gustavo, is not too bad, maybe
<pedronis> Chipaca: pushed the change to *RawMesssage
 * zyga-ubuntu wonders if we could reach PR zero by EOD
<pedronis> very unlikely
<pedronis> also seems we are adding more stuff to 2.28
<pedronis> that needs jamie reviews
<pedronis> Chipaca: anything else in #3573 ?
<zyga-ubuntu> I think jamie is back today, no?
<pedronis> he was back already yesterday
<pedronis> doesn't mean much, depends where things stand on his prios
<zyga-ubuntu> Chipaca: conflict on https://github.com/snapcore/snapd/pull/3748
<mup> PR snapd#3748: many: fetch & cache remote snaps and sections; complete from there <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>
<pedronis> it's also Blocked
<pedronis> mvo: seems  snapd#3502 needs a 2nd look either from zyga or jamie  ?
<mup> PR snapd#3502: snap-seccomp: add more tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3502>
<zyga-ubuntu> mvo: conflicts on https://github.com/snapcore/snapd/pull/3779 (probably trivial but I'd rather not hand-edit vendor.json)
<mup> PR snapd#3779: snap-seccomp: remove use of x/net/bpf from tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3779>
<Chipaca> pedronis: no, as i say it's fine (even without that change)
<zyga-ubuntu> Chipaca: I think we could pull out https://github.com/snapcore/snapd/pull/3748/commits/90a8ca941f6f322e7aa7150bc7bba738708e06cb for a separate landale PR
<mup> PR snapd#3748: many: fetch & cache remote snaps and sections; complete from there <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>
<pedronis> also soon or already travis will bottleneck us
<Chipaca> zyga-ubuntu: agreed on that, but is it worth it
<zyga-ubuntu> Chipaca: yes, diffs shrink
<zyga-ubuntu> that is always good :)
<zyga-ubuntu> even if that branch doesn't land for whatever reason
 * zyga-ubuntu looks at 3719
<mvo> zyga-ubuntu: didn't the removal itself trigger the conflict? anyway, resovled
<zyga-ubuntu> mvo: thanks
<zyga-ubuntu> mvo: I think it did
<mvo> zyga-ubuntu: uh, sorry, where does x/sys/unix come from?!? let me look again at this pr
 * zyga-ubuntu doesn't know, sorry
 * zyga-ubuntu is half-way through sid debootstrap
<zyga-ubuntu> slow network lets one appreciate time
<mup> PR snapd#3827 opened: vendor: fix artifcat from manually editing vendor/vendor.json  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3827>
<Chipaca> zyga-ubuntu: did you see 3502 is ready for another look?
<zyga-ubuntu> mvo: interesting read for later: https://jneem.github.io/pijul/
<zyga-ubuntu> Chipaca: I'll review this after the desktop interface PR now
<Chipaca> mvo: FYI: there are no spread tests that fail if I nuke the dh_systemd sections from the 16.04 rules file
<zyga-ubuntu> Chipaca: o_O
<zyga-ubuntu> that's curious
<zyga-ubuntu> we are very reliable ;-)
<Chipaca> zyga-ubuntu: meaning the defaults word probably work well enough for us
<Chipaca> zyga-ubuntu: the overrides were created in the prehistory, and cargo-culted, need revisiting
<mvo> Chipaca: \o/ lets kill them with fire then
<Chipaca> mvo: piano piano
<Chipaca> mvo: this might mean we aren't testing enough :-)
<mvo> Chipaca: well, I guess it makes sense to compare the output of systemctl for the various units with our old rules and the defaults
<mvo> Chipaca: not us ;)
<Chipaca> it is an encouraging direction for further research :-)
<Chipaca> but, not now. now i've got conflicts to resolve and review feedback to address
<Chipaca> zyga-ubuntu: if you have feedback on snapd#3748 now would be a very good time
<mup> PR snapd#3748: many: fetch & cache remote snaps and sections; complete from there <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>
<zyga-ubuntu> Chipaca: I will, just let me finish the PRs :)
<zyga-ubuntu> I have them all open in tbas
<zyga-ubuntu> *tabs
<Chipaca> zyga-ubuntu: about separating that commit, it's more involved than that unfortunately
<Chipaca> conceptually simple, sure :-)
 * mvo grumbles about upstart and the lack of any information why a job is no longer running
<zyga-ubuntu> Chipaca: aha, I see
<Chipaca> zyga-ubuntu: i'd have to go over the previous commits and pull out the right bits that made that commit necessary
<Chipaca> very untidy of me :-/
<pedronis> Chipaca: doesn't sound a super useful use of time
<Chipaca> pedronis: mhmm
<Chipaca> OTOH if the PR took much longer to get out there there might be merit to it
<pedronis> Chipaca: it is fixing a preexisting problem? a potential preexisting problem? or something that your other stuff triggered?
<Chipaca> pedronis: the tests were messy, some of them running with root dir on / and not writing/reading system stuff by happenstance
<Chipaca> so i added a setrootdir to the test setup
<Chipaca> so i then had to change all the tests that matched strings to the fixed ones
<Chipaca> this came about because i added a test that broke when there wasn't a file in the "outside"
<Chipaca> (the test passed on my machine because i'd already run the code in the pr so i had that file)
<Chipaca> pedronis: so, bit of column a, bit of column b
<mup> PR snapd#3828 opened: release: 2.27.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3828>
<pedronis> Chipaca: sounds easier to do a new PR
<pedronis> just about this
<pedronis> that untangling it from that PR
<Chipaca> my thought exactly
<pedronis> mvo: do we have a fix for snap-userd test?
<pedronis> I get
<pedronis> + stop test-snap-userd
<pedronis> stop: Unknown instance:
<pedronis> mvo:  https://travis-ci.org/snapcore/snapd/builds/269919547?utm_source=github_status&utm_medium=notification
<Chipaca> pedronis: i think that's what mvo is getting too
<Chipaca> mvo: does it go away if you back out snapd#3398 ?
<mup> PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3398>
<mvo> pedronis: looking into it currently, the going is slow, my upstart is rusty and things are slightly dubious
<mvo> Chipaca: I doubt that 3398 is related, it looks like for some reason snap userd is dying before its time
<mvo> Chipaca: and I'm trying to figure out *why* now
<Chipaca> mvo: if i run with --debug
<Chipaca> mvo: i find that userd runs fine, via dbus activation? i think
<Chipaca> mvo: it's just that upstart doesn't "see" it
<Chipaca> i mean, ps doesn't see a snap userd, but i can message it and it appears
<Chipaca> that's something activating it :-)
<mvo> Chipaca: yeah, it is auto-activated
<Chipaca> mvo: so it looks like it gets activated before upstart can start it
<mvo> Chipaca: yeah, that sounds plausible
<mvo> Chipaca: let me test this theory, maybe we can kill some code here :)
<Chipaca> mvo: and this might be caused by 3398 because before we weren't copying the dbus things into place
<mvo> Chipaca: oohhhhh
<mvo> Chipaca: yes, now things start to make sense
<zyga-ubuntu> jdstrand: hey
<Chipaca> mvo: and 3398 landed because it ran the test at some silly hour in the morning, meaning less load on travis
<Chipaca> or linode
<Chipaca> or whatever
<Chipaca> bah, it's a race, we one it once :-)
<Chipaca> a bit like england motorsport
<mvo> Chipaca: or footbal
<mvo> Chipaca: (SCNR)
<Chipaca> as an argentine i daren't mention the f word
 * zyga-ubuntu raises his eyebrow 
<mvo> Chipaca: yeah, I think it all makes sense, let me run one more test, then I will push something that removes a bunch of extra lines in this test :)
<zyga-ubuntu> jdstrand: 3719 is good to land though it will need a follow up
<mvo> Chipaca: f-word *cough* - double sorry, forgot about that
<Chipaca> :-)
 * mvo is not actually following this very much
<Chipaca> at least fangio never won with his hand, or something
<mvo> lol
<zyga-ubuntu> jdstrand: I'll leave it as is and merge later today
 * zyga-ubuntu reads 3502
<zyga-ubuntu> Chipaca: what is the official fake base store?
<Chipaca> zyga-ubuntu: store/storetest.Store
<Chipaca> zyga-ubuntu: // Store implements a snapstate.StoreService where every single method panics.
<zyga-ubuntu> that's bad-hair-day-store in lisp, rigt/
<zyga-ubuntu> right*
<ogra_> can y<ou then "snap install vaporware" ?
<Chipaca> ogra_: 1. snap install xbill-xaw
<Chipaca> ogra_: 2. enjoy your vaporware
<Chipaca> :-)
<ogra_> heh, insteasd of duke-nukem-forever ?
<ogra_> -s
<Chipaca> ogra_: there was no vapor in dnf
<Chipaca> waaaait
<ogra_> haha
<Chipaca> dnf is duke-nukem-forever?
<ogra_> i think so
<zyga-ubuntu> well, come on
<Chipaca> bunch'a nerds
<zyga-ubuntu> duke is out
 * Chipaca goes back to playing xbill
<ogra_> yeah, it isnt exactly vaporware butu it was dfor a decade
<zyga-ubuntu> snap install world-peace
<zyga-ubuntu> miracle assertion required
<ogra_> yeah, and a boring game i bet
<zyga-ubuntu> my sid debootstrap is at "g" now
<zyga-ubuntu> and my git fetch is at "k" now
<ogra_> dooesnt debian have pre-made tarballs like ubuntu-base ?
<zyga-ubuntu> ogra_: it's for sbuild
<ogra_> ah
<zyga-ubuntu> and I doubt I'd save any time
<ogra_> well, using debootstrap on ubuntu takes minutes ... downloading and untarring the base tarball takes seconds
<ogra_> that is why we have this product ;)
<zyga-ubuntu> ogra_: my modem takes forever, priceless
<zyga-ubuntu> mvo: should tests in cmd/snap-seccomp in https://github.com/snapcore/snapd/pull/3502 take long?
<mup> PR snapd#3502: snap-seccomp: add more tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3502>
<zyga-ubuntu> mvo: on my x250 it's ~~ minute and going
 * zyga-ubuntu breaks for 3 minutes
<pedronis> Chipaca: mvo: does that test passes sometimes?Â or always fail?Â should I try to rerun?
<Chipaca> pedronis: it passes sometimes
<Chipaca> pedronis: but if mvo is fixing it, maybe instead of rerunning, merge his fix?
<pedronis> when it exists
<pedronis> anyway seems quite consistent in failing
<zyga-ubuntu> mvo: 2m39,683s
<zyga-ubuntu> ouch!
<pedronis> also fedora preparate
<pedronis> took too long
<pedronis> https://travis-ci.org/snapcore/snapd/builds/269925918?utm_source=github_status&utm_medium=notification
<pedronis> here
<mvo> Chipaca, pedronis: PR is ready, sorry, took so long because I wanted to verify in qemu first
<Chipaca> mvo: was the diagnosis confirmed?
<mup> PR snapd#3829 opened: tests: fix race in snap userd test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3829>
<Chipaca> mvo: shouldn't we stop it after the test?
<Chipaca> mvo: anyway +1
<Chipaca> whoops, i just merged a pr without realising it had a request for jdstrand :-(
<mup> PR snapd#3824 closed: interfaces: do not match any file or directory in or under /sys/bus/pci/devices/ <Created by adglkh> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3824>
<Chipaca> jdstrand: ^ :-( sorry
<Chipaca> mvo: snapd#3825 seems ok to land, unless you want to implement zyga-ubuntu's suggestion
<mup> PR snapd#3825: tests: add nmcli regression test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3825>
<zyga-ubuntu> mvo: do you recall where you saw "/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(libc-start.o): relocation R_X86_64_32 against undefined symbol _dl_starting_up' can not be used when making a shared object; recompile with -fPIC"
<zyga-ubuntu> mvo: (context PR 3502)
<pedronis> Chipaca: I did mark that one for jamie, but maybe you understand that stuff more than me
<mup> PR snapcraft#1517 opened: integration: make onboarding easier for code users <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1517>
 * zyga-ubuntu -> lunch
<Chipaca> pedronis: very little, but just enough to get that one
<pedronis> Chipaca: I probably got paranoid form the recent interface tweaks regressions we had
<Chipaca> niemeyer: snapd#3642 is getting long in the tooth
<mup> PR snapd#3642: cmd/snap: get keys or root document <Created by stolowski> <https://github.com/snapcore/snapd/pull/3642>
<Chipaca> pedronis: la la la la can't hear you la la
<pstolowski> is travis acting up or is it just me?
<pedronis> pstolowski: lots of work on PRs, it might just be queuing stuff, or you seeing something in particular?
<pstolowski> pedronis, test failures
<Chipaca> need to reboot my router. brb.
<pedronis> pstolowski: there's a recently added test that is flaky,  mvo has a fix
<pstolowski> tests/main/snap-userd ?
<pedronis> pstolowski: also fedora tests have been reenable and they seem flaky, at least they can take too long to prepare
<pedronis> pstolowski: yes
<pstolowski> ack, thanks
<pedronis> pstolowski: fix is here 2017-08-11T15:49:49Z
<pedronis> sorr
<pedronis> y
<pedronis> pstolowski: fix is here snapd#3829
<mup> PR snapd#3829: tests: fix race in snap userd test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3829>
<zyga-ubuntu> oh, good old netsplit
<mvo> Chipaca: I will investigate about your stoping question and do a followup
<mvo> Chipaca: I'm in favour of merging 3829 to unbreak the world
<zyga-ubuntu> Chipaca: reviewed https://github.com/snapcore/snapd/pull/3748
<mup> PR snapd#3748: many: fetch & cache remote snaps and sections; complete from there <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>
<zyga-ubuntu> except still sending the request to github
<arm1e> Hey guys, I have found a snap I want to install on github, but does not show in snap find. Can you tell me why this is please. It says it is stable and strict confinement. Thanks
<arm1e> https://github.com/jacobzimmermann/gnucash-jz-snap/blob/master/snap/snapcraft.yaml
<zyga-ubuntu> arm1e: is the snap released?
<zyga-ubuntu> arm1e: is it public?
<zyga-ubuntu> arm1e: the presence of that snapcraft.yaml doesn't indicate that in any way (it cannot)
<zyga-ubuntu> sub 30 PRs
<zyga-ubuntu> nice to see that
<arm1e> zyga-ubuntu, can I manually install it?
<zyga-ubuntu> I find it funny that everyone seems to edit vendor.json by hand because govendor usability is poor
<zyga-ubuntu> arm1e: I don't know, build it from source and try
<arm1e> ty
<mvo> zyga-ubuntu: re 3502 - if you reformat the C code, why not use the indent we use in snap-confine for consitency? instead of adding a different indent
<zyga-ubuntu> mvo: oh sorry about that, just because it produces saner indent and I'm about to switch to that one
<zyga-ubuntu> mvo: clang-format is less crazy
<zyga-ubuntu> mvo: and has good defaults for various styles
<zyga-ubuntu> mvo: I just didn't want to bother with running indent that right way for this
<mvo> zyga-ubuntu: I refer to the "standards" from xkcd :)
<zyga-ubuntu> mvo: and one more observation, indent actually broke with future versions
<zyga-ubuntu> mvo: it produces different output for same profile
<mvo> zyga-ubuntu: anyway, I don't relaly mind much, it just seems that we should pick one and stick to it. the go fmt guys were incredible wise
<zyga-ubuntu> mvo: so that coupled with general sane output from clang-format
<mvo> zyga-ubuntu: it does? meh, that sucks
<zyga-ubuntu> mvo: indeed
<zyga-ubuntu> mvo: I'll switch us to that when travis is calm
<zyga-ubuntu> mvo: yep, sadly
<zyga-ubuntu> mvo: the difference is in one spot and we could just remove that code and replace it with something that doesn't trigger it
<zyga-ubuntu> mvo: but meh
<mvo> zyga-ubuntu: I'm not a fan of reformating as we will loose all VCS history (git blame will be useless)
<zyga-ubuntu> mvo: mmm, good point
<zyga-ubuntu> mvo: we'll see, maybe we can do it on a file-by-file basis when introducing significant enough changes
<mvo> omg - autopkgtests in artful for 2.27.5 arre all green, yay!
<zyga-ubuntu> mvo: that's a rare sight :)
<mup> PR snapd#3829 closed: tests: fix race in snap userd test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3829>
<zyga-ubuntu> Chipaca: I reviewed https://github.com/snapcore/snapd/pull/3748
<mup> PR snapd#3748: many: fetch & cache remote snaps and sections; complete from there <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>
<Chipaca> zyga-ubuntu: ack
<zyga-ubuntu> hmm
<zyga-ubuntu> zesty broke my modem connection
<zyga-ubuntu> that's not great :/
<zyga-ubuntu> I mean my built-in modem
<Son_Goku> zyga-ubuntu, so... dnf is now in openSUSE Factory
<jdstrand> Chipaca: responded (https://github.com/snapcore/snapd/pull/3824/files#r136058008)
<mup> PR snapd#3824: interfaces: do not match any file or directory in or under /sys/bus/pci/devices/ <Created by adglkh> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3824>
<Son_Goku> zyga-ubuntu, this means that we can use the same API for supporting snapcraft on RPM based distributions
<zyga-ubuntu> hey
<zyga-ubuntu> I read your earlier note, that's a good thing
<zyga-ubuntu> not certain yet but after layouts it looks like something I can work on
<Son_Goku> which reminds me, niemeyer, I'll be making that snapcraft forum post soonish today
<Son_Goku> I've just been busy with life things, like eye doctor visits
<Son_Goku> to get new glasses :)
<zyga-ubuntu> sigh
<zyga-ubuntu> zesty broke 3G
<zyga-ubuntu> ...
<zyga-ubuntu> "no such device" you say, while showing the modem *and* the signal strenght
<Son_Goku> :)
<zyga-ubuntu> strength
<niemeyer> Son_Goku: Thanks!
<niemeyer> Hello all
<zyga-ubuntu> 2fa
<zyga-ubuntu> logging in
<Chipaca> jdstrand: phew
<zyga-ubuntu> connection breaking
<abeato> ogra_, does wifi work in the dragonboard?
<ogra_> abeato, sure
<ogra_> wer dont have any device where it doesnt work atm ... at least to my knowledge
<abeato> ogra_, ok, just double checking, thanks
<mup> PR snapd#3719 closed: interfaces: add desktop and desktop-legacy <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3719>
<zyga-ubuntu> woot, wife arrived
<zyga-ubuntu> I'll move luggage into the car and be back soon
<zyga-ubuntu> mvo: you should have used your 3g modem
<zyga-ubuntu> mvo: then you would tell me the zesty update broke it :)
<zyga-ubuntu> mvo: and I would have stayed on xenial
<zyga-ubuntu> mvo: I'll move to artful at home, hopefully it won't be more broken
<mvo> zyga-ubuntu: sorry for that, I actually hardly ever use that thing
<mvo> zyga-ubuntu: have a good trip back
<mvo> zyga-ubuntu: nothing we can fix (relatively) easily with regards to the modem?
<ogra_> just ... snap revert distro
<ogra_> :P
<niemeyer> Chipaca, pstolowski: About snapd#3642, yeah, I was somewhat consciously letting this one sleep.. I was concerned about jumping the gun on the UI change and regret the decision we agreed to
<mup> PR snapd#3642: cmd/snap: get keys or root document <Created by stolowski> <https://github.com/snapcore/snapd/pull/3642>
<zyga-ubuntu> mvo: I need to give you a working sim card :)
<niemeyer> Let me look into it again
<zyga-ubuntu> mvo: there are those services that give you low transfer for free essentially
<zyga-ubuntu> mvo: no idea why it doesn't work, the modem works, it's just nm and mm don't see eye to eye
<mvo> zyga-ubuntu: ha! yeah, I guess I need one of those
<niemeyer> Hmm.. I think we should teach mup to use #3652 as a snapd bug here..
<niemeyer> s/bug/PR
<niemeyer> Sounds vastly more common to talk about those
<niemeyer> Anyone against? 3.. 2.. 1.. :P
<zyga-ubuntu> niemeyer: hmm?
<mup> PR snapd#3823 closed: tests: rename complexion to test-snapd-complexion <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3823>
<niemeyer> zyga-ubuntu: I'll take the hmm as "Yeah, great idea!"
<zyga-ubuntu> niemeyer: I was trying to parse your earlier statement
<mvo> zyga-ubuntu: fwiw, I updated 3825 (based on your idea)
<zyga-ubuntu> niemeyer: but yeah :)
<zyga-ubuntu> go ahead
<zyga-ubuntu> mvo: oh, thank you!
 * zyga-ubuntu looks
<zyga-ubuntu> Thank you!
<niemeyer> #3573
<mup> PR #3573: overlord: always try to get a serial, lazily on classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/3573>
<niemeyer> There you go!
<zyga-ubuntu> ah
<zyga-ubuntu> niemeyer: I parsed your earier comment now, yes, definite +1
<niemeyer> ;)
<zyga-ubuntu> github unicorns :/
<mvo> down to 25!
<Chipaca> mmm, unicorns
<mup> PR snapd#3827 closed: vendor: fix artifact from manually editing vendor/vendor.json  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3827>
<Chipaca> i've got a slow cooker
<ogra_> Riddell, wow, falkon is impressingly fast!
<Riddell> ogra_: ooh it's working?
<ogra_> yeah
<Riddell> nice
<ogra_> (xenial here)
<Riddell> it seems very promising
<ogra_> Riddell, not sure you have seen it https://forum.snapcraft.io/t/kde-neon-chooses-snap/1898 ... not working everywhere yet (though thats more an arch snapd issue i guess)
<Riddell> yeah that's why it's nice to have a good report
<jdstrand> mvo: fyi, I have PR 3779 on my list, but I'd like to see 3502 go through first so it is easier to see the changes
<mup> PR #3779: snap-seccomp: remove use of x/net/bpf from tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3779>
<jdstrand> PR 3502
<mup> PR #3502: snap-seccomp: add more tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3502>
<mup> PR snapd#3828 closed: release: 2.27.5 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3828>
<pedronis> niemeyer: I'm not sure if your comment was about the TODO I added, do you have a suggestion for what comment you would like added instead?
<niemeyer> pedronis: It wasn't about the code.. I haven't seen the updates
<Riddell> a snapd issue? https://blog.neon.kde.org/index.php/2017/08/29/great-web-browsing-coming-back-to-kde-with-falkon-new-packaging-formats-coming-to-kde-with-snap/#comment-249
<pedronis> niemeyer: I added a TODOÂ there
<niemeyer> pedronis: +1 then!
<niemeyer> pedronis: I mean, it already had the +1, so that's +2 I guess :P
<pedronis> yea, mostly waiting for green but travis is queuing, so much PR work going :)
<pedronis> jdstrand: #3621 is also something IÂ marked for you to look at
<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>
<jdstrand> pedronis: yep, on the list
<pedronis> thx
<mup> PR snapd#3484 closed: tests: add autopilot-introspection interface test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3484>
<mup> PR snapd#3830 opened: tests: deal with __PNR_chown on aarch64 to fix FTBFS on arm64 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3830>
<Chipaca> 24 PRs!
<Chipaca> do we get cookies
<genii> !cookie
<ubottu> Wow! You're such a great helper, you deserve a cookie!
<genii> Hm
<genii> Ah, there we go
<pstolowski> Chipaca, hey, see https://forum.snapcraft.io/t/support-for-snapctl-stop-start-restart-services/1908/8 ;ok if I take it or have you already started?
<Chipaca> pstolowski: i have not started but was about to
<Chipaca> pstolowski: but, if you'd rather do it go for it
<Chipaca> pstolowski: i have no lack of things to do
<Chipaca> pstolowski: i know the service side but would need to learn the snapctl side, and you viceversa. I suspect you've got less to learn than i
<mup> PR snapd#3635 closed: tests: add out-of-the-box test suite <Decaying> <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3635>
<niemeyer> Lunch.. biab
<pstolowski> Chipaca, ok. yes, that was exactly the point niemeyer was making (about other stuff on your plate), so I'm fine to take it
<Chipaca> ogra_: how much hard drive space would a 'small' device have these days?
<Chipaca> (for handwavy values of "hard drive")
<ogra_> Chipaca, dunno ... i think the smalles Sd card you can buy is 2GB atm
<Chipaca> ogra_: so keeping 100MB of space around just-in-case is not too bad?
<Chipaca> ogra_: that is, if snapd said "i'm going to ignore what you just told me to do because disk is running short" at 100MB, that'd be alright?
<Chipaca> on small devices i mean
<ogra_> well the formatting tools typically reserve 5% for root so that the system keeps running even if a user fills up the disk
<Chipaca> ogra_: yes, but snapd runs as root
<ogra_> i wonder if a percentage is better than a fixed limit of megabytes
<Chipaca> 5% is way too much these days, most of the time
<ogra_> yeah, i didnt mean that :)
<ogra_> 100MB are surely ok to keep the OS running ...
<Chipaca> I'd be fine with max(10MB, min(100MB, 5%))
<Chipaca> or maybe 20MB as the min min
<ogra_> yeah,.. that sounds fine
<ogra_> well
<Chipaca> or, shocking idea, make it configurable
<Chipaca> but that's Hard Work
<ogra_> perhaps we shoudl take the core snap as measure here
<Chipaca> so stage 2 :-)
<Chipaca> ogra_: ah, good idea, or the kernel or sth
<ogra_> thats 70+ MB
<ogra_> yeah
<ogra_> kernel can easily vary a lot ... if you produce a monolithic one with no modules that might actually become a pretty small snap
<Chipaca> ogra_: not smaller than the kernel snap on a classic system
<Chipaca> :-D
<ogra_> yet, if you use our generic kernel and ship all modules 200MB is probably a likely size
<ogra_> (modulo squashfs compression)
<Chipaca> ah :-)
<ogra_> snap info says the pc-kernel snap has 130MB in stable
<ogra_> so thats probably a good number
<ogra_> add some wiggle room and you end up at 150
<Chipaca> so if we want to leave enough space to refresh core+kernel+gadget, 250MB would not be a bad number
<ogra_> yeah
<Chipaca> that's a lot, but it also seems reasonable
<Chipaca> OTOH if you're on classic, 100MB would be fine
<pedronis> Chipaca: notice though that means you need to teach UpdateMany to try only  subset of all things in some cases
<ogra_> (gadgets are usually in the kilobytes though :) (unless they are raspberry pis with blob firmware :P ))
<Chipaca> pedronis: allow me to weep a little
<Chipaca> pedronis: but yes
<Chipaca> pedronis: i'm just exploring the space, still
<pedronis> or piggyback on the prerequisites task mvo is adding in one of his branches
<pedronis> Chipaca: that's trying to make sure we don't make it worse
<pedronis> like you get stuck
<ogra_> Chipaca, also take into account that our device images come with only a few MB free in writable ... expansion only happens on first boot
<pedronis> Chipaca: it depends alos where you check/fail
<ogra_> (5 oor 10 ... i forgot what ubuntu-image adds exta ... but it isnt much)
<pedronis> Chipaca: if you check in download just before downloading it might be alright with lanes
<pedronis> but also need to check if UpdateMany create sequential lanes or not, IÂ don't think so
<Chipaca> pedronis: ogra_: added this to https://forum.snapcraft.io/t/out-of-disk-space-protection/1632/8
<pedronis> Chipaca: thx
<cachio_> mvo, I already saw this error in pi3 and i385 exec https://paste.ubuntu.com/25432913/
<cachio_> mvo, not sure if the problem is in the snap or it is in snapd
<cachio_> It is breaking the whole execution on pi3, I am running again without that test
<Chipaca> cachio_: :-(
 * zyga-ubuntu updates to artful
<mvo> cachio_: a race in the tests :(
<cachio_> mvo, yes, seems to be
<cachio_> mvo, I am skipping this one
<cachio_> mvo, I'll fix it on master
<mvo> cachio_: I have a fix ready
<mvo> cachio_: it is in #3825
<mup> PR #3825: tests: add nmcli regression test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3825>
<mvo> cachio_: the problem is that systemd considers the unit started too early. i.e. nm has started, but it has not yet setup its dbus things
<cachio_> mvo, you are fast!!
<cachio_> mvo, great
<cachio_> mvo, the rest of the exec is ok, so we are going well
<zyga-ubuntu> jdstrand: commented on https://github.com/snapcore/snapd/pull/3621#discussion_r136128075
<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'm happy to split the rule, can you be more specific as to what you expect
<nacc> so i'm using an application (not exposed) in my classic snap that has a hardcoded path. Is my best bet to fork their repository and apply a patch to make it a non-absolute path for the purpose of using it in the snap (since I need to use the version from my snap)?
<zyga-ubuntu> nacc: or some preload tricks
<nacc> zyga-ubuntu: ok, thanks
<nacc> zyga-ubuntu: what preload trick would work to alter a hardcoded path buried in a python file? :)
<zyga-ubuntu> nacc: one that remaps open
<nacc> zyga-ubuntu: oh ... gross :)
<nacc> zyga-ubuntu: i'll just fork :)
<nacc> i filed a bug/feature request upstream
<zyga-ubuntu> that's much better long-term IMO
<nacc> yeah
<nacc> zyga-ubuntu: thanks!
<jdstrand> zyga-ubuntu: I'll comment in the PR (a bit later). note I have not done my full review of the pr yet. planning on it a bit later today
<zyga-ubuntu> jdstrand: thank you!
<zyga-ubuntu> I'm (passive) driving home so I have limited conditions
 * zyga-ubuntu tries to focus on reviews amids $distractions
 * zyga-ubuntu watches the sunset 
<arm1e> Hey guys, can you help with an error at the end of building please. Will paste, hold on...
<arm1e> https://paste.ubuntu.com/25433178/
<arm1e> last line is red in terminal
<zyga-ubuntu> arm1e: looked, no idea
<arm1e> willsee if it will install.
<ogra_> well, it tires to remove a file that doesnt exist obviously
<ogra_> you might want to put libgtk-3-bin into build-packages
<zyga-ubuntu> jdstrand: btw, is your comment on https://github.com/snapcore/snapd/pull/3814 a formal +1?
<mup> PR #3814: interfaces: enable partial apparmor support <Created by zyga> <https://github.com/snapcore/snapd/pull/3814>
<jdstrand> zyga-ubuntu: not until the comments were addressed. let me look at the new commits
<zyga-ubuntu> jdstrand: I think they are, let me know if something is missing
<jdstrand> zyga-ubuntu: done
<niemeyer> mvo: Can we merge #3830 or do we need to wait for the autopkgtests?
<mup> PR #3830: tests: deal with __PNR_chown on aarch64 to fix FTBFS on arm64 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3830>
<zyga-ubuntu> jdstrand: strict mode with logging?
<zyga-ubuntu> jdstrand: are you referring to using the real strict template
<jdstrand> zyga-ubuntu: yes. the point of partial is to let apparmor mediate what it can for whatever kernel is running, and logging what it can't
<zyga-ubuntu> jdstrand: and logging == devmode?
<jdstrand> no
<zyga-ubuntu> ahh
<zyga-ubuntu> right
<zyga-ubuntu> so about that
<zyga-ubuntu> (now that I understand the question)
<jdstrand> cause,in my mind, classic confinement != partial confinement
<jdstrand> just like devmode != partial confinement
<jdstrand> maybe I misunderstand where you are going?
<zyga-ubuntu> (call)
<zyga-ubuntu> re
<zyga-ubuntu> jdstrand: I plan to switch to the normal template and see what happens in practice, if snaps using particular interface misbehave. I'm not very scientific abut this yet
<zyga-ubuntu> jdstrand: my goal is to enable enforcing confinement to all the features that the kernel offers
<zyga-ubuntu> jdstrand: and, if necessary, insert compatibility permissions so that apps operate
<jdstrand> zyga-ubuntu: ok, good, that is what I understood to be where you were going
<jdstrand> yep, +1
<zyga-ubuntu> jdstrand: (as I recall some things changed behavior as specific features were introduced)
<zyga-ubuntu> jdstrand: I'm mainly doing this because I spend most of my time on opensuse
<jdstrand> we can do in the interfaces, if partial append(...)
<zyga-ubuntu> jdstrand: and also as a way to have distros on vanilla 4.14 LTS supported to the extent possible
 * jdstrand nods
<jdstrand> +1
<zyga-ubuntu> jdstrand: yep, the way I coded it now is that we can see specific features
 * jdstrand nods
<zyga-ubuntu> jdstrand: so that we can be smarter than just "partial vs full"
<jdstrand> yeah
<zyga-ubuntu> great, sorry about being confused, tired from the trip and general chaos today :)
<jdstrand> I was going to correct myself, but then thought it hard to quickly write the pseudo code for that :)
<zyga-ubuntu> jdstrand: and also had a call from family to interrupt at the "best" moment :)
<jdstrand> they have a tendency to do that. hope everything is ok and the chaos diminishing
<zyga-ubuntu> yes, all is very good :)
<zyga-ubuntu> we're together and safely heading home
<jdstrand> nice
<nacc> is it possible to do a local cleanbuild using a specific container image?
<zyga-ubuntu> mvo: my kids go to local school on Monday :)
<zyga-ubuntu> mvo: we'll finally wake up at 6:00 :)
<bschaefer> hey, getting a fun install error on my raspi3: snap install mir-libs --edge
<bschaefer> error: cannot install "mir-libs": snap type unset
<zyga-ubuntu> bschaefer: interesting
<zyga-ubuntu> bschaefer: can you run "snap version"
<bschaefer> zyga-ubuntu, http://paste.ubuntu.com/25433361/
<bschaefer> i tried a refresh but was all up to date
<zyga-ubuntu> that's good
<bschaefer> was working yesterday, so was figuring an auto update possibly
<bschaefer> or some state got stuck somewhere
<ogra_> snap changes
<ogra_> ... should tell you
<bschaefer> https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapmgr.go#L143
<zyga-ubuntu> bschaefer: yes, perhaps
<zyga-ubuntu> I don't have a way to download that revision now
<zyga-ubuntu> I'd love to see the snap.yaml file from mir-libs from edge from armhf
<zyga-ubuntu> in case anyone from store side can provide that
<bschaefer> zyga-ubuntu, i can install local *.snaps
<bschaefer> i can try any package from the store if you want
<bschaefer> was happening with mir-kiosk as well
<zyga-ubuntu> bschaefer: aha
<ogra_> is your SD full ? :)
<bschaefer> ... /me checks syslog
<ogra_> df -h /writable
 * zyga-ubuntu finishes update to arftul
<bschaefer> /dev/mmcblk0p2  3.6G  680M  2.7G  21% /writable
<zyga-ubuntu> upstart is being removed :'(
<bschaefer> hmm seems happy
<bschaefer> though it actually failed to install the local snap
<ogra_> yeah, just to make sure
<zyga-ubuntu> what do you see in snap changes (ogra's idea is good!)
 * bschaefer digs around syslog
<bschaefer> umm
<bschaefer> Aug 30 17:54:32 localhost kernel: [    5.716015] EXT4-fs (mmcblk0p2): couldn't mount as ext2 due to feature incompatibilities
<bschaefer> Aug 30 17:54:32 localhost kernel: [    5.736041] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
<ogra_> yeah,
 * zyga-ubuntu reboots
<zyga-ubuntu> I *hope* to see you soon
<ogra_> way to noisy ...
<ogra_> (not an issue)
<bschaefer> o ok
<bschaefer> :)
<ogra_> the ext4 driver supports ext2 and  too
<ogra_> it loops over the features when mounting an fs
<ogra_> and prints that crap ... and eventually mounts ext4
<bschaefer> ogra_, hmm yeah i dont see any yelling about full or ... anything
<bschaefer> though this log is always large :)
<ogra_> no, if df is happy everything should
<bschaefer> yeah and AlbertA has it working on a raspi3 with same version
<ogra_> samy snapd too ?
<bschaefer> sooo im thinking ... something is going on with my image
<bschaefer> yeah
<ogra_> *same
<mvo> cachio_: thank you!
<mvo> niemeyer: yeah, merged it now
<mup> PR snapd#3830 closed: tests: deal with __PNR_chown on aarch64 to fix FTBFS on arm64 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3830>
<mup> PR snapd#3825 closed: tests: add nmcli regression test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3825>
<bschaefer> ogra_, 119  Done    2017-08-30T17:38:21Z  2017-08-30T17:41:17Z  Refresh snaps "core", "pi2-kernel"
<bschaefer> was the last refresh
<bschaefer> (besides me messing with interfaces/connects)
<ogra_> both should be fine
<ogra_> (didnt break here on my pi2 (my 3 is off atm) )
<bschaefer> ogra_, well since AlbertA image is working im just going to reflash
<bschaefer> unless you want any more debug info off it :)
<ogra_> perhaps zyga would ...
<bschaefer> yeah i can wait a bit
<ogra_> well, he just did a dist-upgrade to artful ... i'D set a time limit :)
<ogra_> heh
<bschaefer> haha
<ogra_> speaking of the devil
<zyga-ubuntu> so
<bschaefer> ive yet to do that, been meaning to
<zyga-ubuntu> that worked
<zyga-ubuntu> but network-manager still crashes on my modem
 * ogra_ builds to many snaps ... i stay on xenial 
<bschaefer> well thats good news, as ive been planning on going to artful this weekend
<bschaefer> zyga-ubuntu, so fun, AlbertA has a raspi3 with all the same versions
<bschaefer> and he is just fine installing snaps
<ogra_> i have a pi2 here with the same setup/versions too .. no issues
<zyga-ubuntu> bschaefer: I'm happy to debug this tomorrow
<bschaefer> zyga-ubuntu, cool yeah i can keep this SD around. Want to make sure you get any debug info out you want
<zyga-ubuntu> bschaefer: but today my working conditions are ... unusual, and I need to do three releases for different distros
<zyga-ubuntu> thank you!
<bschaefer> yup no worries, i can use a different SD card for work atm and reflash
<bschaefer> np, and thank you!
<zyga-ubuntu> I'll ask around gnome developers tomorrow
<zyga-ubuntu> maybe someone will know how to debug
<mvo> zyga-ubuntu: uh, 6:00am - sounds like fun (not!)
<niemeyer> mvo: Thanks!
<arm1e> ogra_: sorry, wasputting toddler to bed. it's not my snap, just one from github, but it ran  fine in a previous build. Should all of the snap folders (prime, snap etc,) have contents once it has built successfully?
<arm1e> Can someone please tell me if they can get this to build correctly so that I know if it is my setuo that is the issue: https://github.com/jacobzimmermann/gnucash-jz-snap
<arm1e> Thanks
<arm1e> (Not my snap, just want to try it)
<nacc> arm1e: so ... the error message you got
<arm1e> nacc: yup
<nacc> arm1e: that snapcraft.yaml has a install entry
<nacc> arm1e: which does the rm
<nacc> arm1e: possibly that line (109) needs updating if that binary has moved, isn't used, etc
<arm1e> nacc: Not much I can do then, other than to wait for it to be fixed
<nacc> arm1e: you can fork and fix it yourself :)
<arm1e> I dont know how to
<arm1e> fix, not fork
<nacc> arm1e: ah ok
<arm1e> nacc: Ok, looking at the build, it is the staging directory that has that file in usr/sbin/
<arm1e> nacc: the file is there, so why wont it delete?
<nacc> arm1e: i don't know, and i don't know why it's done that way
<nacc> arm1e: but you coudl make it `rm -f` and it would not fail anymore
<arm1e> will try
<arm1e> nacc: might have worked!
<arm1e> nacc: Right, a;; snapped up and ready to test!
<arm1e> nacc: Error, cannot find signatures with metadata for snap
<arm1e> nevermind, found the option to force the install
<nacc> arm1e: nice
<arm1e> yeah, but wont run after installed. Nothing happens
<arm1e> oh well
<mup> PR snapcraft#1518 opened: project: introduce build-snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1518>
<arm1e> nacc: Will wait for a fix. Thanks for your help
<jdstrand> willdeberry: hi! you probably saw this, but fyi, I commented on https://github.com/snapcore/snapd/pull/3812
<mup> PR #3812: interfaces: expose bluez interface on classic OS <Created by willdeberry> <https://github.com/snapcore/snapd/pull/3812>
<jdstrand> willdeberry: it is really close now
<willdeberry> jdstrand: got out of meeting and noticed. just submitted an updated revision :)
<jdstrand> willdeberry: one last small thing
<jdstrand> willdeberry: s/s.appSlot/s.coreSlot/ for the udev on classic test
<jdstrand> (see the PR)
<willdeberry> rgr
<willdeberry> stupid miss by my part. all fixed though
<jdstrand> willdeberry: ok, approved. thanks!
<willdeberry> glad I was able to figure it out. honestly thought it was going to end up being one of those things you post on the forum and twiddle your thumbs while someone else fixed lol
<jdstrand> hehe
<jdstrand> :)
<jdstrand> you took control of the situation :)
<willdeberry> with a lot of help from you and others. definitely much appreciated
<jdstrand> willdeberry: np, my pleasure
<willdeberry> the tests do take a crazy amount of time to run i've noticed
<mup> PR snapcraft#1516 closed: lxd: LXD not installed when using remote <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1516>
<mup> PR snapd#3573 closed: overlord: always try to get a serial, lazily on classic <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3573>
<davidcalle> sergiusens: elopio: following the build-snaps PR, an issue or PR for https://github.com/CanonicalLtd/snappy-docs/blob/master/build-snaps/syntax.md will be appreciated, thanks!
<sergiusens> davidcalle: sure, but you owe me an answer wrt the tour ;-)
<davidcalle> sergiusens: oh, I didn't replied? With fire, kill it with fire ;-)
<sergiusens> my eyes are pleased to read that!
<Pharaoh_Atem> niemeyer: here it is: https://forum.snapcraft.io/t/proposal-move-to-more-granular-architecture-names-for-snaps/1916
#snappy 2017-08-31
<mup> PR snapcraft#1517 closed: vcs: ignore .vscode project settings  <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1517>
<zyga-ubuntu> good morning
 * zyga-ubuntu updates debian snapd to .5 
<zyga-ubuntu> hello mvo
<mup> PR snapd#3502 closed: snap-seccomp: add in-kernel bpf tests  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3502>
<mvo> hey zyga-ubuntu, good morning
<mvo> zyga-ubuntu: how are you? happy about better network :)?
<zyga-ubuntu> mvo: yes, I just installed debian-keyring in a blink of an eye
<zyga-ubuntu> mvo: and that's a welcome sight :)
<zyga-ubuntu> mvo: I'm working on the .5 update for debian
<zyga-ubuntu> mvo: could you please upload the extra tarballs to https://github.com/snapcore/snapd/releases/tag/2.27.5
<mvo> zyga-ubuntu: uh, thank you, doing that now. sorry
 * zyga-ubuntu is sad to see gustavo remove 2.28 from 3814
<mvo> zyga-ubuntu: updated
<zyga-ubuntu> thank you
<mup> PR snapd#3812 closed: interfaces: expose bluez interface on classic OS <Created by willdeberry> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3812>
<zyga-ubuntu> hmm
 * zyga-ubuntu tries to wrap his head around the git tree for debian snapd
<abeato> lool, maybe you know, what is this flash-kernel package?
<mvo> pedronis: 3781 has two +1 and green tests, this can go in, right?
<pedronis> mvo: yes, IÂ think so
<mup> PR snapd#3781 closed: cmd/snap-repair: track and use a lower bound for the time for TLSÂ checks <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3781>
<zyga-ubuntu> mwhudson: hey
<zyga-ubuntu> mwhudson: around?
<mwhudson> zyga-ubuntu: ish
<zyga-ubuntu> mwhudson: so, I looked at other distros but now I'm back to debian
<zyga-ubuntu> mwhudson: how should I approach this? I see git-buildpackage files
<zyga-ubuntu> mwhudson: what is the workflow?
<zyga-ubuntu> mwhudson: I have both the gbp tree and the dst files from .4
<zyga-ubuntu> mwhudson: should I import-orig?
<mwhudson> zyga-ubuntu: i don't really use gbp much i guess
<zyga-ubuntu> mwhudson: ok, so how do you maintain the git repo at alioth?
<mwhudson> git merge 2.27.5; dch; git push i think
<mwhudson> oh git commit as well of course :)
<zyga-ubuntu> mwhudson: so merge the snapd upstream repository in this manually?
<mwhudson> yeah, i have upstream as a remote
 * zyga-ubuntu tries
 * zyga-ubuntu tries building
<zyga-ubuntu> mwhudson: thanks, I was approaching this from the wrong angle
<zyga-ubuntu> mwhudson: will you dput if I push it back?
<zyga-ubuntu> mwhudson: reviewdput
<zyga-ubuntu> review/dput
<mwhudson> zyga-ubuntu: yes, tomorrow :)
<zyga-ubuntu> mwhudson: ok
<zyga-ubuntu> mwhudson: I mean, just the changelog
<zyga-ubuntu> apart from that it was a clean merge
<mwhudson> zyga-ubuntu: cool
<zyga-ubuntu> http://paste.ubuntu.com/25437187/
<zyga-ubuntu> mwhudson: I can dput if I have the permissions to do so
<mwhudson> zyga-ubuntu: push
<mwhudson> pls
<zyga-ubuntu> k
<mwhudson> :)
<mwhudson> sorry for terseness, a bit tired :)
<pedronis> mvo: what's the plan for 2.28 now?
<zyga-ubuntu> mwhudson: pushed
<mvo> pedronis: I it seems 2.27.5 is looking good, so today might be a good day to fork it, I have not checked the 2.28 milestones yet though
<pedronis> mvo: there's one PRÂ by zyga, seems a bit of a stretch to fit it in, unless we want to do it next week
<mvo> pedronis: let me have a look, we could create the 2.28 branch on monday too, that has the added benefit that 2.27 should be out of the door by then
<mvo> pedronis: 2.27.5 in stable hopefully
<pedronis> mvo:  #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> pedronis: aha, yeah, this one looks risky
<zyga-ubuntu> mvo: risky?
<mvo> zyga-ubuntu: well, lots of feedback from jamie, no gustavo review yet, risky in the sense that it may take time to get it in shape
<zyga-ubuntu> mvo: this was reviewed by gustavo already
<zyga-ubuntu> mvo: we did it over a hangout
<zyga-ubuntu> mvo: the feedback I reacted to was actually from gustavo originally
<pedronis> he should probably vote too for clarity
<mvo> zyga-ubuntu: aha, I don't see anything in the PR itself about this
<zyga-ubuntu> mvo: I'm only worried about one thing: https://github.com/snapcore/snapd/pull/3621#discussion_r136204646
<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: exactly what pedronis said, hard for others to know that
<zyga-ubuntu> mvo: yes, gustavo didn't comment
<pedronis> anywway jamie didn't finish his review yesterday
<zyga-ubuntu> mvo: I think I need to talk to jamie about that point as I wasn't planning on confining snap-update-ns yet
<mvo> zyga-ubuntu: aha, ok
<zyga-ubuntu> it's way further down the line and I don't think this is any less safe
<zyga-ubuntu> (since snapd already calls it unconfined on interface changes)
<mvo> zyga-ubuntu: right, so that is what I mean with "risky", it seems there are some open points still
<mvo> zyga-ubuntu: anyway, if its important we can wait, but I don't want to wait long :)
 * zyga-ubuntu would love to get some real-world testing for this
<zyga-ubuntu> right
<pedronis> we should be careful not too move thing so much that 2.29 is after the rally
<mvo> pedronis: gustavo has some questions in 3773 about the possiblity to simplify the repair logs by overwriting some old data. I'm slightly concerned about the possible information loss but OTOH it will mean a much more tidy output. have you seen his comment?
<pedronis> yes, IÂ have seen his comment
<mvo> pedronis: good point about the rally
<pedronis> mvo: IÂ suppose if we send   execution where  exit status !=Â 0 to errtracker, losing data is a bit less of an issue
<pedronis> the script doesn't change for the same revision
<pedronis> so as long as we keep enough info to know which revno we *did* run, it should be ok
 * zyga-ubuntu reboo/
<pedronis> mvo: less files around would be nicer
<stub> Would it be possible to make a classic snap that exposes an arbitrary filesystem path to a contained snap via the content interface ?
<pedronis> mvo: then we would renames all files  to r#.ext   as we discussed already
<lool> abeato: what do you need to know about flash-kernel?
<ogra_> stub, ICBW but i think classic turns off all interface capabilities
<lool> abeato: it's an ad hoc way to install kernels on random ARM and other boards
<lool> e.g. in flash, on this or that partition, in this or that format etc.
<mvo> pedronis: aha, excellent plan - so errtracker+simplified logs. I will do that
<stub> oh, I thought that sort of thing was starting to be allowed to make it easier to transition from classic -> contained.
<ogra_> that would be quite a security hole
<abeato> lool, yeah, I was wondering what did it support. uboot only? would it support creating and flashing an android boot partition?
<lool> abeato: it does support flashing an android style image
<lool> abeato: see https://anonscm.debian.org/cgit/d-i/flash-kernel.git/tree/functions search for abootimg
<lool> abeato: this is how the db entries look like https://anonscm.debian.org/cgit/d-i/flash-kernel.git/tree/db/all.db
<lool> abeato: search for android in there too
<abeato> lool, hmm, so to have a new device supported, it would need to be added to that DB
<lool> abeato: Yes; I think you can override it localy, but the easiest is to edit a .db file to your looking until it works
<lool> *locally
<abeato> lool, got it, thanks
<lool> abeato: note that Ubuntu's and Debian's flash-kernel often have a large delta, but the general concepts and architecture should be the same
<abeato> lool, ok, noted
<mvo> pedronis: 2.28 has one blocker right now, we need to sort some armhf/arm64 syscall in the seccomp tests, I will dig into that later, right now arm builds are broken :/
<pedronis> mvo: oops, ok
<mwhudson> i guess zyga's reboot didn't go so well
<mvo> yeah, but no worries, I will look into it soon
<zyga> re
 * zyga sent kids to the cinema and resumes work
<zyga> mwhudson: sorry for being off, if you are still around just tell me if I shall dput now
<mwhudson> zyga: this is splitting hairs a bit but uploaders has me@zygoon.pl but the changelog is @canonical.com
<mwhudson> zyga: otherwise looks fine, i assume you've test built it?
<zyga> mwhudson: aw, sorry, shall I amend and force pus>
<mwhudson> zyga: pls
<zyga> yes, certainly
<zyga> mwhudson: doing that now
<zyga> mwhudson: edited, let me rebuild ... just in case
<zyga> I also fixed the local repo config so that the right email gets used in the future
<mup> PR snapcraft#1519 opened: lxd: use a unique temporary folder <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1519>
 * zyga sighs
<zyga> artful is artfoul for me :/
<mup> PR snapd#3831 opened: store: move device auth endpoint uris to config <Created by atomatt> <https://github.com/snapcore/snapd/pull/3831>
<pedronis> mvo: Chipaca: do you remember what's the state of this:  https://forum.snapcraft.io/t/hashsum-failures-during-tests/198/4
<jdstrand> mvo: you need set_tls
<pedronis> so fedora is back to flakyness
<pedronis> https://travis-ci.org/snapcore/snapd/builds/270368782?utm_source=github_status&utm_medium=notification
<jdstrand> mvo: syscall=983045. scmp_sys_resolver -a arm 983045
<jdstrand> mvo: also, syscall=78, scmp_sys_resolver -a aarch64 78: readlinkat
<jdstrand> mvo: so, set_tls for armhf and readlinkat for arm64
<jdstrand> mvo: i386 failure was unrelated to seccomp
<jdstrand> mvo: with old snap-confine I think we may have limited the architectures we ran the testsuite on, so didn't have the full list
<jdstrand> mvo: I'm going to try to build snapd from the ppa in a classic chroot on armhf and see if it needs more than set_tls
<jdstrand> mvo: my dragonboard is not readily available, but if you need me to do the same there, I can
<mup> PR snapd#3832 opened: cmd/snap-seccomp/main_test.go: add syscalls for armhf and arm64 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3832>
<jdstrand> mvo: that is for you ^ (I'm still checking armhf)
 * ogra_ glares at 983045 ... i always thought syscall is an int
<jdstrand> that's an int :)
<jdstrand> arm has a few high numbered syscalls for historical reasons
<mvo> jdstrand: aha, excellent, thank you
<ogra_> heh, i guess i'm to old ... somehow my brain made int a 16bit thing :)
<mvo> jdstrand: yeah, our testing is now much much better with the new code, thanks a bunch for the PR
<jdstrand> mvo: ok  github.com/snapcore/snapd/cmd/snap-seccomp99.356s (armhf)
<jdstrand> mvo: let me dig up my dragonboard
<mvo> jdstrand: thanks a bunch. I'm running the tests in my pi2 currently too, but I gues I could hit ctrl-cl now :)
<jdstrand> mvo: you can :)
<mvo> jdstrand: all green, thanks a bunch
<jdstrand> mvo: I *think* arm64 is going to be ok if I remember previous patches, but will run the tests in classic on there and update the PR. I'll ping you either way
<mvo> jdstrand: if its much of a hassle we can merge/upload it and see if the arm64 build still fails
<mvo> jdstrand: getting the dragnboard to work I mean
<jdstrand> mvo: we may have to do that, give me a few minutes. lights are lit...
<jdstrand> mvo: https://github.com/snapcore/snapd/pull/3832#issuecomment-326284730
<mup> PR #3832: cmd/snap-seccomp/main_test.go: add syscalls for armhf and arm64 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3832>
<Chipaca> pedronis: I don't remember the state of that
<cachio_> Chipaca, https://paste.ubuntu.com/25438314/
<cachio_> Chipaca, i have this in a linode machine
<Chipaca> cachio_: with shell access?
<cachio_> yes
<Chipaca> cachio_: PM me the creds?
<Chipaca> cachio_: from .spread*
<zyga-ubuntu> RE
<zyga-ubuntu> mvo: re,
<zyga-ubuntu> mvo: I can now push that udev fix
<zyga-ubuntu> mvo: and other changes
<zyga-ubuntu> mvo: did you do the udev fix already by any chance?
<zyga-ubuntu> mwhudson: pushed as agreed earlier
<zyga-ubuntu> mwhudson: aha, except that !ff are rejected
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/3833 is the fix I talked about
<mup> PR #3833: interfaces/opengl: use == to compare, not = <Created by zyga> <https://github.com/snapcore/snapd/pull/3833>
<mup> PR snapd#3833 opened: interfaces/opengl: use == to compare, not = <Created by zyga> <https://github.com/snapcore/snapd/pull/3833>
<niemeyer> Hey!
<niemeyer> Will be a couple of mins late. Just finishing the mate
<jdstrand> omg
<pedronis> mvo: I justed noticed (because zyga didn't delete it), that the link to the contributing guide in the PULL TEMPLATE ends up wrong
<zyga-ubuntu> niemeyer: ok
<zyga-ubuntu> jdstrand: ?
<jdstrand> mvo: the sd card wasn't pushed in all the way :P
<mvo> jdstrand: haha
<mvo> jdstrand: ok
<zyga-ubuntu> jdstrand: LOL
<mvo> pedronis: meh, ok
<pedronis> we probably need an absolute link there
<pedronis> mvo: we get this atm:  https://github.com/snapcore/snapd/pull/CONTRIBUTING.md
<mvo> pedronis: ok
 * Chipaca omw
<jdstrand> mvo: ok, give me a few minutes. I'm in
<mvo> jdstrand: great, thanks you
<zyga-ubuntu> mwhudson: resolved
<ikey> zyga-ubuntu, im gonna have some time again for my PR in the next couple of days so im tempted to withdraw and make new
<ikey> so that its logically organised
<ikey> haven't been on top of it as much as i woulda liked, sorry, but a ton of stuff going on atm
<zyga-ubuntu> ikey: that's okay
<zyga-ubuntu> ikey: consider chopping it in pieces that can land separately
<ikey> between post solus 3, kernels, budgie 11, mate bits... zonked.
<zyga-ubuntu> ikey: small diff >> chance of landing IMO
<Son_Goku> morning all
<ikey> yeah thats what im thinking
<zyga-ubuntu> ikey: thank you for doing this
<ikey> the PR is a bit convoluted right now if we're honest
<ikey> should be **initial** solus support, then apparmor refinement, then GPU stuff, etc
<zyga-ubuntu> ikey: and part of the PR landed through my opensuse work
<ikey> oh ok
<ikey> hm yeah they'd share some common paths with us
<ikey> lib64 bits
<zyga-ubuntu> I was very generic
<ikey> best way
<zyga-ubuntu> I think it will work for you
<Son_Goku> niemeyer, did you see my post yesterday evening?
<zyga-ubuntu> Son_Goku: we're in a call now, will be done in ~20 min
<greyback> hey, I'm trying to get ubuntu core working on my raspberry pi3, but it is hanging when applying my network config (using wifi, it is stuck at 66%)
<greyback> what could I do to debug/where can I log a bug?
<ogra_> greyback, which image (you need edge/daily)
<greyback> ogra_: ah, I'm using stable.
<greyback> ok, I'll switch image
<ogra_> yeah, dont do that on the pi's
<greyback> we should not point to stable on https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3
<davidcalle> greyback: why?
<ogra_> davidcalle, because the kernels are ancient
<ogra_> but we can not point to daily/unstable eithere
<greyback> davidcalle: if it doesn't work... or at least admit there may be wifi issues
<ogra_> the prob is that we can not upgrade kernels on the pi ... until we have gadget upgrades in snapd
<davidcalle> ogra_: IIRC, wifi works after first boot, right?
<ogra_> davidcalle, not sure if the old stable kernel even has all firmware included
<ogra_> (we could never test it back when that kernel was created because back then netplan was still completely broken)
<ogra_> (regarding the brcmfmac driver)
<davidcalle> ogra_: ok, let's present the issue on the page then, with both links. Which image do you recommend to get wifi working?
 * greyback trying edge, will let you know if it works out of the box
<ogra_> davidcalle, daily/edge ... one sec
<ogra_> davidcalle, http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ ... (or my images from http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/)
<zyga-ubuntu> mvo: about the base snaps, let me drive home and let's have the call on telegram
<davidcalle> greyback: thanks for testing (at a coworking space today)
<zyga-ubuntu> mvo: when would be a comfortable time for you?
<greyback> davidcalle: np
<mvo> zyga-ubuntu: maybe in ~30-45min?
<mvo> zyga-ubuntu: or later
<zyga-ubuntu> mvo: that sounds good to me
<zyga-ubuntu> 45-60 min
<mvo> zyga-ubuntu: sounds good
<zyga-ubuntu> I'll be home then
<zyga-ubuntu> on my business network :D ^_^
 * zyga-ubuntu heads home 
<jdstrand> mvo: so, I'm having a number of problems. notably: /usr/lib/go-1.6/pkg/tool/linux_arm64/link: running gcc failed: fork/exec /usr/bin/gcc: cannot allocate memory
<greyback> davidcalle: ogra_: edge/daily fixes my wifi issue, all seems to be working well now, thanks!
<jdstrand> mvo: but also, the core snap is stuck on r1432. it keeps wanting to reboot, so I do, then it says it needs to reboot. r2781 is present, but I guess it fails to boot, goes back into r1432 and then loops
<Chipaca> jdstrand: does setting GOMAXPROCS=1 help the memory issue?
 * jdstrand tries
<Chipaca> jdstrand: what board is this, btw?
<jdstrand> Chipaca: dragonboard
<Chipaca> jdstrand: that had a reasonable amount of memory. strange.
<niemeyer> Son_Goku: Thanks for the post!
<jdstrand> Chipaca: looks like 8G
<Chipaca> :-(
<jdstrand> oh no
<jdstrand> it is 800M
<jdstrand> that seems weird
<jdstrand> Chipaca: that did not help
<mvo> jdstrand: snap version would be nice to kow what is goind on, i.e. why you can't refresh
<mvo> jdstrand: 800mb seems a bit on the low side indeed
<jdstrand> $ snap version
<jdstrand> snap    2.23~201703020745.git.0f2bdc1~ubuntu16.04.1
<jdstrand> snapd   2.23~201703020745.git.0f2bdc1~ubuntu16.04.1
<jdstrand> series  16
<jdstrand> kernel  4.4.0-1049-snapdragon
 * jdstrand hadn't booted this in a while
<jdstrand> https://developer.qualcomm.com/hardware/dragonboard-410c says it has 1G of memory. so I guess the kernel is taking up the first 200M
<Chipaca> jdstrand: any swap? is /tmp a tmpfs?
<jdstrand> Chipaca: no swap
<Son_Goku> niemeyer, I think I covered everything okay
<Chipaca> Son_Goku: niemeyer: is the idea to then have a "amd64 can install amd64, i686, ..., i385" thing?
<Chipaca> that'd be awesome
<Son_Goku> Chipaca, that's one hope, yes
<Son_Goku> in rpm, we have an arch compatibility table that allows for that semi-automagically
<Son_Goku> once the architecture name scheme is fixed up, we can rather easily port that table into snapd and allow that
<Son_Goku> so like, for example, x86_64 can install x86_64/amd64, i686, i586, ..., i386 and so on
<Son_Goku> and armv7hl can install armv7hl, armv6hl, but not armv6hnl or armv7hnl
<Chipaca> yeah that sort of thing
<Chipaca> i'm sold already :-)
<Chipaca> it's going to be a bunch of work though
<Son_Goku> yeah
<Chipaca> at least
<Chipaca> on intel, ia64 and ia32 use different syscalls
<Son_Goku> yeah
<Chipaca> so seccomp is munged up
<Chipaca> i dunno arm
<Chipaca> but i expect surprises
<Chipaca> still, we've got the former covered already (because you can ship ia32 binaries in ia64 snaps)
<Son_Goku> speaking of which, it's somewhat sad how often I get asked if people can run amd64 stuff on their 64-bit x86 machine
<mvo> kyrofa: hey, do you know if anything is missing from my side for the snapcraft pr#1420?
<Chipaca> Son_Goku: "no, sorry, itanium only"
<davidcalle> ogra_: greyback: thanks for the heads up/testing, adding edge to the page with some explanations. Is it the case for Pi2 and Pi3 or just Pi3?
<Son_Goku> which is partly why I use "x86_64" as the name, as it's pretty damn generic
<Son_Goku> people seem to get that it's Intel or AMD with that name
<ogra_> davidcalle, no wlan on pi2 ;)
<davidcalle> ogra_: so it doesn't work? :p
<ogra_> Son_Goku, but totally historically incorrect :)
<ogra_> davidcalle, there is no wlan hardware :)
<jdstrand> Chipaca: 'so seccomp is muged up' -- what exactly are you talking about?
<jdstrand> munged*
<Son_Goku> ogra_, yeah, yeah
<Son_Goku> I know AMD invented it
<lool> So I have a working image with a signed kernel; I'm trying to test a new kernel without reflashing the device entirely; I get: - Mount snap "joule-linux" (unset) (cannot replace signed kernel snap with an unasserted one)
<lool> I guess there's no way to bypass this?
<Chipaca> jdstrand: i mean: seccomp rules for ia32 and ia64 are separate (right?)
<ogra_> Son_Goku, well, alpha did ... AMD just poiorted it to x86 compatibility
<ogra_> *ported
<Son_Goku> well yes
<Chipaca> lool: why not push the new kernel up, so it gets signed?
<Son_Goku> but Linux, the compiler, and several other things call it x86_64
<Son_Goku> which just makes the 'amd64' name more confusing
<lool> Chipaca: cause I dont have the permissions to do so, it's a canonical signed kernel and I'm not in the right teams
<ogra_> Son_Goku, and while i dont really care about the arches i use as a developer ... you have to take familiarity into accoount as well ... users of debian based distros know the other namings ...
<Son_Goku> ogra_: IMO, just support both names as aliases to each other
<ogra_> i wonder if it would make sense to have a "visible layer" that can be distro specific
<lool> this is me testing a kernel change/rebuild, but a partner has the same issue: they need to test a new kernel and they are not Canonical and not in a position to publish a test kernel
<ogra_> so endusers see their distro naming ...
<Son_Goku> yeah
<Son_Goku> if the distro name is known, use that, otherwise fallback to generic name ('x86_64', 'armv7hl', etc.)
<jdstrand> Chipaca: what do you mean by ia32 and ia64? do you mean i386 and amd64 in Ubuntu speak?
<Son_Goku> x86_32 and x86_64, jdstrand
<Son_Goku> so, yes
<Son_Goku> i686 and x86_64 / i386 and amd64
<Chipaca> jdstrand: we were talking about amd64 vs i[3456]86
<jdstrand> ok
<Chipaca> so i used ia32 for the latter
<jdstrand> so, there is a syscall table for each architecture
<Son_Goku> ia64 unfortunately is Itanium
<Chipaca> ouch :-)
<Chipaca> sorry then
<jdstrand> the names of the syscalls are usually the same,but some architectures have different names
<jdstrand> for amd64, it also supports compat syscalls for i386
<Chipaca> lool: I'm not sure (maye noise][ can add info here), but do you need to be canonical to push kernels at all? I'd imagine you'd trigger a manual review, but other than that it should work?
<Chipaca> lool: i mean, you can't push a canonical kernel, but you can push a lool kernel surely?
<jdstrand> so while the names are the same (eg, 'read'), the syscall number in the kernel is different
<jdstrand> $ scmp_sys_resolver -a x86_64 open
<jdstrand> 2
<jdstrand> $ scmp_sys_resolver -a x86 open
<jdstrand> 5
<ogra_> Son_Goku, also your argument about raspbians armhf is a bit moot given they break the standard with that to (falsely) have users be able to use the normal debian rachive alongside
<jdstrand> Chipaca: so, technically, 'yes' things are different, but how we write our policy, it doesn't matter
<ogra_> armhf is always 'armv7hl' ...
<Son_Goku> ogra_, the 'why' is beside the point
<ogra_> that has been pretty much standardized when we started it
<jdstrand> Chipaca: we write our policy, we include all the relevant syscalls for the architectures
<Son_Goku> the point I was trying to illustrate is that base arch names are too coarse
<jdstrand> Chipaca: eg, all the policy has 'open', but it has *both* getfid and getgid32
<Son_Goku> and can be arbitrary or redefined
<jdstrand> err, getgid and getgid32
<ogra_> you cant really punish everyone just because an outsider distro decided to break it
<ogra_> (against better advise actually)
<Son_Goku> ogra_: can it really be considered an outsider distro any more than Ubuntu is to Debian?
<Son_Goku> also, that's a shitty argument to make to begin with
<Chipaca> jdstrand: right, and that's the kind of fiddly thing i'd imagine we'd have to loop around to support running two slightly different flavour of arm binaries in the same snappy system
<jdstrand> Chipaca: if a syscall that we specify doesn't exist on an arch, we ignore it. so set_tls only exists on arm, but it is in the default template, so on amd64 set_tls is ignred
<Son_Goku> ogra_, and this is not even really punishing anyone
<ogra_> measured by userbase and amount of derivatives ? ... yeah
<Son_Goku> as it is today, even Fedora's ecosystem can't properly handle this
<Chipaca> jdstrand: ah, i didn't realise we shipped everything everywhere, that might make it easier
<Son_Goku> because we do have derivatives that do this
<jdstrand> Chipaca: so... adding other architectures is easy-- if there are other syscalls (there wouldn't be terribly many-- most syscall names are shared), we just add them to the appropriate interface
<ogra_> Son_Goku, that is why we tired to form a standard back then ...
<Chipaca> yup
<ogra_> across distros actually
<Chipaca> jdstrand: i get that it wouldn't be a lot of work, but i see it as fiddly work (that i'd be terrible at)
<Son_Goku> well, I was around during the arm bootstraps for these, and I don't recall such a thing happening
<jdstrand> Chipaca: so to bring on itanium, if execve was execve_itanium, then we just add execve_itanium to the default template
<Son_Goku> the rpm guys reached out to arm to actually figure out how to do it
<Son_Goku> and we followed their advice
<ogra_> somewhere in there https://lists.linaro.org/pipermail/cross-distro/
<jdstrand> Chipaca: sure. that is something I could help with
<Son_Goku> anyway, g2g to work
<Son_Goku> bbs as Pharaoh_Atem
<jdstrand> it isn't as fiddly as you might think
<Chipaca> jdstrand: i stopped listening after you promised to do the work yourself
<Chipaca> =D
<jdstrand> because I have the entire list of syscalls for all architectures that Ubuntu builds in ./cmd/snap-confine/README.syscalls
<Chipaca> jdstrand: aha, but that's the thing, we're talking about arch flavours we _don't_ currently build in
<jdstrand> and there are only a few arch-specific syscalls
<Chipaca> but yeah, i get that there wouldn't be a lot of variation
<jdstrand> Chipaca: I understand. there is nothing saying we can't add to that
<Chipaca> like, maybe armv7potato adds one or two
<jdstrand> maybe
<Chipaca> over basic armv7whatever that we currently have
<jdstrand> unlikely, but not impossible
<Chipaca> also why am i, like, suddenly using "like"
 * Chipaca eyes his boys with suspicion
<jdstrand> it is actually probably more possible with arm kernels, since there are so many and they are heavily patched, but it's easy t see when something goes wrong
<jdstrand> importantly though, the arch needs to be supported by libseccomp
<jdstrand> (and I guess the go one, if it doesn't use libseccomp)
<cachio_> mvo, did you trigger snapd in update_excuses?
<jdstrand> otherwise you end up with 'unknown syscall'
<cachio_> I don't see it
<mvo> cachio_: I didn't, let me check the status
<mvo> cachio_: do you see any errors/regressions there?
<lool> Chipaca: hmm I'll try uploading then
<jdstrand> mvo, Chipaca: ok, I removed several snap revisions, upgrade the dragon-board kernel and was able to refresh core to 2776
<jdstrand> so, that part is resolved
 * jdstrand tries to wrestle with the testsuite and memory
<lool> Chipaca: so type: kernel snap goes to manual review queue
<Chipaca> lool: ok, so now you need to request a manual review
<Chipaca> (there's a button in there for that)
<lool> yeah, that's automatic
<Chipaca> it is? it used to be that you had to hit the button
<Chipaca> but ok
<lool> I have a button to remove it from the queue and I got an email telling me it is going into manual review queue
<Chipaca> mvo: ping?
<jdstrand> oh, I should use my swaps snap
<mvo> Chipaca: pong
<Chipaca> mvo: who'd be best for reviewing lool's kernel snap?
<jdstrand> or is that core config now...
<pedronis> mvo: rereviewed a couple of your PRs
<mvo> Chipaca: a good question, what is jdstrand opinion here?
<jdstrand> I can do it
<mvo> ta
<Chipaca> mvo: while he answers that, should ubuntu-16.04/snap-confine.maintscript be in 14.04 also?
<mvo> pedronis: thank you
<jdstrand> done
<Chipaca> lool: done ^
<Chipaca> jdstrand: thanks :-)
<mvo> Chipaca: we don't need it there because we do not do the conffine rename in trusty for apparmor
<jdstrand> lool: if you upload another revision, ping me. the store needs an update to pass automated review
<mvo> Chipaca: we could add it to trusty too though just to have a smaller delta
<Chipaca> mvo: do maintscripts support comments?
<lool> thanks
<jdstrand> lool: are you aware of the 'joule-linux' snap?
<Chipaca> mvo: (are they just shell scripts?)
<lool> jdstrand: well that's the snap I've forked from
<jdstrand> I see
<jdstrand> ok
<lool> I dont think this approach scales well for kernel development on top of UC
<lool> (I realize UC is not really meant to be a devel platform)
<lool> - Mount snap "joule-linux-lool" (1) (cannot replace kernel snap with a different one)
<jdstrand> lool: it doesn't. there is model assertion work that needs to be done
<lool> so I can't switch kernels either
<Chipaca> lool: oh drat
<ogra_> dont rename it
<pedronis> jdstrand: we did some of that work,  we need to sync up on what is missing
<pedronis> jdstrand: IÂ mean model assertion work
 * jdstrand nods
<jdstrand> pedronis: really, I just need to be told when to change the review tools
<cachio_> mvo, I don't see an entry for snapd
<jdstrand> pedronis: as in, if it is now safe for anyone to upload kernels and gadgets, I can remove the check
<mvo> cachio_: there is one file for each distro release, let me check. for example http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#snapd does not has any autopkgtest runs yet it seems
<mvo> cachio_: aha, its missing in artful because it already promoted from artful-proposed to artful
<pedronis> Chipaca: well that's part of the work that should let us drop the manual reviews
<pedronis> you cannot have but the kernel in your model assertion
<pedronis> and that kernel publisher needs to match the model as well
<jdstrand> ogra_: looking at the core snap configure hook, I don't see anything for swaps. I thought I remembered that was going to happen. am I misremembering?
 * jdstrand is not blocked and installs his 'swaps' snap
<ogra_> jdstrand, we have the backend but no config hook
<Chipaca> pedronis: ah :-(
<Chipaca> lool: see what pedronis is saying ^
<Chipaca> so hacking it by hand isn't going to work either
<Chipaca> so, bottom line: no, you can't
<Chipaca> not right now
<ogra_> ogra@bbb:~$ cat /etc/default/swapfile
<ogra_> FILE=/var/tmp/swapfile.swp
<ogra_> SIZE=0
<Chipaca> not yet
<Chipaca> no
<ogra_> jdstrand, ^^^^
<ogra_> jdstrand, if you set it != 0 it creates a swapfile
<cachio_> mvo,
<pedronis> Chipaca: if you want to swap kernels around you need to start with a sideloaded kernel
<jdstrand> Chipaca: size is bytes?
<cachio_> mvo, ok
<Chipaca> ogra_: potatoes
<pedronis> at least that's the current status
 * ogra_ tries to remember ... 
<ogra_> ... looking at the code
<ogra_> jdstrand, MB http://paste.ubuntu.com/25438844/
<cachio_> mvo, so, manual tests passed
<cachio_> just missing update_excuses now to finish the sru
<mvo> cachio_: yay for passing tests, thank you! you mean you miss the output of the autopgktest in update_excuses ? or am I missunderstanding?
<jdstrand> ogra_: thanks
<cachio_> mvo, yes
<Chipaca> mvo: but, i mean, "snap-confine.maintscript"?
<lool> pedronis, Chipaca: So just to share this specific context: this is a partner trying to do the right thing of targeting UC from day one as to avoid developing on classic and moving to UC for production at the end of the devel cycle and running into tons of issues; this means we either currently require classic for devel iterations, or that the CI process has to be architectured around image builds and image tests which is heavier than local iterations with
<Chipaca> mvo: there's also a snapd.maintscript
<Chipaca> lool: cut off at "local iterations wit"
<mvo> cachio_: sounds like we just need to be patient
<cachio_> mvo, yes, almost there
<mvo> Chipaca: correct, we used to ship snap-confine as its own package
<pedronis> lool: as I said if they make an image with a sideloaded kernel they can be able to swap it around, but I'm not sure what's their starting point here
<mvo> cachio_: great, thanks a lot for the quick validation
<Chipaca> lool: so, you start with their own kernel, in their model
<pedronis> swap it around in development I mean
<Chipaca> lool: and then they can refresh it and everything just fine (once they're into the whitelist for reviews)
<lool> pedronis: I was trying to start from a working signed image, but if a sideloaded kernel in an image allows more sideloading, I guess that might be enough
<pedronis> but I'm not sure why didn't start with a development model assertion
<lool> I think I'll rebuild the official image with the official kernel minus its assertions to get the effect of sideloading but the same image contents
<pedronis> anyway
<lool> what's a development model assertion?
<pedronis> just a model assertion with their name for stuff
<pedronis> but they can sideload it
<lool> right
<pedronis> until they have stuff in the store
<lool> well it's a long story
<Pharaoh_Atem> back
 * Pharaoh_Atem sighs
<lool> with things delivered across multiple partner teams and canonical teams
<pedronis> lool: just trying to explain what is possible atm
<lool> pedronis: yup, thanks
<lool> and I'm also learning what good devel cycles we can use in the process
<Pharaoh_Atem> mvo: do you have any idea when we're going to see 2.28 with base snap support and stuff?
<jdstrand> ogra_: fyi $ cat /etc/default/swapfile
<jdstrand> FILE=/var/tmp/swapfile.swp
<jdstrand> SIZE=512
<jdstrand> ogra_: I rebooted and no swap file
 * jdstrand googles for other setup
<mvo> Pharaoh_Atem: I need to convince zyga to accept 3625, then very basic base snap support should be ready, I will try my best for today
<jdstrand> ogra_: /etc/systemd/system/swapfile.service isn't on the device
<jdstrand> ogra_: /usr/bin/mkswapfile is
<jdstrand> ogra_: looks like https://bugs.launchpad.net/snappy/+bug/1560942 is only fix committed for ubuntu-core-config
<mup> Bug #1560942: Support swap <snapd:Invalid> <Snappy:In Progress by ogra> <ubuntu-core-config (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1560942>
<ogra_> jdstrand, hmm https://github.com/snapcore/core-build/tree/master/config/etc/systemd/system
<jdstrand> ogra_: dpkg.list says 0.6.40+ppa46 is installed
<ogra_> ogra@bbb:~$ ls /etc/systemd/system/swapfile.service
<ogra_> /etc/systemd/system/swapfile.service
<ogra_> thats on edge though
<jdstrand> I'm on candidate
<ogra_> ah
<jdstrand> r2776
<jdstrand> but, the fix was supposedly in ppa41, and this has ppa46
<ogra_> which is actually the latest package
<ogra_> and definitely ships /etc/systemd/system/swapfile.service here for me
<ogra_> (it isnt enabled though ... you need to do that manually atm)
<jdstrand> sudo systemctl list-unit-files|grep swap
<ogra_> jdstrand, what arch/device is that
<jdstrand> only swap.target
<jdstrand> dragonboard
<ogra_> very weird ... there is nothing arch specific about this file
<jdstrand> ogra_: it isn't on my bbb, which is on stable with ppa45
<ogra_> hmm, even 45 should have had it ... that really landed a while ago
<jdstrand> ogra_: it isn't on my amd64 vm, which is stable with ppa45
<ogra_> it landed in ppa41 and had a small change in 42
<jdstrand> ogra_: /snap/core/current/etc/systemd/system/swapfile.service exists (amd64)
<ogra_> right, my bbb on armhf has it too
<jdstrand> /etc/systemd/system/swapfile.service does not exist
<jdstrand> these are all just normal upgraded machines
<ogra_> well, it only exists on core ...
<ogra_> and it is shipped by the squashfs
<jdstrand> these are all core devices
<jdstrand> dragnboard, bbb, the amd64 vm
<ogra_> ogra@nanopi-air:~$ grep systemd/system /etc/system-image/writable-paths
<ogra_> /etc/systemd/system                     auto                    persistent  transition  none
<ogra_> /etc/systemd/system.conf.d              auto                    persistent  transition  none
<ogra_> thats the issue ....
<ogra_> "transition"
 * ogra_ points to http://manpages.ubuntu.com/manpages/xenial/man5/writable-paths.5.html 
<jdstrand> ah
<ogra_> i suspect we'd need to "synced"
<ogra_> *need to switch to
<jdstrand> yeah, these are all pretty old machines
<jdstrand> so, I'm not blocked or anything
<ogra_> mvo, what do you pothink about switching /etc/systemd/system to "synced2 intead of "transition" ... so new systemd units from the squashfs get actually copied in place on updates ?
<ogra_> s/pothink/think/
<jdstrand> I guess I could just cp that file into place...
<ogra_> yes, you can
<ogra_> but we want users to recieve such changes automatically i guess :)
<jdstrand> yeah
<jdstrand> ok, if I copy it, enable it and start it, I have a swap
<ogra_> cool, so it works as intended
<mvo> ogra_: yeah, lets try it
<ogra_> i''m a bit scared of braking something though
<ogra_> but i cant put my finger on any clear breakage that could happen
<mvo> ogra_: this definitely needs to get tested carefully, I guess the risk is that we can never remove files from synced dirs
<jdstrand> another option would be to update the core snap to copy the file into placec
<jdstrand> place
<jdstrand> (eg, in configure hook on upgrade)
<mup> PR core-build#17 opened: switch /etc/systemd/system to "synced" mode <Created by ogra1> <https://github.com/snapcore/core-build/pull/17>
<jdstrand> the core-support interface would need to be updated for that
<jdstrand> but I see you are going with the other method :)
<ogra_> heh
<ogra_> yeah, i think we always want new units to be copied if they dont exist in the target dir
<jdstrand> it does make sense
<jdstrand> we don't have interfaces for adding units
<ogra_> which is fine
 * jdstrand nods
<jdstrand> point I was making is that snaps aren't supposed to be able to interact with systemd directly like that
<jdstrand> so, should be good
<zyga-ubuntu> testing
<mup> PR snapd#3832 closed: cmd/snap-seccomp/main_test.go: add syscalls for armhf and arm64 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3832>
<zyga-ubuntu> mvo: I think I'm online now
<zyga-ubuntu> mvo: updated my 1-5KB/s network to 70Mbit
<zyga-ubuntu> 76Mbit down, 21 down
<Pharaoh_Atem> mvo, zyga-ubuntu, I'm debating on whether I should do 2.27.5 or wait for 2.28
<roadmr> zyga-ubuntu: so it's 1400 times faster? that's quite an upgrade.
<Pharaoh_Atem> since there's also a snapd-glib update, and I like doing those two together
<zyga-ubuntu> roadmr: yes, and no longer the crap consumer type
<zyga-ubuntu> Pharaoh_Atem: 2.28 is monday at the earliest
<zyga-ubuntu> Pharaoh_Atem: I'd do .5
 * zyga-ubuntu notices ipv6 
<zyga-ubuntu> oooohh
 * zyga-ubuntu looks at the account page
<Pharaoh_Atem> zyga-ubuntu: keep in mind no one ever tests the updates to make them go quickly
<Pharaoh_Atem> so they sit for a week in updates-testing before shipping out as updates
<mup> PR snapcraft#1514 closed: docs: add github processed templates <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1514>
<zyga-ubuntu> Pharaoh_Atem: I'd go with .5 because it is more stable (lesser change) than 2.28 which will likely go through the same .1, .2, .3 cycle
<zyga-ubuntu> I didn't look at the glib package in a long time
<zyga-ubuntu> are you sure that it will work with << 2.28 snapd?
<Chipaca> pedronis: question for you, about packaging
<jdstrand> mvo: fyi, it will need at least one more syscall for arm64. I have a working test environment now so will send up another pr
<pedronis> Chipaca: about packaging? are you sure it's for me ?
<Chipaca> pedronis: yes :-)
<Chipaca> pedronis: in the 14.04 rules you added a check for a second sha3 sum
<pedronis> I added it in both places
<pedronis> or so IÂ hope
<Chipaca> pedronis: but in 14.04 you didn't bump the check on how many sha3 sums there are in total
<pedronis> oh
<Chipaca> pedronis: would it be safe to assume that they need to be the same :-)
<pedronis> yes
<Chipaca> ok then
<pedronis> I wonder how tests pass though
<pedronis> ah, it's autopkgtest
<pedronis> that use that
<pedronis> we don't have 14.04 autopkgtests
<pedronis> I mean in the travis runs
<jdstrand> mvo: ok, just one: https://github.com/snapcore/snapd/pull/3834
<Chipaca> pedronis: we don't run the package tests in travis
<mup> PR #3834: cmd/snap-seccomp/main_test.go: add one more syscall for arm64 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3834>
<Chipaca> pedronis: we explicitly skip 'em
<mup> PR snapd#3834 opened: cmd/snap-seccomp/main_test.go: add one more syscall for arm64 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3834>
<pedronis> Chipaca: well they use packaging enough to be upset if that is not set right
<pedronis> that's how IÂ re-learned about that
<pedronis> fwiw
<Chipaca> pedronis: i don't follow
<Chipaca> pedronis: it was a different checksum before?
<Chipaca> hash, not checksum, ykwim
<pedronis> Chipaca: all the autopkgtest in travis were failing when -eq was still 1 for 16.04
<Chipaca> pedronis: autopkgtest yes, travis no
<pedronis> ah
 * zyga-ubuntu has 1TB data cap a month now
<pedronis> now understand
<pedronis> sorry
<Chipaca> no prob
<pedronis> IÂ mean the CIÂ tests kicked from github
<pedronis> yes, the autopkgtest don't go through travis
 * Chipaca continues looking at the diff
<Chipaca> pedronis: thank you
<pedronis> but we don't have 14.04 autopktest there
<pedronis> Chipaca: fwiw the 2nd hash is the 'generic' authority models key
<mvo> jdstrand: thanks a bunch
<pedronis> Chipaca: does this mean we want some kind of shared  common.mk file ?
<pedronis> or that we need a 14.04 autopkgtest ?
<Chipaca> pedronis: I think we never got the 14.04 autopkgtest to work, but i'm not sure
<jdstrand> mvo: np
<Chipaca> zyga-ubuntu: how would you best describe snap.mount.service?
<Chipaca> zyga-ubuntu: i'm going with âtrusty needs this to make /snap rsharedâ but let me know if that could be made clearer
<mup> PR snapcraft#1520 opened: tour: remove the tour assets <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1520>
 * zyga-ubuntu reinstalls xenial
<zyga-ubuntu> actually, I should talk to mvo and I need to do a backup anyway
<zyga-ubuntu> mvo: would you like to talk about that base snap branch?
<Chipaca> what's the right way for a postinst to alert the user about something?
<Chipaca> âechoâ is probably not it
<zyga-ubuntu> eh, deja-dup doesn't work on artful
<Chipaca> zyga-ubuntu: neither does curl
<zyga-ubuntu> Chipaca: really?!
<zyga-ubuntu> Chipaca: I'm hand-backing up stuff now
<Chipaca> well, not properly :-)
<Chipaca> zyga-ubuntu: like a caveman!
<Chipaca> zyga-ubuntu: we found that out yesterday digging into some weirdness sergiusens came across
 * zyga-ubuntu is tempted to boot tumbleweed on his laptpo 
<Chipaca> zyga-ubuntu: in the old âcurl -N -0 -s --unix-socket /run/snapd.socket http:/v2/<blah>â you need to add another /v2 for it to work
<Chipaca> O
<Chipaca> I'd imagine /// instead of /v2 would also do the job
<zyga-ubuntu> why another /v2
<Chipaca> zyga-ubuntu: well, we were writing /v2/snap and the server was only getting /snap
<zyga-ubuntu> oood?
<zyga-ubuntu> why
<Chipaca> zyga-ubuntu: because, curl is broken on artful? QED
<zyga-ubuntu> yeah, I'm just trying to figure out what kind of feature would chop /v2
<Chipaca> the docs say nothing about having to add more stuff, and it's documented everywhere as just http:<path> when using a unix socket
<Chipaca> sergiusens: did you file that bug btw?
 * zyga-ubuntu steps out for the backup to continue
<mvo> Chipaca: re altering users in postinst> what do you want to alert about? there is no really good way, you can select debconf (which users may not see) or using a user notification (https://wiki.ubuntu.com/InteractiveUpgradeHooks)
<mvo> Chipaca: eh, I mean notifying users (not altering them ;)
<Chipaca> mvo: there's currently an
<Chipaca> 		echo "Please reboot, logout/login or source /etc/profile to have /snap/bin added to PATH."
<Chipaca> in the 14.04 postinst
<Chipaca> mvo: that sounds like the wrong way to do it, but maybe there's no right way
<mvo> Chipaca: all the way are nasty, I think this is ok(ish)
<mvo> Chipaca: plus snapd is really optimized at server/cloud in 14.04
<mvo> Chipaca: so the kind of user would probably use apt install snapd
<mvo> Chipaca: but thanks for looking into it!
<Chipaca> ok
<zyga-ubuntu> Chipaca: for that I think snap (the command) should do it when running on 14.04 and seeing 3.13 kernel
<Chipaca> zyga-ubuntu: why just there? any time it's not in the path would be good
<zyga-ubuntu> Chipaca: specifically there because snapd doesn't work before
<zyga-ubuntu> Chipaca: not just when it's not on path (that's a separate issue and I don't mind solving it)
<Chipaca> zyga-ubuntu: but it does sound like the kind of cheap check we could do always
<Chipaca> mvo: vvv for your entertainment
<mup> PR snapd#3835 opened: packaging: bring down the delta between 14.04 and 16.04 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3835>
<jdstrand> niemeyer: hey, re https://github.com/snapcore/snapd/pull/3818#issuecomment-326186434, are you saying when I 'Approve changes' I should '+1', or something else?
<mup> PR #3818: interfaces: fix network-manager plug <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3818>
<niemeyer> jdstrand: The opposite.. just saying +1 as a comment in the PR won't track the review as an actual review
<pedronis> jdstrand: you didn't 'Approve Changes' in that one
<niemeyer> jdstrand: If you do the approval, comment, or change request (with any comment) via the formal mechanism, we get a summary at the top right, and it's also tracked in the review board
<jdstrand> ok
<jdstrand> I find it weird how sometimes I see the 'Review Changes' button, but other times I need to go into /files
<jdstrand> anyway, understood
<jdstrand> "always use the formal method if doing a formal review"
<Chipaca> zyga-ubuntu: little reminder about actually +1'ing snapd#3748 if that was your intent
<mup> PR #3748: many: fetch & cache remote snaps and sections; complete from there <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>
<mup> PR snapcraft#1521 opened: python plugin: always record constraints and requirements contents <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1521>
<zyga-ubuntu> Chipaca: ack, will do soon-ish
 * zyga-ubuntu installs xenial
<zyga-ubuntu> this new network is really insanely good
<zyga-ubuntu> I just want to get back to stable OS as well
<zyga-ubuntu> I'm getting 7MB/s to ubuntu.com archive
<zyga-ubuntu> woah
<zyga-ubuntu> 10
<zyga-ubuntu> 10MB/s for larger downloads
<zyga-ubuntu> 11MB/s :D
<nacc> is the core-snap's path for a given snap a snap environemtn variable?
<zyga-ubuntu> nacc: hmmm
<zyga-ubuntu> nacc: can you say that again please?
<zyga-ubuntu> nacc: do you want to find the core snap at runtime?
<nacc> zyga-ubuntu: i'm trying to 'fake' my classic snap being confined (because i wnat to sure it doesn't happen to have dependencies on the system)
<nacc> zyga-ubuntu: that involves not using $PATH, but setting it to some specific values in my snap
<nacc> zyga-ubuntu: however, that then means the core snap is not in $PATH :)
<nacc> e.g., /snap/core/current/bin, /snap/core/current/usr/bin ,etc
<nacc> is /snap/core/current something i can just use? or is it stored in some env variable for portability
<zyga-ubuntu> nacc: how is confinement needed for the classic snap?
<nacc> zyga-ubuntu: it's not, but i want to ensure only my binaries are used
<zyga-ubuntu> nacc: /snap/core/current is reliable
<nacc> zyga-ubuntu: e.g., my version of git, not the system git
<nacc> zyga-ubuntu: and so i need to manipulate PATH in very specific ways
<zyga-ubuntu> ok
<nacc> zyga-ubuntu: ok, i htink i can wrap that up then, for now
<nacc> zyga-ubuntu: thanks!
<zyga-ubuntu> yw!
<zyga-ubuntu> backup's done
 * zyga-ubuntu wonders what else to check
<zyga-ubuntu> making live USB
<jdstrand> roadmr: hi! has the reviewers page url changed? https://dashboard.snapcraft.io/dev/snaps/reviewer/ is giving me 404
<jdstrand> roadmr: earlier today it worked
<jdstrand> roadmr: so, I logged out and back in, then went to 'stores I can access', clicked on Ubuntu and the url is https://dashboard.snapcraft.io/dev/snaps/reviewer/ubuntu/
<cachio> niemeyer, about the images with the dependencies installed
<cachio> when I have them ready, you will take an screenshot?
<jdstrand> roadmr: I wonder if ubuntu/ is the right name since the store is the public snap store, and not specific to ubuntu
<jdstrand> roadmr: that is a different conversation though. should I update docs/etc for the new url?
<cachio> niemeyer, should I create a PR first?
<niemeyer> cachio: I'd prefer to see the spread project updated first, and then we change the images with it
<niemeyer> cachio: So we're actually just persisting what we have already automated
<cachio> ok, i'll create a PR
<jdstrand> niemeyer: is there something wrong with travis? https://travis-ci.org/snapcore/snapd/builds/270480495?utm_source=github_status&utm_medium=notification from https://github.com/snapcore/snapd/pull/3834 doesn't seem to want to start
<mup> PR #3834: cmd/snap-seccomp/main_test.go: add one more syscall for arm64 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3834>
<jdstrand> I already tried a cancel/restart once
<niemeyer> jdstrand: Supposed to be fine: https://www.traviscistatus.com/
<niemeyer> jdstrand: That works against you, actually..
<niemeyer> jdstrand: Puts you back at the end of the queue
<niemeyer> jdstrand: We have a limit of 3 concurrent jobs
<jdstrand> niemeyer: I thought it might but I rolled the dice since it had been more than hour (maybe closer to two)
<jdstrand> ok
 * jdstrand stops watching the pot waiting for it to boil
<jdstrand> niemeyer: thanks
<niemeyer> jdstrand: You can see it here:
<niemeyer> jdstrand: https://travis-ci.org/snapcore/snapd/pull_requests
<niemeyer> jdstrand: and here: https://travis-ci.org/snapcore/snapcraft/pull_requests
<niemeyer> jdstrand: We have quite a few PRs waiting indeed.. two of them running
<niemeyer> jdstrand: You seem to be next in line on snapd.
<niemeyer> (assuming you don't restart! ;)
<mup> PR snapd#3833 closed: interfaces/opengl: use == to compare, not = <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3833>
 * zyga-ubuntu reinstalled xenial
<zyga-ubuntu> everything works again :)
<zyga-ubuntu> time to sleep though
<mup> PR snapcraft#1522 opened: catkin plugin: only append PYTHONPATH if set <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1522>
<roadmr> jdstrand: hi! hm - there may have been some changes to how stores are accessed, let me check
<nessita> jdstrand, hi!
<nessita> jdstrand, could you please visit https://dashboard.snapcraft.io/dev/store/list/
<nessita> and follow the links for review there?
<nessita> jdstrand, we are working on removing the need to "be in a given store" to perform actions related to stores, so we are replacing generic URLs with URLs that have the store-id in it
<roadmr> hi nessita hehe
<cachio> niemeyer, https://github.com/snapcore/spread-images/pull/9
<mup> PR spread-images#9: Install dependencies on the images <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/9>
<cachio> niemeyer, I run it and I see this error for debian and opensuse: cannot send project content: remote directory /root/spread is not empty
<cachio> the base images are not clean
<cachio> niemeyer, I am going to bed now, I am feeling really bad
<niemeyer> cachio: Sure thing, have a good rest there and hop you get better soon
<jdstrand> nessita: I did that (hence me comment regarding ubuntu/)
<jdstrand> I'll update my bookmark and docs
<jdstrand> my*
<nessita> jdstrand, I'm adding a redirect helper as well, for the deprecated URLs
<nessita> jdstrand, sorry for not having that redirect in place before
<nessita> jdstrand, regarding the name "ubuntu", that's the store id, and if we want to change it, we have to plan for it (is also the DB id). Regarding docs, please don't put the explicit URL in it, just say "in the dropdown under your name, at the top right corner, click on "stores you can access" and follow the reviewer link"
<nessita> jdstrand, because URLs will change again
<mup> PR snapcraft#1523 opened: python node: record installed node packages in manifest <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1523>
<jdstrand> nessita: ok, thanks
<pedronis> niemeyer: nessita: snapd itself doesn't use/send that store id directly, it's a legitimate question whether we want to change it now that is more prominent
<nessita> pedronis, I agree
<niemeyer> pedronis: You mean the one from the model?
<pedronis> niemeyer: is not used in the model
<pedronis> IÂ mean it's the implicit default
<pedronis> I don't think people have put it directly into models
<pedronis> for sure we don't
<niemeyer> pedronis: That would be incorrect then?
<pedronis> niemeyer: ?
<niemeyer> Sorry, I mean
<niemeyer> If the store side is assuming "ubuntu" to be a default, it doesn't seem right
<pedronis> yes, the store side is doing that, because the main/default store atm  has id ubuntu
<pedronis> in the store side
<pedronis> snapd simply doesn't send anything to get the default
<niemeyer> Yeah, that seems fine.. the default is just the default
<niemeyer> The store just shouldn't assume that.. sounds like a simple string change
<pedronis> I'll let nessita comment on the simple, but we need a new more neutral name/id then
<nessita> niemeyer, is not simple because is also the DB table ID (historic reasons)
<nessita> doable, for sure
<nessita> niemeyer, pedronis it may hardcoded in some other places, it needs some planning and checking, but doable for sure
<nessita> will add an item to our rally agenda
<niemeyer> nessita: Ack, not a big deal either as long as this isn't showing anywhere
<nessita> pedronis, niemeyer what would be the ideal store id for the main/default store?
<pedronis> niemeyer: did you see this comment by jdstrand on the reuse snap-update-ns PR:  https://github.com/snapcore/snapd/pull/3621#discussion_r136437075
<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>
<niemeyer> pedronis: Not yet, and I need to run out just now to pick kid up in school
<niemeyer> Back in a bit
<pedronis> nessita: main would be the obvious one, sounds  a Gustavo's question though
 * pedronis -> rest
<mup> PR snapd#3834 closed: cmd/snap-seccomp/main_test.go: add one more syscall for arm64 <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3834>
#snappy 2017-09-01
<mup> PR snapcraft#1524 opened: Yarn lock record <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1524>
<zyga-ubuntu> good morning
<zyga-ubuntu> mvo: my network is better than ever, I've reinstalled xenial
<zyga-ubuntu> mvo: if you want to have that call I'm available and eager to test
<mvo> zyga-ubuntu: hey, good morning - please check the latest bits I wrote in 3625, I'm available in some minutes (just want to finish two small review feedback tasks)
<zyga-ubuntu> mvo: great, I'll read your feedback and grab a coffee, let's chat soon
<zyga-ubuntu> mwhudson: hello, I made git happy, shall I dput or do you want to do that yourself?
<zyga-ubuntu> mvo: let me take your branch and look at some possiblity to make it more uniform, I won't push to your PR but will have something as a base for discussion, ok?
 * zyga-ubuntu is still sleepy, needs to transition to waking up at 6AM
<mvo> zyga-ubuntu: sure
<greyback> ogra_: hey, I'm having trouble bringing up Mir on the edge/daily RPi3 image (and I tried your images too, no diff). I'm suspect https://pastebin.ubuntu.com/25443549/ Is this a known issue?
<mvo> pedronis: this might be interessting for you: httputil/logger.go:108: assignment copies lock value to transport: net/http.Transport contains sync.Mutex (from go vet 1.7)
<pedronis> mvo: that is annoying,  the rule is  A Mutex must not be copied after first use, I think the current code isn't quite right, even reasonably code will not make vet happy there :/
<pedronis> though
<pedronis> mvo: more correct code would be like this:  https://pastebin.canonical.com/197306/   don't think it make vet happier though
<mvo> pedronis: yeah, I think there is a open bug about that vet is not smart about this :/
<mvo> pedronis: the alternative of creating a transport with the same values as default trnasport is very much not DRY, so maybe best to ignore/silence this vet message
<pedronis> that's what I had the problem is that the exact params change between 1.6, 1.7, 1.8
<pedronis> so params are new in each
<pedronis> so we would need multiple versions of that code
<pedronis> mvo:  I don't think there's  a way to supress single warnings
<pedronis> unless we do it from the outside?
<pedronis> mvo: what's your thinking?
<mvo> pedronis: yeah, I was thinking to grep -v on the outside
<mvo> zyga-ubuntu: ready when you are, sorry that things took a bit longer
<pedronis> mvo: this is how they look in the versions btw:   http://pastebin.ubuntu.com/25443642/
<mvo> pedronis: meh, really annoying
<pedronis> mvo: we can probably get away with 2 version  1.6  and 1.7+ at least for a bit
<ogra_> greyback, that output looks normal to me (these bind errors have always been there IIRC)
<greyback> ogra_: ok. I'll try to figure out why Mir is sad then.
<ogra_> i guess /dev/dri/card0 exists ?
<greyback> ogra_: yep
<ogra_> then he device should technically be initialized properly ...
<ogra_> there was a change regarding famebuffer handling in the kernel though
<greyback> ogra_: is it a custom kernel?
<ogra_> it is based on our 4.4 tree i think with broadcom patches on top ... you have to ask ppisati for more details ... mir worked fine in the past though ...
<ogra_> the framebuffer thing is https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1708417
<mup> Bug #1708417: Board hangs with 'dtoverlay=vc4-kms-v3d' while writing to /dev/fb0 <patch> <verification-done-xenial> <linux-raspi2 (Ubuntu):New> <linux-raspi2 (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1708417>
<ogra_> (the patch is attached there)
<ogra_> not sure if that can have any impact on mir
<ogra_> greyback, also ... remembering the forum...did you try a reboot ? :)
<greyback> ogra_: yep :)
<greyback> ok, well I know where to start, thanks
<ogra_> greyback, FYI i just installed mir-libs and mir-kiosk from edge and have a mouse cursor now on a pi2
<greyback> ogra_: ack, thanks for that. I didn't think pi3 was that different...
<ogra_> the kernel and rootfs are identical ... the bootloader setup differs slightly
<ogra_> (bootloader binaries should also be identical nowadays, it is really only config diffs in the gadget)
<pedronis> mvo: I'll propose something using the 2 versions
<mvo> pedronis: thanks a lot, i have a look
<ogra_> pedronis, hmm, could your recent changes to serial handling have introduced a race ? i just had the second installl in a week where installing my first snap on a device ended up in installing core first ... (which indicates that firstboot or key setup failed)
<pedronis> ogra_: that sounds more like a firstboot issue
<ogra_> k
<pedronis> serial doesn't play a role there
<pedronis> IÂ mean you have no core
<ogra_> sadly the card is already messed up and i'm re-flashing
<pedronis> serial starts after seeeding
<ogra_> but i guess that will happen again
<pedronis> I'm sure there's an issue, don't think it's related to serial
<ogra_> well, the images were pretty reliable until recently so it is definitely a recent change, serial just came to my mind as first thing here :)
<pedronis> those changes should not have modified behavior on core
<pedronis> also as I said they trigger after seed is set
<pedronis> we need a log
<ogra_> ogra@localhost:~$ snap changes
<ogra_> error: no changes found
<ogra_> ogra@localhost:~$ snap list
<ogra_> No snaps are installed yet. Try "snap install hello-world".
<ogra_> ogra@localhost:~$
<ogra_> ok ... seems reliably broken
<pedronis> that seems very broken
<pedronis> there not even a try to seed
<ogra_> pedronis, http://paste.ubuntu.com/25443792/ looks relevant
<ogra_> pedronis, note that i have only seen it on wlan-only boards ... which come up without any networking (because WPA isnt set up indeed)
<pedronis> you r image as a strange time:   2016/02/11 16:28:15.328983
<ogra_> hmm, true
<pedronis> that's the problem
<ogra_> damn
<cjwatson> upgrading launchpad-buildd to 148; please let me know if you see new oddities with snap building on LP
<cjwatson> (yes, I'll announce it on the forum once it's done)
<ogra_> pedronis, thanks, i know wheer to look then
<pedronis> yea, something with the rtc fixing code or the filesystem times
<ogra_> right and i just merged abeato's initrd changes at the start of the week
<ogra_> i guess something broke there
 * zyga-ubuntu has fun with system
<zyga-ubuntu> "fun"
<ogra_> argh ... no, even worse ...
<ogra_> xenail had a new initramfs-tools superseding ours in the PPA
<abeato> ogra_, pedronis, that seems like systemd built date when date is seen by it as older than that
<abeato> (systemd changes the date in that case)
<ogra_> abeato, yeah, sorry, not your fault ...
<abeato> not yet probably ;)
<ogra_> theer were other initrd fixes that the upload to xenial-proposed did override
<ogra_> in initramfs-tools itself
<Chipaca> hmm
<Chipaca> pedronis, mvo, why is it called âsnap-repair.serviceâ and not âsnapd-repair.serviceâ?
<ogra_> because it repairs snaps ?
<ogra_> or does it repair snapd ?
<Chipaca> snap- is what we use for units associated with a snap
<mup> PR snapd#3836 opened: httputil: more naive per go version way to recreate a default transport for tls reconfig <Created by pedronis> <https://github.com/snapcore/snapd/pull/3836>
<Chipaca> snapd. is what we're using for units associated with snapd itself
<Chipaca> so it should probably snapd.repair.service
<pedronis> Chipaca: I don't know, that's a mvo question
<pedronis> mvo: #3836
<mup> PR #3836: httputil: more naive per go version way to recreate a default transport for tls reconfig <Created by pedronis> <https://github.com/snapcore/snapd/pull/3836>
<mvo> Chipaca: the tool is called snap-repair, we could rename it I guess
<pedronis> but all our tools are snap-
<ogra_> ppisati, we have a problem ... fixrtc in the generic initrd is broken, i need to re-upload the fix and re-spin core and then we would need a no-change rebuild of the kernel snaps (for all devices without rtc battery at least)
<pedronis> Chipaca, mvo:  we risk a clash there right?
<Chipaca> mvo: tbh it's probably not a huge deal, we already have snap.mount.service which breaks the pattern
<pedronis> ah, no, because revision
<Chipaca> mvo: and for this, snap.mount.service needs special treatment -- so i need to do the same for the other i think? maybe
<mvo> Chipaca: yeah, its slightly inconsistent but we can fix it still, so maybe we should and rename it if its the only one that sticks out
<ppisati> ogra_: ok
<ogra_> missing this fix http://paste.ubuntu.com/23175211/
<ogra_> (i really need to SRU this so such issues cant happen anymore :/ )
<mvo> Chipaca: I guess we go all the way and rename snap-repair to snapd-repair as well?
<ppisati> ogra_: i've been testing 4.13 with ubuntu core, and the serial console is completely trashed
<ogra_> ppisati, on what devices ?
<ppisati> ogra_: the funny thing is that, the same exact kernel works fine in ubuntu classic
<ppisati> ogra_: raspi3
<ogra_> ppisati, differences in config.txt ?
<ppisati> ogra_: on raspi2, the boot doesn't complete, it hangs during usb bus init, again perfectly fine in ubuntu classic
<ogra_> (and did you copy the dtbs over to the gadget path ?)
<ppisati> ogra_: uhm, none i think
<pedronis> mvo: IÂ don't like snapd-repair a lot for the tool, given our snap- pattern there
<ppisati> ogra_: i would i do that? (copy the dtb to the gadget path)
<ppisati> *how
<mvo> pedronis, Chipaca: hm, hm, snapd-repair.service but snap-repair as the tool sounds also inconsistent to me. so maybe keep as is (snap-repair.service and snap-repair tool)?
<ogra_> ppisati, well, from the kernel snap /lib/firmware/.../device-tree to /boot/uboot/ (and to the overlays subdir)
<Chipaca> mvo: snapd.snap-repair.service ?
<ogra_> ppisati, else you will indeed boot with a 4.4 dtb
<ogra_> (the old issue on the pi)
<ppisati> ogra_: i thought ubuntu image would pick the dtb from the kernel snap nowadays
<ogra_> not on the pi3
<ppisati> that might explain why i only have problems with ubuntu core
<pedronis> mvo: should IÂ mark my go vet fix for 2.28 ?
<mvo> pedronis: please
<mvo> Chipaca: that sounds ok
<ogra_> the pi bootloader needs the dtb in the toplevel of the vfat and we cant really load it from uboot anymore
<ogra_> thats why it is still shipped in the gadget unlike on all other boards
<pedronis> Chipaca: quick (maybe) review to please the go vet gods: #3836
<mup> PR #3836: httputil: more naive per go version way to recreate a default transport for tls reconfig <Created by pedronis> <https://github.com/snapcore/snapd/pull/3836>
<ppisati> ogra_: me checks that
<ogra_> hmm, i dont get it ... how did the breakage make it into the current pi2-kernel snap ... the deb only landed yesterday, the broken initrd.img only showed up in todays build of the core snap ... but the kernel snap was built 3 days ago
<xnox> Hello, i have a python3 build-dependency which is not on pypi =( it's only a package in ubuntu. I've added "build-packages" stanza, but it seems to me that it is failing to import none-the-less.
<xnox> https://launchpadlibrarian.net/335415335/buildlog_snap_ubuntu_xenial_amd64_xnox-subiquity_BUILDING.txt.gz
<xnox> Setting up python3-distutils-extra (2.39-1) ...
<ogra_> are you using the python3 plugin for it ?
<xnox> ImportError: No module named 'DistUtilsExtra'
<xnox> ogra_, oh, i have "plugin: python" should it be "python3" ?
<ogra_> it think "python" has a version property
<xnox> everything is calling python3 as far as I can see
<xnox> let me check the docs
<Chipaca> i think it was python3 earlier, but it's been renamed
<xnox> - python-version:
<xnox>   (string; default: python3)
<xnox> The python version to use. Valid options are: python2 and python3
<xnox> so yes i am using python3
<Chipaca> xnox: I don't know snapcraft well at all, but if it's python i assume the problem is that it's not being included in the snap? as there is no build phase?
<Chipaca> or no compile in the build at least
<Chipaca> xnox: so maybe it should be a stage-package, not a build-package?
<ogra_> yeah
<xnox> Chipaca, no i don't need to stage distutils-extra at all. distutils-extra are helper functions to use in setup.py which build extra things (translations in my case) and is only needed during building
<Chipaca> ah alright
<ogra_> xnox, if you use snapcraft cleanbuild locally, does it work ?
<xnox> Chipaca, my problem is that system installed python modules (from build-packages, normal ubuntu package) are not available inside the pyenv / during the pip call
<Chipaca> xnox: if you wait a little bit, sergiusens would be around
<Chipaca> should, could
<Chipaca> xnox: distutils-extra was a problem until recently at least, as per https://forum.snapcraft.io/t/week-31-of-2017-in-snapcraft/1598/3
<Chipaca> xnox: maybe kalikiana found how to work with it?
<mvo> Chipaca: do you want me to look at the rename of snapd.snap-repair.service after lunch? or are you at it already?
<Chipaca> mvo: I'm not on it, but I can glom it into this huge packaging pr
<Chipaca> mvo: unless it's time-sensitive?
<mvo> Chipaca: we should probably do it before 2.28 just to avoid that it hit -updates
<mvo> Chipaca: I have a look after lunch
<Chipaca> ok
<Chipaca> mvo: changing subjects, do you remember where it was that you had an io.Reader and you needed to write it atomically?
 * Chipaca is thinking about that while waiting for spread
<mvo> Chipaca: I don't remember where this was, sorry.
<Chipaca> no probs
<xnox> is there a way for me to see the contents of the just built snap somehow?
<Chipaca> xnox: unsquashfs -ls
<xnox> snap info --show-me-contents-like-dpkg-deb-c subiquity_0+git.3c5c5a5-dirty_amd64.snap
<xnox> hm, ok.
<Chipaca> xnox: or --lls
<ogra_> xnox, did you use cleanbuild or did you build natively ?
<Chipaca> xnox: if you're in snapcraft, I think the 'prime' directory is the contents of the snap
<ogra_> the prime dir should have the conten in the latter case
<ogra_> *content
<Chipaca> xnox: (and you don't need the snap to try the snap -- 'snap try' can run it, uncompressed, from the prime dir)
<xnox> ogra_, i do not understand what you mean; and it sounds too many too similar terms
<xnox> i did snapcraft
<xnox> so i don't like how things look
<Chipaca> xnox: snapcraft on its own does build, not cleanbuild -- cleanbuild builds it in a vm
<ogra_> xnox, "snapcraft cleanbuild" is the command you should use to get a build similar to what lp does (in-container, properly using xenial repos)
<ogra_> xnox, while just calling "snapcraft" will just use your host for all build deps etc
<xnox> right..... but why is it a separate command instead of e.g. "build --vm"?
<xnox> becuase there is "clean" and "build" subcommands, i assumed "cleanbuild" subcommand does the previous two in order, just an alias/shortcut
<ogra_> (so running "snapcraft on artful will never get you what lp builds)
<xnox> not like a brand new behariouv.
<xnox> ..
<xnox> anyway
<xnox> ..
<ogra_> clean and build are steps ...
<ogra_> clanbuild is a special type of building
<ogra_> *cleanbuild
<xnox> my python modules are installed into /lib/python3.5 instead of /usr/lib/python3.5 i find that confusing
<xnox> it's as if --prefix=/usr was not passed to setup.py
<xnox> is this normal?
<xnox> especially when binaries are in /usr/bin/
 * ogra_ honestly doesnt know ... i usually stay away from pythjon snaps :P ... and i guess you might have better chances to find the snapcrafters in rocketschat 
<ogra_> i'm sure they have a ton of examples you could look at
<Chipaca> my only python snap predates snapcraft Â¯\_(ã)_/Â¯
<ogra_> heh
<Chipaca> (and I think the way it does things is frowned upon :-) )
<Chipaca> it does result in a 1MB snap though :-D
<Chipaca> arch: all, to boot
<Chipaca> or was it any
 * Chipaca forgets
 * Chipaca goes back to work
<ogra_> greyback, did you use your pi on a wired network when first booting it ? seems there was actually a bug in the image where the clock is wrong on first boot and thus the snaps are not properly initialized (results in ""core" bein installed if you install the first snap)
<ogra_> greyback, if your system behaved like this that might cause issues with mir too
<ogra_> (actually with any snaps)
<davidcalle> pstolowski: ping
<pstolowski> davidcalle, hey!
<davidcalle> pstolowski: hey, I'm working on examples for the hooks doc page, and I'm wondering if you have any
<greyback> ogra_: hmm, not in my first tests (those were wifi only), but subsequent tests were on wired, and yes I did see an oddity with core snap update leaving things in a weird state (snapd at 100% cpu too). A reboot seemed to fix it
<ogra_> that just looks like it fixed it :)
<davidcalle> pstolowski: install hook
<ogra_> greyback, there are images with rolled back kernel snap in my people.u.c page now ... just re-flash
<mvo> pedronis: build failure in your latest Transport branch in debian-unstable and fedora that it cannot find Transport, I guess those already have go > 1.7 maybe?
<greyback> ogra_: ack, will test. I didn't bring my Pi3 into my office today, so will try tonight/over weekend
<ogra_> ah, ok
<pstolowski> davidcalle, not really. install and refresh are very new hooks. but i'm happy to answer any questions.
<mvo> niemeyer (and anyone else interessed): i updated 3556 (the license branch) with a slightly different validator, please let me know
 * mvo would love to see this merged
<greyback> ogra_: sorry
<pstolowski> davidcalle, nb, install hook is run only on fresh install of a snap
<ogra_> greyback, heh, what for ... thanks for making me look and finding the bug
<greyback> ogra_: well immediate feedback is nice :)
<ogra_> :)
<davidcalle> pstolowski: ok, so if I create a snap with an "install" hook, a simple sh executable that echoes a string. Here is what happens on snap install "error: cannot perform the following tasks:
<davidcalle> - Run install hook of "playground" snap if present (run hook "install": cannot snap-exec: cannot find hook "install" in "playground")"
<davidcalle> pstolowski: and I can't really make sense of the error message.
<pstolowski> davidcalle, is 'install' actually present in meta/hooks/ ? exec bit set?
<ogra_> ppisati, initramfs tools fix is in the PPA ... can you re-build the pi2-kernel and dragonboard kernel  snaps ?
<ppisati> ogra_: me kicks a build
<ogra_> thx
<davidcalle> pstolowski: it doesn't install the snap at all. But it's in my "prime" dir, in meta/hooks with the exec bit set.
<ogra_> ppisati, did the copying of the dtbs help btw ?
<zyga-ubuntu> mvo: is LIBEXECDIR set there for a particular reason? https://github.com/snapcore/snapd/pull/3625#discussion_r136512808
<mup> PR #3625: many: end-to-end support for the bare base snap <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/3625>
<davidcalle> pstolowski: and if I remove the install file, it installs just fine and the configure hook it ships works
<ogra_> zyga-ubuntu, why did you mark #3807 blocked ? the fix is in my comment
<mup> PR #3807: cmd/snap-confine,packaging: import snapd-generated policy <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/3807>
<pstolowski> davidcalle, are you running current stable release?
<zyga-ubuntu> ogra_: it's blocked for now, I want to try to make that change but would rather not do it for 2.28 (too soon, too uncertain)
<pstolowski> (of snapd)
<zyga-ubuntu> ogra_: after 2.28 we can do that and see what happens
<zyga-ubuntu> ogra_: it's blocked in the terms that it cannot land yet
<ogra_> zyga-ubuntu, the fix has to happen in the core snap, not in snapd
<ogra_> zyga-ubuntu, and it is trivial ... (identical to https://github.com/snapcore/core-build/pull/17 ... i can add your path in the PR if you want)
<mup> PR core-build#17: switch /etc/systemd/system to "synced" mode <Created by ogra1> <https://github.com/snapcore/core-build/pull/17>
<zyga-ubuntu> ogra_: right, I know,
<davidcalle> pstolowski: 2.27.5+17.10
<zyga-ubuntu> ogra_: hmm, that's tempting
<zyga-ubuntu> ogra_: when do you plan to land that change?
<zyga-ubuntu> ogra_: have you tested it?
<pstolowski> davidcalle, good. can you push or email your snap somewhere so I can give it a shot?
<ogra_> zyga-ubuntu, we use synced in other dirs (and switched them on the fly) so i dont expect any particular breakage ...
<zyga-ubuntu> ogra_: in that case, when do you plan to land your PR?
<zyga-ubuntu> ogra_: don't get me wrong, I'd love to try
<ogra_> as soon as it gets appoved :)
<zyga-ubuntu> ogra_: did you test upgrades from older layout
<ogra_> no, thats hat edge is for ... i'd land it and test in edge
<ogra_> perhaps not today though ... i dont want to have to roll back on the weekend :)
<ogra_> zyga-ubuntu, how about we land it on monday
<ogra_> manually upgrading core doesnt really reflect the behaviour so i'd prefer to use the store here
<cjwatson> We're rolling back launchpad-buildd 148 due to some unexpected networking issues with LXD
<pedronis> mvo: sorry, will fix, build flags are annoying this way
<zyga-ubuntu> re, mailman
<zyga-ubuntu> ogra_: on monday after mvo branches off 2.28 is fine
<ogra_> cool
<ogra_> i'll ping you about it then
<zyga-ubuntu> ogra_: I mainly worry about the build logic where it would be good to be able to do 2.28.1 without this change
<zyga-ubuntu> ogra_: thank you!
<mvo> pedronis: yeah, no worries, just wanted to let you know
<mup> PR snapd#3837 opened: overlord/snapstate: remove superfluous/misleading check from All <Created by pedronis> <https://github.com/snapcore/snapd/pull/3837>
<pedronis> tiny cleanup there with open question
<mvo> ta
<davidcalle> pstolowski: sorry, I was in a meeting, yes, sending you something, thanks!
<abeato> lool, hey, is there a repo for flash-device or I need a debdiff to submit a patch?
<lool> abeato: I dont think there's an Ubuntu repo; the Debian repo is under d-i project at git.d.o
<abeato> lool, ok, should I then submit the change to debian directly?
<lool> abeato: we typically land Ubuntu changes directly in Ubuntu and then send a patch to Debian if applicable there
<abeato> lool, alright, will do that
<lool> abeato: what's your change :)
<lool> abeato: seeing version in Ubuntu is ubuntu65, it has not been rebased in a reallllly long time
<ogra_> pfft ... whats 64 revisions :P
<lool> ogra_: 65!
<ogra_> we always have ubuntu1 :)
<lool> with a delta already!
<abeato> lool, adding one device to the database : http://paste.ubuntu.com/25444576/
<ogra_> well, only the maintainer address :)
<jdstrand> mvo: hi! I'm seeing this inside an lxd container (ie, my dev environment is in an lxdcontainer): http://paste.ubuntu.com/25444561/
<lool> abeato: is it an officially supported flavor in Ubuntu?
<zyga-ubuntu> jdstrand: hey
<jdstrand> hey zyga-ubuntu :)
<lool> abeato: in which case, I suggest you add a Kernel-Flavor header as well
<jdstrand> mvo: wondering if there is anything there that might ring a bell
<abeato> lool, well, it is for a commercial device
<lool> abeato: if there's no kernel in Debian supporting the hardware, I suggest you only upload it to Ubuntu
<mvo> jdstrand: not right now, I can check inside lxd
<mvo> jdstrand: to see if I see the same
<abeato> lool, I guess not supported by debian, right
<lool> abeato: Kernel-Flavor is basically an extra check to make sure the right kernel unames are allowed and you don't accidentally write a -generic kernel to your flash that wont boot
<lool> so it's a nice safety net if that works for your hardware
<jdstrand> zyga-ubuntu: fyi, re snap-update-ns, I've got an exploratory PR that shuffles some stuff around to address much of the import issues I mentioned in snap-update-ns
<zyga-ubuntu> jdstrand: thank you, do you want to talk about it?
<zyga-ubuntu> jdstrand: I also added an idea to the PR, to use a remote API to talk to snapd to call update-ns
<jdstrand> zyga-ubuntu: yes, but not right this second. let me finish the tests and send it up
<zyga-ubuntu> jdstrand: ok
<zyga-ubuntu> jdstrand: thanks, I'll be here, my network works now
<pedronis> mvo: pushed the rename there
<jdstrand> zyga-ubuntu: oh, that is an interesting idea too
<lool> abeato: I guess it's a for a xenial based install? BTW since this is not snappy specific, we should probably be discussing this somewhere else
<jdstrand> it would add ipc to exec...
<zyga-ubuntu> jdstrand: it _might_ be even IPC-less but in a very convoluted way
<zyga-ubuntu> jdstrand: but yes, IPC is the way to go
<jdstrand> anyway, let me finish this and send it up
<zyga-ubuntu> jdstrand: ok
<mvo> pedronis: ta
<jdstrand> mvo: thanks!
<cachio> mvo, I updated the pc-kernel snap in staging using the one in prod but seems to bring many issues
<cachio> mvo, I see many of this ones https://paste.ubuntu.com/25444618/
<cachio> I need to update the kernel because the lxd test needs a new kernel to work
<cachio> mvo, any Idea?
<mvo> cachio: hm, device session errorin https://paste.ubuntu.com/25444618/ that might be something for pedronis
<zyga-ubuntu> cachio: whick kernel are you on?
<cachio> zyga-ubuntu, 4.4.0-83
<pedronis> cachio: that's look like a prod snapd trying to talk to staging
<pedronis> cachio: d-Jc... is a prod key
<cachio> pedronis, yes
<zyga-ubuntu> cachio: it's definitely not too old IMO
<pedronis> that doesn't work
<cachio> pedronis, so I should build the snap spacially for staging?
<pedronis> cachio: yes, I think as IÂ said that already, and you need to set the env vars
<pedronis> you need both
<cachio> pedronis, the env vars are already set
<cachio> and the tests working but I need to update the pc-kernel snap to make the lxd test pass in stagnig
<pedronis> well something is not using a snapd for staging or the env var are not set
<pedronis> that key there is a prod key
<pedronis> that's why staging says what
<pedronis> or it might be that we don't switch to staging early
<pedronis> enough
<pedronis> that's a new potential problem
<pedronis> with master
<cachio> I ran the cron-job that already was passing for all the tests but now with the new pc-kernel that I got from prod
<pedronis> the kernel alone shouldn't make a difference
<cachio> pedronis, that cron-job was working against staging
<cachio> pedronis, I though the same, that's why I updated that
<pedronis> something else has changed
<cachio> but after I updated it a lot of these errors appeared
<pedronis> how did you update it?
<pedronis> update it in the store?
<cachio> I downloadede manually from prod and uploaded to the staging store
<pedronis> ok, something else is going on here
<mup> PR snapd#3838 opened: systemd: rename snap-repair.{service,timer} to snapd.snap-repair.{service,timer} <Created by mvo5> <https://github.com/snapcore/snapd/pull/3838>
<cachio> niemeyer, I'll be few minutes late
<zyga-ubuntu> pedronis: standup?
<niemeyer> pedronis: pingous
<jdstrand> mvo: fyi, if I comment out that test, it gets a lot farther, but fails with: http://paste.ubuntu.com/25444693/
<jdstrand> mvo: SNAP_EXEC is "0" instead of ""
<jdstrand> SNAP_REEXEC*
<jdstrand> oh frak
<jdstrand> I have SNAP_REXEC=0 in /etc/environment. why in the world is that there?
<jdstrand> ok, that does not affect cmd_test.go
<jdstrand> meh, yes it does
<jdstrand> mvo: ok, please disregard. hopefully I didn't waste your time. I had SNAP_REEXEC=0 in /etc/environment. remove that, log out and back in and it is fine. that said, perhaps the testsuite shouldn't be affected by that...
<ogra_> probably because you added it when testing a snapd deb change
<jdstrand> I don't run snapd in the container. I must have fat fingered something and accidentally added it there
<zyga-ubuntu> jdstrand: I think each one of us ran into this since we introduced this feature
<jdstrand> zyga-ubuntu: hehe
 * jdstrand adds to ~/.bashrc:
<jdstrand> if [ -n "$SNAP_REEXEC" ]; then
<jdstrand>     echo "WARNING: SNAP_REEXEC is set to '$SNAP_REEXEC'. This may affect the snapd testsuite"
<jdstrand> fi
<ogra_> heh
<jdstrand> I hate bothering people when the issue was my fault. this will *not* happen again :P
<mvo> jdstrand: yay, thank you. but good point
<zyga-ubuntu> oh, that's nice
<zyga-ubuntu> jdstrand: stolen!
<zyga-ubuntu> jdstrand: it should be a part on snapd thing in /etc/profile ;)
<zyga-ubuntu> just couple that wiht $LOGNAME switch
<jdstrand> heh
<ogra_> pfft ... push it to upstream into /etc/skel ...
<zyga-ubuntu> jdstrand: it should also sleep and play yankie-doodle
<jdstrand> hehe
<ogra_> nah, we live in modern times ... it should send you a tweet that plays yankee-doodle
 * ogra_ would really like to know why travis doesnt work anymore in core-build
<ogra_> "Automatic restarts limited: Please try restarting this job later or contact support@travis-ci.com."
<ogra_> not really helpful when there is no further output
<zyga-ubuntu> ogra_: throw more monies at the screen
<zyga-ubuntu> ogra_: offtopic, I got the pi drive for my hate of SD cards outgrew the discounted price of the smaller drive, did you play with it?
<ogra_> doesnt stick ... i tried
<ogra_> zyga-ubuntu, pi-drive ? never heard of it
<zyga-ubuntu> ogra_: wd labs pidrive
<zyga-ubuntu> ogra_: I got the one with 314GB
<ogra_> the one thats shipped with the nextcloud box ?
<zyga-ubuntu> ogra_: I bet
<zyga-ubuntu> ogra_: I just got it now because they shut the progrma down
<zyga-ubuntu> *program
<ogra_> (i have a nextcloud box here but never even unpacked it)
<zyga-ubuntu> and the drives are cheap
<zyga-ubuntu> aha
<ogra_> well, you would still need the SD to booot
<zyga-ubuntu> it includes a berry boot SD card
<ogra_> so boot, and run through console-conf to hve the Sd completely set up ...
<zyga-ubuntu> but it's also optional once you put the right stuff into your fuses, I hear
<ogra_> then dd the second partition to the USB disk and remove the label from the SD second partition
<ogra_> that should be all
<ogra_> after reboot you should be in core booted from /writable on the USB disk
<ogra_> (and writable should have been properly resized to the full disk size)
<ogra_> (you might need to manually create an msdos partition table on the USB disk first though)
<ogra_> zyga-ubuntu, blowing the fuse and usb-booting should work in edge ... but in stable (as usual) the kernel and gadget are to old
 * ogra_ needs to go afk for some errands ... back soon
<zyga-ubuntu> ogra_: thanks
<ahasenack> hi guys, quick question. When reverting to a previous revision of a classic snap, why do I need to pass --classic again?
<zyga-ubuntu> ahasenack: because snaps can confinement flip/flop across revisions and I think we are very paranoid about being explicit for that one
<ahasenack> the revert command works without --classic, but the snap then doesn't, and it can be baffling at first, because snap refresh (forced upgrade) doesn't need --classic
<ahasenack> zyga-ubuntu: but the previous one is already installed: you know if it was a classic one or not
<zyga-ubuntu> ahasenack: yes, but you may have installed it with --jailmode
<ahasenack> which you would know too
<zyga-ubuntu> ahasenack: I think it's just "because", I think Chipaca has deeper insight
 * zyga-ubuntu checks familiy before jumping into another call
<ahasenack> do you guys know if a reverted snap will be automatically upgraded?
<ahasenack> in other words, if the current stable snap is broken, and I have reverted to the previous one which is fine, will I have to keep doing that all day long?
<Chipaca> ahasenack: the revision that you revert away from is blacklisted locally
<ahasenack> nice
<ahasenack> thx
<Chipaca> ahasenack: that's the main difference between revert and refresh --revision=<something you have locally>
<Chipaca> ahasenack: bah. Two main differences: the blacklisting, and revert using the old data whereas refresh copies new data in place
<ahasenack> I used revert --revision
<Chipaca> and nice red uniforms
<Chipaca> ahasenack: that's fine (although should be unnecessary)
<mup> PR snapd#3836 closed: httputil: more naive per go version way to recreate a default transport for tls reconfig <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3836>
<mup> PR snapd#3839 opened: docs: use abolute path in PULL_REQUEST_TEMPLATE.md <Created by mvo5> <https://github.com/snapcore/snapd/pull/3839>
<mup> PR snapd#3840 opened: Snap update ns intial refactor for setuid [EXPLORATORY, DO NOT COMMIT] <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3840>
<Chipaca> ahasenack: about requiring --classic, we had good reasons for doing it at the time, which revolved around what the user would expect as things evolved, but I think we could probably revisit that sometime (as we recently revisited devmode)
<ahasenack> Chipaca: it was unexpected to me: http://pastebin.ubuntu.com/25444749/
<ahasenack> Chipaca: *specially* because after the revert, snap list shows the snap as classic still
<ahasenack> so for a while I was thinking the problem was something else
<Chipaca> wait
<ahasenack> until dmesg confirmed the apparmor DENIED messages
<Chipaca> ahasenack: you're saying it was saying classic but wasn't?
<Chipaca> if so that's a Bug
<ahasenack> Chipaca: yep, after the revert
<ahasenack> it was 209 before
<ahasenack> I still have the list --all output from before the revert, let me expand that pastebin
<Chipaca> I'll dig into this in a moment
 * zyga-ubuntu looks at jdstrand's idae
<Chipaca> ahasenack: to be clear, it should have either done it (leaving it as classic) or not done it (telling you you needed to say --classic), depending on the codepath
<ahasenack> Chipaca: http://pastebin.ubuntu.com/25444883/
<zyga-ubuntu> mhm
<zyga-ubuntu> jdstrand: shall I prepare a small RPC idea as well?
<sergiusens> zyga-ubuntu: what does this error mean Setup snap "core" (2462) security profiles (cannot setup udev for snap "core": cannot reload udev rules: exit status 2 ? It seems sporadic as eventually core was installed by means of a different test https://travis-ci.org/snapcore/snapcraft/jobs/270814907
<zyga-ubuntu> sergiusens: hmm, it means that we cannot re-trigger udev
<zyga-ubuntu> I would have to look it up
<zyga-ubuntu> sergiusens: note that just until yesterday we had a bug in master that would generate broken rules for the opengl interface
<zyga-ubuntu> sergiusens: so it may be related
<zyga-ubuntu> sergiusens: but those would not show up for core
<zyga-ubuntu> sergiusens: so not really related
<zyga-ubuntu> unfortunately udev was vey terse :/
<sergiusens> zyga-ubuntu: so there are around 8 tests that would need to setup core in order to get build-snaps tested, seems one failed and the following test dtrt
<sergiusens> also, this is in a container
<jdstrand> zyga-ubuntu: I don't think it is required. that is easy to understand. Knowing how much work was involved in the refactor was more key since it was unknown and a bit scary sounding
<jdstrand> niemeyer, zyga-ubuntu: fyi, https://github.com/snapcore/snapd/pull/3621#discussion_r136583426
<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>
<niemeyer> jdstrand: I'd prefer to continue the conversation on a hangout if that's okay
<jdstrand> niemeyer: well, I would want you and zyga to have the context that I wrote up before having that conversation. note that I'm not sure the hangout is strictly necessary for all of us (see bottom of my comment)
<jdstrand> niemeyer: if you decide it is necessary after reading the comment, that's fine too
<niemeyer> jdstrand: I would really prefer to have a chat about it
<niemeyer> jdstrand: This has been coming for a while, and the back and forth in the PR is also indicative that getting together and actually talking is worth the timing
<jdstrand> niemeyer: that's fine, but please read my context in prepration of the conversation
<zyga-ubuntu> jdstrand: I just read your comment
<Chipaca> hmm
<Chipaca> linode his having some issues
<Chipaca> so, 30 minutes in, 48/1320 tests done
<Chipaca> :-(
<zyga-ubuntu> Chipaca: that's modern market economy
<zyga-ubuntu> Chipaca: and virtualizatoin
<zyga-ubuntu> Chipaca: let me sell you some virtual land
<ogra_> Chipaca, cool, you will be done in just 13h
<Chipaca> ogra_: and 50 minutes travis says "right! everybody out of the pool!"
<Chipaca> zyga-ubuntu: let's go back to barter
<ogra_> well, your tests actually start ... mine are dead in the water before even starting
<zyga-ubuntu> Chipaca: travis said that because linode peed into the pool
<niemeyer> jdstrand: Okay, we've both read it.. what's the best time for a call today?
<ogra_> https://travis-ci.org/snapcore/core-build/builds/270465829
<jdstrand> niemeyer: I can do it in 40 minutes or after
<zyga-ubuntu> sounds good to me
 * zyga-ubuntu is sleepy with the weather, I'll get a qucik nap and see you then
<Chipaca> darn, now i have _two_ reviews without a +1 :-)
<ogra_> jdstrand, is there any reason why i dont see thw wayland interface on my ubuntu core devices ? (shouldnt it be secure enough to allow it on core as well)
<Chipaca> ogra_: psh, that "wayland" thing is never going to take off. DirectFB is where it's at.
<ogra_> !
<pedronis> Chipaca: wasn't /names fixed to be sorted?
<ogra_> i'd live directfb with full GLES :)
<Chipaca> pedronis: I filed a bug for it to be sorted
<Chipaca> pedronis: wishlist bug, filed last tuesday, accepted by nessita the very same day, status confirmed, no way in anything is that going to be live for a while yet
<Chipaca> bug#1714023
<Chipaca> bug 1714023
<mup> Bug #1714023: please make names endpoint sorted <Snap Store:Confirmed for nataliabidart> <https://launchpad.net/bugs/1714023>
<Chipaca> i mean, even if it were an important bug, it wouldn't even be on staging yet i reckon
<pedronis> ok, I was just confused, I saw long funny discussions on it
<Chipaca> :-)
<pedronis> I thought it would have been fixed
<pedronis> in the mean time
<Chipaca> pedronis: those long discussions were last tuesday dude
<pedronis> Chipaca: anyway given that I see little point in trying to get this into 2.28
<Chipaca> pedronis: because the sort won't be needed down the line?
<pedronis> Chipaca: yes, and because IÂ cannot give a +1 right now, all the SetRootDir changes need extra concetration that IÂ don't have
<Chipaca> ah, ok
<pedronis> not to look at that, but to ignore them carefully
<pedronis> s/that/them/
<pedronis> also refreshMisc is not a great name
<Chipaca> pedronis: âThe worst part of this is probably the names of the ensure bits. I'll leave you all to decide that.â
<pedronis> refreshCatalogs ?
<pedronis> IÂ don't know
<niemeyer> mvo: #3556 has a review..
<mup> PR #3556: client,daemon,snap,store: add license field <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/3556>
<niemeyer> Needs a second one
<Chipaca> pedronis: i might retract the PR, do the setrootdir, and then redo this one
<Chipaca> it's going to be a nightmare of conflicts, which is why it's probably going to be a redo and not a rebase, but Â¯\_(ã)_/Â¯
<pedronis> maybe you can find higher stamina people
<Chipaca> pedronis: it's been two weeks, so no
 * zyga-ubuntu is ready for the call
<niemeyer> jdstrand, zyga-ubuntu: I can do in ~1h
<mup> PR snapd#3748 closed: many: fetch & cache remote snaps and sections; complete from there <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3748>
<jdstrand> ok
<zyga-ubuntu> niemeyer: ok
<pedronis> mvo: what's the status of #3379, does it need a jdstrand review?
<mup> PR #3379: cmd/snap,tests: show the snap id if available in snap info <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3379>
<pedronis> heh sorry
<pedronis> mvo: what's the status of #3779, does it need a jdstrand review?
<mup> PR #3779: snap-seccomp: remove use of x/net/bpf from tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3779>
<Chipaca> i'm going offline for a bit, have a good weekend all if i don't make it back before eod
<Chipaca> o/
<jdstrand> pedronis: it is on my list after 3621
<pedronis> Chipaca: o/
<jdstrand> pedronis: but I was waiting on another PR to be committed that it is based on iirc
<pedronis> jdstrand: #3502 was merged
<mup> PR #3502: snap-seccomp: add in-kernel bpf tests  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3502>
<jdstrand> yeah, that one
<pedronis> jdstrand: so, yes should be ready to look at (master merged, other review addressed afaict)
 * jdstrand nods
<jdstrand> I should be able to get to it today
<nacc> is it possible to install the recommends of  stage-package automatically?
<ogra_> yes, if you list them in stage-packages ;)
<nacc> ogra_: not true :/
<nacc> ogra_: oh you mean explicitly? :)
<nacc> ogra_: that bypasses my "automatically" (although not clear how i phrased it)
<nacc> ogra_: i want a package and all it's depends and recommends to be staged
<ogra_> yeah, then you need to manually list them to have them automatically installed :)
<ogra_> iirc only actual depends are processed
<ogra_> (and the debs are also only unpacked, not installed (i.e. none of the maintainer scripts get run)
<ogra_> )
<mvo> niemeyer: thanks a lot for your review, I address the points now
<mvo> pedronis: a jamie review would be good but I think we could merge even without one, he was much in favour of the in-kernel tests that I implemented over the bpf.VM
 * zyga-ubuntu feels so so today
<roadmr> :/
<jdstrand> mvo: fwiw, I don't consider my review essential for that. I'm fine with the concept of it (just using the kernel). I did notice it would be good to comment why you aren't testing PR_SET_ENDIAN above the PR_ for loop. if it is helpful for me to review, that's fine, if not, let me know and I won't
 * zyga-ubuntu resumes fixing stuff
<jdstrand> zyga-ubuntu: sorry you aren't feeling well :\
<zyga-ubuntu> jdstrand: weather
<zyga-ubuntu> jdstrand: spain.read returns EOF
<jdstrand> yeah..
<zyga-ubuntu> jdstrand: I guess the weather outside will forece me to watch that popular series with sex, death and snow people
<zyga-ubuntu> I can smell snow in a few weeks
<zyga-ubuntu> ah, thrones something
<jdstrand> I was surprised how cool it was in Warsaw
<zyga-ubuntu> I think it just ended, right?
<ppisati> ogra_: manually copying the dtbs fixed it
<zyga-ubuntu> cool as in cold?
<jdstrand> zyga-ubuntu: yes
<jdstrand> zyga-ubuntu: no, cool as in pleasant (at the product sprint)
<ogra_> ppisati, thanks for the freedback !
<zyga-ubuntu> haha :)
<zyga-ubuntu> I see :)
<jdstrand> I was then imaging how cold it must get in the winter if it was that pleasant in the summer
<ogra_> ppisati, so same probleam as always ...
<jdstrand> imagining*
<zyga-ubuntu> jdstrand: I think -5/-15C is common
<zyga-ubuntu> it's more that it's cold for a long time
<zyga-ubuntu> and that it's dark
<zyga-ubuntu> I don't like the lack of sunlight
<jdstrand> brrr
<roadmr> haha yes, dark at 4 PM is so weird
<zyga-ubuntu> jdstrand, niemeyer: ready if you are
<ogra_> ogra@localhost:~$ snap list
<ogra_> Name        Version                   Rev   Developer  Notes
<ogra_> core        16-2.27.5+git352.186fdc0  2793  canonical  core
<ogra_> pi2-kernel  4.4.0.1071.71             41    canonical  kernel
<ogra_> pi3         16.04-0.5                 22    canonical  gadget
<ogra_> PHEW!
<jdstrand> me too
 * ogra_ hugs pedronis for the help and ppisati for the kernel re-spins
<ogra_> all back to normal now
<zyga-ubuntu> jdstrand: standup HO?
<ogra_> (such a little fix ... so time consuming ...)
 * zyga-ubuntu looks for headset
<niemeyer> zyga-ubuntu: Grabing a cup of coffee and will be with you
<mup> PR snapcraft#1525 opened: typo: replace occured with occurred <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1525>
<ogra_> ondra, jdstrand http://paste.ubuntu.com/25445729/ i see that on my pi3 now after installing avahi
<ogra_> greyback, FYI ... http://paste.ubuntu.com/25445732/ (mir-kiosk not starting here either on pi3, even with the fixed image, reboot doesnt change anything)
<mup> PR snapd#3779 closed: snap-seccomp: remove use of x/net/bpf from tests <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3779>
<zyga-ubuntu> okay, let me finish the fixes quickly
<jdstrand> niemeyer, zyga-ubuntu: I'll summarize the outcome in the PR
<zyga-ubuntu> thank you!
<zyga-ubuntu> I have a few more things to sort out there, I'll write a dedicated message to signal I'm done with the requested changes
<mvo> niemeyer: addressed your review comments for 3556, thanks again for those
<mvo> niemeyer: I get dinner but check back later
<mvo> zyga-ubuntu: if you could check 3625 and (formally) approve, that would be nice
<om26er> When will the new snappy images release ? (Not talking about updates, rather new img files)
<zyga-ubuntu> mvo: sure
<ogra_> om26er, given that you get an update of all snaps immediately after install, does that really matter ?
<zyga-ubuntu> one
<ogra_> two
<zyga-ubuntu> *done
<zyga-ubuntu> :-)
<niemeyer> mvo: Responded to your question.. still +1 with or without it
<om26er> ogra_: thats true but wouldnt that also bring device specfic changes that are only available in edge right now. (Once new images spin)
<ogra_> om26er, no, stable images only update from stable
<ogra_> (and gadgets do not update any bootloader bits, only snap.yaml (interface definitions etc)
<ogra_> )
<ogra_> (no matter which channel)
 * om26er processes
<jdstrand> zyga-ubuntu, niemeyer: whoops I accidentally hit 'Comment' rather than 'Preview'-- I'm still finetuning the plan of action. I'll edit the comment and ping you when done
<zyga-ubuntu> sue
<zyga-ubuntu> sure
<jdstrand> zyga-ubuntu, niemeyer: ok, read away! :)
 * zyga-ubuntu reads
<zyga-ubuntu> jdstrand: I think this is all fine
<zyga-ubuntu> jdstrand: note that we may choose to opt-out of go-flags
<zyga-ubuntu> jdstrand: to limit the surface to only the standard library and code in the repository
<ogra_> would they be stay-flags then (if you opt-out) ?
<zyga-ubuntu> jdstrand: sounds super good
<zyga-ubuntu> jdstrand: one suggestion/question, shall you just push extra features into this branch so that we can both work on one location or would you rather land this in stages and use separate branches?
<zyga-ubuntu> jdstrand: updated
<zyga-ubuntu> jdstrand: do you plan to write the child profile now?
<zyga-ubuntu> jdstrand: if no I will take a break to help my son and I'll be back to write a quick prototype and see how that operates
<mup> PR snapcraft#1526 opened: catkin plugin: don't assume catkin is in underlay <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1526>
<mup> PR snapd#3841 opened: Do not emit cloud-init.disabled; cloud-init only runs if datasource is present <Created by raharper> <https://github.com/snapcore/snapd/pull/3841>
<jdstrand> zyga-ubuntu: sorry, I'm not working on this right this second. I noticed a bug in the recent big udev PR that affects 2.28 and nvidia
<jdstrand> zyga-ubuntu: I'd like to chase that done a bit
<jdstrand> mvo: hey, are you tracking 2.28 issues anywhere?
<jdstrand> zyga-ubuntu: if you are wanting to write the child profile (I just saw your PR comment), feel free. I'll of course review it deeply
<pedronis> jdstrand: given the outcome in that PR, should we close (at least for now)Â #3840 ?
<mup> PR #3840: snap-update-ns intial refactor for setuid [EXPLORATORY, DO NOT COMMIT] <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3840>
<zyga-ubuntu> jdstrand: thank you, that was my intent
<zyga-ubuntu> jdstrand: curious about nvidia issue
<jdstrand> pedronis: yes. I'll do that
<mup> PR snapd#3720 closed: cmd,interfaces: add initial support for Solus <Created by ikeydoherty> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3720>
<zyga-ubuntu> jdstrand: about the RPC approach, the actual update-ns tool could be woken up by systemd
<zyga-ubuntu> jdstrand: not by snapd
<zyga-ubuntu> jdstrand: not perfect but possible
<zyga-ubuntu> jdstrand: I'm not proposing that we do it, I just wanted to say that, thinking about our conversation earlier
<mup> PR snapd#3838 closed: systemd: rename snap-repair.{service,timer} to snapd.snap-repair.{service,timer} <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3838>
<jdstrand> zyga-ubuntu: so, apparently only GPL modules can use sysfs. sysfs is integral to udev tagging it seems (I need to look a little further). nvidia is proprietry, so no sysfs. therefore it doesn't show up in the udev query to add it to the device cgroup. since opengl now uses the device cgroup, no nvidia
<zyga-ubuntu> hmmmm
<zyga-ubuntu> well, that certainly hairy
<zyga-ubuntu> can we just add predictable things to the cgroup?
<zyga-ubuntu> I'll let you poke and check back soon, still helping my son with his stuff
<mup> PR snapd#3840 closed: snap-update-ns intial refactor for setuid [EXPLORATORY, DO NOT COMMIT] <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/3840>
<jdstrand> zyga-ubuntu: we add some devices automatically to the cgroup now (eg, /dev/zero). I was thinking worst case just add these nvidia devices to the cgroup if they exist, then rely on apparmor for access
<jdstrand> zyga-ubuntu: if we are encountering a lot of things like nvidia, we might manage a file of things to add or come up with something different
<jdstrand> it could get hairy with hotpluggable proprietary devices, but there are things we could do there too
<mup> PR snapd#3842 opened: store: have an ad-hoc method on cfg to get its list of uris for tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/3842>
<mup> PR snapd#3843 opened: cmd/snap: SetRootDir from SetUpTest, not in just some individual tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/3843>
<mup> PR snapd#3844 opened: overlord/snapstate: SetRootDir from SetUpTest, not in just some tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/3844>
<Chipaca> hello from webchat :-)
<Chipaca> zyga-ubuntu: thank you for the speedy reviews!
<Chipaca> and next stop is mine, so i'm off again o/
<zyga-ubuntu> :)
<jdstrand> sigh, the device cgroups aren't working right. I'll need to investigate that first before nvidia
<jdstrand> mvo: fyi, ^
<jdstrand> mvo: I'll file bugs/etc when have complete info
<jdstrand> basically, if there are more than one command in /etc/udev/rules.d/70-snap.foo.rules, only one of the commands gets a device cgroup. and if it gets a device cgroup, snap-confine isn't putting it into it
<jdstrand> s/are more/is more/
<mvo> jdstrand: uh, meh :/
<mvo> jdstrand: is that a regression?
<jdstrand> mvo: not in 2.28. it is a regression somewhere (it used to work :)
<jdstrand> I need to figure out when it occurred. I also need to look at the spread test for this
<jdstrand> I suspect a) it isn't doing enough to test an actual denial and b) it isn't doing multiple commands within the same snap
<jdstrand> I'll get this all fixed up with updated spread tests. won't have it today, will do it first thing next week
<jdstrand> well, sorta first thing-- monday is a US holiday
<jdstrand> anyhoo, I' figure it out
<jdstrand> mvo: ^
<jdstrand> I'll*
<mvo> jdstrand: ok, thanks a bunch. if you put infos how to reproduce e.g. into the forum I can check monday. its not a holiday in my part of the world
<mvo> jdstrand: if its not too hard I could e.g. bisect to see when things went wrong
<jdstrand> mvo: as such, there is no problem with nvidia and the udev PR. cgroups are being created but not used so nothing can break ;P
<mvo> jdstrand: aha, ok
<jdstrand> mvo: I'd really like to dig in on this and then document how to debug this stuff so others can do it in the future
<jdstrand> mvo: I'm sure you're busy enough. plus, there should be no user facing regression for the 2.28 release (2.27.5 seems affected too)
<mup> PR snapd#3843 closed: cmd/snap: SetRootDir from SetUpTest, not in just some individual tests <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3843>
<mvo> jdstrand: ok, if there is no user facing fallout I'm fine with waiting, I mostly offering monday as it sounded very urgent. yeah, I have plenty else to work on :)
<mvo> jdstrand: thanks for looking into it!
<jdstrand> np
<jdstrand> mvo: if there is a user facing regression (again, I'm not seeing it), but the time it is discovered I will be on it, so I think we're good. thanks for the offer
<jdstrand> s/but the/by the/
<mvo> jdstrand: thank you as well. I will call it a day now, have a great (long) weekend
<mup> PR snapcraft#1520 closed: tour: remove the tour assets <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1520>
<mup> PR snapcraft#1521 closed: python plugin: always record constraints and requirements contents <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1521>
#snappy 2017-09-02
<zyga-ubuntu> o/
<mup> Bug #1648988 changed: Unable to fork a new WebProcess: Failed to execute child process "/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess" (No such file or directory). <Snappy:Invalid> <https://launchpad.net/bugs/1648988>
<nsg> We are thinking about using snaps to manage a few applications at work and we noticed that the project linked under "Other stores" in the docs are dead. Is there some other implementation out there? Half finished are fine, we can contribute.
<ogra_> nsg, https://docs.ubuntu.com/core/en/build-store perhaps ?
<nsg> Brand stores? I did not like the phrase "To get a brand store, you need to contact a Canonical sales representative, that will transmit your store creation request to the engineering teams." ... we are not afraid of money but it's usually easier with pure FOSS software.
<nsg> I also guess that that's a hosted solution, we prefer to have our repos inside the local network.
<ogra_> there is work going on to provide this but it isnt done yet (i think there are infos on the forum (see channel topic))
<nsg> At the moment I'm looking for the API:s to see how much work it would be to write a simple minimal store for our needs :)
<nsg> Ah, nice, I will check the forums
<nsg> Ah, I see the problem. I'm happy that you are working/thinking about a solution and a hack similar to your "snap-get" hack from the forums is a solution with much less effort to make and probably easier to sell that idea to my team.
#snappy 2017-09-03
<waters33637> Question: I want to change the port for sshd ... did "sudo snap install classic --devmode --edge
<waters33637> " then edit /etc/ssh/sshd_config and change the port ... and shutdown -r now ... yet when it comes back up .. it is still on port 22  .. and  the config file still has the new port.... what am i missing?
<waters33637> had to change in in /writeable/ ... is that new?
<om26er> Why don't I have `dbus` interface on my Ubuntu 16.04 ? snapd 2.26.14
<ogra_> because nothing provides it ?
<ogra_> you need a snap providing it
<ogra_> https://forum.snapcraft.io/t/how-do-i-connect-a-snap-to-dbus/1533
<om26er> Thanks! that worked.
<om26er> apparently, now my snap needs "manual review".
<om26er> human review required due to 'deny-connection' constraint for 'slot-attributes' from base declaration declaration-snap-v2_slots_deny-connection (kde-screensaver-dbus, dbus)
<om26er> ogra_: if a snap provides a slot, does that snap itself get access to that slot (without connection) ?
<ogra_> hmm, not sure
<om26er> popey: are you by any chance staring at a computer screen on a Sunday ? mind doing a manual review for my snap that got blocked due to whatever reason :)
<popey> om26er: I am!
<popey> om26er: got a link?
<om26er> popey: ah great, just a sec.
<om26er> popey: this: https://dashboard.snapcraft.io/dev/snaps/8290/rev/7/
<popey> om26er: sorry, i think I'm going to have to leave that one for someone from the security team.
<om26er> popey: can you specify the exact reason for that ? Seems the error message is not helpful.
<om26er> I might try to fix/change things in the meantime
<popey> ogra_: seen http://www.banana-pi.org/bpi-zero.html ? :)
<mup> PR snapd#3845 opened: osutil: include a variant of AtomicWrite* that takes an io.Reader <Created by chipaca> <https://github.com/snapcore/snapd/pull/3845>
<mup> PR snapcraft#1527 opened: repo: Use os-release(5) to detect supported Linux distributions <Created by Conan-Kudo> <https://github.com/snapcore/snapcraft/pull/1527>
#snappy 2018-08-27
<mborzecki> morning
<mborzecki> mvo: hi, any ideas if snapd will blow up if there's apparmor support in the kernel but no userspace tools?
<mvo> mborzecki: that sounds likely
<mvo> mborzecki: I think we need a extra check in the release.Apparmor code that checks if apparmor_parser is available
<mvo> mborzecki: should be a trivial PR
<mvo> mborzecki: and nice catch
<mborzecki> mvo: i'll look into that
<mvo> mborzecki: ta
<mvo> mborzecki: and GOOD MORNING :)
<mborzecki> mvo: hah right :) morning
<mvo> mborzecki: I also left some feedback in the arch -hardended kver PR, nice catch on the details of the kernels there
<mborzecki> mvo: saw your review, thanks
<mborzecki> mvo: nice thing is apparmor will be in the default kernel in arch, but you still need to pass apparmor=1 security=apparmor to the kernel and have the userspace tools, need to make sure we degrade gracefully
<mvo> mborzecki: nice! thats a good step forward
<zyga> good morning!
<mvo> hey zyga ! good morning
 * zyga is sleepy but needs to wake up rapidly
<zyga> today I plan to spend 30% on PRs (reviews and gardening) and 70% on helping with a CE request
<mup> PR snapd#5715 closed: selftest: detect if apparmor is unusable and error <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5715>
<zyga> mvo: question about 5715
<zyga> https://github.com/snapcore/snapd/pull/5715#pullrequestreview-149598142
<mup> PR #5715: selftest: detect if apparmor is unusable and error <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5715>
<mborzecki> zyga: hey
<zyga> :-) o/
<mvo> zyga: whats the question?
<zyga> mvo: I asked in the review if there's any difference about the two lines that check for the new message inside a container
<mvo> zyga: aha, sorry, I see it now. one is the loop but we also need to ensure the loop did not timeout
<zyga> ah
<zyga> that makes sense, thanks
<mvo> zyga: ok
<mvo> zyga: does it look ok otherwise? sorry did not see that we were also reviewing
<zyga> yes, it looks good :)
<zyga> nice and simple
<zyga> (which is not to say that it is easy, it's great to make simple things)
<mvo> ta
<mborzecki> mvo: for the record, i've removed apparmor tooling and cannot remove snaps anymore https://paste.ubuntu.com/p/fhmfjm6vhM/
<mvo> mborzecki: can you install snaps? or does anything install/remove related break?
<mborzecki> mvo: snap remove/install errors out on security profiles
<pstolowski> morning
<mborzecki> mvo: refresh probably doesn't work either as it's practically install under the hood
<mborzecki> pstolowski: hey
<mborzecki> zyga: when checking if we need to downgrade apparmor template to classic, do we care about specific kernel version, or is 4.16+ good to go in general?
<zyga> mborzecki: it was just the version that opensuse happened to ship with
<zyga> and was meant as an experiment to see what breaks
<zyga> I think it was successful though
<mborzecki> zyga: any clue how network_v8 is different from network in apparmor features?
<zyga> some, network is just "you can interact with given set of sockets", there's a very simple table that has some flags per socket type (AF_INET, AF_INET6, etc).
<zyga> network_v8 is ... more than that :) I heard that fine grained network mediation was coming
<zyga> so perhaps there's a more rich table now
<zyga> let me look quickly
<zyga> mvo: can you please look at https://github.com/snapcore/snapd/pull/5721
<mup> PR #5721: interfaces: retain order of inserted security backends <Created by zyga> <https://github.com/snapcore/snapd/pull/5721>
<zyga> (again, updates based on your review)
<mvo> zyga: sure
<zyga> thanks :)
<zyga> mborzecki: looking now
<mborzecki> zyga: found this https://www.mail-archive.com/apparmor@lists.ubuntu.com/msg09772.html
<zyga> mborzecki: this is not new stuff, it was merged in July 2017
<zyga> mborzecki: it's the old network support code from ubuntu, now mainline
<zyga> (I'm looking at torvald's tree)
<niemeyer> Morning all!
<zyga> mborzecki: note that I don't see "network" (plain, without v8) anymore
<zyga> hey :)
<pstolowski> morning niemeyer!
<mvo> I see some strange errors on arch: Aug 27 07:17:06 arch snapd[25825]: task.go:303: DEBUG: 2018-08-27T07:17:06Z ERROR cannot generate device key pair: asn1: structure error: tags don't match (16 vs {class:1 tag:15 length:112 isCompound:true}) {optional:false explicit:false application:false defaultValue:<nil> tag:<nil> stringType:0 timeType:0 set:false omitEmpty:false} pkcs1PrivateKey @2 does that ring any bells?
<mvo> and good morning niemeyer
<niemeyer> o/
<mborzecki> niemeyer: hey
<zyga> mvo: no, I never heard of this issue before
<mborzecki> mvo: ... value *state.changeError = &state.changeError{errors:[]state.taskError{state.taskError{task:"Generate device key", error:"cannot generate device key pair: asn1: structure error: tags don't match (16 vs {class:1 tag:15 length:112 isCompound:true}) {optional:false explicit:false application:false defaultValue:<nil> tag:<nil> stringType:0 timeType:0 set:false omitEmpty:false} pkcs1PrivateKey @2"}}}
<mborzecki> ("cannot perform the following tasks:\n- Generate device key (cannot generate device key pair: asn1: structure error: tags don't match (16 vs {class:1 tag:15 length:112 isCompound:true}) {optional:false explicit:false application:false defaultValue:<nil> tag:<nil> stringType:0 timeType:0 set:false omitEmpty:false} pkcs1PrivateKey @2)")
<mborzecki> in unit tests
<zyga> are we shelling out to external tools for key crypto?
<pedronis> yes, to ssh-keygen because go own key creation was deemed too slow
<pedronis> so something might be going on there
<mborzecki> hmm [2018-08-26 22:29] [ALPM] upgraded openssh (7.7p1-2 -> 7.8p1-1)
<mborzecki> what version are you guys on?
<mvo> 7.6
<zyga> mborzecki: ssh changed something lately
<zyga> mborzecki: there was an article about this on lwn
<mvo> aha and the changelog has information that they changed the output of ssh-keygen
<mvo> -m PEM will fix it
<mborzecki> ok, i'll add it here
<zyga> https://lwn.net/Articles/763444/
<zyga> indeed
<zyga>  * ssh-keygen(1): write OpenSSH format private keys by default
<zyga>    instead of using OpenSSL's PEM format. The OpenSSH format,
<zyga> mborzecki: nice :)
<mvo> and it works all the way back to trusty
<mvo> so that should be fine
<mborzecki> seems to work now, opening a PR in a minute
<mup> PR snapd#5725 opened: overlord/devicestate: use OpenSSL's PEM format when generating keys <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5725>
<mvo> mborzecki: ta
<mborzecki> hm apparmor mocking around the tests for system-key is noop
<mvo> mborzecki: oh? do you have more details?
<mborzecki> mvo: a path to apparmor sysfs features directory was built in SetUpTest() but it was never used afaict
<mvo> mborzecki: the pem pr failed with an unrelated error, I can restart but I will have a look at the error, it looks like we don't mock enough somewhere
<mborzecki> mvo: ack, unit tests sans snap-seccomp were passing locally
<mup> PR snapd#5726 opened: release, interfaces: make snapd degrade gracefully when AppArmor userspace tooling is unavailable <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5726>
<mborzecki> mvo: zyga: let me know if that makes sense
<mborzecki> ^^
<zyga> reading that now
 * mvo looks
<mup> PR snapd#5723 closed: cmd: remove --skip-command-chain from snap run and snap-exec <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5723>
<mborzecki> ok, time for some reviews
<mup> PR snapd#5725 closed: overlord/devicestate: use OpenSSL's PEM format when generating keys <Critical> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5725>
<zyga> thank you!
<zyga> brb, coffee and snack
<mup> PR snapd#5716 closed: tests: spread test for parallel-installs desktop file handling <Parallel installs> <Simple> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5716>
<zyga> re
<mup> PR snapcraft#2220 closed: schema: allow license field <Created by mvo5> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2220>
<mvo> can I get a review for https://github.com/snapcore/core/pull/93 please?
<mup> PR core#93: hooks: unwind /etc/alternatives <Created by mvo5> <https://github.com/snapcore/core/pull/93>
<zyga> mvo: looking
<zyga> mvo: wow, I missed that!
<zyga> thank you for sharing
<mvo> zyga: no worries
<zyga> mvo: reviewed
<mvo> zyga: thanks, I like your suggestion there
<mvo> zyga: mind if I do it in a followup, first in core18 ? that is much simpler to test (i.e. it can be build in 1/10 of the time)
<ogra> jdstrand, an interesting one for you https://paste.ubuntu.com/p/ZwdqN6XMVY/
<mup> PR snapcraft#2223 closed: snap: prepare override scripts to allow rebuilding <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2223>
<zyga> ogra: how is it interesting?
<zyga> it looks like just missing "home"
<ogra> zyga, the traceback ...
<ogra> that shouldnt happen
<ogra> (and usually doesnt)
<zyga> locale?
<ogra> well, german ...
<ogra> it doesnt happen with other snaps
<zyga> no, I mean PYTHONENCODING=utf-8
<zyga> is home connected?
<ogra> the snap doesnt have a home plug
<ogra> (yet)
<zyga> then it cannot access Dokumente
<zyga> I still don't see what's the interesting part
<ogra> sure, but snappy-debug shouldnt crash
<ogra> i dont care about home, i know i havent added it yet
<ogra> i want to see all the subsequent info that comes after home in the log
<ogra> but snappy-debug crashes hard before it can evcen show anything
<ogra> *thats* the interesting part
<zyga> aaah, it was snappy-debug
<ogra> right
<zyga> I missed that
<zyga> indeed, I don't know why we do that
<ogra> i guess snappy-debug needs some utf-8 love somewhere in the code
<zyga> ijohnson: hey
<zyga> thank you!
<zyga> ijohnson: when would be a good time to chat?
<pedronis> zyga: wrong channel?
<mup> PR snapd#5721 closed: interfaces: retain order of inserted security backends <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5721>
<twobitsprite> So, I'm delving in to the world of snaps on my Debian Buster system... I'm trying to install the helm client, and it's only available as a snap or as a tarball, so I figured I'd try the snap version... I got snapd installed and I ran "sudo snap install helm". It says it installed it, but I don't have a helm command in my path...
<zyga> pedronis: yes, we moved
 * zyga -> errand break (1.5-2hrs)
<ogra> twobitsprite, "snap info helm" should list any commands the snap ships
<ogra> twobitsprite, you also might want to check if there are interfaces you need to manually connect ... list them with "snap interfaces helm"
<twobitsprite> ogra: it says "helm" is a command it should provide
<ogra> twobitsprite, ah,m you newly installed snapd .. that adds /snap/bin to your oath but it will indeed only take effect if you re-login
<ogra> *path
<twobitsprite> ogra: interfaces lists :home, :network and :network-bind, all of them say "helm" under the "Plug" column
<twobitsprite> ogra: ahh
<ogra> yeah, these typically auto-connect
<ogra> you can either use "snap run helm"
<ogra> or use the full path via /snap/bin/heml
<ogra> *helm
<ogra> or re-login indeed
<twobitsprite> ogra: yep, that was the problem, thanks
<ogra> enjoy
<jdstrand> ogra: ack, thanks
<niemeyer> Taking a short break here
<kyrofa> mvo, can I get your input on this? https://bugs.launchpad.net/snapd/+bug/1779416
<mup> Bug #1779416: Scripts in core snap attempt to do things impossible under confinement and die <snapd:New> <https://launchpad.net/bugs/1779416>
<mvo> kyrofa: that sounds sensible, I was not aware this is actually used
<kyrofa> mvo, me neither, took me forver to sort it out :P
<mvo> heh, thanks for this kyrofa
<zyga> re
 * zyga has finished the car insurance and ownership saga
 * cachio lunch
<zyga> jdstrand: hey, just a gentle ping about https://github.com/snapcore/snapd/pull/5170 and https://github.com/snapcore/snapd/pull/5307
<mup> PR #5170: interfaces/builtin: add adb interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
<mup> PR #5307: cmd,interfaces,tests: add /mnt to removable-media interface <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5307>
 * zyga gets back to his activity
<jdstrand> zyga: yep, both on the list. hopefully today
<zyga> thank you :)
<mup> PR snapcraft#2227 opened: Wait lxd <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2227>
<om26er> How far along is "parallel install" feature of snaps ?
<om26er> we want different versions (stable, beta, canary) of android studio at the same time (popular request)
<zyga> om26er: it is coming along
<zyga> om26er: ask mborzecki tomorrow morning
<om26er> zyga: will do, thanks
<mup> PR snapd#5727 opened: interfaces/builtin, cmd/snap-seccomp: Allow read-only ptrace, for the Breakpad crash reporter <Created by jld> <https://github.com/snapcore/snapd/pull/5727>
<cachio> zyga, hey, any idea why this could be happening? https://paste.ubuntu.com/p/dG7WVRZ8Q3/
<cachio> it is braking ubuntu-core-18
<cachio> zyga, if I restart the service it works, but initially it fails
<dave_uy> What is the right way to reference a desktop icon in a .desktop file?
<dave_uy> Nevermind. I found an example: https://github.com/sergiusens/telegram-snap/blob/master/snap/gui/telegram.desktop
<zyga> cachio: looking
<cachio> zyga, tx,
<cachio> otherwise tomorrow is ok
<zyga> perhaps because the socket doesn't respond initially (seeding)
<zyga> but yeah, tomorrow
<cachio> zyga, tomorrow better, now it is time to rest :)
<kyrofa> Is the store down?
<kyrofa> Ah, it seems so
<kyrofa> "Intermittent access issue in few services for 7 Mins 20 Secs" makes it sound like it's over
#snappy 2018-08-28
<Caelum> zyga: looks like we'll need to update the opensuse package again, stopped working
<Caelum> zyga: "cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied"
<mborzecki> morning
<mup> PR snapd#5691 closed: spdx: allow Other-Open-Source <Simple> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5691>
<mup> PR snapd#5728 opened: spdx: remove "Other Open Source" from the support licenses <Created by mvo5> <https://github.com/snapcore/snapd/pull/5728>
<mvo> zyga: hey, what do you think, when can we remove the experimental flag from layouts?
<mup> PR snapd#5729 opened: many: rename ClientOpts to ClientOptions <Created by mvo5> <https://github.com/snapcore/snapd/pull/5729>
<mborzecki> mvo: hi, is /etc/hostname not writable in core 18 devices? https://github.com/snapcore/snapd/pull/5722 hostnamectl appears to be failing with 'read only filesystem'
<mup> PR #5722: tests: test for the hostname interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5722>
<mborzecki> mvo: iirc layouts still have that problem with trespassing to the host's filesystem
<mvo> mborzecki: hm, etc/hostname should be a symlink on core18 to etc/writable/hostname, let me double check that
<mvo> mborzecki: yeah, its a symlink
<mvo> mborzecki: so maybe thats the problem? that the apparmor policy does not have the symlink?
<mvo> (target)
<mborzecki> mvo: hmm, but it failed with 'read only fs', i'd guess EROFS appeared somewhere there, with apparmort that'd be more like permission denied
<mborzecki> mvo: wonder if hostnamectl truncates /etc/hostname or writes a new file and does a rename
<zyga> Good morning
<mborzecki> zyga: hey
<zyga> Iâll start soon
<mvo> mborzecki: oh that rings a bell
<zyga> Kids had blood test today
<mvo> mborzecki: let me quickly check
<zyga> And needed my âmoral supportâ
<mvo> pedronis: is 5699 something you want to review ? or do you think its fine?
<mvo> mborzecki: this sounds a lot like https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936
<zyga> mvo: after trespassing bug is fixed
<mvo> zyga: aha, ok
<zyga> Then they are ready
<mup> Bug #1778936: please re-add Support-system-image-read-only-etc.patch <patch> <systemd (Ubuntu):New> <systemd (Ubuntu Bionic):New> <systemd (Ubuntu Cosmic):New> <https://launchpad.net/bugs/1778936>
<mborzecki> mup: heh, yes
<mup> mborzecki: I apologize, but I'm pretty strict about only responding to known commands.
<mborzecki> mvo: heh, yes :)
<zyga> Iâll work with Maciej on this as it was harder to come up with precise logic than I wished last time
<mvo> mborzecki: I get the feeling I will have to do this SRU myself :/
<mvo> mborzecki: anyway
<mvo> mborzecki: I will put it on my list
<mup> PR snapd#5730 opened:  devicestate: support getting (http) proxy from core config  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5730>
<mup> PR snapd#5704 closed:  snap: add new type "TypeSnapd" and attach to the snapd snap  <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5704>
<mup> PR snapd#5728 closed: spdx: remove "Other Open Source" from the support licenses <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5728>
<mvo> mborzecki: want to have a quick look at 5719 again? I had to change it slightly after gustavos review but should be fine (all tests still happy and errors better)
<mborzecki> mvo: already +1'ed it
<mborzecki> oh, w8, that's the other one :)
<mup> PR snapd#5710 closed:  cmd: support re-exec into the "snapd" snap  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5710>
<mup> PR snapd#5709 closed: configcore,snapstate: add new core.experimental.snapd-snap option <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5709>
<mup> PR core#93 closed: hooks: unwind /etc/alternatives <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/93>
<zyga> Back
<zyga> mvo: re
<zyga> mvo: I have that dragon on my desk if you need any support
<zyga> mvo: it's not powered on but I can bring all the misc bits and set it up if you need me to
<pstolowski> mornings
<mborzecki> pstolowski: hey
<Caelum> zyga: hi, opensuse package is broken again, something to do with apparmor, would an update fix it? If so I'll send you a PR.
<zyga> Caelum: yes, I have the build ready, just need to pull the trigger
<zyga> Caelum: can you review & test?
<Caelum> zyga: yeah totally
<zyga> ok
<zyga> hold on, let me commit
<mvo> zyga: I just send an update to the etc/alternatives stuff in snapcore/core18. not urgent but you may be interessted
<mup> PR core18#64 opened: hooks: improve /etc/alternatives unwinding <Created by mvo5> <https://github.com/snapcore/core18/pull/64>
<zyga> ack
<Caelum> zyga: also at some point I want to talk about reviving the gentoo overlay
<zyga> sure
<zyga> I have nothing for that so please go ahead
<mup> PR core#94 opened: hooks: improve /etc/alternatives unwinding <Created by mvo5> <https://github.com/snapcore/core/pull/94>
<zyga> btrfs rebalance ...
<zyga> ha
<zyga> mvo: I found a bug in our systemd unit
<zyga> system key refresh takes long eough
<zyga> long enough
<zyga> that systemd restarts us
<zyga> we need to poke systemd using sd-notify during the security setup as it can take a lot of time
<zyga> I guess this will continue while balancing is in progress as the system is much slower than usual
<Caelum> it's good to cron that shit
<Caelum> mine is @daily
<Caelum> zyga: well highlight me if you want me to do anything
<zyga> Caelum: sure, I'll send my build as soon as btrfs stops my system from crawling
<zyga> Caelum: I want to branch it so that it can be reviewed
<Caelum> awesome
<zyga> ok I/O aside I managed to branch it
<mborzecki> mvo: left you a coment in https://github.com/snapcore/snapd/pull/5729 btw. the title says it's only messing with ClientOptions, but it's adding proxy too
<mup> PR #5729: many: rename ClientOpts to ClientOptions <Created by mvo5> <https://github.com/snapcore/snapd/pull/5729>
<zyga> https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd
<niemeyer> Good mornings!
<Chipaca> moin moin
<zyga> hey guys
<zyga> good morning
<zyga> :)
<pstolowski> o/
<zyga> summer is supposedly back this week (just not yet)
<Chipaca> mvo: did you see the last failure on #5722? is /etc/hostname writable on core 18?
<mup> PR #5722: tests: test for the hostname interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5722>
<mvo> Chipaca: I did not, but i suspect its https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936
<mup> Bug #1778936: please re-add Support-system-image-read-only-etc.patch <patch> <systemd (Ubuntu):New> <systemd (Ubuntu Bionic):New> <systemd (Ubuntu Cosmic):New> <https://launchpad.net/bugs/1778936>
<Chipaca> mvo: ah
<mvo> zyga: nice catch
<mvo> mborzecki: 5729 is build on top of the other one, I hope I added it to the description
<mvo> mborzecki: I think I could split them maybe thats clearer
<mborzecki> mvo: it's ok with me
<mvo> mborzecki: otoh the proxy one can land, I was just waiting to double check with pedronis if he wants to have a look at the proxy thing because it does some potentially dangerous state interactions (it needs to lock state to get the proxy)
<mvo> mborzecki: ok
<mvo> Chipaca: and WELCOME BACK
<Chipaca> mvo: :-)
<Chipaca> mvo: looking forward to all the review feedback that'll be waiting for me
<Chipaca> zyga: were you able to get your lab back up? I could use a darwin shell about now
<zyga> Chipaca: almost, I can set you up in 10 min
<Chipaca> zyga: no rush; just let me know
<zyga> almost done
<pedronis> mvo: hi
<mvo> pedronis: good morning! just wanted to double check if 5699  is something you want to have a look at :)
<pedronis> mvo: I'm a bit worried that we are not super consistent about releasing the lock when doing store things
<mvo> pedronis: just to clarify you don't have to, but it might be interessting because of the proxy helper and state lock interplay
<pedronis> we do for some main things
<mvo> pedronis: yeah, this PR would enforce that we are
<pedronis> mvo: enforce ?
<mvo> pedronis: well, it will crash or hang if we don't
<pedronis> wouldn't call that enforce
<zyga> Chipaca: check check?
<mvo> pedronis: ok, bad wording then :/ I mean we will need it
<Chipaca> zyga: check what?
<Chipaca> ah
<zyga> Chipaca: did you see my private msg?
<pedronis> mvo: yea, re-double checking
<Chipaca> zyga: now yes
<zyga> Chipaca: there's golang and gcc
<zyga> Chipaca: there should be git and other things but let me know if you need more
<zyga> Chipaca: you are on bare metal
<Chipaca> zyga: woo, thanks
<Chipaca> mbuahaha
<zyga> enjoy :)
<pedronis> mvo: so rechecking most of the relevant packages have tests with a fakeStore that uses a pokeStateLock helper to check for that,  daemon doesn't do that though because usually it doesn't hold the lock for long and also there's no clear state in many tests, but bit delicate, maybe you want to look there what we can do
<mvo> pedronis: so it sounds like I should add tests in daemon that poleStateLock?
<pedronis> mvo: add pokeStateLock in daemon test fake store bits, yes,   it seems by definition there is always a state if we use those, because we had to use ReplaceStore anyway
<mvo> pedronis: great, I will do that, thank you
 * zyga wonders what the error is in https://build.opensuse.org/build/home:zyga:branches:system:snappy/openSUSE_Tumbleweed/i586/snapd/_log
<zyga> log files from suse are horrible :/
<mborzecki> hm i guess locking the state for the whole duration of doMountSnap() is a bad idea?
<Chipaca> zyga: can you install squashfs-tools?
<zyga> Chipaca: not sure, let me try
<Chipaca> zyga: (assuming you're using something like brew)
<zyga> no, I try to stay clear of brew
<Chipaca> (or whatever the package mangler on osx is)
<Chipaca> zyga: I'll run it from git (or try to!)
<zyga> Chipaca: it doesn't build, hold on
<zyga> mksquashfs.c:4404:29: error: use of undeclared identifier 'FNM_EXTMATCH'
<zyga>                                 FNM_PATHNAME|FNM_PERIOD|FNM_EXTMATCH) == 0;
<zyga> I have a firm deja-vu now
<zyga> Chipaca: if you can find me a copy that builds :)
<zyga> Chipaca: I suspect someone patched the glibc-specific flag
<zyga> I remember now, I was building this on my MacBook
<zyga> (remember, the one I had in Netherlands)
<zyga> and I had to patch some things for it to build
<Chipaca> zyga: looks like there's a nixos patch for darwin
<zyga> Chipaca: do you have a link or a tree ?
<zyga> ideally something we would later on incorporate into our build
<Chipaca> zyga: could you sudo chmod u+s /usr/bin/dtrace
<zyga> dtrace? :)
<zyga> sure, what do you need it for
<Chipaca> zyga: this is the patch: https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/filesystems/squashfs/darwin.patch
<Chipaca> zyga: 'snap pack' failing with 'exit error 1', wondering what all is failing
<Chipaca> shortest path to answer that is to trace it :-)
<Chipaca> then i need to improve the error output
<Chipaca> then, fix it
<zyga> Chipaca: are you set now?
<Chipaca> zyga: it works
<zyga> ok, good luck
<zyga> I should reboot the ssh host as it runs an older kernel
<zyga> so let me know when would be a good time for that
<zyga> Caelum: hey
<zyga> I pushed https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd
<zyga> can you please have a look at that
<zyga> I cannot understand why the i386 build fails
<zyga> (the error log is just ... not saying anything)
<zyga> in any case, that is the latest and greatest
<zyga> so any feedback you can get on that is appreciated
<zyga> Caelum: you need to build the package locally as I didn't publish the build
<zyga> I'll grab a coffee and be back soon
<Caelum> zyga: looking now
<Caelum> zyga: one reason the build can fail I told you about a couple months ago, there is one time-sensitive test running in parallel
<Caelum> don't remember which one it was
<zyga> Caelum: maybe but I'm not convinced
<zyga> this is failing on i386 consistently
<zyga> while not failing on amd64
<Caelum> oh ok
<Caelum> I've had a similar thing initially, it would build on i386 but fail on amd64
<Caelum> because it needs 32bit support stuff
<zyga> but on 32bit system every library is this
<zyga> I mean, 32bit
<Caelum> yup
<Caelum> there are no logs?
<zyga> sure there are
<zyga> have a look
<zyga> I could not find what failed
<zyga> the go build / check wrappers are extremely verbose
<zyga> it seems a page full of text flies for every single file
<Caelum> it thinks the tests failed because of bad exit status but there is no error, that would probably mean a segfault
<Caelum> is it always failing on i386?
<Caelum> err i686 I guess
<Caelum> in the same exact place?
<Caelum> build is randomly freezing on me downloading packages
<Caelum> weird
<zyga> Caelum: I don't know, what I managed to get is the log file it references
<zyga> https://www.irccloud.com/pastebin/SC8Lnihd/
<Caelum> zyga: yeah that just runs the tests
<Caelum> zyga: and then one of them segfaults
<zyga> aha,
<zyga> I can run tests with "go test ./..." just fine
<Caelum> on 32 bit?
<zyga> but on x86_64 :)
<zyga> probably some of the hardening things are breaking
<mvo> pedronis: adding pokestate is a bit of a rathole, a lot of tests do not setup the fake store and just rely on that some other test did that. anyway, working on it. good intuition there
<Caelum> zyga: if you want to do a test on a 32 bit docker image, there are apparently some tricks involved: https://github.com/moby/moby/issues/611
<zyga> I'm using a 32bit chroot
<Caelum> ah cool
<zyga> abuild@tumbleweed:~/go/src/github.com/snapcore/snapd/vendor/github.com/mvo5/libseccomp-golang> go test
<zyga> can't load package: package github.com/snapcore/snapd/vendor/github.com/mvo5/libseccomp-golang: build constraints exclude all Go files in /home/abuild/go/src/github.com/snapcore/snapd/vendor/github.com/mvo5/libseccomp-golang
<zyga> mvo: ^ that's interesting, I'm trying to understand why this happens
<zyga> nothing immediately obvious would cause this
<mvo> zyga: that it the upstream libseccomp-golang with a mintor tweak
<mvo> zyga: what arch is this?
<zyga> mvo: i586 chroot
<mvo> zyga: maybe its just missing from libseccomp-golang?
<zyga> mvo: the constraints just say +linux
<zyga> I'm exploring
<Caelum> zyga: well, for some reason my build kept freezing on downloading packages, so I was not able to test anything, sorry.  Going to be driving for the next 8 hours. If you aren't sure this always happens, you can make a dummy commit to force a rebuild or there is an osc command to force a rebuild too.
<popey> Why does "snap info chromium" say license:   unknown, but https://snapcraft.io/chromium shows lots of licenses?
<zyga> Caelum: I tried that
<Caelum> zyga: ah great
<zyga> popey: because meta/snap.yaml doesn't say license:
<popey> ah
<popey> ok, thanks! :D
<popey> It's a bit odd that it behaves differently if installed or not
<zyga> yes
<zyga> because once set of meta-data is from the store and the other is from the package
<popey> yes, that's bizarro
<zyga> # runtime/cgo
<zyga> cc1: sorry, unimplemented: 64-bit mode not compiled in
<zyga> mvo: tadam
<zyga> that's golang 1.10 i386
<zyga> being confused about something apparently
<zyga> this is a i386 chroot
<zyga> (well i586)
<zyga> this is after unsetting CGO_ENABLED=0
<mvo> zyga: yeah, I was suspecting that it can't identify its architcture
<mup> PR snapd#5731 opened: daemon: remove TestSnapsInfoUnknownSource <Created by mvo5> <https://github.com/snapcore/snapd/pull/5731>
<mvo> Chipaca: ^-- might be interessting for you, would love your feedback
<niemeyer> cjwatson: ping
<Caelum> zyga: and there is some kind of problem with 'osc build' that I saw in another one of my projects that I'm getting now: file /usr/lib/rpm/fileattrs/kernel.attr from install of rpm-config-SUSE-0-1.1.noarch conflicts with file from package rpm-4.14.1-3.1.x86_64
<Caelum> zyga: not related to snapd
<zyga> I can build / test it in a chroot after setting GOARCH=386
<Chipaca> popey: license should be per snap revision (and not editable via web), but the store hasn't been able to implement it yet
<Caelum> zyga: it also runs: file /usr/lib/rpm/fileattrs/kernel.attr from install of rpm-config-SUSE-0-1.1.noarch conflicts with file from package rpm-4.14.1-3.1.x86_64
<Caelum> err
<Chipaca> mvo: what does 'go env' print?
<Caelum> /usr/bin/make -O -j2 -C cmd check
<mvo> Chipaca: you mean zyga right?
<Chipaca> probably, yes
<zyga> go env https://www.irccloud.com/pastebin/YsN4UGgW/
<zyga> though this is tweaked in an interactive shell
<zyga> vanilla build doesn't show me anything useful
<Chipaca> zyga: not sure what you're trying to do, but why are you trying to do it with gccgo?
<Caelum> zyga: I mean, did you do only "go test" or "make check" too
<zyga> this is for snap-seccomp
<zyga> lots of red
<zyga> https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd
<mup> PR snapd#5732 opened:  daemon: add pokeTest helper to the daemon tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5732>
<zyga> I'm just going to say this, whoever came up with the wrappers for golang in opensuse needs to do a reality check, it's the least useful wrapper I saw
<zyga> and this includes the previous ruby wrapper
<mvo> pedronis: I added the tests to a new PR and also updated the 5699 - should I add more before merging 5699?
<zyga> I'm giving up on this
<Caelum> zyga: so this happens on all architectures now
<cjwatson> niemeyer: hi
<Caelum> zyga: ok well, I'll take a look over the next few days
<zyga> ok
<Caelum> zyga: driving home from LA to san francisco now, take care
<zyga> safe ride home
<niemeyer> cjwatson: Heya
<niemeyer> cjwatson: How do we kick spammers and their comments out of Launchpad?
<niemeyer> cjwatson: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053/comments/100
<mup> Bug #1575053: Please move the "$HOME/snap" directory to a less obtrusive location <julyshakedown> <snapd:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1575053>
<cjwatson> niemeyer: done
<cjwatson> (https://answers.launchpad.net/launchpad/+addquestion is our preferred way to report spam)
<niemeyer> cjwatson: Thanks!
<niemeyer> cjwatson: Will use that next time
<cjwatson> thanks for the report, we obviously try to boot spammers out ASAP to minimise damage
<abeato> Wimpress, hey, do you know how can make snapcraft generate a manifest?
<zyga> ok
<zyga> small progress
<zyga> finally feels better than packaging
<baimafeima> hi does anyone know what's the difference in terms of security and user privacy when comparing snaps, flatpaks and appimages?
<zyga> baimafeima: it's complicated
<zyga> baimafeima: except maybe appimages that by default have no sandbox at all
<baimafeima> zyga, mhm so appimages could theoretically gather a lot of data as they are not sandboxed ...
<baimafeima> if I were to install a malicious snap or flatpak or appimage, through which could my system most easily be exploited?
<zyga> baimafeima: as appimage is not sandboxed in any way the answer is obvious
<baimafeima> zyga, what about snaps vs flatpaks? pros and cons?
<zyga> it's complicated
<baimafeima> zyga, let's say I have wayland and on the operating system side all the latest versions
<zyga> it's still very complicated
<zyga> it's not something that can be accurately described in a few moments
<baimafeima> zyga, does having reproducible builds apply to both?
<zyga> no, to neither
<baimafeima> zyga, I know snaps have a broader use case, IoT and such and distribution is centralized, whereas everyone can host their own flatpaks and it's more desktop-focused...
<zyga> baimafeima: perhaps it's not common knowledge but both systems cannot care less about how the package is built
<zyga> so any package can be built in any way really
<zyga> so some packages can be built with all the hardening and reproducible build tweaks
<zyga> while others can just contain a debug build from someone's lap
<baimafeima> zyga, so you basically suggest a snap is not a snap or a flatpak isn't a flatpak and I would still have to trust the developer on the quality of the packaging? So there are going to be hardened snaps and those that are not?
<zyga> baimafeima: with both systems you trust on whoever is making the package, yes
<baimafeima> is the reason to keep the entry barrier into snap or flatpak development low? or is there a way to enforce higher minimum standards below which a snap simply won't run?
<zyga> while many packages can be of good quality there is nothing that prevents anyone from making a bad quality package
<baimafeima> zyga, I see, then I would say a centralized distribution system like with snaps could have an eye on quality control whereas that wouldn't be easily possible with flatpaks?
<zyga> well
<zyga> what's the goal?
<zyga> linux packaging is hard
<zyga> linux market share is pretty much close to zero
<zyga> using the right helpers people will get (over time) better and better builds
<zyga> but you have to recognise that packaging is very hard as it is already
<zyga> with each distribution having complex policy
<zyga> and widely different levels of quality
<zyga> the point of snaps and flatpak is to make it better for developers and users
<zyga> that includes making it easier
<baimafeima> zyga, mhm I see, which distribution do you use to build and develop?
<zyga> we have plenty of bad outdated, buggy apps already
<zyga> and the existing policy system does not change that
<zyga> you can link the buggy and broken and old package with hardening options and use reproducible builds while you are at it
<zyga> but because it's hard and complex the upstreams cannot care less about that (I'm generalising obviously) and if they ever test something it is whatever they are running (probably not linux because of statistics)
<zyga> so in the end, we are hoping to make the process less complex so that more people have a better time at making apps
<zyga> and at using apps
<zyga> baimafeima: I use multiple operating systems
<baimafeima> zyga, interesting
<baimafeima> zyga, I remember (but cannot find the github issue) that there was a discussion regarding on-the-fly updates and whether there is a possibility for end-users to prevent a snap from updating itself and how this can be integrated into software centers with fine-grained control
<zyga> baimafeima: I wonder if statistically upstream developers still use compiled languages as a majority so reproducible builds and hardening probably apply a level below where people generally tend to code now
<zyga> baimafeima: there's a thread about that on the snapcraft forum I believe
<baimafeima> zyga, ah yeah I think it was on the forum, not sure whether it's been resolved by now
<zyga> baimafeima: it depends by what you mean, there's no universal agreement on what should happen
<baimafeima> zyga, it's a pity that there's not more commitment to reproducible builds
<zyga> baimafeima: it's a pity there's no more commitment to {useful APIs,documentation,stability,artwork,localisation,business friendliness}
<baimafeima> zyga, I think most end-users won't care but some care about the degree of control through the auto-update mechanism
<zyga> there are many dragons to fight
<abeato> sergiusens, , hey, do you know how can make snapcraft generate a manifest?
<baimafeima> zyga, thanks for the infos, I'll slowly read my way into this
<zyga> baimafeima: if you have specific questions I will be happy to answer them
<baimafeima> zyga, thanks
<zyga> brb
<zyga> re
<Son_Goku> baimafeima, reproducible builds aren't particularly valuable to most people
<Son_Goku> they've made that choice when they decided in their ecosystems that they attempt fetching from a VCS (nodejs, php, golang, etc.) rather than having releases upload a tarball (python, rust, c/c++, etc.)
<jdstrand> mborzecki, mvo: /etc/writable/hostname is *not* writable in interfaces/builtin/hostname_control.go
<zyga>  3085 1000000   20   0   70896  65316  38896 R 100.0  8.1   2:34.73 unattended+
<zyga> that's weird
<zyga> that's on a dragon board running core
<zyga> ah, that's inside a container
<mup> PR snapcraft#2227 closed: lxd: wait for cloud-init <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2227>
<mup> PR snapcraft#2228 opened: storeapi: handle releasing to curly braced branch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2228>
<ogra> hmm ... when i "snap stop" a service from a snap and the snap gets refreshed, the service gets automatically started again
<ogra> is that expected (not by me for sure, but is it expected y the implementation ?)
<ogra> *by the
<Chipaca> ogra: yes
<Chipaca> ogra: or, no
<Chipaca> ogra: â¦ maybe?
<Chipaca> ogra: 'snap stop' does not imply 'snap disable'
<Chipaca> ogra: i mean, snap stop --disable
<Chipaca> which is different from snap disable, of course
<pedronis> mvo: btw assertions not only have revisions, but also format (an increasing version of the format), in theory we could also play with that (so far we have incremented it only for snap-declaration)
<mvo> pedronis: oh, interessting idea
<pedronis> mvo: snapd always sends the max-format it supports when asking for assertions
<pedronis> anyway another thing
 * mvo nods
<ogra> Chipaca, well, can i disable single services and not the whole snap ? i thought disable completely turns off the whole set
<pedronis> mvo: to be clear it's per assertion type, is not global
<Chipaca> ogra: 'snap disable' is snap-level; 'snap stop --disable' is service-level
<mvo> pedronis: ta
<ogra> Chipaca, aaah !! thanks
<zyga> re, hasty day, quick lunch done
<sergiusens> abeato: hey, sorry, I saw your question pop-up but was super focused on code reviews. So you want SNAPCRAFT_BUILD_INFO (also reminded under recording here https://github.com/snapcore/snapcraft/releases/tag/2.43)
<abeato> sergiusens, ok, so that is just an env var, right? is it considered experimental still?
<sergiusens> abeato: no, not experimental, it is being used by USN already
<abeato> sergiusens, got it, thanks
<mup> PR snapd#5733 opened: snap/squashfs: improve error message from Build on mksquashfs failure <Created by chipaca> <https://github.com/snapcore/snapd/pull/5733>
<mup> PR core#94 closed: hooks: improve /etc/alternatives unwinding <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/94>
<mvo> fwiw, I'm looking at the core16 degraded boot failure right now
<zyga> mvo: flashing dragon now
<zyga> mvo: I'm done with meetings today
<abeato> sergiusens, can you force creation of the manifest in snapcraft.yaml file?
<sergiusens> abeato: we have no language for that. Maybe create a forum post requesting it.
<abeato> sergiusens, ok
<sergiusens> abeato: fwiw, I do agree we need a way to opt-in/opt-out
<sergiusens> but it is one of those where agreeing on the syntax for it is the larger discussion:-)
<abeato> haha
<abeato> ok
<abeato> sergiusens, https://forum.snapcraft.io/t/no-way-to-create-manifest-from-snapcraft-yaml/7076
<cachio> zyga, hey
<cachio> https://paste.ubuntu.com/p/y2p6byKthP/
<cachio> I saw this error
<zyga> right
<zyga> I don't know why it happens
<zyga> I saw the pastebin before
<cachio> zyga, ok :(
<zyga> there's clearly a bug but we don't have a firm understanding if this is a bug in systemd or in the kernel
<zyga> or in some intermediate libraries
<cachio> zyga, nice, I'll continue researching
<zyga> there's a thread that has some information about this
<zyga> if you find out anything please add it there
<xnox> mvo, so you went and fixed something for which you already had a universal pam script for without fixing the issue we hit with cloud-sdks shipped as snaps =)
<xnox> mvo, can we talk about https://github.com/snapcore/snapd/pull/5226 again? i posted the comment there.
<mup> PR #5226: data: add systemd user environment generator <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5226>
<xnox> mvo, is the test case still not clear which environment is still wrong and still does not contain /snap/bin
<zyga> mvo: booting your image now
<zyga> I had some SD card woes
<zyga> (apparently that silly lock switch does something)
<zyga> it errors with: /usr/share/subiquity/console-conf-wrapper: line 13: snap: command not found
<zyga> I'm in interactive uboot prompt
<zyga> mvo: just let me know what you need when you're back
<zyga> mvo: I applied: env set snappy_cmdline net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc systemd.debug-shell=1
<pstolowski> zyga: hey, got a moment for quick HO?
 * cachio lunch & doctor
<blackboxsw> nice sergiusens: on cloud-init status --wait. :) per the above lxd: wait branch.
<blackboxsw> glad to see consumers of that blocking wait
<mvo> xnox: I'm checking your comment and will reply
<xnox> mvo, thanks
<mvo> zyga: yeah, that might not be sufficient to get a shell
<mvo> xnox: aha, so we need a *system* env generator. is there such a thing? pardon my ignorance on this
<mvo> xnox: anyway, I will investigate
<xnox> mvo, well the generator is that.
<xnox> mvo, we already had user thing already anyway
<xnox> mvo, via the legacy script that we did
<mvo> xnox: ok
<mvo> xnox: so we ship a systemd system env generator but its not picked up, that is the issue, correct?
<xnox> mvo, no you never shipped it
<xnox> mvo, you proposed it and then did not merge....
<xnox> mvo, and decided that you need environment.d snippet and that's it.... but you didn't need that one at all
<xnox> cause you already had the pam.d thing already (the shell script thing)
<xnox> mvo, maybe we need a hangout?
<sergiusens> blackboxsw: heh, I wish I'd known about that sooner, I had implemented my own poller looking at the cloud init status file
<xnox> mvo, so the /etc/profile.d/apps-bin-path.sh & /usr/lib/environment.d/990-snapd.conf are redundand.
<mvo> xnox: oh, now I remember, sorry, it was a while. ok - I think I know what is going on, I missed the difference between the two
<mvo> xnox: the difference between environment.d and a generator
<xnox> mvo, well profile.d is used by pammy / more traditional things; and the latter one is used by recentish systemd things for /logged in users/
<blackboxsw> sergiusens: mea cupla. /me needs to figure out how to better advertise nice CLI features... I dump updates in here https://cloudinit.readthedocs.io/en/latest/topics/capabilities.html#cli-subcommand-details, but I'll make sure to rope someone snappy in on next round of changes that could affect folks.
<xnox> mvo,  the /usr/lib/environment.d/ is read by /usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator for the logged in users.
<mvo> xnox: thanks, I know now what to do - sorry for this
<mvo> xnox: I will resurrect the system env generator
<xnox> mvo, that's ok. it is confusing, and most things are named identical.
<xnox> or very similar
<xnox> mvo, dammit can't find the docs now.
<sergiusens> blackboxsw: no worries, I only found out about that status file by a google/ddg search that led to a bug report from 5 years ago iirc where scott mentioned he'd implement it; look at the code a bit, saw it was there for the series we needed it and just went ahead and did what needed doing
<sergiusens> documentation is hard :-)
<mvo> xnox: no worries, I will resurrect the PR tomorrow
<mvo> xnox: thanks for the heads up!
<xnox> mvo, cool thanks!
<xnox> mvo, it would be nice to have a direction.d thing for system envrionemnt too, but there doesn't appear to be one, hence the need of a executable generator for the system one.
<xnox> (systemd doesn't pre-ship one, the way it does a user generator)
<blackboxsw> sergiusens: as a heads up, I know snappy also looks at instance-data.json we'll shortly have a 'cloud-init query' subcommand which allows one to query the struct without having to parse the data file directly. Some of those query changes will also surface improved 'region' detection on a couple of clouds. I'll add you as a reviewer when that branch is up, just for a glance to see if it's of interest.
<sergiusens> blackboxsw: heh, well the person you want to reach out to is mvo; I personally work on only snapcraft these days
<blackboxsw> +1 thx
<sergiusens> my snapd days ended almost 3 years ago :-)
<zyga> pstolowski|afk: now yes
<zyga> mvo: I can tinker perhaps enough to get a Getty
<mvo> zyga: good luck
 * zyga just states for the record that we have some idea why the dragon image is not working
<mup> PR snapd#5734 opened: tests: remove /etc/alternatives from dirs-not-shared-with-host <Created by mvo5> <https://github.com/snapcore/snapd/pull/5734>
 * zyga EODs
 * zyga likes https://commit.style/
<mup> PR snapcraft#2226 closed: templates: reimplement templates as python classes <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2226>
#snappy 2018-08-29
<dave_uy> How do you add a license for a publish snap?
 * Son_Goku hates his life right now
<Son_Goku> my air conditioning died, so now it's nearly 35C in my house
<mborzecki> morning
<zyga> Good morning
<mborzecki> zyga: hey
<zyga> :)
<mborzecki> mup is quiet again?
<mborzecki> https://github.com/snapcore/snapd/pull/5735
<mborzecki> simple one ^^
<mborzecki> mvo: hey
<mvo> hey mborzecki
<zyga> mvo: good morning
<mvo> looking
<mvo> good morning zyga
<zyga> mvo: that issue from last evening, the journal included sigsegv
<zyga> not sure if you noticed that
<mvo> zyga: thanks for the log from last night  I think I know now what is going on
<mvo> zyga: yeah, console-conf
<mvo> zyga: but the key was the error from snap-repair \o/
<zyga> oh?
<zyga> can you explain?
<mvo> zyga: part of the "bootstrap" of snapd itself is to start its services
<mvo> zyga: if one of them fails the bootstrap fails
<mvo> zyga: and snap-repair is failing apparently because it has no network
<mvo> zyga: so the fix is probably as simple as making this non-fatal (which it is - I mean, it should be :)
<zyga> ah, I see
<pstolowski> morning
<mborzecki> pstolowski: o/
<mvo> hey pstolowski ! good morning
<mvo> zyga: if I could get a review for 5734 master should be good again
<mvo> zyga: right now tests are failing there because of the latest core snap changes
<zyga> mmm
<zyga> doing now
<zyga> mvo: question
<mvo> zyga: ta
<zyga> mvo: what shall we do with snapd code that groks alternatives, in a world with core18 and core16 and snapd there is no way to "depend" on the right build of core in snapd snap (or vice versa)
<zyga> if I kill the small bit of code that handles alternatives in snap-confine and people upgrade the wrong way they will see old core with alternatives symlinks and nothing to handle that in s-c
<zyga> shall I remove that code or just wait until nobody reasonably will be on the old snapd
<mvo> zyga: if we find /etc/alternatives we keep doing what we are doing today
<mvo> zyga: and once we have epochs we drop it
<zyga> mvo: ah, so only after epochs
<zyga> that was the answer I was looking for, thanks!
<mvo> zyga: we can add a note in the code though
<mvo> zyga: we *could* keep the test alive using ubuntu-core
<zyga> ack
<mvo> zyga: which never changes
<mvo> zyga: I mean, the spread that we just removed
<mvo> zyga: but I think its fine
<zyga> nah
<zyga> I think it's fine
<mvo> :) agreement!
<t1mp> hello
<zyga> hello
<t1mp> is there a recommended way to get python 3.6 or 3.7 in a snap? Xenial comes with 3.5...
<zyga> You can use base: core18 to use ubuntu 18.04 as a base
<zyga> or you can build python from source as a part
<zyga> but I think using the base is easier
<t1mp> yes, I prefer not to spend the time to build python from source
<t1mp> right, I'll try core18. I thought that xenial was basically always the base image
<t1mp> maybe then it is also time to upgrade my laptop, so that I have the same environment everywhere :)
<t1mp> well, I use docker anyway
<t1mp> zyga: thanks
<zyga> t1mp: you can now choose out of two stable bases
<zyga> t1mp: with more coming
<zyga> t1mp: obviously anyone can run all the snaps regardless of the base they use :)
<t1mp> zyga: True. But for testing my python lib, and building the snap (I'm not using cleanbuild) locally it is nice to have the same environment
<zyga> yeah, I agree
<zyga> well, good luck :-)
<t1mp> well, for testing the python code locally I use miniconda anyway.
<Chipaca> pedronis: thank you for the review! :-D
<Chipaca> pedronis: I'll look at writing that test asap
<pedronis> Chipaca: thx, I think that's how abort should work without lanes but IÂ might be misremembering anyway my point was also about the comment
<Chipaca> pedronis: yep, i'll add a comment also
<zyga> Chipaca: question for you sir
<Chipaca> zyga: the answer is that it was working that way when I found it, all I did was pick it up and put it somehwere dry, honest ociffer
<zyga> what's the factor that chooses * over â https://www.irccloud.com/pastebin/EYj3TrPi/
<Chipaca> zyga: canUnicode is true, assuming --unicode=auto, if the first one of LC_MESSAGES, LC_ALL, or LANG that is set has "UTF-8" or "UTF8" in it (case-insensitively)
<zyga> hmm
<zyga> interesting
<Chipaca> zyga: I say "set" but I mean "set and non-empty", fwiw
<zyga> Chipaca: this test works/fails depending on suse version
<zyga> missing mocking?
<Chipaca> zyga: I don't think so, but, maybe?
<zyga> or maybe broken mocking, I'll re-trigger
<Chipaca> zyga: maybe you're on to somehting with the mocking
<zyga> Chipaca: the log comes from obs
<Chipaca> zyga: I think we set LANG=UTF-8 in our run
<Chipaca> er, C.UTF-8
<Chipaca> it's a regexp, we could change it to accept either :-)
<zyga> yes, something for .1
<zyga> I'll fix that
<Chipaca> the smile is because it'll be a fun regexp
<Chipaca> [*â]
<Chipaca> :-)
<Chipaca> zyga: but, there should be a bunch of other tests failing in the same way
<Chipaca> or similar
<zyga> mmm
<Chipaca> zyga: 'snap info' output for ex
<Chipaca> zyga: (not just publisher but the channel map will be different on non-utf8)
<Chipaca> I _nearly_ succumbed to the temptation of working on widths this last vacation
<Chipaca> but i resisted! i can do it in my 20% time if i ever do
<zyga> 3 tests left
<zyga> 2945 tests passed with my patch :)
<pstolowski> zyga: hey, got a moment for HO?
<zyga> yes
<zyga> I saw your ping last evening
<zyga> but I was on a walk then
<zyga> let's HO
<zyga> can you send me the link pelase
<zyga> *please
<pedronis> pstolowski:  I reviewed the sublevel PR with some comments
<pstolowski> pedronis: thank you!
<mborzecki> E: Failed to fetch http://us-east1.gce.archive.ubuntu.com/ubuntu/dists/xenial-updates/universe/binary-amd64/Packages.xz  Hash Sum mismatch
<mborzecki> heh
<ogra> zyga, mvo is it true that you want to hide base snaps from "snap list" output ? if so, will there be an exception from this on Ubuntu Core (how would i find out the version of my rootfs otherwise ?)
<zyga> ogra: snap list --all or something will show more things
<zyga> but I see your point
<zyga> maybe on core we should show the boot snap
<ogra> yeah
<ogra> we often have customers digging through CVEs for example ... for that they need to know what rootfs revision they run etc
<ogra> or perhaps add a --show-base option that lists them again
<ogra> (i dont really care about the impleentation but the info is valuable on core)
<zyga> ogra: I don't know what the exact argument to show / hide this would be but I think we agreed to have some
<ogra> ah, cool, as long as seeing them somehow is still possible all is fine ...
<mvo> xnox: so about the systemd env generator - i have put a PR up but it does not work and I am a bit lost about the why. setting env vars works just fine. as long as the env is not PATH. now the sad part is that even the man-page talks about reording path so I would assume systemd itself is fine but something we customize is probably not fine. any ideas? I am poking at the code and it looks like it applies DEFAULT_PATH for un
<mvo> known reasons and nothing in the (manager) code stands out as strange
<pachulo> afternoon everyone! Is there any roadmap for core18 snap somewhere? Right now is 0.1 but the beta & edge channels revisions weight as twice as the one in the stable & candidate channels...
<popey> pachulo: https://forum.snapcraft.io/t/the-road-to-core18/5547  this do?
<pachulo> ok, yes, forgot about it, thanks popey !
<cachio> mvo, hey, I got +1 to go to stable with 2.35
<mvo> cachio: did you had a chance to check with sergiusens  if there will be any issues from his side if we go to stable with 2.35?
<cachio> mvo, no, I'll do it today
<mvo> cachio: thank you!
<cachio> mvo, yaw
<cachio> sergiusens, please tell me which test we should do to validate snapcraft with the core 2.35
<cachio> mvo, I am leaving in 10 minutes, I'll ping you once I am back
<mvo> cachio: sure, no worries
<mvo> xnox: fwiw, just tested the same behavior on fedora28 with systemd 238 so might be an upstream bug
<Chipaca> niemeyer: how do I 'fork' a comment into its own topic? For https://forum.snapcraft.io/t/where-is-a-snap-stored-and-how-can-i-change-that/3194/10?u=chipaca
<niemeyer> Chipaca: Click on the wrench or gear (whatever it is) for the topic, and there should be an option there which will allow you to select the topics to split
<Chipaca> niemeyer: https://imgur.com/xt0xCgS
<niemeyer> Hmm
<niemeyer> Chipaca: This is the post menu
<niemeyer> Chipaca: At the bottom of the post there should be a topic-general one
<Chipaca> ah, for the _topic_
<niemeyer> Yeah
<Chipaca> niemeyer: yup! found it, thanks!
<niemeyer> np
<Chipaca> I plague of radioactive locusts on all randomly-failing tests
<Chipaca> s/I/A/
<zyga> re :)
<zyga> useful call with mborzecki
<mborzecki> zyga: yeah, nice stuff
<zyga> mborzecki: wrote that comment now
<mborzecki> zyga: thanks
<sergiusens> cachio, mvo: "snap install snapcraft --classic && snap install lxd && cd $(mktemp -d) && snapcraft init && snapcraft cleanbuild"
<ogra> sergiusens, lxd init ? not needed anymore ?
 * Chipaca ~> lunch
 * Chipaca ~> hopefully lunch cor real this time
<sergiusens> ogra: yes you do, "lxd init --auto" should cover that
<mborzecki> zyga: mvo: shall we land https://github.com/snapcore/snapd/pull/5720 ?
<sborovkov> Hi, what does this mean? automated review rejected the snap
<sborovkov> Failed to run click-review properly. click-review
<sborovkov> I can't even reupload it because automated review rejects with that dumb error that makes zero sense to user
<mvo> debugging why systemd env generators do not work for PATH
<pedronis> sborovkov: there's been a regression on how review tools results are being handled, it should be getting fixed
<sborovkov> pedronis: is there any workaround
<sborovkov> ?
<pedronis> sborovkov: I think once the fix is out it should be possible to re-run things and get the proper result and go from there
<zyga> mborzecki: yes, I see it was merged now
<pedronis> out in the store
<zyga> mvo: hey
<zyga> mvo: about that :)
<pedronis> sborovkov: roadmr can probably say more when he is around
<zyga> mvo: I have a question related to PATH
<zyga> mvo: (also systemd env generators were made for PATH so if they don't work it's a bit unexpected)
<sborovkov> pedronis: ok, thanks.
<zyga> mvo: on my quest to kill --with-snap-mount-dir I reached 990-snapd.conf.in
<mvo> zyga: yeah, its super annoying
<mvo> zyga: what is your question?
<zyga> mvo: maybe we can ask Zbyszek about it (he implemented them)
<zyga> mvo: can we simply add both /snap/bin:/var/lib/snapd/snap to PATH
<mvo> zyga: do you know him?
<zyga> mvo: so that we have one set of files
<zyga> mvo: yes
<zyga> mvo: I met him at flock and he lives nearby
<mvo> zyga: I was trying to build a test case first before I bother upstream
<zyga> mvo: he invited me to co-work with him on snapd topics in fedora yesterday but $meeting_frenzy
<mvo> zyga: but even that is hard :/
<mvo> zyga: woah
<mvo> zyga: ok, that sounds great
<zyga> mvo: yes :) he's super nice
<zyga> since he wrote this feature we may just ask
<zyga> but ideally we'd have a reproducer that we can show him
<zyga> (something trivial like a shell script that ECHOs one path)
<zyga> mvo: so since we are looking at the same file now, how can I reproduce the problem?
<sborovkov> pedronis: or is there anyone who i can ask to set it to the accepted state? since it's a branded store it should not be an issue
<mvo> zyga: reproducer is really just "#!/bin/sh -ex; echo "PATH=$PATH:/snap/bin" ; echo "OTHER_ENV=foo"
<zyga> ok
 * zyga adds that and reboots
<zyga> do I need to reboot?
<mvo> zyga: and when I daemon-reload and run "systemd-run --unit testenv; journalctl -u testenv"
<mvo> zyga: no
<mvo> zyga: just daemon reload
<zyga> ok, one sec
<mvo> zyga: let me write a shell script
<mvo> zyga: so that its bullet-proof
<mvo> zyga: and then we can share it
<zyga> -rw-rw-r--  1 zyga zyga   32 Aug 24 14:00 990-snapd.conf.in
<zyga> we drop the .in file !?!
<zyga> not the .conf file
<mvo> zyga: wuuut?
<zyga> mvo, could that be it :D
<zyga> yep
<zyga> look at your disk
<mvo> zyga: no, thats not it
<mvo> zyga: I mean that is a problem but that is not related to the systemd env stuff I was poking at this morning
<zyga> hm, something dropped .in on my disk
<mvo> zyga: anyway, I make a reproducer script
<zyga> k
<mvo> zyga: and ping you
<zyga> the in file is not from dpkg
<zyga> how. I got it now
<zyga> it's from august 24
<zyga> anyway
<pedronis> sborovkov: if it's a branded the store somebody on your team should have permissions to do that , but if the review-tools failed there might something off for real with the snap
<sborovkov> pedronis, hmm, so we can override automatic review? my previous snap version was uploaded and review went fine. diff shows that there is no difference in snapcraft.yaml besides snap version
<mvo> zyga: please try http://paste.ubuntu.com/p/pjMyGZ7RsR/
<zyga> mmm
<pedronis> sborovkov: there are checks on version too?  what does version look like ?
<mvo> zyga: hm?
<zyga> nothing, just "mmm, trying" (ack)
<zyga> I heard you :)
<mvo> zyga: ta
<mvo> zyga: sorry, misread :)
<pedronis> sborovkov:  the first is not a question,  there are checks on version too since a while
<mborzecki> mvo: it doesn't work?
<mvo> mborzecki: it does
<mvo> mborzecki: *but*
<mvo> mborzecki: not for PATH
<mborzecki> hm
<mvo> mborzecki: it looks like something overrides that later again
<zyga> https://www.irccloud.com/pastebin/KGyqwVCZ/
<mborzecki> mvo: can you rename it to 99-test.sh ?
<mvo> mborzecki: when I set PATHxxx=$PATH:/snap/bin I see a (very) different path
<mvo> mborzecki: sure, let me try that
<sborovkov> pedronis, I mean in the snapcraft.yaml I just bumped the version from 1.0.19 to 1.0.20. Error from the tools is very weird Failed to run click-review properly. click-review
<pedronis> something seems strange
<Chipaca> niemeyer: I was actually considering runing delete on loading the warnings
<Chipaca> niemeyer: I'll look into prune though, that might be better (or maybe both)
<pedronis> sborovkov: do you have  a dot at the end of the version by chance or something else odd with the version line
<Chipaca> niemeyer: note the current impl doesn't delete anywhere
<mvo> zyga: hold on
<pedronis> sborovkov: is this a large snap?
<mvo> zyga: the script has at least one bug, let me fix this first
<zyga> mvo: I have some interesting findings from tinkering
<zyga> k
<mborzecki> mvo: for eg. here on arch i have 10-arch which overrides PATH
<sborovkov> pedronis, no. it is a large snap yes
<sborovkov> version is set to 1.0.20
<pedronis> sborovkov: ok, either way we need somebody that can look around in the store (which I can't)
<zyga> mvo: what's testenv?
<niemeyer> Chipaca: Yeah, Prune seems perfect for that.. it's already multi-purpose, and has the goal of GCing
<mvo> zyga: http://paste.ubuntu.com/p/JnmTrjpWsP/
<zyga> ah, 'EOF' is key
<mvo> zyga: its just a systemd unit that runs the "env" command
<mvo> zyga: yeah, sorry
<zyga> mvo: where is testenv defined?
<zyga> systemctl cat doesn't know about
<zyga> about it
<mvo> zyga: systemd-run --unit testenv env
<mvo> zyga: thats what creates it
<zyga> ahh
<zyga> I see
<mvo> zyga: I can add -k
<zyga> neat
<mvo> zyga: to keep it running
<zyga> mvo: does systemd-environment-d-generator matter?
<zyga> mvo: I have an idea!
<zyga> one sec
<pedronis> sborovkov: I saw you opened a topic,  I will ping somebody that can look when they are around
<mvo> zyga: tell me more please
<sborovkov> pedronis, thanks
<zyga> there's a built-in generator that reads /etc/environment.d
<zyga> and it is stated that generators can mutate the environment for future generators
<zyga> so perhaps what happens is that we do something but then the default generator just overwrites PATH
<zyga>        The environment.d directories contain a list of "global" environment variable assignments for the user environment.  systemd-environment-d-generator(8) parses them
<zyga>        and updates the environment exported by the systemd user instance to the services it starts.
<mvo> zyga: standup :)
<mvo> zyga: /etc/environment.d is empty for me
<zyga> I have 999-snapd.conf there because I'm running dpkg -i'd master
<mvo> zyga: but even that is ok, no?
<mvo> zyga: i.e. nothing in it overrides PATH
<zyga> Aug 29 15:03:52 fyke env[45277]: MAGIC=canary
<zyga> Aug 29 15:03:52 fyke env[45277]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
<zyga> Aug 29 15:03:52 fyke env[45277]: ALT_PATH=/sbin:/usr/sbin:/bin:/usr/bin:/it-worked
<mvo> zyga: anyway I was also able to reproduce this in fedora
<zyga> echo "ALT_PATH=$PATH:/it-worked"
<zyga> echo "PATH=$PATH:/it-worked"
<zyga> echo "MAGIC=canary"
<mvo> zyga: but that was on our fedora (google image)
<mvo> zyga: so same issue, right?
<zyga> I'm testing on bionic locally
<zyga> yes
<zyga> but look that ALT_PATH is ok
<zyga> but still contains _different_ value
<zyga> so this smells like something else (pam?) changing everything
<zyga> compare
<zyga> : /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin vs /sbin:/usr/sbin:/bin:/usr/bin
<mvo> zyga: yeah
<mvo> zyga: the latest reproducer also uses PATH in the OTHER_ENV to show that
<zyga> the first is PATH , the other is ALT_PATH sans the it-worked directory
<mvo> zyga: so yeah, something is fishy
<zyga> so
<zyga> grep for /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
<zyga> that's the one we get
<mvo> zyga: well, grep for that in the systemd source ;)
<mvo> zyga: it is also the #define DEFAULT_PATH there
<mvo> zyga: its slightly more complicated there because it has it split up for combined /usr,/ and not but afaict its the same as we have in /etc/environment
<zyga> it's all broken
<zyga> look at this
<mvo> zyga: I also moved /etc/environment away and tried with that
<zyga> https://www.irccloud.com/pastebin/FnDZ58Y1/
<mvo> zyga: no difference, but maybe I need to reboot
<zyga> the value in /etc/environment is _different_, it has /usr/games as well that we don't see
<zyga> the one in login.defs matches
<mvo> zyga: aha, I actually moved it away /etc/enviornment and still the same issue
<zyga> let me grep elsewhere
<mvo> zyga: yeah, I commted that out
<mvo> zyga: same issue
<mvo> zyga: I think its internal somehow but maybe I'm wrong
<zyga> I did a grep in /usr
<zyga> and ... nothing sensible
<zyga> nothing in systemd
<zyga> or libraries
<zyga> https://www.irccloud.com/pastebin/WKOrsDWb/
<zyga> mvo: /bin/slogin or /bin/rlogin
<zyga> are those used?
<zyga> ah, I didn't grep in /lib
<mvo> zyga: https://github.com/systemd/systemd/blob/54fe2ce1b943b55162cc35b28e976c4fbf490dae/src/basic/path-util.h#L26
<zyga> it's internal https://www.irccloud.com/pastebin/NI6HRX6J/
<mborzecki> mvo: your test script has the same issue here on systemd 239
<mvo> mborzecki: something also overrides path for you? yeah, I think we need zyga  to talk to upstream
<zyga> some more fun with PATH
<zyga> I'll share my script
<mvo> zyga: anything interessting?
<zyga> mvo: yes
<zyga> so, some more context needed
<mvo> zyga: does it work?
<zyga> wanna HO?
<zyga> https://hangouts.google.com/call/-0nioHSGU_Bqe5rpEuYaAAEI
<xnox> mvo, yo! re the testing.
<xnox> mvo, you do need to reboot...
<xnox> cause manager.c doesn't really rerun system generators on reload/re-exec, or at least I do not see it do that.
<cachio> sergiusens, hey, I got this https://paste.ubuntu.com/p/BCyssdQKTZ/
<mvo> xnox: I think reboot does not help and afaicts it does re-run the generators, I did "strace -f -p 1 -e trace=execve -s256 -v" and I can see daemon-reload running my generator
<mvo> xnox: but let me try to reboot just to be one the safe side
<sergiusens> cachio: try again, but "snap refresh snapcraft --edge" first.
<mvo> xnox: http://paste.ubuntu.com/p/JnmTrjpWsP/ <- fwiw - my reproducer
<sergiusens> that should come out as soon as this ends https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-43/7024
<mvo> xnox: but *maybe* it runs the generator just does not pick it up
<sergiusens> for which I was hoping more interaction with, but oh well.
<mvo> xnox: anyway, trying to reboot now
 * zyga had lunch and needs a small break
<mvo> xnox: ohhh, it looks like the reboot helped, let me try this again on a clean system (cc zyga)
<zyga> mvo: hold on, I rebooted _doen_ times
<zyga> mvo: what did you get?
<mvo> zyga: oh
<zyga> *dozen*
<zyga> mvo: did you get PATH changed?
<xnox> mvo, i think daemon-reexec may be sufficient, deamon-reload would not be.
<xnox> mvo, note that system-environment-generators are not available in xenial
<xnox> mvo, i need this in bionic and up, .deb package...
<zyga> http://paste.ubuntu.com/p/DGKWqtQvZW/
<xnox> mvo, such that on classic systems things are right.
<zyga> that's what I ran
<xnox> and on core18
<mvo> xnox: yeah, I'm testing this on bionic
<mvo> zyga: yes http://paste.ubuntu.com/p/Sr2BMvh8fq/
<mborzecki> zyga: spread test for parallel instances and the content interface https://paste.ubuntu.com/p/qh33dy9j3W/ basically install some instances, poke data here and there, verify that it's written and visible everywhere
<mvo> zyga: I'm trying inside spread now
<xnox> mvo, zyga $ systemclt daemon-reexec
<zyga> mvo: can you add /foo or something like that and check if that is pickedu p
<mvo> zyga: I messed around quite a bit with my system
<xnox> not just daemon-reload....
<zyga> k
<mvo> xnox: cool, will try that
<zyga> I'll check
<zyga> mborzecki: ack
<mvo> zyga: yeah, its strange
<mvo> xnox: also the documentation is a bit misleading: "After installing new generators or updating the configuration, systemctl daemon-reload may be executed. This will re-run all generators, updating environment configuration. It will be used for any services that are started subsequently." (from the systemd.environment-generator man page)
<mvo> xnox: but yeah, running inside spread now, hopefully that was it :)
<cachio> sergiusens, https://paste.ubuntu.com/p/sqb3YRpZSH/
<cachio> sergiusens, am I doing somthing wrong?
<sergiusens> cachio: is the store down? that is basically "snap install core" failing on lxd
<xnox> mvo, yeah that's lies.
<mvo> xnox: :( thanks for confirming
<xnox> mvo, * but will not affect running units, units that are starting or stopping, failed units, or things that have been loaded already, or manager instance env will not be updated and so on and so forth
<xnox> is closer to truth
<zyga> mvo: because of the fact that the test cleans up after itself my rebooting was not a factor
<cachio> sergiusens, it is not
<mvo> zyga: ohhhhh
<mvo> zyga: ok
<cachio> I though it was a problem on my network config
<mvo> zyga: I updated the spread test
<sergiusens> cachio: try installing core on a "lxc launch ubuntu:xenial" lxd instance
<sergiusens> it might be your network, did you "sudo lxd init"?
<xnox> mvo, zyga - basically we need to affect the internal structure of manager object, which does load /etc/systemd/system.conf and stuff from the generators, but from then on it keeps on serializing state and keeping it persistent even across re-execs. Thus to be sure, we need a reboot, such that manager object loads things correctly upon initial exec.
<xnox> i mean, i can fix manager.c to be better, but that will not help with upgrades =) and by the time we rebooted once we should be tip top =)
<cachio> trying
<cachio> sergiusens, let me try it
<mvo> xnox: does https://github.com/mvo5/systemd/commit/9040e581561d920d3ba4ee0e01661392985c4bf6 look sensible?
<mvo> xnox: just so that the next guy does not have this misleading experience
<mvo> xnox: actually that did not work in my clean test env - trying the full reboot now
<xnox> mvo, i think they will want an issue that adding system generator, things do not change, after daemon-reload/rexec.
<xnox> mvo, reading the code i see that it does re-run generators; but then does deserialize; thus wiping the results of generators.
<xnox> mvo, imho it should run generators; deserialize; re-run generators again
<mvo> xnox: +1 for that
<mvo> xnox: I can file a bug, its easy enough to reproduce
<xnox> mvo, yeah, and look at manager_reload function in manager.c
<mvo> xnox: in a meeting now
<xnox> and point out that probably manager_deserialize wipes out the result of manager_run_environment_generators earlier
<xnox> ack
<mvo> xnox: thanks, will do
<mvo> xnox: (in a meeting now)
<eraserpencil> Hi guys, I'm following the official docs and guide https://blog.ubuntu.com/2017/06/28/build-test-and-publish-snap-packages-using-snapcraft, but I cant seem to get it to work.
<eraserpencil> i'm having trouble creating the docker instance
<cachio> sergiusens, I had to reinstall lxd
<cachio> sergiusens, it worked las executino
<cachio> so, do I need to do something else?
<sergiusens> cachio: on edge? ok that should be released tomorrow
<cachio> sergiusens, yes, https://paste.ubuntu.com/p/H8ghgN6Pmw/
<cachio> this is the log
<cachio> jdstrand, could you please take a look to the error in #5722
<sergiusens> cachio: ð
<cachio> sergiusens, nice
<jdstrand> cachio: ok
<cachio> jdstrand, tx
<mvo> Chipaca: review for 5731 would be great, should be trivial
<cachio> mvo, checked with snapcraft
<cachio> so I'll make the promotion if its ok for you
<cachio> I need to check with the store guys for sure
<mvo> cachio: yay
<Chipaca> mvo: hmm. That's a query old gnome-software would do IIRC
<mvo> Chipaca: do we support that query?
<mvo> Chipaca: I looked at the source and could not see we handle unknown
<Chipaca> mvo: we should not fail on it
<mvo> Chipaca: or am I not looking hard enough
<Chipaca> I think all the test is checking is that we don't fall over
<Chipaca> source is supposed to be A or B, but if it's C, don't panic
<Chipaca> something like that
<mvo> Chipaca: well, I think the test is wrong in any case, if you run it in isolation it fails
<Chipaca> mvo: I'll take a look later, if that's ok
<mvo> Chipaca: totally
<Chipaca> mvo: where does the test come from? i don't have it on master
<mvo> Chipaca: wuut? not in master. its from 2016
<Chipaca> grep -r TestSnapsInfoUnknownSource -> nothing
<Chipaca> on master here
<mvo> git grep TestSnapsInfoUnknownSource
<mvo> daemon/api_test.go:func (s *apiSuite) TestSnapsInfoUnknownSource(
<Chipaca> I get nothing for the same query :-(
<Chipaca> what's going on
<Chipaca> mvo: where is it in this: https://github.com/snapcore/snapd/blob/master/daemon/api_test.go
<zyga> mvo: so what's the bottom line, daemon reexec or bug in manager?
<Chipaca> Author: Michael Vogt <mvo@ubuntu.com>
<Chipaca> Date:   Tue Aug 28 12:31:46 2018 +0200
<Chipaca>     daemon: remove TestSnapsInfoUnknownSource
<Chipaca>     
<Chipaca> mvo: you removed that one yesterday
<Chipaca> mvo: in 22cbc462724b9ee7ef42fe0b768981773e6b95bb
<mvo> Chipaca: uhhh, ok
 * Chipaca hugs mvo 
<mvo> Chipaca: sounds like the pr needs to change then
<mvo> Chipaca: and I need to re-add it so that we can inspect it
<Chipaca> mvo: leave it as is for now
<Chipaca> mvo: I'll think about it and we can talk tomorrow
<mvo> Chipaca: +1
<Chipaca> mvo: it worries me that you're forgetting what you did yesterday :-/ you ok?
<mvo> Chipaca: i am - but maybe a bit too spread out recently :(
<Chipaca> mvo: take care
 * Chipaca afk for a bit for same
 * mvo hugs Chipaca 
 * Chipaca hugs back
<pedronis> Chipaca: what happened I think is that https://github.com/snapcore/snapd/pull/5732 was merged that included the removal PR
<cachio> mvo, 2.35 is stable
<mvo> cachio: thank you!
<cachio> mvo, yaw
 * zyga ->walk
<Chipaca> pedronis: what surprised me was that the new pr didn't conflcit
<pedronis> Chipaca: it was older than one that merged
<pedronis> *than the
<pedronis> Chipaca: out-of-order merging
<Chipaca> pedronis: All I hear is 'github r dumb'
<pedronis> Chipaca: github doesn't care afaik,  if you create a chain of 10 PR and merge the last one, you get everything in
<pedronis> nothing stopping you
<Chipaca> pedronis: right, but at that point why doesn't it mark the merged ones somehow
<pedronis> as implicitly merged?
<pedronis> it doesn't know, it tracks the to be merged branch, not the target
<Chipaca> pedronis: well it does something to detect conflicts
<Chipaca> pedronis: i'm sure the same something can detect nops
<pedronis> probably
<Chipaca> pedronis: OTOH, Â¯\_(ã)_/Â¯
<pedronis> it doesn't seem they care supporting chain of PRs
<pedronis> it's not a thing it seems for their pov
<ogra> zyga, what ever happened to the non-apparmor side of https://forum.snapcraft.io/t/apparmor-profile-caching/1268 ? did you ever fix the updating of the rootfs mount time ?
<zyga> ogra: checking
<zyga> ogra: ah that
<zyga> non apparmor side is not affected
<zyga> it was really a combination of apparmor caching, devices without battery-powered RTC _and_ the bug in the time restore from mount time
<zyga> apparmor caching was reliant upon mtime
<zyga> with the fix to the last part of the chain the bug is gone
<ogra> zyga, well, the not-updating of the last mount time causes other issues for customer snaps
<zyga> and that was fixed
<ogra> we have customers with x509 certs in use that fail when the tie isnt correct
<ogra> *time
<zyga> AFAIK
<ogra> (using them inside their app snaps)
<ogra> do you know who worked on it so i can point to a PR in a bug ?
<zyga> let me think
<zyga> checking
<ogra> (this can also wait til tomorrow ... no hurry ... i was just pinged about it ...)
<zyga> sorry
<zyga> I'm wrong
<zyga> I fixed one aspect of apparmor usage that made us immune to time skew
<zyga> but I believe someone else (not sure who) worked on the root bug
<ogra> yeh,, that one i know
<zyga> I will show you what I did
<ogra> i had hoped Chipaca has probably looked into the shutdown issue to fix the root cause
<zyga> https://github.com/snapcore/snapd/commit/32a63a0326f365d0b008893c76a3371a740a79cf#diff-57dc34ab6f4bf9730b356d0439daa0fd
<zyga> and woot for the commit message
<Chipaca> ogra: ?
<ogra> zyga, right, that doesnt really help with the clock :)
<ogra> Chipaca, fixrtc reads the last mount time stamp from dumpe2fs on systems without rtc ... due to the fact that snapd-shutdown-helper never really unmounts, that timestamp permananetly stays at image creation time
<zyga> http://commit.style/
<Chipaca> ogra: why does snapd-shutdown-helper never really unmount?
<zyga> ogra: AFAIK it was slightly different
<zyga> ogra: kernel chooses not to update that timestamp if the filesystem is remounted ro before unmounting
<ogra> Chipaca, i think thats actually an ext4 bug that zyga discovered
<zyga> and that's what happens
<ogra> right
<ogra> that
<Chipaca> ogra: so, no, i haven't fixed it -- first i'm hearing of it :-)
<ogra> heh, yeah, obviously
<Chipaca> in my defence i've been on holidays for a week
<ogra> lets talk tomorrow :)
<Chipaca> â¦ I could easily go away for another week though
<Chipaca> this 'working' thing sucks
<ogra> its late and i dont want to keep anyone busy after hours
<Chipaca> :-)
<ogra> :)
<Chipaca> yeah, i've got to walk the dog, and see about dinner
<ogra> enjoy ... i'll ping tomorrow
<Chipaca> k
<jdstrand> kjackal_bot: fyi, https://github.com/snapcore/snapd/pull/5739
<jdstrand> kjackal_bot: fyi, having trouble getting to the docker-support side, so I just sent up the classic change
<MattJ> Howdy. I searched the docs and the forum, but couldn't find an answer... is there a way for a snap to access /etc/ssl? It seems like it would be a common requirement, but I don't know how people handle it
<Doctor_Nick> MattJ: Sounds like you'd need a plug to access the root file system, or just use classic containment
<Doctor_Nick> also, if someone could help me out with this issue here, I would be greatly appreciative: https://forum.snapcraft.io/t/getting-a-part-build-artifact-into-another-parts-build-before-pull/7082
#snappy 2018-08-30
<vivus> Hello all.
<vivus> Are snaps basically LXC containers running different applications?
<xnox> vivus, and so much more. some of the underlying security and confinment technology is similar, but that's only the basic building blocks. Cause there is a lot of mediation and support around installing/updating/upgrading snaps, allowing/disallowing snaps to do things on the host OS, and to/with other snaps to connect to each other. and the core systems, ship everything as the snap including bootloaders and kernel.
<xnox> vivus, and that's definately so much more than just "containers" and "applications"
<vivus> xnox: so how do I make my snap-installed IDE see my development environment such that I get code auto-complete, etc. ?
<xnox> vivus, usually i would expect it to connect with a home plug to access user's home.
<xnox> vivus, are you creating the IDE snap? or are you just using some IDE snap created by somebody else?
<vivus> xnox: so I still need to install lots of dependencies on the main system then?
<xnox> no, none.
<xnox> well depends what you build.
<vivus> its mostly hypothetical at this stage. Im seeing if I should switch from LXC to snaps
<xnox> vivus, play around with examples to understand what snaps are. they are more like android/iphone apps then chroots/containers/vms.
<xnox> since the snap app itself is read-only typically, but can have data in strict ways on the host system.
<xnox> so e.g. there is golang provided as a snap, which gives one compiler.
<vivus> xnox: by lots of dependencies I mean dev-environment deps. For example, let's say I install PyCharm. Now I want to use PyCharm with autocomplete for my Python environments. Where do I install the Python environment stuff?
<xnox> typically in a pyenv in like ~/code
<vivus> is the pyenv a snap also?
<xnox> no
<vivus> so that's on the host?
<xnox> yeah... cause you'd need it read-write, don't you?
<vivus> that seems like going a bit backwards for me then. all my dev stuff are isolated in LXC containers, because of the bloat they create on the host.
<vivus> can i attach and modify a snap container?
<xnox> right but pycharm itself could be a snap. and all of its dependencies would be inside the snap and do not leak on the host at all.
<xnox> and you can have multiple things co-installed which use same deps, but different versions, without any conflicts on the host.
<vivus> yeah but say I want to install a python package that has lots of system dependencies, like Pillow, then my host would still accumulate system-deps just for Pillow
<xnox> this is generic development stuff. you would not be installing those as snaps typically, no. you would use some form of confinement.
<xnox> but you would not need to install it on the host into /usr
<xnox> vivus, and e.g. Pillow -> i'd be installing that in a virtual env, in project directory in a reproducible way. https://docs.python.org/3/tutorial/venv.html
<xnox> cause with python, one typically creates a virtual-env which contains this project dependencies only, and develops / runs / tests code there.
<vivus> xnox: yeah, but Pillow and some other Py packages will sometimes need system-deps to compile
<xnox> true
<vivus> now say you have to do this for Python, and then maybe Node too. Creates lots of bloat
<vivus> The other day I had to install mono and I used isolation to specifically avoid the bloat
<xnox> maybe you want to look at snapcraft
<vivus> *on the host
<xnox> that's tooling to build snaps, with isolation, which has a lot of tooling to use lxd containers to build all the layers/dependenices of your app, including your app, and bundle everything as a snap.
<vivus> Perhaps I can create the snaps myself. but they are immutable right? I cannot `sudo lxc-attach -n snapcontainer` right?
<xnox> but that's mostly for "from scratch build & deploy" scenario. not meant for interactive coding/iterations.
<xnox> vivus, snap filesystem structure, is a bind-mounted squashfs -> so no, attaching into its mountspace will not gain you much.
<xnox> and paths and prefixes may look odd to you
<xnox> vivus, what's your actual problem and why did you start looking at snaps? =)
<xnox> vivus, are lxd containers not working out for you? (i find $ lxc launch ubuntu:cosmic etc so much nicer than old lxc-* commands)
<xnox> vivus, have you used lxd already?
<vivus> xnox: ill reply in 5. just afk
<vivus> xnox: the distro I use doesn't have first-class support for LXD, but I've been using LXC for a few years now, so that's not the pain-point. I was hoping I'd get to use some type of containerized desktop IDEs that can help me do code auto-complete, etc.
<vivus> right now what I use is Vim
<vivus> and I kind of prefer mouse interaction at times
<Doctor_Nick> if anyone could help me out with this in this post, i would greatly appreciate it, I need to kick this out the door soon: https://forum.snapcraft.io/t/getting-a-part-build-artifact-into-another-parts-build-before-pull/7082
<mborzecki> morning
<zyga> o/
<zyga> good morning
<mvo> hey zyga
<zyga> hey, how are you doing?
<mvo> zyga: doing well, thank you
<mvo> zyga: how are you?
<mborzecki> zyga: mvo: hey
<mvo> mborzecki: hey hey
<mborzecki> zyga: pushed the changes to https://github.com/snapcore/snapd/pull/5713
<zyga> looking
<zyga> there is a conflict with your other patch in master now
<mborzecki> zyga: i'm really bad at naming things, feel free to suggest something different than ExpandSnapMountVariables()
<zyga> ExpandSnapVariables(perspectiveHost,perspectiveSnap) # maybe?
<zyga> that is maybe a flag rather than a new function
<zyga> because then anyone using it must face the fact that perspective matters
<zyga> but I didn't read all so just quick reaction
<mborzecki> idk, i'm open for alternatives
<zyga> let's use the word perspective for that across the tree
<zyga> though not sure if it is sufficient:
<zyga> there's the outside perspective (host perspective?)
<zyga> there is the inside perspective for strictly and devmode confined snaps
<zyga> (perhaps for classic snaps the inside perspective should just error or be the same as outside perspective)
<zyga> mvo: btw: did we decide to do something about "snap install classic"
<zyga> mvo: I had some ideas on that
<zyga> mborzecki: but then there's the inside perspective of instance snaps, what should is say for $SNAP - /snap/foo/42 or /snap/foo_bar/42
<mborzecki> zyga: hm that sounds good
<zyga> mborzecki: if the instance aware path is rare we could do ExpandSnapVariables(innerPerspective | instanceAware)
<mvo> zyga: snap install classic is on my todo
<zyga> mborzecki: but normally just pass innerPerspective
<mvo> zyga: funny enough it will work, it will just be the wrong classic
<zyga> mborzecki: from what I guess there's just three places that need to be instanceAware
<mborzecki> zyga: and it has an upside that i could push this as a pr outside of 5713
<mvo> zyga: it will pull in "core"
<zyga> mvo: right :)
<zyga> mvo: remember that on core18 all the snaps use pivot_root
<zyga> so yeah :)
<mborzecki> zyga: naming aside, please take a look at the rest of the changes and the spread test and i'll start looking into this change with perspective flag
<zyga> I
<zyga> OK
<zyga> the instance layout test is very nice
<mborzecki> zyga: do you think i could add something to the content interface test?
<zyga> reading it now
<abeato> mvo, hey, would it be possible to make sure https://forum.snapcraft.io/t/pulling-network-online-target-as-prerequisite-target-slows-down-starting-services/6063 does not happen on UC18?
<mborzecki> zyga: omg, found some bad merge
<mvo> abeato: indeed, sorry, it is still on my TODO let me move it up
<zyga> mmm? where?
<mvo> mborzecki: yeah, tell us more
<mborzecki> mvo: my code :) no worries
<mvo> puhhh :)
<abeato> mvo, awesome, thanks a lot
<mborzecki> zyga: in info.go, ExpandSnapMountVariables, around SNAP_DATA
<zyga> I'm not there yet
<mborzecki> hm wonder why it was picked up by vet on travis, but not locally, iirc go test is supposed to run vet now too?
<zyga> is it? I was never using go vet automatically, it's always manual
<mborzecki> zyga: https://golang.org/doc/go1.10#test-vet
<zyga> ah,go 1.10!
<zyga> so I was using it without being aware of it
<mborzecki> they mention high confidence checks though, idk how unreachable code is not among those
<zyga> I'd love unused code detector
<mborzecki> zyga: try gometalinter
<zyga> e.g. public functions that are not used
<mborzecki> there's deadcode checker
<zyga> yeah but $standard vs $toolbox
<zyga> I agree I'm just lamenting it is not a standard issue feature
<mborzecki> btw. deadcode actually picks up some stuff in the project, just didn't open any PRs yet
<pstolowski> morning
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5713/files#r213925025
<zyga> the path discussion summarized
<zyga> hey pawel
<mvo> hey pstolowski
<mborzecki> pstolowski: czeÅÄ
<mborzecki> zyga: wonder if that's a bit too many flags
<zyga> mborzecki: four?
<zyga> really we need the two flags for perspective + one flag that "flips" the natural instance awareness
<zyga> so three
<zyga> but the reality is that I think we just need it
<mborzecki> zyga: i'm taking yagni angle here, all the use cases are inside mount ns now https://paste.ubuntu.com/p/RZF98hg8hd/
<zyga> snapshots need the outside path
<zyga> inside you need both the instance and non-instance paths
<zyga> (or we can just craft the instance paths with instance key manually
<zyga> +1 on yagni though, if you can get it to work
<zyga> we can add the override flag if needed
<mborzecki> zyga: i'd expect snapshots to use snap.Info methods, those do instance-specific paths
<zyga> interesting
<zyga> yeah
<mborzecki> zyga: to recap, the snap.Info.SomeSuchDir() return all instance path, then the package level helpers snap.MountDir() et al take a snapName, so you can do snap.MountDir(info.SnapName(), info.Revision)
<mborzecki> zyga: hm need to update that symlink path in layouts test
<zyga> ah, right
<zyga> +1
<mborzecki> zyga: actually something broke there with /etc/demo, i'm looking into this right now, will ping you if i need a hand
<zyga> ok
<zyga> what was the error?
<mborzecki> /etc/demo/writable is not created in $SNAP_COMMON for some reason
<mborzecki> zyga: the fstab looks ok to me https://paste.ubuntu.com/p/wMw8hrWZmq/
<zyga> mmm
<zyga> ok
<mborzecki> zyga: i can see /etc/demo/writable inside snap mount ns, but it's not in $SNAP_COMMON/etc/demo for some reason (and not in /var/snap/test-snapd-layout_foo/common either)
<zyga> is it because /etc is the real /etc and it is writable and then you don't get a private-namespace copy?
<zyga> aka, trespassing bug
<zyga> maybe we can revive my branch for that
<mborzecki> zyga: mountinfo inside, https://paste.ubuntu.com/p/FXrp8Cmymc/
<mborzecki> zyga: hm it worked before fwiw
<zyga> 894 737 8:1 /var/snap/test-snapd-layout/common/etc/demo /etc/demo rw,relatime master:1 - ext4 /dev/sda1 rw,data=ordered
<zyga> so /etc/demo is /var/snap/test-snapd-layout/common/etc/demo
<zyga> anyway, I'll revive it
<zyga> I need to land htat
<mborzecki> zyga: hmm https://paste.ubuntu.com/p/3MXW6fz5RC/ what if it's not? :)
<zyga> and on the host :D
<zyga> because this really tells you what happens
<zyga> ext4 filesystem on /dev/sds1, the slice at /var/snap/test-snapd-layout/common/etc/demo is at /etc/demo
<zyga> 977 764 8:1 /var/snap/test-snapd-layout_foo /var/snap/test-snapd-layout rw,relatime master:1 - ext4 /dev/sda1 rw,data=ordered
<zyga> this hides it from your namespace (it's later in the sequence)
<zyga> (sequence matters)
<zyga> but just check on the host
<zyga> am I right?
<mborzecki> hm on the host, /etc/demo is there, /var/snap/test-snapd-layout_foo/common/etc/demo/writable is not, but /var/snap/test-snapd-layout/common/etc/demo/writable is and contains what was written by the _foo instance :/
<mborzecki> zyga: ^^
<zyga> right
<zyga> that's what I expected
<zyga> I mean, mountinfo doesn't lie
<zyga> it's just non-obvious what the outcome is
<mborzecki> zyga: heh, ok, i'll just leave a comment in the test that this part blows up too
<zyga> mborzecki: I'm looking at my trespassing fix onw
<zyga> the part I got stuck on is something you could help me with
<zyga> if you want we can HO today and I'll walk you through it
<zyga> maybe the solution will become obvious as we d oit
<MattJ> Is there a way I could grant a snap read-only access to /etc/ssl without going all the way and changing it to a classic one? Is there an interface I'm missing? If not, is there a potential for one to be added?
<zyga> MattJ: let me look
<mborzecki> zyga: ok, sure
<zyga> so
<zyga> MattJ: the network interface does that
<zyga> but you need to know that /etc/ssl is not from the host
<zyga> it is the one from the base snap of your app
<zyga> so you cannot add ssl certs by adding them to your host
<MattJ> Ah, ok :/
<MattJ> Thanks - do you see any easy way around this or should I give up and switch to classic confinement?
<zyga> it depends on what you want to do
<zyga> you can add ssl certs from your snap to your snap's runtime
<zyga> that is
<MattJ> Another thing I thought was if I could just run one command without confinement to import the certs to the data path or something
<zyga> any given snap can add certs for itself
<MattJ> Well it's a server process, but it needs valid certificates for the domain it is serving
<MattJ> Most people these days will already have these via Let's Encrypt/etc.
<zyga> mmm
<zyga> where do you need that cert to be exactly?
<MattJ> I need it anywhere that can be read by the server process launched in the snap
<zyga> copy it to $SNAP_COMMON
<zyga> and have your snap read it from there
<MattJ> I guess I could provide a script in the snap that does this, and the user could execute it manually
<MattJ> Thanks for the thoughts :)
<Chipaca> MattJ: a script can detect if it's being run or being sourced, and error if it's being run, with an error along the lines of 'you need to source this'
<Chipaca> MattJ: in bash, that is: check whether ${BASH_SOURCE[0]} is $0
<MattJ> This would probably need to be actually run as root, from cron
<MattJ> But thanks for the tip
<Chipaca> MattJ: systemd timers ftw
<MattJ> Sure, though that can't be installed by the snap... but I guess it could be installed by this script, hmm :)
<Chipaca> MattJ: OTOH you're not the only person asking us to be able to add certificates
<MattJ> I think it's easier for web-based apps that may be the only thing on the system, they can bind to port 80 and include certbot in the snap
<Chipaca> so maybe we need to think about a more general solution
<Chipaca> MattJ: if your snap was installed on a core device, where /etc/ssl is readonly, what would your users do?
<MattJ> Probably install some Let's Encrypt/certbot snap
<MattJ> (I would like the snap to work on a core device for sure, so I would also like a solution for that - but I haven't got that far yet)
<Chipaca> MattJ: so from your POV getting the cert is never your snap's concern, it always needs to come from outside
<Chipaca> MattJ: why would the copying need to be put on a timer? because presumably the certs get updated periodically in some other place and the whole tree needs to be in sync?
<t1mp> should the app version number always be "hard-coded" in the snapcraft.yaml file?
<t1mp> I'd like to get it from my_python_package.__version__ instead
<mborzecki> zyga: i'm looking at the log from test-snapd-layout_foo, https://paste.ubuntu.com/p/j5WSWJtyJH/ if the mount changes are pefroemd in the order they are logged in line 178 then this will be incorrect, won't it?
<mborzecki> zyga: i mean i see it's doing all the layout stuff before parallel instance setup, although fstab lists parallel instance pieces first
<zyga> hmmm
<mborzecki> zyga: before it worked because layouts used instance-specific paths and the instance -> snap bind mount would not confclit
 * zyga looks
<zyga> aha
<zyga> interesting
<zyga> hmmm
<zyga> right
<zyga> we sort them in a specific way
 * zyga thinks
<mborzecki> hm parallel-instance then should come first?
<Chipaca> t1mp: you can tell snapcraft to grab the version from elsewhere
<zyga> lines 162-190 of the log
<zyga> not sure if that's correct
<mborzecki> zyga: we have x-snapd-origin we could use
<MattJ> Chipaca, Let's Encrypt certificates are only valid for 3 months, and are typically updated more often than that
<zyga> yes but it's super super tricky what happens
 * mborzecki looking
<zyga> the rationale for the ordering is specific
<zyga> I was thinking if we need to do batching
<MattJ> Chipaca, so either the snap needs constant access to them, or they need to be imported periodically by something with access to them
<Chipaca> t1mp: look up "snapcraftctl set-version", i think that'll lead you to the how
<mborzecki> zyga: like parallel instances first, then layouts, then the rest (if needed?)
<zyga> perhaps
<Chipaca> MattJ: yeah, that's what i thought
<zyga> but it's all non-trivial
<mborzecki> zyga: computing changes would be tricky
<zyga> not sure if this remains correct
<t1mp> Chipaca: thanks, reading.
<zyga> mborzecki: what if we do a stable sort
<zyga> and sort by (target, source)
<zyga> not just by target
<zyga> I think what is happening that is wrong is
<zyga> we order things by where they appear
<mborzecki> zyga:  i can try that
<zyga> ignoring the what they bring aspect
<zyga> and what they bring is also relevant
<zyga> we need to correctly order the desired state
<zyga> but then the question becomes;
<zyga> is this breaking any invariants the current code has
<zyga> will it undo correctly
<mborzecki> zyga: i'll do some experimentation and we can later meet in HO
<mborzecki> zyga: heh, finny that it worked before by accident :)
<mborzecki> and i was like, 'oh hey it works, so nice' ;)
<zyga> mborzecki: I need to go to the post office
<zyga> mborzecki: we can HO after that
<zyga> ok?
<mborzecki> sure
<zyga> brb
<mborzecki> niemeyer: hi, when you're around could you take a look at https://github.com/snapcore/snapd/pull/5735 ?
<niemeyer> mborzecki: Looking
<mborzecki> niemeyer: thanks
<niemeyer> mborzecki: Reviewed, np
<Chipaca> t1mp: this: https://forum.snapcraft.io/t/extracting-information-from-sources-in-snapcraft-parts/4642
<t1mp> Chipaca: thanks.
<t1mp> I see there is also a version-script property in the yaml file, but not a lot of docs on that yet.
<zyga> re
<mborzecki> zyga: i'm playing with this naiive change https://paste.ubuntu.com/p/K54npKZzFg/
<zyga> sure but think about the consequences as well
<mvo> zyga: do you think 5307 needs another look by jamie ? or can we squash it?
<mborzecki> zyga: just verifying that moving those mounts to be firs fixes the issue at hand
<zyga> mvo: looking
<zyga> mvo: ideally jamie would look but he's been busy
<zyga> also gustavo asked for +1 from jamie
<mborzecki> zyga: the tests are passing now (expectedly)
<t1mp> Chipaca: version-script looks like it will do what I want, but still the 'version' property is required. I assume that version-script will override that (but it is not documented what will happen). I guess I'll have to try it
<niemeyer> WOAH
<niemeyer> There's no a "Resolve conversation" button in GH..
<niemeyer> So simple and so useful
<pstolowski> pedronis: hey, wrt your comment about revert & Sequence after currentIndex, what're the semantics of Sequence?
<niemeyer> And "Show resolved" and "Hide resolved".. OMG.. my day just got better
<Chipaca> niemeyer: nice
<niemeyer> https://usercontent.irccloud-cdn.com/file/uMovdf2m/image.png
<mvo> xnox: that reminds me, can I do an sru for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 or do you plan to do one anyway where you could include this change?
<ogra> mvo, hmm, you said SNAP_ARCH_TRIPLET was not implemented ... this one is very curious though ... :
<ogra> $ snap run --shell qemu-virgil -c "/usr/bin/env"|grep SNAPCRAFT
<ogra> SNAPCRAFT_ARCH_TRIPLET=x86_64-linux-gnu
<ogra> seems the snapcraft var is actually inside the installed snap
<ogra> (whihc is great but smells like it should not be like that)
<mvo> ogra: I did not follow what snapcraft was doing there
<ogra> mvo, well, somehow SNAPCRAFT_ARCH_TRIPLET ends up in my runtime env
<ogra> that snap has no wrappers or anything so this is very curious
<ogra> i mean, i appreciate that ... but it doesnt feel right that a SNAPCRAFT var ends up in my installed snap package
<ogra> $ grep SNAPCRAFT /snap/qemu-virgil/current/command-qemu-virgil.wrapper
<ogra> $
<ogra> it is definitely not in the default wrapper
<ogra> so i wonder where it comes from
<ogra> gar
<ogra> ignore that ... somthing exported it into the shell i'm in
<ogra> (which is also curious ... should snap run --shell not wipe my env ? )
<Chipaca> ogra: nope, only remove some of it
<ogra> ah
<mborzecki> pstolowski: left you some comments on #5680
<pstolowski> mborzecki: ty!
<zyga> hmm, if a test panics the panic breaks the test
<zyga> but if a test panics and teardown uses c.Assert() that fails then the assertion error is show but the panic is gone
<zyga> is this expected?
<Chipaca> grr grr grr integration tests grr
 * Chipaca ~> lunch
<zyga> mborzecki: hey
<zyga> do you want to HO?
<mborzecki> sec
<zyga> I'm progressing on the trespassing fix, I rebased it and solved a blocker I had the last time
<zyga> now going through tests that ... well, need some love since syscalls changed
<zyga> but it's mostly inserting a syscall in a chain and going on
<mborzecki> zyga: ok, ready
<zyga> standup?
<pedronis> mvo: can #5583 be reviewed again?  I might not get to it today tough
<ogra> hmm, an install hook should also run on upgrades, right ?
<mvo> pedronis: yes, I updated it ~1h ago
<pedronis> ok
<mvo> pedronis: it has a minimal wait and tracks the idle connections now
<mvo> s/tracks/checks/
<pedronis> mvo: likely I will look at it tomorrow, trying to getting started with something today (but had a bit of a cut up day by errands so far)
<pstolowski> ogra: no
<mvo> pedronis: no worries, its not urgent
<pstolowski> ogra: on upgrades we run pre-refresh and post-refresh hook sinstead
<pstolowski> *instead
<ogra> pstolowski, hmm, so i need two scripts if i want something to work on install as well as on upgrades ?
<ogra> hooks/install and hooks/*-refresh ?
<zyga> jdstrand: hey, there's a pr that is blocked on you (the one about /mnt)
<zyga> jdstrand: do you think you will have time to review it today
<pstolowski> ogra: yes
<jdstrand> I got through some yesterday. will try to get to that one
<ogra> boo
<ogra> ok
<zyga> jdstrand: thank you!
<pstolowski> ogra: if the logic is the same you can move it to a helper.. or maybe a symlink will work (not sure)
<ogra> well, i#ll just cp it ...
<zyga> I must say I love our standups
<mborzecki> guys, any clue why i'm not able to edit https://forum.snapcraft.io/t/security-policy-and-sandboxing/554 ?
<zyga> it's not a wiki
<zyga> the irony there hurts ;)
<zyga> oh boy!!
<zyga> I used 1TB of data this month
<zyga> and I actually hit my cap
<zyga> wow
<zyga> (LTE cap)
<zyga> I need better visibility into this, who is using this data ....
<mborzecki> nasty neighbours :)
<mborzecki> zyga: hm i can edit this https://forum.snapcraft.io/t/the-snap-format/698 but not the other one
<axino> hi
<axino> I have a snap containing some rust code, it compiles fine on amd64/i386 but not on arm64/armhf
<axino> error is "error[E0658]: non-reference pattern used to match a reference (see issue #42640)"
<axino> has anyone seen this ?
<axino> https://launchpad.net/~build.snapcraft.io/+snap/17fc91e19f932bd8a75175923b533019-xenial builds are here
<Chipaca> axino: is this specific to the snap?
<axino> Chipaca: I can't answer that
<Chipaca> axino: why not?
<axino> Chipaca: I haven't tried to build sentry outside of the snap context
<axino> Chipaca: or maybe I misunderstood your question
<Chipaca> axino: the error does not seem to be about snaps at all
<Chipaca> axino: I'm not sure how we could help
<axino> Chipaca: maintainers of multi-arch rust snaps might have seen this behaviour
<axino> I guess I'll try #rust
<Chipaca> axino: if you don't have luck there, try a topic on the forum
<axino> Chipaca: yup I will - thanks
<Chipaca> mup: ping
<Chipaca> mup: how much chug would a moose chug â¦ wait
<popey> jdstrand: I'm getting a snap suddenly getting rejected by the store, which was fine previously
<popey> jdstrand: https://dashboard.snapcraft.io/snaps/scummvm/revisions/466/
<popey> "unknown keys in snap/manifest.yaml: snapcraft-os-release-id,snapcraft-os-release-version-id,snapcraft-version lint-snap-v2_snap_manifest "
<jdstrand> popey: tools needs an update. thanks!
<jdstrand> popey: can you request a manual review?
<jdstrand> popey: we'll get that fixed fast
<popey> done, thanks
 * zyga goes for a bike for 1..2 hours
<jdstrand> popey: can you do the same for 466 (i386)?
<popey> jdstrand: done
<zyga> jdstrand: I'm making good progress on the trespassing bug (it was unblocked today), I'll bug you about that tomorrow
<jdstrand> zyga: great. fyi, I'm off tomorrow/Monday (will send email later)
<zyga> ah
<zyga> ok, then on Tuesday
<zyga> can you try to look at https://github.com/snapcore/snapd/pull/5307 - you're the last +1 needed :)
<zyga> (regardless, I'm heading out)
<jdstrand> zyga: yes, we talked about that already today :P
<zyga> I know, sorry :|
<diddledan> snapd 2.35 is installing the .snap files as root:root 600 - previous snapds installed root:root 644
<diddledan> caused an error that I've documented in the cft for snapcraft 2.43: https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-43/7024/5
<popey> i had this the other day too
<Chipaca> diddledan: popey: that is known and fixed on master fwiw
<Chipaca> master of snapcraft that is
<diddledan> how can snapcraft, running as me, decide to override root-only access?
 * diddledan eyes it suspiciously
<Chipaca> diddledan: say again?
<Chipaca> diddledan: it doesn't
<Chipaca> diddledan: it no longer tries to copy those files into the container
<diddledan> you said it was fixed in snapcraft, but snapcraft can't override the root-only access
<diddledan> aah
<diddledan> gotcha
 * diddledan removes suspicious eyes
<Chipaca> diddledan: in the future we'll bring the caching back by adding api to snapd to stream the snaps
 * diddledan inserts googley eyes instead
 * Chipaca whacks diddledan over the head just watch the googley eyes bobble
 * ogra steals diddledan's goggley eyes and replaces them with xeyes for nostalgic reasons
<diddledan> https://www.youtube.com/watch?v=BBFqGHgCFiY
 * popey runs wayland on diddledan  to break the xeyes
<diddledan> haha
 * ogra secretly shoves XWayland underneath popey's injection ... just to notice the xeyes became stills due to securit reasons
<ogra> +y
<Chipaca> clearly the way to have it  work again is to make diddledan be all eyes
<jdstrand> roadmr: hi! can you pull r1123 of the review-tools. this should be considered fairly urgent since anything using a new snapcraft will end up in manual review
<jdstrand> roadmr: ideally done today since I'm off tomorrow/Monday
<ogra> http://www.davidmelling.co.uk/blog/wp-content/uploads/2012/05/monster5-e1337951522979-1024x602.jpg
<jdstrand> roadmr: fyi, https://paste.ubuntu.com/p/553Jg578yF/
<jdstrand> roadmr: (r1123 changed sr_common.py)
<jdstrand> popey: that has your fix ^
<popey> yay
<popey> ta
<Chipaca> fair warning, a lot of our argentine colleagues might be a bit distracted these days
<ogra> we should just pay them in euros then
<ogra> (or is there more than the crazy inflation ?)
<Chipaca> ogra: it's the chaos and turmoil that with this
<ogra> yeah
<Chipaca> could I get a review or two of https://github.com/snapcore/snapd/pull/5744 ? reasonably straightforward (might even qualify as Simple)
<Chipaca> tests are green despite what github says (at least  here)
<sergiusens> niemeyer, kyrofa: wrt out conversation from Monday, are we good on s/templates/extensions/ ?
<niemeyer> So far it sounds good
<sergiusens> niemeyer: great, we will rename them
<roadmr> jdstrand: hi! I'll put it in the pipeline
<popey> jdstrand: i take it you've seen the review tools themselves got rejected? :)
<popey> (also, lol)
<roadmr> haha
<mvo> heh
<zyga> Returned
<zyga> TIL police does not arrive even after 25 minutes of waiting
<ogra> oh gosh ... thats a lot of additional apt sources in that "16.04 snap missing" thread !
<ogra> ... what could possibly go wrong ...
<roadmr> zyga: why did you call police? ð±
<zyga> roadmr: some drunk assholes were harassing a young couple
<roadmr> oh not nice :(
<ogra> jdstrand, hmm ... i just had three weird rejects of a plain package rebuild ... " unknown keys in snap/manifest.yaml: snapcraft-os-release-id,snapcraft-os-release-version-id,snapcraft-version lint-snap-v2_snap_manifest"
<ogra> jdstrand, https://dashboard.snapcraft.io/snaps/qemu-virgil/revisions/30/ (and 31, 32) in case you want to take a look ... it is built using build.snapcraft.io and there were no fancy changes or anything ... the former build went through for all arches
<ogra> jdstrand, oh, ignore me, just saw the backlog ... i guess it will magically fix itself
<Caelum> zyga: I'm getting that exact fail on my tw server with 'osc build'
<zyga> Caelum: hey
<zyga> Caelum: I talked to some golang people from suse
<zyga> Caelum: apart from some issues in test suite (unicode vs ascii output) I'm re-working the use of golang helpers
<zyga> Caelum: tl;dr; version is that people that make golang helpers recommend not to use golang helpers
<Caelum> zyga: so you found the issue, was it a segfault or something like that?
<Caelum> zyga: yeah figures
<zyga> Caelum: ish, I have not confirmed it on pure i586 system
<Caelum> zyga: the go build stuff is very weird to be honest
<zyga> "go build" is very nice but %go_build is horrible
<Caelum> zyga: honestly I've never yet built snapd with the regular tools, the patches I ran through osc
<Caelum> zyga: but I'm going to try again now
<zyga> Caelum: actually it's pretty easy, just go build :)
<zyga> Caelum: anyway, I'm reading now, but I will push updates to my home branch
<Caelum> zyga: looks like ./run-checks is all I really need
<Caelum> zyga: looks like fixing things for gentoo is going to be non-trivial, already ran into a needed dependency that gentoo doesn't have
<jdstrand> roadmr: thanks for putting it in the pipeline-- do you have an eta?
<roadmr> jdstrand: I'll do my best to roll out today but no promises; if not, it'd be until Monday/Tuesday
<jdstrand> roadmr: ok, thanks
<jdstrand> roadmr: Monday/Tuesday is going to be a problem. basically, all snapcraft.io/LP builds are getting blocked
<jdstrand> roadmr: I apologize for this. I wasn't aware of the changes
<roadmr> :(
<roadmr> I'll do my best to get this out today
<popey> sorry, but +1 to getting this fixed asap. We're already getting mails about stuff failing
<cjwatson> Do we need to revert LP's snapcraft?
<cjwatson> (Is it a snapcraft change that caused this?  I have no idea TBH.)
<jdstrand> cjwatson: yes, snapcraft
<jdstrand> cjwatson: but lets hold off on the revert and see what roadmr can do
<roadmr> jdstrand, cjwatson : if it's easyish to revert, it might be faster than what I can do :(
<jdstrand> I don't personally have a preference, but I don't know what snapcraft is fixing
<roadmr> jdstrand: at this point the store release pipeline involves a CI run which might take 2 hours, then requesting the rollout which, assuming someone from IS is around to process and I nag them hard enough, might take another hour. But it's already 4 PM for me so that puts me past EOD (my son is very strict in enforcing EOD)
<roadmr> jdstrand: we put a veto on Friday releases since last Friday's broke the world :D so if not done today, that's why it would have to wait for Monday. Monday is Labor Day in some countries so coverage will be low as well
<roadmr> (I'm off on Monday for one, and so are you :D)
<cjwatson> roadmr: unless I'm missing a quicker way, we'd do it by building a reverted version with a higher version number and put it in the snappy-dev/ubuntu/tools PPA
<jdstrand> cjwatson: would it be possible to revert until next Monday/Tuseday when roadmr pings us that the fix is in place?
<cjwatson> That doesn't require (or even really benefit from) an LP person being available, which is a good thing since I'm about to walk out the door
<cjwatson> Anyone in ~snappy-dev could do it
<jdstrand> I'm in snappy-dev
<cjwatson> This works because LP puts "deb http://ppa.launchpad.net/snappy-dev/tools/ubuntu %(series)s main" (with the appropriate series substituted for "%(series)s", but it's usually xenial and in particular it's xenial for all build.snapcraft.io builds) in the sources.list for every snap build
<cjwatson> For exactly this sort of reason
<pedronis> how did this snapcraft got throught anyway? should have it broken some store integration tests?
<jdstrand> cjwatson: https://launchpad.net/~snappy-dev/+archive/ubuntu/tools seems to have ancient stuff...
<cjwatson> Yes, it hasn't been actively used for a while
<cjwatson> But it's still in sources.list
<jdstrand> cjwatson: oh, you're saying take the last xenial from -updates and shove it there
<jdstrand> (with proper versioning, etc)
<cjwatson> It needs to have a higher version number than anything else in the snap build's sources.list, but yes
<jdstrand> sure
<cjwatson> I mean you should probably alert the snapcraft team that you're doing this
<cjwatson> o hai
<roadmr> once that thing is in the PPA, how does Launchpad pick it up? magic?
<jdstrand> pedronis: that will be my next question. snapcraft should definitely have some tests that run snaps it produces through the review tools
<sergiusens> cjwatson, roadmr: what's up?
<cjwatson> roadmr: snap builds are dispatched to builders with a sources.list that includes that PPA
<cjwatson> so not particularly magic
<roadmr> cjwatson: it is magic! https://www.youtube.com/watch?v=tYh94XTJTDU
<cjwatson> sergiusens: latest snapcraft apparently breaks the store until a new click-reviewers-tools is rolled out, which may not be until Monday depending on how things go.  we were planning to have jdstrand drop a reverted version into ppa:snappy-dev/ubuntu/tools until such time as that happens, so that e.g. BSI users don't suffer in the meantime
<jdstrand> sergiusens: the review-tools got grumpy over some added manifest.yaml keys. I've added them (and one could argue they shouldn't do that) but atm LP/build.s.io builds are failing review
<sergiusens> jdstrand: heh, those are the manifest keys you asked for :-) the irony :-P
<jdstrand> sergiusens: the problem is even though they are fixed, they can't get to prod fast enough
<jdstrand> sergiusens: indeed. I seem to be paying the price for that request
<pedronis> something seems still broken process wise
<jdstrand> pedronis: I mentioned that
<sergiusens> this hassle just also proves that my calls for testing are useless
<sergiusens> should probably just stop doing them
<jdstrand> 15:05 < jdstrand> pedronis: that will be my next question. snapcraft should definitely have some tests that run snaps it produces through the review-tools
<cjwatson> jdstrand: anyway, as mentioned, I'm about to go out.  all clear on what needs to be done if you do go the revert route?
<jdstrand> that could be part of SRU, autopkgtest, travis, whatever
<roadmr> thanks cjwatson
<pedronis> sergiusens: this would have broken any  good enough integration test with the store, unless I'm missing something, or those don't run making a manifest
<pedronis> so we are missing that
<jdstrand> cjwatson: yes. you said xenial is all I need to fix?
<cjwatson> jdstrand: I'll have my phone with me so feel free to SMS the number in the directory if you get stuck
<sergiusens> pedronis: we use the staging store
<sergiusens> pedronis: explicitly told not to use the prod store for any testing
<cjwatson> jdstrand: for BSI, yes.  for other LP builds, that'll still catch nearly everything so it should be fine
<jdstrand> cjwatson: I'll be fine. thanks for the offer
<roadmr> sergiusens, pedronis : this should have broken even with the staging store, since the reviewer-tools that support this only landed on staging today after jdstrand brought the problem up
<pedronis> indeed, still not understanding
<pedronis> are we not checking enough? not testing the manifest case?
<roadmr> I wonder if the store pre-release tests  would have caught them; but we don't run those when snapcraft changes, only when we're about to do a prod release
<sergiusens> roadmr: it should of broken all your travis runs too fwiw, as this functionality is in since late May
<jdstrand> cjwatson: on monday/whenever, I guess we could simply remove the packages from the ppa, then all is good cause builders are ephemeral?
<cjwatson> jdstrand: yes
<roadmr> sergiusens: oh! and it hasn't broken anything!
<jdstrand> cool
 * jdstrand updates the ppa
<jdstrand> cjwatson: thanks
<pedronis> roadmr: sounds either that we don't check that the test go past review tools or the tests are generating manifests
<sergiusens> roadmr: oh, this is missing coverage about generating manifests for those tests.
<jdstrand> cjwatson: enjoy your evening :)
<cjwatson> I plan to.  thanks
<jdstrand> hehe
<cjwatson> good luck
<roadmr> thanks!
 * roadmr needs to step out for a bit but will read backscroll later
 * cachio afk
<hunterk> ok, reading the scrollback, I'm not the only person with the 'unknown keys' build failure, and that's something the snapcraft folks will sort out on their end?
<ogra> yes
<hunterk> kk, thanks :)
<LargePrime> hi,  can i get a link or keyword to enable write areas in a snap?
<LargePrime> am tryint to have a snap packager to fix his snap
<LargePrime> please ping
<popey> LargePrime: snaps have writable areas. $SNAP_USER_DATA and $SNAP_USER_COMMON - see https://docs.snapcraft.io/reference/env  for details
<popey> LargePrime: which snap out of interest?
<LargePrime> popey, https://github.com/diddlesnaps/starruler2/issues/2
<LargePrime> star ruler 2 has lots of mods and modability.  and they seem mostly borked with current ackage
<popey> one possibility that i don't know if diddledan has tried, is you can copy the moddable stuff out to a writable area on first launch
<popey> I did this with one or two snaps
<popey> can end up wasting space though
<popey> the other option is to patch upstream to look in multiple places
<diddledan> I've not had a change to look into it yet
<diddledan> chance*
<LargePrime> popey, would it be a small ask for you to reply to the issue?
<LargePrime> ther he is
<LargePrime> haha
<diddledan> afaict it requires shoving stuff into the binaries directory
<popey> ahh
<popey> that's unfortunate
<diddledan> aye
<popey> how big is the binaries directory?
<LargePrime> diddledan, also we cannot add portraits
<popey> can that be copied out and then launched?
 * diddledan goes looksee
<diddledan> 858MB
<diddledan> most of that in ./data which is probably one of the places that people want to fiddle
<diddledan> there's also ./maps, and ./mods
<diddledan> ./mods we can probably sync across, and put a symlink in place instead
<popey> that might work
<popey> what happens when they have traditionally packaged ones
<popey> like, if you install from a deb (is there a deb?)?
<diddledan> there is no deb that I know of
<popey> is there a mac dmg or somehting
<popey> Or do you just unpack a zip and run it in place?
<diddledan> for the snap it's compiled from sauce
<diddledan> I know not how it's distributed elsewhere :-)
<jdstrand> roadmr (cc cjwatson): I uploaded 2.43+0really2.42.1 to the ppa. it's building
<roadmr> jdstrand: I love the version number :)
<jdstrand> roadmr: yeah, Sergio is uploaded 2.43.1 on Monday, so it should all be good
<jdstrand> uploading*
<roadmr> nice
<roadmr> jdstrand: meanwhile the dashboard rollout process toils along :/ I'm still waiting for the CI run to complete.
<roadmr> should finish in the next 40 minutes or so \o/ *sob*
<diddledan> if a snap with layouts passes manual review can anybody install it? i.e. do users still need to opt-into layouts experiment for a manually approved store snap?
<jdstrand> jeez it takes snapcraft two hours to build
 * jdstrand taps fingers
<jdstrand> (in LP)
<jdstrand> Get:11 http://ppa.launchpad.net/snappy-dev/tools/ubuntu xenial/main ppc64el snapcraft all 2.43+0really2.42.1 [199 kB]
<cjwatson> good good
<jdstrand> fyi, things should start passing again
<jdstrand> see https://forum.snapcraft.io/t/builds-failing-automated-review/7112/3
<jdstrand> my review-tools upload grabbed the downgraded snapcraft, built and reviewed successfully
<jdstrand> cjwatson: thanks for the tip :)
<cjwatson> np
#snappy 2018-08-31
<sergiusens> jdstrand, kyrofa, popey Wimpress https://github.com/snapcore/snapcraft/pull/2234
<mborzecki> morning
<zyga> Good morning
<zyga> Summer feels over now
<zyga> good morning
<zyga> again
<zyga> this time from a computer
<zyga> man, Monday will be brutal :)
<mvo> zyga: good morning
<mvo> zyga: monday is back to school?
<zyga> yes
<zyga> mvo: reviewed systemd env generator PR
<mvo> zyga: nice
<mborzecki> mvo: zyga: hey
<mborzecki> yeah, i'll likely be starting late on monday (or have a break sometime around morning) with the school and all
<zyga> mborzecki: same here
<zyga> two kids to sort out :)
<mvo> mborzecki: good morning
<mvo> mborzecki: no worries
<mborzecki> and back to the 'breakfast, work, kids from school, help with home homework, <do one other thing you may have planned>, dinner, sleep, goto 1' routine
<mvo> zyga: curious, why a man-page for the generator? this thing is pretty well hidden
<zyga> All generators have them
<mvo> zyga: aha, ok
<zyga> It is good courtesy to users since this is an opaque compiled program
<mborzecki> systemd-environment-d-generator has it too, although it's not very useful
<zyga> Iâm moving outdoors
<zyga> Network at home sucks
<zyga> And I need to do a trial school run to see how bus traffic looks like
<pstolowski> morning
<mborzecki> pstolowski: heyah
<zyga> re
<mvo> mborzecki: the arch failures on 2.35 look real
<mborzecki> mvo: that's unfortunate, do you have link to the logs?
<mvo> mborzecki: I mean, they are the same as yesterfday, any idea ? and if this does not affect master we probably just need to find the right commit that fixed it in master
<mvo> mborzecki: https://api.travis-ci.org/v3/job/422560948/log.txt
<mborzecki> mvo: ssh keygen?
<mvo> mborzecki: ohhh
<mvo> mborzecki: yeah, let me find htis one and cherry-pick it
<mvo> mborzecki: thats definitely a good candidate
<mvo> mborzecki: cherry-picked and pushed, lets see if that helps
<mvo> mborzecki: thank you!
<mborzecki> mvo: hopefully it'll be green now :)
<zyga> breaking compat one by one :)
<Chipaca> moin moin
<Chipaca> any idea why #5744 still shows up in github as 'in progress' (and no coverage report) when the tests passed?
 * zyga works on trespassing unit tests
<zyga> working from suse :)
<zyga> I think we have enough people with ubuntu
<zyga> (in the team, go ubuntu :)
<mborzecki> haha
<popey> hmm
<popey> when snapd dies, "snap info" lies
<popey> it says "no snap found" when it should really say that it couldn't contact the store
<popey> https://www.irccloud.com/pastebin/MErmQt88/
<Chipaca> popey: it didn't say there weren't any, it said it didn't find any
<Chipaca> popey: like when I tell my boys to go get something
<popey> "Man looking"
<Chipaca> popey: "I LOOKED NOWHERE AND I CAN'T FIND IT"
<popey> :D
<popey> Should it not also warn that it can't get to snapd?
<popey> the "I looked nowhere" bit
<Chipaca> maybe snap should learn to pick things up and look under things, especially if it just put that thing down
<popey> It should at least pick up the boxes and give them a bit of a shake.
<Chipaca> that's like level 3
<Chipaca> no chance
<popey> snapd needs to lean the Jan Hankel Flank Pat system for finding things
<Chipaca> I see what's going on, I'll push a pr to address it in a bit
<popey> https://www.youtube.com/watch?v=DY-Zdgo0OXo
<popey> Thank you!
<Chipaca> popey: the first time I saw that vid I didn't notice how old it was
<Chipaca> maybe it was a long time ago
<Chipaca> hm
<popey> Yeah, Mitchell & Webb Look aired 10 years ago!
<mvo> mborzecki: aarch is greeeeeeeeeeen
<mborzecki> yay, rejoice :P
<mvo> mborzecki: merged into 2.35 thanks again
<Chipaca> popey: if you did 'snap info foo bar' in that situation, what would you expect to see?
<popey> We'll. Shut down snapd and run snap list. You get a completely different experience
<popey> I would prefer snap list had a nicer error too
<popey> When snapd is down
<popey> (in this case snapd was down due to lack of disk space)
<Chipaca> popey: the problem is 'snap info' does a lot more stuff than 'snap list'
<Chipaca> popey: so each query to  'snap info' can produce up to 2 errors during normal operation
<Chipaca> popey: and up to 3 errors when snapd is down
<Chipaca> popey: note info _can_ produce useful output with no snapd
<Chipaca> popey: e.g. 'snap info /var/lib/snapd/snaps/*'
<popey> (I never knew that)
<popey> (I bet nobody else does either)
<Chipaca> popey: 'snap info /snap/core/current/' also tries to be informative
<Chipaca> popey: or 'snap info ./prime'
<Chipaca> I need to make the errors from client a little more structured before I can hope to make this work
<Chipaca> but we've been wanting this for a while now
<Chipaca> so, yay
<popey> \o/
<Chipaca> yeap. Just, not a quick fix
<popey> no rush
<popey> is it done yet?
<Chipaca> popey: https://www.youtube.com/watch?v=RYVlJKSEsyM
<popey> awwww <3 that video
<popey> Those were happy times
<Chipaca> popey: back when we were part of ESA you mean?
<mborzecki> zyga: niemeyer: https://github.com/snapcore/snapd/pull/5747
<zyga> +1
<mvo> zyga: is there a way to make apparmor refuse to stat/etc/lsb-base-logging.sh  ?
<mvo> zyga: context is https://bugs.launchpad.net/snapd/+bug/1779416
<popey> main.go:192: cannot change mount namespace of snap "mattermost-desktop" according to change mount (/snap/gtk-common-themes/319/share/sounds/communitheme /snap/mattermost-desktop/78/usr/share/sounds/communitheme none bind,ro 0 0): cannot create writable mimic over "/snap/mattermost-desktop/78/usr/share/": permission denied
<popey> ^ anyone seen that before? What does it mean?
<Chipaca> zyga: ^
<popey> I am launching mattermost-desktop from edge, and have the communitheme install
<zyga> popey: hey
<zyga> popey: known issue, please show me the snapcraft yaml, I will show you how to work around it
<zyga> it's a trivial trick
<popey> zyga: https://github.com/snapcrafters/mattermost-desktop/blob/master/snap/snapcraft.yaml
<zyga> looking
<zyga> right
<zyga> if the snap ships $SNAP/usr/share/{icons,themes,sounds} as empty directories
<zyga> this bug goes away
<popey> hah!
<diddledan> ooh, new mycroft
 * diddledan gets compiling
<zyga> popey: the issue is that the rules for poking holes are super precise
<zyga> and they should be more generic in cases like this where there are many more directories to create
<zyga> popey: I'm working on fixing that (2.36)
<popey> ok, thanks.
<diddledan> oh, looks like it's not rolled-out yet (mycroft 18.08)
<Son_Goku> zyga, snapd 2.35 rolled out to fc28
<Son_Goku> still waiting for karma for fc27
<zyga> Son_Goku: Thank You!
<zyga> Son_Goku: I can give it a spin today
<zyga> I'm trying to get out of a very long unit test change
<zyga> for a .1 release
<zyga> Son_Goku: btw, I want to participate in the golang sig
<zyga> I have my own proposal to contribute
<zyga> I was working on it after hours recently
<Son_Goku> cool
<zyga> something that fits upstream and downstream at the same time
<zyga> is easy to use for regular go developres
<zyga> and does all that distros need
<zyga> (magic, right?)
<zyga> I will have it ready in a few days
<zyga> I think there's a real chance to unify fedora and suse helpers
<Son_Goku> heh
<mborzecki> zyga: no more shell wrappers for each go command?
<zyga> mborzecki: exactly
<zyga> anyway, back to work, I'll demo it next week
<mborzecki> heh going through opensuse wrappers was interesting, but to be fair OE also has some hacks spefifically for go packaging
<Son_Goku> Fedora's wrappers are pretty thin
<Son_Goku> the macro directly calls the go command
<mborzecki> Son_Goku: well, suse has an elaborate shell script(s) :/
<Son_Goku> it used to be ruby
<Son_Goku> so be happy it's not that
<mborzecki> hehehe
<mborzecki> Son_Goku: but ruby is like haiku
<mborzecki> Son_Goku: or better, the code reads like plain english
<Son_Goku> suse's golang-packaging being rewritten from ruby to shell was the result of an ugly dispute with the original creator of suse's golang packaging standard
<mborzecki> Son_Goku: otoh the languages bundling their dependencies do not really fit that well with the packaging model used by some distros, i can't imaging splitting dependencies of a trivial node app
<Son_Goku> you don't have to imagine
<Son_Goku> it happened for a while in Fedora
<Son_Goku> and it still does in Debian
<popey> yeah, the number of ITP mails which are "please package this node module" is too damn high
<niemeyer> mborzecki: Thank you! And sorry for the late reply
<niemeyer> And good morning :)
<Chipaca> niemeyer: you got to say 'good morning' by two minutes :-)
<Chipaca> niemeyer: good afternoon sir
<niemeyer> Aftnoon!
<Chipaca> :-)
<mborzecki> niemeyer: sure, thanks for the review
<Chipaca> zyga: pstolowski: if you have a window for an easy review, #5744 is kinda blocking me (I could merge it and then let git sort it out, and I'll do that if it's not reviewed soonish, but i'd rather avoid it)
<zyga> looking
<Chipaca> woo
<Chipaca> thanks
<Chipaca> zyga: tests are green despite github not knowing it
<pstolowski> kk. and what happend to mup btw, is it gone again?
<zyga> mvo: my dragon apparently has android on emmc
<Chipaca> pstolowski: ^ zyga's on it, thanks
<mborzecki> niemeyer: pushed the changes to https://github.com/snapcore/snapd/pull/5713 too (hopefully got all of it now)
<Chipaca> also, how can I merge a PR if travis didn't let github know it was green?
<Chipaca> :-(
<zyga> Chipaca: ask mvo
<zyga> Chipaca: is bytes.Bytes expensive?
<zyga> er
<zyga> buffer.Bytes
<Chipaca> zyga: only a little bit more than doing the maf ourselves
<Chipaca> zyga: memorywise it's about the same
<Chipaca> (especially as it's already used elsewhere)
<mvo> Chipaca: I can
<zyga> why did you move w.partial = nil; to be a w.partial.Reset() a few lines below (after } )
<mvo> Chipaca: which one do you need
<zyga> 5713
<zyga> er
<zyga> not
<zyga> 5744
<Chipaca> mvo: 5744 (but it doesn't have zyga's second +1 yet)
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/5744/files#diff-7c96d8cb550f40c45f4ded10cc30f5eeL54 about this line
<Chipaca> zyga: yep ye
<zyga> it is clear that it is just a p.Reset but why did you move it?
<zyga> is it because of https://github.com/snapcore/snapd/pull/5744/files#diff-7c96d8cb550f40c45f4ded10cc30f5eeL58
<zyga> which is not 1-to-1 (write is append, = was reset + write)
<Chipaca> zyga: because I'd be doing it in the other paths as well
<zyga> ok
<Chipaca> zyga: that is: w.partial = p -> w.partial.Reset(); w.partial.Write(p)
<zyga> +1
<Chipaca> mvo: ok now yes please
<zyga> done
<zyga> mvo: 3/4 flashed
<Chipaca> mvo: https://github.com/snapcore/snapd/pull/5744 is green and has two +1's
 * Chipaca ~> break
<mvo> Chipaca: done thank you
<Chipaca> mvo: whee, thanks
<Chipaca> wait i was supposed to be on a break
 * Chipaca hides
<popey> hm, is there any way to see which snap pulled in a core18 ?
<Chipaca> we should include that in the error (there's a // TODO)
<Chipaca> (in the "snap remove core18" error i mean)
<pedronis> popey: snap info --verbose should show the base of a snap
<zyga> yep, it does
<Chipaca> maybe snap list should include it as well
<mvo> or snap info core18 could list the rdepends
<Chipaca> mvo: oooh
<Chipaca> mvo: I'll add that
<popey> that would be nice
<Chipaca> could also look at slots/plugs
<popey> diddledan: you moved to core18 on gimp? :)
<diddledan> yes. I've got the snap building on launchpad for now
<mborzecki> zyga: where was the mapping thing that changed system -> core and back?
<diddledan> just this second told it to do a new build for libx11-related security patches overnight
<zyga> mborzecki: in overlord/ifacestate
<zyga> man, SD cards are slow
<mborzecki> zyga: i'm thinking if we could have something similar instead of snap.Info.ExpandSnapVariables(), like a mapped that does this in 'inside' snap mount ns or 'outside' (cc niemeyer)
<mborzecki> s/mapped/mapper/
<zyga> hmmm
 * zyga thinks
<mborzecki> zyga: then for eg. snap.MountNSView().ExpandVariables(info)
<niemeyer> mborzecki: The problem tastes a bit simple for that
<niemeyer> mborzecki: What changes between the two cases, and how often we need either?
<popey> diddledan: that'll be why core18 number of installs rocketed up over the last few days then :)
<mborzecki> niemeyer: yeah, the only use cases now are 'inside' mount ns, so we could go yagni about that just have one function for this (as it is right now)
<niemeyer> mborzecki: !
<diddledan> rocketed?
<diddledan> one snap. yeesh :-p
<popey> one - popular - snap :)
<diddledan> aha
<diddledan> I see what you mean
<diddledan> pics or it didn't happen!
 * niemeyer wants pictures too
<popey> https://snapcraft.io/core18
<popey> look at the distro graph
<diddledan> I don't see a timeline :-(
<MattJ> On a tangent, but the map just reminded me of https://xkcd.com/1138/
<zyga> mvo: it's booting
<popey> MattJ: hah! :D
<pstolowski> niemeyer: hey! will you find a moment today for a quick HO re udev & stop channel?
<zyga> mvo: same as last time
<zyga> mvo: let me look at logs
<niemeyer> pstolowski: Yeah, definitely
<zyga> mvo: same == "snap command not found"
<zyga> I'll enable journal and see what we get
<mvo> xnox: did you get my message about https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 ?
<mvo> xnox: i.e. can/should I sru this or will you do a sru with more changes anyway where this could be included?
<zyga> mvo: I reflashed and created /var/log/journal
<mvo> zyga: meh, that sucks
<mvo> zyga: thanks
<zyga> it failed
<zyga> let me recover the journal after a second, I want to make sure this is written to the card
<mvo> zyga: ta
<mvo> zyga: the error you got a couple of days ago should be fixed so I wonder what is going on
<zyga> mvo: I'll bring it for the sprint
<zyga> sie 31 12:32:18 localhost run-snapd-from-snap[738]: stateengine.go:102: state ensure error: devicemgr: cannot use gadget snap because its base "" is different from model base "core18"
<zyga> mvo: :D
<zyga> let me know if you want another test run
<zyga> mvo: I streamlined my setup so I can test it very quickly
<zyga> there are more errors, I'll give you the full og
<zyga> *log
<zyga> mvo: boot log https://paste.ubuntu.com/p/pkhHBrzFNm/
<zyga> back to coding
<zyga> ping me for another run
<mvo> zyga: thanks, fixing
<Chipaca> ouch, a panic from prepare-image
 * zyga is hungry
<mborzecki> Chipaca: bt?
<mvo> Chipaca: yeah, I saw this a couple of time in the lsat day
<mvo> Chipaca: I pushed a fix for the panic
<mvo> Chipaca: its an open pr, that hopefully gives us clues what is going on
<mvo> Chipaca: 5743 if you look for a simple review ,)
<Chipaca> mborzecki: https://pastebin.ubuntu.com/p/2ZTtNDngWp/
<Chipaca> mvo: nice
<mvo> Chipaca: the question is really why we get into this situation, its impossible :) (well, clearly not but)
<Chipaca> mvo: because it's only added to the map 		if typ == snap.TypeKernel || local.Name(snapName) == baseName {
<Chipaca> mvo: and then it looks in that map for 'snapweb'
<mvo> Chipaca: is it snapweb its crashing for?
<mvo> Chipaca: I thought that was invisilble without the other PR
<mvo> (but maybe I hvae not looked hard enough)
<Chipaca> mvo: it prints "fetching %s" before looking at the map?
<Chipaca> bah, i don't realluy know this code
<Chipaca> so i could have it backwards
<Chipaca> hmm hmm
<Chipaca> mvo: so, with your change, the test will still fail at this point, right?
<mvo> Chipaca: yes
<mvo> Chipaca: it will fail but report on what snap it failed
<mvo> Chipaca: I can add some more code to diagnose this I think
<mvo> Chipaca: heh, you suggested this too :) let me add it
<Chipaca> mvo: +1'ed, but yeah
<mvo> Chipaca: ta
<zyga> re
 * Chipaca ~> lunch
<mborzecki> niemeyer: https://github.com/snapcore/snapd/pull/5749
<jdstrand> zyga: hey, I'm not really here. I didn't get to the /mnt PR yesterday but will try today
<zyga> jdstrand: hey
<zyga> jdstrand: mvo and I decided to merge it (ahead of an important release) but if you find anything we will do a point release
<zyga> sorry about that, I hope that's okay
<zyga> jdstrand: so take your holidays for real and let's do this next week
<xnox> mvo, there is an sru outstanding to do, yes.
<xnox> mvo, however, it appears that snapd is failing autopkgtests now that said patch is in, in cosmic-proposed.
<xnox> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/s/snapd/20180830_184959_a6800@/log.gz
<xnox> 2018-08-30 18:49:42 Failed tasks: 1
<xnox>     - autopkgtest:ubuntu-18.10-amd64:tests/main/dirs-not-shared-with-host:alternatives
<xnox> mvo, as if i should back that change out.... if it is related.
<zyga> mborzecki: less than 20 errors left, brace yourself for that long code review :D
<mvo> jdstrand: who else can approve snaps? I have some gadgets with "base: core18" that neeed approval
<mvo> xnox: its not related I will push a fix for this
<mvo> xnox: its a core snap change
<xnox> mvo, oh, ok!
<xnox> mvo, that's good =) cause it means i need not to back out things in systemd package then!
<mvo> xnox: yeah, I'm very happy if the fix is included too :)
<diddledan> wheee
<diddledan> all those failed-to-release: https://www.youtube.com/watch?v=0BHQT3Omqtw
<diddledan> err
<diddledan> wrong link
<diddledan> file:///home/dllewellyn/Pictures/Screenshot_20180831_132719.png
<diddledan> bah
<diddledan> THIS TIME! https://usercontent.irccloud-cdn.com/file/hKp3lTzL/Screenshot_20180831_132719.png
<mvo> diddledan: i had some store upload rejections as well, mine were some new fields from snapcraft iirc
<zyga> mborzecki: it's green :)
<zyga> mborzecki: I'll chop it
<diddledan> https://www.youtube.com/watch?v=TkZFuKHXa7w
<diddledan> ^^ without comment
<cachio> mvo, hey
<cachio> https://paste.ubuntu.com/p/Gr835VXzcF/
<cachio> did yo see that error on master?
<mvo> cachio: yes
<mvo> I pushed a PR to make it more obvious what is going on
<cachio> mvo, great, thanks
<mvo> cachio: 5743 - its ready
<mvo> cachio: that hopefully gives us a clue
<mvo> cachio: what is going on there
<mvo> cachio: I saw it a couple of times today and yesterday
<mvo> diddledan: let me try to find out what is going on with the rejections - do you also get it for nknown keys in snap/manifest.yaml: snapcraft-os-release-id
<diddledan> no idea why it's failed to release
<diddledan> everything appears normal
<diddledan> for example, micropolis failed to release, but: https://usercontent.irccloud-cdn.com/file/eZSJeaNF/Screenshot_20180831_134635.png
<cachio> mvo, yes it started yesterday suddenly, some branches without any change started failing
<diddledan> gimp just got rejected with "unknown keys in snap/manifest.yaml: snapcraft-os-release-id,snapcraft-os-release-version-id,snapcraft-version lint-snap-v2_snap_manifest"
<zyga> brb, see you at the call
<mvo> diddledan: yeah, I had the same
<diddledan> apparently I singlehandedly skyrocketed the number of core18 installations (according to popey )
<diddledan> I call shenanigans
<diddledan> as if my gimp is really _That_ popular!?!
<popey> "skyrocketed" :D
<diddledan> oh, right, so in the last 3 days 77 thousand people have updated to core18ified gimp...
<diddledan> htf have I managed to become influential to 100k people?!
<popey> Turns out people like gimp. who knew? :)
<diddledan> nuts
<diddledan> left with no comment: https://usercontent.irccloud-cdn.com/file/gOjXXEh5/Screenshot_20180831_141513.png
<diddledan> actually, question regarding that, is nil gonna be treated as string 'nil' or as no-value?
<diddledan> I wanted it to be no-value
<diddledan> i.e. don't you dare think of giving me a base damn you!
 * diddledan hacks all the things
<Son_Goku> mvo, zyga: https://github.com/snapcore/snapd/pull/5750
<Son_Goku> mvo, also, your script for generating changelogs is broken
<Son_Goku> I had to add the "- New upstream release <version>" line for the last few changelog entries
<zyga> Son_Goku: shall we sort the changelogs like I did in suse?
<zyga> I need to update my script
<Son_Goku> sort them?
<zyga> the dates are broken
<zyga> at least in suse they were, due to various historic mistakes
<Son_Goku> yeah
<Son_Goku> the dates and authors need to be fixed
<zyga> https://gitlab.com/zygoon/rpmtools
<Son_Goku> I thought about fixing it the last time I went in and whacked the changelogs
<Son_Goku> err fixed the suse packaging
<zyga> just need to handle embedded changelogs
<Son_Goku> changes format changed last week
<Son_Goku> zyga: spot the difference: https://build.opensuse.org/package/view_file/system:packagemanager:dnf/dnf/dnf.changes?expand=1
<mvo> Son_Goku: thanks, in a meeting right now, but thanks for the PR - and sorry for the broken script I have a look and fix it
<zyga> Son_Goku: in a meeting, but I will look after
<Son_Goku> mvo, zyga, clearly you're both in the same meeting :P
<zyga> yep
<zyga> standup
<Son_Goku> zyga, also: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html-single/7.6_release_notes/#BZ1461652 & https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html-single/7.6_release_notes/#BZ1564775
<niemeyer> cachio: uploaded
<cachio> niemeyer, tx
<zyga> Son_Goku: how do the two rhel notices you linked to affect us?
<Son_Goku> zyga, well, the first one means that the code I'm writing for integration in fedora infra will work for producing centos7 base snaps eventually
<Son_Goku> as for the second one, I'm not sure, it sounds like something we might want?
<Son_Goku> at least with the mmap() support, that means that the policy will compile again on el7
<Son_Goku> zyga, it seemed like the socket stuff is something along the lines of what the socket mediation stuff in apparmor does
<zyga> Son_Goku: apparmor does packet inspection (so to speak)
<zyga> more like a firewall than a traditional "you can or cannot use that socket" control
<Son_Goku> ah
<zyga> but I understand what you meant now
<mvo> diddledan: I got feedback about the store rejections, they are working on it and it should be back to normal soon. out of curiosity, is your gimp snap core18 based?
<diddledan> yes, it is
<mvo> diddledan: thanks for confirming. it looks like only the 18.04 build env is currently in unhappy land
<diddledan> hence 77k new core18 downloads this week :-p
 * mvo hugs diddledan 
<mvo> diddledan: thats cool
<diddledan> ooh cuddles!
<diddledan> I wanna see the graph of core18 to see what impact that's had overall
<mvo> diddledan: its quite dramatic
<diddledan> I unleashed gimp core18 about 3 days ago IIRC
<mvo> diddledan: yeah and the graph is exploding since :)
<zyga> indeed :)
<mvo> diddledan: nice job
<diddledan> nice
<mvo> Chipaca: 5730 might be interessting for you
<zyga> mvo: beta testers ;)
<mvo> Chipaca: super easy
<diddledan> haha. I hope you were ready ;-p
<mvo> zyga: yeah but to be fair, core18 as a base for normal snaps should be fine
<diddledan> seems stable for gimp's usage
<mvo> diddledan: he is joking, as a base its good
<zyga> yes, I was somewhat kidding
<mvo> diddledan: as a booting image we have some work (but even there its pretty good by now :)
<diddledan> "should"
<diddledan> yey
 * diddledan waits for his pi to automatically upgrade
<diddledan> I'm guessing moving over to the core18 boot image is gonna be a case of many spinning plates
<zyga> flashing bits
<zyga> yes
 * diddledan flashes his bits
<zyga> brb, I need some water, it's getting warm on this side of the house
<mvo> 5743 is trivial and needs a second review
<diddledan> yeah, the sun's just got around to my main window now, too
<Chipaca> mvo: in a mo
<zyga> mvo: shall I squash it
<zyga> or just merge it
<popey> jdstrand: did the snapcraft build get reverted back in launchpad builders?
<popey> jdstrand: we are seeing developers complaining that their snaps are not updating
<mvo> zyga: which one?
<mvo> zyga: just merge unless it has the label
<zyga> 5743
<cjwatson> popey: for xenial builds, yes
<cachio> niemeyer, still failing spread
<popey> cjwatson: ok, thanks
<cjwatson> popey: unless I'm confused about what you mean by "reverted back".  xenial builds are currently running with (effectively) 2.42.1
<popey> well, a working version of snapcraft, which doesn't have the extra metadata which the store rejects
<popey> so <2.43
<cjwatson> indeed
<cachio> niemeyer, I found the problem
<cachio> it works now
<niemeyer> Ah, nice
<zyga> mvo: will you have another dragon image to test today?
<zyga> or can I put it back into the drawer
<mvo> zyga: I will ask the store guys if they can approve my dragon gadget
<Chipaca> mvo: 5730 is about talking to a store proxy through an http proxy?
<mvo> Chipaca: correct
<Chipaca> mvo: why tho
<Chipaca> :-)
<mvo> Chipaca: also about locking
<mvo> Chipaca: oh, if thats not a support configuration I can close the PR
<Chipaca> mvo: I don't know. Maybe sparkiegeek does (but he's away i think)
<Chipaca> mvo: I'll ask
<Chipaca> mvo: seems sane though
<Chipaca> I mean, why would you do it, but if you need to do it, this is what we need to do to let you do it
<pedronis> Chipaca: should also be normal store, no?
<Chipaca> pedronis: 5730 is only about the proxy store
<Chipaca> pedronis: it changes 'newEnoughProxy'
<Chipaca> oh! also getSerial
<Chipaca> darn
<Chipaca> heh
<Chipaca> my bad
<Chipaca> pedronis: thanks
<pedronis> ah, IÂ thought I was confused
<pedronis> it seems consistent at least
<pedronis> and the bit in getSerial might be useful
<Chipaca> yup
<mvo> thanks guys!
<zyga> mvo: did you ask about /etc/lsb something and apparmor?
<mvo> zyga: I did but i figure out I can't deny stat with apparmor
<mvo> zyga: which is a) surprising b) annoying
<zyga> Yes
<zyga> Yes
<zyga> :-)
<Chipaca> mvo: is the prepare-image pr merged?
<mvo> Chipaca: someone merge it I think
<Chipaca> mvo: nice
<Chipaca> mvo: and you merged it into 5730?
<mvo> Chipaca: yes, I think I did
<sergiusens> jdstrand: did you get a chance to look at https://github.com/snapcore/snapcraft/pull/2234/files ? roadmr too maybe
<joc> mvo: Chipaca: could you clear up something for me - i'm wondering what is the mechanism that distinguishes a series 16 Ubuntu Core image from a series 18 Ubuntu Core image - i.e. both could have the core snap from the other installed, but there is something that indicates where to run init + snapd from?
<joc> (also trying to get my terminology correct)
<sergiusens> joc: isn't that described in the model/gadget?
<roadmr> sergiusens: oh so we weren't pushing snaps with a manifest before?
<roadmr> this looks good
<sergiusens> roadmr: we always were, just that the review tools are a bit overzealous about new attributes.
<roadmr> yes, that they are.
<mvo> joc: not sure I get the question, but could you check /etc/os-release?
<roadmr> sergiusens: remember jdstrand is off today and Monday
<joc> sergiusens: possibly, but i was looking around the gadget of an image i'm testing and could see an obvious key that says the is a core18 system
<sergiusens> roadmr: which I think we agreed would be removed. I am not sure all the corner cases for all possible entries for the manifest are covered. I do agree that the review-tools should be strict on what they already know about to be able to generate proper USNs and other tooling
<Chipaca> mvo: I think he's asking, on a core device with core16 and core18 installed, how do we know which one to boot
<joc> yeah that basically :)
<Chipaca> joc: it depends on how good the random number generator of the board is
 * Chipaca runs for the hills
<joc> lol
<Chipaca> joc: the model says which one is the blessed one
<Chipaca> joc: https://forum.snapcraft.io/t/model-assertions-for-core18/6870
<sergiusens> roadmr: the irony in this case is that the review tools are rejecting the keywords Jamie asked me to add :-)
<mvo> pedronis: thanks again for the review for 5583, I think you are right and we need to periodically check if snapd can go into socket activated mode, maybe every 5min?
<sergiusens> well, were, as the review tools are up to date already
<mvo> Chipaca, joc yeah, the model it is
<mvo> zyga: new test dragonboard image is uploading, I let you know once its there
<joc> and that then informs the variables used at boot time to identify which snap to mount?
<Chipaca> joc: yep
<roadmr> sergiusens: it's because they're old tools that don't know those keywords :) haha we've seen this, we can't start sending snaps with new fields until the tools support them :/ makes for some interesting interlock
<joc> Chipaca: ok, thanks, that clears thing a bit for me
<zyga> mvo: cool
<sergiusens> roadmr: the tools already do support them ;-)
<zyga> mvo: did you really compress it this time? :D
<roadmr> sergiusens: aha, but not the version that's in the store :/ that was added recently AIUI (r1122/1123 while the store has 1121)
<roadmr> sergiusens: we've discussed using the review-tools snap so it might be easier to update the tools
<roadmr> sergiusens: haha yes, we haven't embraced the snap :) we had one huge hurdle which was the store being on trusty, that's not true anymore so the road is now open but fraught with peril
<mvo> zyga: new version is up
<mvo> zyga: I did not bother this time
<sergiusens> roadmr: I do not know what rXXXX are, all I see is revision 553 (version 0.48+git) :-)
<zyga> mvo: it's a big difference on both upload and download
<zyga> ETA 52min
<zyga> (on my capped link)
<Chipaca> you know that feeling when you're writing long, hard to read integration-type tests and suddenly realise you could instead just write a unit test and let the rest sort itself out? yeah, that
<zyga> switched to my laptop LTE, it's going to be fast now
<Chipaca> i blame friday
<zyga> 3 minutes
<Chipaca> zyga: is this the same lte that you ate 1TB off of?
<pedronis> mvo: as I said I'm not sure it's a serious problem
<zyga> Chipaca: no, I have ... many
<zyga> Chipaca: the 1TB empty one is slow now
<pedronis> mvo: but wanted to point it out
<zyga> Chipaca: my laptop has 100GB of private plan
<zyga> Chipaca: and my phone has 65GB
<zyga> Chipaca: I also have a pre-paid plan on a backup router with 60GB (pre-paid so I won't use it this way)
<zyga> Chipaca: the polish phone has ... some amount but it's running ubuntu so I never use it
<roadmr> I have 1 GB allowance :~(
<zyga> roadmr: yes comrade ;-)
<zyga> roadmr: I know, US&Canada suck wrt network
<Chipaca> zyga: is your whole house glowing at night
<roadmr> totally
<zyga> roadmr: it's crazy how much network you get here
<roadmr> there's slightly more competition in the US but Canada is horrible
<roadmr> and I live in one on the best provinces for that, others are worse
<zyga> Chipaca: plus each phone (e.g. kid phones) have 10GB at least (probably more, never ran out)
<zyga> roadmr: I wonder if you could get a better deal by roaming from EU sim
<zyga> roadmr: up until recently I had free roaming in US (I didn't check if that's still valid)
<zyga> so my 65GB data, yep, same as back home
<zyga> roadmr: my rural network link I used while on holidays has 100GB of data for 12 euro / month
<zyga> roadmr: and it came with this big ass outdoor modem / antenna + indoor repeater wifi
<roadmr> that's ridiculously cheap hehe
<zyga> roadmr: it also allows you to make wifi-based phone calls so you don't need coverage in your handset
<roadmr> oh I have that as well, never used it though
<zyga> roadmr: works great in the forest
<zyga> I'm very happy with the network here, it's never been this available and cheap
<roadmr> cool :) somewhat envious :)
<zyga> the rural aspect is interesting, is it a side product of covering everything else?
<zyga> (get the last 10% customers?)
<roadmr> sure, and also of the territory being smaller
<roadmr> parts of rural and northern Canada has no coverage, because it' sjust huge
<joc> mvo: i refreshed snapd to edge as the extrausers PR had landed then rebooted - it appears to have fixed those issues i was having - thank you!
<mvo> joc: cool, thanks for confirming
<mvo> sil2100: we may need your console-conf expertise soon again :) zyga has a test image for the dragonboard and it looks like console-conf is segfaulting there, might be related to not having network yet. we are investigating, just a heads up
<sil2100> mvo: hm hm! Symptoms sound familiar to what I was seeing on my pi3
<mvo> sil2100: it looks like its segfaulting
<zyga> it is definitely signal 11
<zyga> it goes all the way up to 11 in a bad way
<zyga> sil2100: let me know if you want any debugging done
<Chipaca> zyga: where was the thing that compared directories?
<zyga> syncdir?
<zyga> syncdir.go
<zyga> osutils
<Chipaca> zyga: thanks
 * zyga hugs Chipaca 
<zyga> :)
<Chipaca> hmmmm
<Chipaca> zyga: didn't we have a thing where we gave it to dirs and it told us what was different?
<zyga> mmmmmmmmm
<Chipaca> zyga: looks like no
<zyga> no, I don't think we had _that_
<Chipaca> zyga: because I see pack_test just doing diff
<Chipaca> which is fine, i'll do that as well
<zyga> we have this thing that compares mount profiles
<zyga> but that's not that
<Chipaca> zyga: diff is _fine_ :-)
<zyga> woot
<zyga> I found the bug :)
<zyga> man :P
<zyga> refactoring
<zyga> old old old refactoring
<zyga> I used an interface
<zyga> and review asked to change that
<zyga> so the only place that cared didn't get updated
<zyga> fixed now!
<zyga> woooot
<Chipaca> pedronis: if overlord.Settle(t) takes more than t, what do i need to poke?
<zyga> ah maciej is off already
<zyga> well, fair enough :)
<zyga> I'll prepare this for chopping
 * Chipaca ~> afk (gym! but tests are running)
<cmars> question about branches & auto upgrades. if i have a snap installed from a branch of edge, and that branch expires, what does auto-upgrade do?
<cmars> would it install whatever's on edge automatically?
<zyga> Chipaca: ^
<zyga> ah
<zyga> cmars: I think it's going to behave as if it was on edge
<cmars> zyga: then i notice the branch expired and i push back to the branch.. would the clients that had this branch installed switch back? or would i have to snap refresh on all the machines/devices to get them back?
<cmars> basically, i needed these devices to stay on the branch, but forgot to keep the branch alive and there was a window where it was gone
<cmars> wondering what kind of mess this might have made..
<Chipaca> cmars: the client is tracking the branch; when it re-opens, it'll get the new thing
<Chipaca> cmars: you can check this: in "snap info", see what "tracking" says
<cmars> Chipaca: ok. that's encouraging.. what if i had an older rev on the edge branch than edge, and when i restore the branch, it's still older than edge, but the branch is there again
<cmars> Chipaca: will the client still switch back to the branch?
<Chipaca> cmars: there is no "older"; there's jsut "is this the current tip"
<cmars> or, would it have autoupgraded to edge in the first place?
<zyga> woooooooooooooooooooooooooot
<zyga>  :D
<zyga> layouts no longer leak
<Chipaca> cmars: if it refreshed while the branch was closed, it would have gone to whatever was current on edge
<zyga> wooot wooot woot
<Chipaca> cmars: also why do you have long-lived branches and not tracks
<Chipaca> :-)
 * zyga is super happy :D
 * Chipaca hugs zyga 
<Chipaca> zyga: EOW right now, on this feeling
<cmars> Chipaca: i don't think tracks existed when we needed different builds. what's a track?
<zyga> I need to chop the code a little but basically https://github.com/snapcore/snapd/compare/master...zyga:fix/trespassing-v2?expand=1 does the right thing
<Chipaca> cmars: https://forum.snapcraft.io/t/using-tracks/6230
 * Chipaca needs to run
<zyga> I'll go for a bike ride with my kids
<zyga> and then polish the diff
<Chipaca> cmars: i'll be back in ~1.5h if you have more qs
<cmars> Chipaca: ok, thanks
 * zyga EODs
<pedronis> Chipaca: usually something is not right
<pedronis> Chipaca: it's more a matter of understanding what is not happening that should or we think should
<pedronis> Chipaca: going over tasks and changes and look at their state, clean state after the timeout might be a good idea
<Chipaca> pedronis: fair enough. I'll take a look at it Monday morning
<Chipaca> now I think I'll just call it a wrap
<diddledan> here's a good one for snapcraft devs to be thinking "wtf is he doing?!" about: `shutil.Error: [('/root/build_gnome-calculator-gentoo/parts/gnome-calculator/src/var/spool/nullmailer/trigger', '/root/build_gnome-calculator-gentoo/parts/gnome-calculator/build/var/spool/nullmailer/trigger', '`/root/build_gnome-calculator-gentoo/parts/gnome-calculator/src/var/spool/nullmailer/trigger` is a named pipe')]`
<diddledan> note that it took several hours to get to that point
#snappy 2019-08-26
<zyga> good morning
<zyga> hey pedronis :)
<pedronis> hi
<mvo> hey pedronis
<pstolowski> mornings
<mvo> hey pstolowski
<mup> PR snapd#7329 opened: snap: explicitly forbid trying to parallel install from seed <Created by pedronis> <https://github.com/snapcore/snapd/pull/7329>
<pedronis> mvo: ^ pstolowski: ^
<pedronis> pstolowski: hi
<mvo> pedronis: ta
<pstolowski> ok
<zyga> mvo: what about https://github.com/snapcore/snapd/pull/7321
<mup> PR #7321: tests: restore dpkg selections after upgrade-from-2.15 test <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7321>
<zyga> I'm not sure how many reviews we need now
<mup> PR snapd#7328 closed: tests: pass --remove to userdel on core <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7328>
<mvo> zyga: its fine from my POV, its not perfect
<zyga> mvo: yeah, I'd like to land it
<mvo> I mean, you pointed out that the tool has flaws
<mvo> but its fine IMO
<zyga> mvo: yeah
<zyga> mvo: do we need zero, one or two reviews on top of this state?
<mvo> zyga: so far this has zero reviewsâ¦ :( let me review it
<mvo> zyga: having one review from !us would be nice I think
<zyga> yeah, I feel the same way
<zyga> it's unclear what the rules say when two people work on something and agree
<mvo> zyga: lets not fuss too much, its a tiny PR and affects only tests. I'm sure if e.g. pstolowski can have a quick look it can land :)
<zyga> +1
<pstolowski> seems i missed my 2 minute window to review this ;)
<pstolowski> ah, it wasa about 7321, looking at it
<zyga> brb
<pstolowski> one comment there, +1
<zyga> re
<zyga> pstolowski: replied
<pedronis> mvo: I archive 2.40 and created the 2.42 lane, I also made cards for the UC20 things I'm working on
<mup> PR snapd#7321 closed: tests: restore dpkg selections after upgrade-from-2.15 test <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7321>
<mvo> pedronis: excellent, thank you
<Chipaca> ullo ullo
<Chipaca> i just popped in to make sure y'all were aware today's a bank holiday so that's why i'm not here
<pstolowski> pedronis, zyga: when we optimize apparmor backend to load multiple profiles in one go we're going to loose the granularity of error handling we have now for the apparmor_parser invocation. at the moment regenerateAllSecurityProfiles just logs an error for a given snap and carries on with the rest (we can still have such per-snap policy for intermediate errors before aa parser is invoked). any toughts on that?
<pstolowski> hey Chipaca
<pstolowski> pedronis, zyga unless we run apparmor parser with --vebose flag and go into business of parsing it's output ('Replacement succeeded for "snap....' gets printed for every successfull profile)
<abeato> mvo, morning! would it be possible to merge https://github.com/snapcore/snapd/pull/7252 now? Also, what about https://github.com/snapcore/snapd/pull/7173 ? Is retriggering the tests needed there?
<mup> PR #7252: interfaces/network-manager: allow using org.freedesktop.DBus.ObjectManager <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7252>
<mup> PR #7173: interfaces: support Tegra display drivers <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7173>
<mvo> abeato: in a meeting, will check in ~1h when they are over
<abeato> mvo, ack, thanks
<zyga> pstolowski: interesting
<zyga> pstolowski: on failure, we can re-run per profile and see what really failed
<pstolowski> zyga: yeah but we need to find out which one failed (for which snap), just log this snap and don't consider entire operation as failed
<zyga> pstolowski: yeah but when the batch fails you can re-try non-batch to reliably get information about those that really failed
<zyga> pstolowski: alternatively
<zyga> pstolowski: we can batch only inside one snap
<zyga> pstolowski: that's less generic but better in terms of our understanding what to do
<zyga> pstolowski: because when things fail, we need to change at the snap-granularity anyway
<pstolowski> zyga: we already pass all profiles of given snap to aa parser (if that's what you mean). but re-trying one-by-one is an interesting idea
<zyga> pstolowski: if it's already per-snap then retrying is not of much use
<zyga> pstolowski: because it partially failed anyway
<zyga> pstolowski: another idea: do it in stages: first compile then load
<zyga> pstolowski: if compilation failed nothing in the system is broken
<zyga> pstolowski: it's easier to reason about the state
<zyga> pstolowski: you can pass a flag to the parser to let it just compile all profiles
<zyga> pstolowski: then you can pass a different flag to ask it to just load binary profiles
<pstolowski>  -d, --debug
<pstolowski>            Given once, only checks the profiles to ensure syntactic correctness.
<pstolowski> zyga: ^ yeah, interesting
<zyga> pstolowski: rather than debug I'd try something like --skip-kernel-load
<pstolowski> zyga: aha! thanks
<zyga> pstolowski: you can use other options to capture the compiled profile into memory
<zyga> pstolowski: or to disk
<niemeyer> Morning all
<mvo> hey niemeyer ! welcome back
<niemeyer> Thanks! Glad to be back
<niemeyer> How're things going?
<mup> PR snapd#7252 closed: interfaces/network-manager: allow using org.freedesktop.DBus.ObjectManager <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7252>
<mvo> niemeyer: going well, thank you!
<niemeyer> I see mup is still going strong
<mvo> niemeyer: some annoying test hickups that we are fighting but its getting better
<mvo> niemeyer: yeah, mup was doing great last week iirc
<mvo> mup: hey, still fine?
<mup> mvo: I apologize, but I'm pretty strict about only responding to known commands.
 * mvo hugs mup
<niemeyer> Nice
<zyga> mvo: found the bug :)
<zyga> mvo: whee
<zyga> core is good
<mvo> zyga: tell me more!
<zyga> mvo: the logic in reset_all_snap was silly wrong
<zyga> I'll send a PR in a moment
<mvo> zyga: ta
<zyga> mvo: two bugs actually
<zyga> in other news, shell is tricky
<ogra> pfft
<zyga> fired one more run to be sure, brb
<zyga> mvo: tl;dr; grep -w is a deception
<zyga> mvo: - is a word separator
<zyga> mvo: dont-remove-this-snap-core18 matches against grep -w core18
<mvo> zyga: woah, nice find
<zyga> mvo: https://github.com/snapcore/snapd/pull/7330
<mup> PR #7330: tests: fix removal of snaps on ubuntu-core <Created by zyga> <https://github.com/snapcore/snapd/pull/7330>
<mup> PR snapd#7330 opened: tests: fix removal of snaps on ubuntu-core <Created by zyga> <https://github.com/snapcore/snapd/pull/7330>
<mup> PR snapd#7331 opened: tests: move interfaces-contacts-service to /tmp <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7331>
<zyga> ohh, a new PR label
<mup> PR snapd#7332 opened: tests: remove trailing spaces from shell scripts <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7332>
<abeato> mvo, it looks like tests for https://github.com/snapcore/snapd/pull/7173 finally passed :)
<mup> PR #7173: interfaces: support Tegra display drivers <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7173>
<zyga> I need to do some reviews while tests are churning
<mup> PR snapd#7333 opened: tests: fix system version check on listing test for external backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7333>
<zyga> wow, only one test not passing cleanly in main on core16!
<zyga> and a simple one at that
<zyga> unit test failure?
<zyga> https://www.irccloud.com/pastebin/AQb5iDB8/
<zyga> and another one on snap_daemon user
<zyga> https://www.irccloud.com/pastebin/5rYhzSZG/
<zyga> mvo: is that still expected?^
<zyga> or should I get more recent master
<mup> PR snapd#7334 opened: tests: remove locally installed revisions of core <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7334>
<mvo> zyga: the daemon-user in tumbleweed?
<zyga> mvo: that is 16.04
<zyga> mvo: not TW
<zyga> mvo: group removal failed because there's a user using it as primary group
<mvo> zyga: let me check
<zyga> mvo: offtopic: core18 does not leak any more mount points as far as my tests are showing
<zyga> mvo: I'm running a more complete pass but this is fantastic, it's not buggy anymore :
<zyga> mvo: this means both core and classic are clean, only two PRs to review to get there
<mvo> zyga: cool
<mvo> zyga: where is the userdel failure?
<mvo> zyga: I mean, what PR failed ? I want to check the log
<zyga> mvo: I restarted it already
<zyga> mvo: sorry, :/
<jamesh> and then the test suite will be 100% robust? :-)
<zyga> jamesh: no :)
<zyga> jamesh: but that aspect will
<zyga> jamesh: so my test that measures it can be enabled again
<zyga> jamesh: without acting like a mount leak detector
<jamesh> zyga: fyi, I'm in Greece for GUADEC until Thursday (and then flying home until Friday evening).  So I may be slow to respond to activity on my PRs
<zyga> jamesh: enjoy Guadec, I'd love to visit Greece for one :)
<zyga> I'm doing a pass over older PRs, including many that you sent, sorry for the enormous lag
<jamesh> zyga: no problem.  At some point I'd like to go over the work I need to complete for 20.04
<jamesh> dbus activation is still the big one (which hopefully is getting close to unblocked)
<jamesh> there will probably be some xdg-desktop-portal related changes too though
<zyga> jamesh: any interesting portal work that would be of interest for us to integrate with?
 * zyga has some back pain today, should move to laptop
<jamesh> zyga: mostly things that were brainstormed almost a year ago
<zyga> jamesh: as in, they are coming now?
<zyga> after a year of being under development?
<jamesh> I want to give xdg-desktop-portal more information about snaps, which will probably involve adding a hidden "snap" command that takes a pid for a confined app and spits out some machine readable data about the snap
<jamesh> a year of having other priorities
<zyga> jamesh: oh neat
<zyga> jamesh: would it be like snap info --pid=123
<zyga> that then matches that pid to a snap and gives you that kind of information
<zyga> jamesh: my question is mainly: do you need more than what snap info would say
<jamesh> in particular, I want snap name, desktop file ID, possibly presence of network plug
<jamesh> maybe some information about readable/writable paths
<zyga> mmm
<zyga> jamesh: what kind of writable paths do you mean? precise rules or something high-level?
<jamesh> zyga: the main use would be to identify cases where files do not need to be proxied through xdg-document-portal
<zyga> oh, I see
<jamesh> so it's alright if it isn't complete
<zyga> jamesh: would it be ok if it was just a query per path?
<zyga> jamesh: snap internal is-accessible --pid=123 /path/to/file
<jamesh> zyga: perhaps.  I need to get up to speed with that code base again
<zyga> ok
<zyga> thanks for sharing, this is interesting
<jdstrand> pstolowski: ime you don't want to run apparmor_parser so much on all profiles as much as run it only once at the end
<jamesh> zyga: also: what is the best cross platform way to detect if a pid is a snap app?
<jamesh> zyga: the current code is checking AppArmor labels, but that obviously doesn't work for the non AA distros
<jdstrand> pstolowski: ie, snap.foo.bar has 3 interfaces. apparmor_parser it once after all 3 interfaces are connected instead of each time after one is connectedc
<jamesh> the aim is to have something quick to check before shelling out to the "snap internal" command we eventually write
<jdstrand> jamesh: the freezer cgroup atm
<zyga> jamesh: that's a good question
<zyga> jamesh: I'd like that to be an API of snapd, not something that is determined externally
<zyga> jamesh: because e.g. the freezer or apparmor are internal implementation detail
<zyga> jamesh: and that will change
<zyga> jamesh: unless we can come up with a robust way to make that without making any problems
<jamesh> zyga: the flatpak method is to check for a special file in the root directory of the process's mount namespace
<zyga> jamesh: perhaps /proc/PID/root/meta/snap.yaml presence?
<zyga> jamesh: that would be reliable today (except for classic snaps)
<jdstrand> and yes, we should have an api
<zyga> jdstrand: ^ I might even be happy with that being a stable way to check
<zyga> regardless of an API
<jamesh> zyga: treating classic snaps as unconfined is fine for the purposes of xdg-desktop-portal
<jamesh> they effectively are anyway
<pstolowski> jdstrand: right. this is kind of already done for auto-connect on install (landed recently, edge only atm)
<jdstrand> pstolowski: the same goes for snap-seccomp
 * zyga goes to a meeting
<jdstrand> pstolowski: oh! 'kind of'?
<pstolowski> jdstrand: the case i'm trying to cover now is where we regenerate all profiles on startup when system key or templates changed
<pstolowski> jdstrand: 'kind of' in a sense that it's only for auto-connect, not connect in general
<jdstrand> pstolowski: but that includes auto-connect via snap decl too, right?
<jdstrand> (it would be weird if it didn't, but thought I'd ask)
<jdstrand> pstolowski: what about app snap refresh?
<pstolowski> jdstrand: yes, precisely that - when you install a snap, and slots get automatically connected
<jdstrand> pstolowski: is refresh a special case for install?
<pstolowski> otp
<jdstrand> pstolowski: feel free to ping me after
<mup> PR snapd#7331 closed: tests: move interfaces-contacts-service to /tmp <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7331>
<pstolowski> jdstrand: yes, refresh as well, it's special case for install indeed
<pstolowski> jdstrand: but there is atm no improvement if you manually snap connect multiple plugs/slots in one go. this could benefit from similiar optimization (as you suggested; and similiar to auto-connect), the framework for that is already in place and we can tackle it at some point
<jdstrand> pstolowski: oh, I didn't know you could do more than one in one go :) indeed, that could be done. I think the key is once per command, not per snap or per batch of snaps and then you get reasonable optimizing with good error reporting
<jdstrand> pstolowski: doing more than one profile at a time only saves you a fork/exec/tiny overhead which is probably not worth losing the error handling
<jdstrand> at least note atm
<jdstrand> not*
<jdstrand> pstolowski: and this was done for snap-seccomp too?
<pstolowski> jdstrand: yes, this was done on higher level than specific backends, we basically run setup-profiles just once at the right moment
<jdstrand> pstolowski: woo nice! :)
<pstolowski> jdstrand: hmm re apparmor parser, my tests on pi3 suggest we will benefit a lot (3x faster) by running aa parser once over multiple snaps' profiles, did i miss something? see https://forum.snapcraft.io/t/apparmor-parser-performance-on-pi3/12909
<pstolowski> (re error handling i'm sure we can overcome this, per zyga's suggestions)
<jdstrand> pstolowski: so apparmor can do some parallelizing and things for sure... but it seems your --cache-loc is wrong
<jdstrand> pstolowski: it should be /var/cache/apparmor, not /etc/apparmor.d/cache
<jdstrand> the cache's should be invalidated
<jdstrand> (though)
<jamesh> jdstrand: I'll be talking to the freedesktop-sdk folk tomorrow.  Is there anything newer than what you wrote at https://forum.snapcraft.io/t/base-runtime-freedesktop-sdk-runtime-19-08/11153/40?u=jamesh that I should be aware of?
<jdstrand> jamesh: unfortunately not. since the work is unplanned, it is falling behind some other stuff that is planned
<jamesh> fair enough
<jdstrand> jamesh: but, there is a clear path forward
<jdstrand> it's 'just work'
<jamesh> getting to that point is half the battle :-)
<jdstrand> (in terms of implementaion. there are a few process details to sort out, but that isn't a big deal)
<jdstrand> jamesh: ha, yes :)
<zyga> mvo: FYI https://github.com/snapcore/snapd/pull/7316#pullrequestreview-279586840
<mup> PR #7316: tests: add unit tests for cmd_whoami <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7316>
 * zyga goes to rest to avoid the back pain
<mvo> zyga: thanks, looking
<mvo> zyga: nice, thank you!
<jdstrand> pstolowski: your use of snap.* is not accounting for snap-update-ns.*, no? did you find those aren't getting regenerated with ifacemgr?
<mup> PR snapd#7173 closed: interfaces: support Tegra display drivers <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7173>
<pstolowski> jdstrand: indeed, looks like i used the wrong cache path. anyway, that shouldn't matter for the test due to --skip-read-cache, as i was testing the pessimistic scenario only
<pstolowski> jdstrand: and you're right i haven't tested snap-update-ns* profile (it is covered by snapd code, so code is fine)
<jdstrand> I think what is happening here is with the single call you are benefiting from parallel processing
<jdstrand> whereas otherwise it is completely serial
<jdstrand> gimme a second and I can confirm that
<mup> PR snapd#7330 closed: tests: fix removal of snaps on ubuntu-core <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7330>
<jdstrand> right, a pi3 has 4 cpus that can be used
<jdstrand> and so apparmor will used -j4
<jdstrand> right, if I use --max-jobs=1 then I get roughly the same performance as serial
<mup> PR snapcraft#2684 closed: meta: decouple DesktopFile logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2684>
<jdstrand> 33s vs 35s on amd64
<pstolowski> jdstrand: ah, that means it would help on faster machines (originally the problem was reported with fast pc & lots of snaps https://forum.snapcraft.io/t/snapd-causing-lengthy-boot-time/10466), but not on low-end ones that some customers have...
<jdstrand> pstolowski: I commented: https://forum.snapcraft.io/t/apparmor-parser-performance-on-pi3/12909/2
<jdstrand> ps
<pstolowski> jdstrand: thank you, that's useful feedback
<jdstrand> pstolowski: let me dig up one more tidbit. I recall we had perf bugs in Ubuntu when we took all the CPUs and choked boot
<zyga> mvo: another failure, daemon user present, test failed to add it
<ogra> on actual single core HW you will also see I/O saturation that you wont if you use a multicore device and just limit cores
<jdstrand> pstolowski: also, you may find this handy: getconf _NPROCESSORS_ONLN
<ijohnson> jdstradn, pstolowski: fwiw the big problem I remember from a customer device about this is that it takes _ages_ on a low-end ARM CPU to finish the first boot because there's a lot of snaps and a lot of service/commands with a lot of plugs
<mvo> zyga: yeah, I pushed a pr to get to the bottom of this
<ijohnson> jdstrand: sorry ^
<mvo> zyga: its very strange
<jdstrand> pstolowski: right, I remember now. we could make the parser even faster by using a -j value higher than _NPROCESSORS_ONLN, and that was the problem. In Ubuntu, we use _NPROCESSORS_ONLN. *maybe* you want to use _NPROCESSORS_ONLN-1? (you'd want to measure, etc)
<ijohnson> note that device only has one CPU core
<jdstrand> ijohnson: that is already going to be helped tremendously by what pstolowski already did. run the parser once per command rather than once per interface per command
<pstolowski> jdstrand: interesting. we may try to be conservative and paranoid there to start with
<ijohnson> right okay, I missed part of this conversation so I wasn't sure what was being discussed right now :-) I'm sure they will be happy to hear that
<jdstrand> btw
 * jdstrand hugs pstolowski :)
<jdstrand> pstolowski: ok cool. I forgot that the rpi3 had so many cores. parallelizing defintely helps with more cores :)
<ogra> we should really measure on actual HW that was designed as single core though ... faking it like that will make you miss a lot of aspects
<abeato> ijohnson, yes, I am happy to hear that :D
<ogra> (though if the focus is really only on CPU processing thats probably okay ... but for overall performance mesuaring IO should also come into play)
<pstolowski> jdstrand: thanks for looking at this!
<jdstrand> ogra: well, note, on a single core it defaults to -j1. apparmor will use -jNUMBER OF CORES by default. My question is do we want to make that 'minus 1' or something
<jdstrand> no one is suggesting a -j higher than the number of cores (I advocated agaisnt it :)
<ogra> what would minus 1 achieve ? dynamic picking ?
<jdstrand> no no
<ogra> oh, you mean "one less"
<jdstrand> I'm saying 1 core, -j1. 2 cores, -j1, 3 cores, -j2, etc
<ogra> yeah
<jdstrand> yes
<ogra> got it, sorry, slow today
<jdstrand> ie, leave at least one for other stuff
<jdstrand> which is probably quite reasonable for a refresh core scenario
<ogra> if we can we should surely do that since we might have something running in parallel (we have no real control about systemd here  i guess)
<jdstrand> but I'll let others decide
<abeato> jdstrand, or maybe change the nice value for the process, as another option?
<jdstrand> oh, we can do that. calculate the cores (see aforementioned getconf command), add --max-jobs
<jdstrand> abeato: that is an available option as well
 * zyga has lots of back pain and stops to do any reviews too
<zyga> sorry folks, need to break and get better somehow
 * ijohnson relocates, back in ~15 min
<pedronis> mvo: I got this:  https://api.travis-ci.org/v3/job/576683798/log.txt  do I need to merge master again?
<mup> PR snapd#7334 closed: tests: remove locally installed revisions of core <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7334>
<mvo> pedronis: no, this is still under investigation :(
<mvo> pedronis: its strange, let me add some more debug
<cachio> mvo, hey
<mvo> hey cachio
<cachio> mvo, taking a look to the error on core18 I see this
<cachio> https://paste.ubuntu.com/p/9hzczyDQjf/
<cachio> 2.41. instead of 2.41~
<cachio> is it a bug?
<cachio> or we will use dot
<cachio> just to see if I need to change the script
<mup> PR snapd#7336 opened: tests: add debug section to interfaces-contacts-service <Created by mvo5> <https://github.com/snapcore/snapd/pull/7336>
<mvo> cachio: thats a bug
<mvo> cachio: the edge is the correct version
<mvo> cachio: its just the version number though that is wrong in beta, its the right snapd
<mvo> cachio: with the next beta/candidate the version shoud be fine
<cachio> mvo, perfect
<cachio> thanks!
<mvo> cachio: once you are happy with the beta I can push a new version. but we need to make sure of course that it includes all fixes you have for 2.41
<cachio> mvo, sure, I'll push a fix now
<cachio> mvo, that + the fix for listing test should be enough
<cachio> then I have another one but so far I cound't reproduce it
<mvo> cachio: thanks, let me tag the listing one as 2.41
<mup> PR snapd#7332 closed: tests: remove trailing spaces from shell scripts <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7332>
<zyga> Thank you mvo
<mup> PR snapd#7337 opened: tests: re-enable mount-ns test on classic <Created by zyga> <https://github.com/snapcore/snapd/pull/7337>
<zyga> mvo: all stuff fails on travis
<zyga> E: Failed to fetch http://apt.postgresql.org/pub/repos/apt/dists/xenial-pgdg/main/binary-i386/Packages  Writing more data than expected (788347 > 787357)
<zyga> 269
<mvo> zyga: yeah, I noticed - I don't think we can do much, this is in the travis setup itself
<zyga> correct :/
<mvo> zyga: I wonder if #travis is a thing to report issues
<mvo> zyga: but I guess nowdays #twitter is the thing :P
<zyga> I'm sure  they know
<zyga> yeah
<zyga> where the kids and crazy world leaders (or is that that same thing) are
<zyga> mvo: random simple patch from my pile https://github.com/snapcore/snapd/pull/7338
<mup> PR #7338: tests: move restore-project-each code to existing function <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7338>
<mup> PR snapd#7338 opened: tests: move restore-project-each code to existing function <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7338>
<mup> PR snapd#7339 opened: tests: don't look for lxcfs in mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/7339>
<zyga> mvo: cna we unblock  https://github.com/snapcore/snapd/pull/7196
<mup> PR #7196: packaging: use passthrough for type:snapd <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7196>
<pstolowski> cachio: https://github.com/snapcore/snapd/pull/7110 is green and can land?
<mup> PR #7110: tests: new test to check the output after refreshing/reverting core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7110>
<zyga> pstolowski: please hold on
<pstolowski> ok
<mup> PR snapd#7340 opened: tests: adding support for arm devices on ubuntu-core-device-reg test <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7340>
<zyga> pstolowski: I asked two questions there
<zyga> cachio: can you please check those out?
<cachio> zyga, sure
<zyga> Thanks
<zyga> I'm mainly after avoiding network IO
<cachio> pstolowski, yes
<cachio> :)
<cachio> pstolowski, first let me check the questions
<cachio> zyga, answered
<cachio> zyga, thanks for the review, I didn't know about those questions
<zyga> cachio: no worries, I just asked them a moment ago
 * cachio lunch
<zyga> cachio: replied again, sorry for being persistent about this
<mvo> zyga: anything new in the twitter sphere about travis :) ?
<zyga> mvo: sadly no
<zyga> mvo: no status on travis website
<zyga> as in, all is green there
<mvo> booo
<zyga> I'm still in bed so if I don't respond it's me trying to re-orient to get less painful layout
<mvo> zyga: no worries, was just curious
<zyga> oh, mvo is gone  :)
<zyga> https://paste.ubuntu.com/p/Pdx9qmqbdH/
<zyga> some unexpected stuff here
<zyga> but I should break now
<cachio> zyga, ok, let me see how could be changed that
<cachio> zyga, do you know which test is installing a local version of the snap?
<cachio> I found some but in most of the cases we are building the snap as part of the test
<zyga> cachio: I don't remember from the top of my head, I recall seeing some that were installing a snap over itself but it was from "snap pack"
<zyga> yeah
<cachio> zyga, what do you suggest in this case?
<zyga> snap install /var/lib/snapd/snap/core_$rev.snap
<cachio> zyga, ah, ok
<zyga> rev is read from readlink /snap/core/current
<cachio> I'll try that
 * zyga eod
<cachio> zyga, updated
<cachio> :)
<mup> PR snapd#7341 opened: many: introduce package seed and seedtest <Created by pedronis> <https://github.com/snapcore/snapd/pull/7341>
<zyga> travis is back to normal
<ardaguclu_> Hi, there are some FIXME comments in various places, is it ok handling some of them. For instance, "// FIXME: this really should be TypeCore" in the types package
<zyga> ardaguclu_: hey
<zyga> ardaguclu_: yeah, though it's best to try asking first as some are harder or more tricky than others
<zyga> ardaguclu_: but we 100% welcome all participation so please feel welcome :-)
<ardaguclu_> zyga: thanks
<ardaguclu_> creating unit tests and fixing bugs are the best ways to understand snapd codebase efficiently
<ardaguclu_> that's why, I am really happy working these stuff :)
<zyga> There is always something to improve :-)
<zyga> Iâm working on making the integration test suite more robust
<zyga> Mainly by writing tools that detect misbehavior and adjusting tests not to do bad stuff
<ardaguclu_> zyga: you are right, they are definitely not bad stuff.
<arnatious> Hey all - I'm trying to run the code-insiders snap in an 18.04 lxd container and I'm just getting "dropping privs did not work"
<arnatious> That look like a snap error or should I look elsewhere?
<kyrofa> arnatious, it's definitely snap-related (comes from snap-confine if I remember correctly), just not sure what might be causing it. It's not a privileged container, is it?
<arnatious> kyrofa nope
<kyrofa> Hmm. zyga, any idea there? ^
<arnatious> It has nesting enabled, and is being run from `lxc shell --user 1000 --env SHELL=/bin/bash -- sh -c /bin/bash`
<kyrofa> arnatious, nesting shouldn't need to be enabled
<mup> PR snapd#7342 opened: fixme: rename ubuntu*architectures to dpkg*architectures <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7342>
<mup> PR snapcraft#2686 opened: New app handler (command-chain and no wrappers if command allows for it) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2686>
<mup> PR snapcraft#2679 closed: colcon plugin: add ability to ignore packages in workspace <Created by danielwangksu> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2679>
<mup> PR snapcraft#2687 opened: colcon plugin: add ability to ignore packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2687>
<mup> PR snapd#7343 opened: tests: moving tests to nightly suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7343>
<mup> PR snapcraft#2688 opened: Build base types <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2688>
#snappy 2019-08-27
<zyga> good morning
<zyga> arnatious: hey, can you tell me how you created the container and where is it running?
<zyga> arnatious: host info, lxd version, container info, etc
<mvo> hey zyga
<zyga> :)
<zyga> how are you doing?
<zyga> mvo: back to fighting that user test?
<zyga> mvo: meanwhile: https://github.com/snapcore/snapd/pull/7337 is simple and green
<mup> PR #7337: tests: re-enable mount-ns test on classic <Created by zyga> <https://github.com/snapcore/snapd/pull/7337>
<zyga> if you agree it is simple, that is :)
<mvo> zyga: yeah, that and one more flaky one
<Aavar> Where is my config stored when using irssi as a snap?
<zyga> I had a look at the two leaking lets that are on core
<zyga> Aavar: most likely in ~/snap/irssi/current/.irssi
<mvo> zyga: looking at the prs now
<zyga> mvo: and one of them was very puzzling, the one I pasted last night
<zyga> but I'll re-read that with fresh minnd
<zyga> *mind
<zyga> the pastebin is https://paste.ubuntu.com/p/Pdx9qmqbdH/
<zyga> mvo: btw, one surprise from yesterday is ordering of prepare calls
<zyga> mvo: prepare-project-each is before prepare-suite-each
<zyga> I was somewhat assuming that prepare-project-each is like prepare-task-each which doesn't exist
<zyga> mvo: in that pastebin I linked to the part I don't understand is where did the revision 1001 and 1002 come from
<zyga> where normally the revision map shows 36 and similar numbers
<mvo> zyga: from our fake store maybe?
<mvo> zyga: just guessing at this point, we setup a fake store for some tests
<zyga> Ahhh, interesting. That must be it! Thank you
<zyga> hey pedronis
<zyga> I'm just looking at unit test failure in one of your PRs
<zyga> https://www.irccloud.com/pastebin/CKcptuEn/
<zyga> I've seen this a few times recently
<pedronis> weird error, I wonder why is not deterministic
<pedronis> anyway I'm working in that area
<zyga> thanks :)
<pedronis> so don't think you should spend time on it
<zyga> ok
<zyga> I'll focus on review
<zyga> pedronis: https://github.com/snapcore/snapd/pull/7329 can land, I think
<mup> PR #7329: snap: explicitly forbid trying to parallel install from seed <Created by pedronis> <https://github.com/snapcore/snapd/pull/7329>
<mup> PR snapd#7329 closed: snap: explicitly forbid trying to parallel install from seed <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7329>
<pstolowski> hello
<zyga> good morning :)
<mvo> hey pstolowski - goooood morning :)
<mup> PR snapd#7340 closed: tests: adding support for arm devices on ubuntu-core-device-reg test <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7340>
<mvo> zyga: 7338 has conflicts
<mup> PR snapd#7339 closed: tests: don't look for lxcfs in mountinfo <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7339>
<zyga> mvo: on it
<zyga> done
<mup> PR snapd#7335 closed: tests: add check for snap_daemon user/group <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7335>
<zyga> pedronis: https://github.com/snapcore/snapd/pull/7323 is something you should review I think
<mup> PR #7323: features, overlord: make parallel-installs exported, export flags on startup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7323>
<zyga> it deals with feature flags and startup behavior
<pedronis> added to my list
<pedronis> zyga: that failing test is weird
<pedronis> it's broken by design
<pedronis> but a bit unsure why it fails only rarely
<zyga> those kinds are most interesting :)
<pedronis> pstolowski: did you add the MissingBase test to first boot stuff?
<pstolowski> pedronis: checking
<pstolowski> pedronis: yes, TestPopulateFromSeedMissingBase
<pedronis> pstolowski: something is odd with it
<mvo> zyga: 7336 should be an easy review
<pedronis> pstolowski: unasserted goes into seed.yaml, not the snap
<pedronis> but is working anyway, most of the time
<pedronis> but sometimes it fails
<zyga> mvo: mhm
<pedronis> trying to understand why
<pedronis> pstolowski: anyway, mostly pointing out that unasserted: true is in the wrong place
<zyga> mvo: +1
 * zyga reviews https://github.com/snapcore/snapd/pull/7313
<mup> PR #7313: many:  add the start of Core 20 extensions support to the model assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/7313>
<pstolowski> pedronis: hmm, sorry about that, shall i investigate?
<pedronis> pstolowski: no, I'm looking into it
<pstolowski> ok, thanks
<Aavar> thank you zyga ;)
<zyga> Aavar: for what? :)
<pedronis> pstolowski: here's the cleanup/fix, fyi:  https://github.com/snapcore/snapd/pull/7341/commits/709e0bd10c78fc74334d7660c7549647d04d5232
<mup> PR #7341: many: introduce package seed and seedtest <Created by pedronis> <https://github.com/snapcore/snapd/pull/7341>
<pedronis> pstolowski: it was creating variant of local both unasserted and asserted (under the foo* stuff), and sometimes they diverged (not sure why)
<pedronis> pstolowski: anyway, a bit of confusion all around there :)
<pstolowski> pedronis: aaah i see
<mup> PR snapcraft#2688 closed: Build base types <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2688>
<zyga> pedronis: https://github.com/snapcore/snapd/pull/7313#pullrequestreview-280011112
<mup> PR #7313: many:  add the start of Core 20 extensions support to the model assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/7313>
<zyga> mvo: hey
<zyga> mvo: look at this:
<zyga> + getent passwd snap_daemon
<zyga> snap_daemon:x:584788:584788::/nonexistent:/usr/bin/false
<zyga> mvo: full log https://api.travis-ci.org/v3/job/576917244/log.txt
<zyga> 2019-08-27 07:47:28 Error restoring google:arch-linux-64:tests/main/system-usernames-illegal :
<zyga> also suspicious there
<zyga> + snap remove test-snapd-illegal-system-username
<zyga> snap "test-snapd-illegal-system-username" is not installed
<zyga> typo?
<zyga> mvo: this was in https://github.com/snapcore/snapd/pull/7316
<mup> PR #7316: tests: add unit tests for cmd_whoami <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7316>
 * zyga reviews https://github.com/snapcore/snapd/pull/7341
<mup> PR #7341: many: introduce package seed and seedtest <Created by pedronis> <https://github.com/snapcore/snapd/pull/7341>
<mup> PR snapd#7344 opened: snapstate: use strutil.VersionCompare() in checkVersion() <Created by mvo5> <https://github.com/snapcore/snapd/pull/7344>
<mup> PR snapd#7333 closed: tests: fix system version check on listing test for external backend <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7333>
<mup> PR snapcraft#2689 opened: schema: kernel and snapd types do not use bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2689>
<mvo> zyga: nice, thanks, let me check
<mvo> zyga: so the catcher of the test thing did find something
<zyga> indeed
<zyga> look at the log in detail, I'm sure there's something there that's useful
<mvo> zyga: yeah, look
<sergiusens> xnox: mvo does `type: kernel` always require a base or will any kernel snap work with any base?
<sergiusens> mvo: pedronis and from last week, do we want the `type: snapd` to NOT specify a base or do we want it to specify a base (even if none or bare)? (unrelated to using a build-base)
<mvo> sergiusens: I think we do not need a base for snapd, its self contained
<mvo> sergiusens: the kernel is tricky, if it uses hooks it needs a base so that we know how to run the hooks
<mvo> hey Chipaca, good morning!
<Chipaca> mvo: ð !
<mvo> Chipaca: can I pester you with a question already?  I got:
<mvo> $ snap switch test-snapd-assumes --edge
<mvo> "test-snapd-assumes" switched to the "edge" channel
<mvo> Channel edge for test-snapd-assumes is closed; temporarily forwarding to candidate.
<mvo> Chipaca: today which is a bit odd because the edge channel is open (and was open at the time of this message). does that ring any bells?
<Chipaca> mvo: was this in a spread test, or somewhere you have debug logs?
<Chipaca> huh
<mvo> Chipaca: I ran this manually, was doing some exploring about "assumes:" this morning
<Chipaca> it's reproducible
<mvo> cool!
<mvo> zyga: this is a fun issue, the logs show that the snap_daemon user is added *before* test-snapd-illegal-system-username is POSTed to the daemon. very puzzling
<zyga> POSTed?
<zyga> as in installed?
<zyga> whaat?
<zyga> :D
<zyga> mvo: I'll be back soon, let me make some tea
<mvo> zyga: yeah, at least if the journald logs are in order
<mvo> zyga: yeah, no worries, just wanted to share my puzzlement
<Chipaca> mvo: is 381b45e27773eff87bca4f8ed9b96d027bfb8ee5 part of 2.41~pre1 ?
<Chipaca> mvo: i suspect that's the issue
<mvo> zyga: found the issue, its "fun"
<mvo> Chipaca: let me check
<mvo> Chipaca: it is part of 2.41 it seems :/
<Chipaca> mvo: maybe we should back that out until we have time to fix it
<mvo> Chipaca: could we just revert it in 2.41?
<mvo> Chipaca: yeah, I think that makes sense
<zyga> mvo: oh
<zyga> mvo: tell me :)
<mvo> zyga: pr will be up shortly but its easy once spotted
<pedronis> zyga: I tried to answer to some of your model assertion comments
<zyga> pedronis: thanks, let me look
<sergiusens> mvo: so for kernel we will require a base for now (it can be bare)
<zyga> pedronis: I replied to some but it all makes sense
<zyga> pedronis: LGTM and iterate or iterate and LGTM, as you prefer :)
<mup> PR snapd#7345 opened: overlord/devicestate,seed:  small step introduce seed.LoadAssertions and use it from firstboot <Created by pedronis> <https://github.com/snapcore/snapd/pull/7345>
<mup> PR snapd#7346 opened: snapstate: validate all system-usernames before creating them <Created by mvo5> <https://github.com/snapcore/snapd/pull/7346>
<mvo> zyga: ^- thats the one
<zyga>  /o\
<zyga> mvo: did we ship this?
<mvo> zyga: yeah, also kind of annoying that we overlooked this in the code review
<mvo> zyga: well
<zyga> :E
<mvo> zyga: its in beta
<zyga> mvo: should such usernames be made at the time the snap is linked?
<zyga> mvo: I'm looking at this now and it's unclear when this runs
<pedronis> it runs early but this usernames are shared
<pedronis> so they will end up staying around either way
<pedronis> in many cases
<zyga> pedronis: that's okay, I worry that the sequence now is [check-foo, check-users, check-bar]
<zyga> and that check-bar fails but we already acted a little on the system, which feels wrong
<pedronis> as I said, for the current one support user is ok
<pedronis> but when we add more we need to revisit this
<pedronis> it probably merits a TODO in that PR though < mvo
<zyga> mvo: how is the patch making things better tough
<zyga> it's unclear to me
<pedronis> we either create all users or none
<pedronis> we might still fail to install the snap
<pedronis> later
<zyga> ah, indeed
<pedronis> but given that the one support user
<pedronis> is shared
<pedronis> it's not too bad
<pedronis> but it might be worth revisiting at some point
<mvo> pedronis: indeed, let me add this todo
<mup> PR snapd#7347 opened: gadget: do not error on gadget refreshes with multiple volumes <Created by mvo5> <https://github.com/snapcore/snapd/pull/7347>
<zyga> mvo: multi volume as in multi partition?
<zyga> mvo: or multiple disks
<mvo> zyga: multiple disks
<zyga> mvo: do we have customers using that?
<zyga> or is this just a precaution?
<mvo> zyga: we have customers using this and this is breaking ondra
<zyga> +1
<zyga> thanks for explaining
<zyga> mvo: left a suggestion, +1 anyway
<popey_> zyga: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923500#10
<mup> PR #10: Update README.md <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/10>
<zyga> popey_: looking
<popey_> is that comment still accurate?
<zyga> ah that one
<zyga> it didn't move forward, we discussed accepting partial confinement with actual apparmor enabled but it was nacked for existing distributions
<zyga> as we don't have the time to deal with regressions if that broke people
<zyga> that's what the state of this is now
<popey_> Worth updating the bug?
<zyga> it's not a great message but yeah
<zyga> if only updating bugs in debian didn't involve email
<pedronis> mvo: approved #7346 with a comment
<mup> PR #7346: snapstate: validate all system-usernames before creating them <Created by mvo5> <https://github.com/snapcore/snapd/pull/7346>
<mvo> pedronis: thanks, looking in a wee bit
 * Chipaca takes a break
<arnatious> zyga: Container created on Ubuntu 18.04, LXD stable/3.16 snap, container config https://paste.ubuntu.com/p/JrcC89rwN2/
<mup> PR snapd#7348 opened: snapstate,store: check assumes early before downloading the snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/7348>
<mvo> Chipaca: bad news, it seems like reverting 7204 still gives the same error message, I can bisect
<Chipaca> mvo: rats
<Chipaca> mvo: is it actually a regression?
<mvo> Chipaca: not sure, let me try
<mvo> Chipaca: aha, I think I'm a muppet, hold on, let me retest this
<Chipaca> mvo: Rowlf?
<mvo> Chipaca: that sounds about right
<mvo> Chipaca: maybe "beaker" just needs to be renamed to "breaker"
<mup> PR snapd#7349 opened:  snap: revert PR#7204 as breaks `snap switch` output <Created by mvo5> <https://github.com/snapcore/snapd/pull/7349>
<mvo> pstolowski: your input here would be great :)
<Chipaca> mvo: https://www.youtube.com/watch?v=VnT7pT6zCcA
<pstolowski> mvo: oh :( interesting, saying 'stable' instead will be confusing as well
<mvo> pstolowski: aha, this is latest/stale vs stable? the new default-channel stuff?
<mvo> Chipaca: lol - this is great - his expression matches my mood perfectly
<pstolowski> mvo: yes... and with this revert we'll be showing *wrong* (imprecise/misleading) information when the snapd-side logic of keeping the track kicks in
<cachio> zyga, hey, when you have time could you please take a look to #7110
<mup> PR #7110: tests: new test to check the output after refreshing/reverting core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7110>
<cachio> zyga, hope last one
<mvo> pstolowski: meh, ok
<mvo> pstolowski: so we need something else I guess :/
<mvo> pstolowski: there is a spread test in there that might be useful
<mvo> pstolowski: the other parts can probably be removed then
<pstolowski> mvo: thanks, +1 and i'll work on this soon
<mvo> pedronis: I updated 7346 with a unit test, thanks for the suggestion!
<zyga> cachio: in an hour
<cachio> zyga, sure, thanks
<mvo> pedronis: would love your opinion on 7348 too :) but no rush
<pedronis> mvo: finishing lunch break
<mvo> pedronis: yeah, no rush, I will soon have lunch too - I was just surprised how small it was
<pedronis> mvo: commented
<mup> PR snapd#7350 opened: tests: clean snap_daemon user and group on system-usernames-illegal test <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7350>
<mup> PR snapd#7351 opened: tests: retry checking until the written file on desktop-portal-filechooser <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7351>
<xnox> sergiusens:  at the moment, `type: kernel` works with any bases, but which base is used matters. As initramfs.img is build with binaries from the base. Thus one should be specified, and it does matter if it's core16, core18, or core20 cause then the initramfs.img has libc6 and etc. from those matching releases xenial / bionic / $devel
<zyga> re
<pedronis> xnox: the plan is that kernels should use/specify build-base:  not a base:
<xnox> pedronis:  yes, that is good. initramfs.img is self contained / can be used by anyone...... but it matters what it is built out of. More like "Built-Using: bionic" in "dpkg speak", despite having no "Depends:".
<mup> PR snapd#7346 closed: snapstate: validate all system-usernames before creating them <Test Robustness> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7346>
<mup> PR snapd#7352 opened: tests: always say 'restore: |' <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7352>
<zyga> are draft branches visible by default?
<zyga> I meant draft PRs
<zyga> https://github.com/snapcore/snapd/pull/7337 needs a 2nd review
<mup> PR #7337: tests: re-enable mount-ns test on classic <Created by zyga> <https://github.com/snapcore/snapd/pull/7337>
<pstolowski> jdstrand: hey, one correction to what i said yesterday: i was wrong when i said 'snap connect' could also be optimized for multiple connections at once like i did with automatic connections, i misremembered the code that resolves plug/slot names for connect (was thinking we can resolve multiple plugs/slots if you omit connect arguments, but we only resolve a single plug/slot if you omit them)
<ijohnson> has anyone seen debian-sid-64 fail to prepare like this: https://pastebin.ubuntu.com/p/GQjg4jK4rw/ ?
<ijohnson> I've seen it fail to prepare on numerous builds now and it doesn't look like a transient error
<mup> PR snapd#7353 opened: tests: simplify interfaces-account-control test <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7353>
<mup> PR snapd#7354 opened: tests: rename fuse_support to fuse-support <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7354>
<mup> PR snapd#7355 opened: [RFC] interfaces/apparmor: load multiple profiles in a single batch <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7355>
<Chipaca> augh, 2fa
<mup> PR snapd#7110 closed: tests: new test to check the output after refreshing/reverting core <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7110>
<jdstrand> pstolowski: thanks. it sounded like an exciting feature that I missed :)
<pstolowski> jdstrand: :)
<mup> PR snapd#7352 closed: tests: always say 'restore: |' <Simple ð> <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7352>
<zyga> why does it have to be so hot
<mup> PR snapcraft#2674 closed:  file_utils: introduce link_or_copy_files <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2674>
<mup> PR snapd#7203 closed: i18n, vendor, packaging: drop github.com/ojii/gettext.go, use github.com/snapcore/go-gettext <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7203>
<pstolowski> Chipaca: i'm working on a fix for the confusing snap switch message ("Channel %s for %s is closed; temporarily forwarding to..) caused by my #7204; i don't understand the logic of this temporary forward meesage but i assume it's fine to simply skip it for op = "switch" in showDone(), this will basically make "switch" behave as before, modulo the new track/risk behavior that will be shown correctly (thanks to
<pstolowski> showDone)
<mup> PR #7204: cmd/snap: use showDone helper with 'snap switch' <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7204>
<pstolowski> Chipaca: sounds sensible?
<Chipaca> pstolowski: sounds like the quickest way forwards yes
<Chipaca> the logic probably assumes 'refresh'
<pstolowski> Chipaca: ok, thamks
<pstolowski> *thanks
<mup> PR snapd#7356 opened: i18n, vendor, packaging: drop github.com/ojii/gettext.go, use github.com/snapcore/go-gettext (2.41) <Created by mvo5> <https://github.com/snapcore/snapd/pull/7356>
<zyga> pstolowski: could you please do a pass over the three simple PRs I have
<zyga> they are all tiny and I'd love to merge them
<pstolowski> zyga: sure
<zyga> thanks
<zyga> there's one -0,+0 PR :D
<mup> PR snapd#7357 opened: Fix snap switch message <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7357>
<pstolowski> zyga: which one?
<zyga> pstolowski: 7354
<mup> PR snapd#7358 opened: Rename die() -> die_reboot() to fix build failures with LTO enabled <Created by dcermak> <https://github.com/snapcore/snapd/pull/7358>
<zyga> Chipaca: can you look at that, it looks good-ish but I'm worried about it slightly
<Chipaca> zyga: the switch one?
<zyga> no, the die one above
<pstolowski> zyga: did two others, not sure if these were the ones you wanted first. let me know if you need any more
<zyga> pstolowski: that's great, thank you
<Chipaca> zyga: the intention was to use the same die from the lib, wasn't it?
<zyga> Chipaca: original intention or one in this PR
<cachio> zyga, when you have time, could you please atke a look to #7159
<zyga> Chipaca: the original die is not flexible enough
<mup> PR #7159: tests: add functions to make an abstraction for the snaps <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7159>
<zyga> Chipaca: I'm looking at fixing that
<cachio> zyga, and this one also #7256 please
<mup> PR #7256: tests: adding retry command and use it to delete $XDG directory <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>
<zyga> cachio: ok
<cachio> thanks
<zyga> cachio: does retry argument parsing really work correctly?
<zyga> cachio: "$@" is expanded once
<zyga> and it contains all the stuff
<zyga> you can look at "${1:-}", and while that is not empty parse arguments
<zyga> the problem with this method is that it just zooms through all the arguments, shifting some (not the one looked at)
<zyga> ignoring things it doesn't handle
<cachio> checking
<zyga> cachio: please
<zyga> cachio: perhaps it's time to use python :)
<zyga> cachio: there it's trivial
<cachio> zyga, works well
<cachio> zyga, https://paste.ubuntu.com/p/R9mrmSBq65/
<zyga> cachio: what happens when you pass call retry rm foo --max-attempts 2
<cachio> fails
<zyga> cachio: but that's not how it was supposed to work
<cachio> seq: unrecognized option '--max-attempts'
<zyga> cachio: the command was not supposed to be quoted
<zyga> cachio: you call it as retry rm -rf "$XDG"
<zyga> but your example is different
<zyga> I'm not super happy about the parser, I can fix it tomorrow morning
<cachio> that works
<cachio> what fails is when you use --xx at the end
<cachio> zyga, see that https://paste.ubuntu.com/p/XGNy3ZJRgx/
<zyga> cachio: what does shift shifts from?
<zyga> cachio: when you are mid-iteration in that for loop
<zyga> cachio: I thought that shift shifts from the left of the "$@" array
<pedronis> pstolowski: Chipaca: it was very weird that this was landed withotu spread tests: https://github.com/snapcore/snapd/pull/7199/files
<mup> PR #7199: overlord/snapstate: keep current track if only risk is specified <Created by stolowski> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7199>
<pedronis> pstolowski: Chipaca: we should add some
<pedronis> both for refresh and switch
<pstolowski> pedronis: ok, i can work on it
<pedronis> pstolowski: I'm adding a card
<cachio> zyga, don't get you
<zyga> cachio: what's the semantics of shift
<zyga> cachio: and how does it impact the loop
<zyga> cachio: if you have a loop that goes over 1 2 3 4 5 6
<zyga> cachio: and you are at 3
<zyga> cachio: what does shift do?
<pedronis> pstolowski: https://trello.com/c/6oPPAjLD/312-add-spread-tests-for-https-githubcom-snapcore-snapd-pull-7199-for-both-switch-and-refresh
<zyga> cachio: does it remove "3" or "1"
<zyga> cachio: I think the loop and the parser is incorrect
<cachio> zyga, ok, let me check that
<zyga> cachio: I'm not sure if that's "standard" but when I'm doing shell parsing I'd using a while loop
<zyga> cachio: checking to see if there are more arguments in "$@"
<zyga> cachio: looking at the one up front
<zyga> cachio: handling it, shifting it away
<zyga> cachio: terminating argument parsing (typically on --)
<zyga> cachio: or reporting an error
<zyga> cachio: there are some helpers like getopt as well but those don't always have the right precision
<cachio> zyga, https://paste.ubuntu.com/p/C94tCPm6F7/
<zyga> Chipaca: now swap retry argument order
<zyga> er, cachio ^
<zyga> cachio: the parser is wrong because it shifts something else than it is looking at
<zyga> cachio: it shifts "$@" - aka the magic array
<zyga> cachio: it looks at an item out of a snapshot of that array
<cachio> zyga, I dont see in which case it could fail
<cachio> when we change the order of the parameters?
<zyga> cachio: yes, but it's more fundamental, it's just not right in what it is doing
<mvo> pstolowski: with 7357 - should I close 7349 ?
<cachio> zyga, to fix that I should create another array and remove items instead of shift?
<zyga> cachio: I think you can use shift but you must look at the first element at all times
<zyga> cachio: not at the i-th element
<pstolowski> mvo: if we are happy about resolution, yes
<zyga> cachio: but honestly, you can just drop the parsing entirely and hard-code those
<zyga> cachio: or just use python
<zyga> cachio: where such things are easier
<cachio> zyga, rightin python is much easier
<mvo> pstolowski: I close mine for now then, I'm not sure I understand all the implications yet but it looks like your changes are small and targeted so hopefully
<mvo> pstolowski: hopefully all fine
<cachio> zyga, I'll try that
<mup> PR snapd#7349 closed:  snap: revert PR#7204 as breaks `snap switch` output <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7349>
<cachio> zyga, thanks for reviewing the change!
 * cachio lunch
<zyga> cachio: sure
<mup> PR snapd#7356 closed: i18n, vendor, packaging: drop github.com/ojii/gettext.go, use github.com/snapcore/go-gettext (2.41) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7356>
 * zyga breaks to rest until the call later today
<mvo> zyga: thanks for holding the fort later!
<zyga> :)
<pedronis> cachio: this could land https://github.com/snapcore/snapd/pull/7259 but probably needs a master merge to get green
<mup> PR #7259: tests: just build snapd commands on go-build test <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7259>
<mup> PR snapd#7260 closed: tests: add a runtime scripts generation to generate scripts to call functions <Created by sergiocazzolato> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7260>
<mup> PR snapd#7338 closed: tests: move restore-project-each code to existing function <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7338>
<mup> PR snapd#7353 closed: tests: simplify interfaces-account-control test <Simple ð> <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7353>
<cachio> pedronis, merged, waiting for test results in green
<cachio> pedronis, thanks
<mup> PR snapd#7354 closed: tests: rename fuse_support to fuse-support <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7354>
 * ijohnson lunches, bbiab
<mup> PR snapd#7359 opened: overlord/snapstate: check channel names on install <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7359>
<mup> PR snapd#7337 closed: tests: re-enable mount-ns test on classic <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7337>
<mup> PR snapd#7259 closed: tests: just build snapd commands on go-build test <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7259>
<mup> PR snapd#7360 opened: snap: use deterministic paths to find the built deb <Created by sergiusens> <https://github.com/snapcore/snapd/pull/7360>
<sergiusens> mvo: https://github.com/snapcore/snapd/pull/7092#issuecomment-525448848
<mup> PR #7092: packaging: use snapd type and snapcraft 3.x <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>
<sergiusens> mvo: cachio I added a link to a built snapd there ... a comment yay or nay on the snapcraft PR mentioned there would be grand.
<cachio> sergiusens, ok, thanks
<mup> PR snapcraft#2690 opened: remote-build: error when --user is required <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2690>
<mup> PR snapd#7361 opened: tests: enabling ubuntu 19.10-64 on spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7361>
<mup> PR snapd#7362 opened: cmd: unify die() across C programs <Created by zyga> <https://github.com/snapcore/snapd/pull/7362>
<mup> PR snapd#7363 opened: cmd/snap-confine: fix group and permission of .info files <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7363>
#snappy 2019-08-28
<mup> PR snapd#7364 opened: overlord/snapstate: add migration function to fix invalid channel spec <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7364>
<mup> PR snapcraft#2662 closed: windows installer <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2662>
<zyga> good morning
<zyga> good morning pedronis
<pstolowski> morning
<zyga> good morning pawel, mvo
<mvo> hey zyga and pstolowski
<pstolowski> mvo: hey, i'm applaying yours & John suggestions to the snap switch PR; interestingly, snap revert op test is explicitily expecting the "..forwarding" message. wrong test?
<pedronis> mvo: hi, tests/main/install has a weird name, it's really install-fontconfig-cache
<pedronis> I noticed because it apparently confused Ian
<zyga> flock nil pointer failure https://www.irccloud.com/pastebin/W7rNxA82/
<zyga> I'll check that out after breakfast
<pedronis> mvo: anyway, I'm looking/tweaking Ian PRs
<mvo> pedronis: yes, sorry for that
<mvo> pedronis: cool, thanks
<mvo> pstolowski: interessting, maybe it does make sense for revert? worth checking with john when he is around
<mvo> pstolowski: but I think john is right, I was overdoing it a bit in my pastebin suggestion. the unit test might be useful hopefully
<mup> PR snapd#7360 closed: snap: use deterministic paths to find the built deb <Created by sergiusens> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7360>
<pstolowski> mvo: yep, i'll apply your 'equals' test tweak, ty
<mvo> pedronis: 7313 LGTM, do you want to wait for john before merging or is that good?
<pedronis> mvo: I would wait for John to give a look
<mvo> ta
<pedronis> mvo: #7359 can be reviewed,  and hopefully the spread tests are right now
<mup> PR #7359: overlord/snapstate: check channel names on install <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7359>
<mvo> pedronis: great, I have a look now
<mvo> pedronis: thank you!
<mvo> pedronis: about 7364, whats your feeling, should we do it this way or via a patch?
<pedronis> mvo: not sure at all, apparently the store is very very liberal
<pedronis> (which I don't remember it being)
<mvo> pedronis: I see, hm, hm
 * mvo scratches head
<pedronis> mvo: you can send this:  ////18/////stable/////
<mvo> pedronis: meh, "fun"
<mvo> zyga: bad news, "main/mount-ns" failed on master
<zyga> oh, can you show me how?
<mvo> zyga: in the ubuntu-18.04-64 tests
<mvo> zyga: sure, one sec, let me paste the relevant bits
<zyga> do you have a log or was it locally?
<mvo> zyga: its master
<mvo> zyga: https://travis-ci.org/snapcore/snapd/jobs/577710067
<mvo> zyga: https://paste.ubuntu.com/p/wjvW4PrkDk/
<zyga> hmmm
<zyga> I see it
<zyga> it seems LXD test fixes were not enough somehow
<zyga> one moment
<zyga> oh
<zyga> lxd didn't run in that set!?
<mvo> zyga: I don't know, I have not looked deeper yet
<pstolowski> mvo: do you have powers to create a track for test-snapd-tools snap in the store (for the new spread tests i'm preparing)?
<mvo> pstolowski: I think only the store can do this
<mvo> pstolowski: the formal process is to ask in the forum but given that its a test snap hopefully this is a quick one
<mvo> pedronis: I was leaning slightly towards a patch before because it means less things to worry about in snapstate and because its a one-off thing. but no super strong opinion
<pedronis> mvo: we need to chat I think
<pedronis> also with John when he's around
<mvo> pedronis: ok, I have a meeting in 45min but time until then
<pstolowski> mvo: got it, thanks
<pedronis> mvo: Chipaca: hi, let me know when we can chat about /stable
 * Chipaca doesn't like stables
<mvo> pedronis, Chipaca ready when you are, I'm looking at this firstboot_test.go unit test failure we see sometimes
<pedronis> mvo: that's fixed one of my PRs
<pedronis> if it's the MissingBase one
<mvo> pedronis: aha, nice. looking
<pedronis> mvo: Chipaca: going to the standup HO
<Chipaca> i'll be there in a minute
<pstolowski> mvo: i'm gonna request track "2.0" for test-snapd-tools, any objections / suggestions?
<mvo> pedronis: I'm there now - did you fix the issue by using better helpers? or was there someting deeper
<mup> PR snapd#7365 opened: tests: spread test for snap refresh/switch channel and risk switching <Created by stolowski> <https://github.com/snapcore/snapd/pull/7365>
<pedronis> Chipaca: we forgot to mention, this is relevant as well: https://github.com/snapcore/snapd/pull/7359
<mup> PR #7359: overlord/snapstate: check channel names on install <Squash-merge> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7359>
<Chipaca> pedronis: I was just noticing that the path to install lets you get nasty channels into state no problem, only showDone prints the error (once it's too late to abort)
<Chipaca> same for refresh i think
<Chipaca> ugh, 60kB/s download :-(
<pedronis> Chipaca: with that code it shouldn't be the case
<pedronis> Chipaca: anyway, sorry I didn't mention it, but it needs a review, be built on top
<Chipaca> to print the warning and continue the check needs to be done way earlier than snapstate
<pedronis> Chipaca: yes, but snapstate needs to fail if it gets something not normalized
<pedronis> Chipaca: to print a warning we need to do this ins cmd_snap_op, no?
<Chipaca> yep
<zyga> mvo: I have an idea
<zyga> checking it onw
<zyga> *now
<zyga> hmm
<zyga> cannot build spread?
<zyga> cmd/humbox/main.go:170:39: m.HTTPHandler undefined (type autocert.Manager has no field or method HTTPHandler)
<Chipaca> zyga: spread and snapd have different deps
<zyga> should I use separate GOPATH for each thing>?
<Chipaca> probably
<Chipaca> zyga: snapd shouldn't need anything from gopath right now though
<Chipaca> zyga: you might have some old deps in there :)
<zyga> thanks, let me look
<mvo> pedronis: the SeedMissingBase test failure is understood now, s.makeAssertedSnap() makes a local_1.0.snap and snaptest.MakeTestSnapWithFiles() also makes one. but what is signed/used is inconsistent so sometimes (when the second rolls over) the two get out of sync because the second is stored in the squashfs header
<pedronis> mvo: ah
<zyga> mvo: wow
<zyga> nice
<mvo> zyga: predronis fixed all of this afaict in his refactor
<mvo> pedronis: given that 7341 is mostly shuffling things around, should we be ok with a single review? I would love to move forward with 7345
<mvo> pedronis: 7341 probably needs a master merge to get green
<mvo> pedronis: also 7067 seems to be super close, we could do the comments in a followup
<mup> PR snapd#7347 closed: gadget: do not error on gadget refreshes with multiple volumes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7347>
<pstolowski> huh, #7345 was quite a beast
<mup> PR #7345: overlord/devicestate,seed:  small step, introduce seed.LoadAssertions and use it from firstboot <Created by pedronis> <https://github.com/snapcore/snapd/pull/7345>
<mup> PR snapd#7366 opened: interfaces/gpg-keys: Allow access to gpg-agent and creation of lockfiles <Created by ppd1990> <https://github.com/snapcore/snapd/pull/7366>
<zyga> uhgh
<zyga> as soon as I'm done with current stuff I'm looking at xdg-portal-filechooser
<zyga> I restarted that like 20 times
<zyga> today
<zyga> is that even possible, not sure :?
<mvo> pstolowski: its based on another pr
<pstolowski> mvo: allright, i reviewed the entire thing then
<zyga> mvo: I reproduced the bug
<zyga> mvo: it's super surprising!!!
<zyga> mvo: it's not any other test
<zyga> mvo: it's just REBOOT
<zyga> mvo: spread somwhow gets different behavior on 2nd boot
<zyga> mvo: on 1st boot the mount table is different than later on
<zyga> mvo: I think that's because project-prepare doesn't run after reboot
<zyga> mvo: I'll check that
<pedronis> mvo: I think because pstolowski reviewed all of 7345 7341 got two reviews now
<pedronis> mvo: so I'll merge master into it, try to address your comments and it can land
<pstolowski> +1
<mvo> pedronis: thank you!
<mup> PR snapd#7367 opened: snap, cmd/snap: support (but warn) using deprecated multi-slash channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/7367>
<Chipaca> pedronis, mvo, please let me know if this is what you had in mind: ^^^
<pedronis> Chipaca: yessish, but is it missing tests?
<pedronis> I mean I cannot tell it does what is supposed to from the test in cmd_snap_op_test.go
<pedronis> mvo: fun: E: Failed to fetch http://apt.postgresql.org/pub/repos/apt/dists/xenial-pgdg/main/binary-amd64/Packages.bz2  Hash Sum mismatch
<mvo> pedronis: meh, not again
<pstolowski> mvo: question to #7336
<mup> PR #7336: tests: add debug section to interfaces-contacts-service <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7336>
<zyga> brb
<zyga> mvo: and I now understand the origin of the failure as well
<zyga> well, that's that :)
<zyga> mvo: the origin is that on ubuntu we remove lxd on project prepare
<zyga> but since it had executed it left behind its stale state
<zyga> mvo: I'll collect some tangible proof for the commit message and have a solution shortly
<mup> PR core18#138 opened: Use snapcraft's now-non-default destructive mode for building on travis <Created by sil2100> <https://github.com/snapcore/core18/pull/138>
<Chipaca> pedronis: ah, i started writing a unit test but then realised it was almost the same as an existing one so i modded that, but maybe it's not super clear
<pedronis> Chipaca: it's not clear at all, I expected the reverse
<pedronis> also a test about this would have /stable in it, no?
<Chipaca> pedronis: the reverse to what?
<pedronis> Chipaca: turning /stable => latest/stable
<pedronis> not turning stable into stable
<pstolowski> cachio: re 7361, what about apt-hooks?
<cachio> pstolowski, hi, yes, testing this right now
<pstolowski> cachio: ah, ok, no worries, i wasn't sure if you saw the question in the PR
<cachio> pstolowski, yes, I am also testing another test which failed
<cachio> I'll push that in a momento
<pedronis> Chipaca: no, I'm not going silly, the warning code in cmd_snap_op is not exercised
<pedronis> at all
<Chipaca> pedronis: ah! hm. I'll fix that.
<Chipaca> i was talking about the code in snap :-)
<pedronis> Chipaca: no, I was talking about the code in cmd_snap_op
<pedronis> anyway travis is not with us today
<mvo> zyga: ta
 * ijohnson pours one out for travis
<ijohnson> morning folks
<pstolowski> hey ijohnson
<mup> PR snapcraft#2691 opened: travis: use apt addon to prevent apt update issues <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2691>
<ijohnson> hey pstolowski
<ijohnson> hey I see this unit test failure on travis but not locally, anybody else seen this? https://pastebin.ubuntu.com/p/SHm3dWhgNP/
<Chipaca> pedronis: pushed unit test for that
<mvo> ijohnson: fixed in one of pedronis prs
<mup> PR snapcraft#2689 closed: schema: build-base support for the snapd type <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2689>
<Chipaca> snap install http --channel=$(printf "/%.0s" {1..65527})stable$(printf "/%.0s" {1..65527})
<mvo> Chipaca: you are having fun?
<mup> PR core18#138 closed: Use snapcraft's now-non-default destructive mode for building on travis <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/138>
<Chipaca> mvo: I hit the limit of my shell before I hit any other limit :-)
<Chipaca> also my patience
<ijohnson> pedronis: can I push a shellcheck fix to #7359 ?
<mup> PR #7359: overlord/snapstate: check channel names on install <Squash-merge> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7359>
<pedronis> ijohnson: yes
<ijohnson> ack, one moment
<pedronis> Chipaca: that's probably for you to review ^ (I touched it too much to do a review myself at this point)
<pedronis> mvo: Chipaca: all the PRs in play are now marked 2.41
<mvo> pedronis: thank you
<cachio> mvo, are you promoting to beta today right?
<mvo> cachio: that was my plan but it seems like we have too much pending in the 2.41, I want to merge them all before I push a new version
<mvo> cachio: so more likely tomorrow
<cachio> mvo, good
<cachio> mvo, thanks for the news
<mup> PR snapd#7368 opened: cmd/snap,image,seed:  move image.ValidateSeed to seed.ValidateFromYaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/7368>
<cachio> zyga, hey, #7256 updated
<mup> PR #7256: tests: adding retry command and use it to delete $XDG directory <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>
<pstolowski> pedronis: can you +1 my request https://forum.snapcraft.io/t/track-request-2-0-for-test-snapd-tools/12965/2 ?
<cachio> zyga, tested on py2 and 3
 * cachio lunch
<pstolowski> thanks pedronis and roadmr !
<roadmr> ;)
<zyga> cachio: thank you, I'll review it soon
<roadmr> pstolowski: your track is ready ð¯
<sergiusens> mvo: cachio did you guys have a chance to see if that snapd I built was correct?
<sergiusens> mvo: can you give a nod on my PR if possible to merge and tag a release?
<pstolowski> roadmr: thank you!
<pstolowski> now i need someone to push something there
<pstolowski> mvo: do you have rights to push test-snapd-snap to the new track?
<Chipaca> ijohnson: i think your patch pr would be cleaner if it built on my pr
<Chipaca> ijohnson: but we're targetting different things :-/
<Chipaca> this'll be fun :-)
<ijohnson> Chipaca: ok, I'll hold off on doing anything more to my patch PR until yours is ready, I am about to leave for the airport in ~20 minutes, so I probably won't be able to do much yet today
<Chipaca> ijohnson: i might merge the two into a pr that targets 2.41
<ijohnson> Chipaca: that's fine with me
<Chipaca> similarly i can take your snapstate pr about this, stack it on the deprecation one, and add a check for that in there, again targeting 2.41
<Chipaca> i'll be taking a break before i delve into that though :-)
<pedronis> Chipaca: sorry, I'm confused, I thought in the end we wante to turn /stable into latest/stable
<pedronis> becauses stable means just switch risk atm
<Chipaca> pedronis: hmm, if that was what we wanted, then I might need to take steps :-)
<Chipaca> pedronis: before we were using one and printing the other, which was wrong
<pedronis> that's why I asked
 * ijohnson is quite confused about what /stable is supposed to be turned into and when
<Chipaca> pedronis: the code that does  mx.Channel = ch.Name  would be wrong though
<pedronis> yes
<Chipaca> ijohnson: quite
<pedronis> ijohnson: the issue is that Channel in states are actual channel,  the channel on the command line are intentions
<mvo> pstolowski: I think so, what snap what track? I can also make you contributor then you can also do it
<pedronis> so conceptually we might not normalize them the same way
<Chipaca> I think turning /stable into latest/stable is OK, although I don't think saying it's just stable would break anything
<pedronis> Chipaca: anyhow
<pstolowski> mvo: test-snapd-tools, track 2.0
<Chipaca> and given that /latest/stable turns into latest/stable, turing /stable to stable might be easier to think of
<mvo> pstolowski: sure, let me look at this
<pedronis> Chipaca: did you get to work on the patch that is really the thing that will break people
<pedronis> there we want to turn /stable in stable
<Chipaca> pedronis: ijohnson has the patch
<pedronis> where?
<Chipaca> https://github.com/snapcore/snapd/pull/7364/files
<mup> PR #7364: overlord/snapstate: add migration function to fix invalid channel spec <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7364>
<pedronis> that's not a patch
<pedronis> it's also not the full normalisation either
<pedronis> I thought I said this
<pedronis> at some point :)
<Chipaca> pedronis: i mean, that's what the patch needs to do (just for every snap)
<Chipaca> pedronis: so i thought i'd build it on that
<pedronis> don't think it's doing the right thing
<Chipaca> hmm, ok
<pedronis> the patch needs to FieldsFunc and join by "/" again
<pedronis> I think
<Chipaca> eh, ok
<Chipaca> i'll do that instead then
<Chipaca> but after my break
<pedronis> ok
<pedronis> sorry, this is confusing
<pedronis> Chipaca: about your other PR, not sure, maybe we should just keep if we get push back when things go to beta or candidate
<pedronis> there is no obvious thing for it to do
<pedronis> still
<ijohnson> pedronis, Chipaca: okay, well feel free to abandon my PR #7364 and go with what Chipaca has or will have, I will check in tomorrow to see what happens but am unable to do anymore work now unfortunately
<mup> PR #7364: overlord/snapstate: add migration function to fix invalid channel spec <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7364>
<ijohnson> BTW I resolved the merge conflict between PR 7367 and 7359, the branch is here: https://github.com/anonymouse64/snapd/tree/channels-with-extra-slashes-with-7359
<mup> PR #7367: snap, cmd/snap: support (but warn) using deprecated multi-slash channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/7367>
<ijohnson> talk to y'all tomorrow
<sergiusens> jdstrand: hey, is this something you can quickly sort "error: snap "review-tools" is not available on edge for this architecture (s390x) but exists on other architectures amd64, arm64, armhf, i386, ppc64el)." ?
<mvo> pstolowski: there are some complications but I'm on it
<kyrofa> noise][1, niemeyer: is this our current doc for brand stores? https://docs.ubuntu.com/core/en/build-store/
<kyrofa> I was surprised to find that on docs.ubuntu.com instead of snapcraft
<mup> PR core18#136 closed: Remove the 60-unminimize motd, identify system as Ubuntu Core 18 <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/136>
<Saviq> pedronis: hey, could you (or one of you snapd masters) suggest what should be done to "clean" snapd's state (without removing the installed snaps or their data)? context: https://discourse.ubuntu.com/t/building-multipass-images-with-packer/12361
<Saviq> thanks! :)
<pstolowski> mvo: ack, ty
<jdstrand> sergiusens: I can enable it. I can't test it, but I can enable it
<mup> PR snapd#7363 closed: cmd/snap-confine: fix group and permission of .info files <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7363>
<jdstrand> sergiusens: done. I'm building it
 * jdstrand crosses fingers
 * zyga still debugs stuff
<sergiusens> jdstrand I will get it tested by clicking on adt-retry
<sergiusens> jdstrand surprised this went away as it used to be working before
<Saviq> jdstrand: hey do you know about ure and uno-libs3 perpetually causing review-tools to barf about 4063-1 and 4102-1?
<Saviq> USNs claim the latest packages (6.0.7-0ubuntu0.18.04.9 in our case) have the fix, but still review-tools is unhappy
<roadmr> poor review-tools ð
<jdstrand> sergiusens: I never built for s390x.... /me hmms
<jdstrand> Saviq: let me look. is it possible you have a revision that is in a channel/track that is lingering without the fix?
<jdstrand> Saviq: what package? multipass? mir-kiosk? I get all the emails for outdated packages and don't see what you see. can you paste?
<jdstrand> sergiusens: fyi, says it'll build in 2 hours
<Saviq> jdstrand: egmde-confined-desktop, I checked the manifest that it has the latest packages
<Saviq> jdstrand: you've got mail
<jdstrand> Saviq: the package name was enough. /me looking
<jdstrand> that is a big snap
<jdstrand> Saviq: 6.0.7-0ubuntu0.18.04.9 < 1:6.0.7-0ubuntu0.18.04.8
<jdstrand> Saviq: snapcraft is dropping the epoch in the manifest
<jdstrand> stage-packages:
<jdstrand> - uno-libs3=6.0.7-0ubuntu0.18.04.9
<sergiusens> jdstrand: wow, that build is sure taking its time to start
<jdstrand> USN has 1:6.0.7-0ubuntu0.18.04.8
<jdstrand> sergiusens: there seems to be a bug in the way that snapcraft is calculating what was staged. likely because snapcraft is parsing the on disk filename of the deb and that filename omits the epoch
<jdstrand> sergiusens: shall I file a bug? if so, where? LP?
<jdstrand> sergiusens: actually, hold on
<sergiusens> jdstrand: was looking as this code base was not fresh
<sergiusens> jdstrand: we use python-apt for this and use .candidate
<sergiusens> I can look deeper, just not right now
<Saviq> jdstrand, sergiusens: ack, filing bug
<jdstrand> Saviq: no, don't
<jdstrand> it turns out that libreoffice is one of those weird packages that uses different versions for the binaries
<jdstrand> Source: libreoffice (1:6.0.7-0ubuntu0.18.04.9)
<jdstrand> Package: uno-libs3
<jdstrand> Version: 6.0.7-0ubuntu0.18.04.9
<Saviq> ah, source vs. package
<Saviq> s/package/binary/
<Saviq> so review-tools needs to take that into account?
<jdstrand> there are limitations to what the review-tools can do since they don't have all the information. I'll see if I can come up with some
<jdstrand> something
<Saviq> kk
<Saviq> shall I file bug for review-tools then?
<sergiusens> epochs are evil!
<jdstrand> Saviq: no real point, I am working on it
<jdstrand> I had another thing I'm working on, so I'll do both. if I need to, I'll fill it
<Saviq> "I had another thing I'm working on, so I'll do both"
<jdstrand> hmm, the usn db has the wrong version (it includes the epoch)
<sergiusens> mvo: what does ~ >>> snap run --strace riot-web
<sergiusens> /var/lib/snapd/snap/strace-static/current/bin/strace: Unexpected wait status 0x8b
<sergiusens> error: exit status 1 mean?
<mup> PR snapd#7350 closed: tests: check snap_daemon user and group on system-usernames-illegal test are not created <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7350>
<roadmr> jdstrand: hm. Review-tools doesn't know about gpio-control interface apparently :( and I'm being asked to allow-{installation,autoconnection} for it for a couple of snaps. Do you know what the deal is with that interface?
<mup> PR snapd#7359 closed: overlord/snapstate: check channel names on install <Squash-merge> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7359>
<mvo> sergiusens: hm, hm, that is an issue with strace usually
<roadmr> jdstrand: I was able to just plonk some json in plugs referring gpio-control, just concerned that tools will be unhappy with it
<jdstrand> what up with all the review-tools stuff today?
 * jdstrand looks
<roadmr> hehe sorry jdstrand  :(
<jdstrand> roadmr: there are several that were added and not documented in the forum either
<roadmr> jdstrand: ð¢
<jdstrand> roadmr: let me add those, fix the icon issue and get you a tag. that may be tomorrow
<mup> PR snapd#7357 closed: cmd/snap: fix snap switch message <Simple ð> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7357>
<mup> PR snapd#7369 opened: overlord/snapstate: check channel names on install (2.41) <Created by mvo5> <https://github.com/snapcore/snapd/pull/7369>
<roadmr> jdstrand: sure thing, no huge rush - I asked code-insiders to re-request manual review but they haven't so far
<jdstrand> degville: hey, fyi, https://forum.snapcraft.io/t/supported-interfaces/7744 is missing packagekit-control and appstream-metadata. it lists gpio-control but without a link
<jdstrand> roadmr: plonking the json is fine. thanks! did you want me to review?
<roadmr> jdstrand: not necessarily, it seems like a straightforward allow-installation: true (and same for allow-autoconnection) and the interface is well-scoped, it's also in a snap for a brand store
<roadmr> no superprivileged shenanigans or anything
<roadmr> (just that when trying to generate the json, I used review-tools which barfed at the interface name - but I wrangled it manually and it was ok)
<jdstrand> roadmr: cool. fyi, ad1045d
<jdstrand> (not a tag)
<roadmr> looked more like a year to me :) only the trailing "d" threw me off
<jdstrand> hehe
<degville> jdstrand: thanks for letting me know! I'll fix it.
<jdstrand> degville: thanks!
<jdstrand> Saviq: it is more involved than a quick fix, so I filed a bug: https://bugs.launchpad.net/usn-tool/+bug/1841848
<mup> Bug #1841848: snap USN notifications reporting binaries with different versions than source as out of date when they are not <review-tools:New> <USN Tool:New> <https://launchpad.net/bugs/1841848>
<jdstrand> Saviq: I'll get it done this cycle (hopefully soon)
<mup> PR snapd#7370 opened: tests: fix ephemeral mount table in prepare-image <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7370>
<zyga> jdstrand: ^ this one took a while to figure out
<zyga> I feel so dumb now
<zyga> jdstrand: it's not a security bug, just a curious thing
<sergiusens> mvo_: fwiw, I am on manjaro
<sergiusens> trying out the snap story over here
<sergiusens> some hits and misses
<zyga> sergiusens: ha, I will no longer accept comments about using macos from you ;)
<zyga> (I'm totally joking)
<sergiusens> zyga: ALL the apps I use are snaps though :wink:
<zyga> sergiusens: I think that's mostly true of me as well, I just use fare fewer apps
<zyga> sergiusens: maybe the browser
<zyga> I use macos browser because it's got my entire state and that's easier
<zyga> anyway :)
<sergiusens> well, then you barely use any snaps!
<sergiusens> chromium and firefox are snaps for me too
<zyga> sergiusens: I spend all my day in an editor and shell
<zyga> shell is not a snap but the editor is
<zyga> sergiusens: yeah but they don't have iphone sync that's good :P
<zyga> sync wins
<sergiusens> emacs is available as a snap
<zyga> sergiusens: I'm using a snap editor
<zyga> sergiusens: (not emacs though)
<sergiusens> nice
<zyga> I need a good editor ;)
<zyga> I use sublime
<zyga> sergiusens: today I only made one patch
<zyga> I feel so tired
<zyga> it's been an exhausting pathc
<zyga> *patch
<jdstrand> zyga: wow. that seemed 'fun'. it was a fun read :) nice work
<zyga> jdstrand: writing that commit message helped
<jdstrand> hehe, they tend to
<zyga> jdstrand: especially since the fix is not that long
<zyga> but was not on our radar for weeks and months
<jdstrand> I like to write documentation before code often times
<zyga> jdstrand: with this fix, again, the mount namespace on classic systems should no longer be flaky
<zyga> but I thought so before
<zyga> the reboot bug caught me totally by surprise
<jdstrand> that mount tool is the tool that keeps on giving
<zyga> jdstrand: indeed
<zyga> jdstrand: I have one new tool like that under development and one more in early stages
<zyga> jdstrand: but thats for later :)
<jdstrand> :)
<zyga> (one detects leaked processes, the other can detect leaks of various kinds by delegating to mountinfo-tool and the new process-tool
<pedronis> zyga: prepare-image ?
<zyga> pedronis: hmm?
<zyga> thunderstorm!
<zyga> shutting my desktop down
<pedronis> zyga: your PR summary contains prepare-image, but I'm not sure how it relates
<zyga> oh, I'll correct it!
<zyga> thanks!
<zyga> fixed
<mup> PR snapcraft#2691 closed: travis: use apt addon to prevent apt update issues in CLA-check <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2691>
 * zyga EODs
<Chipaca> let it be known that I hate patches
#snappy 2019-08-29
<mup> PR snapcraft#2692 opened: internal: unknown apt packages aren't installed <Created by stefanor> <https://github.com/snapcore/snapcraft/pull/2692>
<mup> PR snapd#7272 closed: interfaces/bluez: enable communication between bluetoothd and meshd via dbus <Created by jrigling> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7272>
<mup> PR snapd#7341 closed: many: introduce package seed and seedtest <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7341>
<mup> PR snapd#7336 closed: tests: add debug section to interfaces-contacts-service <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7336>
<mup> PR snapd#7316 closed: tests: add unit tests for cmd_whoami <Created by ardaguclu> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7316>
<mvo> zyga: looks like 7370 has some real spread failurs (just fyi, not urgent :)
<mup> PR snapd#7369 closed: overlord/snapstate: check channel names on install (2.41) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7369>
<mup> PR snapd#7344 closed: snapstate: use strutil.VersionCompare() in checkVersion() <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7344>
<pstolowski> morning
<zyga> mvo: yeah, looking
<zyga> mvo: I tested a smaller subset last night so perhaps there's some outcome of the change
<zyga> that is not handled by the rest of the code
<zyga> ahhh
<zyga> interesting
<zyga> it failed on opensuse 15
<zyga> perhaps unified cgroup does not have that feature there, let me look
<zyga> it's odd that it only _sometimes_ failed though
<zyga> that's very weird
<mup> PR snapd#7371 opened: snapstate: add comment to checkVersion vs strutil.VersionCompare <Created by mvo5> <https://github.com/snapcore/snapd/pull/7371>
<mvo> hey pstolowski and zyga ! good morning
<zyga> btw
<mvo> zyga: aha, yeah, I did not look at what system failed just noticed it looked legit
<zyga> does anyone know what may be behind
<zyga> shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
<zyga> it spams all the logs
<mvo> zyga: I have not seen (at least consciously) this
<pstolowski> mvo, pedronis i think we have at least one more issue wrt track/risks change, see https://forum.snapcraft.io/t/behavior-change-risk-only-channel-specifications-will-not-switch-track/11769/7
<pstolowski> mvo, pedronis related to 2nd part of my reply, one issue is the migration of old state (which i suppose Chipaca's patch will cover?), second is simply `snap install <foo>` which defaults to "stable" in the state and again will be reported as such with v2/snaps tracking-channel (and confuse GUI)
<mvo> pstolowski: indeed, that looks like a problem
<pedronis> pstolowski: I am a bit confused
<pedronis> pstolowski: didn't you discuss this with them under https://github.com/snapcore/snapd/pull/7255 ?
<mup> PR #7255: store: use track/risk for "channel" name when parsing store details <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7255>
<pstolowski> pedronis: yes, and the channels map is as we discussed. but there is also channel name at the top level which i haven't touched (shown in the snippet from Robert in that forum post)
<pedronis> mvo: pstolowski: I start to think that the overall change was premature
<mvo> pedronis: I was wondering the same, if we should just revert it for 2.41
<pedronis> mvo: let's talk after the town hall
<Chipaca> which change?
<pstolowski> Chipaca: track/risk behavior change
<pedronis> Chipaca: https://github.com/snapcore/snapd/pull/7199
<mup> PR #7199: overlord/snapstate: keep current track if only risk is specified <Created by stolowski> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7199>
<pedronis> and all that descended from that
<pstolowski> Chipaca: https://forum.snapcraft.io/t/behavior-change-risk-only-channel-specifications-will-not-switch-track/11769/7
<pedronis> I think we do want that change
<pedronis> but we really need to roll it out a bit more carefully
<pedronis> and right now we are scrambling a bit
<Chipaca> given the amount of work we now see is missing, i agree it looks like it's shorter to roll it back
<pedronis> Chipaca: I also not sure while the change makes sense at the CLI level
<pedronis> whether it makes sense at the API level
<pedronis> which means API tweaks
<pedronis> does gnome-software do refreshes now?
<Chipaca> pedronis: i don't think so
<Chipaca> pedronis: why?
<pedronis> Chipaca: I'm confused why we did #7255 already
<mup> PR #7255: store: use track/risk for "channel" name when parsing store details <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7255>
<pstolowski> pedronis: this was believed to be transparent to the ubu/gnome store as discussed with Robert before, and not requiring any special-casing on their side.. anyway, i'm prepping a revert of all this
<pstolowski> mvo: btw, the test-snapd-tools track 2.0 didn't work?
<mvo> pstolowski: not yet, sry, let me pick this up again
<pedronis> pstolowski: ok, either we should have a chat with mvo and Chipaca to see where we stand
<mvo> pstolowski: its open now
<pstolowski> mvo: \o/ thy!
<Chipaca> pedronis: pstolowski: reverting from 2.41, right?
<pedronis> Chipaca: yes, but we have many pieces to revert, and we need to talk what next
<pedronis> Chipaca: also if you started working on a patch, we will need it at some point, so don't throw it away
<Chipaca> pedronis: was planning on stashing it for now
<Chipaca> pedronis: OTOH i might finish it first, not sure
<pedronis> Chipaca: if you are close, please finish it
<pstolowski> Chipaca: i prepared revert for master with a plan to propose again after fixes. and yes revert for 2.41 as well
<pstolowski> Chipaca: and i'd like to discuss that patch in the light of what was discussed this morning
<pedronis> Chipaca: pstolowski: mvo: does it work to have a HO now?
<pstolowski> pedronis: yes, give me 3 minutes pls
<Chipaca> can i get 10 minutes?
<Psil0Cybin> how the hell do  iget snapcraft working on debian based distros whjen it says / does not have /home
<Psil0Cybin> for the app
<Psil0Cybin> what the hell
<pedronis> Chipaca: yes
<Chipaca> ð
<Chipaca> Psil0Cybin: could you try asking that again please?
<Chipaca> maybe a little less sweary and with more context for us to understand it
<Psil0Cybin> Chipaca, sorry on debian when /home is somewhere else snapd does not work
<Psil0Cybin> and wont install / run an app
<Chipaca> Psil0Cybin: snapd needs homes to be in /home, yes; taht is a limitation of snapd that is unlikely to go away in the short term
<Chipaca> Psil0Cybin: especially because there's no good reason to not have homes in /home, either directly or via bind mounts
<Chipaca> Psil0Cybin: also note the homes need to be always there, ie not automount, not auto-decrypt-on-login
<Psil0Cybin> okay but for example im using kali, how can i use snapd?
<Psil0Cybin> in that case?
<Chipaca> i thought you said you were using debian
<pstolowski> pedronis: ok ready when you are
<Chipaca> Psil0Cybin: kali does many things differently, and breaks/blocks the way we set up confinement
<Chipaca> Psil0Cybin: including confinement of x11 apps for example, they won't work on kali. Also apps that use the network.
<Psil0Cybin> Chipaca, i said debian because kali is debian based?
<Psil0Cybin> okay on that note, what if an application only has insturctions for snapd installs how do i go about obtaining that software?
<pedronis> pstolowski: Chipaca: I made an actual invite
<Psil0Cybin> anyway of getting around that, for example using this guide? (https://miloserdov.org/?p=2448&PageSpeed=noscript)
<Psil0Cybin> ?
<Chipaca> pedronis: thank you
<Psil0Cybin> Chipaca, or are you suggesting im out of luck from community support basically?
<Psil0Cybin> just would like to understand thx
<Psil0Cybin> i am assuming becasue your mia, im just out of luck?
<Chipaca> Psil0Cybin: in a meeting, not mia
<Psil0Cybin> Chipaca, apologies.
<Psil0Cybin> i will wait now, sorry.
<Chipaca> Psil0Cybin: is this with kali from a live cd, or installed?
<abeato> zyga, hey, I'm seeing something weird related to the content interface
<Chipaca> Psil0Cybin: some of the issues we've seen on kali are only on the live cd
<zyga> tell me
<Chipaca> pedronis: could you update the forum to let people (including rob) know we're reverting?
<abeato> zyga, wifi-ap snap shares a socket named $SNAP_DATA/sockets/control
<abeato> zyga, declared in slot as    write:
<abeato>       - $SNAP_DATA/sockets
<pedronis> Chipaca: yes
<abeato> zyga, and used in another snap as 'target: $SNAP_COMMON/sockets'
<abeato> zyga, what I see in the target is $SNAP_COMMON/control , should it not be inside a sockets folder?
<abeato> zyga, all that gets written in  $SNAP_COMMON in the target is seen in $SNAP_DATA/sockets in the provider (wifi-ap)
<pstolowski> pedronis: did you mean to revert also #7359 completely, or just https://github.com/snapcore/snapd/pull/7359/commits/4e54b6d8a2b6ffd1d539abdc9bf4af2438e691c6 ?
<mup> PR #7359: overlord/snapstate: check channel names on install <Squash-merge> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7359>
<zyga> abeato: I understand, give me a moment to finish something here
<abeato> sure
<pedronis> pstolowski: yes
<pedronis> Chipaca: https://forum.snapcraft.io/t/behavior-change-risk-only-channel-specifications-will-not-switch-track/11769/8?u=pedronis
<pstolowski> pedronis: yes - #7359 completely?
<mup> PR #7359: overlord/snapstate: check channel names on install <Squash-merge> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7359>
<pedronis> pstolowski: yes
<pstolowski> pedronis: ok, ty. in that case i think i'll prep 2 reverts, otherwise it'll be slightly bug
<pstolowski> *bug
<pstolowski> *bug
<pstolowski> *big
<pstolowski> grr
<pedronis> pstolowski: thx, please mark me for reviewing those reverts
<mup> PR snapd#7372 opened: overlord/snapstate: revert track risk behavior change for 2.41 <Created by stolowski> <https://github.com/snapcore/snapd/pull/7372>
<mup> PR snapd#7373 opened: overlord/snapstate: revert track risk behavior change <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7373>
<abeato> zyga, fyi, if I change the name of the target from $SNAP_DATA/sockets to something different to the folder in the provider, like $SNAP_COMMON/sockets-wifi-ap, I actually see $SNAP_COMMON/sockets-wifi-ap/control, as expected
<mup> PR snapd#7371 closed: snapstate: add comment to checkVersion vs strutil.VersionCompare <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7371>
<pstolowski> pedronis: i think i'll actually revert all that in same PRs, otherwise resolveChannel change will be annoying to review
<pstolowski> mvo: ^
<Chipaca> mvo: patch patch sent sent
 * mvo hugs Chipaca 
<mvo> Chipaca: thank you
<mvo> pstolowski: thank you as well!
<pstolowski> mvo: sorry, more stuff coming to the reverts you just reviewed..
<mvo> pstolowski: no worries
<mvo> pedronis: 7345 has two +1 and is green, shall I merge?
<mup> PR snapcraft#2693 opened: rust plugin: support for s390x <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2693>
<abeato> zyga, this is the bug: https://bugs.launchpad.net/snapd/+bug/1838537
<mup> Bug #1838537: Analyze wifi-ap's disk usage in SNAP_DATA <snapd:New> <snappy-hwe-snaps:New> <https://launchpad.net/bugs/1838537>
<pedronis> mvo: yes, was about to (will apply couple of tweaks in the later work)
<mvo> pedronis: cool, go for it!
<mup> PR snapd#7345 closed: overlord/devicestate,seed:  small step, introduce seed.LoadAssertions and use it from firstboot <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7345>
<pedronis> mvo: #7368 is the next in that series
<mup> PR #7368: cmd/snap,image,seed:  move image.ValidateSeed to seed.ValidateFromYaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/7368>
 * pstolowski lunch and a walk
 * Chipaca hugs pstolowski 
<abeato> zyga, actually, hold on, I'm not 100% sure that is what is happening
<mup> PR snapd#7364 closed: overlord/snapstate: add migration function to fix invalid channel spec <â Blocked> <Created by anonymouse64> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7364>
<cachio> mvo, hey
<cachio> mvo, is protocol error fixed on 2.41?
<mvo> cachio: it should be, yes
<cachio> mvo, still see this https://travis-ci.org/snapcore/snapd/jobs/578207214#L7054
<mvo> cachio: thanks, let me look
<mvo> cachio: thanks, I cherry-picked one more patch from master, hopefully that fixes it. really good catch!
<cachio> thanks!
 * zyga needs to take half of the day off
<zyga> I must skip standup. Sorry
<zyga> I will catch up in the evening
<pstolowski> hmm google:ubuntu-core-16-64:tests/main/snap-info failure on my revert in master
<Chipaca> pstolowski: can i see?
<pstolowski> Chipaca: https://api.travis-ci.org/v3/job/578294589/log.txt
<Chipaca> pstolowski: you should be able to run that one locally, if it helps
<Chipaca> but
<Chipaca> pstolowski: but
<Chipaca> pstolowski: that's actually broken, now
<Chipaca> pstolowski: I blame mvo
<Chipaca> the test needs fixing, not related to your revert
<pstolowski> Chipaca: ok, good, it got me confused
<Chipaca> :)
<Chipaca> pstolowski: I'll push a pr to fix it
<pstolowski> ty
<Chipaca> pstolowski: you're working on master, yes?
<Chipaca> pstolowski: 7374 has the fix
<mup> PR snapd#7374 opened: tests/main/snap-info: update check.py for test-snapd-tools 2.0 <Created by chipaca> <https://github.com/snapcore/snapd/pull/7374>
<pstolowski> Chipaca: aaa it's because the new track i asked mvo to create :)
<Chipaca> pstolowski: self-inflicted pain i see
<pstolowski> it's really not a great day today
<pstolowski> and super hot here
<pstolowski> #7374 needs second review and it's required to unbreak master
<mup> PR #7374: tests/main/snap-info: update check.py for test-snapd-tools 2.0 <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7374>
<pstolowski> ... and we will need to cherry pick it for 2.41 i suppose
<mup> PR snapd#7343 closed: tests: moving tests to nightly suite <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7343>
<Psil0Cybin> Chipaca, i have it installed
<Psil0Cybin> on my hard drive,i am trying to see if perhaps there is a work around i uninstalled it and purged the install i am wondering if i should  try again?
<Chipaca> Psil0Cybin: where is your home?
<Psil0Cybin> I just had so many errors, after getting snap.d to run it would not run the program i forgot the exact error message, but I am wondering if maybe you had experience before I attempted again?
<Psil0Cybin> Chipaca, its /username
<Chipaca> Psil0Cybin: why?
<Psil0Cybin> instead of /home/username i assume
<Psil0Cybin> no idea
<Chipaca> quite
<Psil0Cybin> default installed it like so
<Chipaca> Psil0Cybin: you can work around that in particular with a bind mount
<Chipaca> Psil0Cybin: shouldn't be a blocker
<Psil0Cybin> Oh amazing! Perhaps you have a guide i can reference too when i install it (i am working from home today -- remote)
<Psil0Cybin> so i appreciate that!
<Chipaca> I do not have a guide, at present
<Chipaca> not enough kali users to write a guide
<Chipaca> Psil0Cybin: but you could write one
<Psil0Cybin> you know what I will its about time i contribute to the community, okay im going to give it an install after a webex meeting and give it a go :)
<Psil0Cybin> Thanks! Chipaca you gave me hope
<Chipaca> Psil0Cybin: i'll be here for anohter couple of hours, otherwise we can continue tomorrow
<Psil0Cybin> thank you Chipaca you are amazing!
 * Chipaca writes that down
<mup> PR snapd#7374 closed: tests/main/snap-info: update check.py for test-snapd-tools 2.0 <Simple ð> <â  Critical> <Created by chipaca> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7374>
<mup> PR snapd#7375 opened: tests: fix snap info test <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7375>
<pstolowski> ^ cherry pick for 2.41
<cachio> mvo, tests on spread https://travis-ci.org/snapcore/spread/builds/578357987?utm_source=github_status&utm_medium=notification
<cachio> mvo, really good news
<cjp256> https://www.irccloud.com/pastebin/6p15warB/ - installing snaps causes my USB devices to exhibit  some strange behavior - effectively disconnects my monitors through my USB-C dock (and maybe they come back without having to unplug). anyone have any ideas on what may be causing that?
<diddledan> cjp256: I bet that's because we do a udev rebuild
<diddledan> I believe we trigger a hotplug or something similar to reparse everything
<pstolowski> yes, we trigger udevadm control --reload-rules and/or a few variants of udevadm trigger ... depending on circumstances
<mvo> cachio: nice
<jdstrand> roadmr: hi! can you pull 20190829-1435UTC?
<roadmr> jdstrand: sure!
<cachio> mvo could you please take a quick look to #7375 ?
<mup> PR #7375: tests: fix snap info test <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7375>
<cachio> mvo, we will need it as part of 2.41 as well :)
<cachio> pstolowski, thanks for the fix
<pstolowski> cachio: credit goes to Chipaca
<mvo> cachio: thanks, cherry picked
<cjp256> thanks diddledan pstolowski, that's helping me narrow it down to which udev calls are doing it :)
<pstolowski> cjp256: this is related to the installation of specific snaps and interfaces (plugs) that they have, some interfaces declare udev rules and interact with udevadm when connected
<pstolowski> mvo: #7375 is already a cherry-pick for 2.41 :)
<mup> PR #7375: tests: fix snap info test <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7375>
<diddledan> I'm eagerly awaiting 2.41 to be in the candidate or stable channels
 * cachio bank
<cjp256> pstolowski: any workaround to preventing the kind of behavior i'm seeing? for me, it pretty much prohibits the use of my usb-c dock when working with snaps, particularly for displays. Probably due to X/gnome, but resorting to unplugging/plugging the displays is only about a 1 in 3 shot of recovering.
<popey> diddledan: what in particular?
<diddledan> popey: code that I added that will enable me to progress with makemkv stabilisation :-)
<cjp256> diddledan: me too :D PROTOCOL_ERROR fix *crosses fingers*
<popey> pstolowski: also, my audio device is on usb and it freaks out when this happens.
<popey> diddledan: nice!
<diddledan> I'm really keen to get makemkv stable :-)
<diddledan> I've had quite a few people requesting it
<cjp256> `udevadm trigger --subsystem-nomatch=input` appears to be the source of the behavior
<cjp256> or perhaps at least one of them
<pstolowski> cjp256, popey : we probably need to revisit our udevadm backend and see if we can restrict that reloading more to specific classes of devices (nb, it is not related to our hotplug support, it has always been like that with our udev backend)
 * pstolowski quick errand, bbiab
<pstolowski> re
<diddledan> fwd
<pstolowski> #7375 needs second +1
<mup> PR #7375: tests: fix snap info test <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7375>
<pstolowski> mvo: and i've requested your re-review on 7373 since there was one more revert after you initial review
<mvo> ok
<mvo> pstolowski: in a meeting right now, will look after it
<cjp256> wrt to my display issues, I think it boils down to trigger subsystem=drm
<cjp256> and triggering it alongside other subsystems at the same time makes breakage much more likely
<diddledan> aww, netflix doesn't like snapped chromium :-(
<roadmr> netflix and chi.. er no :(
<diddledan> not for linux users :-(
<diddledan> s/linux/snap/
<pstolowski> cjp256: would you mind filing a bug report (https://bugs.launchpad.net/snapd) and capture all the details you found?
<mup> PR snapd#7375 closed: tests: fix snap info test <Simple ð> <â  Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7375>
<cjp256> pstolowski: will do
<cjp256> pstolowski: https://bugs.launchpad.net/snapd/+bug/1841971 i'll update it when I figure out anything more, thank you :)
<mup> Bug #1841971: installing and removing snaps triggers display failures <snapd:New> <https://launchpad.net/bugs/1841971>
<mup> PR snapcraft#2693 closed: rust plugin: support for s390x <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2693>
<mup> PR snapd#7376 opened: image,o/devicestate,seed: oops, make sure to clear seedtest helpers <Created by pedronis> <https://github.com/snapcore/snapd/pull/7376>
<mup> PR snapcraft#2692 closed: internal: unknown apt packages aren't installed <Created by stefanor> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2692>
#snappy 2019-08-30
<mup> PR snapcraft#2694 opened: multipass: fix unexpected FileNotFoundError exception in setup_multipass <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2694>
<mup> PR snapd#7376 closed: image,o/devicestate,seed: oops, make sure to clear seedtest helpers <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7376>
<mup> PR snapd#7368 closed: cmd/snap,image,seed:  move image.ValidateSeed to seed.ValidateFromYaml <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7368>
<mup> PR snapd#7373 closed: overlord/snapstate: revert track-risk behavior change and validation on install <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7373>
<mup> PR snapd#7377 opened: patch: add an overlord patch that normalizes channel in state <Created by mvo5> <https://github.com/snapcore/snapd/pull/7377>
<mup> PR snapd#7372 closed: overlord/snapstate: revert track-risk behavior and change validation on install for 2.41 <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7372>
<mvo> hey pedronis ! good morning. I'm releasing 2.41 now (just fyi)
<mvo> pedronis: also - 7067, should this go in or do you want to work on the feedback first?
<pedronis> mvo: I'll work on feedback first, it's not urgent
<pstolowski> mornings
<mvo> pedronis: ok
<mvo> pstolowski: good morning. thanks for your reverts
<mvo> pstolowski: its all in and ready now, 2.41 should be in beta soon (just fyi)
<pstolowski> mvo: sure, np!
<zyga> good morning, sorry for being gone yesterday
 * zyga jumps into coding
<mup> PR snapd#7378 opened: release: 2.41 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7378>
 * pstolowski is doing some bug triaging
<pstolowski> love this one https://bugs.launchpad.net/snapd/+bug/1829229
<mup> Bug #1829229: league of legends snap crashes on entering in the game <snapd:New> <https://launchpad.net/bugs/1829229>
<Chipaca> zyga: https://forum.snapcraft.io/t/hard-coded-absolute-paths/12987?u=chipaca
<zyga> looking
<zyga> thanks
<zyga> brb
<zyga> mvo: I fixed https://github.com/snapcore/snapd/pull/7370 - I'll push the fix after a run of local tests
<mup> PR #7370: tests: fix ephemeral mount table in left over by prepare <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7370>
<mvo> zyga: thanks
<mup> PR snapd#7379 opened: tests: add version-tool for comparing versions <Created by zyga> <https://github.com/snapcore/snapd/pull/7379>
 * zyga needs coffee
<mup> PR snapd#7313 closed: many:  add the start of Core 20 extensions support to the model assertion <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7313>
<pedronis> mvo: got John +1 ^
<mup> PR snapd#7380 opened: debian: set GOCACHE dir during build to fix FTBFS on eoan <Created by mvo5> <https://github.com/snapcore/snapd/pull/7380>
<mvo> pedronis: \o/
 * zyga looks at https://github.com/snapcore/snapd/pull/7218
<mup> PR #7218: tests: measure behavior of the device cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/7218>
 * pstolowski lunch break
<zyga> uh, soo hot
<Chipaca> I like how go's testing package avoids 'testing.Testing' by just calling it 'testing.T'
<Chipaca> what can I call mockbootloader.MockBootloader? :-)
<zyga> Chipaca: could ve testing.It
<zyga> Chipaca: mockbootloader.Bootloader seems more appropriate as a type though
<Chipaca> mockbootloader.Er
<zyga> oh oh
<zyga> mockbootload.Er
<zyga> ;D
 * zyga hides
<Chipaca> mockbootloader.WhoYaMockin
<Chipaca> mockbootloader.YouTalkingToME
 * Chipaca stops going down that one
<mup> PR snapd#7381 opened: seed,image,o/devicestate: extract seed loading to seed/seed16.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7381>
 * Chipaca commits the boring one and goes on to the next chunk
<pedronis> that is a big PR
 * Chipaca looks
<Chipaca> pedronis: is there nowhere non-toplevel for 'seed'?
<pedronis> Chipaca: is not new to that PR
<pedronis> also it's fairly central
<Chipaca> ah i hadnt noticed
<pedronis> if we start worrying about top level packages
<pedronis> I would do something about some other ones
<Chipaca> i do :) but it's not a new worry
<Chipaca> that's part of the reason for this refactor chunk
<pedronis> anyway what I said
<pedronis> Chipaca: we can have a chat about your worry (in general) at some point
<Chipaca> k
<zyga> hmmmm
<zyga> mborzecki will be happy next week
<zyga> woah
<zyga> I'm so happy
<zyga> mvo: I think by and large our cgroup woes are over
<zyga> mvo: some actual work needed but conceptually we're going to have a good and clean way to handle our needs
<ijohnson> morning folks
<pedronis> ijohnson: hi, I'm pushing some small simplications to #7149
<mup> PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
<ijohnson> hi pedronis
<ijohnson> sounds good
<pedronis> Chipaca: ijohnson: can you give a quick look at my last change to snap model: https://github.com/snapcore/snapd/pull/7149/commits/1a679f945673dd6a864a146f00908cffb1a4ddc8
<pedronis> when you have time
<mup> PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
<ijohnson> pedronis: sure I can look now
<pedronis> ijohnson: I also tweaked separely api_model_test.go, please look what I did there
<pedronis> fyi
<ijohnson> ack
 * Chipaca needs to go see about lunch
<ijohnson> pedronis: reviewed, I think a couple comments around the test behavior would be helpful
<ijohnson> I need to finish breakfast actually, bbiab
<mvo> zyga: nice, great to hear
<diddledan> why do I always read "ack" as "bah"-like, aka a moan or sign of annoyance, instead of "acknowledged"?!
<roadmr> diddledan: it sounds to me like a bird skwawking or something
<diddledan> ack
<diddledan> :-p
<roadmr> ð¦
<diddledan> ð§
<roadmr> ohai tux
<diddledan> :-)
 * roadmr checks calendar... yup, it's Friday
<diddledan> yey!
<diddledan> two new streaming TV series that I've been anticipating have landed today! (Carnival Row on Amazon Prime in the UK at least, and The Dark Crystal on Netflix)
<roadmr> dark crystal? nice!
<diddledan> I guess my evenings are tied up for the foreseeable :-p
<zyga> Chipaca: so
<diddledan> The Dark Crystal Trailer: https://youtu.be/WwcvJTVnUgc
<Chipaca> zyga: so
<roadmr> thanks diddledan ! /me gets out his skeksis tunic and starts making chamberlain skwawks
<zyga> Chipaca: I'll make something cold to drink
<Chipaca> zyga: my main issue is I can't tell whether you're +1'ing with nits, or what
<Chipaca> zyga: your review was wishy-washy :-)
<diddledan> thinking about Netflix, makes me wonder what we're missing in the Chromium snap to support it. Amazon also complains.
<zyga> Chipaca: +1
<zyga> Chipaca: +2 even
<zyga> Chipaca: we can  iterate, that's always better unless there's a clear bug in the  code
<Chipaca> diddledan: does chromium work outside of the snap?
<Chipaca> diddledan: i thought it was widevine
<diddledan> I've not tried that
<Chipaca> i.e. secret google sauce
<diddledan> let me give it a go
 * diddledan apt installs and gets confused at having two chromiums :-p
 * Chipaca wins
<zyga> Chipaca: I'm going for lunch now
<Chipaca> zyga: buen provecho
<diddledan> ok yeah, it fails outside, too
<diddledan> hmm :-(
<diddledan> @Wimpress get googlie onboard to publish the real chrome :-p
<Chipaca> wooo
 * Chipaca merges
<mup> PR snapd#7185 closed: boot, etc.: refactor boot to have a lookup with different imps <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7185>
<Chipaca> zyga: I'll address some of your concerns in the followup that i'm trying to wrap up
<diddledan> interesting: https://packages.debian.org/stretch/chromium-widevine
<pedronis> pstolowski: I did a high-level pass on #7355
<mup> PR #7355: [RFC] interfaces/apparmor: load multiple profiles in a single batch <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7355>
<mup> PR snapd#7378 closed: release: 2.41 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7378>
<mup> PR snapd#7380 closed: debian: set GOCACHE dir during build to fix FTBFS on eoan <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7380>
<zyga> Chipaca: sounds great
 * Wimpress adds a task to my list for diddledan 
<pstolowski> pedronis: ty
<diddledan> \o/
<pstolowski> zyga: was this fixed / understood? https://bugs.launchpad.net/snapd/+bug/1832725
<mup> Bug #1832725: snap refresh failure <snapd:New for zyga> <https://launchpad.net/bugs/1832725>
<diddledan> Wimpress: my hero ð»
<zyga> pstolowski: ah, yes
<zyga> pstolowski: this is a dupe, let me find the other one
<zyga> pstolowski: dedupped
<zyga> thank you
<pstolowski> ty
<zyga> hmmm
<mup> PR snapcraft#2690 closed: remote-build: error when --user is required <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2690>
 * cachio afk
<cachio> for lunch
<zyga> quick update and reboot
<popey> jdstrand: seeing conversations about printing popping up again. Can we please re-visit https://forum.snapcraft.io/t/inkscape-autoconnect-cups-control/8739
<popey> (inkscape)
<popey> 6 months later, no reply, and still complaints from users (and developers) that they can design something and then not print it.
<ijohnson> pedronis: could you add your thoughts you shared this morning from SU to the forum topic on `snap model`: https://forum.snapcraft.io/t/remodeling-to-a-new-model/10477 ?
<ijohnson> pedronis: I'm willing to keep sculpting at the output until it's what we want too
<ijohnson> though I am now starting to think about this code as less of something that's built like a house and more something that's carved away like a marble michaelangelo sculpture :-)
<roadmr> ijohnson: the sculpture is already there, you just have to chisel away the leftover chunks
<ijohnson> exactly
<ijohnson> I should start all PR's with 100000 lines of random chars and just whittle away the diff until I have a masterpiece
<roadmr> ijohnson: meh just train an AI - these days, the artist would be replaced by some machiine learning on michelangel.io
 * ijohnson considers buying michelangel.io and not michelangelo.io
<roadmr> ijohnson: only because there's no .lo TLD
<ijohnson> well also michelangelo.io is $3500/year and michelangel.io is only $45
<roadmr> ouch
<zyga> it's kind of crazy but the temperature is just right, now, to work :)
<pedronis> ijohnson: I'll write something my monday morning there
<ijohnson> pedronis: ack thanks
<ijohnson> so am I good to merge PR #7149?
<mup> PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
<Chipaca> ok peeps, i'm out for a while. Will probably be back later to wrap up. TTFN and have an awesome weekend if I don't see you!
<zyga> ijohnson: thanks for the review, you found a bug indeed :-)
<ijohnson> happy to help zyga :-)
<zyga> ijohnson: updated https://github.com/snapcore/snapd/pull/7379
<mup> PR #7379: tests: add version-tool for comparing versions <Created by zyga> <https://github.com/snapcore/snapd/pull/7379>
<zyga> if you +1 this it would be my highlight of the day :)
<ijohnson> looking now
<ijohnson> zyga: +1'd
<zyga> woot, thank you!
<zyga> back to cgroups :)
 * ijohnson takes a break
<mup> PR snapd#7149 closed: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7149>
<pedronis> ijohnson: ^ I merged it
<mup> PR snapd#7067 closed: overlord/devicestate:  support the device service returning a stream of assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7067>
<ijohnson> thanks pedronis
<B|ack0p> hi
<B|ack0p> everytime i boot into ubuntu 18.04 i face system error report popup
<B|ack0p> error report doesnt give any detail but when i check the logs
<B|ack0p> at the same time i received error report popup these are the possible errors/fails: https://termbin.com/xlo9
<B|ack0p> Time is 22:54
<B|ack0p> many errors like this:
<B|ack0p> Aug 30 22:54:17 uthink-x61 gnome-software[3571]: Failed to load snap icon: local snap has no icon
<B|ack0p> Aug 30 22:54:19 uthink-x61 gnome-software[3571]: Failed to load snap icon: local snap has no icon
<B|ack0p> oh it is same sorry
<B|ack0p> there are 7 same error log as above
<mup> PR snapcraft#2695 opened: spread tests: install package marker into ament index <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2695>
<jdstrand> popey: please note that there was nothing for me to reply to. the vote is cast. it was contentious. I asked for others to rule on it
<jdstrand> popey: I did respond to today's posts
<jdstrand> s/rule/comment/
#snappy 2019-08-31
<mup> PR snapd#7382 opened: osutil: make flock test more robust <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7382>
#snappy 2019-09-01
<mup> PR snapd#7383 opened: Better help text and error message for snapshot commands <Created by galgalesh> <https://github.com/snapcore/snapd/pull/7383>
#snappy 2020-08-24
<mborzecki> morning
<zyga> good morning
<mup> PR snapd#9198 closed: features: add HiddenSnapFolder feature flag <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9198>
<mborzecki> zyga: hey
<zyga> hey :)
<zyga> finally some cold air, eh?
<mborzecki> yeah, much cooler (and nicer)
<mborzecki> later summer/early autumn, cold mornings/evening, warm during the day
<mborzecki> s/later/late/
<mborzecki> errand, back ~11
<mborzecki> mvo: hey
<zyga> irc, eh,...
<mvo> good morning mborzecki and zyga
<mborzecki> need to run an errand, back ~11 hopefully
<zyga> good morning mvo
<zyga> mborzecki o/
 * zyga waits for Lucy to wake up
 * zyga goes to squash merge https://github.com/snapcore/snapd/pull/7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> just need to think of a proper commit message
<zyga> is anyone else using "git reflog" like the recent call lists on pre-smartphones?
<mup> PR snapd#9204 opened: sandbox: track applications unconditionally <Created by zyga> <https://github.com/snapcore/snapd/pull/9204>
<zyga> ^ this is not yet ready for review
<zyga> I want to see how it affects our tests
<zyga> I'll go do some reviews
<zyga> and then break to handle lucy being awake
<zyga> and should then return for 1:1 and remaining work
<mup> PR snapd#7825 closed: many: use transient scope for tracking apps and hooks <Security-High> <Squash-merge> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7825>
<pstolowski> morning
<zyga> good morning Pawel
<mvo> good morning pstolowski
<pstolowski> o/
<mvo> just fyi (all) 8982 needs reviews, samuele is happy with it on a high level but did not do a full review (not urgent though)
<pstolowski> ack
<pstolowski> mborzecki: hey, i've updated selinux profile in #9084, can you take a look (last commit)?
<mup> PR #9084: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9084>
<zyga> In the office
<zyga> mborzecki hey
<zyga> mborzecki I've proposed a draft that attempts systemd-based app tracking by default
<zyga> and I got a few denials for selinux
<zyga> 1) type=AVC msg=audit(08/24/20 07:27:34.527:12644) : avc:  denied  { getattr } for  pid=78926 comm=snap path=/run/user/0/bus dev="tmpfs" ino=22956 scontext=system_u:system_r:snappy_cli_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=1
<zyga> 2) type=AVC msg=audit(08/24/20 07:27:34.528:12645) : avc:  denied  { write } for  pid=78926 comm=snap name=bus dev="tmpfs" ino=22956 scontext=system_u:system_r:snappy_cli_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=1
<zyga> 3) type=AVC msg=audit(08/24/20 07:27:34.529:12646) : avc:  denied  { connectto } for  pid=78926 comm=snap path=/run/user/0/bus scontext=system_u:system_r:snappy_cli_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1
<zyga> I would appreciate some ideas on how to tackle that
<zyga> those are from fedora 32
<zyga> mborzecki I've added a comment on https://github.com/snapcore/snapd/pull/9204 with the same information
<mup> PR #9204: sandbox: track applications unconditionally <Created by zyga> <https://github.com/snapcore/snapd/pull/9204>
<mborzecki> re
<pedronis> mborzecki: hi, I did a pass on #9201
<mup> PR #9201: [RFC] boot: observe update & rollback of trusted assets <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9201>
<mborzecki> pedronis: thanks, would have some time for a chat later?
<pedronis> mborzecki: before the standup
<mborzecki> pedronis: sounds good
<mborzecki> let me add something
<mborzecki> zyga: looks like this should be covered by dbus chat interfaces
<mborzecki> zyga: let me see if there's something for chattign with systemd specifically
<zyga> thank you!
<mborzecki> zyga: there's a bunch of systemd_dbus_chat in refpolicy but those seem to cover logind, timedated, machined, resolved
<zyga> do we need a new interface or is there a better way out?
<mborzecki> zyga: hm but it's user_tmp_t, can you try adding userdom_write_user_tmp_sockets(snappy_cli_t) to the policy, reload and see what happens?
<zyga> mborzecki sure, I'll try
<pstolowski> mborzecki: heh, my selinux fix worked everywhere except for centos 8. although there i see "type=AVC msg=audit(1598261418.464:4691): avc:  denied  { getattr } for  pid=133098 comm="snapd" path="/var/snap/lxd/common/ns/shmounts"
<mborzecki> pstolowski: why is snapd looking there?
<zyga> mborzecki: probably because "du"
<zyga> to estimate size of the data
<pstolowski> yes exactly
<zyga> in a way we need one-file-system that really means ignore-magic-filesystems
<mborzecki> pstolowski: zyga: there's --one-file-system switch to du
<zyga> but we don't really want that
<zyga> we want to allow people to have other file systems mounted on /var/snap/blargh
<zyga> what we want is to filter out nsfs
<zyga> or procfs
<mborzecki> zyga: should those other filesystems count towards snapshot size?
<pstolowski> that's interesting. i wonder what happens when we do actual snapshot
<zyga> it probably archives an empty file
<zyga> it's a permissive profile
<zyga> it's a bind mount of /proc/PID/ns/mnt to an empty file
<zyga> so the archiver will just see the empty file
<pstolowski> yeah but what about the rest of proc\
<zyga> pstolowski is all of proc mounted in SNAP_DATA?
<pstolowski> zyga: i don't know, re-running to see what happens (it's a lxd snap_
<pstolowski> )
<zyga> pstolowski I think you will only find nsfs
<zyga> the rest of the filesystems are mounted inside that thing
<zyga> it's like a chest for more mounts
<zyga> mborzecki I have one deny left
<zyga> mborzecki I have one deny left
<zyga> type=AVC msg=audit(08/24/20 10:05:41.032:928) : avc:  denied  { connectto } for  pid=29450 comm=snap path=/run/user/0/bus scontext=system_u:system_r:snappy_cli_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1
<zyga> brb
<mborzecki> zyga: ok, so you probably need unconfined_dbus_chat(snappy_cli_t) now
<ijohnson> morning folks
<zyga> hey ijohnson :)
<zyga> mborzecki trying
<mvo> good morning ijohnson
<ijohnson> o/
<ijohnson> mmm have we not had a new snapd edge since 8-22 ?
<mborzecki> zyga: and maybe unconfined_dbus_connect(snappy_clit_t) too
<mborzecki> ijohnson: hey
<ijohnson> or 22-8 for y'all europeans :-)
<pstolowski> hi ijohnson !
<ijohnson> hey pstolowski
<zyga> ijohnson looking
<zyga> yeah
<zyga> it seems so
<ijohnson> smells odd
<zyga> ijohnson snapd had a long weekend? :D
<ijohnson> haha maybe
<zyga> either stuck in moderation or the publish pipeline got blocked somewhere
<mvo> ijohnson: probably no changes in edge since 22 ?
<ijohnson> mvo: ah actually you're right there were a couple commits this morning but nothing over the weekend
<ijohnson> I'm just so used to seeing the snapd snap update every day
<zyga> re
<zyga> ha, does it mean we had a long weekend instead?
<zyga> as in two days without patches
<zyga> ijohnson https://listed.zygoon.pl/17659/introduction-to-bashunit-unit-testing-for-bash-scripts :)
<ijohnson> do we hijack the post-refresh hook for the core* snaps as well as the configure hook ?
<ijohnson> zyga: very cool stuff! that's really nice to see it all come together like that, one thing I wonder though is that in the failure output you have for bashunit you don't see what the actual output of `hello_world` function is before the grep fails, so it's a bit difficult to debug
<ijohnson> zyga: that's probably intristic to using bash however so probably not worth looking into, but I wonder if it would be helpful to have some kind of test util command you can use in the unit test file that saves the output inside pipes only to be displayed on test failure
<ijohnson> zyga: something like `hello_world | echo_on_fail | grep -qFx 'Hello world'`
<ijohnson> just a thought
<ijohnson> I've wanted something like that _so_ many times when looking at spread failures
 * zyga-x240 switches devices
<zyga-x240> mvo: 2.46 branches are red, do you want to merge master or cherry pick all the fixes back>
<mvo> zyga-x240: will merge master to it today
<zyga-x240> ok
<zyga-x240> do 2.46 jamie branches make sense to review then?
<mvo> zyga-x240: no, please not
<mvo> zyga-x240: in a meeting now
<zyga-x240> ok
<mvo> zyga-x240: we can close them
<zyga-x240> mvo: ack, doing that now
<mvo> ta
<mup> PR # closed: snapd#9192, snapd#9193, snapd#9194, snapd#9195
<ijohnson> real simple uc20 PR: https://github.com/snapcore/snapd/pull/9205
<mup> PR #9205: boot/initramfs_test.go: reset boot vars on the bootloader for each iteration <Simple ð> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9205>
<mup> PR snapd#9205 opened: boot/initramfs_test.go: reset boot vars on the bootloader for each iteration <Simple ð> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9205>
<zyga-x240> is shell surprising? https://paste.ubuntu.com/p/FGYyvVXmm8/
<zyga-x240> our || true pattern is dangerous
<ijohnson> wow just wow
<ijohnson> how can such fundamental things in bash be so broken
<zyga-x240> ijohnson: it's documented :)
<zyga-x240> it's a feature
<zyga-x240> just ill-designed IMO
<zyga-x240> I think we can do something like "not"
<ijohnson> didn't we have a NOT in spread ?
<zyga-x240> we have "not" in snapd
<zyga-x240> it's really exactly the same feature in bash that requires it
<diddledan> yes. it's surprising :-) (not what I expect with `set -e`)
<zyga-x240> diddledan: it's just another case of https://listed.zygoon.pl/17629/broken-composition-or-the-tale-of-bash-and-set-e
<diddledan> I guess you need to add set -e inside the function?
<zyga-x240> diddledan: but just seeing the code behave this way is shocking
<zyga-x240> diddledan: no :)
<zyga-x240> diddledan: try that
<zyga-x240> it's ignored
<diddledan> gah
<zyga-x240> the link I referenced explains why
 * diddledan reads it
 * zyga-x240 reviews nested.sh
<diddledan> it's the same with /bin/sh (which in Ubuntu 20.04 is dash, right?)
<zyga-x240> yes
<zyga-x240> it's a very old feature
<diddledan> the `do-something && do-something-on-success || do-something-on-fail` is a common pattern that I've seen all over the interweb
<zyga-x240> diddledan: it all depends on what those are
<zyga-x240> diddledan: also, remove the echo that says "surprising" and it's well, also documented but more surprising
<diddledan> gosh, there's a lot of strange interactions you've highlighted
<zyga-x240> mvo: shellcheck issue (reported in early 2019) https://github.com/koalaman/shellcheck/issues/1484
<zyga-x240> cachio: how much work would it take to make nested.sh a non-sourced script?
<ijohnson> morning cachio
<cachio> zyga-x240, hi, I already did something like that a time ago
<cachio> ijohnson, hi
<zyga-x240> cachio: oh? where?
<cachio> good morning
<cachio> zyga-x240, I closed that a time ago
<zyga-x240> why?
<cachio> I need to open it again
<cachio> because there were too many changes
<zyga-x240> I'm reading https://github.com/snapcore/snapd/pull/9098 and I'm very worried about bugs
<mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
<zyga-x240> well, we can start small
<cachio> Iand I decided to create a new change to address that
<zyga-x240> but I think we must go that way
<cachio> I could make it again
<zyga-x240> please start small
<cachio> it could be a tool
<zyga-x240> prepare/restore + execute
<zyga-x240> yeah, I think sourcing is a no-go
<zyga-x240> port a single test (keep nested.sh as-is)
<zyga-x240> over time it will replace the other
<cachio> zyga-x240, ok, makes sense
<zyga-x240> cachio: why is execute remote using "$*"?
<zyga-x240> https://github.com/snapcore/snapd/pull/9098/files#diff-3af5dfa44ec70d885e9485dbb117f52fR844
<mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
<cachio> zyga-x240, it is very old
<cachio> zyga-x240, I think federico created that
<zyga-x240> I think that's wrong
<cachio> and nobody updated that
<zyga-x240> and I suspect it's broken with regards to quoting
<zyga-x240> cachio: I did a quick pass over https://github.com/snapcore/snapd/pull/9098#pullrequestreview-473374133
<mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
<cachio> zyga-x240, nice, thanks
<cachio> I'll take a look
<zyga-x240> cachio: let me know if anything I said there is unreasonable please
<zyga-x240> cachio: please look through all the functions, they should not create new globals unless that's exactly desired
<zyga-x240> e.g. start_nested_classic_vm defines a dozen or so new globals
<cachio> zyga-x240, ok, np, I'll update that
<zyga-x240> cachio: wait_for_ssh defines retry as a global
<zyga-x240> please go through the entire file
<cachio> zyga-x240, ok, I'ldd
<cachio> I'll do
<zyga-x240> thanks,
<zyga-x240> the more we learn about shell the more we need to be careful
<cachio> zyga-x240, yes hehehe
<pstolowski> mborzecki: pondering what to do about that second denial on centos8 only; is "allow snappy_t unconfined_service_t:file getattr;" too terrible?
<mborzecki> pstolowski: wouldn't that only mask the issue?
<pstolowski> mborzecki: fwtw these files appear empty, and are included in actual snapshot
<zyga-x240> pstolowski: they are empty
<zyga-x240> pstolowski: they are mount points to contain nsfs objects
<mup> PR snapcraft#3260 opened: tools: update setuptools in environment-setup <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3260>
 * zyga-x240 -> lunch
<mup> PR snapd#9160 closed: boot, o/devicestate: observe existing recovery bootloader trusted boot assets <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9160>
<pstolowski> degville: hi, welcome back! it seems you made a nice shot of milky way but unfortunately for some reason i see very pixelated/blurry pictures, something wrong with google photos here i suspect
<ijohnson> zyga-x240: what's your take on passing function names to a bash function? I want to inject any function to be called during the execution of another function, but only sometimes, something like passing a func() as a param in Go
<ijohnson> zyga-x240: does my idea seem terrible given your current experiences ?
<ijohnson> I could just add all the functions I need inside the main function and just use a silly named option/switch to the function when I call it
<zyga-x240> ijohnson: re
<zyga-x240> ijohnson: let me read backlog
<ijohnson> zyga-x240: sure no rush
<zyga-x240> ijohnson: no, not really
<zyga-x240> ijohnson: there's even a way to do "pointers" in bash if you need to
<zyga-x240> ijohnson: the more important detail is exactly how is the function called
<zyga-x240> ijohnson: I think that disabling set -e, calling the function, recording $? and re-enabling set -e is probably correct, to the best of my understanding
<zyga-x240> ijohnson: some simpler functions are also correct in more generic cases, those that involve a single command
<ijohnson> zyga-x240: the function I need to call is very simple, but it needs to be called at a very specific point in time
<zyga-x240> ijohnson: I'm happy to review and suggest improvements
<ijohnson> but actually I think I can get away with just a single implementation, thinking about it I don't know that I need multiple different functions to be called so I think I'll just use a special optional argument to the original function I need to call
<degville> pstolowski: thanks for letting me know (and the welcome back!) - I'll check, but it's pretty low quality anyway as it was just a long exposure shot taken with my phone. I do have a RAW version, so I may try and play with it in Darktable.
<mup> PR snapcraft#3261 opened: requirements: pin setuptools devel requirement <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3261>
<mborzecki> zyga-x240: there's no way to set the 'script' interpreter in spread, or is there?
<zyga-x240> mborzecki: no and in addition, spread joins many separate task together
<zyga-x240> IIRC
<ijohnson> let's all switch to julia instead of bash
<ijohnson> alternative to julia would be the good ol lisp
<zyga-x240> ijohnson: I think js is the most realistic alternative
 * ijohnson really doesn't wanna write js tho
<zyga-x240> it's not great but has arguably the best tooling
<ijohnson> I see your clojures in js and raise you an offer of erlang
<zyga-x240> I think it's not something we should pick in a rush
<zyga-x240> maybe figuring out how to transition to anything is more relevant
<zyga-x240> then we can consider alternatives
<cachio> zyga-x240, I see this error https://github.com/snapcore/snapd/runs/1021534236#step:5:1744
<cachio> todya the image has been updated
<cachio> did you already see that?
<zyga> cachio strange, is that image changing from efi to legacy boot?
<cachio> no
<cachio> zyga, it shouldn't
<cachio> I am trying to reproduce
<zyga> ok
<mup> PR snapd#9206 opened: boot: complain about reused asset name during initial install <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9206>
<zyga> snap wait --help panics
<zyga> pstolowski snap save on f32 says "broken: invalid snapshot"
<zyga> https://pastebin.ubuntu.com/p/cxHqJ9MZQn/
<mborzecki> zyga: backtrace goes to go-flags
<zyga> maybe go-flags is old
<mborzecki> zyga: maybe a particular version is broken
<zyga> the beauty of maintaining packages
<pstolowski> zyga: ? is this my PR?
<zyga> nope
<zyga> mborzecki it creshes on
<zyga>                                         descPadding := strings.Repeat(" ", descStart-len(argPrefix))
<zyga> afk
<zyga> dog needs to go out
<pstolowski> we run snapshot-basic spread test everywhere, are you sure it's not some local issue on your f32?
<pedronis> pstolowski: I did a pass on #9199
<mup> PR #9199: snapstate: installSizeInfo helper that calculates total size of snaps and their prerequisites <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9199>
<pstolowski> pedronis: just saw it, thanks
<pstolowski> mborzecki: does the selinux workaround in #9084 look fine to you? it passed now (except for unrelated test failure on centos8 and suse)
<mup> PR #9084: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9084>
<mborzecki> pstolowski: yeah, i don't think we have any other options at this point
<pstolowski> mborzecki: ok thanks, i'll land this
<mup> PR snapd#9084 closed: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9084>
<mborzecki> pstolowski: still, it'd be nice to maybe ask the lxd team what that ns/shmounts contains, my rough guess it's some bit of /proc/self/ns/.. of the lxd process, hence the unconfined_t label (and nsfs fstype)
<pstolowski> pedronis: interesting, so the idea is to essentially exclude snaps that could have been installed in the meantime when computing total?
 * cachio lunch
<pedronis> pstolowski: yes, as I said, it doesn't cover all cases, but it get us closer to the kind of code that we would need for that
<pstolowski> pedronis: right, got it, thanks
 * zyga-x240 goes for PT
<mvo> pstolowski: I updated 8982
<mvo> pstolowski: thanks for your review, the misgging BadRequest test highlighted a bad error message
<pstolowski> mvo: yes, i looked briefly, thanks for the changes
<pstolowski> ð
<pstolowski> +1
<mvo> yay now 8982 just needs a second review
<mup> PR snapd#9207 opened: boot/bootstate20: reboot to rollback to previous kernel <Bug> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9207>
<zyga-x240> re
<zyga-x240> today's exercise was *intense*
<zyga-x240> I'm genuinely tired
 * zyga-x240 needs water
 * zyga-x240 is rehydrated 
<zyga-x240> let's write some ocd
<zyga-x240> *code
 * zyga-x240 goes upstairs
<mup> PR core20#82 opened: [RFC] hooks: mv docker user/group definition to extrausers <Created by anonymouse64> <https://github.com/snapcore/core20/pull/82>
<mup> PR snapd#9208 opened: tests/nested/core20/kernel-failover: add test for failed refresh of uc20 kernel <Run nested> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9208>
 * ijohnson EODs
#snappy 2020-08-25
<mup> PR snapd#9209 opened: Correctly parse Content-Type HTTP header <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/9209>
<pstolowski> morning
<mvo> hey pstolowski
<zyga> good morning
<zyga> maciek's question from last evening made me realize why things are broken
<mvo> good morning zyga
<zyga> I think the 11AM thing will be necessary, today kids were very time consuming
<zyga> and grandparents had to leave early in the morning so it was all on my head
<zyga> anyway, maciek asked why are we hitting session bus for hooks and he is right, we should not
<zyga> hah, there's even a TODO that says exactly what maciej suggested in the code
<zyga> so that's easy
<zyga> pstolowski what are you using for IRC?
<pstolowski> zyga: textual7
<zyga> same
<zyga> I stand up and make tea and my mbp suspends :)
<zyga> I miss an always-on imac
<zyga> well, imac also suspends
<zyga> so it's just an illusion
<zyga> macos suspends so aggressively
<pstolowski> zyga: hmm, doesn't happen here, but i'm plugged most of the time
<zyga> pstolowski I'm on defaults and suspend time is ...
<zyga> 2 minutes
<zyga> yeah on a cable its' 10
<pstolowski> zyga: ah, ok, i bumped them a bit and already forgot
<mup> PR snapd#9210 opened: [RFC] daemon: add /v2/systems "reboot" action API <Created by mvo5> <https://github.com/snapcore/snapd/pull/9210>
<zyga> testing the change now
 * zyga makes coffee while tests run
<zyga> I think my PT is starting to work
<mvo> pedronis: would be great if you could double check https://github.com/snapcore/snapd/pull/9158/commits/a0786608b312063025ff713b2a896cecf6a1df43 - had to do a small extra change to this PR because of a bug in go 1.9 :/
<mup> PR #9158: logger: add support for setting snapd.debug=1 on kernel cmdline <Documentation> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9158>
<zyga> ok that worked fine
<zyga> but now I have new denials
<zyga> type=AVC msg=audit(08/25/20 08:57:14.811:930) : avc:  denied  { search } for  pid=29402 comm=snap name=dbus dev="tmpfs" ino=17427 scontext=system_u:system_r:snappy_cli_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir permissive=1
<zyga> type=AVC msg=audit(08/25/20 08:57:14.811:931) : avc:  denied  { write } for  pid=29402 comm=snap name=system_bus_socket dev="tmpfs" ino=17428 scontext=system_u:system_r:snappy_cli_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=1
<zyga> type=AVC msg=audit(08/25/20 08:57:14.816:932) : avc:  denied  { connectto } for  pid=29402 comm=snap path=/run/dbus/system_bus_socket scontext=system_u:system_r:snappy_cli_t:s0 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1
<zyga> I'll propose this separately and park that until Maciek is back
<pedronis> mvo: ok, will look in a little bit
 * zyga adds tests for tracking services and hooks to verify everything
<zyga> tested hooks and services now, let's expand that to more systems and add session-level service tracking tests
<zyga> oh drat
<zyga> need power
<zyga> ok, let's test on all the systems now
<zyga> and add a test for session-level service tracking
<mup> PR snapd#9211 opened: o/snapstate: disk space check with InstallMany <Disk space awareness> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9211>
<mvo> zyga: if you are in review mood, please check out 8982 :)
<zyga> mvo let me look
<zyga> oh a biggie
<zyga> but I need to grok snapshots more anyway
<zyga> in 10 minutes, let me open a PR with a small but important fix
<zyga> mvo reviewing now
<zyga> https://github.com/snapcore/snapd/pull/9212 is ready for review, this will help with the feedback from maciek and will allow me to adjust the selinux policy next
<mup> PR #9212: cgroup,snap: track hooks on system bus only <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/9212>
<mup> PR snapd#9212 opened: cgroup,snap: track hooks on system bus only <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/9212>
<mup> PR snapd#9213 opened: secboot: read kernel efi image from snap file <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9213>
 * zyga goes for lunch
<zyga> mvo 90% done with review
<zyga> mvo but it will be a -1 so please don't merge
<zyga> mvo done
<mvo> zyga: thanks you
<zyga> thanks me :)
<mup> PR snapcraft#3262 opened: specifications: configurable apt mirror <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3262>
<mup> PR snapd#9158 closed: logger: add support for setting snapd.debug=1 on kernel cmdline <Documentation> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9158>
<pedronis> zyga: mvo: I checked the go code (quickest thing), there is padding, probably not completed padding but is there
<pedronis> s/completed/complicated/
<zyga> pedronis in the per-member header?
<zyga> In the call I was confused by the question and I replied about gzip padding, not tar padding
<zyga> I think we can expland the tar writer to have an optimized mode when TarWriter.Write cheats and assumes the header had the right size and ignores the source
<pedronis> we were talking about tar
<pedronis> the zip files are just put in a tar
<zyga> yes, I looked at tar now as well
<zyga> I think the optimization is not hard to do, we should fix the small stuff, land this and I can open a follow-up
 * cachio afk
<ijohnson> pedronis: instead of `emptyMap` is `cleanBootVars` an ok var name for #9205 ?
<mup> PR #9205: boot/initramfs_test.go: reset boot vars on the bootloader for each iteration <Simple ð> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9205>
<pedronis> ijohnson: yes, either clean or reset
<ijohnson> pedronis: ack since it's just 7 lines I am going to force push with `cleanBootVars`
<zyga> https://github.com/snapcore/snapd/pull/9212 is green and relatively simple (most changes are just additional testes)
<mup> PR #9212: cgroup,snap: track hooks on system bus only <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/9212>
<zyga> coffee and back to debugging
<ijohnson> cachio: hey I just noticed we don't actually run the tests/nested/core20 suite with the run-nested label do we ?
<mup> PR snapcraft#3260 closed: tools: update setuptools in environment-setup <tooling> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3260>
<mup> PR snapcraft#3261 closed: requirements: pin setuptools devel requirement <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3261>
<ijohnson> zyga: +1d that simple PR
<mup> PR snapcraft#3263 opened: colcon v2 plugin: honour http(s) proxy for all build commands <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3263>
<zyga> thanks!
<ijohnson> pedronis: actually I looked into a bit more, I don't think we should use `-f` for reboot from the initramfs, see https://github.com/snapcore/snapd/pull/9207#discussion_r476526179
<mup> PR #9207: boot/bootstate20: reboot to rollback to previous kernel <Bug> <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9207>
<ijohnson> pedronis: given my findings there, do you think we should actually switch to using `systemctl reboot`? or should I ask x n o x (who is away this week at plumbers)
 * zyga runs one more tests and calls it a day
<cachio> ijohnson, sorry for the delay, I had to to buy a medicine and the had lunch
<cachio> it should run core20
<cachio> we are running tests/nested/
<ijohnson> cachio: no worries, which spread-nested task on github actions runs tests/nested/core20 ?
<cachio> google-nested:ubuntu-20.04
<ijohnson> cachio: ah thanks, I got confused by the breakdown
<ijohnson> thanks I see the test I was interested in actually failed
<cachio> ijohnson, which one?
<ijohnson> cachio: a test I proposed in https://github.com/snapcore/snapd/pull/9208/checks?check_run_id=1023281431
<mup> PR #9208: tests/nested/core20/kernel-failover: add test for failed refresh of uc20 kernel <Run nested> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9208>
<ijohnson> tests/nested/core20/kernel-failover failed there due to silly bashisms
<mvo> cachio: 2.46 is getting released now, snapd snap beta should be ready in ~30min, core will be ~1h or so
<cachio> mvo, nice, thanks
<zyga> ijohnson good silly or bad silly
<zyga> ijohnson was it masking a real bug
<ijohnson> zyga: nah just I thought using `local` would work not in a function but it doesn't, I made a change to the test after it passed locally thinking it was harmless, seems it's not
<ijohnson> 2020-08-24T20:19:32.8528139Z + local retry=120
<ijohnson> 2020-08-24T20:19:32.8528330Z /bin/bash: line 82: local: can only be used in a function
<ijohnson> oh hey this came up while you were out zyga
<zyga> yeah?
<zyga> nested.sh needs love
<ijohnson> forgot to bring this up, but retry does not work with functions sourced from i.e. nested.sh
<zyga> I need to review the changes from cachio tomorrow
<ijohnson> how do you think we could make retry work with functions ?
<mvo> zyga: I'm done with my meetings and mostly with the release, I'm happy to do your suggested fixes on 8982 in my morning (I will be up early). but if you get to it that's welcome of course. but don't feel obliged, you have a a lot of important stuff on your plate :)
<zyga> ijohnson retry doesn't work with any function
<zyga> it works with programs
<ijohnson> zyga: yes
<ijohnson> zyga: but could it be made to work with functions ?
<ijohnson> or is this just another rat hole not worth trying to fix
<mup> PR snapd#9214 opened: release: 2.46 <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9214>
<zyga> ijohnson it would be unsafe, I really don't want to go there
<ijohnson> fair
<zyga> I think it could be
<zyga> I mean, yeah,
<zyga> but the semantics is not something I'm 100% sure
<cachio> zyga, tx
<ijohnson> I realize this would work much better if nested.sh becomes a tool program instead of a sourced program
<ijohnson> so maybe we just do that instead of trying to make retry work with functions
<zyga> yeah, I think so
<ijohnson> ok, fair enough
<ijohnson> this came up while you were out and I forgot about it til just now
<zyga> I think that's a fail desire but it's really more robust to compose programs than functions
<zyga> let's see what we can do about nested.sh first
<zyga> I lied, I ran more tests
<zyga> but I need to run
<zyga> my wife calls me
<zyga> mvo released snapd
<zyga> arch pings me to update
<zyga> heh
<ijohnson> zyga: how dare we not release to arch immediately, we must be lazy :-)
<cachio> zyga, should we test on opensuse leap 15.2 as well?
<cachio> there are new gce images
<mvo> cachio: armhf failed to build in the ppa so core is a little bit delayed there
<cachio> mvo, ok, np
<cachio> I'll start with snapd
<cachio> mvo, is snapd delayed as well?
<mvo> cachio: no, but it looks like the change to "mkversion.sh" we did gives it a terrible version number :(
<cachio> mvo, 2.46+git2.46.2.46
<cachio> mvo, is it the final version for snapd?
<ijohnson> oh no was that my fault
<mvo> cachio: well, it should be 2.46
<ijohnson> sorry
<mvo> ijohnson: a bit unclear, no worries just yet
<cachio> mvo, ijohnson no problem
<cachio> just wanted to make sure
<mvo> cachio: it's the right binary content but the version needs fixing :/
<mup> PR snapcraft#3109 closed: pcache: introduce persistent cache decorator <enhancement> <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3109>
<mup> PR snapcraft#3110 closed: repo: use persistent cache for fetching stage packages <enhancement> <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3110>
<mvo> ijohnson: hm, I suspect "git describe --dirty" is not quite fixed :/
<ijohnson> ah darn do we build with an old version of snapcraft in LP?
<mvo> ijohnson: I think I set it to "candidate"
<mvo> ijohnson: we build it here https://code.launchpad.net/~snappy-dev/+snap/snapd-2.46
<ijohnson> mvo: but that bug is marked as fix released for snapcraft 3.1 which was released in jan 2019 :-(
<ijohnson> the bug that the dirty thing referenced that is, https://bugs.launchpad.net/snapcraft/+bug/1806746
<mup> Bug #1806746: Move state file to avoid dirtiness when snap is used for code <19.04> <19.04-external> <Snapcraft:Fix Released by sergiusens> <https://launchpad.net/bugs/1806746>
<ijohnson> mvo: when I run mkversion.sh from master with your changelog placeholder mkversion.sh works fine
<ijohnson> ah but I bet it is built from the release/2.46 branch let me try that one
<ijohnson> mvo: it still gives me a valid version number it just has
<ijohnson> ./mkversion.sh
<ijohnson> *** Setting version to '2.46' from git.
<mvo> ijohnson: it might be snapcraft in LP that is the problem
<mvo> ijohnson: it works for me locally too
<ijohnson> argh I think I know why
<ijohnson> the core snap builds with "legacy" snapcraft because it doesn't specify a base or build-base in the snapcraft.yaml
<mvo> ijohnson: this is the snapd snap
<ijohnson> oh then I don't know why
<ijohnson> mvo: I'm going to try and reproduce building snapd locally from release/2.46 then
<ijohnson> mvo: does it only happen for snapd snap or the core snap too ?
<mup> PR snapd#9215 opened: mkversion.sh: do not use git describe --dirty <Created by mvo5> <https://github.com/snapcore/snapd/pull/9215>
<mvo> ijohnson: just snapd snap it seems
<mvo> ijohnson: core just finished
<ijohnson> ok, I've got a build going locally, should be done in a couple minutes
<mvo> ijohnson: thanks, I will need to do some stuff around the house, should be back in 15min or so
<mvo> ijohnson: in the meantime *maybe* 9215 will help
<ijohnson> mvo: I will start a parallel build of your branch too just to see
<ijohnson> silly snapcraft doesn't let multiple lxd containers for the same snap to run simultaneously
<mup> PR snapcraft#3264 opened: colcon v2 plugin: don't strip environment for stage-runtime-dependencies <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3264>
<ijohnson> mvo: I did manage to reproduce with snapcraft locally, debugging now
<ijohnson> ah but actually there is a diff, it is dirty!
<ijohnson> -                       "checksumSHA1": "UHhUJNcYbKn3xxZDuPh9GX6BWrM=",
<ijohnson> +                       "checksumSHA1": "uLS+3ymPr8NztAjDjmiRkpKIsIQ=",
<mvo> oh, what makes it dirty?
<ijohnson> get-deps.sh modifies vendor.json with the above patch
<ijohnson> I'm gonna try a fresh build with that changed on release/2.46 and committed
<ijohnson> ah but then it won't be building 2.46 tag
<ijohnson> hmm
<ijohnson> I could always move the tag locally on my repo
<mvo> oh, interessting
<ijohnson> alright build running again let's see what happens
<mvo> aha, secboot hm, hm
<mvo> strange that we did not encounter this before
<ijohnson> mvo: but actually though we have encountered this frequently
<ijohnson> that secboot SHA keeps changing for myself and claudio and pedronis and possibly also others too locally
<mvo> oh
<mvo> so maybe that's the fix - updating vendor.json instead of --dirty
<mvo> anyway, stuff for tomorrow, I need to call it a day
 * mvo waves
<mup> PR snapd#9216 opened: vendor.json: update mysterious secboot SHA again <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9216>
<mup> PR snapd#9217 opened: run-checks: add typos from auto-tools when using `make hack` <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9217>
<mup> PR snapd#9218 opened: tests: running tests on opensuse leap 15.2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9218>
#snappy 2020-08-26
<mup> PR snapcraft#3263 closed: colcon v2 plugin: honour http(s) proxy for all build commands <bug> <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3263>
<zyga-x240> o/
<zyga-x240> mvo: I saw your message yesterday
<zyga-x240> oh boy I open my laptop and Lucy wakes up
<mvo> zyga-x240: good morning
<zyga-x240> :)
<mvo> zyga-x240: no worries, either way is fine
<zyga-x240> until she's fully awake, changed and fed I will not be fully available
<zyga-x240> just a few more days till next week
<mvo> zyga-x240: no worries
<mvo> can someone please approve 9214? it's just changelog updaes
<mup> PR snapd#9215 closed: mkversion.sh: do not use git describe --dirty <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/9215>
<mup> PR snapd#9215 opened: mkversion.sh: do not use git describe --dirty <Created by mvo5> <https://github.com/snapcore/snapd/pull/9215>
<pstolowski> morniing
<mvo> good morning pstolowski
<zyga> re
<zyga> mvo looking
<zyga> mvo merged
<mup> PR snapd#9214 closed: release: 2.46 <Skip spread> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9214>
<mvo> zyga: \o/
<zyga> mvo in a way it's good we'll need 2.47
<zyga> we should release it in a few weeks at most
<zyga> and get back to small releases
<zyga> that are fast
<mup> PR snapd#9219 opened: run-checks: only check files in git for misspelling <Created by mvo5> <https://github.com/snapcore/snapd/pull/9219>
<zyga> mvo reviewed with a question
<mvo> zyga: \o/
<zyga> mvo I'm available now, shall I pick up snapshot export PR?
<mvo> zyga: if you want, I did not manage to and have meetings soon :/
<zyga> ok
 * mvo hugs zyga
<zyga> gladly
<zyga> on it
<zyga> it's a new topic
<zyga> that feels good sometimes
<zyga> btw, offtopic, my lxd install stopped working
<zyga> it says it needs manual network configuration
<zyga> as it cannot find a free subnet or something
<zyga> I have a 10.x.y.z/8 netmask
<zyga> so I'm quite surprised
<zyga> mvo shellcheck complained about the spell changing
<mvo> zyga: yeah, I am a muppet
<mvo> zyga: I force pushed a fix, I don't have $GOPATH/bin in my $PATH
<zyga> k
<mvo> zyga: so for local testing I did that (I don't like the idea of something like $GOPATH/bin in my PATH, feels too dangerous)
<mvo> anyway
<mvo> silly me
<zyga> it's okay
<mvo> zyga: I replied, I can add comments about where the ignore comes from, maybe a good idea
<zyga> mvo replied too
<mup> PR snapd#9205 closed: boot/initramfs_test.go: reset boot vars on the bootloader for each iteration <Simple ð> <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9205>
<zyga> mvo I've updated https://github.com/snapcore/snapd/pull/8982 and left two unresolved comments:
<mup> PR #8982: snapshots: export of snapshots <Created by slimjim777> <https://github.com/snapcore/snapd/pull/8982>
<zyga> mvo one is about the help message of export-snapshot, I need to ask Graham for help here
<zyga> it can also happen in a follow up I guess but it might be easy enough to do todat
<zyga> *today
<zyga> the second one is about error handling in https://github.com/snapcore/snapd/pull/8982#discussion_r476372693
<zyga> and I think I need pstolowski help on that
<zyga> can you look and express your opinion please pawel?
<zyga> other code seems to handle errors from requests in a different way
<zyga> and can use the body to unpack error details
<zyga> we should either be consistent about it or leave a comment why we are not doing this
<zyga> mvo I left the tar improvements out for a new PR
<zyga> and adjusted everything else
<zyga> so it means someone other than me should do a review
<mvo> zyga: in a meeting, but *thanks*
<pstolowski> zyga: sure
<pedronis> I can look about the error handling as well but in a bit, I suspect the difference might relate that the happy response is not json here
<pedronis> but I suspect the error ones should be
<zyga> yeah, I think so too
<zyga> thanks!
<zyga> I'll return to my other tasks and try to finish the tar optimize after PT in the evening
<pstolowski> zyga: it looks like e.g. maintenance status on error may be interesting to have
<mvo> zyga: just looked over your changes, looks fine
<mvo> zyga: thank you!
<zyga> mvo cheers :)
<mvo> pstolowski: I wonder if the client error handling should be done in a followup, I'm not sure we need more here tbh but even if it seems the exiting code is not wrong, just that it could be improved(?)
<mvo> pstolowski: I'm in favor of merging (if green :)
<pstolowski> mvo: yes, absolutely, a followup is gine
<pstolowski> *fine
<zyga> mvo I'm okay with that as well
<pstolowski> hmm services PR failed and the failure looks real on 14.04
<mup> PR snapd#9220 opened: o/snapstate: disk space check with single snap install <Disk space awareness> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9220>
<zyga> pstolowski how did it fail?
<pstolowski> zyga: state of services not as expected
<zyga> mmm
<pstolowski> oddly only on 14.04. i'm going to investigate in a bit
<zyga> what was the unexpected status?
<pstolowski> zyga: enabled/inactive instead of disabled/inactive
<mup> PR snapd#9221 opened: tests: disk space awareness spread test <Disk space awareness> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9221>
<mup> PR snapd#8982 closed: snapshots: export of snapshots <Created by slimjim777> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8982>
<mup> PR snapd#9199 closed: snapstate: installSize helper that calculates total size of snaps and their prerequisites <Disk space awareness> <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9199>
<pedronis> pstolowski: should I re-review the service PR or wait?
<mup> PR snapd#9222 opened: osutil: add a package doc comment (via doc.go) <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9222>
<pstolowski> pedronis: please wait, i'll let you know
<pedronis> pstolowski: ok, thx
<pedronis> pstolowski: when you have a moment, can you merge master into #9211 ?
<mup> PR #9211: o/snapstate: disk space check with InstallMany <Disk space awareness> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9211>
<pstolowski> yes
<pedronis> mvo: #9222 is small/simple and touches something you did
<mup> PR #9222: osutil: add a package doc comment (via doc.go) <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9222>
<mvo> pedronis: thank you
<mup> PR snapd#9206 closed: boot: complain about reused asset name during initial install <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9206>
<mup> PR snapd#9222 closed: osutil: add a package doc comment (via doc.go) <Simple ð> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9222>
<Chipaca> hey-o
<Chipaca> i've recently found that i need to restart snapd.socket manually every so often
<mvo> pstolowski: 9211 has some unhappy unit test but looks great otherwise
<pstolowski> mvo: ah, i forgot to rename after mergin master, thanks
<cachio> zyga, hey
<cachio> about the error related to the failober tests
<zyga> re
<cachio> of rexternal backend
<zyga> Chipaca, oh what's the state of the socket when you do?
<zyga> cachio, yeah?
<cachio> do you have in mind anython to fix that?
<Chipaca> zyga: a fair question. i'll look next time it happens.
<zyga> cachio sorry, the failure we talked about before or some new one?
<zyga> Chipaca I did observe something weird related to pulse socket like that
<zyga> oh, sorry
<zyga> not to the pulse socket
<cachio> zyga, the one we talked before
<zyga> to the snapd socket in fact
<zyga> it was related to snapd-userd socket
<zyga> when we changed the socket definition
<zyga> (just rewrite it)
<zyga> and not reload systemd-userd
<cachio> zyga, which failed because external backend does "sudo su to run the spread script"
<zyga> cachio right
<zyga> cachio that's fundamentally broken sadly :/
<zyga> cachio we have to change that
<zyga> it should, at minimum, do sudo -l
<cachio> zyga, so change spread
<zyga> er, wait
<zyga> not -l
<zyga> su -l, for sudo that's ....
<mup> PR snapd#9217 closed: run-checks: add typos from auto-tools when using `make hack` <Simple ð> <Test Robustness> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/9217>
<zyga> cachio sudo -i (or sudo --login for clarity)
<zyga> not tested
<zyga> but that should be much better if it works as I expect
<zyga> if that's convenient, change spread and see if this fixes it
<cachio> zyga, ok, I'll make the change
<zyga> ok
<cachio> zyga, thanks for the suggestion
<zyga> Chipaca in any case, thanks for the heads up
<zyga> I'm running snapd without rebooting on metal to observe weird things as well but I have been unable to spend the time to dig into the things I saw
<zyga> (insert commas for best sense)
<ijohnson> zyga: mvo: so for #9216, what should I do? the changelog typo fix is not on release/2.46 so I'm not sure what to force push ?
<mup> PR #9216: vendor.json: update mysterious secboot SHA again <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9216>
<mup> PR snapd#9215 closed: mkversion.sh: do not use git describe --dirty <â  Critical> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/9215>
<zyga> ijohnson I was unclear, sorry, I expected to find only the hash change, not the typo fixes
<ijohnson> zyga: sure but then no tests run against the PR if I don't fix the typos here
<zyga> are they necessary in this branch?
<zyga> oh
<zyga> meh
<zyga> that sucks, can we just merge the fixes separately?
<ijohnson> i.e. open any PR against release/2.46 and tests don't run
<zyga> it's not a biggie
<ijohnson> I'll leave to mvo to decide what to do, I'll leave the PR as-is for now
<zyga> ijohnson due to the typos?
<zyga> ok
<ijohnson> zyga: yes
<zyga> I trust mvo's merge button
<ijohnson> the unit / static tests fail on the typos and don't do spread runs
<mup> PR snapcraft#3264 closed: colcon v2 plugin: don't strip environment for stage-runtime-dependencies <bug> <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3264>
<ijohnson> normally I'd say it's fine but this sha thing is mysterious enough to make me want to see spread results of building with this vendor.json change
<zyga> ijohnson I would just merge the typos separately
<zyga> and then rebase this branch
<zyga> so we can see a single thing to track, not that with other bits
<ijohnson> zyga: sure but I would rather wait til mvo says what he prefers
<zyga> ok
<mup> PR snapcraft#3265 opened: colcon v2 plugin: honour http(s) proxy for stage-runtime-dependencies <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3265>
<pedronis> mvo: pstolowski: there is no daemon support yet for ErrInsuffiecientSpace ? also that name is not following style conventions
<pstolowski> pedronis: correct, no daemon yet
<cachio> zyga, so currently it is doing "sudo -i /bin/bash /tmp/tmp.zwRt33mi04"
<cachio> to execute the script
<pedronis> pstolowski: I left some comments
<zyga> cachio currently as in with some changes or vanilla?
<mvo> ijohnson, zyga sorry, meetings will look at the backlog
<cachio> zyga, vanilla
<zyga> cachio ok, perhaps it needs some more oomph
<pstolowski> pedronis: ty
<zyga> can you try changing that to su -l
<cachio> zyga, sure
<ijohnson> mvo: I opened https://github.com/snapcore/snapd/pull/9223 to fix the --dirty handling in mkversion.sh
<mup> PR #9223: mkversion.sh: simple hack to include dirty in version if the tree is dirty <Bug> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9223>
<ijohnson> hopefully that is the best of all possible worlds (but all possible worlds are still terrible)
<ijohnson> mvo: also please advice on next steps for #9216
<mup> PR #9216: vendor.json: update mysterious secboot SHA again <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9216>
<mup> PR snapd#9223 opened: mkversion.sh: simple hack to include dirty in version if the tree is dirty <Bug> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9223>
<mup> PR snapd#9216 closed: vendor.json: update mysterious secboot SHA again <â  Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9216>
<pedronis> pstolowski: mvo: do we plan to have checks also for refresh ?
<mup> PR snapcraft#3266 opened: cli: add --enable-experimental-extensions option for expand-extensions <enhancement> <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3266>
<mvo> pstolowski, pedronis: I think that would be good
<pstolowski> pedronis: yes i think so
<pedronis> pstolowski: mvo: given that we remove old revisions only after installing the new ones, it's probably not too different form install
<pedronis> *from
<mvo> pedronis: yeah
<mvo> pedronis: one interessting point for really low disk space system is that we may need to provide a mode in the future to change this behavior to "remove-before-install"
<pedronis> ok, sounds something to think about when we get there
<pedronis> it means no rollback unless you keep two old revisions
<pedronis> which would take more space
<pedronis> mvo: if you really want just one revision there's no undo
 * cachio lunch
 * mvo nods
<mup> PR snapd#9224 opened: Added MIRKey to U2F devices list in interfaces/builtin <Created by kobusgrobler> <https://github.com/snapcore/snapd/pull/9224>
<pstolowski> hmm there is something wonky with 'systemctl enable --root=/ on 14.04 ...'
<pstolowski> mvo: interesting idea
<mvo> pstolowski: all later
<pstolowski> sure, ack
<mvo> pstolowski: just an idea because we were talking about really low disspace systems
<pstolowski> systemctl enable --root=/ on 14.04 creates symlinks sunch as "snap.disabled-svcs-kept.svc.service -> ///etc/systemd/system/snap.disabled-svcs-kept.svc.service" and things seem to go wrong from there
<pedronis> pstolowski: what is using enable --root ? a test?
<pstolowski> pedronis: Enable(..) in our systemd package, and it's now used in my services PR. no problems except for 14.04
<pstolowski> so it's used for real, not in test
<pedronis> pstolowski: is that related to preseeding ?
<pstolowski> pedronis: no
<pedronis> or it was always like that?
<pstolowski> pedronis: as far as systemd package is concerned , --root is 1 year old
<pedronis> it's related to user services it seems
<pstolowski> pedronis: but it's now used for snap start.. in my PR. i need to compare with master
<pstolowski> pedronis: likely, the change was from James
<pedronis> not sure
<pedronis> James didn't change that
<pedronis> at least not in the obvious PR
 * mvo hockey, available via tg for ugent cases
<pstolowski> pedronis: right, he just touched the line but didn't change semantics. anyway, something in my PR to fix, i need to check what did we do in master, most likely --root wasn't and shouldn't be passed in this case
<pedronis> afaict even on master we pass it everywhere
<pedronis> ah, no
<pedronis> sorry, I'm confused is the problem enable or start?
<pstolowski> pedronis: start --enable our our side, which translates to separate enable followed by start
<pedronis> pstolowski: I see, anyway --root was there since that code started using systemctl in 2016
<pedronis> pstolowski: 5106ed3bcb193bf
<mup> PR snapd#9225 opened: many: cloud-init cleanups from previous PR's <Cleanup :broom:> <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9225>
<pstolowski> pedronis: yes, but afaict it wasn't used with this exec-command tasks where systemctl was called directly, that's the thing
<pstolowski> anyway i need to eod, appointment
<mup> PR snapd#9226 opened: cmd/snap-bootstrap/initramfs-mounts: compute string outside of loop <Cleanup :broom:> <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9226>
<pedronis> ijohnson: does #9225 need to run with nested tests enabled?
<mup> PR #9225: many: cloud-init cleanups from previous PR's <Cleanup :broom:> <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9225>
<cachio> zyga, no luck with sudo -l
<ijohnson> pedronis: ah yes good point, let me re-open with that label
<pedronis> ijohnson: I reviewed the cleanup PRs
<ijohnson> thanks
<mup> PR snapd#9219 closed: run-checks: only check files in git for misspelling <Skip spread> <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9219>
<ijohnson> cachio: can you add to your nested test TODO to fix the regexp here for the ubuntu-16.04-64:tests/nested/core/extra-snaps-assertions test? https://pastebin.ubuntu.com/p/8y5pYY5PQw/
<ijohnson> pedronis: the last change you requested re cloud-init was in nested.sh from the private reviews, but I pushed it to https://github.com/snapcore/snapd/pull/9208/commits/9d1a8d64f0eb1242ce912875fc9e9f977fe72fe3 since that branch needed a restart anyways and is already nested.sh related
<mup> PR #9208: tests/nested/core20/kernel-failover: add test for failed refresh of uc20 kernel <Run nested> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9208>
<ijohnson> pedronis: you originally requested it here: https://github.com/anonymouse64/snapd-private/pull/8/files/bbfe9f9fc266d9cc43fe2c45c44620f4ad6ff2d0#r451357700
<cachio> ijohnson, to fix?
<cachio> let me check
<ijohnson> cachio: see the pastebin, the regexp for the core snap is wrong, it doesn't expect to see a pre version there
<mup> PR snapd#9227 opened: snap: add stat to the random access file return interface <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9227>
<cachio> ijohnson, ahhh, the pre + git
<ijohnson> yes
<cachio> in my pr
<cachio> I am not checkin hte version when the rev ix x1
<cachio> because we test that as part of the listing test in main suite
<cachio> so what I did is to simplify what we test in case we build core
<cachio> ijohnson, does it make sense for you?
<ijohnson> cachio: sure if it doesn't make sense to check that you can just remove that check that's fine
<ijohnson> just wanted to make sure you knew about the failure
<cachio> ijohnson, nice, so that problem is covered in #9098
<mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
<ijohnson> great
<zyga> cachio, can you check if if su -l creates a logind session?
<cachio> zyga, sure
 * zyga feels so so
<zyga> I think I may be getting the same thing my wife has
<cachio> zyga, go to rest
<ijohnson> zyga: oh no
<zyga> cachio alternatively try this
<zyga> cachio run without sudo
<zyga> cachio use sudo to create a systemd unit, maybe via systemd-run or manually
<zyga> have the unit run the shell script
<cachio> zyga, run the script without sudo?
<zyga> and start the unit similarly to how session-tool does it, with runuser -l
<zyga> cachio start the script with runuser -l, as the desired user (root) but inside a systemd system unit
<zyga> cachio it's all a bit convoluted but that's one scenario that I know should behave correctly
<zyga> cachio you can then try to reduce this
<cachio> zyga, ok, I'll try that
<ijohnson> cmatsuoka: what's the keyboard shortcut to open a debug shell for a uc20 vm again? I seem to remember it was ctrl+f8 or something but that doesn't do anything :-/
<zyga> ijohnson, cmatsuoka: please review simple bug fix https://github.com/snapcore/snapd/pull/9228
<mup> PR #9228: interfaces/systemd: compare dereferenced Service <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/9228>
<zyga> customer bug
<zyga> and my shame
<zyga> as I wrote this
<ijohnson> cmatsuoka: hey on your spread runner do you have python installed?
<ijohnson> cmatsuoka: see https://github.com/snapcore/snapd/runs/1032308198?check_suite_focus=true
<zyga> ijohnson: python-launchpadlib probably
<zyga> or python3-launchpadlib
<ijohnson> the CLA checker failed because it couldn't find python
<zyga> anyway
<ijohnson> zyga: sure I'll have a look
<cachio> zyga, back to this
<cachio> zyga, you said start the script with runuser -l
<cachio> which script are you talking about?
<zyga> cachio runuser -l is like sudo
<cachio> zyga, yes
<zyga> but it has the right pam config so it gives you a logind session
<zyga> the logind session is only created if the invoking process does not belong to a cgroup which is considered part of a session
<cachio> you mean spread has do to that?
<cachio> instead of doing sudo -i
<zyga> hence the workaround with running a systemd unit to run runuser -l
<zyga> yes
<cachio> zyga, ah, ok
<zyga> or offer a way for us to do this via spread
<cmatsuoka> ijohnson: installing python-is-python3
<zyga> otherwise, the external user has a session
<zyga> and root does not
<ijohnson> cmatsuoka: thanks
<zyga> and our tests are not compatible wiith  that
<cmatsuoka> zyga: will check asap
<ijohnson> cmatsuoka: also did you see my ping before you logged off about the debug shell on a VM?
<mup> PR snapd#9228 opened: interfaces/systemd: compare dereferenced Service <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/9228>
<cmatsuoka> ijohnson: yes, I answered it (alt+f9) but maybe it was lost in a reconnection?
<ijohnson> cmatsuoka: yeah I didn't see the response
<zyga> Thank you for the quick review Ian
<zyga> btw, if my wife is okay and she goes back to work next week
<zyga> I will shift my hours to start at 11 AM or perhaps even at noon
<ijohnson> cmatsuoka: hmm so I added rd.systemd.debug-shell=1 to the kernel command line via grub.cfg but alt-f9 still doesn't work
<zyga> to be with lucy in the morning
<ijohnson> zyga: that's great that your wife is okay
<ijohnson> happy to hear that
<zyga> and then hand off to her (my wife will work part time)
<zyga> ijohnson: she's not yet, I meant "iff she's okay"
<ijohnson> zyga: ah I missed the most critical word there
<zyga> ijohnson: so if that all works out I will be working more with you guys :)
<ijohnson> :-)
<zyga> more overlap during the day
<cmatsuoka> zyga: reviewed
<zyga> thank you guys!
<zyga> complex day
<zyga> older kids fighting
<zyga> lucy not seeing mom all day, being very grumpy about that
<zyga> wife coming home sick
<zyga> eh
<zyga> eh
<zyga> and now bugs
<mup> PR snapcraft#3267 opened: ci: re-enable appveyor artifact collection <tooling> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3267>
<cachio> zyga, tried that but the session was not created
<cachio> allways have the external and test sessions but can make it for the root session
<cachio> I need to go to the kinesiologist now
<cachio> I tried manuall
<cachio> y
<cachio> once I am back I'll continue reading documentation
<cachio> zyga, if you have any idea please leave a note
<cachio> zyga, thanks
 * cachio -> kinesiologist
<cmatsuoka> ijohnson: did you add dangerous too?
<ijohnson> cmatsuoka: yes I did still didn't work, but I was able to work around it anyways
<cmatsuoka> ijohnson: it works for me with regular systemd.debug-shell, it's been a long time since I used rd.systemd but it should work using the same mechanism
<cmatsuoka> afk, /me forgot to pay some bills
<ijohnson> cachio: I reviewed #9098, I think it is getting close just a few more comments
<mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
<cachio> ijohnson, thanks
<ijohnson> np
<cachio> ijohnson, any idea how to create a user session for root when I an using external user?
<cachio> I tried what zyga suggested
<cachio> but no luck
<ijohnson> ahh no unfortunately I don't I would need to spend a bit of time looking at the problem first, I haven't looked at the user session stuff in a while
<ijohnson> if you still can't get it worked out tomorrow maybe I can have a look tomorrow afternoon
<cachio> ijohnson, np, tomorrow I'll continue with zyga
<ijohnson> sounds good
<cachio> not it is too late for him
#snappy 2020-08-27
<mup> PR snapcraft#3265 closed: colcon v2 plugin: honour http(s) proxy for stage-runtime-dependencies <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3265>
<mup> PR snapcraft#3266 closed: cli: add --enable-experimental-extensions option for expand-extensions <enhancement> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3266>
 * zyga-x240 debugs failing core/apt test
<mborzecki> morning
<zyga-x240> hey
<zyga-x240> something broke, new core18 has apt-get
<zyga-x240> I've adjusted a test and will push a branch soon
<zyga-x240> master is red currently
<zyga-x240> mborzecki: I have something for you
<zyga-x240> https://github.com/snapcore/snapd/pull/9212
<mup> PR #9212: cgroup,snap: track hooks on system bus only <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/9212>
<zyga-x240> can you quickly look please, it's very small apart from extra tests
<mborzecki> zyga-x240: hey
<mborzecki> master red? ehh
<zyga-x240> yep
<zyga-x240> but fix is coming
<zyga-x240> mborzecki: https://github.com/snapcore/snapd/pull/9229
<mup> PR #9229: tests: account for apt-get on core18 <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9229>
<zyga-x240> this should fix master
<mup> PR snapd#9229 opened: tests: account for apt-get on core18 <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9229>
<zyga-x240> mborzecki: so your question was on the right track
<zyga-x240> mborzecki: hooks were tracked in the root session
<zyga-x240> mborzecki: that is fixed with that PR
<zyga-x240> mborzecki: the next step is to rebase the selinux patches, this change made them useless
<zyga-x240> mborzecki: when mvo is around we can start making progress
<zyga-x240> mvo: hey
<zyga-x240> mvo: good morning
<zyga-x240> mvo: I have a few things for you
<mvo> good morning zyga-x240
<zyga-x240> mvo: hello
<zyga-x240> mvo: so first thing first, master is broken because core18 now ships the apt-get wrapper script
<zyga-x240> mvo: because we no longer maintain core18 I chose to adjust tests instead of chasing the snap
<zyga-x240> mvo: this is https://github.com/snapcore/snapd/pull/9229
<mup> PR #9229: tests: account for apt-get on core18 <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9229>
<zyga-x240> mvo: second thing, the bug you poked me about last night
<zyga-x240> mvo: it's very embarrassing as I wrote that code
<zyga-x240> mvo: the fix is in https://github.com/snapcore/snapd/pull/9228 and should be merged to 2.46 if we are getting a .1
<mup> PR #9228: interfaces/systemd: compare dereferenced Service <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/9228>
 * zyga-x240 goes to review https://github.com/snapcore/snapd/pull/9098
<mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
<zyga-x240> and then other things
<mvo> zyga-x240: thank you!
 * mvo hugs zyga-x240 for 9228
<zyga-x240> mvo: it never failed before because our tests and our customers never had a case where a gpio was used by more than one plug at a time
<zyga-x240> mvo: anyway, it's fixed now
<mvo> zyga-x240: great job
<mvo> zyga-x240: also good timing as 2.46.1 will happen very soon
<zyga-x240> that's great
<zyga-x240> mvo: I would also like to include one more thing
<zyga-x240> https://github.com/snapcore/snapd/pull/9212
<mup> PR #9212: cgroup,snap: track hooks on system bus only <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/9212>
<zyga-x240> it's only for people who enabled r-a-a
<zyga-x240> this corrects a mistake in how we track hooks
<mborzecki> mvo: hey
<zyga-x240> it should be better even if root logs out
<mvo> good morning mborzecki and welcome back
<zyga-x240> (right now the hook might get killed if root logs out after the hook starts running)
<zyga-x240> not a must but I'd love to get it in, it's only used for feature flag users anyway
<mvo> zyga-x240: re core18> looking now but there are some messages that core18 is held in the review queue, maybe related
<zyga-x240> mvo: maybe it got unblocked?
<zyga-x240> in any case, master is broken now so we should probably do something to the test, other ideas are welcome
<mvo> zyga-x240: yeah, probably, but in any case, it's fine that apt-get exists
<zyga-x240> yeah, I think so
<mvo> zyga-x240: so your fix is probably right, looking at it now
<zyga-x240> mvo: meh
<zyga-x240> I botched the fix
<zyga-x240> sorry
<mvo> zyga-x240: which one?
<zyga-x240> the one for apt
<zyga-x240> I forgot *
<zyga-x240> ubuntu-core-16-*
<mvo> zyga-x240: no worries, just force push
<zyga-x240> done
<mup> PR snapd#9228 closed: interfaces/systemd: compare dereferenced Service <Bug> <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9228>
<mborzecki> zyga-x240: nice 9212 is green, selinux does not complain
<zyga-x240> mborzecki: not really
<zyga-x240> mborzecki: selinux is not tested there
<zyga-x240> mborzecki: the other PR enabled tracking to get more coverage
<zyga-x240> mborzecki: this one just prepares for that, selinux still needs changes
<zyga-x240> at some point we should run all tests with selinux checks
<zyga-x240> but that would be a lot of work today, I fear
<zyga-x240> mborzecki: would you mind if I make those changes in a follow-up
<zyga-x240> the PR is green now
<mborzecki> zyga-x240: it's fine
<zyga-x240> ok
<zyga-x240> merging then, thank you
<zyga-x240> and we have more tests for tracking now as well, thank you for reviewing :)
 * zyga-x240 runs for quick breakfast
<mup> PR snapd#9212 closed: cgroup,snap: track hooks on system bus only <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9212>
<mup> PR snapd#9223 closed: mkversion.sh: simple hack to include dirty in version if the tree is dirty <Bug> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9223>
<pstolowski> morning
<mvo> good morning pstolowski
<mborzecki> pstolowski: heya
<pedronis> mborzecki: hi, I added this comment: https://github.com/snapcore/snapd/pull/9201#discussion_r478204904, not sure it's clear
<mup> PR #9201: [RFC] boot: observe update & rollback of trusted assets <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9201>
<zyga-x240> back from breakfast
<pedronis> I tweaked #9227
<mup> PR #9227: snap: add size to the random access file return interface <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9227>
<zyga-x240> ta
 * zyga-x240 goes for the desktop call
<mborzecki> pedronis: yes, i think it makes sense, i need to think a bit how to do it reliably for newly added assets though
<mborzecki> pedronis: and i've updated the PR since the tweaks for install observer landed
<pedronis> mborzecki: we are holding the state lock during the whole gadget assets update right?
<mborzecki> pedronis: let me double check, i don't think so
<mborzecki> pedronis: we don't, there's an explicit unlock/lock around call to gadget.Update
<Chipaca> ullo ullo
<mborzecki> Chipaca: heya
<Chipaca> zyga: snapd.socket is dead right now, want to know more?
<zyga> Chipaca yes
<zyga> mborzecki ^^^
<zyga> I'm in a call
<zyga> please use this opportunity to learn more
<zyga> Chipaca did snapd snap refresh or did the classic package update?
<zyga> mvo ^
<zyga> could be pretty serious
<Chipaca> neither afaik, but i'll check
<Chipaca> logs are swamped by microk8s poking snapctl (and failing) all the time
<mborzecki> Chipaca: systemctl status snapd.socket please
<Chipaca> mborzecki: https://paste.ubuntu.com/p/K87wFBQwt3/
<mborzecki> Chipaca: heh interesting, Transaction for snapd.service/start is destructive (systemd-suspend.service has 'start' job queued, but 'stop' is included in transaction)
<mborzecki> the system is suspending so systemd won't start the socket or what?
<zyga> woah
<zyga> interesting
<zyga> Chipaca are you suspending your computer often?
<Chipaca> 21.55.20 is a 'reached target Sleep'
<Chipaca> zyga: when i don't use it
<Chipaca> zyga: so, no :-) but daily for sure
<Chipaca> zyga, mborzecki, anything else you want to get out of this, or should i go ahead and restart the socket?
<zyga> Chipaca I think restarting the socket is ok
<mborzecki> Chipaca: hm maybe snap changes and snap change if there's something relevan tin there
<Chipaca> mborzecki: can't do that without restarting the socket :-)
<Chipaca> mborzecki: no changes newer than yesterday at 18:54
<Chipaca> and that was core18 refreshing
<mborzecki> Chipaca: ha, you actually can now, snap debug state
<Chipaca> oooh, schmancy!
<zyga> Chipaca haha, yeah
<mborzecki> snap debug state /var/lib/snapd/state.json [--change=<id> if there's anything relevant]
 * zyga reboots for upgrade quickly
<mup> PR snapd#9226 closed: cmd/snap-bootstrap/initramfs-mounts: compute string outside of loop <Cleanup :broom:> <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9226>
<mup> PR snapd#9229 closed: tests: account for apt-get on core18 <Test Robustness> <â  Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9229>
<zyga> mvo do you need a backport of the GPIO bug fix?
<mvo> zyga: I already cherry-picked it
<zyga> superb, thanks!
<zyga> mvo it's such a terrible bug, I'm sorry for causing this
<mvo> zyga: don't worry
<pedronis> mborzecki: there's probably a bad idea at this point, we need to rethink that
<pedronis> mborzecki: that's probably a bad idea at this point
<mborzecki> pedronis: not locking state?
<pedronis> mborzecki: I mean releasing the lock
<pedronis> yes
<pedronis> it's not clear that that op should so slow to matter
<pedronis> and now we are playing with modeenv without a lock
<pedronis> not a good idea
<mborzecki> ah right
<mborzecki> pedronis: hm thre's some unclear scenarios, can you request a reboot to recovery when assets update is in progress?
<pedronis> mborzecki: well, if we hold the lock you won't be able to
<pedronis> no?
<pedronis> mborzecki: RequestSystemAction asks for the lock
<mborzecki> pedronis: yeah
<mborzecki> pedronis: otoh, it's not like there's going to be GBs of assets being updated, so holding a lock during the update isn't too bad
<pedronis> yes
<pedronis> and the new code is reading modeenv once and then writing it multiple times
<pedronis> so we really need some kind of lock
<pedronis> I don't think it's very explicit but in general the assumption is that we hold the lock
<pedronis> when manipulating modeenv
<mborzecki> pedronis: would a boot package level modeenv lock work?
<pedronis> mborzecki: yes, but I think it will be messy, I wouldn't do that unless we have a strong reason to
<mborzecki> pedronis: hm state lock also has some nice checks built in already
<pedronis> like the code as is would have to old for the existence of the observer
<pedronis> you need to unlock at the right times also on error paths etc etc
 * zyga quick break for something warm (temperature dropped by 15C) and back to reviews
<pedronis> mvo: seems 20.04 is failing degraded with secureboot-db.service loaded failed failed Secure Boot updates for DB and DBX
<mvo> pedronis: fun, I saw this too
<mvo> pedronis: do you plan to review 9227 or shall I do that ? the size() helper one
<pedronis> mvo: I touched it myself now so a review from somebody else is better
<mvo> pedronis: sure thing, doing that now
<mvo> pedronis: similar question about 9213
<pedronis> mvo: 9213, it looks okish, I'm not sure it makes 100% sense but I'm also not sure this the last version of that code we need
<pedronis> mvo: it looks too much like guessing to me
<mvo> pedronis: thanks
<pedronis> mvo: should I leave a comment there?
<mvo> pedronis: I think that would be good
<mup> PR snapd#9209 closed: daemon: correctly parse Content-Type HTTP header <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9209>
<mvo> pedronis: I also looked at 9227 and added a possible suggestion
<pedronis> mvo: done https://github.com/snapcore/snapd/pull/9213/files#r478343623
<mup> PR #9213: secboot: read kernel efi image from snap file <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9213>
<mvo> pedronis: ta
<pedronis> mvo: your suggestion is exactly what I undid , see my new comment
<pedronis> the code originally had the error and use stat
<pedronis> in Size
<pedronis> mvo: sorry, you wasted a bit of time, your suggesting is exactly the reverse of my last commit
<mvo> pedronis: aha, then I misunderstood your comment, I thought you said too much stuff in stat is ill-defined. but this variation is only returning size not the full stat info
<pedronis> mvo: sorry, that was the original comment, my motivation for my last change is its commit
<mvo> pedronis: I see it there now, that's fine then. thank you
<pedronis> mvo: snaps are meant to be immutable (notwithstanding all the fun of try and snapdir) so the size shouldn't really be variable
<mvo> pedronis: yeah, it makes sense
<mup> PR snapd#9227 closed: snap: add size to the random access file return interface <Simple ð> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9227>
<zyga> pedronis: while reviewing validation sets and refreshing my memory, I came across a TODO and wrote https://github.com/zyga/snapd/commit/76049517f35f25e68b165fe0f427555fb790bf93 -- should I propose it later?
<pedronis> zyga: I don't know, I expect there are changes needed also outside of asserts
<zyga> ah, I didn't think about that
<zyga> anyway, it's not a big thing, just something I noticed while reviewing
<pedronis> yes, is something to do
<pedronis> at least seed and seedwrite needs changes as well
<pedronis> don't know if there are other places
<pedronis> naive grepping says likely only seed and seed/seedwriter
<zyga> pedronis validation sets have perfect test coverage, nice
<cachio> zyga, hey
<zyga> hey!
<zyga> I had a quick look at your branch
<zyga> I left some comments,
<cachio> so, yesterday tried everything
<cachio> to make work the user session for root
<zyga> cachio did you get a logind session?
<cachio> also tried the change in spread
<cachio> no
<zyga> cachio ok, I'll try to help after the standup
<cachio> zyga, thnanks
<ijohnson> morning folks
<pedronis> pstolowski: hi, I re-reviewed #9211
<mup> PR #9211: o/snapstate: disk space check with InstallMany <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9211>
<pstolowski> pedronis: thank you!
<pstolowski> will push the tweaks in a moment
<zyga> pedronis https://github.com/snapcore/snapd/pull/9155#pullrequestreview-476677226
<mup> PR #9155: asserts/snapasserts: introduce ValidationSets <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9155>
<mup> PR snapd#9230 opened: overlord/devicestate: do not release the state lock when updating gadget assets <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9230>
<zyga> cachio I'll look at the external thing in a moment, let me grab some food
<cachio> zyga, sure, thanks a lot
<ijohnson> pedronis: actually sorry I forgot I need to step out for a few minutes, can we chat in like 15 minutes or later today about the ensure boot problem ?
<mup> PR snapd#9213 closed: secboot: read kernel efi image from snap file <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9213>
<pedronis> ijohnson: I have meetings in 10 mins for 1h
<pedronis> I can chat after that
<zyga> cachio back with food, let me tinker a little and I'll get back to you
<cachio> zyga, sure
<ijohnson> pedronis: ack I'll send a meeting invite just to be sure
<zyga> cachio I have something that works
<zyga> let me minimize it
<cachio> great
<jdstrand> mvo: hey, so I addressed all feedback in PR 8920 quite some time ago and this is one of the items that I milestoned for 2.46. I'm not sure if people are waiting on pedronis because it has his tag, but I addressed all his feedback so I think really anyone could review
<mup> PR #8920: interfaces: update cups-control and add cups for providing snaps <Needs Samuele review> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8920>
<jdstrand> mvo: zyga did review and approve the now closed PR 9194 (with some non-blocking comments), but 8920 doesn't have reviews
<mup> PR #9194: interfaces: update cups-control and add cups for providing snaps - 2.46 <Created by jdstrand> <Closed by zyga> <https://github.com/snapcore/snapd/pull/9194>
<jdstrand> s/reviews/approvals/
<zyga> mmm
<zyga> I should review those
<zyga> cachio ok
<zyga> cachio try this: sudo systemd-run --unit "spread-$RANDOM" --property=User=root --property=PAMName=runuser-l --pipe sh -c "loginctl"
<zyga> works on 18.04 for sure, I can look at older systems too
<zyga> you can drop the sh -c thing, just give it a path to a script
<cachio> ok
<cachio> systemd-run: unrecognized option '--pipe'
<zyga> cachio 16.04?
<cachio> zyga, core16
<zyga> can you try on newer system
<zyga> I will adjust it to core16
<zyga> try core18 for now
<cachio> sure, let me get the image
<zyga> cachio for 16.04
<zyga> sudo systemd-run --unit "spread-$RANDOM" --property=User=root --property=PAMName=runuser-l --tty  sh -c "loginctl"
<zyga> it's not the best but meh
<zyga> it probably is enough
<cachio> zyga, works
<zyga> note that --pty may be problematic
<zyga> so we may need something slightly different like a hand-rolled code that does this and bridges stdin/stdout
<zyga> without making a pty
<zyga> ptys are problematic
<cachio> so, we a new unit that runs this?
<cachio> to keep the session up during the test?
<zyga> cachio this runs a program with a PAM name
<zyga> in isolation from the session of the calling user
<zyga> that's enough
<cachio> https://paste.ubuntu.com/p/WsPfXcfTH8/
<cachio> I see this
<cachio> same if I run with a test user
<zyga> right
<zyga> on core16 with core18 snap installed:
<zyga> nah, that doesn't work
<zyga> try what I gave you
<zyga> and I'd like to know what you tried
<zyga> since it didn't work for you before
<ijohnson> pedronis: ready ?
<pedronis> ijohnson: finishing previous meeting
<ijohnson> sure let me know when you're ready
<cachio> zyga, just tried manually with the command you sent
<zyga> which command?
<cachio> <zyga> sudo systemd-run --unit "spread-$RANDOM" --property=User=root --property=PAMName=runuser-l --tty  sh -c "loginctl"
<cachio> that one
<pedronis> ijohnson: ready now, sorry
<zyga> I mean before, when it failed?
<cachio> yesterday tried updating spread to use runuser instead of sudo -i
<cachio> to run the script
<cachio> also tried manually to start the session for root using runuser
<cachio> I created a systemd unit with that
<cachio> something similar to what you just passed but without --property=PAMName
<cachio> I manually created the unit
<cachio> I tried to make the unit sleep forlong time
<cachio> to it was going to be running
<cachio> zyga, does it make sense?
<zyga> cachio I wonder why that didn't work
<zyga> but anyway
<zyga> now you have something to work with
<cachio> zyga, yes, I'll try with this
<cachio> I think I can make it work
<cachio> zyga, thanks
<cachio> I'll try again after lunch
 * cachio lunch
<ijohnson> jdstrand: rebuilding a snap with go 1.15, I see a seccomp denial that isn't there when compiled with go 1.14 for copy_file_range, and that is only allowed for docker-support currently
<ijohnson> jdstrand: is it possible / feasible / sensible to add that to the default template ?
<ijohnson> the denial looks like this: `audit: type=1326 audit(1598542961.776:12423): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=157684 comm="security-secret" exe="/snap/edgexfoundry/x1/bin/security-secrets-setup" sig=0 arch=c000003e syscall=326 compat=0 ip=0x47b5ea code=0x50000`
<ijohnson> jdstrand: see also this update in the go 1.15 release notes:
<ijohnson> > The os.File type now supports a ReadFrom method. This permits the use of the copy_file_range system call on some systems when using io.Copy to copy data from one os.File to another.
<ijohnson> jdstrand: ah apparently there is an upstream fix for this where if copy_file_range returns EPERM then Go falls back to an alternate impl that should work in confinement see https://go-review.googlesource.com/c/go/+/249257/
<ijohnson> so I guess this problem will just go away with the next Go release, but is there a security reason not to allow copy_file_range in the default profile ?
 * zyga goes to work upstairs 
<ijohnson> cachio: the regexp in ubuntu-core-20-64:tests/main/listing needs to be updated too to account for pre versions
<ijohnson> cachio: see the failure here: https://pastebin.ubuntu.com/p/MBG5Crr8bC/
<cachio> ijohnson, ah, yes, I'll do it today
<cachio> ijohnson, thanks for the heads up
<ijohnson> cachio: np
 * cachio afk 30 minues
<jdstrand> ijohnson: sorry, was in a meeting
<ijohnson> jdstrand: no worries, if you prefer I can open a PR tagged with security review and discussion can take place there
<jdstrand> ijohnson: reading the man page, it seems like a reasonable addition for the default template since a) you are giving it open fds that should be mediated by apparmor and b) this is not dissimilar to write()
<jdstrand> ijohnson: so, logically, it makes sense but would need to look deeper into how the LSM handles it
<jdstrand> ijohnson: that sounds fine
<ijohnson> jdstrand: ack I can certainly throw up a PR for you to look at eventually
<ijohnson> jdstrand: they are unblocked since go 1.15 will be updated to fix the problem sometime soon, so it's not a rush to fix anymore
<ijohnson> thanks!
<mup> PR snapd#9230 closed: overlord/devicestate: do not release the state lock when updating gadget assets <Simple ð> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9230>
<mup> PR snapd#9231 opened: tests: update listing test for "-dirty" versions <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9231>
<mup> PR snapd#9232 opened: run-checks: check for dirty build tree too <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9232>
<mup> PR snapd#9231 closed: tests: update listing test for "-dirty" versions <Test Robustness> <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9231>
<mup> PR snapd#9233 opened: vendor: run ./get-deps.sh to update the secboot hash <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9233>
<mup> PR snapcraft#3268 opened: v2 plugins: add catkin plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/3268>
<mup> PR snapd#9234 opened: systemd/systemd.go: support journald JSON messages with arrays for values <Bug> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9234>
#snappy 2020-08-28
<mup> PR snapd#9235 opened: tests: new tests for nested and external <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9235>
<mup> PR snapd#9233 closed: vendor: run ./get-deps.sh to update the secboot hash <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9233>
<mborzecki> morning
<mup> PR snapd#9232 closed: run-checks: check for dirty build tree too <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9232>
<zyga> o/
<zyga> mvo you're up early
 * zyga leaves the macbook to charge and goes upstairs to do reviews from the imac
<mborzecki> mvo: zyga: hey
<mvo> hey zyga and mborzecki
<mup> PR snapd#9236 opened: kernel: remove "edition" from kernel.yaml and add "update" <Created by mvo5> <https://github.com/snapcore/snapd/pull/9236>
<mborzecki> heh, in the 15.2 images we have there's no daemon user/group
<mborzecki> zyga: i think we need to fix the rpm spec on openssue and add a dependency on system-user-daemon (as daemon is needed for system usernames)
<mborzecki> zyga: idk why but installing lsb release does not seem to pull in that package (even though daemon user is required by lsb?)
<mvo> thanks for this
<mvo> I mean, thanks for looking/fixing this
<mvo> mborzecki: quick question - gadget updates are already smart in the sense that there is no file update if the hash is the same, correct?
<mborzecki> mvo: yes
<mvo> ta
 * mvo still scratches head over how to best apply the kernel-dtb refs
<mborzecki> mvo: this is the bit that does that https://github.com/snapcore/snapd/blob/master/gadget/mountedfilesystem.go#L763
<mvo> mborzecki: ta
<jamesh> zyga: thanks for the review comments.  Since you're the expert on process tracking, my spread test is failing on Ubuntu 14.04, where it doesn't seem to be able to identify a process from a classic confined snap.  Is that a known limitation?
<zyga> jamesh, yes, 14.04 has no tracking
<zyga> jamesh we could fake it I mean
<zyga> we can expand tracking to use apparmor labels
<zyga> that would cover 14.04
<zyga> by fake it, I mean we could be better while not being really equal to 16.04+
<zyga> mborzecki sounds good (dependency change) - I have some changes I didn't merge into master, related to suse packaging
<jamesh> zyga: weird that the rest of the test using strict confinement passed then.
<zyga> jamesh, hmmm, but even with classic confinement, we should be setting an apparmor label
<mborzecki> zyga: i have a fix to push to #9218
<mup> PR #9218: tests: running tests on opensuse leap 15.2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9218>
<jamesh> zyga: I could probably just skip the test on 14.04
<zyga> jamesh which exact test is that?
<zyga> jamesh I honestly think that's best
<zyga> 14.04 is not a fully supported release
<jamesh> zyga: the spread test in https://github.com/snapcore/snapd/pull/9132: the "exit_staus 11 ..." test at the end to check against a classic process returns 10 (which is "not snap confined")
<mup> PR #9132: o/hookstate/ctlcmd: add optional --pid argument to "snapctl is-connected" <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9132>
<zyga> jamesh I'll look
<pstolowski> morning
 * zyga small errand
<zyga> hey Pawel
<mvo> good morning pstolowski
<mborzecki> zyga: can you take a look at?
<mborzecki> zyga: pff, forgot to paste the link ;P https://github.com/snapcore/snapd/pull/9218
<mup> PR #9218: tests: running tests on opensuse leap 15.2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9218>
<pstolowski> eh, snap-logs test failures seem related to my services changes but i don't understand how
<pstolowski> did anyone see this test failing on master recently?
<zyga> mborzecki looks sensible
<mborzecki> pstolowski: snap logs?
<mborzecki> pstolowski: there's a PR from ijohnson with a bug fix, do you have a log?
<pstolowski> mborzecki: yes sna logs
<mborzecki> pstolowski: this PR from ian: https://github.com/snapcore/snapd/pull/9234
<mup> PR #9234: systemd/systemd.go: support journald JSON messages with arrays for values <Bug> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9234>
<mborzecki> related?
<pstolowski> mborzecki: ah, interesting! thanks, could be
<pstolowski> going to test with my branch
<pstolowski> this test often fails on snap logs -f ... check (no match for the expected log message), but snap logs -n=all does include it
<mborzecki> quick errand, back in 30
<pedronis> pstolowski: now the service PR is ready for re-review, right? (not sure I'll get to it today though)
<pstolowski> pedronis: i'm testing ijohnson's fix for log parsing to see if it fixes snap-logs test failures in my PR, i'll know shortly
<mborzecki> re
<pedronis> mborzecki: hi, is #9201 still a draft or should I re-review it?
<mup> PR #9201: boot: observe update & rollback of trusted assets <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9201>
<mborzecki> pedronis: i converted it to non-draft
<mborzecki> pedronis: would appreciate if you could take a look, and maybe we can discuss things if needed
<pedronis> ok
<mborzecki> mvo: can you force merge https://github.com/snapcore/snapd/pull/9218 ? the failure on 18.04 is unrelated
<mup> PR #9218: tests: running tests on opensuse leap 15.2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9218>
<mvo> mborzecki: sure
<mvo> mborzecki: also reviewed/approved the other pr
<mborzecki> mvo: thanks!
<mup> PR snapd#9218 closed: tests: running tests on opensuse leap 15.2 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9218>
<pstolowski> pedronis: Ian's fix didn't help with my issue with snap-logs, probably makes sense if you wait till i figure out what's going on
<pedronis> pstolowski: ok, it wasn't yet at the top of my queue anyway
<pstolowski> ha https://pastebin.ubuntu.com/p/v9G8ZMsw2c/
<pstolowski> journalctl seems to be skipping messages if we ask for multiple units
<mborzecki> macos github job failing?
<mborzecki> huh https://github.com/snapcore/snapd/runs/1041031007
<mborzecki> go get golang.org/x/sys/unix apparently fails there
<ijohnson> morning folks
<ijohnson> anybody have any ideas why I would be getting `cannot install "generic-classic" fallback model assertion: no matching public key "Lcw4MOHeD6yUabUqD_Gd5BwBGuJBB6t8jDV42wg02jv5XikFZoe6CBMJAo5pTbrW" for signature by "generic"` for unit tests I didn't change in o/devicestate ?
<ijohnson> pedronis: maybe ^ ?
<pstolowski> hi ijohnson
<ijohnson> hey pstolowski
<ijohnson> more fun with journald I see ?
<pstolowski> ijohnson: yes
<ijohnson> the fun never ends!
<pedronis> ijohnson: where is that?  it seems an assertion db not configured right
<ijohnson> pedronis: it comes from the firstBoot16Suite.TestPopulateFromSeedOnClassicNoop unit test
<ijohnson> this only happens when I enable my 2nd suite in devicestate_cloudinit_test.go for uc20 variants
<ijohnson> where my uc20 suite inherits from the devicemgrbasesuite
<pedronis> ijohnson: ok, something is not cleaning up correctly I suppose
<ijohnson> pedronis: what's most confusing is that I have tried even deleting all of the setup code from my uc20 suite, and simply calling the device mgr base suite setup is enough to trigger this other unit tests to fail
<ijohnson> pedronis: do you want me to push a wip branch to look at the tests ?
<pedronis> ijohnson: I suppose
<ijohnson> one moment
<ijohnson> pedronis: sorry still a wip commit, but here is my current branch: https://github.com/anonymouse64/snapd/commit/8c17373ac055a1d0ef90f99f3bc8a566ed594b95
<ijohnson> pedronis: if you just run all the tests in o/devicestate you should see the issue with all of my various print statements
 * ijohnson afk for quick breakfast
<mborzecki> 2020-08-28T10:15:41.3077042Z - Fetch and check assertions for snap "test-snapd-content-plug" (5) (cannot fetch assertion: got unexpected HTTP status code 408 via GET to "https://api.snapcraft.io/api/v1/snaps/assertions/snap-revision/UzfhJIDc1A04xUNzbAEwvu2_aCeT3FxOvo5tsKFG2V9ZzssK_ZIaEiRAFh8RdNus?max-format=0")
<mborzecki> pedronis: still getting 408 from time time apparently ^^
<pedronis> yea
<ijohnson> ok I'm back
<mvo> pstolowski: 9211 looks good, please let me know if you need a force-merge or if the spread issues are real
<ijohnson> mvo: could I ask for your super powers on https://github.com/snapcore/snapd/pull/9225#issuecomment-682478359 ?
<mup> PR #9225: many: cloud-init cleanups from previous PR's <Cleanup :broom:> <Run nested> <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9225>
<ijohnson> the comment I just linked to explains the various spread failures, some of which are already fixed in master
<ijohnson> none of which are related to the PR in question
<ijohnson> huh I think the issue I was having is that my cloudInitUC20Suite embedded the cloudInitBaseSuite struct, which embeds the deviceMgrBaseSuite, and so it inherited a SetUpTest from that, but then I also called setup on deviceMgrBaseSuite again separately, so setting my test up twice caused a different test to fail
<ijohnson> pedronis: ^
<pstolowski> mvo: yes i think you can merge
<pedronis> ijohnson: yes, I see some setup being run twice, is that the problem though?
<ijohnson> pedronis: I am not 100% sure, but I am going to try with a small patch on master to see if I can reproduce with just calling deviceMgrBaseSuite's setup twice on a single test
<pedronis> ijohnson: anyway fwiw the line that is causing trouble is 	s.AddCleanup(sysdb.MockGenericClassicModel(s.storeSigning.GenericClassicModel))
<ijohnson> yes
<ijohnson> sorry I meant interesting
<pedronis> it seems is not undone properly ?
<ijohnson> hmm
<pedronis> ah
<pedronis> it's funny probably
<pedronis> in a terrible sort of funny way
<pedronis> let me see if I'm right
<pedronis> ijohnson: yes, the issue is the double setup, the problem with that is among other things that the first setup is never undone, because the 2nd setup will simply reset the cleanup function list
<ijohnson> pedronis: hmm that's weird, should we fix that ?
<pedronis> ijohnson: I don't know if it's weird or not, it's one way to implement this, you need to stare at testutils/base.go
<ijohnson> uhh
<ijohnson> AddCleanup just appends the handlers, so the handler should just get called even if it's appended twice ?
<ijohnson> oh I wonder if it's called in the wrong order
<ijohnson> maybe AddCleanup should be a stack
<pedronis> well, the order is weird as well
<pedronis> but that's the problem
<ijohnson> *use
<pedronis> your second setup
<pedronis> calls the BaseTest.Setup
<pedronis> that's just forgets everything
<ijohnson> ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
<ijohnson> yes you're right
<ijohnson> I see it now
<pedronis> SetUpTest is not really intended to be called twice
<pedronis> in general I mean
<ijohnson> yes, I'm not sure how I accidentally got to that point
<ijohnson> but I think it's clear to me that as long as we don't use BaseTest.SetUpTest twice things are fine
<ijohnson> so that was my original problem
<pedronis> yes
<ijohnson> ok, good to know
<pedronis> but I agree that the order we call the cleanup is weird
<pedronis> it should be a stack
<ijohnson> I will fix up this commit and open the PR shortly
<pedronis> I don't know why is like that
<ijohnson> probably just because it was easy
<ijohnson> last change to that file was 4 years ago
<pedronis> anyway I don't think SetUpTest should need to cleanup the handlers, is not a map, otoh maybe it should panic if the handlers are not empty already
<ijohnson> I like that change a lot actually
<ijohnson> would have made it super obvious my error very quickly
<pedronis> maybe I should try to do that in a separate PR and fix the order, and see if anything breaks
<ijohnson> I will propose that in a separate PR I think
<pedronis> or you can
<ijohnson> well I will work on that after opening the cloud-init PR
<ijohnson> so if you want to do it first go for it
<pedronis> ok, I'll try to do that just now
<pedronis> ijohnson: we have some tests that fail interestingly
<cachio> zyga, hi
<zyga> hi
<ijohnson> oooh fun
<ijohnson> morning cachio and zyga
<zyga> nice find on non-stack cleanup for base test
<cachio> ijohnson, good morning
<zyga> and the related issues
<zyga> maybe base test should panic if invoked incorrectly
<pedronis> ijohnson: one is cloud init, was the problem already on master?
<cachio> zyga, yesterday implented what you sent and that works, the session is created
<ijohnson> pedronis: no, there shouldn't any problems on master
<ijohnson> well I don't think so
<cachio> zyga, during the test the sesions is there
<ijohnson> pedronis: what test failed ?
<pedronis> ijohnson: well it's panicing
<ijohnson> err how did it fail
<cachio> zyga, but still fails when we do "systemctl --user daemon-reload"
<pedronis> well I added code to panic if cleanup handlers are not empty in setup
<pedronis> what I said before
<ijohnson> :-(
<ijohnson> ok, I will have a look
<zyga> cachio what do you mean "fails", what fails when you do this?
<cachio> zyga, 1 sec
<pedronis> ijohnson: I see issues with repair, something in cmd/snap (just one test, that is weird)
<pedronis> and then quite a few in devicestate
<pedronis> the rest is fine
<cachio> zyga, https://paste.ubuntu.com/p/PPYFgSQy69/
<cachio> fail like this
<zyga> cachio before the failure, do we still have the seesion?
<cachio> zyga, yes
<zyga> are you absolutely sure?
<cachio> when it fails we have the session in the debug session
<zyga> the root session?
<cachio> yes
<zyga> can you check the status of user@0.service
<cachio> zyga, sure
<ijohnson> pedronis: I don't understand how, but if I make cloudInitSuite embed a pointer to deviceMgrBaseSuite and initialize that pointer in cloudInitSuite.SetUpTest, then the panic goes away
<ijohnson> pedronis: I have seen other test suites that inherit base suites do that too, so perhaps that's the thing to do
<ijohnson> otoh, I have seen the pattern of not defining SetUpTest for the base suite, and instead having something like setup() for the base suite which needs to be called from the final suite's SetUpTest
<pedronis> ijohnson: so some tests call SetUpTest on their own, fun
<pedronis> without TearDown
<ijohnson> ugh what
<ijohnson> I'm still confused how this happens for i.e. the cloudInitSuite since we aren't manually calling SetUpTest there
<pedronis> well, I'll have to stare it myself in a bit
<ijohnson> ok, well we know how to make the panic's go away
 * ijohnson returns to prepping the cloud-init PR
<cachio> zyga, https://paste.ubuntu.com/p/vvxJCWCr67/
<zyga> cachio and systemctl --user status
<zyga> (note: assuming this is invoked by root)
<zyga> not by the external user
<cachio> Failed to connect to bus: No such file or directory
<zyga> strace -f systemctl --user status
<zyga> and check which connect fails
<cachio> I am in core16
<cachio> dont have strace
<cachio> is there an y snap instead?
<zyga> we have strace static
<zyga> try that
<cachio> this is hte output https://paste.ubuntu.com/p/KjKMz6s5g9/
<zyga> cachio run strace-static directly, not as a snap please
<cachio> https://paste.ubuntu.com/p/w5krDr87Np/
<cachio> like that?
<zyga> no
<zyga> that's not any different
<zyga> directly without snap run pipeline
<cachio> zyga, https://paste.ubuntu.com/p/VGQYZKsXP5/
<zyga> open("/sys/fs/kdbus/1001-user/bus", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
<zyga> this is not running as root for real
<zyga> are you logged in as the external user?
<cachio> https://paste.ubuntu.com/p/t3sHWqj9CC/
<cachio> we login as external
<zyga> using sudo / su will again bring back the same issues
<zyga> it's not the same
<zyga> as logging in as root
<cachio> through ssh
<cachio> then we make sudo to run the test script
<zyga> hmm?
<zyga> we cannot do that
<cachio> so we should run with runuser?
<zyga> we must use what I provided to run the script
<zyga> runuser won't work directly
<zyga> do you understand what the problem is?
<cachio> partially
<zyga> the script cannot run in the session of the external user which just happens to elevate to root
<zyga> our tests do not cope with that
<zyga> my suggestion was to run the whole test this way
<zyga> "this way" is the way we talked about yesterday, with the service and pam name
<zyga> this then runs in an environment very similar to root ssh-ing into the system
<zyga> cachio perhaps we can log in as external
<zyga> install a ssh key for root
<zyga> and then go back to running as root
<cachio> is it possible to do that in core syste?
<cachio> to add a ssh key for root?
<zyga> can you write to /root/.ssh/?
<zyga> if so then yes
<zyga> I mean...
<zyga> root is not read only :D
<cachio> zyga, but to connect to the system  using spread a password we need for root
<cachio> because spread just connects using password
<zyga> something has to change
<zyga> what we have doesn't work
<zyga> we just need to pick the most sensible thing to alter
<cachio> zyga, so
<cachio> some time ago I did a change
<cachio> in sporead to support connecting using ssh keys
<cachio> if we could add that to spread we could connect using root
<cachio> and the problem is solved
<cachio> right?
<zyga> if we can connect as root over ssh then yes
<zyga> however that is done
<zyga> cachio could we hack it like this?
<zyga> add an extrauser
<zyga> root-with-password
<zyga> have it have uid 0
<zyga> and home /root
<zyga> but have a password?
<cachio> we need password for spread
<zyga> right, but isn't that what I just said?
<cachio> I though it was a question
<zyga> cachio?
<cachio> 1 sec
<cachio> can do that
<cachio> Warning: The home dir /root you specified already exists.
<cachio> adduser: The UID 0 is already in use.
<zyga> cachio you can add it as another uid
<zyga> and just sed it to zero
<zyga> it's just the tool that complains
<cachio> zyga, cant create the home /root
<cachio> because it already exists
<zyga> use whatever directory and edit the created user
<zyga> you can just edit the text file
<zyga> you can even just append to
<mup> PR snapd#9237 opened: [RFC] many: enable cloud-init on uc20 for grade signed and secured <Complex> <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9237>
 * zyga will go AFK in about 10 minutes
<mborzecki> errands, bbl
<pedronis> ijohnson: so on master things are clean for me now
<pedronis> devicestate was in a very messy state though
<mup> PR snapd#9225 closed: many: cloud-init cleanups from previous PR's <Cleanup :broom:> <Run nested> <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9225>
<cachio> ijohnson, is this the same error you fixed a time ago for uc20-recovery test? https://paste.ubuntu.com/p/C94XTPBTWG/
<ijohnson> cachio: could be, will look in little bit
 * cachio lunch
<ijohnson> pedronis: so are you going to prepare a PR to make the panic change ?
<pedronis> ijohnson: yes, about to propose it actually
<ijohnson> pedronis: also if you could give a quick review to #9237 on the general direction and options names and such I can split it up
<mup> PR #9237: [RFC] many: enable cloud-init on uc20 for grade signed and secured <Complex> <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9237>
<ijohnson> thanks
<ijohnson> I guess names of things can be separate PR's but the overall interaction between devicestate and sysconfig.ConfigureRunSystem via the options is more what I'm curious about
<pedronis> ijohnson: I have a meeting now but I'll try to look after
<ijohnson> k, thanks
<pedronis> ijohnson: https://github.com/snapcore/snapd/pull/9238 is the PR, likely it might conflict with yours
<mup> PR #9238: many: check that users of BaseTest don't forget to consume cleanups <Created by pedronis> <https://github.com/snapcore/snapd/pull/9238>
<mup> PR snapd#9238 opened: many: check that users of BaseTest don't forget to consume cleanups <Created by pedronis> <https://github.com/snapcore/snapd/pull/9238>
<ijohnson> pedronis: sure no problem, the RFC one won't be mergable right away unless one big PR review is easiest
<mup> PR snapd#9239 opened: many: misc doc-comment changes and typo fixes <Simple ð> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9239>
<pstolowski> pedronis: your hunch about systemd & my --root change was good... this is peculiar: https://pastebin.ubuntu.com/p/yMXYd93ZQZ/
<pstolowski> also funny how the message is slightly different
<ijohnson> pedronis: I de-conflicted things so that #9237 doesn't need your PR and doesn't conflict with it afaict and updated the PR description to reflect this
<mup> PR #9237: [RFC] many: enable cloud-init on uc20 for grade signed and secured <Complex> <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9237>
<pstolowski> the basic problem is we set rsyslog in gagdet defaults (which makes no sense on core18 but because of emulation mode), but then we fail on normal "snap set.. ", but that was masked with --root=.. as my pastebin demonstrates, because it prints error but gives exit 0
<ijohnson> pstolowski: bash exit codes strike again?
<pstolowski> ijohnson: what about bash exit codes?
<mup> PR snapd#9240 opened: o/devicestate/devicestate_cloudinit_test.go: test cleanup for uc20 cloud-init tests <Simple ð> <Skip spread> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9240>
<ijohnson> pstolowski: you said "because it prints error but gives exit 0"
<pstolowski> ijohnson: see https://pastebin.ubuntu.com/p/yMXYd93ZQZ/
<ijohnson> just curious if that was related to all the random bash issues that zyga has discovered recently
<pstolowski> ijohnson: ah got you. no it's not bash, it' ssytemctl behavior
<ijohnson> ah great
<ijohnson> that's so silly
<pstolowski> ijohnson: note the slightly different spelling of the error message...
<ijohnson> --root=/ makes it exit with code 0 and not that option makes it exit with code 1
<pstolowski> yet it means the same
<ijohnson> oh ffs
<ijohnson> that's ridiculous
<pstolowski> "error but not really"
<pstolowski> it's also the case on 20.04
<ijohnson> mmm how do we do tests for grade signed images in spread with custom snapd snaps
<ijohnson> because grade signed model assertions don't allow unasserted snaps
<ijohnson> pedronis: thoughts ?
<ijohnson> cachio: do you have more logs from that uc20-recovery failure? it seems that it should have gone back to run mode but it didn't so that seems like a real test failure
<mup> PR snapd#9241 opened: tests: do not set rsyslog.disable in core18 config defaults test <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9241>
<pstolowski> i see no other option than ^
<pedronis> ijohnson: there is nothing easy we can do, what kind of modifications do you need?
<pedronis> ijohnson: also I did a pass on #9237
<mup> PR #9237: [RFC] many: enable cloud-init on uc20 for grade signed and secured <Complex> <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9237>
<pstolowski> hmm i wonder if we should maybe ignore error on disable in configcore
<pedronis> pstolowski: well, if I understand the issue is that we trying to disable a service that doesn't exist?
<pedronis> and in that case --root makes a difference
<pstolowski> pedronis: yes, we do that because test setup is wrong, but it is masked because with --root systemctl returns 0
<ijohnson> pedronis: I'm trying to write a spread test of the grade signed cloud-init changes
<ijohnson> pedronis: but how do I test grade signed with an unasserted custom snapd snap
<pedronis> pstolowski: systemd seems to be using a special exit code to mean no unit
<pedronis> but is not consistent
<pstolowski> pedronis: yes
<zyga> back from PT
<zyga> I need to catch up and cover this time, I'll be here for a few hours at least
<pedronis> ijohnson: we can only write a test using store snaps , so I'm asking what changes do we need?  otherwise we can have a chat but the solutions are slightly horrible
<ijohnson> pedronis: well if we accept that we can only write cloud-init spread tests for grade signed, then we don't need any changes
<ijohnson> pedronis: it just means that getting all the bits correct for uc20 cloud-init will take more time as I can't verify anything with an integration test
<pedronis> I can't parse that sentence
<ijohnson> pedronis: sorry let me rephrase
<ijohnson> pedronis: I would like to write a spread test like we have for uc16/uc18 cloud-init but for grade==signed uc20
<ijohnson> pedronis: but I can't write this spread test today because there is no snapd snap in the store with my changes I made
<zyga> cachio any luck?
<pedronis> ijohnson: can we have a quick chat?
<ijohnson> pedronis: sure
<ijohnson> pedronis: I'm in SU HO
<pedronis> pstolowski: it seems that systemctl status foo uses exit code 4 when the unit is not there, maybe we should teach systemd.Status to detect that and then use Status in the loop to know if a service exits at all
<pedronis> ans just skip doing anything with it
<pedronis> if it doesn't
<pstolowski> pedronis: to be clear about systemctl issue, this is not about emulation mode (we use it when we should); this is about running for real, per man page the mere presence of --root bypasses systemd (and apparently changes semantics of error code)
<pstolowski> pedronis: yeah, probably
<pedronis> yes, that's why I'm suggesting something slightly complicated
<pedronis> I don't think we want to just ignore errors without understanding them
<pstolowski> fair point
<pstolowski> i'll address this on monday, thanks
<pstolowski> have a great weekend everyone!
<cachio> ijohnson, hey, do you know if there was any change that could produce this cd: /home/gopath/src/github.com/snapcore/snapd/tests/core/uc20-recovery: No such file or directory
<cachio> I think it is the first thing you fixed
<cachio> for this test
<ijohnson> cachio: I asked earlier before you disconnected
<ijohnson> cachio: do you have more logs from that run ?
<cachio> no, but I can reproduce it
<ijohnson> cachio: what seems to have happened is a real test failure, where we went to reboot and should have gone back to run mode, but we didn't and went back to recover mode
<ijohnson> cachio: if you could get me the full system journal that would be great
<cachio> and give you a shell there
<ijohnson> I need to go break for lunch now, but will be back in a little bit to debug this further with you
<cachio> ijohnson|lunch, sure
<pedronis> #9201 needs 2nd reviews
<mup> PR #9201: boot: observe update & rollback of trusted assets <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9201>
 * zyga grabs coffee 
<ijohnson> pedronis: yes I can take a look, also should I look at the cups PR again today ?
<pedronis> ijohnson: if you can (abou cups)
<ijohnson> pedronis: sure
<cachio> ijohnson, I have an instance ready
<cachio> ijohnson, which already failed
<cachio> you need to be connected to the vpn
<pedronis> cmatsuoka: ijohnson: do you need anything more from me today?
<ijohnson> pedronis: no I'm good
 * ijohnson is staring at fakestore
 * ijohnson to some useful effect however
<cmatsuoka> pedronis: I'm trying the bootloader chain composition but found some problems
<cmatsuoka> pedronis: mainly related to being unable to, after composing the run mode chain, map entries to the asset cache
<cmatsuoka> (because we don't know from the final chain which parts came from each bootloader)
<cmatsuoka> in my previous implementation I was doing this mapping before composing the run mode chain
<cmatsuoka> I could do the same thing but it seems to me that the bootloader shouldn't be cache-aware
<cmatsuoka> anyway, I'll think a bit about the in-between degraded upgrade states before returning to the boot chains
<pedronis> cmatsuoka: I see two approaches to that we include the root path in the assets names then you can find which partition/bootloader they belong to from that, or we return just names (that is what we need) and have a separate flag/marker to know which role/partition they are on
<cmatsuoka> pedronis: just the name with an origin mark should solve it
<cmatsuoka> pedronis: thanks
 * cachio afk
